S Ra P A Concurrent, Evolutionary Software Prototyping Process

S-RaP: A Concurrent, Evolutionary Software
Prototyping Process

Xiping Song, Arnold Rudorfer, Beatrice Hwong, Gilberto Matos,
Christopher Nelson

Siemens Corporate Research Inc. 755 College Road East,
Princeton, NJ 08540, U.S.A.
{xiping.song, arnold.rudorfer, beatrice.hwong, gil-
berto.matos, christopher.nelson}@siemens.com

Abstract. This paper defines a highly concurrent, software rapid proto-
typing process that supports a sizable development team to develop a
high-quality, evolutionary software prototype. The process is particu-
larly aimed at developing user-interface intensive, workflow-centered
software. The Software Engineering Department and User Interface De-
sign Center at Siemens Corporate Research (SCR) have successfully
practiced this process in prototyping a healthcare information system
over the last year. We have evolved this agile, iterative software devel-
opment process that tightly integrates the UI designers and the software
developers with the prototype users (e.g., marketing staff), leading to ef-
ficient development of business application prototypes with mature user
interfaces. We present the details of our process and the conditions that
make it effective. Our experience with this process indicates that proto-
types can be rapidly developed in a highly concurrent fashion given a
stable prototyping software architecture and access to readily available
domain knowledge.

1 Introduction

Rapid software prototyping is an effective way to facilitate communication among the
customers, the requirement engineers and the marketing staff by providing them with
an executable, intuitive representation of a target system. Prototyping is an effective
approach to evaluate and refine software requirements [4][5][6][7]. Prototyping is
also used to aid the communications between the company’s marketing team and
potential customers, promoting the advanced features of the product and gathering
customer feedback. It helps to gain early customer buy-in for novel product ideas.
A software prototyping project can be “throwaway” or evolutionary. The throw-
away prototyping normally has a short duration and the software code will not be
reused for the corresponding product. The evolutionary prototyping has a potential to
mature a prototype into the final product and thus it needs to be of high quality and
with a software architecture that is compatible with the product software technolo-
gies. In this paper we define a rapid software prototyping process that is aimed at

developing the evolutionary software prototype and can be applied during the early
phases (e.g., Requirements, Analysis and Design of RUP [10]) of the software prod-
uct development. We describe the process with sufficient detail so that other organi-
zations can apply this process as well. This process will be referred to as S-RaP
(Siemens Rapid Prototyping) throughout this paper.
A number of rapid prototyping approaches (e.g., agile modeling and software
development methods (e.g., Extreme Programming [9]) [5][8], RAD [4])) have been
described in the past. Agile methods usually emphasize involving the product users in
the prototyping, and encourage a rapid users-to-developers feedback cycle. Project
management and tracking are often not emphasized by those methods. Some agile
methods rely completely on using experienced developers.
S-RaP is similar to Extreme Programming (XP) method [9] in that it uses a story-
board (XP uses a similar idea called Story Card) and extensively involves product
users during the development. Our contribution is that S-RaP is a unique and effec-
tive approach that provides specific details for concurrent and iterative prototyping of
certain kinds of software applications within certain project constraints. Those appli-
cations and project constraints are

• High software quality within short development life cycle (a few weeks or
months): Some of the quality attributes could be reliability, customizability, us-
ability, and code maintainability. In the projects where S-RaP was originated, the
company’s marketing team planned to use the prototype to communicate with
customers at pre-scheduled dates. Thus prototypes need to demonstrate an overall
high quality. Because the prototype is required to be highly customizable and
high fidelity, “throwaway” prototyping that is built upon hardwired code and
scripted scenarios is not acceptable.
• Support the visibility of project progress: The effort for which this process
originated is to deliver a prototype for a major trade show. This is different from
many other prototyping efforts that are only for technology evaluation or for a
few potential customers. Thus, project management must be able to evaluate the
project progress and manage the risk effectively.
• Workflow driven: The targeted prototype is viewed as a piece of software sup-
porting a set of workflows. A workflow within the scope of this paper refers to a
sequence of users’ UI interactions to achieve a certain business function. For ex-
ample, checking in the patient with the use of a healthcare information system
would be a workflow. Use-case refers to a specific instantiation of the workflow.
For example, checking in a particular patient (e.g., John Smith) would be a use-
case.
• The architecture of the prototype is largely known in advance. Particularly,
S-RaP is aimed at software applications built upon n-tiered web application ar-
chitecture. With a known architecture at the start of prototyping, the prototyping
process can be more focused on the implementation of specific user require-
ments.

• Use of inexperienced developers: The project where this process originated was
a series of short-term contracts between SCR and a Siemens company. Due to
fluctuations in development resource needs, SCR had to engage quickly new de-
velopers. Even if the developers had advanced development skills, they were un-
familiar with the application areas (e.g., medical financial calculation, hospital
bed management). Thus the process needs to facilitate their application knowl-
edge ramp-up through early exposure to relevant concepts.
• Ill-defined requirements: The initial requirements from the users are unclear
and the developers also need time to acquire domain knowledge. However, the
business application has been in practice for a long time (e.g., the healthcare fi-
nancial applications).
• Emphasis on UI interaction: A mature and intuitive UI is a key acceptance
criterion for most software systems. Evaluating alternative UI designs for the
software prototype is a key activity.

From the above characteristics, we can see that S-RaP does not have some charac-
teristics and constraints required by other agile methods. For example, some agile
methods require using experienced developers while S-RaP is designed to use inexpe-
rienced developers. S-RaP is also aimed at supporting the development of the soft-
ware with specific architectures (i.e., n-tiered, MVC based architectures).
Initially, in our early use of S-RaP, we laid out this process as a project plan that
included the definitions of the concurrent activities and key reviewing activities. In
this paper we will define the process in detail, following the process engineering
approach as suggested in [2]. First we define the requirements in Section 2 for the
process and then in Section 3, define the process. Finally, in Section 4, we will dis-
cuss our experiences with S-RaP, specifically how we used and managed this process
to carry out a successful project.

2 Process Requirements

Because of the prototype characteristics targeted by S-RaP as described in Section 1,
S-RaP must provide the following support (note that in this paper the user is often
referred to the people who will use the prototype to define and validate the product
requirements, such as marketing staff or requirements engineers):

• Support high concurrence in a sizable project team: It must support a sizable
development team (e.g., 20-30 developers) working on the prototype in parallel
to facilitate a quick delivery. This is one of the unique requirements of our
process since many of the software prototyping activities tend to be at small scale
and performed with a small team (5-6 developers). The parallelism could be
achieved in a number of ways; the activities of same kind (e.g., UI design) are
performed concurrently on the different portions of a prototype, or the activities

of the different kinds (e.g., UI design and UI implementation) are performed on
the same portion of the prototype.
• Enable user involvement: because of the vague initial requirements, the process
must involve the users in making all the requirements decisions and approve ma-
jor UI designs.
• Allow iteration: Since the requirements are not well defined, the users and UI
designers must see the prototyped behaviors to be able to adjust the existing re-
quirements and UI design. Thus, the process must be iterative enough to allow
continuous changes to the user interface and system behaviors.
• Promote cooperation between UI designers and developers: In order to avoid
miscommunication between UI designers and software developers, the process
should foster quick feedback on feasibility and usability between these two
teams.
• Sufficient documentation: Due to the short development life cycle, it is not
possible to develop extensive documents since that would create too much over-
head for the project. The document should be just sufficient to ensure that the
prototype is delivered with the correct UI look-and-feel and behaviors.

3. Process Definition

Figure 2 uses a basic flow chart to define the S-RaP process. The process starts from
the top-left corner and finishes at the bottom-right corner. From the project planning
and tracking point of view, it consists of three phases. Thus, the project management
can evaluate the project progress based upon the numbers of workflows that are being
mainly developed in each phase. However, from the development point of view, the
activities are performed concurrently through those three phases. For example, the UI
Design Phase and the Prototype Implementation Phase are largely carried out in par-
allel.
The solid-line objects in the diagram are the steps as we defined in our plan of the
project where the S-RaP process was originated. The major outputs of the process are
the prototype and the storyboard that contains the prototype requirements. The proto-
type requirements can be used as the initial requirements document of the corre-
sponding product. Each workflow will be implemented by using this process. Thus,
at one point of the project, there can be a number of instantiations of the S-RaP proc-
ess that concurrently develops a number of workflows.

3.1 UI Design Phase

The user interface design begins with the initial understanding of the workflow and
prior experience in developing similar functions. The UI designer will carry out this
activity with extensive involvement of the users and limited participation of the soft-

ware engineers who will be implementing the user interface. This activity requires a
varied number of meetings with the users depending on the different complexities of
the targeted workflows. This activity will deliver a document called a storyboard that
defines each workflow (e.g., check-in of a patient for a healthcare information sys-
tem). The storyboard is a Microsoft PowerPoint document. The first page is a text
description of the function that the workflow achieves. The next page is a diagram
(e.g., a flowchart-alike diagram) of the workflow. Following the diagram, each page
of the storyboard defines one screen shot of the workflow. The interactions and be-
haviors embedded in the screen shot are described in the notes area of the document
(see Figure 1). A storyboard is an evolving artifact, initially based upon the ideas
from the users. However, it will be further refined during the user reviews (either at
UI design or UI implementation level) or during the requirements meetings with the
users. Since this activity attempts to describe dynamic system behaviors with static
screen shots and English, the workflow description in the storyboard is likely incom-
plete, at least at the beginning of the documentation. However, the storyboard will be
further refined and completed along with the maturing prototype throughout the S-
RaP process. The finished storyboard contains both the prototype requirements and
the UI design.
The UI design can start with an existing preliminary style guide to ensure design
consistency. The use of such a style guide can make the UI design and communica-
tion with users more effective and efficient. For example, a modification to the UI
design can be consistently applied to other similar UI designs via the style guide. The
consistent naming of the UI presentations will make the communication easier. How-
ever, it is also understood that prototyping will enhance the style guide, so the style
guide becomes a deliverable of the prototyping as well.

Figure 1. Sample page from the storyboard

A long and complex workflow can be divided into two or more sub-workflows to
enable multiple UI designers to work concurrently on the same workflow.
Activity Review with Users ensures that all the major users are satisfied with the
user interface and the system behaviors. The main user contact must approve the UI
design as sufficiently complete so it can be final-reviewed by all the major users. All
the major stakeholders will attend this review and decide if the storyboard will be
approved. This activity is largely a requirement activity that is focused on the UI
look-and-feel and correct interaction sequences. Due to the limited meeting duration,
the meeting can be focused on only the important requirement issues. The review
meeting will not verify all the behaviors of the workflow with the users.

Initial
Requirements

UI Design Not Approved

UI Design

UI Problem, not approved UI Design Phase

Storyboard
Review w/
(per workflow)
users

UI Design Approved

Prototype
Implementation
Impl. Not Approved Phase

UI Review w/
Implementation users

Data (Model)
Design/
Implementation

Application
Service Testing Not Passed
Development

System
Integration/Bug Testing Passed
Testing
Fixing

Test Not Passed

Acceptance
Acceptance Testing
Testing
Phase Finished

Figure 2. A diagram illustrating the S-RaP prototyping process

3.2. Prototype Implementation Phase

3.2. 1. UI Implementation

The UI Implementation activity starts as soon as a portion of a workflow’s storyboard
has been developed and its basic layout is relatively stable (e.g., about 30-40% fin-
ished). It is not necessary to wait until the storyboard is completed. Implementers can
first start implementing the most stabilized UI designs. This enables a high parallel-
ism between the UI Design and the UI Implementation. The UI Implementation activ-
ity delivers an executable, interactive user interface of the prototype, possibly using
mock-up data. This ensures that the workflow appears realistic, and thus users can
easily review the workflow’s dynamic behaviors before completely validating more
detailed prototype requirements.
For inexperienced developers, this activity can be started even earlier to allow the
developers to have extra time to become familiar with the prototype architecture.
What they develop during this period of time will likely be extensively modified later.
The Review with Users activity of the UI implementation cannot be started until
the UI Design Review is finished. This ensures that the validation of the dynamic
aspect of the prototype requirements can be based upon the validated static aspect of
the prototype requirements. It is possible that the implementation will reveal areas of
improvement in the UI design (e.g., missing required interactions for users). This
would lead to an extra UI design iteration. However, if the UI design change is minor
and does not require changing the requirements, this will not cause an additional UI
design review. Since at this point the prototype is interactive, the users will be able to
see some complete interactive use-cases of the prototyped workflow. Thus, the re-
quirements can be further refined and more completely validated with users. For
example, for “checking-in patients into a hospital” workflow, since it is interactive
and the users can actually execute it, the working prototype can ensure that the UI
design is complete at least for one use-case (for a particular patient) of the workflow.

3.2.2. Data Design and Implementation

Unlike a “throwaway” prototype that completely relies on mock-up data, the evolu-
tionary software prototype needs to use realistic data and the data changes should
remain realistic after being accessed and modified by the users. The data design can
consist of two parts. One is the data model and another is the actual data value set that
will be stored in the data model. Since S-RaP is aimed at supporting evolutionary
prototyping, it needs to support the data design and implementation.
To support highly concurrent processes of refining requirements of UI look-and-
feel, dynamic UI interactions and the data changes, S-RaP can start the data model
design once a few of the storyboards are initially defined. The data designers can
analyze the UI designs to understand what data needs to be accessed and modified. In
addition, by analyzing the prototype behaviors specified in the storyboards, the data
designers can better understand the relationships among the different data. Based
upon this understanding, data designers can develop a data model that can be con-
verted into a database design and a data access layer (e.g., Java classes) that supports
the direct access from the UI implementation. During this activity, the data designers

will discuss the data requirements with users as well to gain an overall understanding
of the requirements across multiple workflows.

The data design is the second task of this activity. This task is to ensure that the
data values are realistic as well as sufficient for exploring a variety of interesting use-
cases that would use the varied data values. It will identify a basic data set (e.g., the
patient demographics data) and the rules that govern which data should be allowed to
appear in certain workflows. Such rules depend heavily on the application domain
knowledge. Thus, the development of those rules requires the communication with
the users.

3.2.3. Application Service Development

This activity develops the application services that support the prototype behaviors.
The application services support the business logic that can be shared among a num-
ber of workflows. For example, it supports the calculation of a reimbursement for a
patient. Starting this activity early gives the developers extra time to gain the domain
knowledge required for implementing the services. This activity is started immedi-
ately after a few storyboards are initiated. The developers for this activity must dis-
cuss with the users the requirements for the behaviors of the services they will im-
plement. With an in-depth understanding of the application service requirements, the
service application developers can provide useful inputs to the data model designers
for how the data should be structured to effectively support the data accesses from the
application services.

3.2.4. Integration and Bug Fixing

This is the final activity for each workflow to be developed. During this activity, the
developers will integrate the UI implementation code and application service code.
The developers may need to implement the UI/data interface code to facilitate the
data support for each UI (e.g., forms in the Struts architecture [3]). The developers
will unit-test the developed workflow against the corresponding storyboard. This is
often teamwork between the developers who are involved in the previous activities
such as Application Service Development and UI Implementation development.
Sometimes, if the data model needs to be changed, it will require the participation of
the data designers.

3.2.5. System Testing

The system testing is to test the functional behaviors of a workflow after it has been
fully integrated with all the required business logic and persistent support. It differs
from the “unit testing” in: 1) it is carried out by testers who do not implement the
particular workflow being tested, and 2) it will formally report the defects which will
then be tracked by project management and the test lead. The storyboard is used as
the testing script for verifying the prototype behaviors. At this stage, the testers verify
the prototypes against the storyboard for every detail.

3.3. Acceptance Testing

The prototype users will carry out the acceptance testing. The users are the people
who will demonstrate the prototype to their customers for the proposed new product
features. Like the system testers, the users use the storyboard as the requirements to
verify the prototype behaviors and the user interface compliance. Since the users have
previously approved the storyboard, there should be little disagreement between the
testers and the implementation team as to whether the prototype UI and behaviors are
implemented correctly. Acceptance testing can be viewed as a final step to validate
the actual requirements, since the users will perform the testing, based both on the
storyboard and their understanding of the application domain.

4. Experience

In using this process, we developed a healthcare information system. The proto-
type has the attributes as we described in Section 1. Specifically, a Siemens market-
ing team planned to use this prototype to communicate with Siemens customers on
proposed features. The initial requirements of the prototype were based upon their
existing understanding of the customer needs and their knowledge on the prior similar
products. Prior to our prototyping effort, a large portion of existing understanding of
customers’ needs was neither well documented nor organized in a way to support
product development. Thus, our prototyping activity had two goals: 1) To develop the
prototype that is a marketing and requirement solicitation tool for the marketing team,
2) To formulate the product requirements elicited from the Siemens customers in an
organized and tangible manner.
The prototype consists of 6 workflows and each workflow was specified with a
storyboard that has on average about 25 screen-shots. The prototype is required to be
customizable; the data displayed in the prototype UI can be customized for different
customer audiences. The business rules can be added or modified to enforce the
prototype data compliance. The schedule for the delivery was very tight and firm (we
needed to deliver the prototype in four months) while the prototype was required to
be extremely reliable and with high look-and-feel quality. Our development team had
on average 20 staff members throughout the project duration.
By using S-RaP, we finished the project even a little earlier than the scheduled de-
livery dates even though at the start, the project was considered as highly risky for
delivering on time. The project size in terms of the number of requirements, projected
lines of implementation code, and number of team members all exceeded those of our
prior projects. Our success in applying the S-RaP process concurrency indicates that
concurrent and iterative prototyping is highly effective for the development of a large
software prototype within a short development life cycle. In the following sections we
discuss our observations in detail.

4.1. Progress Visibility

The following diagram provides a combined snapshot view as the project manager
evaluated the project progress. Note that this is not a view directly shown by the pro-
ject-planning tool (i.e., Gantt Chart), but rather a project progress envisioning by the
project manager based upon the executing project plan. The span of each box indi-
cates roughly where the major activities for each workflow fall. For example, the
diagram shows that Workflow 1 was finished while Workflow 6 was being developed
in parallel in both UI Design and the Prototype Implementation phase. After a work-
flow development had completely been moved from one phase to another, the project
manager will know most of the work in the past phase had been finished. The span of
a specific workflow across multiple phases (for example, Workflow 5 is in UI Design
and Prototype Implementation) indicates that the activities of both phases are still
taking place. The implementation phase will be under way for the data and service
aspects, or for the parts of the UI whose UI design has been matured and approved.
The S-RaP process provided the project manager with four checkpoints to evaluate
if a workflow has passed certain development phase: 1) ”UI Design Review with
Users”, 2) “UI Implementation Review with Users”, 3) Problem list from System
Testing, and 4) Problem list from the Acceptance Testing. 1) and 2) are two very
specific activities that will either approve or reject the reviewed artifacts Thus, they
provided clear information for the project manager about the progress. Since the
problem lists describe specific defects of the prototype found at certain dates for each
workflow, they were very informative for evaluating the project progress.

Project Progress

Acceptance
UI Design Prototype Impl. Finished
Testing

Workflow 6 Dev.

Workflow 5 Dev.

Workflow 4 Dev.

Workflow 3 Dev.

Workflow 2 Dev.

Workflow 1
Dev.

Figure 3. Project progress envisioning

4.2 Concurrent Prototype Development

We successfully applied the S-RaP concurrency as we planned. Our experience how-
ever indicates that the concurrent activities should be highly interactive among the
different teams (e.g., UI design and UI implementers). Those interactions can trigger
the iterations of the activities in a more timely fashion. For example, the requirements
of different system aspects (e.g., UI look-and-feel, and the dynamic interactions) were
developed concurrently. However, once an initial working prototype was created, the
detailed UI interactions and data behavior provided by the prototype affected the UI
design again. Reviewing the UI prototype provided an opportunity for users to itera-
tively refine their UI requirements with the developers. To reduce the time spent on
those team interactions, a representive member of one team can participate in the
requirement meetings of other teams.
One major issue for the concurrent development is that the concurrent activities
can cause substantial rework that outweighs the time gains from the activity execu-
tion concurrency. We addressed this issue by allowing the dependent activities to be
carried out only on the stable requirements. Thus, the activities can speed up the itera-
tive refinement of requirements rather than cause a complete rework of the require-
ments. For example, a storyboard draft in our project had over about 40 screen-shots
that define UI and interactions. We started the UI implementation on the first 10
screen-shots that were relatively well defined. Thus, while the UI designers worked
on the other slides, the developers implemented the first part of the workflow and
provided the UI designers with feedback more quickly than if this had been done in a
linear order.
Our experience also shows that concurrent development requires a centralized co-
ordination, so the requirement changes can be managed to ensure their consistency
across different workflows. In our project, there were three to four workflows being
implemented concurrently. The project lead tracked the issues coming from the dif-
ferent teams and coordinated some unified approach to address those issues that can
be about the implementation techniques or prototype requirements such as the consis-
tent system behaviors. For example, two different workflows allow users to enter the
data. However, when to save the data can be an issue (e.g., immediately after the data
is entered, or after the “OK” button is pressed). Sometimes, whether we should keep
the behaviors consistent depended on different application purposes. The identifica-
tion of these sorts of issues sometimes led to a team meeting or a meeting with users
to resolve the unclear requirements that can have a global impact on multiple work-
flows.
Another important benefit of this process is that it supports incremental delivery to
users. One major issue in our project was that if we delivered the prototype exactly on
the scheduled delivery date, the users would not have enough time to acceptance-test
the prototype. The incremental delivery supported by S-RaP process very effectively
solved this problem since the incremental delivery involved the users in the concur-
rent development process. In our project, the system-tested workflows were packaged
into a number of groups and then delivered to users incrementally. Thus, while the
other workflows were still being developed and system-tested, the users were able to
acceptance-test the delivered workflows. The early acceptance testing also provided

the development team sufficient time to fix the bugs, which would be impossible if
the process were completely sequential and the delivery were not made incrementally.

4.3. Start System-Testing Early

One important factor that contributes to the successful use of S-RaP in this project is
to start the system testing early. As soon as the integration for a workflow was stable,
the system testers started the system testing for this workflow. Sometimes, for a long
workflow, the system testing can be started on a finished portion of the workflow.
The system testing helped identify quite a few problems that were not identified dur-
ing the UI Implementation Review. Partially, it was due to the fact that the UI Imple-
mentation Review is more oriented towards the requirements validation, not the sys-
tem verification. Thus, portions of the workflow implementation that were not related
to the requirement issues were often not reviewed. The system testing was aimed at
testing all the details of the prototype. Thus, it revealed the previously overlooked
problems. Thus, it is extremely important to understand that the approved prototype
implementation cannot in any way to replace the system testing.
About 10% of the development staff performed the system testing. The project
leads played a significant role in the system testing. This helped them to have an
accurate estimate about the project progress and to identify issues (e.g., developers’
misunderstanding of the requirements) early. Since the project lead had a broad view
of the workflows being concurrently developed, the identification of issues helped
him to estimate the impacts on the other workflow developments (e.g., efforts re-
quired for making the changes).
UI designers who previously worked on the storyboards also tested most of the
prototypes with an emphasis on the UI look-and- feel. This helped to identify the
detailed UI issues that were often overlooked by the system testers.

5 Conclusions and Future Work

Highly concurrent, evolutionary software prototyping for certain application types
that have stable application practice can be very feasible and effective. Even if the
user interaction definition is initially unclear, if the application practice is well under-
stood by the users, then the data model design and application services can be devel-
oped in parallel with the UI design to a large extent. Hence, the requirements for the
different system aspects can be defined concurrently to speed up the prototype devel-
opment.
The S-RaP prototyping process helps mature the prototype requirements that will
then be used as the inputs to the product requirements. The UI design, implementa-
tion, system/acceptance testing of the prototype correspond to the different stages of
the requirements activities, namely, requirement elicitation, analysis, specification,
and validation. UI and the implementation reviews facilitate the above activities. The
prototype system testing and acceptance testing can reveal potential requirement
issues (e.g., behavior consistency) across different workflows. As with any method

that involves customers throughout the software development, S-RaP requires the
project management and development leads to manage the customer involvement
efficiently and sufficiently. For example, the manager needs to direct the customers to
describe only the domain knowledge that is relevant to the desired prototype behav-
iors. Otherwise, customers and software developers can both waste their time discuss-
ing irrelevant issues.
A well-designed software process can be essential to the success of a software pro-
totyping and development project. However, process alone will not guarantee the
project success. Its success additionally requires a good understanding of the process
(and its rationales) by all key project staff at the project start and by the entire team
soon after. The project leads and developers need to understand when they should
defer a design decision making to the next prototyping iteration and when they should
design and implement the system to the level of perfection. Documenting and repre-
senting such knowledge and criteria can be challenging since they are often not very
tangible and measurable. We believe that capturing such knowledge however will be
very useful for understanding rapid software prototyping and specifically, for using
S-RaP more effectively. This should potentially be a future research topic for us.

References

1. Gamma E., et al.: Design Patterns, Addison-Wesley (1977)
2. Song, X., Osterweil, L: Engineering Software Design Processes to Guide Process
Execution, IEEE Transactions on Software Engineering, Vol. 24, No.9 (1998)
759-774
3. Cavaness, C.: Programming Jakarta Struts. O’Reilly & Associates (2002)
4. Millington, D., Stapleton J.: Developing A RAD Standard. IEEE Software. Vol.
12, No. 5, (1995) 54-55
5. Martin, C. R.: Agile Software Development, Principles, Patterns and Practice,
Prentice Hall (2002)
6. Hwong B., Laurance, D., Rudorfer A., Song, X.: User-Centered Design and
Agile Software Development Processes, CHI, April 25-29, Vienna, Austria,
(2004)
7. Gunaratne, J., Hwong, B., Nelson C., Rudorfer A.: Using Evolutionary Prototype
to Formalize Product Requirements, workshop with International Conference on
Software Engineering (2004)
8. Boehm, B, Turner R.: Balancing Agility and Discipline, Addison-Wesley (2002-
2003)
9. Beck K.: Extreme Programming Explained, Addison-Wesley (2000)
10. Kruchten P.: The Rational Unified Processes, Addison Wesley (1999)

S Ra P A Concurrent, Evolutionary Software Prototyping Process

More Related Content

What's hot (19)

Similar to S Ra P A Concurrent, Evolutionary Software Prototyping Process (20)

More from Arnold Rudorfer (18)

S Ra P A Concurrent, Evolutionary Software Prototyping Process