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

Defining Processes A defined process: Elements of process descriptions facilitates communication about the process provides a basis for process automation facilitates process reuse and evolution aids process management 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

Evolution of Software Process Models “Code and Fix” model code, test, debug 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

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

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

Waterfall Methods and Variants Phases (similar to develop hardware) Analysis, Design, Code, Test, Maintain 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 Variants V-shaped model: relationship between types of tests and phases before testing Prototyping variant: requirements and design prototypes

Process Models Prototyping quick design, build prototype, evaluate, refine prototype, … engineer product 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

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

Process Models Evolutionary Process Model Spiral, Incremental, Iterative

Evolutionary Models (Microsoft) Build 1 Build 2 Build 3 Developers Users Release 1 Release 2 Release 3

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

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

Process Models Transformation (4GLs) No coding phase formal models mechanically transformed to code Requirements, “design”, implementation using 4GL (specifications into code generator), testing domain engineering (lex, YACC, SDL) Problems: Limited to Business IS Some CASE tools produce skeletonized code Reduces time to produce SW Design/Analysis also reduced 4GTs for large SW development efforts as much A/D/testing

Other Process Models Operational (5GLs) Combining Paradigms executable specifications Combining Paradigms

Choosing a Process Models Choice depends on nature of project requirements clearly defined and stable? Pressure to produce a working product quickly? Consequences of operational errors serious? 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 None of the extremes are viable