EPRAM: A Risk Analysis and Mitigation-Based Evolutionary Prototyping Model for Quality Requirements Development.

(1)

EPRAM: A Risk Analysis and Mitigation-Based Evolutionary

Prototyping Model for Quality Requirements Development.

Carter, Ryan Alden

Ana (Annie) I. Antón, Committee Chair

ABSTRACT

Evolutionary prototyping focuses on the iteration of software planning,

implementation, and evaluation while gathering a correct and consistent set of

requirements. The process lends particular strength to building quality software due,

in part, to the ongoing clarification of existing requirements and the discovery of

previously missing or unknown requirements. Traditionally, however, the iterative

reexamination of a system’s requirements has not been the panacea that practitioners

sought due to the predisposition for requirements creep and the difficulty in managing

it. This thesis describes the use of evolutionary prototyping in conjunction with an

aggressive risk-mitigation strategy. Together, these techniques support successful

requirement discovery and clarification and guard against the negative effects of

requirements creep; an aspect that general evolutionary prototyping methodologies

have not mastered. These techniques are embodied in a comprehensive software

development model, which has been christened as the EPRAM (Evolutionary

Prototyping with Risk Analysis and Mitigation) model. To ensure that quality is

inherent within this process model, the Software Engineering Institute’s (SEI)

Capability Maturity Model (CMM) was tailored to conform to the development

(2)

base upon which to build the model. The model was intentionally designed to

comply with the Level 2 Key Process Areas (KPA) of the CMM. Validation of the

EPRAM model has occurred on several software development efforts employing the

(3)

EPRAM: A Risk Analysis and Mitigation-Based Evolutionary

Prototyping Model for Quality Requirements Development.

by

Ryan Alden Carter

A thesis presented to the Academic Faculty of North Carolina State University

in Partial Fulfillment of the requirements for the Degree of

Master of Science

COMPUTER SCIENCE

April 2001

APPROVED BY:

Dr. Ana (Annie) I. Antón, Chair of Advisory Committee

Dr. Aldo Dagnino

(4)

Personal Biography

Ryan Alden Carter is originally from Minneapolis, North Carolina – a small town

situated high in the Appalachian Mountains. He pursued a Bachelor of Science degree in

Computer Science from the University of North Carolina at Charlotte. Upon completion

of his undergraduate coursework in 1999, Ryan continued his education by enrolling in

North Carolina State University where he sought a Master of Science degree in Computer

Science. During the summer of 2000, he was the instructor for Computer Science 310

(Software Engineering), a core course in the North Carolina State undergraduate

curriculum. Ryan has also taught computer classes at Mayland Community College in

Spruce Pine, North Carolina. He intends to graduate from North Carolina State

(5)

Acknowledgements

Sometimes our light goes out but is blown into flame by another human being. Each of us owes deepest thanks to those who have rekindled this light.

Albert Schweitzer

First and foremost, I would like to thank my family for their continued support.

To Mom, Dad, and Grant for never letting me drive myself crazy, however hard I tried. I

owe each of you special thanks beyond what I could ever express.

I wish to thank Thomas, John, Devon, and Jason for allowing me to crash in their

office when they were here, and in their homes when they weren’t.

I would like to thank my committee members, Dr. Antón, Dr. Dagnino, Dr. Earp,

and Dr. Williams for their time and help over the last year. Special thanks to Dr. Antón

for rap sessions about my thesis and life, in general. Additionally, I would like to thank

Dr. Vouk for providing the opportunity to delve into prototyping during CSC 510.

I am grateful to have had the opportunity to work with ABB (this work was

partially funded by Asea Brown Boveri grant #2001-0867) and with the e-commerce

practicum students. I wish to thank Hema Srikanth, Ashish Sureka, Kai Yang, and

Lingyun Yang for their assistance and discussions while tailoring the CMM to achieve

(6)

List of Tables

3.1 Example Tailored CMM Elements ……….. 48

4.1 Relationships Encountered During EPRAM

Inspection Validation ……….. 54

4.2 Results Found from Inspections During the Case

(10)

List of Figures

2.1 Vertical Prototyping ……….. 12

2.2 Horizontal Prototyping ……….. 12

2.3 Evolutionary Prototyping Cycle ……….. 13

2.4 Representation of the Evolutionary Prototyping

Model ……….. 16

2.5 Operational Prototyping ……….. 30

2.6 Levels of Risk and Knowledge in the Gate

Model ……….. 36

3.1 The Evolutionary Prototyping with Risk

(11)

List of Symbols and Abbreviations

4GLs …. 4th generation languages

ABB …. Asea Brown Boveri

CASE …. Computer Aided Software Engineering

CMM …. Capability Maturity Model

E-commerce …. Electronic Commerce

EDM …. Electricidade da Madeira (utility company)

EPRAM …. Evolutionary Prototyping with Risk Analysis and Mitigation

(model)

KPA …. Key Process Area

NCSU …. North Carolina State Univeristy

RAD …. Rapid Application Development

SEI …. Software Engineering Institute

SITINA …. Sistema de Telemetria para Instalacoes Nao Acompanhadas

(12)

Glossary

• Capability Maturity Model: A software process improvement model that provides a set of best practices for improving the software development process, thereby

increasing product quality [JB97].

• Evolutionary Prototyping: An iterative software lifecycle model in which a software prototype gains functionality by being repeatedly planned, implemented, and

reviewed until a final system emerges. The prototype embodies the best-understood

requirements.

• Horizontal Prototyping: A form of iterative prototyping in which all modules covering the breadth of the software system are developed with limited, yet

increasing functionality as the project is refined.

• Operational Prototyping: A form of prototyping that involves the incorporation of throw-away prototyping layered on top of an evolutionary baseline [Dav92].

• Requirements Creep: Significant additions or modifications to the requirements of a software system, resulting in extensions to and alteration of the software’s

(13)

• Throw-away Prototyping: A form of prototyping in which prototypes are developed from the least-understood requirements for experimentation purposes and are then

discarded [Som95].

• Vertical Prototyping: A form of iterative prototyping in which a limited number of modules are developed per cycle with complete functionality. Thus, the system

(14)

Chapter 1 Introduction

Sometimes a scream is better than a thesis.

Ralph Waldo Emerson

Prototyping has gained acceptance in the software engineering community as a

credible model for software creation, and it has been listed among other more traditional

process methodologies including the Waterfall and Spiral models [Jal00]. Due to the

rising costs of software and the lower rates of systems meeting customer needs,

evolutionary prototyping has become a viable software development model [Dav92]. It

addresses a number of problems such as increased maintenance requests [Gra89],

premature freezing of requirements [Som95], difficulty in revisiting previous model

stages [Pre01, Som95], lack of consideration of user-system interfaces [Gra91], and

miscommunication between developers and customers [Gra91] that are not adequately

addressed in more traditional software process models. Additionally, evolutionary

prototyping provides other benefits including: the clarification of management and user

requirements [LSZ93], the ability to uncover missing or previously unknown

(15)

developers can communicate about systems, the easing of maintenance tasks, the creation

of ‘better’ user interfaces [Gra89, Gra91, LSZ93], prototyping with quality [Dav92,

Roy90], and the ability for developers to reflect on lessons learned during system

development [FD89].

Requirements creep refers to significant additions or modifications to the

requirements of a software system throughout the lifecycle, resulting in extensions to and

alteration of the software’s functionality and scope. Requirements creep can be

especially troublesome and frustrating to developers when it is not properly managed due

to the detrimental impact such changes may have on cost, resources, quality, or the ability

to deliver a system that incorporates the new requirements on time. While it can be

argued that the majority of software applications have unstable requirements and that

requirements creep is observed, to some degree, in all requirements methodologies

[Jon96], evolutionary prototyping is particularly susceptible to significant changes in

requirements [Gra89, Gra91]. This is due, in part, to the cyclical revisiting of

requirements throughout the development process.

Electronic commerce (e-commerce) software developers, under pressure to

develop applications at a record pace, are especially ill-equipped to handle requirements

creep due to the widespread lack of process discipline and procedural guidance available

for such market-driven environments. For this reason, requirements creep is rampant in

emerging e-commerce domains, as the innovator often discovers requirements as the

system is incrementally implemented. This thesis presents a risk-based evolutionary

(16)

Mitigation) model, that explicitly addresses the challenges inherent in these small, rapid

development efforts.

We ensured that the EPRAM model follows the intent and guidance (thus

adhering to the spirit) of the CMM. This was done by first tailoring the Software

Engineering Institute’s (SEI) Capability Maturity Model (CMM) [PWC94] for use by

small software development teams comprised of as few as 5 individuals, and then using

this tailoring as the basis for the EPRAM. The EPRAM model and associated techniques

facilitate the construction of a complete and consistent set of system requirements while

mitigating the ill effects of requirements creep by supporting the early detection and

resolution of requirements conflict.

Use of the model by small teams has demonstrated that the EPRAM model is

effective for rapid software development; it has undergone validation in various

e-commerce projects in which security and privacy are paramount. The model has been

employed in five projects for three companies (Newton Instruments, Blue Cross Blue

Shield of North Carolina, and Haht Software) within the North Carolina State University

(NCSU) E-commerce Studio [AE00]. As the model is refined, based on the lessons

learned during these five development efforts, it will be further validated during the

development of Web applications at Asea Brown Boveri (ABB).

The remainder of this thesis discusses research directed toward the description of

a risk-based, CMM compatible evolutionary prototyping model; it focuses on such a

model’s ability to circumvent the weaknesses of the “traditional” evolutionary

(17)

mitigation, and CMM tailoring and use. The modified evolutionary prototyping model,

the EPRAM model, is detailed in Chapter 3 along with a description of the CMM

tailoring process used as the basis for the EPRAM model. Chapter 4 presents the results

of validation efforts held to verify the tenets of the EPRAM model. Finally, Chapter 5

highlights the EPRAM model’s research contributions, including the view of EPRAM as

(18)

Chapter 2 A Survey of Related Work

A dwarf standing on the shoulders of a giant may see farther than a giant himself.

Robert Burton

Our evolutionary prototyping model must address several practical issues, which

are discussed below in the context of related work. Section 2.1 provides an overview of

prototyping models, including an in-depth look at evolutionary prototyping processes.

We then focus on the core aspects of prototyping in relation to risk management during

requirements engineering and the Capability Maturity Model in Sections 2.2 and 2.3

respectively.

2.1 A Survey of Prototyping in Software Engineering

Prototyping as a software lifecycle model or lifecycle model phase has been the

subject of much discussion. We now examine many different kinds of prototypes so that

we may better establish the context for an evolutionary approach. This type of approach

specifically supports practitioners as they seek to better manage requirements creep using

(19)

primarily on evolutionary prototyping for software system creation, a survey of other

prototyping categories and reasons behind the rise in popularity of prototyping are also

included for a complete picture of the state of field.

2.1.1. The Movement Toward Prototyping Model Use

Software engineering practitioners, in general, have established certain

‘traditional’ non-evolutionary process guidelines. These guidelines have proven to be

prime candidate steps for guiding the development of quality software. However, there is

a migration occurring on many fronts from non-evolutionary processes to iterative

processes. We demonstrate the movement away from non-evolutionary models using the

replacement of the Waterfall model as one example, in the subsections below.

2.1.1.1. Example: Non-evolutionary Waterfall Process Models

Originally, software development almost exclusively used the ad-hoc,

unpredictable “code and fix” process model. The Waterfall model succeeded this

approach and demonstrated significant improvements in quality and predictability.

Entrenched within the software engineering field, the Waterfall model for system

development has cultivated a loyal following among software developers. In fact, the

Waterfall Model is followed year after year in the software engineering classrooms and

industries throughout the world. According to Sommerville [Som95], this traditional

software development model involves a sequential application of the following phases:

• problem definition – state the problem that is to be solved

(20)

• design specification – define ‘how’ the system should operate

• coding, debugging, and unit testing – develop and remove errors from the actual code

• integration and system testing – verify and validate the code that was developed; test the completed system to ensure requirements coverage

• maintenance – modify and tailor the system after delivery to the customer; fix errors discovered after system delivery to the customer

The Waterfall methodology is more applicable to projects with certain

characteristics. The process lends itself well to systems that embody relatively simple

tasks, the developer does not need specialized domain knowledge to produce the system,

there are low expectations from the customers, the project has well-understood

requirements, or the system concept is stable [Bea99]. This approach is widely popular

with software engineering professionals, and it is engrained in the mindset, experiences,

and history of software creation.

2.1.1.2. Problems Facing Non-evolutionary (Waterfall) System Development

Often, popular non-evolutionary process models, such as the time-tested Waterfall

model, do not provide the complete solution to all software engineering woes. There are

a number of problems associated with non-evolutionary system development:

Growing Costs of Software. The rising costs of software have resulted in

software practitioners employing alternative evolutionary process methods in the

(21)

reported that upwards of 50% of maintenance requests are the direct result of not

having complete or correct specifications during development [Gra89]. In a 1989

paper, Graham addresses the need for some way to combat these errors and their

related costs with techniques that aid in the production of better software system

specifications. Graham specifically recommends prototyping as a means for

improving these specifications.

Requirements Difficulties. The set of requirements is often one of the most

pivotal matters of importance for any software system. The inability to discover

needed requirements and the inability to adapt to changes in user requirements

will mean failure for many software projects. Yet, non-evolutionary models are

often very weak in these very areas [Bea99]. The Waterfall model, for example,

has a strict linearity with regards to requirements discovery, insisting that the

developers create a complete set of requirements up-front. This may lead to the

premature freezing of the requirements [Som95] in which requirements are either

missing, incorrect, or unchangeable.

Lack of User-Centeredness. Oftentimes in the software development process,

neither those who commission the project nor those who develop the project can

truly identify the needed functionality of the system. In more traditional

non-evolutionary approaches, there is a notable lack of user input into and control of

the entire project development [Bea99]. The list of requirements is derived

(22)

representations in order to gain a focus on what they really need from the

delivered product. Successful project completion, however, requires a marked

involvement of those who will ultimately use the system [Gra98].

Difficulty in Revisiting Previous Model Stages. As mentioned above, the

Waterfall model and other non-evolutionary models are structured as linear

sequential models. Iteration can only be done indirectly and causes confusion

when attempted [Pre01]. As a process continues, developers often would like to

revisit previous stages with lessons that have been learned so as to improve the

project, but can only do so with much difficulty, if at all [Bea99]. Sommerville

states that this difficulty sometimes leads to incomplete requirements and design

problems “circumvented by implementation tricks” [Som95].

Lack of Consideration of User-system Interface. Conventional software

engineering process models rarely consider user-system interfaces until the end of

development. Since these interfaces are not available until late in the

development cycle, users have little input into the usefulness and appeal of this

crucial part of the system with which they interact. Many of the problems of

which users complain stem from this very area, and when these problems require

changes, costs escalate. Therefore, various models must be considered in order to

(23)

Miscommunication Between Developers and Customers. Many customers are

uncomfortable with the “huge volumes of text, structured English, screen layouts,

and diagrams which constitute most functional specifications” [Gra91].

Documents found within the non-evolutionary models can be confusing to

less-technical customers and therefore require greater effort to understand; ironically,

these are often the only tools for communication that linear models possess. This,

therefore, solely provides an error-prone communication path between developers

and customers. The communication missteps created as a result reinforce the

notion of the need for a common, understandable language (embodied, for

example, in prototypes) created by other process models.

2.1.1.3. The Need for a New Solution

In a report published by the Standish Group in 1995, one-third of approximately

250,000 development projects were cancelled at a cost of $80,000m. Additionally,

$60,000m was estimated for cost and delivery overruns. Among the reasons given for

these extraordinary figures were listed a lack of user involvement during the projects, a

failure to obtain a clear statement of requirements, and no clear common project vision

and objectives held by the customer, the user, and the developers [Gra98]. As seen in the

discussion above, traditional non-iterative processes find weaknesses in these very areas.

Their shortcomings can be summarized by saying that these models are useful for

producing the planned product, which quite often is not the product that the customer

ultimately wants. While the Waterfall model is just one established non-evolutionary

(24)

such as the Rapid Application Development (RAD) and Formal Methods models [Pre01].

In response to these deficiencies, other methodologies, such as evolutionary prototyping,

have gained acceptance within the software engineering field. In fact, industry and

academia alike have embraced alternative processes – including holding prototyping as a

legitimate process model for software development by placing it among the other ‘valid’

models such as the Waterfall and Spiral Models [Jal00].

2.1.2. Kinds of Prototypes

Much work has been done in the area of prototyping for the purpose of software

system development. The term ‘prototyping’, however, covers a wide variety of

activities – varying in methodology, outcome, and purpose. This section provides a

big-picture overview of different prototyping categories.

Evolutionary Prototyping. Evolutionary development involves iterativly

gathering system requirements, building a prototype, and delivering this prototype

to the customer. The prototype is started from the best-understood requirements.

This process continues, incrementally adding functionality, until the entire system

is completed. There are two main divisions of this practice: vertical (incremental)

prototyping and horizontal (traditional evolutionary) prototyping. In vertical

prototyping, a small, yet complete portion of the system is delivered to the

customer at the end of each iteration. This piece is fully developed and will not

(25)

not yet developed, but does not allow changes to the completed prototyped pieces

[Bea99]. Vertical prototyping is depicted in Figure 2.1.

In horizontal prototyping, the software is fully specified and gradually

refined during the prototyping iterations. This allows the practitioners to

incorporate lessons learned into the system. In this case, requirements can both

be added and changed throughout development cycles. Horizontal prototyping is

depicted in Figure 2.2.

Breath of the Software System

Functionality of the Software

Module

Vertical _Prototype

Figure 2.1: Vertical Prototyping. The vertical prototyping consists of one or more modules developed completely with full functionality. Figure from Nielsen 1993 [Bea99].

Breath of the Software System (Modules)

Functionality of the Software

Module Horizontal Prototype

(26)

In the most general form, Beaumont [Bea99] provides that evolutionary

prototyping follows the prototyping lifecycle as shown in Figure 2.3.

Throw-Away (Rapid) Prototyping. Throw-away prototyping, also sometimes

(and inconsistently) referred to as rapid or quick-and-dirty prototyping, is a

method of developing a customer’s poorly-understood requirements. For this

method, prototypes are developed from the least-understood requirements for

experimentation purposes [Som95]. This type of prototype is not built with

quality up-front, and therefore the prototype is discarded after the experimental

requirements become clearer and have been written into the requirements

specification [Dav92].

“Revolutionary" (Experimental) Prototyping. Graham [Gra91] defines a third

type of prototype known as the “Revolutionary Prototype”. This kind of

prototyping is more along the lines of the disparaged “hacking”. Ideas can be Develop Prototype

Evaluate Prototype Plan Prototype

(27)

in a commercial environment. In actuality, this type is a subclass of the

throw-away prototyping with even stricter controls set in place to guide it.

Operational Prototyping. A new type of prototyping has been created from the

combination of the very dissimilar evolutionary and throw-away prototyping

models. This new prototyping method, called operational prototyping, starts with

an evolutionary prototype being developed for the well-understood requirements.

At the customer site, a user operates this prototype with a trained prototyper

recording any problems the user finds. The prototyper constructs throw-away

prototypes on top of a copy of the existing evolutionary baseline to ‘fix’ the

problems. The new prototypes are again used and any new requirements or

changes are documented to be added to the specification. The throw-away

prototypes are discarded, and the baseline is evolved with the new requirements.

This method combines rapid-development with a quality approach [Dav92]. This

particular method, however, relies heavily on skilled prototypers that must

quickly create throw-away prototypes in the customer’s own environment.

2.1.3. Traditional Evolutionary Prototyping

More and more, as software permeates everyday life, the focus on software

development methodologies increases. It becomes ever more important for software

engineers to know the current state of software development methodologies so that they

can make informed decisions and appropriate choices during the process of software

(28)

evolutionary prototyping, as it covers practices, benefits, and drawbacks as seen in

current trends.

2.1.3.1. Evolutionary Prototyping Principles and Practices

Evolutionary prototyping is the repeated software development process of

gathering user requirements, prototyping the software system, having the user evaluate

the system, and evolving the prototype with the user’s changes. These steps are cycled

through, incrementally adding functionality, until a final system emerges from the

process. In theory, at process conclusion, this system will have incorporated the set of

true user requirements – often more so than the same system developed through other

non-iterative methods. The prototyping described above requires that the developers

build quality prototypes throughout the entire lifecycle. Therefore, as depicted in Figure

2.4, each round of the evolutionary process requires that work be done on requirements,

(29)

2.1.3.2. Benefits Behind Evolutionary Prototyping

Evolutionary development methods arrived on the scene as valid process models

due, in part, to specific problems that arose in the software engineering and software

development fields. Questions such as how to form clear, complete, consistent

requirements in the face of change, how to have the user involved throughout the life of

the project, and how to adapt to customer expectations and modify those expectations

where appropriate proposed specific challenges – challenges to which evolutionary

prototyping is most remarkably suited. The following is a summary of the benefits of and

motivations for using evolutionary prototyping:

Maintain New Prototype

Deliver Customer Evaluation Debugging / Testing Implementation Design

Reqts

Reqt

Doc New/

Changed Reqts Design

Doc

Prototype Project

Planning

Project Plan

New Design New Reqts

New Correct Prototype

Correct

Not Correct

(30)

Clarifies Management and User Requirements. Due to constantly changing

opinions, vague specifications, and indecisive clients, requirements may suffer

from a lack of focus and direction. The direction in which the software should

develop can be very unclear when software engineers employ traditional process

methods. Evolutionary prototyping helps to alleviate this by embodying the

better-understood requirements in a tangible, executable form. Management and

users can see their requirements in the prototyped systems, and therefore can

validate the requirements reflected in the prototype [LSZ93]. By the iterative

nature of the prototype’s evolution, the customer gets the opportunity to accept,

reject, or change the prototype, and in turn, accept, reject, or change the project’s

requirements.

Uncovers Missing or Previously Unknown Requirements. Another benefit

associated with evolutionary prototyping is that of discovering a more complete

set of requirements for a software project. Once a prototype baseline is

established, users can often find additional functions that the prototype must

provide. In [Gra91], Graham presents this ideal facet of the evolutionary process

by claiming that “the key is that prototypes are an excellent means of eliciting

correct, consistent, and complete specifications of requirements.” Through the

use of evolutionary prototyping, developers are able to find out what requirements

(31)

Allows for System Flexibility to Meet Changing Constraints. Evolutionary

prototyping is beneficial to practitioners who are struggling to build software

systems that, by their very nature, are based on constantly shifting assumptions,

constraints, and requirements. Lehman has summed up this problem by writing

that software always encapsulates some assumptions. Some of these assumptions

will be stated in the documentation. Some assumptions will be implicit. As

software is being developed, the world on which the assumptions are based will

change [Leh90]. Evolutionary development models take these effects into

account, allowing the project to adapt to the changes and uncertainties inevitably

encountered in software system creation. In these models, commitments in the

constraints and requirements are only held until the beginning of the next

prototyping cycle, where they can be changed and altered as needed. The

evolutionary model’s adaptability works to promote its acceptability within the

software community. Developers working on particularly volatile projects often

look first to evolutionary prototyping from which to base their project [NC98,

FD89].

Provides a Method Whereby Users, Management, and Developers Can

Communicate about Systems. Graham is a proponent of evolutionary

prototyping for the purposes of facilitating communication between all

stakeholders of the software project. The prototypes produced allow all involved

to have a common ‘language’ from which to speak about the system. There is

(32)

misinterpretations stemming from the often conflicting, ambiguous natural

language specifications seen in the more traditional, non-evolutionary software

development methods. Many stakeholders are also less intimidated by the

presentation of a prototype than by the paper avalanche of specifications, designs,

screen layouts, and diagrams found too often in methods such as the Waterfall

model [Gra89, Gra91, Gra98]. Graham is not alone in his support of prototyping

for communication [LSZ93].

Eases Maintenance. Evolutionary prototyping reduces the effort that the

developers must apply towards maintenance. There is a relationship between the

maintenance gains and the improvement in the requirements gathering process

upheld by prototyping processes. By achieving a clearer, more complete

requirements list (as previously mentioned) during the project development, the

software is more likely to be what the customer actually wants. Therefore, the

developers will have less to change, fix, and clean-up at the end of the software

project [Gra89, Gra91]; thereby reducing maintenance efforts.

Enables Developers to Create ‘Better’ User Interfaces. Interface problems and

difficulties are often the source of complaints from users of many software

systems. As these problems grow so large that they require changes and

maintenance, costs will rise. Prototyping, such as that done during the phases of

(33)

with ways to make the user interface more powerful and easier to use [Gra89,

Gra91]. Prototypes will also assure that the user interface is compatible with the

user requirements [LSZ93].

Encourages Prototyping with Quality. Not all prototypes are the same. There

are various kinds of prototyped systems, each created with differing levels of care

and attention and each possessing varying degrees of quality. For example, unlike

a throw-away prototype, an evolutionary prototype, according to [Dav92], “is

built in a quality manner (including a software-requirements specification, design

documentation, and thorough test).” Royce touts an evolutionary process model

as one in which the quality will not suffer due to rapid bug fixes which are pushed

into the software without valid software engineering practices [Roy90].

Allows Participants to Reflect on Lessons Learned During System

Development. As opposed to the more linear models, traditional evolutionary

prototyping allows developers to take what they have learned and experienced

from the implementation of the earlier prototypes and correct their mistakes and

build on the experiences to gradually refine the software system [Bea99]. This

sentiment is shared among software engineers, as there is a common belief that

“evolutionary models of prototyping take advantage of knowledge acquired as

development progresses [FD89].” Developers can successfully apply

newly-acquired knowledge such as that resulting from a better understanding of the

(34)

2.1.3.3. Evolutionary Prototyping Quality Metrics

Software quality is the measure of compliance with customer and user budget,

schedule, functional expectations, and performance expectations. Practitioners in the

software field strive to build products that have the highest level of quality that is needed.

One common, agreed-upon idea that has arisen is the need to judge the quality levels for

software systems. In this light, software engineers often uphold ease of change as the

most important quality perspective. The idea behind this perspective is that the easier

that software is to modify, the easier it is to gain any other aspect of quality [Roy90].

Since ease of change is upheld as the measure by which software quality can be

judged, evolutionary prototyping and development are at the forefront of process models

for building quality software. Evolutionary development enables its practitioners to

achieve better quality more efficiently. This development model is successful at

achieving quality because it mandates the production of intermediate products that assist

in providing early insight into quality. Evolutionary models also help to eliminate

extensive rework at the end of the project and obtain a stable set of requirements as

quickly as possible [Roy90].

Royce, in [Roy90], proposes that rework (in changed lines of source code) should

be the primary metric to be collected. This rework figure could be helpful in identifying

trends in product attributes both during and after project development. In particular, the

rework measure allows software engineers to investigate modularity, the average extent

of breakage, changeability, the average complexity of breakage, maintainability, the ratio

(35)

2.1.3.4. Evolutionary Prototyping Issues / Shortcomings

As previously discussed, evolutionary prototyping alleviates many of the issues

that practitioners face during the use of other linear development methods. While

evolutionary prototyping has succeeded in becoming an accepted and even supported

software process model, it has succeeded despite having its own set of drawbacks,

difficulties, and shortcomings. Evolutionary development remains a viable and often

best-fit solution for the creation of many software systems as long as the developers

recognize and accommodate for the model’s liabilities. The EPRAM model described in

Chapter 4 employs risk analysis to address the problems of process control and

functionality / requirements creep as mentioned later in this subsection.

Difficult to Control. Software engineers who use evolutionary prototyping often

face a process that seems difficult to manage and control. The prototyping

literature demonstrates that management of evolutionary prototyping is a major

contributor to the building of ‘good’ software [BS96]. Control of this process lies

in solid management practices, as it can be difficult for all stakeholders to agree

on the direction and objectives of the software development. The contents of the

next prototype may also be hard to determine as a number of revisions and

decisions may need to be made by management. Finally, it is often hard to judge

the level of completeness of the prototyped system as prototyped systems often

lend themselves to being either over-evolved or delivered prematurely [BS96].

(36)

being done in the areas of limiting iteration cycles [Gra89, Gra91] and using risk

analysis [BS96] for the purpose of controlling the evolutionary process.

Perception Within Software Engineering Community that Prototyping is

Equivalent to 'Hacking'. In some software engineering circles, prototyping has

become synonymous with ‘hacking’ [Gra91]. Some software engineers view

prototyping as being an unstructured process with low quality and little planning.

Dire warnings abound in certain literature that “prototypes tend to be hacked and

pasted together with little attention to architecture or good programming [CL99].”

Though such statements are meant to discourage the use of prototyping for

development, they actually are somewhat misleading since at their heart, they talk

about evolving throw-away prototypes. In fact, multiple sources, [LSZ93,

Dav92], counsel against the evolution of throw-away prototypes into the final

system. However, [Dav92] praises evolutionary prototyping as having a rigorous

development approach, thereby debunking the ‘hacking’ stereotype.

Project Team Motivation After Many Prototyping Rounds. Graham [Gra91,

Gra98] warns that developers need some indication during the project’s lifecycle

that their efforts are ‘paying-off’. In fact, during some prototyping experiences,

though the system changes, the evolved software never seems to be nearing

completion. This perpetual changing process may become burdensome as

(37)

Functionality Creep Possibility. A major benefit of using evolutionary

prototyping for a process model is that it leads to systems that meet known user

requirements and yet can change to meet the user requirements that are discovered

later. This helps to produce systems that the customers want and need. However,

this, too, can become burdensome as customers often try to continually request

that new features be added – features that will add to development time and costs

[Gra91, Gra98]. Stricter time limits, risk analysis and mitigation (as employed,

for instance, in the EPRAM model described in Chapter 3), and limits on the

number of iteration cycles are sometimes used to mitigate this downside.

Poorly Structured Applications. Traditionally, evolutionary prototypes have

had a certain amount of poor structure associated with them, and this structure

deficiency is mainly the result of the iterative process of the evolutionary model

[NC98]. Often, the structures that result from evolved prototypes are considered

to be inefficient when compared to their linear system counterparts [BS96] since

the software design has a tendency to become corrupted through continual

change. Care must be taken when cycling through prototype refinement processes

so that the design is kept clean.

Lack of Defined Milestones. Another anticipated obstacle presented by

evolutionary prototyping is the lack of defined milestones [Bea99]. As the

(38)

to keep up-to-date or even to create in the first place. Many times, milestones are

not defined due to the constant revisiting of stages of requirements gathering,

design, and implementation. Such practices, while they may make sense for the

prototyped system, reduce process visibility and therefore must be monitored and

controlled carefully [NC98].

Lack of Achievement. Software developers must carefully plan the contents of

each iteration of the evolutionary process. A temptation that arises from the use

of this software method is the ability for developers to procrastinate in an ‘I’ll do

it later’ approach. These system builders gain the ability to put off what should be

in the present prototype until the next one, extending the time and decreasing the

efficiency of evolutionary prototyping as a useful software engineering process

model [Bea99].

Lack of Continued Commitment from Users. End user involvement is a

must-have for any evolutionary prototyping based project [LSZ93]. End users are an

integral part of the process of refining requirements and evaluating prototypes.

They must be involved for longer sustained periods than is traditionally required

by other processes. Users have to be aware of the status of the prototypes and

should know what to expect from the prototypes that they are shown [Bea99].

This is necessary as users sometimes view prototypes as the ‘real’ systems, even

(39)

2.1.3.5. Examples of Systems in Industry Developed Using an Evolutionary Prototyping

Methodology

Evolutionary prototyping is not just a thing of academic study and textbook

reflection. Instead, it has been used countless times in commercial projects. To provide

the reader with a more complete view of evolutionary prototyping as a viable method of

building software, this subsection contains a sample of three such projects of varying

success.

Customer Advice System

In a project documented by Lichter et al. in 1993 [LSZ93], a Customer Advice

System was developed to be the answer to inconsistency of advice given to a public

service organization’s customers and in response to the competition for flexibility in the

market of the organization. It was a sales support system used by sales employees that

allowed for the employees to help configure complex systems that were required to

follow strict legal rules. The system was initialized with a default configuration that was

modified in conjunction with the needs and requests of the organization’s customers

[LSZ93].

Evolutionary prototyping was used for system development for a number of

reasons. The initial prototype assisted the development team in acquiring the project

from the public service organization and in looking at system feasibility. The evolved

prototype provided the core of the system’s functionality, and it helped to evaluate

technical decisions during the project’s completion. Finally, the prototype served in

(40)

The drawbacks of using evolutionary prototyping for this particular system is that

it resulted in a product that had redundant system components. There was a lack of user

involvement that served as a determent for project completion. In addition, poor project

planning resulted in a not-quite-perfect process. Nonetheless, the system was built,

accepted by the users, and put into use [LSZ93].

Planning System

Lichter et al. detail another evolutionary prototyping project in their description of

the Planning System [LSZ93]. The purpose of the Planning System was to aid in the

lengthy manual process of system planning in the heating and plumbing industries. Some

automated tools have been used in these fields, but are generally devoted to performing

single work tasks such as calculating pressure loss. The Planning System was created as

an integrated toolkit to aid these professions by providing united computer support for the

entire planning process [LSZ93].

In order to complete this system, developers used evolutionary prototyping as the

software development process model on which to base the project. The initial prototype

developed for the system showcased the potential of the proposed system to the

customer; thus, it served as a presentation prototype. Also, functional prototypes were

developed and evolved to improve developer-customer-user communication. Finally,

this prototyping methodology assisted the practitioners in performing risk assessment.

As of the cited reference’s publication date, the system was being piloted under a small

(41)

Power Plant Monitoring System

The EDM (Electricidade da Madeira) utility company proposed the Power Plant

Monitoring System, SITINA (Sistema de Telemetria para Instalacões Não

Acompanhadas – Telemetry System for Unaccompanied Utilities), in order to monitor

two automated power plants. The key feature that the system would provide is that it

would collect statistical information on the power plants’ production [NC98].

Since the developers had experience working with 4th generation languages and

their integration with the evolutionary model, they decided to use evolutionary

prototyping as their process model. The benefit that the developers achieved is that they

gained the opportunity to improve upon poorly defined requirements. Additionally, this

paradigm helped to increase user satisfaction with the system, as well.

Problems that were encountered along the way were bothersome, but were

acknowledged and worked-around. There was an explicit need for tools in order for the

project to be a success. This demonstrated the necessity of using CASE tools and 4th

generation languages for some evolved systems. Visibility into the evolutionary process

was reduced, and the prototyping resulted in a poorer system structure as it became

difficult to keep the conceptual models consistent with the changing prototype. Finally,

there was a discernable need for having highly qualified people involved in the

evolutionary process [NC98].

2.1.3.6. Evolutionary Prototyping – Future Practices

The software engineering field must adapt to the ever-volatile technological

(42)

processes to remain useful, they too must undergo modifications and embrace new ideas

and tools. Evolutionary prototyping is no exception, as it benefits greatly from such new

ideas and tools. Included in this subsection is a description of the future outlook for

evolutionary prototyping software methodologies.

Operational Prototyping

Davis proposes a twist on the traditional evolutionary prototyping model – the

incorporation of throw-away prototyping layered on top of an evolutionary baseline. As

previously mentioned, this new prototyping method, called operational prototyping, starts

with an evolutionary prototype being developed for the well-understood requirements.

Practitioners build throw-away prototypes based on the evolved baseline to gather a more

complete set of requirements. The baseline is then evolved with the changes [Dav92] as

shown in Figure 2.5.

Operational prototyping offers a balance between achieving rapid results and

obtaining stability. It develops a set of well-understood requirements and provides the

flexibility for the developer to experiment with poorly-understood requirements.

Operational prototyping also helps to maintain the integrity of the system’s architecture

(43)

Improved / New Use of Tools for Evolutionary Prototyping

There continues to be an increase in the level of technology to assist software

engineers during the use of an evolutionary prototyping process model. As technology

progresses, new ways of mitigating weaknesses of the evolutionary approach appear and

are used successfully. Three such technological advances are Object-oriented analysis

and design methods, CASE (Computer Aided Software Engineering) tools, and 4th

generation languages [NC98].

Object-oriented analysis and design methods have begun to be used during the

evolutionary prototyping process. They benefit prototyped systems by helping to

maintain control of the system structure. They provide a layer of encapsulation and clear

notations so that all participants can be a part of the system analysis. Also, these

object-Evolutionary Baseline

Prototyper _User Evaluate Baseline

Throw-away Prototypes

Create _Evaluate New

Requirements Evolve

Discover and Document

(44)

oriented methods provide the developers with the ability to produce analysis and design

diagrams, thereby increasing the process visibility [NC98].

CASE tools have also provided benefits for evolutionary prototyping for software

system development. Though often domain dependent, CASE tools have helped to

bridge rapid development with the analysis and design phases. These tools enable both

process verification and process validation. They also maintain conceptual models and

measure progress for the system [NC98]. CASE tools have worked to provide a better

environment in which to prototype.

4th generation languages (also known as 4GLs) have accelerated prototype

development (coding, debugging, and maintenance) and increased productivity due to the

abstraction that they provide. When integrated with the CASE tools, 4th generation

languages have helped to prevent prototyping CASE tools from being abandoned after a

period of time. 4th generation languages helped to clear the way for more efficient

evolutionary prototyping [NC98].

2.1.4. Prototyping for Software Development – A Literature Survey

In requirements engineering, prototyping is employed to: generate user interface

prototypes in conjunction with scenarios [EKK99]; support walkthroughs with

stakeholders to elicit and validate requirements [Sut97, SR98]; eliminate ambiguity,

incompleteness, and inconsistency during requirements capture [ABR94, RL93]; and

incrementally replace specifications with implementations [OS94].

(45)

various levels of lack adequate support for requirements evolution and risk management.

Baskerville et.al. advocate risk analysis for controlling the evolutionary prototyping

process [BS96] since it provides developers with the risk management support needed to

control the evolutionary prototyping lifecycle. As discussed in depth later in this

document, Baskerville and Stage describe a four-step procedure to aid developers as they

focus on risk. The four steps are: define the risks, evaluate the risks, assign priorities to

the risks, and resolve the noteworthy risks. Their work touts risk analysis as the solution

to the “main unsolved problem in prototyping” – the difficulty of controlling the

prototyping process [BS96]. Unfortunately, Baskerville et al., do not address the use of

risk mitigation to solve another evolutionary prototyping problem – functionality and

requirements creep.

Walker Royce stresses the importance of quality metrics such as flexibility and

ease of change throughout the life of a software project [Roy90]. This can be especially

meaningful in prototyping environments such as operational, iterative, and evolutionary

prototyping as they provide tangible products that practitioners can use for getting early

feedback about the quality of the products that they are producing. Royce claims that

there are conventional techniques for gauging functionality, reliability, and performance,

but there are no accepted methods for looking at the flexibility of the system including

modularity, changeability, and maintainability. He proposes that metrics should take the

form of various “rework” measures that are variants of the number of changed lines of

source code in software system baselines [Roy90]. We concur that such metrics are

valuable for measuring an evolutionary process and propose the study of such metrics

(46)

Davis notes the advantages of evolutionary prototyping, such as built-in quality,

as well as the pitfalls, including the inability to quickly implement experimental features

[Dav92]. In this work, Davis outlines operational prototyping as a mixture of

evolutionary and throw-away prototyping. He states that operational prototyping results

in “rapid development of experimental features while providing the highest standards of

quality control, configuration management, stability, and robustness [Dav92].”

Ian Graham summarizes the various prototyping approaches of evolutionary,

revolutionary (throw-away), and revelationary (research) prototyping [Gra89, Gra91].

Systems that benefit from evolutionary prototyping are those systems in which the target

programming language is the same as the prototyping language and requirements are

forecasted to quickly change on a regular basis [Gra91]. He does not advocate the use of

prototyping in place of good software engineering practices, but asserts that prototyping

should be accompanied by such practices. According to Graham, project management,

milestone scheduling, deliverable completion, and task decomposition should be included

within the prototyping process model. Graham addresses the need to balance customer

wants versus customer needs, creeping functionality, maintenance of project team

motivation during the cyclical process, and the reduction of implementation shock

through user involvement [Gra91, Gra98]. With respect to creeping functionality,

Graham promotes the use of a time box to limit the time and tendency of the customer to

make significant changes in the scope of the system. This thesis advocates a more

cooperative negotiation and communication between the customer and developers during

(47)

evolutionary prototyping to more readily adapt to requirements changes in a controlled

manner.

2.2 Managing Risk During Requirements Engineering

Risk management during iterative software development is a key factor for

project success [BS96]. However, managing risks during the software lifecycle and, in

particular, during requirements engineering activities, is especially challenging in rapid

development environments. Boehm’s Spiral and Win-Win models have explicit risk

resolution sectors that serve to manage risks [Som95, BI96], though such spiral models

have their critics. These types of cyclical models have been discredited as being “wound

up Waterfall models” which are just as inappropriate for fast-paced development as the

Waterfall model, itself, [Gra98] as discussed earlier in Chapter 2. Hall addresses

identification, analysis, resolution, mitigation, and management of software risks in

[Hal98]. Risk management is also employed within the context of aligning e-commerce

application requirements with corresponding security and privacy policies [AE01,

PFI99].

The EPRAM incorporates the risk and compliance assessment activities of

[AE01] and the risk identification and ranking processes of [BS96] to form a

comprehensive risk mitigation strategy. Additionally, many industries use decision

making business models to manage risk during the development phases of a product. For

example, ABB (Asea Brown Boveri) uses a phased business decision-making model to

minimize the risk that a development cycle will spin out of control [CAD01]. This

(48)

that represent Go/No-Go (Stop/Change) decision points. The model serves to ensure that

a customer will receive a high-quality and high-value product at release time. The Gate

Model allows for a common terminology within the corporation for product development,

especially when several components (hardware/software) must be integrated into a final

product. A gate in the model represents a decision point to determine whether to

continue or terminate a project based on its benefit, status, risk, resource, and technology

considerations. The diagram in Figure 2.6 represents the objectives of progressing from

one gate to another during a product development cycle. When a project begins, the level

of risk and fuzziness is very high and, ideally, as the project progress proceeds through

the gates, the level of risk decreases. Conversely, as the project evolves and moves

through the gates, the level of knowledge and maturity in the project team increases.

Successive refinements to the EPRAM model have involved adaptation to this gate model

to facilitate its adoption by ABB.

2.3. Tailoring the Capability Maturity Model

A growing number of software organizations are turning to the CMM as a viable

mechanism to build quality into their software processes [JB97]. The CMM was

specifically designed for large government contracts; yet, it embodies basic principles

that are applicable, to some extent, to all software development projects. Small

organizations, however, are experiencing difficulties in adopting the CMM due to lack of

resources, tools, and training [OC99]. Customization is often required to support the

(49)

In fact, some practitioners have tailored it to fit smaller, non-traditional organizations

[KHT00, OC99] with mixed results. What is certain is that such tailorings are required

to support the smaller team structure found in common rapid development

environments. This thesis extends the tailoring process to cover small (fewer than 13

individuals) electronic commerce development teams.

Consider Winapp, a company of five employees that develops PC based client

server software applications. Winapp has attempted to improve its software process

maturity. The company was facing increasing difficulty tracking projects, requirements,

and resources as the number, size, and complexity of the projects that it was undertaking

grew. Winapp looked to the CMM for guidance for their process improvements, but

found the CMM a bit overwhelming. Winapp initially experienced difficulties in

adapting the CMM to meet their specific needs for several reasons, including their

inability to support the amount of required documentation, their lack of resources (as

called for by the CMM), and the fact that their flat team structure was not accounted for

in the CMM. To remedy this, the company extracted the applicable concepts of CMM

0 10 20 30 40 50 60 70 80 90 100

b e f o r e G 0

G 0 G 1 G 2 G 3 G 4 G 5 G 6 G 7

Risk, Fuzzyness D e p t h o f K n o w l e d g e %

Figure 2.6. Levels of Risk and Knowledge in the Gate Model.

(50)

process improvement and established an improvement framework according to selected

key process ideals. Despite the overhead incurred, the creation of a CMM-inspired

framework at Winapp yielded the perception of significant improvements among the

developers; developers perceived an improvement in the requirements analysis activities

of 157% and a decrease in the number of requirements faults by 57% [OC99]. While

these figures are, admittedly, subjective, they are indicative of a need for process

improvement and guidance within small organizations. In fact, the catalyst for our work

was our analysis of five such teams within Asea Brown Boveri during the Summer of

2000. We observed that many “small” development efforts were evolutionary in nature,

yet they lacked rigorous support for the Key Process Areas of the CMM, such as

requirements management and project planning. We, thus, tailored the CMM, to more

appropriately support the demands of such efforts and used that tailoring as the basis for

the EPRAM model.

2.4. Summary

This chapter presented an overview of prototyping for software development. It

described background research as it pertains to prototyping, risk mitigation, and CMM

tailoring. Chapter 3 presents the modified evolutionary prototyping model, the EPRAM

model that we have developed to reap the benefits offered by traditional evolutionary

(51)

Chapter 3 The Evolutionary Prototyping with Risk Analysis and Mitigation

(EPRAM) Model

Those who make peaceful evolution impossible will make violent revolution inevitable.

John F. Kennedy

To demonstrate the effectiveness of the EPRAM model and its ability to manage

requirements creep, we first define the model and its subsequent phases. As discussed in

Chapter 2, traditional evolutionary prototyping models encompass phases involving

requirements engineering, design, coding, testing, customer evaluation, and enhancement

reporting [Dav92]. The EPRAM extends this traditional approach by incorporating risk

management, particularly as it pertains to e-commerce systems, while imposing

adherence to the Level 2 KPAs in the CMM.

3.1. The EPRAM Model Process

This section provides an overview of the EPRAM model, shown in Figure 3.1. In

this figure, rectangles represent process activities, dog-eared boxes (pages) indicate

documentation artifacts, thicker arrows represent major control flows through the

(52)

arrow depicts the risk mitigation process maintained throughout the lifecycle. In this

discussion, there is a focus on the requirements activities – specifically, those

requirements activities that are unique to our evolutionary prototyping model, as we show

Government Policy Identification of Risk

Mitigation Strategies

Reqts. Gathering / Integration

Delivery to Customer Risk Analysis

Maintenance Customer Evaluation Implementation

Debugging / Testing Design

Project Planning Project Plan Design Doc. Reqts Doc. New or Changed Reqts Security Policy Consolidated Requirements New Design New Prototype Correct Prototype Acceptable Evaluation Prototype

Non Acceptable Evaluation

Risk Mitigation and Management for the Prototyping Cycle

Existing Design

Updated Design Existing Requirements

Updated Requirements

New / Changed Reqts

Policy Data

New / Changed Reqts Existing Prototype

Newly Updated Prototype Updated Prototype

Existing Project Plan

Updated Project Plan

KEY Documentation Process Activity Risk Mitigation Data Flow Process Flow activity Privacy Policy Negotiated Requirements Risk Doc. Existing Risks Updated Risks Existing Requirements

(53)

how the EPRAM model works to counterbalance the possibility of requirements

(functionality) creep.

The project plan is created during the initial prototyping cycle and must be

maintained throughout the life of the project. A scaled-down set of project planning

sections are recommended in order to reduce the overhead of unnecessary over-planning;

yet, we acknowledge that at a minimum, some documentation must be in place to control

and shepherd the project. It is for this reason that the templates that we provide

developers focus on the most essential aspects of project management. To that end,

templates developed for the model include a core group of project planning sections such

as roles, schedules, and responsibilities. As schedules, personnel, roles, responsibilities,

project descriptions, or related documents are changed, created, added, or deleted during

the course of the project, the project plan should be updated to reflect the modifications.

During each prototyping cycle, requirements are reevaluated for completeness,

consistency, understandability, and compliance with any overriding policies. The

requirements considered during each iteration may stem from many sources including,

but not limited to, previously established requirements, policies (e.g. security and privacy

policies [AE01]), stakeholders (customers, users, and developers), organizational

responsibilities, other systems, or additional projects. Requirements are agreed to during

a negotiation process stemming from the risk mitigation discussion; the agreed-to

requirements are then integrated to the requirements documentation and are reflected in

each subsequent prototype release.

As is the case in most software processes, design of new prototype releases occur

(54)

revised prototypes. The architectural design, subsystem and module specification, file

structure, global data, and interface design are revised and minimally documented as

necessary to ensure a solid system design and prototype structure. The existing design

document, if there is one, is also updated to reflect these changes.

During implementation, the older, antiquated prototype is modified to fulfill the

new requirements and reflect the new redesign. The implementation, and indeed the

entire EPRAM evolutionary prototyping process, is based upon horizontal prototyping

where, as discussed in earlier sections, the software is fully specified (to the extent of the

level of understanding of the best-known requirements) and gradually refined during the

prototyping iterations. This allows practitioners to incorporate lessons learned into the

system. As the components of the prototype are implemented, they undergo unit testing.

These components are then integrated and the retooled prototype is tested once again to

remove errors.

At the end of each prototyping cycle, the stakeholders are shown the newly tested

prototype so that they may judge whether or not it meets their expectations. At this

juncture, if the customer is satisfied, the project is deemed successful and no additional

iterations are necessary; the system is delivered and the project may then wrap up. If,

however, there are areas that are not addressed by the prototype, or the prototype must be

modified in some way, the new requirements generated during customer evaluation are

recorded and a new evolutionary prototyping cycle begins. Obviously, this iterative

approach all but invites requirements creep, which we manage via risk analysis and

EPRAM: A Risk Analysis and Mitigation-Based Evolutionary Prototyping Model for Quality Requirements Development.

EPRAM: A Risk Analysis and Mitigation-Based Evolutionary

Prototyping Model for Quality Requirements Development.

EPRAM: A Risk Analysis and Mitigation-Based Evolutionary

Prototyping Model for Quality Requirements Development.

Personal Biography

Acknowledgements

Table of Contents

List of Tables

List of Figures

List of Symbols and Abbreviations

Glossary

Chapter 1

Introduction

Chapter 2

A Survey of Related Work

Chapter 3

The Evolutionary Prototyping with Risk Analysis and Mitigation

(EPRAM) Model