Facultad de Ingeniería Mecánica y Eléctrica

Universidad Autónoma de Nuevo León

Material Didáctico Elaborado por

Dr. Edgar Danilo Domínguez Vera

Carrera: Ingeniería en Tecnología de Software

Unidad de Aprendizaje: Temas Selectos de la Ingeniería de Software

Elaborado: 01-Junio-2016

Tiempo de elaboración: 4 horas

 Bibliografía

Software Engineering: A practitioner's Approach

Roger S. Pressman

Seven Edition

Mc Graw Hill
The
Software
Process

Chapter 2
Roger S. Pressman
 What It is?
• When you work to build a product or system, It’s
important to go through a series of predictable
steps
 • Software engineers and their
managers adapt the process
to their needs and then
follow it
• The people who have
Who does requested the software have
it? a role to play in the process
of defining, building, and
testing
 The process provides stability,
control, and organization to an
activity that can, if left
uncontrolled, become quite
chaotic
Why is it
important? Modern process must be agile. We
have to choose only those
activities, controls, and work
products that are appropriate for
the project team and the product
that is to be produced
 At a detailed
What level, the process
are the that you adopt
depends on the
steps? software that
you’re building
 • Point of view of a
software engineer:
the set of programs,
documents, and
What is data that are
the work produced as a
consequence of the
product? activities and tasks
defined by the
process
 • There are a number of
software process
assessment mechanics
that enable organizations
How do I to determine the
”maturity”of their
ensure that software process
I´ve done it • Quality, timeliness, and
long-term viability of the
right? product you build are the
best indicators of the
efficacy of the software
that you use
A Generic
Process
Model Fig
2.1 pag.32
A software process framework
Process Flow.
Fig 2.2 pag.33
Process Flow. Fig 2.2 pag.33
 Small project vs. Complex project
Small project Complex project
1. Make contact with • Communication Activity.
Many stakeholders, each with
stakeholder via telephone different set of (sometime
2. Discuss requirements and conflicting) requirements
take notes • Inception
3. Organize notes into a brief • Elicitation
written statement of • Elaboration
requirements • Negotiation
4. E-mail to stakeholder for • Specification
review and approval • Validation
 2.1.2 Identifying a Task Set
• Each software engineering action can be
represented by a number of different task sets –
each a collection of SE work task, related work
products, quality assurance, and project
milestone.
• You should choose a task set that best
accommodates the needs of the project and the
characteristics of your team
• A SE action can be adapted to the specific needs
of the software project and the characteristics of
the project team
 • Chapter 12 • Initial context
2.1.3 • Pattern name • Problem

Process •
•
Forces
Type
•
•
Solution
Resulting Context
Patterns – Stage Pattern: • Related Patterns
e.g.Establising • Know Uses and
Communication Examples
– Task Pattern: e.g.
Requirements
Gathering
– Phase Pattern: e.g.
Spiral Modeling or
Prototyping
 Customers and software engineers
have established a collaborative
A Stage communication
Pattern. Successful completion of a number
(e.g. The of taks patterns [specified] for the
Communication has occurred
Planning The project scope, basic business
Pattern ) requirements, and project
constraints are know
 Standard CMMI Assessment
Method for Process Improvement
(SCAMPI)
CMM – Based Appraisal for Internal
2.2 Process Process Improvement (CBA IPI)
Assessment
and SPICE (ISO/IEC15504)
Improvement

ISO 9001:2000 for Software

 They are also referred as “traditional”
process models

2.3
Prescriptive They were originally proposed to
bring order to the chaos of software
Process development

Models
Are they innapropiated for software
world that thrives on change?
 2.3.1 The Waterfall
Model
• There are times when the
requirements for a problem are
well understood –when work flows
from communication through
deployment in a reasonably linear
fashion
• The requirements are well defined
and reasonably stable
• It is called classic life cycle (SDLC)
The Waterfall • It suggest a systematic sequential approach to
software development that begins with customer
Model. Fig. 2.3 specification of requirements and progress through
planning, modeling, construction, and deployment,
culminating in ongoing support of the completed
pag. 39 software
 The V-model. Fig.2.4 p40
It is a variation in the representation of the water fall model.
It depicts the relation of quality assurance to the actions associated with
communication, modeling, and early construction activities
 Criticism of the Waterfall Model
• It is the oldest paradigm
1. Real problems rarely follow the sequential
flow that the model proposes
2. It is often difficult for the customer to state al
requirements explicitly
3. The customer must have patience. A working
version of the program(s) will not be
available until late in the project time span
 There are many situations in which initial
software requirements are reasonably well
defined, but the overall scope of the
development effort precludes a purely linear
process

2.3.2 It combines elements of linear and parallel

process flows

Incremental
Process The first incremental is often a core product

Models
It focused on the delivery of an operational
product

It is useful when staffing is unavailable for

complete implementation by business deadline
that has been established for the project
The incremental model. Fig. 2.5 p 42
2.3.3 Evolutionary Process Model

Software evolves over a period of time. Business and

products requirements change as development proceeds,
making a straight line path to the end product unrealistic

Evolutionary models are iterative

Prototyping and The Spiral Model

 Prototyping

Often, a customer defines a set of general

objectives for software, but does not detailed
requirements for functions and features

It can be used as a stand-alone process model

It is more commonly used as a technique that

can be implemented whitin the context of any
one of the process models noted in this chapter
The prototyping paradigm. Fig. 2.6 p 43
 Prototyping
• A quick design focused on a representation of
those aspects of the software that will be
visible to the end users (e.g., human interface
or output display)
• Stakeholder provides feedback that is used to
further requirements
• It serves as a mechanism for identifying
requirements
• It can be as “the first system”
 The Spiral Model
• It is an evolutionary process model that
couples the iterative nature or prototyping
with the controlled and systematic aspects of
the water fall model
A typical spiral model. Fig. 2.7 page 46
 2.3.4 Concurrent Models
• It allows a software team to represent
iterative and concurrent elements of any if the
process models described en this chapter
One element of the concurrent process model. Fig. 2.8 pag. 48
Modeling Activity
A final word on Evolutionary Processes
• Modern computer software is characterized
by continual change, by very time lines, and
by emphatic need for customer-user
satisfaction
• Evolutionary process model were concieved to
address these issues
 2.4 Specialized Process Models
• They take on many characteristics of one or
more of the traditional models presented en
the preceding section
• Component-Based Development
• The Formal Methods Model
• Aspect-Oriented Software Development
 • It is an attempt to draw on the best features and
characteristics of traditional software process
2.5 The models, but characterized them in a way that
implements many of the best principles of agile
Unified •
software development (chapter 3)
UML. The Unified Model Language containts a
Process robust notation for modeling and development of
object-oriented systems (part 2 of this book).
• UML does not provide a framework to guide
project teams in their application of the
technology
The Unified Process. Fig. 2.9. page 55.
 2.6
Personal
and Team
Process
Models
 2.6.2 Team Software
(TSP)
• PSP is an introduction for TSP
• Objectives of TPS
– Build self-directed teams that plan an track their
work, establish goals, and their own process and
plans
– Show managers how to coach and motivate
their teams an how to help them sustain peak
performance
– Accelerate software process improvement by
making CMM level behavior normal and
expected
– Provide improvement guidance to high-maturity
organizations
– Facilitate university teaching of industrial-grade
team skills
 2.7 Process Technology

Process Technology tools have been developed to help

software organizations analyze their current process,
organize work task, control and monitor progress, and
manage technical quality

The model can be analyzed to determine typical workflow

and examine alternative process structures that might lead to
reduce development time or cost
 If the process is weak, the
end product will
undoubtedly suffer. But an
2.8 obsessive overreliance on
process is also dangerous
Product
and People derive as much (or
Process more) satisfaction from the
creative process as they do
from the end product