1. Chapter 4 Review Chad Hagstrom CS 310 Spring 2008

2. Concepts Overview Primary Concepts: * The Main Software Process Phases: Specification, Design, Implementation, Validation, and Evolution * Models for Software Development * Description of CASE Tools

3. Processes: Specification Determines what system to build via these stages: * Feasibility Study – Is the software affordable, possible, and beneficial? * Reqs. Elicitation & Analysis – Determine what the customer wants the system to do. Involves research, modeling, user interviews, etc. * Reqs. Specification – Convert Elicitation & Analysis results into formal, concrete requirements. * Reqs. Validation – Look for errors, omissions, etc.

4. Processes: Design & Impl. Determines how to build the system via these stages: * Architectural Design – Create the types and interactions of sub- systems. * Abstract Specification – Define what the sub-systems will provide, as well as their restrictions. * Interface Design – Specifies how sub-systems communicate with one another. * Component Design – Divide sub-systems into smaller pieces to carry out the sub-system's tasks. * Data Structure Design – Create data storage and retrieval methods. * Algorithm Design – Create algorithms that carry out the system's tasks.

5. Processes: Validation Tests the system for errors via these stages: * Component testing – Ensures that the pieces function properly on their own. * System testing – Ensures that the pieces function properly when put together. * Acceptance testing – Ensures that the overall system does what the specifications say (verification) and that it meets the customer's expectations (validation).

6. Processes: Evolution * Systems are often upgraded based on future requirements alterations by customers. * This process is normally far less expensive compared to equivalent hardware evolution.

7. Process Models There are 3 main models in Chapter 4 for carrying out the SW process tasks: * Waterfall – Near-total separation of process phases. * Evolutionary – Simultaneous progression on process phases. * Component-Based – Building the software via pre-made pieces.

8. Models: Waterfall * Requirements, design, etc. are kept (almost) completely separate. * Future process stages are not allowed to begin until prior stages are fully completed and documented. * Changes made to already-completed stages require a total re-work of those stages, starting w/ the earliest. * It is simpler to view project progress, but making frequent system changes is highly inefficient. * Typically works best for giant SW systems.

9. Models: Evolutionary * Requirements, design, etc. are allowed to progress simultaneously. * Changes made to various process stages are handled more efficiently than with the Waterfall model. * However, documentation is typically not produced frequently, so progress measurement is difficult. * Keeping the software flexible may involve sub-par structuring techniques. * Typically works best for medium, dynamic systems.

10. Models: Component-Based * Constructs the system via pre-built software pieces. * Involves acquiring, altering, and adding pre-made code into the desired system. * Allows for decreased development time and money, but restricts requirements & design flexibility.

11. CASE Tools * CASE – Computer Aided Software Engineering * Refers to software that is devoted to helping developers with tasks in the software creation process. * Includes: Code compilers, model creation software, program debuggers, etc.

12. Conclusion My New Ch. 4 Perspectives: * Realization of how high-level Ch. 4's descriptions of the software processes are, compared to later chapters. * Observation of how the component-based model sounds more appealing to me now than before. Utilization of Ch. 4's Content: * My project has thus far been developed with an evolutionary approach.

13. References * Ian Sommerville's Software Engineering (8 th ed)‏ * Professor Carol Shilepsky's PowerPoint slides at aurora.wells.edu