1. Software Processes n What is a process?  Sequence of steps required to develop or maintain software n Characteristics  prescribes major activities  utilizes resources, subject to constraints such as schedule, to produce intermediate and final results  constraints and controls apply to activities, resources, and products  constraints on activities: time, budge, tools  controls on activities: config. Mgmt, reports

2. Process should be n Visible: Activities should provide clear indications of progress (deadlines/milestones) n Understandable: Activities and their order of execution are well-defined n Supportable: Automated support for activities is available n Usable: Process is acceptable to and usable by developers

3. Defining Processes n A defined process:  facilitates communication about the process  provides a basis for process automation  facilitates process reuse and evolution  aids process management n Elements of process descriptions  general description  each activity has an entry and exit criteria  activities are organized in “sequence”  guiding principles explain goals of activities  process may contain subprocesses  resources, constraints

4. Evolution of Software Process Models n “Code and Fix” model  code, test, debug n Problems  requirements analysis and design ignored  code does not evolve gracefully  debugging is difficult Why? Unstructured, spaghetti coding, changes not localized, not modular, difficult to trace, relationships hard to determine

5. SWEng Paradigms for Prescriptive Process Models Chosen based on nature of project, methods, tools used, controls and deliverables required n Linear Sequential Models (Classic or Waterfall, V-shaped) n Prototyping n RAD Model n Evolutionary Process Models (Incremental, Spiral, Concurrent) n Formal Methods n 4GL n Combinations

6. Process Models n Linear Sequential  Analysis, design, coding, testing, maintenance  Difficulties: Projects rarely follow sequential flow Requirements defined up-front a must (rarely done) Patient customer/no immediate feedback

7. Waterfall Methods and Variants n Phases (similar to develop hardware)  Analysis, Design, Code, Test, Maintain n Difficulties  projects rarely follow sequential flow  requirements defined up-front a must (rarely done)  patient customers/no immediate feedback  no insight given into how each activity transforms an intermediate product into another n Variants  V-shaped model: relationship between types of tests and phases before testing  Prototyping variant: requirements and design prototypes

8. Waterfall Model

9. Deliverables n http://www.solovatsoft.com/Development%20 Standard%20Deliverables.pdf http://www.solovatsoft.com/Development%20 Standard%20Deliverables.pdf

10. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 10 The V-Model

11. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 11 Evolutionary Models: Prototyping Construction of prototype communication Quick plan Modeling Quick design Construction of prototype Deployment delivery & feedback

12. Evolutionary Models: Prototyping n Prototyping  quick design, build prototype, evaluate, refine prototype, … engineer product n Prototyping  Paper/working subset of features/existing program with some features  Requirements, quick design, build prototype, customer evaluation, refine prototype, engineered product  Problems: Customer sees prototype, then wants a few fixes quick and delivery Implementation compromises made to get prototype done quickly/forgets compromises and become part of the system

13. Process Models n RAD Model  Short development cycle, “high-speed” linear sequential using component-based construction  Well understood requirements, constrained scope, IS apps  Uses reusable components and 4GLs  Problems: Need sufficient human resources for RAD teams Need committed developers and customers Modular system key Not appropriate when technical risks are high (new technology, performance an issue

14. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 14 The Incremental Model

15. Incremental/Iterative Development Incremental: functionality developed in pieces Iterative: put in all features, but they are limited

16. Benefits and Problems of Evolutionary Development  Incremental: Each build focuses on a subset of functionality, simplifying development  Opportunity to learn about problem as design develops  customer get a product early and can provide feedback for future builds  customer can test software  different releases can focus on enhancements that require specialized expertise  improperly planned builds result in complex system  backward compatibility limits elegance of future releases (and can force hacking)  error in basic system architecture may require changes to basic structure that invalidate earlier releases

17. Other Process Models n Transformation (4GLs)  Requirements, “design”, implementation using 4GL (specifications into code generator)  Advantage Reduces time to produce SW  Problems Design/Analysis reduced Some CASE tools produce skeletonized code  Limited to certain domains Business IS Compilers (lex, YACC, SDL)

18. Choosing a Process Models n Choice depends on nature of project  requirements clearly defined and stable?  Pressure to produce a working product quickly?  Consequences of operational errors serious? n Classified along a spectrum ranging from  radical: all activities carried out in parallel suitable when quick results needed and requirements fuzzy  conservative: all activities carried out in a strict sequence with no overlap suitable when consequences of errors serious and requirements are clear and stable n None of the extremes are viable

19. Process Maturity n Processes should be tailored to development environment n The software process maturity framework allows organizations to determine the capabilities of their current processes and establish priorities for improvement

20. CMM Levels n 1- Initial: few defined processes; adhoc; chaotic; success depends on individual effort n 2- Repeatable: cost, schedule, and product tracking processes in place; disciplined process n 3- Defined: Standard process are defined (written down) and used (and enforced) n 4- Managed: Defined process and product qualities are meaningfully measured; predictable n 5- Optimizing: measures used to evaluate/improve process/product