1. Software Engineering Process
and
Models

2. A Layered Technology Software Engineering tools methods process model
a “quality” focus

3. A Process Framework Process framework Framework activities work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities

4. Framework Activities Communication Planning Modeling Construction
Analysis of requirements
Design
Construction
Code generation
Testing
Deployment

5. Umbrella Activities Software project management
Formal technical reviews
Software quality assurance
Software configuration management
Work product preparation and production
Reusability management
Measurement
Risk management

6. The Process Model: Adaptability
the framework activities will always be applied on every project ... BUT
the tasks (and degree of rigor) for each activity will vary based on:
the type of project
characteristics of the project
common sense judgment; concurrence of the project team

7. Assessment and Improvement

8. The Primary Goal of Any Software Process: High Quality
Remember:
High quality = project timeliness
Why?
Less rework!

9. What are the attributes of good software?
The software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable
Maintainability
Software must evolve to meet changing needs
Dependability
Software must be trustworthy
Efficiency
Software should not make wasteful use of system resources
Usability
Software must be usable by the users for which it was designed

10. What are the key challenges facing software engineering?
Software engineering in the 21st century faces three key challenges:
Legacy systems
Old, valuable systems must be maintained and updated
Heterogeneity
Systems are distributed and include a mix of hardware and software
Delivery
There is increasing pressure
for faster delivery of software

11. What is a software process?
SP is a set of activities whose goal is the development or evolution of software
Fundamental activities in all software processes are:
Specification - what the system should do
and its development constraints
Development - production of the software system
(design and implementation)
Validation - checking that the software is what the customer wants
Evolution - changing the software in response to changing demands

12. What is a software process model?
SPM is a simplified representation of a software process, presented from a specific perspective
Examples of process perspectives:
Workflow perspective represents inputs, outputs and dependencies
Data-flow perspective represents data transformation activities
Role/action perspective represents the roles/activities of the people involved in software process
Generic process models
Waterfall
Evolutionary development
Formal transformation
Integration from reusable components

13. What is a Process … ?
When we provide a service or create a product we always follow a sequence of steps to accomplish a set of tasks
You do not usually
put up the drywall before the wiring for a house is installed or
bake a cake before all the ingredients are mixed together
We can think of a series of activities as a process
Any process has the following characteristics
It prescribes all of the major activities
It uses resources and produces intermediate and final products
It may include sub-processes and has entry and exit criteria
The activities are organized in a sequence
Constrains or control may apply to activities
(budget control, availability of resources )

14. Software Processes Coherent sets of activities for Specifying,
When the process involves the building of some product we refer to the process as a life cycle
Software development process – software life cycle
Coherent sets of activities for
Specifying,
Designing,
Implementing and
Testing software systems

15. Major problems in software developments …
The developers understood it in that way
The requirements specification was defined like this
This is how the problem is solved now
This is how the problem was solved before.
This is how the program is described by marketing department
This, in fact, is what the customer wanted … ;-)
That is the program after debugging

16. The Software Process
A structured set of activities required to develop a software system
Specification
Design
Validation
Evolution
A software process model is an abstract representation of a process
It presents a description of a process from some particular perspective

17. Generic Software Process Models
The waterfall model
Separate and distinct phases of specification and development
Evolutionary development
Specification and development are interleaved
Formal systems development (example - ASML)
A mathematical system model is formally transformed to an implementation
Reuse-based development
The system is assembled from existing components

18. 1. Waterfall Model

19. Prescriptive Models
Prescriptive process models advocate an orderly approach to software engineering
That leads to a few questions …
If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change?
Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

20. The Waterfall Model

21. Waterfall model phases
Requirements analysis and definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
The drawback of the waterfall model is the difficulty of accommodating change after the process is underway

22. Waterfall model problems
Inflexible partitioning of the project into distinct stages
This makes it difficult to respond to changing customer requirements
Therefore, this model is only appropriate when the requirements are well-understood
Waterfall model describes a process of stepwise refinement
Based on hardware engineering models
Widely used in military and aerospace
industries

23. Why Not a Waterfall But software is different : No fabrication step
Program code is another design level
Hence, no “commit” step – software can always be changed…!
No body of experience for design analysis (yet)
Most analysis (testing) is done on program code
Hence, problems not detected until late in the process
Waterfall model takes a static view of requirements
Ignore changing needs
Lack of user involvement once specification is written
Unrealistic separation of specification from the design
Doesn’t accommodate prototyping, reuse, etc

24. 2. Evolutionary development
Exploratory development
Objective is to work with customers and to evolve a final system from an initial outline specification.
Should start with well-understood requirements.
The system evolves by adding new features as they are proposed by customer.
Throw-away prototyping
Objective is to understand the system requirements. Should start with poorly understood requirements
Develop “quick and dirty” system quickly;
Expose to user comment;
Refine;
Until adequate system developed.
Particularly suitable where:
detailed requirements not possible;
powerful development tools (e.g. GUI) available

25. Evolutionary Models: Prototyping
Quick
plan
communication
Modeling
Quick design
Deployment
delivery &
feedback
Construction
of prototype

26. Evolutionary Models: The Spiral

27. Evolutionary Models: Concurrent

28. The Incremental Model

29. The RAD Model

30. Still Other Process Models
Component based development—the process to apply when reuse is a development objective
Formal methods—emphasizes the mathematical specification of requirements
AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects
Unified Process—a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)

31. The Unified Process (UP)
inception
elaboration
inception

32. UP Phases

33. UP Work Products