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.

UI Design

Review w/users

UIImplementation

Review w/users

Data (Model)Design/

Implementation

Integration/BugFixing

SystemTesting

AcceptanceTesting

Storyboard(per workflow)

UI Design Not Approved

Impl. Not Approved

UI Design Approved

Testing Not Passed

Testing Passed

Test Not Passed

Finished

Acceptance TestingPhase

PrototypeImplementation

Phase

UI Design PhaseUI Problem, not approved

ApplicationService

Development

InitialRequirements

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.

Prototype Impl.

Workflow 5 Dev.

Workflow 4 Dev.

Workflow 3 Dev.

Workflow 2 Dev.

UI Design AcceptanceTesting

Workflow 6 Dev.

Project Progress

Finished

Workflow 1Dev.

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)