Test 1 - Answers

1. The principle of information hiding implies that modules only share information with each other on a "need to know" basis to achieve some specific software function. Hiding enforces the procedural constraints to both the module procedural detail and any data structures local to the module. Ch. 13
2. Here are three characteristics:
1. Design implements all explicit requirements from the analysis model, as well as accommodating implicit customer requirements.
2. Design must be understandable to the people who generate the code to implement design, those who test it, and those who support it.
3. Design must provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective. Ch. 13
3. Level 1 – initial or ad hoc level, few software engineering practices are in evidence; development is haphazard and prone to problems.

Level 2 - repeatable level, some software engineering practices are applied and a repeatable process is in evidence.

Level 3 - defined level, in addition to good software engineering practices, training, measurement and other complementary activities are applied.

Level 4 - Managed level, there is a serious emphasis on measurements and also, a serious attempt to manage everything from requirements to change.

Level 5 - optimizing level, best practices exist at almost all levels and there is a continuing attempt to improve. Ch. 2

4. people, product, process, project Ch. 3
5. A measure is an individual datum. A metric relates individual measures in some way. Ch. 4
6. Process metrics are used to make strategic decisions about how to complete and improve common process framework activities and related software engineering tasks while project metrics are used to monitor progress during a software development project and to control product quality. Ch. 4
7. Project risks threaten the project plan, if they become real the schedule may slip or the cost will increase, Technical risks threaten the product quality or timeliness, if they become real, implementation becomes more difficult to impossible. Ch. 6
8. Compartmentalization, interdependency, time allocation, effort validation, defined responsibilities, defined outcomes, defined milestones. Ch. 7
9. state diagrams, usecase diagrams, structure diagrams, activity diagrams, class diagrams. Ch. 21
10. risk identification (determine the risks that are appropriate), risk projection (determine the likelihood that each risk will occur and the damage likely), risk mitigation (figuring out strategies to avoid the risks), risk management and contingency planning (assuming each risk becomes a reality determine ways to limit their impact). Ch. 6
11. 2 – 3 % for planning, 10 – 25 % for analysis, 20 – 25 % for design, 15 – 20 % for coding, 30 – 40 % for testing. Ch. 7
12. Encapsulation supports information hiding, which helps programmers think at an appropriate level of abstraction and also makes it easier to find errors. Ch. 20
13. Some methods are Booch, Rumbaugh, Jacobson, Coad and Yourdon, Wirfs-Brock. Ch. 21.
14. The waterfall approach is a linear sequential model in which requirements analysis is completed first, followed by design of a solution, then coding, testing and support. Ch. 2
15. The waterfall method defines the required steps in completing every software project. However, it is rare that each step can be completed before another is begun.
16. Prototyping is a good approach to use when a customer has only a general idea of what is needed. The software engineering team can put together a quick prototype to get a reaction from the customer and then make necessary adjustments or even replacement if necessary without losing a lot of time. Ch. 2
17. 1. Delay estimation until later in the project to be sure of accuracy.
    2. Base estimates on similar projects that have already been completed.
    3. Use relatively simple decomposityion techniques to generate project cost and effort estimates.
    4. Use one or more empirical models for software estimation. Ch. 5
18. COnstructive COst MOdel. It is a comprehensive estimation model for software. Ch.5
19. A democratic decentralized team has no permanent leader. Each member helps with all tasks, including coordinating job assignments. A controlled decentralized team has a defined leader who serves as coordinator of the project. Ch. 3
20. Data-centered, data-flow, call and return, object oriented, layered. Ch. 14