1 / 18

CS 450 Chapter 2 The Software Process

CS 450 Chapter 2 The Software Process. 2.1-2.8: Real World Software Engineering--Details of Phases 2.9: There is no Silver Bullet 2.10-2.14 Improving the Process. The Software Process. The way a company produces software. Varies from one company to another.

serena-guthrie
Download Presentation

CS 450 Chapter 2 The Software Process

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. CS 450 Chapter 2The Software Process 2.1-2.8: Real World Software Engineering--Details of Phases 2.9: There is no Silver Bullet 2.10-2.14 Improving the Process

  2. The Software Process • The way a company produces software. • Varies from one company to another. • Aim is process improvement -- a better process will result in a better product .

  3. Three Views of Software • Client: customer who orders software. • User: person(s) who will actually use software. • Developers: producers of software, who attempt to meet client specifications and user needs.

  4. Planning • Original project plan -- general time frame for completion of each of the phases and product delivery. • Planning continues throughout development -- in each phase, detailed scheduling of next phase is done. • personnel assignments • completion date for each module • integration schedule

  5. Requirements Phase • Preliminary investigation • generally what is wanted • what are the constraints (budget, delivery) • Successive refinements of requirements • Rapid prototyping • Requirements testing • Software Quality Assurance (SQA) group • Verify product will meet client/user needs • Manage change

  6. Specification Phase Explicitly describes • functionality -- what the product will do • constraints (e.g. must run on certain hardware, timing constraints ...) • Project charter or specification document serves as contract between developer and client • Paragraph numbers for cross reference

  7. Specification Testing • Check for and correct • ambiguities (means different things to different people) • contradictions (different parts of document state different requirements) • incompleteness (not all functionality is described) • Formal review with client

  8. Design Phase • Architectural Design • broken up into modules • data structure design • operations on data determined • interfaces between modules • Detailed Design • design of each module • Aim for modifiability

  9. Design Testing • SQA: Cross reference with requirements to assure each one is met. • Check for • logic faults • interface faults • missing exception handling • Walk-throughs and reviews with development team

  10. Implementation and Integration • Modules written in self-documenting code and unit tested. • Modules gradually integrated and integration tested. • Product tested before release. • Acceptance test by client. • Possible alpha and beta testing (alpha -- at developer site; beta -- at selected customer site(s)).

  11. Maintenance • A high quality product is easily maintainable. • Maintainability was a factor in design. • Documentation is complete and up to date. • Maintenance testing • Each change is tested • Product is regression tested (previous tests run again in case new errors introduced)

  12. Retirement Legacy code is common and seldom retired. Eventually it may be for reasons such as: • Further maintenance is no longer cost-effective. • Software is gradually being upgraded to new paradigm. • Product has outgrown its usefulness.

  13. No Silver Bullet Article by Frederick Brooks: • “... building software will always be hard” due to difficulties in its intrinsic nature (essence); • however, improved process can solve difficulties which surround software production and are not part of its nature (accidents)

  14. Difficulties in Essence of Software • complexity: due to interaction of components, number of possible states grows much faster than lines of code. • conformity: must interface with existing systems. • changeability: must model changing real world, increase functionality, run on new hardware. • invisibility: cannot visualize all aspects at once.

  15. Breakthroughs that have and will solve accidental difficulties • historical: high level languages and time sharing • software development environments • use of “off the shelf” software and components • rapid prototyping • incremental development • training, encouraging great designers

  16. Improving the Process:Capability Maturity Model (CMM) • Internationally recognized rating of quality of an organization’s software production process • CMM Levels • 1: Initial -- no standard process • 2: Repeatable -- Measurements from past similar projects used. • 3: Defined -- Process fully documented • 4: Managed -- Goals set for each project • 5: Optimizing -- Continuous improvement

  17. ISO 9000 and SPICE • International Standards Organization industrial quality standards • Software guidelines are similar, but not identical, to CMM • International trade may require certification as ISO 9000 compliant

  18. Homework • Read Chapter 2 • Be prepared to discuss reading and these problems pp. 59, 60: • 2.1, 2.6 • 2.10, 2.11 • 2.13

More Related