1. Announcements/Assignments
Beginning on Friday, this class will meet in Architecture Hall, room 127 (this is on the East side of the building)
I asked you to read Ghezzi Chapter 1 for today
Be sure to attend class Friday to discuss the project and do team selection

2. This Class

3. Problems of Scale in Engineering
Built by one person
Requires minimal to no planning
Design and implementation blend
Simple tools & construction
Faults have small consequences
Teams with different roles
Scheduling and dependencies
Models & abstraction
Specialized languages and tools
Formal communication
Large impact of changes and faults
Domain knowledge

4. Problems of Scale in Engineering
Built by one person
Requires minimal to no planning
Design and implementation blend
Simple tools & construction
Faults have small consequences
Teams with different roles
Scheduling and dependencies
Models & abstraction
Specialized languages and tools
Formal communication
Large impact of changes and faults
Domain knowledge
These same problems of scale
apply when transitioning from coding to software engineering

5. Scaling Up Requires Systematic Engineering Processes of Many Types
Requirements elicitation and analysis
Requirements specification
Requirements verification
Architectural design
Lower-level design
Coding and unit testing
Integration testing
System testing
Evolution and maintenance

6. What This Class is About
Building complex software systems
Interacting with other stakeholders
Building the right system (getting system requirements right)
Creating extensible architectures and system designs
Making sure you’ve built the system right (verification and validation)
It is only minimally about “coding”

7. Goal Begin to prepare you for: Large-scale software development
including group dynamics, management
Working with other people
coordination of effort
requirements elicitation and specification
design techniques
software processes
quality assurance approaches
sophisticated tools

8. Software Lifecycle and Process Models

9. Software Lifecycle & Process Models
Abstract representations of software development processes
Provide guidance for project management
What major tasks should be tackled next?
How long should we spend on this task?
What kind of progress has been made?
Provide guidance for project staff
Am I doing the right thing?
Am I on schedule?

10. “Monolithic” Processes

11. Problems
The assumption is that an informal understanding of requirements prior to development is enough
This assumption almost never holds; requirements change as our understanding of the system grows, and informality leads to errors
Interaction with the customer occurs only at the beginning (requirements) and end (after delivery)
Limiting interaction makes it difficult to correctly understand requirements in a timely manner

12. “Staged” Processes

13. Advantages Reduce risks by improving visibility
Allow project changes as the project progresses
based on feedback from the customer
based on domain knowledge gained

14. Software Process Models
Waterfall model
Linear, distinct phases of specification and development
Reuse-based model
The system is assembled from existing components
Incremental model
The system is built in distinct increments
Agile / XP model
Takes the incremental model to extremes
Formal systems model
A mathematical system model is formally transformed to an implementation

15. Simple Waterfall Process Model
Requirements
Analysis
and Specification
Design and
Specification
Coding and
Unit Testing
Integration and
System Testing
Delivery and
Maintenance

16. Historical Notes
The waterfall model is based on development models used in manufacturing. In such cases, changes in product and requirements are prohibitively expensive, so the model works.
Also known as a “Big Design up Front” model
First known presentation, 1956, Herbert Benington at a Symposium on programming methods
First formalization, Winston Royce, as an example of a “flawed” model.

17. Waterfall Model Phases
Requirements analysis and specification
Often preceded by feasibility or “market” study
Identify “what” must be built, including functionality and constraints
Document requirements in user terms and in terms appropriate for designers/developers
Requires interaction with customers, and domain knowledge
Various models for expressing requirements are available

18. Waterfall Model Phases
Design and specification
Specifies the “how”, not the “what”
Often split into architectural and detailed design
Architectural design expresses overall system organization, decomposes system into modules
Detailed design provides further details
Considers reuse
Various models for expressing designs are available

19. Waterfall Model Phases
Coding and unit testing
System is coded to meet the design specification
Unit testing is applied to individual modules, usually by developers

20. Waterfall Model Phases
Integration and system testing
Integration testing tests modules as they are put together, using stubs and drivers
System testing tests the entire system, including hardware and software (perhaps with simulators)
These phases may be conducted by developers and/or dedicated test engineers

21. Waterfall Model Phases
Delivery and maintenance
System is packaged for delivery; this includes all code, documentation, and other deliverables
System goes into “maintenance”, where it continues to be perfected, adapted, and corrected
When systems are evolving (as opposed to just being “corrected”), maintenance means revisiting the requirements, design, implementation and testing phases again.

22. Waterfall Model Advantages
Simple, disciplined, structured
Time spent well early in the project increases the chance it will succeed and decreases some risks
Emphasizes documentation, important in long-term larger projects
Requirements
Analysis
and Specification
Design and
Specification
Coding and
Unit Testing
Integration and
System Testing
Delivery and
Maintenance

23. Waterfall Model Disadvantages
Each phase must be complete before the next can be begun
Difficult to accommodate change after the process is underway
Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements
The model is appropriate only when the requirements are well-understood
Requirements
Analysis
and Specification
Design and
Specification
Coding and
Unit Testing
Integration and
System Testing
Delivery and
Maintenance

24. Waterfall Model with “Feedback”
Requirements
Analysis
and Specification
Design and
Specification
Coding and
Unit Testing
Integration and
System Testing
Delivery and
Maintenance

25. Reuse-Oriented Development Model
Based on systematic reuse where systems are integrated from existing components
Process stages
Component analysis
Requirements modification
System design with reuse
Development and integration

26. Reuse-Oriented Development Model
Advantages
Can save time and effort
Builds on reliability of existing systems
Drawbacks
Can lead to unfortunate compromises
Building with future reuse in mind can slow effort, as we try to build things that are more general

27. Incremental Development Model (a.k.a. Feature Driven Development)
Development/delivery is broken into increments
Each increment delivers part of the required functionality
Identifying self-contained functional units (“features”) that may be delivered to customers is crucial

28. Incremental Development Model
User requirements are prioritized
Highest priority requirements are included in early increments
Once development of an increment is started, the requirements are frozen
Requirements for later increments can still evolve some

29. Incremental Development Model
Advantages
Customer value is delivered with each increment so system functionality is available earlier
Early increments act as prototypes
Higher priority system services tend to receive the most testing (not necessarily a bad thing for non-critical systems)
Disadvantages
Expectation that most requirements can be known early in the process

30. “Agile” Development Models
Development and delivery of very small increments of functionality
Teams of 5-10 spend 2-4 weeks per increment
Needs to begin with a relatively clear view of requirements, and a sound architecture/design
Relies (mostly) on well validated principles
Pair programming (reviews)
Revisiting and refactoring (iteration and refinements)
Test first (test before programming)

31. Agile Development Models
Advantages
Provides functionality quickly
Allows fast response to changing requirements
Allows early and frequent feedback
Early functionality gets more testing
Disadvantages
Focuses on working software at the expense of documentation
Development can get off track if customer is not clear about ultimate goals
Future system maintainability depends on how well requirements/architecture can be expressed initially

32. Formal Systems Development Model
Based on the transformation of a mathematical specification through different representations to an executable program
Transformations are “correctness-preserving”
straightforward to show that the program conforms to its specification

33. Formal Transformations
Small increments

34. Formal Systems Development
Advantages
Produces highly reliable systems
Disadvantages
Requires specialized skills and training
Difficult to formally specify some aspects of systems
Applicability
Critical systems (or subsystems), especially those where a safety or security case must be made before the system is put into operation

35. Software Process Models
Waterfall model
Linear, distinct phases of specification and development
Reuse-based model
The system is assembled from existing components
Incremental model
The system is built in distinct increments
Agile / XP model
Takes the incremental model to extremes
Formal systems model
A mathematical system model is formally transformed to an implementation