S Ra P   A Concurrent, Evolutionary Software Prototyping Process
Upcoming SlideShare
Loading in...5
×
 

S Ra P A Concurrent, Evolutionary Software Prototyping Process

on

  • 809 views

This paper defines a highly concurrent, software rapid prototyping ...

This paper defines a highly concurrent, software rapid prototyping
process that supports a sizable development team to develop a
high-quality, evolutionary software prototype. The process is particularly
aimed at developing user-interface intensive, workflow-centered
software. The Software Engineering Department and User Interface Design
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 development
process that tightly integrates the UI designers and the software
developers with the prototype users (e.g., marketing staff), leading to efficient
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 prototypes
can be rapidly developed in a highly concurrent fashion given a
stable prototyping software architecture and access to readily available
domain knowledge.

Statistics

Views

Total Views
809
Views on SlideShare
806
Embed Views
3

Actions

Likes
0
Downloads
1
Comments
0

1 Embed 3

http://www.linkedin.com 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

S Ra P   A Concurrent, Evolutionary Software Prototyping Process S Ra P A Concurrent, Evolutionary Software Prototyping Process Document Transcript

  • 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 IntroductionRapid software prototyping is an effective way to facilitate communication among thecustomers, the requirement engineers and the marketing staff by providing them withan executable, intuitive representation of a target system. Prototyping is an effectiveapproach to evaluate and refine software requirements [4][5][6][7]. Prototyping isalso used to aid the communications between the company’s marketing team andpotential customers, promoting the advanced features of the product and gatheringcustomer 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 bereused for the corresponding product. The evolutionary prototyping has a potential tomature a prototype into the final product and thus it needs to be of high quality andwith 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 earlyphases (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 softwaredevelopment methods (e.g., Extreme Programming [9]) [5][8], RAD [4])) have beendescribed in the past. Agile methods usually emphasize involving the product users inthe prototyping, and encourage a rapid users-to-developers feedback cycle. Projectmanagement and tracking are often not emphasized by those methods. Some agilemethods 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 productusers 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 ofcertain 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 agilemethods 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 thatincluded the definitions of the concurrent activities and key reviewing activities. Inthis paper we will define the process in detail, following the process engineeringapproach as suggested in [2]. First we define the requirements in Section 2 for theprocess 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 processto carry out a successful project.2 Process RequirementsBecause 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 oftenreferred to the people who will use the prototype to define and validate the productrequirements, 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 DefinitionFigure 2 uses a basic flow chart to define the S-RaP process. The process starts fromthe top-left corner and finishes at the bottom-right corner. From the project planningand tracking point of view, it consists of three phases. Thus, the project managementcan evaluate the project progress based upon the numbers of workflows that are beingmainly developed in each phase. However, from the development point of view, theactivities are performed concurrently through those three phases. For example, the UIDesign 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 theproject where the S-RaP process was originated. The major outputs of the process arethe 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 PhaseThe user interface design begins with the initial understanding of the workflow andprior experience in developing similar functions. The UI designer will carry out thisactivity with extensive involvement of the users and limited participation of the soft-
  • ware engineers who will be implementing the user interface. This activity requires avaried number of meetings with the users depending on the different complexities ofthe targeted workflows. This activity will deliver a document called a storyboard thatdefines 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 textdescription 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 pageof 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 ideasfrom the users. However, it will be further refined during the user reviews (either atUI design or UI implementation level) or during the requirements meetings with theusers. Since this activity attempts to describe dynamic system behaviors with staticscreen 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 befurther refined and completed along with the maturing prototype throughout the S-RaP process. The finished storyboard contains both the prototype requirements andthe UI design. The UI design can start with an existing preliminary style guide to ensure designconsistency. 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 UIdesign can be consistently applied to other similar UI designs via the style guide. Theconsistent 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 styleguide 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 toenable multiple UI designers to work concurrently on the same workflow. Activity Review with Users ensures that all the major users are satisfied with theuser interface and the system behaviors. The main user contact must approve the UIdesign as sufficiently complete so it can be final-reviewed by all the major users. Allthe major stakeholders will attend this review and decide if the storyboard will beapproved. This activity is largely a requirement activity that is focused on the UIlook-and-feel and correct interaction sequences. Due to the limited meeting duration,the meeting can be focused on only the important requirement issues. The reviewmeeting 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 process3.2. Prototype Implementation Phase3.2. 1. UI Implementation
  • The UI Implementation activity starts as soon as a portion of a workflow’s storyboardhas 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 canfirst 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 usingmock-up data. This ensures that the workflow appears realistic, and thus users caneasily review the workflow’s dynamic behaviors before completely validating moredetailed prototype requirements. For inexperienced developers, this activity can be started even earlier to allow thedevelopers 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 untilthe UI Design Review is finished. This ensures that the validation of the dynamicaspect of the prototype requirements can be based upon the validated static aspect ofthe prototype requirements. It is possible that the implementation will reveal areas ofimprovement in the UI design (e.g., missing required interactions for users). Thiswould lead to an extra UI design iteration. However, if the UI design change is minorand does not require changing the requirements, this will not cause an additional UIdesign review. Since at this point the prototype is interactive, the users will be able tosee some complete interactive use-cases of the prototyped workflow. Thus, the re-quirements can be further refined and more completely validated with users. Forexample, for “checking-in patients into a hospital” workflow, since it is interactiveand the users can actually execute it, the working prototype can ensure that the UIdesign is complete at least for one use-case (for a particular patient) of the workflow.3.2.2. Data Design and ImplementationUnlike a “throwaway” prototype that completely relies on mock-up data, the evolu-tionary software prototype needs to use realistic data and the data changes shouldremain realistic after being accessed and modified by the users. The data design canconsist of two parts. One is the data model and another is the actual data value set thatwill be stored in the data model. Since S-RaP is aimed at supporting evolutionaryprototyping, 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 modeldesign once a few of the storyboards are initially defined. The data designers cananalyze the UI designs to understand what data needs to be accessed and modified. Inaddition, by analyzing the prototype behaviors specified in the storyboards, the datadesigners can better understand the relationships among the different data. Basedupon 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 supportsthe 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 understandingof the requirements across multiple workflows. The data design is the second task of this activity. This task is to ensure that thedata 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., thepatient demographics data) and the rules that govern which data should be allowed toappear in certain workflows. Such rules depend heavily on the application domainknowledge. Thus, the development of those rules requires the communication withthe users.3.2.3. Application Service DevelopmentThis 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 apatient. Starting this activity early gives the developers extra time to gain the domainknowledge 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, theservice application developers can provide useful inputs to the data model designersfor how the data should be structured to effectively support the data accesses from theapplication services.3.2.4. Integration and Bug FixingThis is the final activity for each workflow to be developed. During this activity, thedevelopers will integrate the UI implementation code and application service code.The developers may need to implement the UI/data interface code to facilitate thedata support for each UI (e.g., forms in the Struts architecture [3]). The developerswill unit-test the developed workflow against the corresponding storyboard. This isoften teamwork between the developers who are involved in the previous activitiessuch as Application Service Development and UI Implementation development.Sometimes, if the data model needs to be changed, it will require the participation ofthe data designers.3.2.5. System TestingThe system testing is to test the functional behaviors of a workflow after it has beenfully integrated with all the required business logic and persistent support. It differsfrom the “unit testing” in: 1) it is carried out by testers who do not implement theparticular workflow being tested, and 2) it will formally report the defects which willthen be tracked by project management and the test lead. The storyboard is used asthe testing script for verifying the prototype behaviors. At this stage, the testers verifythe prototypes against the storyboard for every detail.
  • 3.3. Acceptance TestingThe prototype users will carry out the acceptance testing. The users are the peoplewho will demonstrate the prototype to their customers for the proposed new productfeatures. Like the system testers, the users use the storyboard as the requirements toverify the prototype behaviors and the user interface compliance. Since the users havepreviously approved the storyboard, there should be little disagreement between thetesters and the implementation team as to whether the prototype UI and behaviors areimplemented correctly. Acceptance testing can be viewed as a final step to validatethe actual requirements, since the users will perform the testing, based both on thestoryboard 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 onproposed features. The initial requirements of the prototype were based upon theirexisting understanding of the customer needs and their knowledge on the prior similarproducts. Prior to our prototyping effort, a large portion of existing understanding ofcustomers’ needs was neither well documented nor organized in a way to supportproduct development. Thus, our prototyping activity had two goals: 1) To develop theprototype that is a marketing and requirement solicitation tool for the marketing team,2) To formulate the product requirements elicited from the Siemens customers in anorganized and tangible manner. The prototype consists of 6 workflows and each workflow was specified with astoryboard that has on average about 25 screen-shots. The prototype is required to becustomizable; the data displayed in the prototype UI can be customized for differentcustomer audiences. The business rules can be added or modified to enforce theprototype data compliance. The schedule for the delivery was very tight and firm (weneeded to deliver the prototype in four months) while the prototype was required tobe extremely reliable and with high look-and-feel quality. Our development team hadon 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 fordelivering on time. The project size in terms of the number of requirements, projectedlines of implementation code, and number of team members all exceeded those of ourprior projects. Our success in applying the S-RaP process concurrency indicates thatconcurrent and iterative prototyping is highly effective for the development of a largesoftware prototype within a short development life cycle. In the following sections wediscuss our observations in detail.
  • 4.1. Progress VisibilityThe following diagram provides a combined snapshot view as the project managerevaluated 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 theproject 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, thediagram shows that Workflow 1 was finished while Workflow 6 was being developedin 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 projectmanager will know most of the work in the past phase had been finished. The span ofa specific workflow across multiple phases (for example, Workflow 5 is in UI Designand Prototype Implementation) indicates that the activities of both phases are stilltaking place. The implementation phase will be under way for the data and serviceaspects, 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 evaluateif a workflow has passed certain development phase: 1) ”UI Design Review withUsers”, 2) “UI Implementation Review with Users”, 3) Problem list from SystemTesting, and 4) Problem list from the Acceptance Testing. 1) and 2) are two veryspecific activities that will either approve or reject the reviewed artifacts Thus, theyprovided clear information for the project manager about the progress. Since theproblem lists describe specific defects of the prototype found at certain dates for eachworkflow, 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 DevelopmentWe successfully applied the S-RaP concurrency as we planned. Our experience how-ever indicates that the concurrent activities should be highly interactive among thedifferent teams (e.g., UI design and UI implementers). Those interactions can triggerthe iterations of the activities in a more timely fashion. For example, the requirementsof different system aspects (e.g., UI look-and-feel, and the dynamic interactions) weredeveloped concurrently. However, once an initial working prototype was created, thedetailed UI interactions and data behavior provided by the prototype affected the UIdesign 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 onthose team interactions, a representive member of one team can participate in therequirement meetings of other teams. One major issue for the concurrent development is that the concurrent activitiescan cause substantial rework that outweighs the time gains from the activity execu-tion concurrency. We addressed this issue by allowing the dependent activities to becarried 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-shotsthat define UI and interactions. We started the UI implementation on the first 10screen-shots that were relatively well defined. Thus, while the UI designers workedon the other slides, the developers implemented the first part of the workflow andprovided the UI designers with feedback more quickly than if this had been done in alinear order. Our experience also shows that concurrent development requires a centralized co-ordination, so the requirement changes can be managed to ensure their consistencyacross different workflows. In our project, there were three to four workflows beingimplemented concurrently. The project lead tracked the issues coming from the dif-ferent teams and coordinated some unified approach to address those issues that canbe about the implementation techniques or prototype requirements such as the consis-tent system behaviors. For example, two different workflows allow users to enter thedata. However, when to save the data can be an issue (e.g., immediately after the datais entered, or after the “OK” button is pressed). Sometimes, whether we should keepthe 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 usersto 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 tousers. One major issue in our project was that if we delivered the prototype exactly onthe scheduled delivery date, the users would not have enough time to acceptance-testthe prototype. The incremental delivery supported by S-RaP process very effectivelysolved this problem since the incremental delivery involved the users in the concur-rent development process. In our project, the system-tested workflows were packagedinto a number of groups and then delivered to users incrementally. Thus, while theother workflows were still being developed and system-tested, the users were able toacceptance-test the delivered workflows. The early acceptance testing also provided
  • the development team sufficient time to fix the bugs, which would be impossible ifthe process were completely sequential and the delivery were not made incrementally.4.3. Start System-Testing EarlyOne important factor that contributes to the successful use of S-RaP in this project isto 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 longworkflow, 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 relatedto the requirement issues were often not reviewed. The system testing was aimed attesting all the details of the prototype. Thus, it revealed the previously overlookedproblems. Thus, it is extremely important to understand that the approved prototypeimplementation cannot in any way to replace the system testing. About 10% of the development staff performed the system testing. The projectleads played a significant role in the system testing. This helped them to have anaccurate estimate about the project progress and to identify issues (e.g., developers’misunderstanding of the requirements) early. Since the project lead had a broad viewof the workflows being concurrently developed, the identification of issues helpedhim 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 theprototypes with an emphasis on the UI look-and- feel. This helped to identify thedetailed UI issues that were often overlooked by the system testers. 5 Conclusions and Future WorkHighly concurrent, evolutionary software prototyping for certain application typesthat have stable application practice can be very feasible and effective. Even if theuser 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 thedifferent system aspects can be defined concurrently to speed up the prototype devel-opment. The S-RaP prototyping process helps mature the prototype requirements that willthen 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 ofthe requirements activities, namely, requirement elicitation, analysis, specification,and validation. UI and the implementation reviews facilitate the above activities. Theprototype system testing and acceptance testing can reveal potential requirementissues (e.g., behavior consistency) across different workflows. As with any method
  • that involves customers throughout the software development, S-RaP requires theproject management and development leads to manage the customer involvementefficiently and sufficiently. For example, the manager needs to direct the customers todescribe 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 theproject 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 teamsoon after. The project leads and developers need to understand when they shoulddefer a design decision making to the next prototyping iteration and when they shoulddesign 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 verytangible and measurable. We believe that capturing such knowledge however will bevery useful for understanding rapid software prototyping and specifically, for usingS-RaP more effectively. This should potentially be a future research topic for us.References1. 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-7743. 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-555. 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)