Software Process Models Waterfall Model There is no

Software Process Models Waterfall Model There is no iteration in waterfall model Most software developments apply a great many iterations 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 1

Some New Development Models Replacements for waterfall, have in common the principle: get back to the customer quickly Incremental Prototype Rapid application development Agile methods 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 2

Development Models: Incremental ch 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 3

Software Process Models Prototyping Model Allows repeated investigation of the requirements or design Reduces risk and uncertainty in the development 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 4

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 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 5

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 selforganizing teams; daily “scrum” coordination Adaptive software development (ASD) 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 6

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 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 7

Software Process Models Agile Methods: Twelve Facets of XP The planning game (customer defines value) Small release Metaphor (common vision, common names) Simple design Writing tests first Refactoring Pair programming Collective ownership Continuous integration (small increments) Sustainable pace (40 hours/week) On-site customer Coding standard 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 8

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 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 9

Other SE Methodologies Use-Cases Unified Modeling Language (UML) Process Maturity Models Formal Methods 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 10

Use-Cases A collection of scenarios that describe 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 ch 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 11

Unified Modeling Language (UML) An industry standard to develop requirements modeled by entities and relationships between the entities (ER diagrams) ch 21 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 12

Evaluating Process Maturity Models Capability Maturity Model (CMM) Software Process Improvement and Capability d. Etermination (SPICE) ISO 9000 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 13

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 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 14

12. 5 Evaluating Process CMM Levels of Maturity 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 15

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 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 16

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 highintegrity systems where safety or security is important. 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 17

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. 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 18