Introduction to Software Process

SW Process Foundations

Modelos de Procesos y Metodologías de Ingeniería de software

Mayo de 2014

Universidad de CaldasFacultad de IngenieríasMaestría en Ingeniería Computacional

Welcome!

ContentSW Process Foundations

Software Process Improvement

Processes Models

The IDEAL Model

SP and SWEBOK

Traditional Lifecycles

Sources

•Gerard O’Regan, Introduction to Software ProcessImprovement, 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!!

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.



In the Beginning•… it thereby strongly invites the question of whetherprocess programs might themselves be considered tobe instances of some higher level processdescription…

•…we should expect that they are best thought of asbeing only a part of a larger information aggregate…

•This information aggregate contains such othersoftware objects as requirements specifications (forthe process description itself), design information(which is used to guide the creation of the processdescription), and test cases (projects which wereguided by processes instantiated by the processdescription).

When people think in SW Process?

•In an ISO 9000 program

•In a CMMI adoption program

•In any other process quality adoption (ISO 15504, SixSigma…)

•As consequence of any national call?

•…

•As consequence of pitfalls or chaos?

•Really as a opportunity for reaching a full SW Qualitygoal(¿?) – must we do it?

•Not as consequence of their formation inuniversities…


•In resume

- To elaborate on a high-level “what” step within anactivity

- To satisfy a high-level “what” requirement (e.g., tosatisfy an ISO 9001 standard requirement)

- To satisfy a high-level “what” perceivedrequirement (e.g., to satisfy a CMMI processmaturity goal/standard practice)

- To satisfy implied industry best practices

- To satisfy some kind of stimulus


Software process improvement initiatives are alignedto business goals and play a key role in helpingcompanies achieve their strategic goals. It is invaluablein the implementation of best practice in organizationsand allows companies to focus on fire preventionrather than firefighting.

Source: Gerard O’Regan, Introduction to Software Process Improvement, Springer 2011.

All are connected, such as Touch

(Fox)

Fuente: http://sunilduttjha.files.wordpress.com/2012/02/16_changes.gif

The H-W's power


• National SW Quality initiative (since 2005).

• Red Colombiana de Calidad para el Desarrollo enTecnologías de Información y Comunicación(www.rcctic.org). dead

• SENA

• MinTIC (FITI)

• COLCIENCIAS

• Some Universities (UniCauca, EAFIT, UIS…)


Real life...

So, what is a Software Process?

• It is the process used by software engineers todesign and develop computer software.

• A process is a set of practices or tasks performedto achieve a given purpose. It may include tools,methods, material, and people.

• An organization will typically have many processesin place for doing its work, and the object of processimprovement is to improve these to meet businessgoals more effectively.

SEI to rescue!!• The Software Engineering Institute (SEI) believes

that there is a close relationship between thequality of the delivered software and the qualityand maturity of the underlying processesemployed to create the software.

• The SEI adopted and applied the principles ofprocess improvement employed in themanufacturing field to develop process maturitymodels such as the CMM and its successor theCMMI. These maturity models are invaluable inmaturing software processes in software intensiveorganizations.

Source: Gerard O’Regan, Introduction to Software Process Improvement, Springer 2011.

A SW process is anabstraction of the way inwhich work is done in theorganization and is seenas the glue that tiespeople, procedures, andtools together

So, what is a SP Improvement?

• Software process improvement is concerned withpractical action to improve the processes in theorganization to ensure that they meet businessgoals more effectively.

• A program of activities designed to improve theperformance and maturity of the organization’ssoftware processes and the results of such aprogram.

• Software process improvement initiatives supportthe organization in achieving its key business goalssuch as delivering software faster to the market,improving quality, reducing or eliminatingwaste.

• The objective is to work smarter and to buildsoftware better, faster, and cheaper thancompetitors.

• Software process improvement makes businesssense and provides a return on investment.

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 scheduledelivery

• Improvements to customer satisfaction

• Improvements to employee morale

Process Model

• A process model defines best practice forsoftware processes in an organization.

• It describes what the processes should do ratherthan how they should be done, and this allows theorganization to use professional judgment to choosethe most appropriate process implementation tomeet its needs.

• The process model will need to be interpreted andtailored to the particular organization.

Process Model (II)

• A process model provides a place to start animprovement initiative and it provides a commonlanguage and shared vision for improvement.

• It provides a framework to prioritize actions andallows the benefits of the experience of otherorganizations to be shared.

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

CMMI

• Comes from Humphry, W.: Managing the SoftwareProcess. Addison Wesley (1989)

• The CMMI is a suite of products used for improvingprocesses, and it includes models, appraisalmethods, 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)

CMMI (II)• It is a framework that allows organizations to

improve their maturity by improvements to theirunderlying processes.

• It provides a structured approach and allows theorganization to set improvement goals andpriorities.

• It provides a clearly defined roadmap forimprovement and it allows the organization toimprove at its own pace.

• Its approach is evolutionary rather thanrevolutionary, and it recognizes that a balance isrequired between project needs and processimprovement needs.

CMMI (III)

• It allows the processes to evolve from ad hocimmature activities to disciplined mature processes.

• The CMMI practices may be used for thedevelopment, acquisition, and maintenance ofproducts and services. A SCAMPI appraisaldetermines the process maturity of an organizationand allows it to benchmark itself against otherorganizations.

ISO 9001

• ISO 9001 is an internationally recognized qualitymanagement standard and is customer and processfocused. It applies to the processes that anorganization uses to create and control productsand services, and it emphasizes continuousimprovement.

• The standard is designed to apply to any product orservice that an organization supplies.

• The implementation of ISO 9001 involvesunderstanding the requirements of the standard andhow the standard applies to the organization.

ISO 9001 (II)

• It requires the organization to identify its qualityobjectives, define a quality policy, producedocumented procedures, and carry out independentaudits to ensure that the processes and proceduresare followed.

• An organization may be certified against the ISO9001 standard to gain recognition to its commitmentto quality and continuous improvement. Thecertification involves an independent assessment ofthe organization to verify that it has implemented theISO 9001 requirements properly and that the qualitymanagement system is effective.

•

ISO 9001 (III)

• It will also verify that the processes and proceduresdefined are consistently followed and thatappropriate records are maintained.

• (The ISO 9004 standard provides guidance forcontinuous improvement).

ISO 15504 (SPICE)

• Is an international standard for process assessment.It includes guidance for process improvement andfor process capability determination, as well asguidance for performing an assessment.

• It includes an exemplar process assessment modelfor software life cycle processes and also anexemplar process assessment model for systemslife cycle processes.

ISO 15504 (SPICE) (II)

• ISO/IEC 15504 can be used in a similar way to theCMMI and its exemplar models (for either softwareor systems life cycles) may be employed toimplement best practice in process definition.

• Assessments may be performed to identifystrengths and opportunities for improvement.

PSP/TSP (powered by by Watt Humphrey)

• The Personal Software Process (PSP) is adisciplined data-driven software developmentprocess that is designed to help software engineersunderstand and to improve their personal softwareprocess performance.

• It helps engineers to improve their estimation andplanning skills and to reduce the number ofdefects in their work. This enables them to makecommitments that they can keep and to manage thequality of their projects.

PSP/TSP (II)

• The Team Software Process (TSP) is a structuredapproach designed to help software teamsunderstand and improve their quality andproductivity.

• Its focus is on building an effective softwaredevelopment team, and it involves establishingteam goals, assigning team roles as well as otherteamwork activities. Team members must alreadybe familiar with the PSP.

More about Watt Humphrey

• http://www.sei.cmu.edu/watts/index.cfm

• He is considered as the father of softwarequality

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 toidentify and remove the causes of defects inprocesses by minimizing process variability.

• Six Sigma was influenced by earlier qualitymanagement techniques developed by Shewhart,Deming, and Juran.

• Wikipedia: A six sigma process is one in which99.99966% of the products manufactured arestatistically expected to be free of defects(3.4 defects per million)

Six Sigma

• A Six-Sigma project follows a defined sequence ofsteps and has quantified targets. These targets maybe financial, quality, customer satisfaction, and cycletime reduction.

• It uses quality management techniques and toolssuch as the five whys, business process mapping,statistical techniques, and the DMAIC and DMADVmethodologies.

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

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 insoftware engineering, and

– that it needs to improve to achieve its businessgoals more effectively.

• The starting point of any improvement initiative is anexamination of the business goals of theorganization 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

Obstacles• Software process improvement initiatives are not always

successful, and occasionally an improvement initiative isabandoned. 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

Obstacles

• It is essential that a software process improvementinitiative be treated as a standard project with aproject manager assigned to manage the initiative.

• Senior management need to be 100% committed tothe success of the initiative, and they need to makestaff available to work on the improvement activities.

• It needs to be clear to all staff that the improvementinitiative is a priority to the organization.

• All staff need to receive appropriate training onsoftware process improvement and on the processmaturity model

Be carefull

Software Processes are essential for Software Quality

….

But, quality in software needs more elements…

Be carefull

According with ISO 25000 (SQUARE) – evolution of ISO 9126

ISO’s for Sofware Process

• ISO 9000

• ISO 12207

- defines the software engineering process, activity, andtasks that are associated with a software life cycle processfrom conception through retirement

- A standard that provides a common framework to speakthe same language in software discipline.

• ISO 15504

• Please see slides from Claude Laporte

http://profs.etsmtl.ca/claporte/english/VSE/Education/Intro%20to%20ISO-IEC%20SE%20standards%2002RO.ppt

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

Starting a SPI program

• It's a good idea to follow something of a predictablepath when you want to establish a process program:a method that will help shape the program assmoothly as possible, in an orderly and manageableway.

• One approach to this can be found in the IDEALmodel: Initiate, Diagnose, Establish, Act, and Learn.IDEAL is a general approach to processimprovement

IDEAL Model

IDEAL Model (II) - Initiate

• In the Initiate phase, an organization typicallyreaches the understanding that it has operationalissues that need to be addressed.

• This realization is often predicated by somesymptomatic imbalance within the organization:falling sales, rising costs, increased complaints,low morale, or even the appreciation for generalimprovement, for strengthening theorganization's current position.

• It can be many things, but it's always a trigger foraction.

IDEAL Model (III) - Initiate

• The organization makes a conscious decision toinitiate action, to act on its needs. This decision isthen followed by the critical impetus of dedication toact.

• The Initiate phase is typically the point at which youacquire executive sponsorship and begin toformulate the scope of what you want to address inyour process program.

IDEAL Model (IV) - Diagnose

• In the Diagnose phase, the organization's currentquality and process positions is determined, also itsstrengths and weaknesses, and what areas forimprovement should be addressed by this effort.

• Questions to resolve: What the organizationshould change?, where it should focus itsimprovement activities?.

• Many process managers would argue that this is thestage where you should devote most of your energy,most of your creative thinking. The better thediagnosis, the better the chance for a highlysuccessful solution.

IDEAL Model (V) - Establish

• In the Establish phase, you typically create yourprocess components or refine existing ones.

• The key to successful establishment is to createsolutions that reflect the way your people work,solutions that possess a strong goodness-of-fit tothe culture of the organization.

IDEAL Model (VI) - Establish

• Solution involves three key factors:

- It should be designed with organizational use inmind. That is, you should be pretty certain that ifyou implement it, it will work.

- The solution should be designed not to impact theintegrity of any up-line or down-line activity. Youdon'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 tomeasure its activity. (This use of the measurementdata comes into play during the Learn portion ofIDEAL.)

IDEAL Model (VII) - Act

• Here, you implement the solutions you designed.

• Act may require a series of support steps, such astraining or documentation preparation, but the realgoal here is to act on your design: put it effectivelyinto place, monitor its use, and then move to thefinal step, Learn.

• Act is the phase during which you typically trainyour people, provide them with program supportmaterials, and then implement the program in theorganization.

IDEAL Model (VIII) - Learn

• Process improvement is all about learning.That's a core trait of the discipline: it's a culturalcommitment to continued learning.

• Time and data will give you the factual base youneed to determine the success of your efforts andmay also point you to new opportunities forstrengthening the system

• What that observation period largely depends on isthe nature of your environment and the solutionsyou've added into the environment.

IDEAL Model (IX)

• The IDEAL model are considered since SWEBOK2004 together with Quality Improvement Paradigm(QIP) as the two general models that haveemerged for driving process implementation andchange.

• 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 implementationand change outcomes can be qualitative orquantitative.

SP and SWEBOK

http://www.computer.org/portal/web/swebok/v3guide

SWEBOK 2013 -Chapter 8

ISO TechnicalReport ISO/IEC

TR 19759

SP and SWEBOK

Chapter 8 - Software Process Definition

SP and SWEBOK

•PairProgramming

•RAD

•XP

•Scrum

•FDD

SWEBOK 2013 - Chapter 9 ISO Technical Report ISO/IEC TR 19759

• There is, of course, little point in having high-qualityprocesses unless their use is institutionalized in theorganization. That is, all staff need to follow theprocesses consistently.

• This requires that all affected staff are trained on thenew processes and that process discipline isinstilled by an appropriate audit strategy.

• Mature software companies will establish high-quality processes for the various software.

So…

• The development of software involves manyprocesses such as those for defining requirements;processes for project management and estimation;and processes for design, implementation, testingmanagement and engineering activities.

• All affected staff will then be trained on the newprocesses and audits will be conducted to ensurethat the process is followed. Data will be collected toimprove the process.

• The software process assets in an organizationgenerally consist of

– A software development policy for theorganization

– Process maps that describe the flow of activities

– Procedures and guidelines that describe theprocesses in more detail

– Checklists to assist with the performance of theprocess

– Templates for the performance of specificactivities (e.g. design, testing)

– Training materials

The processes employed to develop high-quality softwaregenerally 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

The software development process has an associatedlife cycle that consists of various phases. There areseveral well-known life cycles employed such as

• the waterfall model,

• the spiral model, and

• the IBM Rational Unified Process.

Traditional components of a SW

Process• Purpose description

• Entry Criteria (previous activities or preconditions that mayneed to have occurred in order for the activities of thisprocess to be successfully carried out)

• Inputs

• Actors

• Activities

• Outputs

• Exit criteria (results that should be in place in order toconclude that the process has been sucessfully run)

• Measures

Traditional components of a SW

Process Program

• Processes

• Procedures

• Templates

• Forms and checklists

• Guidelines

• Repositories

• Training materials

• Roy:70 Royce, Winston.: The software lifecyclemodel (waterfall model). In: ProceedingsWESTCON, Los Angeles, Aug 1970.

• Source of the "conventional software process"?

• Benchmark?

• It provides an insightful and concise summary ofconventional software management philosophycirca 1970.

The waterfall lifecycle model

The waterfall lifecycle model (II)

primary points of Royce paper

The waterfall lifecycle model (III)

proposal 1970

• It starts with requirements gathering and definition.It is followed by the functional specification, thedesign and implementation of the software, andcomprehensive testing.

• The testing generally includes unit, system, anduser acceptance testing.

• The waterfall model is employed for projects wherethe requirements can be identified early in theproject life cycle or are known in advance.

The waterfall lifecycle model (IV)

• Each phase has entry and exit criteria that must besatisfied before the next phase commences.

• There are several variations to the waterfall mode.

• There is a variation: the “V” life cycle model, with theleft-hand side of the “V” detailing requirements,specification, design, and coding and the right-handside detailing unit tests, integration tests, systemtests, and acceptance testing.

- Specially mentioned by the ISTQB Certification!!

The waterfall lifecycle model (V)

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/

• The spiral model is useful where the requirementsare not fully known at project initiation.

• The requirements evolve as a part of thedevelopment life cycle.

• The development proceeds in a number of spirals,where each spiral typically involves updates to therequirements, design, code, testing and a userreview of the particular iteration or spiral.

The spiral lifecycle model

The spiral lifecycle model (II)

Typical spiral example

The spiral lifecycle model (III)

Boehm’s spiral model of the software process (©IEEE 1988)

• The spiral is a reusable prototype with the business analystsand the customer reviewing the current iteration andproviding feedback to the development team.

• The feedback is then analyzed and addressed in subsequentspirals.

• This approach is often used in joint application developmentfor web-based software development as usability and thelook and feel of the application is a key concern. Theimplementation of part of the system helps in gaining a betterunderstanding of the requirements of the system, and thisfeeds into subsequent development cycle in the spiral.

• The process repeats until the requirements and the softwareproduct are fully complete.

The spiral lifecycle model (IV)

• A risk-driven software process framework

• Each loop in the spiral represents a phase of the softwareprocess.

• The innermost loop might be concerned with systemfeasibility, the next loop with requirements definition, the nextloop with system design, and so on.

• The spiral model combines change avoidance with changetolerance.

• It assumes that changes are a result of project risks andincludes explicit risk management activities to reduce theserisks.

Boehm’s spiral model

Objective setting

• Specific objectives for that phase of the project are defined.

• Constraints on the process and the product are identified anda detailed management plan is drawn up.

• Project risks are identified. Alternative strategies, dependingon these risks, may be planned.

Risk assessment and reduction

• For each of the identified project risks, a detailed analysis iscarried out.

• Steps are taken to reduce the risk. For example, if there is arisk that the requirements are inappropriate, a prototypesystem may be developed.

Boehm’s spiral model (II)

Development and validation

• After risk evaluation, a development model for the system ischosen.

• For example, throwaway prototyping may be the bestdevelopment approach if user interface risks are dominant. Ifsafety risks are the main consideration, development basedon formal transformations may be the most appropriateprocess, and so on. If the main identified risk is sub-systemintegration, the waterfall model may be the best developmentmodel to use.

Planning

• The project is reviewed and a decision made whether tocontinue with a further loop of the spiral. If it is decided tocontinue, plans are drawn up for the next phase of theproject.

Boehm’s spiral model (III)

• The main difference between the spiral model and other softwareprocess models is its explicit recognition of risk.

• A cycle of the spiral begins by elaborating objectives such asperformance and functionality. Alternative ways of achieving theseobjectives, and dealing with the constraints on each of them, are thenenumerated.

• Each alternative is assessed against each objective and sources ofproject risk are identified.

• The next step is to resolve these risks by information-gathering activitiessuch 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 problemssuch as schedule and cost overrun, so risk minimization is a veryimportant project management activity.

Boehm’s spiral model (IV)

• A prototype is an initial version of a software system that isused to demonstrate concepts, try out design options, andfind out more about the problem and its possible solutions.

• Rapid, iterative development of the prototype is essential sothat costs are controlled and system stakeholders canexperiment with the prototype early in the software process.

• A software prototype can be used in a software developmentprocess to help anticipate changes that may be required:

1. In the requirements engineering process, a prototype canhelp with the elicitation and validation of systemrequirements.

2. In the system design process, a prototype can be used toexplore particular software solutions and to support userinterface design.

Prototyping

• A system prototype may be used while the system is beingdesigned to carry out design experiments to check thefeasibility of a proposed design. For example, a databasedesign may be prototyped and tested to check that itsupports efficient data access for the most common userqueries.

• Prototyping is also an essential part of the user interfacedesign process. Because of the dynamic nature of userinterfaces, textual descriptions and diagrams are not goodenough for expressing the user interface requirements.Therefore, rapid prototyping with end-user involvement is theonly sensible way to develop graphical user interfaces forsoftware systems.

Prototyping (II)

Prototyping (III)

Prototyping software process defined by Sommerville

• It may be impossible to tune the prototype to meet non-functional requirements, such as performance, security,robustness, and reliability requirements, which were ignoredduring prototype development.

• Rapid change during development inevitably means that theprototype is undocumented. The only design specification isthe prototype code. This is not good enough for long-termmaintenance.

• The changes made during prototype development willprobably have degraded the system structure. The systemwill be difficult and expensive to maintain.

• Organizational quality standards are normally relaxed forprototype development.

• Prototypes do not have to be executable to be useful(mockups for example)

Prototyping in real life

• A general problem with prototyping is that the prototype maynot necessarily be used in the same way as the final system.The tester of the prototype may not be typical of systemusers. The training time during prototype evaluation may beinsufficient.

• If the prototype is slow, the evaluators may adjust their wayof working and avoid those system features that have slowresponse times. When provided with better response in thefinal system, they may use it in a different way.

Prototyping in real life (II)

• Some of the developed increments are delivered to thecustomer and deployed for use in an operationalenvironment.

• In an incremental delivery process, customers identify, inoutline, the services to be provided by the system. Theyidentify which of the services are most important and whichare least important to them.

• A number of delivery increments are then defined, with eachincrement providing a sub-set of the system functionality.

Iterative – Incremental delivery

Iterative – Incremental delivery (II)

typical iterative-incremental scenario

• The allocation of services to increments depends on theservice priority, with the highest-priority servicesimplemented and delivered first.

• Once the system increments have been identified, therequirements for the services to be delivered in the firstincrement are defined in detail and that increment isdeveloped.

• During development, further requirements analysis for laterincrements can take place but requirements changes for thecurrent increment are not accepted.

• Once an increment is completed and delivered, customerscan put it into service. This means that they take earlydelivery of part of the system functionality.

Iterative – Incremental delivery (III)

• Customers can use the early increments as prototypes and gainexperience that informs their requirements for later systemincrements.

• (Unlike prototypes, these are part of the real system so there isno re-learning when the complete system is available).

• Customers do not have to wait until the entire system isdelivered before they can gain value from it. The first incrementsatisfies their most critical requirements so they can use thesoftware immediately.

• The process maintains the benefits of incremental developmentin that it should be relatively easy to incorporate changes intothe system.

• As the highest-priority services are delivered first andincrements then integrated, the most important system servicesreceive the most testing. This means that customers are lesslikely to encounter software failures in the most important partsof the system.

Advantages IID

• Most systems require a set of basic facilities that are used bydifferent parts of the system. It can be hard to identifycommon facilities that are needed by all increments. Asrequirements are not defined in detail until an increment is tobe implemented,

• Iterative development can also be difficult when areplacement system is being developed. Users want all ofthe functionality of the old system and are often unwilling toexperiment with an incomplete new system. Therefore,getting useful customer feedback is difficult.

Problems IID

The essence of iterative processes is that the specification isdeveloped in conjunction with the software.

So…

• This conflicts with the procurement model of manyorganizations, where the complete system specification ispart of the system development contract.

• This requires a new form of contract, which largecustomers such as government agencies may find difficult toaccommodate.

• In the incremental approach, there is no completesystem specification until the final increment isspecified.

Problems IID (II)

Conclusion?

http://testingtype.freetzi.com/sdlc_model.html

The Build and Fix model

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 withoverlapping functionality

Classical waterfall

Multi‐release waterfall withindependent functionality

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

Questions?

Thanks