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

Chapter 2

Process Models

Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman

2

Software Engineering

• The application of systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software;

• that is, the application of engineering to software.

The IEEE definitionThe IEEE definition

SOFTWARE ENGINEERING APPLICATION DEVELOPMENT---- CHAPTER 2

A Layered Technology

3

a “quality” focus

process model

methods

tools

“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?

4

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 methods5

A Layered Technology (cont.)

6

A Process Framework

Process frameworkFramework activities work tasks

work products milestones & deliverables checkpoints

Umbrella Activities

Process framework

Umbrella Activities

Framework activity 1

Framework activity n

Software Process

7

Five Activities of a Generic Process framework

1. Communication2. Planning3. Modeling

– Analysis of requirements– Design

4. Construction– Code generation– Testing

5. Deployment – Delivery– Feedback


Five Activities of a Generic Process framework (cont.)

• Communication: communicate with customer to understand

objectives and gather requirements

• Planning:

• Modeling:

• Construction:

• Deployment:

8



• Communication:

• Planning: creates a “map” that defines the work by describing

tasks, risks and resources, work products and work schedule.

• Modeling:

• Construction:

• Deployment:

9



• Communication:

• Planning:

• Modeling: Create a “sketch”, what it looks like architecturally, how

the essential parts fit together and other characteristics.

• Construction:

• Deployment:

10



• Communication:

• Planning:

• Modeling:

• Construction: code generation and the testing.

• Deployment:

11



• Communication:

• Planning:

• Modeling:

• Construction:

• Deployment: Delivered to the customer who evaluates the

products & provides feedback based on the evaluation.

12


13

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



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:

14


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:

15


Umbrella Activities• Software project tracking & control:• Risk management: assesses risks that may affect the outcome and quality. • Software quality assurance:• Technical reviews:

• Measurement:




16


Umbrella Activities• Software project tracking & control: • Risk management:• Software quality assurance: defines and conduct activities to ensure quality. • Technical reviews:

• Measurement:




17


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:




18


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.




19



• Measurement:

• Software configuration management: manage the effects of change throughout the software process.



20



• Measurement:


• Reusability management: defines criteria for work product reuse and establishes mechanism to achieve reusable components.


21



• Measurement:



• Work product preparation and production: create work products such as models, documents, logs, forms and lists.

22

23These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e

(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

Process Flow

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

1. Stage patterns2. Task patterns3. Phase patterns

26


1. Stage patterns—defines a problem associated with a framework activity for the process.

2. Task patterns3. Phase patterns

27


1. Stage patterns2. Task patterns—defines a problem

associated with a software engineering action or work task and relevant to successful software engineering practice

3. Phase patterns

28


1. Stage patterns2. Task patterns3. Phase patterns—define the

sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature.

Prescriptive Process Models

• Traditional process models• Specialized process models• Unified process

(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

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)

CommunicationProject initiation

Requirements gathering

PlanningEstimatingScheduling

Tracking ModelingAnalysisDesign Construction

CodeTest Deployment

DeliverySupport

Feedback

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

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

34

Incremental Model(Diagram)

Communication PlanningModeling

ConstructionDeployment





Increment #1

Increment #2

Increment #3

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

36

Prototyping Model(Diagram)

Communication

Quick Planning

ModelingQuick Design

ConstructionOf Prototype

Deployment,Delivery,

and Feedback

Start

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

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)

39

Spiral Model(Diagram)

Start

Start

Communication

Planning

Modeling


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

41

General Weaknesses of Evolutionary Process Models

1) Prototyping poses a problem to project planning because of the uncertain number of iterations required to construct the product

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

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

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

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

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

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

48

Background (continued)

• Consists of 5 phases: 1. inception, 2. elaboration, 3. construction, 4. transition, 5. production

49

Phases of the Unified Process

communication

planning

modeling

construction

deployment

Inception Elaboration

Construction

TransitionProduction

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

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

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

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

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

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


56

Agile Process Models


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.

57


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


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?

59


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?

60


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?

61


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?

62


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.

63


64

EndThank you

Documents

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