1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Software Process Models Waterfall Model  There is no iteration in waterfall model  Most software developments apply a great many iterations

2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Some New Development Models Replacements for waterfall, have in common the principle: get back to the customer quickly  Incremental  Spiral  Prototype  Rapid application development  Agile methods

3 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Development Models: Incremental ch2

4 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Spiral Model ch20

5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Software Process Models Prototyping Model  Allows repeated investigation of the requirements or design  Reduces risk and uncertainty in the development

6 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Software Process Models Agile Methods  Emphasis on flexibility in producing software quickly and capably  Agile manifesto  Value individuals and interactions over process and tools  Prefer to invest time in producing working software rather than in producing comprehensive documentation  Focus on customer collaboration rather than contract negotiation  Concentrate on responding to change rather than on creating a plan and then following it

7 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Software Process Models Agile Methods: Examples of Agile Process  Extreme programming (XP)  Crystal: a collection of approaches based on the notion that every project needs a unique set of policies and conventions  Scrum: 30-day iterations; multiple self-organizing teams; daily “scrum” coordination  Adaptive software development (ASD)

8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Software Process Models Agile Methods: Extreme Programming  Emphasis on four characteristics of agility  Communication: continual interchange between customers and developers  Simplicity: select the simplest design or implementation  Courage: commitment to delivering functionality early and often  Feedback: loops built into the various activities during the development process

9 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Software Process Models Agile Methods: Twelve Facets of XP  The planning game (customer defines value)  Small release  Metaphor (common vision, common names) (common vision, common names)  Simple design  Writing tests first  Refactoring  Pair programming  Collective ownership  Continuous integration (small increments) (small increments)  Sustainable pace (40 hours/week) (40 hours/week)  On-site customer  Coding standard

10 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Software Process Models When Extreme is Too Extreme?  Extreme programming's practices are interdependent  A vulnerability if one of them is modified  Requirements expressed as a set of test cases must be passed by the software  System passes the tests but is not what the customer is paying for  Refactoring issue  Difficult to rework a system without degrading its architecture

11 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Other SE Methodologies  Use-Cases  Unified Modeling Language (UML)  Process Maturity Models  Formal Methods

12 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Use-Cases  A collection of scenarios that describe the thread of usage of a system  Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way  Each scenario answers the following questions:  What are the main tasks of functions performed by the actor?  What system information will the actor acquire, produce or change?  Will the actor inform the system about environmental changes?  What information does the actor require of the system?  Does the actor wish to be informed about unexpected changes ch11

13 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Unified Modeling Language (UML) An industry standard to develop requirements modeled by entities and relationships between the entities (ER diagrams) ch21

14 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Evaluating Process Process Maturity Models  Capability Maturity Model (CMM)  Software Process Improvement and Capability dEtermination (SPICE)  ISO 9000

15 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Evaluating Process Capability Maturity Model  Developed by Software Engineering Institute  There are five levels of maturity  Each level is associated with a set of key process area

16 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, Evaluating Process CMM Levels of Maturity

17 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Evaluating Process ISO 9000  Produced by The International Standards Organization (ISO)  Standard 9001 is most applicable to the way we develop and maintain software  Used to regulate internal quality and to ensure the quality suppliers

18 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Formal Methods From Wikipedia: Formal methods are a particular kind of mathematically- based techniques for specification, development. The use of formal methods is motivated by the expectation performing appropriate mathematical analysis can contribute to the reliability and robustness of a design. However, the high cost of using formal methods means that they are usually only used in the development of high-integrity systems where safety or security is important. mathematicallyspecificationsafetysecuritymathematicallyspecificationsafetysecurity

19 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Criticism of Formal Methods Handwritten proofs of correctness need significant time (and money) to produce, with limited utility other than assuring correctness. This makes formal methods more likely to be used in fields where it is possible to perform automated proofs using software, or in cases where the cost of a fault is high. Example: in railway engineering and aerospace engineering, undetected errors may cause death, so formal methods are more popular in this field than in other application areas. aerospace engineeringdeath aerospace engineeringdeath