Introductory slides for the Software Process Theory. It presents the foundations (software process, sw process improvement, basic lifecycles

1. SW Process
Foundations
Modelos de Procesos y
Metodologías de Ingeniería de
software
Mayo de 2014
Universidad de Caldas
Facultad de Ingenierías
Maestría en Ingeniería Computacional

2. Welcome!

3. Content
SW Process Foundations
Software Process Improvement
Processes Models
The IDEAL Model
SP and SWEBOK
Traditional Lifecycles

4. Sources
•Gerard O’Regan, Introduction to Software Process
Improvement, Springer 2011. ISBN 978-0-85729-171-4
•James R. Persse. Process Improvement Essentials. O'Reilly,
2006. ISBN 978-0-59-610217-3
•F. Alan Goodman. Defining and Deploying Software Processes.
Auerbach Publications, 2006. ISBN 0-8493-9845-2.
•Ian Sommerville. Software Engineering Ninth Edition. Addison-
Wesley, 2011. ISBN 978-0-13-703515-1.
•And others!!

5. In the beginning
•Leon Osterweil (1987):
SOFTWARE PROCESSES ARE SOFTWARE TOO
•Osterweil, L. (1987) 'Software
process are software too',
Proceeding of 9th International
Conference on Software
Engineering, Monterey,
California, USA, pp.2-13.

6. In the beginning
•Leon Osterweil (1987):

7. In the beginning
•Leon Osterweil (1987):

8. In the Beginning
•… it thereby strongly invites the question of whether
process programs might themselves be considered to
be instances of some higher level process
description…
•…we should expect that they are best thought of as
being only a part of a larger information aggregate…
•This information aggregate contains such other
software objects as requirements specifications (for
the process description itself), design information
(which is used to guide the creation of the process
description), and test cases (projects which were
guided by processes instantiated by the process
description).

9. When people think in SW Process?
•In an ISO 9000 program
•In a CMMI adoption program
•In any other process quality adoption (ISO 15504, Six
Sigma…)
•As consequence of any national call?
•…
•As consequence of pitfalls or chaos?
•Really as a opportunity for reaching a full SW Quality
goal(¿?) – must we do it?
•Not as consequence of their formation in
universities…

10. When people think in SW Process?
•In resume
- To elaborate on a high-level “what” step within an
activity
- To satisfy a high-level “what” requirement (e.g., to
satisfy an ISO 9001 standard requirement)
- To satisfy a high-level “what” perceived
requirement (e.g., to satisfy a CMMI process
maturity goal/standard practice)
- To satisfy implied industry best practices
- To satisfy some kind of stimulus

11. When people think in SW Process?
Software process improvement initiatives are aligned
to business goals and play a key role in helping
companies achieve their strategic goals. It is invaluable
in the implementation of best practice in organizations
and allows companies to focus on fire prevention
rather than firefighting.
Source: Gerard O’Regan, Introduction to Software Process Improvement, Springer 2011.

12. All are connected, such as Touch
(Fox)
Fuente: http://sunilduttjha.files.wordpress.com/2012/02/16_changes.gif
The H-W's power

13. When people think in SW Process?
• National SW Quality initiative (since 2005).
• Red Colombiana de Calidad para el Desarrollo en
Tecnologías de Información y Comunicación
(www.rcctic.org).  dead
• SENA
• MinTIC (FITI)
• COLCIENCIAS
• Some Universities (UniCauca, EAFIT, UIS…)

14. When people think in SW Process?
Real life...

15. So, what is a Software Process?
• It is the process used by software engineers to
design and develop computer software.
• A process is a set of practices or tasks performed
to achieve a given purpose. It may include tools,
methods, material, and people.
• An organization will typically have many processes
in place for doing its work, and the object of process
improvement is to improve these to meet business
goals more effectively.

16. SEI to rescue!!
• The Software Engineering Institute (SEI) believes
that there is a close relationship between the
quality of the delivered software and the quality
and maturity of the underlying processes
employed to create the software.
• The SEI adopted and applied the principles of
process improvement employed in the
manufacturing field to develop process maturity
models such as the CMM and its successor the
CMMI. These maturity models are invaluable in
maturing software processes in software intensive
organizations.
Source: Gerard O’Regan, Introduction to Software Process Improvement, Springer 2011.

17. A SW process is an
abstraction of the way in
which work is done in the
organization and is seen
as the glue that ties
people, procedures, and
tools together

18. So, what is a SP Improvement?
• Software process improvement is concerned with
practical action to improve the processes in the
organization to ensure that they meet business
goals more effectively.
• A program of activities designed to improve the
performance and maturity of the organization’s
software processes and the results of such a
program.

19. • Software process improvement initiatives support
the organization in achieving its key business goals
such as delivering software faster to the market,
improving quality, reducing or eliminating
waste.
• The objective is to work smarter and to build
software better, faster, and cheaper than
competitors.
• Software process improvement makes business
sense and provides a return on investment.

20. Benefits of SPI
• Improvements to quality
• Reductions in the cost of poor quality
• Improvements in productivity
• Reductions to the cost of software development
• Improvements to on-time delivery
• Improved consistency in budget and schedule
delivery
• Improvements to customer satisfaction
• Improvements to employee morale

21. Process Model
• A process model defines best practice for
software processes in an organization.
• It describes what the processes should do rather
than how they should be done, and this allows the
organization to use professional judgment to choose
the most appropriate process implementation to
meet its needs.
• The process model will need to be interpreted and
tailored to the particular organization.

22. Process Model (II)
• A process model provides a place to start an
improvement initiative and it provides a common
language and shared vision for improvement.
• It provides a framework to prioritize actions and
allows the benefits of the experience of other
organizations to be shared.

23. Process Model Examples
• Capability Maturity Model Integration (CMMI)
• ISO 9001 Standard
• ISO 15504
• PSP and TSP
• Six Sigma
• IEEE standards
• Root Cause Analysis
• Balanced Scorecard

24. CMMI
• Comes from Humphry, W.: Managing the Software
Process. Addison Wesley (1989)
• The CMMI is a suite of products used for improving
processes, and it includes models, appraisal
methods, and training material.
• The CMMI models address three areas of interest:
– CMMI for Development (CMMI-DEV)
– CMMI for Services (CMMI-SVC)
– CMMI for Acquisition (CMMI-ACQ)

25. CMMI (II)
• It is a framework that allows organizations to
improve their maturity by improvements to their
underlying processes.
• It provides a structured approach and allows the
organization to set improvement goals and
priorities.
• It provides a clearly defined roadmap for
improvement and it allows the organization to
improve at its own pace.
• Its approach is evolutionary rather than
revolutionary, and it recognizes that a balance is
required between project needs and process
improvement needs.

26. CMMI (III)
• It allows the processes to evolve from ad hoc
immature activities to disciplined mature processes.
• The CMMI practices may be used for the
development, acquisition, and maintenance of
products and services. A SCAMPI appraisal
determines the process maturity of an organization
and allows it to benchmark itself against other
organizations.

27. ISO 9001
• ISO 9001 is an internationally recognized quality
management standard and is customer and process
focused. It applies to the processes that an
organization uses to create and control products
and services, and it emphasizes continuous
improvement.
• The standard is designed to apply to any product or
service that an organization supplies.
• The implementation of ISO 9001 involves
understanding the requirements of the standard and
how the standard applies to the organization.

28. ISO 9001 (II)
• It requires the organization to identify its quality
objectives, define a quality policy, produce
documented procedures, and carry out independent
audits to ensure that the processes and procedures
are followed.
• An organization may be certified against the ISO
9001 standard to gain recognition to its commitment
to quality and continuous improvement. The
certification involves an independent assessment of
the organization to verify that it has implemented the
ISO 9001 requirements properly and that the quality
management system is effective.

29. ISO 9001 (III)
• It will also verify that the processes and procedures
defined are consistently followed and that
appropriate records are maintained.
• (The ISO 9004 standard provides guidance for
continuous improvement).

30. ISO 15504 (SPICE)
• Is an international standard for process assessment.
It includes guidance for process improvement and
for process capability determination, as well as
guidance for performing an assessment.
• It includes an exemplar process assessment model
for software life cycle processes and also an
exemplar process assessment model for systems
life cycle processes.

31. ISO 15504 (SPICE) (II)
• ISO/IEC 15504 can be used in a similar way to the
CMMI and its exemplar models (for either software
or systems life cycles) may be employed to
implement best practice in process definition.
• Assessments may be performed to identify
strengths and opportunities for improvement.

32. PSP/TSP (powered by by Watt Humphrey)
• The Personal Software Process (PSP) is a
disciplined data-driven software development
process that is designed to help software engineers
understand and to improve their personal software
process performance.
• It helps engineers to improve their estimation and
planning skills and to reduce the number of
defects in their work. This enables them to make
commitments that they can keep and to manage the
quality of their projects.

33. PSP/TSP (II)
• The Team Software Process (TSP) is a structured
approach designed to help software teams
understand and improve their quality and
productivity.
• Its focus is on building an effective software
development team, and it involves establishing
team goals, assigning team roles as well as other
teamwork activities. Team members must already
be familiar with the PSP.

34. More about Watt Humphrey
• http://www.sei.cmu.edu/watts/index.cfm
• He is considered as the father of software
quality

35. Six Sigma
• Six Sigma (6σ) was developed by Motorola in 1985,
as a way to improve quality and reduce waste.
• Six Sigma is an approach whose purpose is to
identify and remove the causes of defects in
processes by minimizing process variability.
• Six Sigma was influenced by earlier quality
management techniques developed by Shewhart,
Deming, and Juran.
• Wikipedia: A six sigma process is one in which
99.99966% of the products manufactured are
statistically expected to be free of defects
(3.4 defects per million)

36. Six Sigma
• A Six-Sigma project follows a defined sequence of
steps and has quantified targets. These targets may
be financial, quality, customer satisfaction, and cycle
time reduction.
• It uses quality management techniques and tools
such as the five whys, business process mapping,
statistical techniques, and the DMAIC and DMADV
methodologies.

37. Six Sigma
http://www.isixsigma.com/new-to-six-sigma/design-for-six-sigma-dfss/dmaic-versus-dmadv/

38. Starting a SPI program
• The need for a software process improvement
initiative often arises from the realization that:
– the organization is weak in some areas in
software engineering, and
– that it needs to improve to achieve its business
goals more effectively.
• The starting point of any improvement initiative is an
examination of the business goals of the
organization and these may include
– Delivering high-quality products on time
– Delivering products faster to the market
– Reducing the cost of software development
– Improving software quality

39. Obstacles
• Software process improvement initiatives are not always
successful, and occasionally an improvement initiative is
abandoned. Some of the reasons for failure are
– Unrealistic expectations
– Trying to do too much at once
– Lack of senior management sponsorship
– Focusing on a maturity level
– Poor project management of the initiative
– Not run as a standard project
– Insufficient involvement of staff
– Insufficient time to work on improvements
– Inadequate training on software process improvement
– Lack of pilots to validate new processes
– Inadequate rollout of new processes

40. Obstacles
• It is essential that a software process improvement
initiative be treated as a standard project with a
project manager assigned to manage the initiative.
• Senior management need to be 100% committed to
the success of the initiative, and they need to make
staff available to work on the improvement activities.
• It needs to be clear to all staff that the improvement
initiative is a priority to the organization.
• All staff need to receive appropriate training on
software process improvement and on the process
maturity model

41. Be carefull
Software Processes are essential
for Software Quality
….
But, quality in software needs more
elements…

42. Be carefull
According with ISO 25000 (SQUARE) – evolution of ISO 9126

43. ISO’s for Sofware Process
• ISO 9000
• ISO 12207
- defines the software engineering process, activity, and
tasks that are associated with a software life cycle process
from conception through retirement
- A standard that provides a common framework to speak
the same language in software discipline.
• ISO 15504
• Please see slides from Claude Laporte
http://profs.etsmtl.ca/claporte/english/VSE/Education/Intro%2
0to%20ISO-IEC%20SE%20standards%2002RO.ppt

44. Starting a SPI program
• Building through executive sponsorship
• Capitalizing on your strengths
• Understanding what you'd like to do better
• Focusing on targeted improvements
• Borrowing from the industry
• Building from the inside
• Building to grow
• Training your people
• Providing support
• Patience, not perfection

45. Starting a SPI program
• It's a good idea to follow something of a predictable
path when you want to establish a process program:
a method that will help shape the program as
smoothly as possible, in an orderly and manageable
way.
• One approach to this can be found in the IDEAL
model: Initiate, Diagnose, Establish, Act, and Learn.
IDEAL is a general approach to process
improvement

46. IDEAL Model

47. IDEAL Model (II) - Initiate
• In the Initiate phase, an organization typically
reaches the understanding that it has operational
issues that need to be addressed.
• This realization is often predicated by some
symptomatic imbalance within the organization:
falling sales, rising costs, increased complaints,
low morale, or even the appreciation for general
improvement, for strengthening the
organization's current position.
• It can be many things, but it's always a trigger for
action.

48. IDEAL Model (III) - Initiate
• The organization makes a conscious decision to
initiate action, to act on its needs. This decision is
then followed by the critical impetus of dedication to
act.
• The Initiate phase is typically the point at which you
acquire executive sponsorship and begin to
formulate the scope of what you want to address in
your process program.

49. IDEAL Model (IV) - Diagnose
• In the Diagnose phase, the organization's current
quality and process positions is determined, also its
strengths and weaknesses, and what areas for
improvement should be addressed by this effort.
• Questions to resolve: What the organization
should change?, where it should focus its
improvement activities?.
• Many process managers would argue that this is the
stage where you should devote most of your energy,
most of your creative thinking. The better the
diagnosis, the better the chance for a highly
successful solution.

50. IDEAL Model (V) - Establish
• In the Establish phase, you typically create your
process components or refine existing ones.
• The key to successful establishment is to create
solutions that reflect the way your people work,
solutions that possess a strong goodness-of-fit to
the culture of the organization.

51. IDEAL Model (VI) - Establish
• Solution involves three key factors:
- It should be designed with organizational use in
mind. That is, you should be pretty certain that if
you implement it, it will work.
- The solution should be designed not to impact the
integrity of any up-line or down-line activity. You
don't want to cause other problems by fixing one.
- The solution should be in some way measurable.
The best way to test if any solution works is to
measure its activity. (This use of the measurement
data comes into play during the Learn portion of
IDEAL.)

52. IDEAL Model (VII) - Act
• Here, you implement the solutions you designed.
• Act may require a series of support steps, such as
training or documentation preparation, but the real
goal here is to act on your design: put it effectively
into place, monitor its use, and then move to the
final step, Learn.
• Act is the phase during which you typically train
your people, provide them with program support
materials, and then implement the program in the
organization.

53. IDEAL Model (VIII) - Learn
• Process improvement is all about learning.
That's a core trait of the discipline: it's a cultural
commitment to continued learning.
• Time and data will give you the factual base you
need to determine the success of your efforts and
may also point you to new opportunities for
strengthening the system
• What that observation period largely depends on is
the nature of your environment and the solutions
you've added into the environment.

54. IDEAL Model (IX)
• The IDEAL model are considered since SWEBOK
2004 together with Quality Improvement Paradigm
(QIP) as the two general models that have
emerged for driving process implementation and
change.
• Reference work: Software Engineering Laboratory,
Software Process Improvement Guidebook,
Software Engineering Laboratory, NASA/GSFC,
Technical Report SEL-95-102, April 1996.
• SWEBOK: Evaluation of process implementation
and change outcomes can be qualitative or
quantitative.

55. SP and SWEBOK
http://www.computer.org/portal/web/swebok/v3guide
SWEBOK 2013 -
Chapter 8
ISO Technical
Report ISO/IEC
TR 19759

56. SP and SWEBOK
Chapter 8 - Software Process Definition

57. SP and SWEBOK
•Pair
Programming
•RAD
•XP
•Scrum
•FDD
SWEBOK 2013 - Chapter 9 ISO Technical Report ISO/IEC TR 19759

58. • There is, of course, little point in having high-quality
processes unless their use is institutionalized in the
organization. That is, all staff need to follow the
processes consistently.
• This requires that all affected staff are trained on the
new processes and that process discipline is
instilled by an appropriate audit strategy.
• Mature software companies will establish high-
quality processes for the various software.
So…

59. • The development of software involves many
processes such as those for defining requirements;
processes for project management and estimation;
and processes for design, implementation, testing
management and engineering activities.
• All affected staff will then be trained on the new
processes and audits will be conducted to ensure
that the process is followed. Data will be collected to
improve the process.

60. • The software process assets in an organization
generally consist of
– A software development policy for the
organization
– Process maps that describe the flow of activities
– Procedures and guidelines that describe the
processes in more detail
– Checklists to assist with the performance of the
process
– Templates for the performance of specific
activities (e.g. design, testing)
– Training materials

61. The processes employed to develop high-quality software
generally include processes for
– Project management process
– Requirements process
– Design process
– Coding process
– Peer review process
– Testing process
– Supplier selection and management processes
– Configuration management process
– Audit process
– Measurement process
– Improvement process
– Customer support and maintenance processes

62. The software development process has an associated
life cycle that consists of various phases. There are
several well-known life cycles employed such as
• the waterfall model,
• the spiral model, and
• the IBM Rational Unified Process.

63. Traditional components of a SW
Process
• Purpose description
• Entry Criteria (previous activities or preconditions that may
need to have occurred in order for the activities of this
process to be successfully carried out)
• Inputs
• Actors
• Activities
• Outputs
• Exit criteria (results that should be in place in order to
conclude that the process has been sucessfully run)
• Measures

64. Traditional components of a SW
Process Program
• Processes
• Procedures
• Templates
• Forms and checklists
• Guidelines
• Repositories
• Training materials

65. • Roy:70 Royce, Winston.: The software lifecycle
model (waterfall model). In: Proceedings
WESTCON, Los Angeles, Aug 1970.
• Source of the "conventional software process"?
• Benchmark?
• It provides an insightful and concise summary of
conventional software management philosophy
circa 1970.
The waterfall lifecycle model

66. The waterfall lifecycle model (II)
primary points of Royce paper

67. The waterfall lifecycle model (III)
proposal 1970

68. • It starts with requirements gathering and definition.
It is followed by the functional specification, the
design and implementation of the software, and
comprehensive testing.
• The testing generally includes unit, system, and
user acceptance testing.
• The waterfall model is employed for projects where
the requirements can be identified early in the
project life cycle or are known in advance.
The waterfall lifecycle model (IV)

69. • Each phase has entry and exit criteria that must be
satisfied before the next phase commences.
• There are several variations to the waterfall mode.
• There is a variation: the “V” life cycle model, with the
left-hand side of the “V” detailing requirements,
specification, design, and coding and the right-hand
side detailing unit tests, integration tests, system
tests, and acceptance testing.
- Specially mentioned by the ISTQB Certification!!
The waterfall lifecycle model (V)

70. The waterfall lifecycle model (VI)
typical "V" waterfall
Source: Advanced Software Testing—
Vol. 3 - Guide to the ISTQB Advanced
Certification as an Advanced Technical
Test Analyst http://www.istqb.org/

71. • The spiral model is useful where the requirements
are not fully known at project initiation.
• The requirements evolve as a part of the
development life cycle.
• The development proceeds in a number of spirals,
where each spiral typically involves updates to the
requirements, design, code, testing and a user
review of the particular iteration or spiral.
The spiral lifecycle model

72. The spiral lifecycle model (II)
Typical spiral example

73. The spiral lifecycle model (III)
Boehm’s spiral model of the software process (©IEEE 1988)

74. • The spiral is a reusable prototype with the business analysts
and the customer reviewing the current iteration and
providing feedback to the development team.
• The feedback is then analyzed and addressed in subsequent
spirals.
• This approach is often used in joint application development
for web-based software development as usability and the
look and feel of the application is a key concern. The
implementation of part of the system helps in gaining a better
understanding of the requirements of the system, and this
feeds into subsequent development cycle in the spiral.
• The process repeats until the requirements and the software
product are fully complete.
The spiral lifecycle model (IV)

75. • A risk-driven software process framework
• Each loop in the spiral represents a phase of the software
process.
• The innermost loop might be concerned with system
feasibility, the next loop with requirements definition, the next
loop with system design, and so on.
• The spiral model combines change avoidance with change
tolerance.
• It assumes that changes are a result of project risks and
includes explicit risk management activities to reduce these
risks.
Boehm’s spiral model

76. Objective setting
• Specific objectives for that phase of the project are defined.
• Constraints on the process and the product are identified and
a detailed management plan is drawn up.
• Project risks are identified. Alternative strategies, depending
on these risks, may be planned.
Risk assessment and reduction
• For each of the identified project risks, a detailed analysis is
carried out.
• Steps are taken to reduce the risk. For example, if there is a
risk that the requirements are inappropriate, a prototype
system may be developed.
Boehm’s spiral model (II)

77. Development and validation
• After risk evaluation, a development model for the system is
chosen.
• For example, throwaway prototyping may be the best
development approach if user interface risks are dominant. If
safety risks are the main consideration, development based
on formal transformations may be the most appropriate
process, and so on. If the main identified risk is sub-system
integration, the waterfall model may be the best development
model to use.
Planning
• The project is reviewed and a decision made whether to
continue with a further loop of the spiral. If it is decided to
continue, plans are drawn up for the next phase of the
project.
Boehm’s spiral model (III)

78. • The main difference between the spiral model and other software
process models is its explicit recognition of risk.
• A cycle of the spiral begins by elaborating objectives such as
performance and functionality. Alternative ways of achieving these
objectives, and dealing with the constraints on each of them, are then
enumerated.
• Each alternative is assessed against each objective and sources of
project risk are identified.
• The next step is to resolve these risks by information-gathering activities
such as more detailed analysis, prototyping, and simulation.
• Once risks have been assessed, some development is carried out,
followed by a planning activity for the next phase of the process.
• Informally, risk simply means something that can go wrong.
• Risks lead to proposed software changes and project problems
such as schedule and cost overrun, so risk minimization is a very
important project management activity.
Boehm’s spiral model (IV)

79. • A prototype is an initial version of a software system that is
used to demonstrate concepts, try out design options, and
find out more about the problem and its possible solutions.
• Rapid, iterative development of the prototype is essential so
that costs are controlled and system stakeholders can
experiment with the prototype early in the software process.
• A software prototype can be used in a software development
process to help anticipate changes that may be required:
1. In the requirements engineering process, a prototype can
help with the elicitation and validation of system
requirements.
2. In the system design process, a prototype can be used to
explore particular software solutions and to support user
interface design.
Prototyping

80. • A system prototype may be used while the system is being
designed to carry out design experiments to check the
feasibility of a proposed design. For example, a database
design may be prototyped and tested to check that it
supports efficient data access for the most common user
queries.
• Prototyping is also an essential part of the user interface
design process. Because of the dynamic nature of user
interfaces, textual descriptions and diagrams are not good
enough for expressing the user interface requirements.
Therefore, rapid prototyping with end-user involvement is the
only sensible way to develop graphical user interfaces for
software systems.
Prototyping (II)

81. Prototyping (III)
Prototyping software process defined by Sommerville

82. • It may be impossible to tune the prototype to meet non-
functional requirements, such as performance, security,
robustness, and reliability requirements, which were ignored
during prototype development.
• Rapid change during development inevitably means that the
prototype is undocumented. The only design specification is
the prototype code. This is not good enough for long-term
maintenance.
• The changes made during prototype development will
probably have degraded the system structure. The system
will be difficult and expensive to maintain.
• Organizational quality standards are normally relaxed for
prototype development.
• Prototypes do not have to be executable to be useful
(mockups for example)
Prototyping in real life

83. • A general problem with prototyping is that the prototype may
not necessarily be used in the same way as the final system.
The tester of the prototype may not be typical of system
users. The training time during prototype evaluation may be
insufficient.
• If the prototype is slow, the evaluators may adjust their way
of working and avoid those system features that have slow
response times. When provided with better response in the
final system, they may use it in a different way.
Prototyping in real life (II)

84. • Some of the developed increments are delivered to the
customer and deployed for use in an operational
environment.
• In an incremental delivery process, customers identify, in
outline, the services to be provided by the system. They
identify which of the services are most important and which
are least important to them.
• A number of delivery increments are then defined, with each
increment providing a sub-set of the system functionality.
Iterative – Incremental delivery

85. Iterative – Incremental delivery (II)
typical iterative-incremental scenario

86. • The allocation of services to increments depends on the
service priority, with the highest-priority services
implemented and delivered first.
• Once the system increments have been identified, the
requirements for the services to be delivered in the first
increment are defined in detail and that increment is
developed.
• During development, further requirements analysis for later
increments can take place but requirements changes for the
current increment are not accepted.
• Once an increment is completed and delivered, customers
can put it into service. This means that they take early
delivery of part of the system functionality.
Iterative – Incremental delivery (III)

87. • Customers can use the early increments as prototypes and gain
experience that informs their requirements for later system
increments.
• (Unlike prototypes, these are part of the real system so there is
no re-learning when the complete system is available).
• Customers do not have to wait until the entire system is
delivered before they can gain value from it. The first increment
satisfies their most critical requirements so they can use the
software immediately.
• The process maintains the benefits of incremental development
in that it should be relatively easy to incorporate changes into
the system.
• As the highest-priority services are delivered first and
increments then integrated, the most important system services
receive the most testing. This means that customers are less
likely to encounter software failures in the most important parts
of the system.
Advantages IID

88. • Most systems require a set of basic facilities that are used by
different parts of the system. It can be hard to identify
common facilities that are needed by all increments. As
requirements are not defined in detail until an increment is to
be implemented,
• Iterative development can also be difficult when a
replacement system is being developed. Users want all of
the functionality of the old system and are often unwilling to
experiment with an incomplete new system. Therefore,
getting useful customer feedback is difficult.
Problems IID

89. The essence of iterative processes is that the specification is
developed in conjunction with the software.
So…
• This conflicts with the procurement model of many
organizations, where the complete system specification is
part of the system development contract.
• This requires a new form of contract, which large
customers such as government agencies may find difficult to
accommodate.
• In the incremental approach, there is no complete
system specification until the final increment is
specified.
Problems IID (II)

90. Conclusion?
http://testingtype.freetzi.com/sdlc_model.html
The Build and Fix model

91. Graphical Comparison
Source: Melnik Grigiri, Meszaros Gerard and Bach Jon. Acceptance Test Engineering Guide Volume I:
Thinking. Microsoft Patterns and Practices Press,2009.
Multi‐release waterfall with
overlapping functionality
Classical waterfall
Multi‐release waterfall with
independentfunctionality

92. Graphical Comparison
Source: Melnik Grigiri, Meszaros Gerard and Bach Jon. Acceptance Test Engineering Guide Volume I:
Thinking. Microsoft Patterns and Practices Press,2009.
Agile methods
(comming soon)
Iterative & Incremental

93. Questions?
Thanks