Help
Options
Didn't know it?
click below
click below
Knew it?
click below
click below
Don't Know
Remaining cards (0)
Know
retry
shuffle
restart
0:00
Embed Code - If you would like this activity on your web page, copy the script below and paste it into your web page.
Normal Size Small Size show me how
Normal Size Small Size show me how
FInal Exam CS 3365
Exam F
| Question | Answer |
|---|---|
| When you test software, you are trying to do two things. What are they? | Discover situations in which the behavior of the software is incorrect Demonstrate the software meets its requirements |
| Which one of the following testing states tests individual methods/functions? | Unit Testing |
| Sometimes software needs to go through urgent changes. What may cause these urgent changes? | Changes to the systems environment New government legislation Detection of critical faults |
| Companies have to decide if they want to keep maintaining a legacy system or scrap it. Which of the following situations will a company choose to maintain a legacy system instead of scraping it? | The system is fairly stable, and the system users make relatively few change requests |
| It is usually more expensive to add new features to a system at certain stages. Which of the following stages should you add new features to a system to minimize cost? | Development Stage |
| When/what stages it is usually more expensive to add new features to a system? | Evolution Stage Maintenance Stage |
| What are some of the negative impacts of computing solutions in society? | Computing solutions sometimes produce displacement and unemployment. |
| What are some of the positive impacts of computing solutions in society? | Employment Benefits: Able to manage tasks more efficiently Information Security |
| What are some of the positive impacts of computing solutions in society? | Higher Quality Products: Microcomputers installed in cars now provide more efficient means of controlling the engine‘s fuel mixture, ignition timing, etc. |
| What are some of the positive impacts of computing solutions in society? | Aid to the handicapped: Give vision to the blind Speech recognition systems that allow users to control other machinery by speaking |
| What are some of the positive impacts of computing solutions in society? | Improved Safety: Vehicles that auto steer when they detect imminent dangers. Systems that detect fires and burglaries and notify law enforcement. |
| What are some of the positive impacts of computing solutions in society? | Better Information Retrieval: Quick computer-assisted retrieval saves time Search engines |
| What are some of the negative impacts of computing solutions in society? | Preserving the privacy of confidential information when large data banks are linked by networks, etc. |
| What are some of the negative impacts of computing solutions in society? | Reduced face-to-face interactions, and social disconnect & Increase cyber crimes. |
| What stages/phases correlate and are invariably inter-leaved with the development of an executable software system? | Software Design Implementation Stage |
| Software design: | a creative activity in which you identify software components and their relationships, based on a customer’s requirements. |
| Implementation Phase: | the process of realizing the design as a program. (Design is about how to solve a problem, so there is always a design process.) |
| System context models and interaction models present: | complementary views of the relationships between a system and its environment use case diagrams identify the "actors" of the system and the major interfaces. context diagram focus on the users of the system and their needs. |
| A system context model: | a structural model that demonstrates the other systems in the environment of the system being developed. Ex: context diagram |
| An interaction model: | a dynamic model that shows how the system interacts with its environment as it is used. Ex: Use-cases |
| The context model of a system may be represented using associations. What are associations? | Associations simply show that there are some relationships between the entities involved in the association. |
| Design models: | show the objects and object classes and relationships between these entities. |
| When you use the UML to develop a design, you should develop two kinds of design models: | Structural Models Dynamic Models |
| Structural Models: | describe the static structure of the system in terms of object classes and relationships. |
| Dynamic Models: | describe the dynamic interactions between objects. Interactions that may be documented include the sequence of service requests made by objects and the state changes triggered by these object interactions. |
| Object-oriented design using the UML: | When you model the interactions of a system with its environment, you should use an abstract approach that does not include too much detail. Use a use-case model |
| Observer pattern: | defines one to many dependencies(relationships) between objects. When one object changes state, all of its dependencies are notified and updated automatically. |
| Observer pattern implementation needs (1): | Name: Observer Description: Separates the display of object state from the object itself. Consequences: Optimisations to enhance display performance are impractical. |
| Observer pattern implementation needs (2): | Problem Description: Used when multiple displays of state are needed. Solution Description: UML Implementation |
| A UML model of the Observer pattern: | This involves two abstract objects, Subject and Observer, and two concrete objects: ConcreteSubject and ConcreteObject |
| A UML model of the Observer pattern: ConcreteSubject and ConcreteObject | inherit the attributes of the related abstract objects. The abstract objects include general operations that are applicable in all situations. |
| A UML model of the Observer pattern: ConcreteSubject | The state to be displayed is maintained in this abstract, inherits operations from Subject allowing it to add and remove Observers and to issue a notification when the state has changed. |
| A UML model of the Observer pattern: ConcreteObserver | maintains a copy of the state of ConcreteSubject and implements the Update() interface of Observer that allows these copies to be kept in step. Then automatically displays the state and reflects changes whenever the state is updated. |
| Implementation issues: Reuse | Most modern software is constructed by reusing existing components or systems. When you are developing software, you should make as much use as possible of existing code. |
| Implementation issues: Configuration management | During the development process, you have to keep track of the many different versions of each software component in a configuration management system. If not, might include a wrong version of a component in your system. |
| Implementation issues: Host-target development | Production software does not usually execute on the same computer as the software development environment. Rather, you develop it on one computer (the host system) and execute it on a separate computer (the target system). |
| Software reuse levels: The abstraction level | you don’t reuse software directly but use knowledge of successful abstractions in the design of your software. (Design patterns and architectural patterns) |
| Software reuse levels: The object level | you directly reuse objects from a library rather than writing the code yourself. |
| Software reuse levels: The component level | Components are collections of objects and object classes that you reuse in application systems. |
| Software reuse levels: The system level | you reuse entire application systems. Sometimes may integrate several systems to create a new system. |
| Reuse costs advantage | By reusing existing software, you can develop new systems more quickly, with fewer development risks and at lower cost, since it’s been tested previously, they are more reliable. |
| Patterns: | Patterns and Pattern Languages are ways to describe best practices, good designs, and capture experience in a way that it is possible for others to reuse this experience. |
| Reuse costs disadvantage | The costs of adapting and configuring the reusable software components or systems to reflect the requirements of the system that you are developing. |
| Open-source development: | an approach to software development in which the source code of a software system is published, and volunteers are invited to participate in the development process (Its roots are in the Free Software Foundation ) |
| Component/system deployment factors | The hardware and software requirements of a component The availability requirements of the system Component communications |
| Benefits of using open-source software | Usually cheaper (Or even free) Open source systems are widely used; therefore, more reliable. Has a large population of users who are willing to fix problems themselves Bugs are discovered and repaired more quickly |
| License models: The GNU General Public License (GPL) | This is a so-called ‘reciprocal’ license which means that if you use open-source software that is licensed under the GPL license, then you must make that software open-source. |
| License models: The GNU Lesser General Public License (LGPL) | a variant of the GPL license where you can write components that link to open-source code without having to publish the source of these components. |
| License models: The Berkley Standard Distribution (BSD) License | This is a non-reciprocal license, which means you are not obliged to re-publish any changes or modifications made to open-source code. You can include the code in proprietary systems that are sold. |
| Configuration management activities: Version management | where support is provided to keep track of the different versions of software components Version management systems include facilities to coordinate development by several programmers |
| Configuration management activities: System integration | where support is provided to help developers define what versions of components are used to create each version of a system |
| Configuration management activities: Problem tracking, | where support is provided to allow users to report bugs and other problems, and to allow all developers to see who is working on these problems and when they are fixed. |
| Program testing: | Testing is intended to show that a program does what it is intended to do and to discover program defects before it is put into use. |
| Program testing process | You execute a program using artificial data. You check the results of the test run for errors, anomalies or information about the program’s non-functional attributes. Testing can reveal the presence of errors NOT their absence. |
| Program testing goals: 1 | To demonstrate to the developer and the customer that the software meets its requirements leads to validation testing |
| Program testing goals: 2 | To discover situations in which the behavior of the software is incorrect, undesirable, or does not conform to its specification. Caused by defects(bugs) leads to defect testing |
| Validation testing: le is inputs causing anomalous behaviour | involves testing with correct inputs that are outside Ie. These stimulate the system to generate the expected correct outputs. |
| defect testing: le is inputs causing anomalous behaviour | to find those inputs in the set Ie because these reveal problems with the system. |
| Testing process goals: Validation testing | To demonstrate to the developer and the system customer that the software meets its requirements A successful test shows that the system operates as intended. |
| Testing process goals Defect testing | To discover faults or defects in the software where its behavior is incorrect or not in conformance with its specification A successful test is a test that makes the system perform incorrectly and so exposes a defect in the system. |
| Verification vs validation: | Verification: "Are we building the product right”. Validation: "Are we building the right product”. |
| Inspections and testing: Software inspections | Concerned with the analysis of the static system representation to discover problems (static verification) |
| Inspections and testing: Software testing | Concerned with exercising and observing product behavior (dynamic verification) |
| Stages of testing: Development testing | where the system is tested during development to discover bugs and defects. |
| Stages of testing: Release testing | where a separate testing team tests a complete version of the system before it is released to users. |
| Stages of testing: User testing | where users or potential users of a system test the system in their own environment. |
| Development testing: | Development testing includes all testing activities that are carried out by the team developing the system. The tester of the software is usually the programmer who developed that software. |
| Development testing: Unit testing | where individual program units or object classes are tested. Unit testing should focus on testing the functionality of objects or methods. |
| Development testing: Component testing | where several individual units are integrated to create composite components. Component testing should focus on testing component interfaces that provide access to the component functions. |
| Development testing: System testing | where some or all of the components in a system are integrated and the system is tested as a whole. System testing should focus on testing component interactions. |
| Object class testing | When you are testing object classes, you should design your tests to provide coverage of all of the features of the object. |
| Testing strategies: Partition testing | where you identify groups of inputs that have common characteristics and should be processed in the same way. |
| Testing strategies: Guideline-based testing | where you use testing guidelines to choose test cases. |
| Automated testing | Whenever possible, unit testing should be automated so that tests are run and checked without manual intervention. |
| Test-driven development | an approach to program development in which you inter-leave testing and code development. development helps programmers clarify their ideas of what a code segment is actually supposed to do. |
| extreme programming(XP): agile- method | Testing is automated and is central to the development process, and development cannot proceed until all tests have been successfully executed aims to produce higher quality software, and higher quality of life for the development team |
| Benefits of test-driven development: Code coverage | Every code segment that you write has at least one associated test. Therefore, all code written has actually been executed. |
| Benefits of test-driven development: Regression testing | A regression test suite is developed incrementally as a program is developed. You can always run regression tests to check that changes to the program have not introduced new bugs. |
| Benefits of test-driven development: Simplified debugging | When a test fails, it should be obvious where the problem lies. The newly written code needs to be checked and modified. You do not need to use debugging tools to locate the problem. |
| Benefits of test-driven development: System documentation | The tests themselves are a form of documentation that describes what the code should be doing. |
| Requirements based testing: | involves examining each requirement and developing a test or tests for it. requirements should be testable |
| performance testing: | usually involve planning a series of tests where the load is steadily increased until the system performance becomes unacceptable Effective way to discover defects is to design tests around the limits of the system |
| User testing: | a stage in the testing process in which users or customers provide input and advice on system testing. |
| User testing: Alpha testing | where a selected group of software users work closely with the development team to test early releases of the software. |
| User testing: Beta testing | where a release of the software is made available to a larger group of users to allow them to experiment and to raise problems that they discover with the system developers. |
| User testing: Acceptance testing | Customers test a system, using their own data, and decide if it should be accepted and ready to be deployed in the customer environment. |
| Reasons for Software change | New requirements emerge when the software is used; The business environment changes; Errors must be repaired; |
| Reasons for Software change | New computers and equipment is added to the system; The performance or reliability of the system may have to be improved. |
| Evolution and servicing: Evolution | The stage in a software system’s life cycle where it is in operational use and is evolving as new requirements are proposed and implemented in the system. |
| Evolution and servicing: Servicing | At this stage, the software remains useful but the only changes made are those required to keep it operational i.e. bug fixes and changes to reflect changes in the software’s environment. No new functionality is added. |
| Evolution and servicing: Phase-out | The software may still be used but no further changes are made to it. |
| Urgent change requests | Urgent changes may have to be implemented without going through all stages of the software engineering process |
| Evolution processes: Software evolution processes depend on | The type of software being maintained; The development processes used; The skills and experience of the people involved. |
| Refactoring: | a continuous process of improvement throughout the development and evolution process. It is intended to avoid the structure and code degradation that increases the costs and difficulties of maintaining a system. |
| Re-engineering: | takes place after a system has been maintained for some time and maintenance costs are increasing. You use automated tools to process and re-engineer a legacy system to create a new system that is more maintainable. |
| Challenges facing evolution | Historical data suggests that somewhere between 60% and 90% of software costs are evolution costs Software evolution is particularly expensive in enterprise systems Changing one system may mean that other systems may also have to evolve |
| Legacy System: | are older systems that rely on languages and technology that are no longer used for new systems development. may be dependent on older hardware |
| Legacy system components: System hardware | Legacy systems may have been written for hardware that is no longer available, or expensive to maintain. |
| Legacy system components: Support software | The legacy system may rely on a range of support software(from the operating system and utilities provided by the hardware manufacturer), which may be obsolete or unsupported. |
| Legacy system components: Application software | The application system that provides the business services is usually made up of a number of application programs. |
| Legacy system components: Application data | These are data that are processed by the application system. They may be inconsistent, duplicated, or held in different databases. |
| Legacy system components: Business processes | These are processes that are used in the business to achieve some business objective. Business processes may be designed around a legacy system and constrained by the functionality that it provides. |
| Legacy system components: Business policies and rules | These are definitions of how the business should be carried out and constraints on the business. |
| legacy system replacement: | Legacy system replacement is risky and expensive so businesses continue to use these systems |
| System replacement is risky for a number of reasons: | Lack of complete system specification Tight integration of system and business processes Undocumented business rules embedded in the legacy system New software development may be late and/or over budget |
| Legacy system reason for changes | No consistent programming style. Because many have changed the system over time. Use of obsolete programming languages with few people available with these language skills. Expensive outsourcing of system maintenance may therefore be required. |
| Legacy system reason for changes | Inadequate system documentation System structure degradation. Many years of maintenance degrade the structure and make it hard to understand. Program optimizations may make it hard to understand. |
| Legacy system categories: Low quality, low business value | These systems should be scrapped |
| Legacy system categories Low-quality, high-business value | These make an important business contribution but are expensive to maintain. Should be re-engineered or replaced if a suitable system is available. |
| Legacy system categories High-quality, low-business value | These systems don’t contribute much to the business but may not be very expensive to maintain. It is not worth replacing these systems, so normal system maintenance may be continued. |
| Legacy system categories High-quality, high-business value | These systems have to be kept in operation. Their high-quality means that you don’t have to invest in system replacement. Normal system maintenance should be continued. |
| Issues in business value assessment: 4 Basic Issues: The use of the system | If systems are only used occasionally or by a small number of people. This may mean that it has a low business value. |
| Issues in business value assessment: 4 Basic Issues: The business processes that are supported | A system may have a low business value if it forces the use of inefficient business processes. |
| Issues in business value assessment: 4 Basic Issues: System dependability | If a system is not dependable and the problems directly affect business customers, the system has a low business value. |
| Issues in business value assessment: 4 Basic Issues: The system outputs | If the business depends on system outputs, then the system has a high business value. |
| Software maintenance: | Modifying a program after it has been put into use. The term is mostly used for changing custom software. Generic software products are said to evolve to create new versions. |
| Software maintenance: Fault repairs | Coding errors are usually relatively cheap to correct; design errors are more expensive. Changing a system to fix bugs/vulnerabilities and correct deficiencies. |
| Software maintenance: Environmental adaptation | Maintenance to adapt the software to a different operating environment Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial implementation. |
| Software maintenance: Functionality addition and modification | Modifying the system to satisfy new requirements |
| Maintenance costs: | Usually greater than development costs (2* to 100* depending on the application). Affected by both technical and non-technical factors. Ageing software can have high support costs |
| Maintenance prediction : | is concerned with trying to identify which parts of the system may cause problems and have high maintenance costs CAN REDUCE COST |
| Refactoring: | the process of making improvements to a program to slow down degradation through change. it is a continuous process of improvement throughout development and evolution CAN REDUCE COST |
| Re-engineering : | takes place after a system has been maintained for some time and maintenance costs are increasing. |
| ‘Bad smells’ in program code | a result of poor or misguided programming, this is where the code of a program can be improved |
| ‘Bad smells’ in program code : Duplicate code | The same or very similar code may be included at different places in a program. This can be removed and implemented as a single method or function that is called as required. |
| ‘Bad smells’ in program code : Long methods | If a method is too long, it should be redesigned as a number of shorter methods. |
| ‘Bad smells’ in program code : Switch (case) statements | These often involve duplication, where the switch depends on the type of a value. The switch statements may be scattered around a program. In object-oriented languages, you can often use polymorphism to achieve the same thing. |
| ‘Bad smells’ in program code : Data clumping | Data clumps occur when the same group of data items (fields in classes, parameters in methods) re-occur in several places in a program. These can often be replaced with an object that encapsulates all of the data. |
| ‘Bad smells’ in program code: Speculative generality | This occurs when developers include generality in a program in case it is required in the future. This can often simply be removed. |
Created by:
DylanCanalesMane