1. Chapter 2 Process Models
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

2. Software Engineering
The IEEE definition
The application of systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software;
that is, the application of engineering to software.

3. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
A Layered Technology
tools
methods
process model
a “quality” focus
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

4. A Layered Technology (cont.)
“We think that software developers are missing a vital truth: most organizations don’t know what they do. They think they know, but they don’t know.” Tom DeMarco Are All developers good?

5. A Layered Technology (cont.)
Quality
Any engineering approach must rest on organizational commitment to quality and to assure a continuous process improvement culture.
Process
Defines as a collection of work activities, actions, and tasks that are performed when some work product is to be created.
Defines who is doing what, when, and how to reach a certain goal.
Forms the basis for management control of software projects.
Methods
technical “how to” for building software
Broad array of tasks: communication, requirements analysis, design modeling, program construction, testing, and support
Tools
Automated support for process and methods

6. A Process Framework Process framework Framework activities work tasks
Software Process
Process framework
Process framework
Framework activities
work tasks
work products
milestones & deliverables
checkpoints
Umbrella Activities
Umbrella Activities
Framework activity 1
Framework activity n

7. Five Activities of a Generic Process framework
Communication
Planning
Modeling
Analysis of requirements
Design
Construction
Code generation
Testing
Deployment
Delivery
Feedback

8. Five Activities of a Generic Process framework (cont.)
Communication: communicate with customer to understand objectives and gather requirements
Planning:
Modeling:
Construction:
Deployment:
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

9. Five Activities of a Generic Process framework (cont.)
Communication:
Planning: creates a “map” that defines the work by describing tasks, risks and resources, work products and work schedule.
Modeling:
Construction:
Deployment:
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

10. Five Activities of a Generic Process framework (cont.)
Communication:
Planning:
Modeling: Create a “sketch”, what it looks like architecturally, how the essential parts fit together and other characteristics.
Construction:
Deployment:
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

11. Five Activities of a Generic Process framework (cont.)
Communication:
Planning:
Modeling:
Construction: code generation and the testing.
Deployment:
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

12. Five Activities of a Generic Process framework (cont.)
Communication:
Planning:
Modeling:
Construction:
Deployment: Delivered to the customer who evaluates the products & provides feedback based on the evaluation.
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

13. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Five Activities of a Generic Process framework (cont.)
These five framework activities can be used to all software development, regardless of the application domain, size of the project, complexity of the efforts etc.
though the details will be different in each case.
For many software projects, these framework activities are applied iteratively as a project progresses. Each iteration produces a software increment that provides a subset of overall software features and functionality.
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

14. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities
Complete the five process framework activities and help team manage and control progress, quality, change, and risk.
Software project tracking and control:
Risk management:
Software quality assurance:
Technical reviews:
Measurement:
Software configuration management:
Reusability management:
Work product preparation and production:
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

15. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities
Software project tracking & control: assess progress against the plan and take actions to maintain the schedule.
Risk management:
Software quality assurance:
Technical reviews:
Measurement:
Software configuration management:
Reusability management:
Work product preparation and production:
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

16. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities
Software project tracking & control:
Risk management: assesses risks that may affect the outcome and quality.
Software quality assurance:
Technical reviews:
Measurement:
Software configuration management:
Reusability management:
Work product preparation and production:
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

17. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities
Software project tracking & control:
Risk management:
Software quality assurance: defines and conduct activities to ensure quality.
Technical reviews:
Measurement:
Software configuration management:
Reusability management:
Work product preparation and production:
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

18. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities
Software project tracking & control:
Risk management:
Software quality assurance:
Technical reviews: assesses work products to uncover and remove errors before going to the next activity.
Measurement:
Software configuration management:
Reusability management:
Work product preparation and production:
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

19. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities
Software project tracking & control:
Risk management:
Software quality assurance:
Technical reviews:
Measurement: define and collects process, project, and product measures to ensure stakeholder’s needs are met.
Software configuration management:
Reusability management:
Work product preparation and production:
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

20. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities
Software project tracking & control:
Risk management:
Software quality assurance:
Technical reviews:
Measurement:
Software configuration management: manage the effects of change throughout the software process.
Reusability management:
Work product preparation and production:
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

21. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities
Software project tracking & control:
Risk management:
Software quality assurance:
Technical reviews:
Measurement:
Software configuration management:
Reusability management: defines criteria for work product reuse and establishes mechanism to achieve reusable components.
Work product preparation and production:
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

22. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Umbrella Activities
Software project tracking & control:
Risk management:
Software quality assurance:
Technical reviews:
Measurement:
Software configuration management:
Reusability management:
Work product preparation and production: create work products such as models, documents, logs, forms and lists.
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

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

24. Process Patterns A Process Pattern
describes a process-related problem that is encountered during software engineering work,
identifies the environment in which the problem has been encountered,
suggests one or more proven solutions to the problem.

25. Process Pattern Types
Stage patterns
Task patterns
Phase patterns

26. Process Pattern Types
Stage patterns—defines a problem associated with a framework activity for the process.
Task patterns
Phase patterns

27. Process Pattern Types Stage patterns
Task patterns—defines a problem associated with a software engineering action or work task and relevant to successful software engineering practice
Phase patterns

28. Process Pattern Types Stage patterns Task patterns
Phase patterns—define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature.

29. Prescriptive Process Models
Traditional process models
Specialized process models
Unified process
(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

30. Traditional Process Models
Defines a distinct set of activities, actions, tasks, milestones, and work products that are required to engineer high-quality software
The activities can be
linear,
incremental,
evolutionary

31. Waterfall Model (Diagram)
Communication
Project initiation
Requirements gathering
Planning
Estimating
Scheduling
Tracking
Modeling
Analysis
Design
Construction
Code
Test
Deployment
Delivery
Support
Feedback 31

32. Waterfall Model (Description)
Oldest software lifecycle model & best understood by upper management
Used when requirements are well understood and risk is low
Work flow is in a linear fashion (i.e., sequential)
Used often with well-defined adaptations or enhancements to current software 32

33. Waterfall Model (Problems)
Doesn't support iteration, so changes can cause confusion
Difficult for customers to state all requirements explicitly and up front
Requires customer patience because a working version of the program doesn't occur until the final phase 33

34. Incremental Model (Diagram)
Communication
Planning
Modeling
Construction
Deployment
Increment #2
Communication
Planning
Modeling
Construction
Deployment
Increment #3
Communication
Planning
Modeling
Construction
Deployment 34

35. Incremental Model (Description)
Used when requirements are well understood
Multiple independent deliveries are identified
Work flow is in a linear (i.e., sequential) fashion within an increment and is staggered between increments
Iterative in nature; focuses on an operational product with each increment
Provides a needed set of functionality sooner while delivering optional components later
Useful also when staffing is too short for a full-scale development 35

36. Prototyping Model (Diagram)
Quick Planning
Communication
Start
Modeling
Quick Design
Deployment,
Delivery,
and Feedback
Construction
Of Prototype 36

37. Prototyping Model (Description)
Follows an evolutionary and iterative approach
Used when requirements are not well understood
Serves as a mechanism for identifying software requirements
Focuses on those aspects of the software that are visible to the customer/user
Feedback is used to refine the prototype 37

38. Prototyping Model (Potential Problems)
The customer sees a "working version" of the software, wants to stop all development and then buy the prototype after a "few fixes" are made
Developers often make implementation compromises to get the software running quickly
(e.g., language choice, user interface, operating system choice, inefficient algorithms) 38

39. Spiral Model (Diagram)
Planning
Communication
Modeling
Start
Start
Deployment
Construction 39

40. Spiral Model (Description)
Follows an evolutionary approach
Used when requirements are not well understood and risks are high
Inner spirals focus on identifying software requirements and project risks; may also incorporate prototyping
Outer spirals take on a classical waterfall approach after requirements have been defined, but permit iterative growth of the software
Operates as a risk-driven model…a go/no-go decision occurs after each complete spiral in order to react to risk determinations
Requires considerable expertise in risk assessment
Serves as a realistic model for large-scale software development 40

41. General Weaknesses of Evolutionary Process Models
Prototyping poses a problem to project planning because of the uncertain number of iterations required to construct the product
Evolutionary software processes do not establish the maximum speed of the evolution
If too fast, the process will fall into chaos
If too slow, productivity could be affected
Software processes should focus first on flexibility and extensibility, and second on high quality
We should prioritize the speed of the development over zero defects
Extending the development in order to reach higher quality could result in late delivery 41

42. Specialized Process Models

43. Component-based Development Model
Consists of the following process steps
Available component-based products are researched and evaluated for the application domain in question
Component integration issues are considered
A software architecture is designed to accommodate the components
Components are integrated into the architecture
Comprehensive testing is conducted to ensure proper functionality
Relies on a robust component library
Capitalizes on software reuse, which leads to documented savings in project cost and time 43

44. Formal Methods Model (Description)
Encompasses a set of activities that leads to formal mathematical specification of computer software
Enables a software engineer to specify, develop, and verify a computer-based system by applying a rigorous, mathematical notation
Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily through mathematical analysis
Offers the promise of defect-free software
Used often when building safety-critical systems 44

45. Formal Methods Model (Challenges)
Development of formal methods is currently quite time- consuming and expensive
Because few software developers have the necessary background to apply formal methods, extensive training is required
It is difficult to use the models as a communication mechanism for technically unsophisticated customers 45

46. The Unified Process

47. Background
They eventually worked together on a unified method, called the Unified Modelling Language (UML)
UML is a robust notation for the modelling and development of object- oriented systems
UML became an industry standard in 1997
However, UML does not provide the process framework, only the necessary technology for object-oriented development
Unified process developed which is a framework for object-oriented software engineering using UML
Draws on the best features and characteristics of conventional software process models
Emphasizes the important role of software architecture
Consists of a process flow that is iterative and incremental, thereby providing an evolutionary feel 47

48. Background (continued)
Consists of 5 phases:
inception,
elaboration,
construction,
transition,
production 48

49. Phases of the Unified Process
Elaboration
Inception
planning
modeling
communication
construction
Construction
deployment
Transition
Production 49

50. (1) - Inception Phase
Encompasses both customer communication and planning activities of the generic process
Business requirements for the software are identified
A rough architecture for the system is proposed
A plan is created for an incremental, iterative development
Fundamental business requirements are described through preliminary use cases
A use case describes a sequence of actions that are performed by a user 50

51. (2) - Elaboration Phase
Encompasses both the planning and modelling activities of the generic process
Refines and expands the preliminary use cases
Expands the architectural representation to include five views
Use-case model
Analysis model
Design model
Implementation model
Deployment model
Often results in an executable architectural baseline that represents a first cut executable system
The baseline demonstrates the viability of the architecture but does not provide all features and functions required to use the system 51

52. (3) - Construction Phase
Encompasses the construction activity of the generic process
Uses the architectural model from the elaboration phase as input
Develops or acquires the software components that make each use-case operational
Analysis and design models from the previous phase are completed to reflect the final version of the increment
Use cases are used to derive a set of acceptance tests that are executed prior to the next phase 52

53. (4) - Transition Phase
Encompasses the last part of the construction activity and the first part of the deployment activity of the generic process
Software is given to end users for beta testing and user feedback reports on defects and necessary changes
The software teams create necessary support documentation (user manuals, trouble-shooting guides, installation procedures)
At the conclusion of this phase, the software increment becomes a usable software release 53

54. (5) - Production Phase
Encompasses the last part of the deployment activity of the generic process
On-going use of the software is monitored
Support for the operating environment (infrastructure) is provided
Defect reports and requests for changes are submitted and evaluated 54

55. Unified Process Work Products
Work products are produced in each of the first four phases of the unified process
In this course, we will concentrate on the analysis model and the design model work products
Analysis model includes
Scenario-based model, class-based model, and behavioural model
Design model includes
Component-level design, interface design, architectural design, and data/class design 55 

56. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Agile Process Models
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

57. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Agile Process Models
The prescriptive process models stress detailed definition, identification, and application of process activates and tasks. Intent is to improve system quality, make projects more manageable, make delivery dates and costs more predictable, and guide teams of software engineers as they perform the work required to build a system.
Unfortunately, there have been times when these objectives were not achieved. If prescriptive models are applied strictly and without adaptation, they can increase the level of organization.
Agile process models emphasize project “agility (alertness)” and follow a set of principles that lead to a more informal approach to software process. It emphasizes maneuverability and adaptability. It is particularly useful when Web applications are engineered.
a planned and regulated movement or evolution of troops,warships, etc.
2.maneuvers, a series of tactical exercises usually carried out inthe field by large bodies of troops in simulating the conditions ofwar.
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

58. The Essence of Practice
How does the practice of software engineering fit in the process activities mentioned above? Namely,
communication,
planning,
modeling,
construction
deployment.
the essence of problem solving is outlined in 4 points:
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

59. Understand the Problem
Who has a stake in the solution to the problem? That is, who are the stakeholders?
What are the unknowns? What data, functions, and features are required to properly solve the problem?
Can the problem be classified? Is it possible to represent smaller problems that may be easier to understand?
Can the problem be represented graphically? Can an analysis model be created?
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

60. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Plan the Solution
Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, and features that are required?
Has a similar problem been solved? If so, are elements of the solution reusable?
Can sub-problems be defined? If so, are solutions readily apparent for the sub-problems?
Can you represent a solution in a manner that leads to effective implementation? Can a design model be created?
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

61. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Carry Out the Plan
Does the solutions conform to the plan? Is source code traceable to the design model?
Is each component part of the solution provably correct? Has the design and code been reviewed, or better, have correctness proofs been applied to algorithm?
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

62. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
Examine the Result
Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented?
Does the solution produce results that conform to the data, functions, and features that are required? Has the software been validated against all stakeholder requirements?
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

63. Software Myths Examples
Myth 1: Once we write the program and get it to work, our job is done.
Reality: the sooner you begin writing code, the longer it will take you to get done. 60% to 80% of all efforts are spent after software is delivered to the customer for the first time.
Myth 2: Until I get the program running, I have no way of assessing its quality.
Reality: technical review are a quality filter that can be used to find certain classes of software defects from the inception of a project.
Myth 3: software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down.
Reality: it is not about creating documents. It is about creating a quality product. Better quality leads to a reduced rework. Reduced work results in faster delivery times.
Many people recognize the fallacy of the myths. Regrettably, habitual attitudes and methods foster poor management and technical practices, even when reality dictates a better approach.
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

64. SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2
End Thank you
SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2