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

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

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

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

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

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

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

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

9. Process Models Evolutionary Process Model
Spiral, Incremental, Iterative

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

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

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

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

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

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