1 / 36

CHAPTER 2

CHAPTER 2. THE SOFTWARE PROCESS. Overview. Client, Developer, and User Requirements Phase Specification Phase Design Phase Implementation Phase Integration Phase Maintenance Phase Retirement Problems with Software Production: Essence and Accidents. The Software Process.

delano
Download Presentation

CHAPTER 2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CHAPTER 2 THE SOFTWARE PROCESS

  2. Overview • Client, Developer, and User • Requirements Phase • Specification Phase • Design Phase • Implementation Phase • Integration Phase • Maintenance Phase • Retirement • Problems with Software Production: Essence and Accidents

  3. The Software Process • The software process is the way we produce software. It incorporates the • life-cycle model • CASE tools • The individuals building the software

  4. Terminology • Systems analysis • Requirements + specifications phases • Operations mode • Maintenance • Design • Architectural design, detailed design • Client, developer, user • Internal software development • Contract software development (outsourcing)

  5. Testing Phase? • There is NO testing phase separately • Testing is an activity performed throughout software production • Verification • Performed at the end of each phase • Validation • Performed before delivering the product to the client

  6. Documentation Phase? • There is NO documentation phase separately • Every phase must be fully documented before starting the next phase • Postponed documentation may never be completed • The responsible individual may leave • The product is constantly changing—we need the documentation to do this • The design (for example) will be modified during development, but the original designers may not be available to document it

  7. Requirements Phase • Assumption • The software being considered is economically justifiable • Concept exploration • Determine what the client needs, not what the client wants • Determine what constraints exist • Deadline • Reliability • Object code size (e.g., for small embedded systems) • Cost • Functionality of the product is successively refined and analyzed for technical feasibility and financial justification

  8. Requirements Phase Testing • Frequently, the clients do not know exactly what they need • Rapid prototyping is often used to solve this problem • Rapid prototype - a software that is quickly put together that incorporates much of the functionality of the target product • Does not show the aspects generally invisible to the client • More on this in Chapter 10

  9. Software Quality Assurance (SQA) • The role of SQA group • Ensures that the delivered project is what the client ordered and that the product has been developed correctly • SQA group is involved from the beginning of software development • Moving Target Problem • The client changes the requirements during development • Keeps changing his/her mind!

  10. Requirements Phase Documentation • Rapid prototype with the records of discussion, OR • Requirements document • Must be thoroughly checked by the client, users and the development team • Finally, SQA checks it

  11. Specification Phase • Specifications document (“specifications”) • Explicitly describes the functionality of the product • Specifies the inputs and the outputs • Legal contract document • Must not have phrases like “suitable”, “enough”, “optimal,” or “98% complete”

  12. Specification Phase (contd) • Specifications must not be • Ambiguous • Incomplete • Contradictory • Once the specifications have been signed off • The Software Product Management Plan (SPMP) is drawn up • This is the earliest possible time for the SPMP • Shows the tasks, which members of the development team are involved in each task, and deadlines for completing each task

  13. Specification Phase (contd) • SPMP • Includes the deliverables (what the client is going to get) and the milestones (when the client gets them) • Describes the software process, life-cycle model, structure of development team, project responsibilities, managerial objectives and priorities, techniques and CASE tools used, detailed schedules, budgets, resource allocations • The most important in SPMP are time and cost estimates

  14. Specification Phase Testing • Traceability of specification document • Must be able to trace every statement in the spec. document to a statement made by the client during the requirements phase • Review • To determine if the specs are correct • Spec team and client participate with SQA member being the chair • Check the SPMP by SQA group

  15. Specification Phase Documentation • Specification document (specifications) • SPMP

  16. Design Phase • Specification—what • Design—how • Retain design decisions • When a dead-end is reached • For the maintenance team • Ideally, the design should be open-ended • Architectural design • Decompose the product into modules • Detailed design • Design each module: data structures, algorithms

  17. Design Phase Testing • Traceability • Every part of the design can be linked to a statement in the specification document • Review • By the design team and the SQA group (no client)

  18. Design Phase Documentation • Design • Architectural design • Detailed design

  19. Implementation Phase • Implement the detailed design in code

  20. Implementation Phase Testing • Code Review • The programmer explains the code to the review team, which includes a SQA member • Test cases • Informal testing (desk checking) • Formal testing (SQA)

  21. Implementation Phase Documentation • Source code • Must have suitable comments • Test cases (with expected output)

  22. Integration Phase • Combine the modules and check the product as a whole • Modules can be integrated • All at once or one at a time • Top to bottom in the module interconnection diagram or bottom to top

  23. Integration Phase Testing • Product testing • By the integration team and SQA • Acceptance testing • By the client • The software is delivered to the client, who tests it on the actual hardware using actual data

  24. Integration Phase Documentation • Commented source code • Test cases for the product as a whole

  25. COTS Software • Commercial off-the-shelf (COTS) • “Shrink-wrapped software” • Nowadays, COTS software is often downloaded over the Internet • “Click-wrapped software” • Alpha testing – alpha version to selected possible clients • Beta testing – beta version (corrected alpha version) testing -> final version

  26. Maintenance Phase • Maintenance • Any change once the client has accepted the software • The most money is devoted to this phase • The problem of lack of documentation

  27. Maintenance Phase Testing • Must make sure that the new changes have been implemented correctly • Regression testing • Testing the modified product against previous test cases

  28. Maintenance Phase Documentation • Record of all changes made, with reasons • Regression test cases

  29. Retirement • Good software is maintained • Sometimes software is rewritten from scratch • Software is now unmaintainable because • A drastic change in design has occurred • The product must be implemented on a totally new hardware/operating system • Documentation is missing or inaccurate • Hardware is to be changed—it may be cheaper to rewrite the software from scratch than to modify it • True retirement is a rare event

  30. Process-Specific Difficulties • Does the product meet the user’s real needs? • Is the specification document free of ambiguities, contradictions, and omissions?

  31. Inherent Problems of Software Production • Hardware has inherent limits • So does software • No Silver Bullet [Fred Brooks, 1986] • Complexity • Conformity • Changeability • Invisibility • Aristotelian categories • Essence: difficulties inherent in the nature of s/w • Accidents: difficulties encountered in development

  32. Complexity • Software is far more complex than hardware • Traditional abstraction will not work • We cannot understand the whole, so we cannot understand any part • Management is difficult • Maintenance is a nightmare (documentation, too)

  33. Conformity • Type 1: Existing gold refinery • Type 2: New gold refinery

  34. Changeability • Software is easier to change than hardware • Pressure to change • Reality • Useful software • Easier to change • Software has a long lifetime (~15 yrs) compared to hardware (~4 yrs)

  35. Invisibility • Software is invisible and unvisualizable • Complete views are incomprehensible • Partial views are misleading • However, all views can be helpful

  36. Is There a Silver Bullet? • What about • High-level languages • Time sharing • CASE tools • These are useful but do not solve the intrinsic problems • We have experienced • 6% annual productivity increase • But, no “silver bullet” (order-of-magnitude increase) is possible • Read Chapter 2 (except sections on CMM)

More Related