People and Project Management Issues in Highly Time-Pressured Rapid Prototyping &                               Developmen...
scope and user acceptance constraints in a very effective and efficient manner. It is based inExtreme Programming (XP) pri...
Figure 2: SF product vision releases over 8 monthsHowever, an adaptive software process model and a top-talent project tea...
Whatever is known about a software feature is captured in a storyboard, which documents theworkflow, screen design, data r...
a contribution to enable SHS to be successful with their product demonstrations in the marketplace. Further, not everybody...
After reallocating the people, their performance was on track again. Unfortunately, three teammembers needed to leave the ...
team facilitates the communication flow. It enhances rapid understanding of the semantics of theworkflows as early alerts ...
the failure on already committed dates. If that happened, the new requirement was put into afeature list and built in one ...
The miniature milestones paired with cross-interviews facilitated by the technical/ project lead ofthe development staff p...
•   Design reviews: Is a meeting with attendance of the UI design lead, tech lead and the        customer representative/ ...
Upcoming SlideShare
Loading in …5
×

People And Project Management Issues In Highly Time Pressured Rapid Prototyping And Development Projects

619 views

Published on

This paper reports the experiences on people- and project management issues and how they
were successfully addressed to produce successive rapid deliveries of a medical healthcare
software prototype, the Soarian Financial product vision. The key practices of people and project
management are highlighted and concrete examples are provided to indicate how problems could
be resolved. Also, an outlook towards further research on people and project management issues
are presented in the context of evolutionary rapid development.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
619
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

People And Project Management Issues In Highly Time Pressured Rapid Prototyping And Development Projects

  1. 1. People and Project Management Issues in Highly Time-Pressured Rapid Prototyping & Development Projects Beatrice Hwong, Gilberto Matos, Christopher Nelson, Arnold Rudorfer, Xiping Song Siemens Corporate Research, Princeton, NJ{beatrice.hwong, gilberto matos, christopher.nelson, arnold.rudorfer, xiping.song}@siemens.comAbstractThis paper reports the experiences on people- and project management issues and how theywere successfully addressed to produce successive rapid deliveries of a medical healthcaresoftware prototype, the Soarian Financial product vision. The key practices of people and projectmanagement are highlighted and concrete examples are provided to indicate how problems couldbe resolved. Also, an outlook towards further research on people and project management issuesare presented in the context of evolutionary rapid development. 1. IntroductionSiemens Corporate Research (SCR) is the US research lab providing its operating companieswith technology innovations that strengthen and maintain their competitive edge. SCR is home toseveral core technologies in different research domains including Software Engineering (SE) andthe User Interface Design Center (UIDC). Over the past three years, SE and UIDC havedeveloped advanced software prototypes and product lines for several Siemens businesses.This paper is about a large rapid prototyping project, the Soarian Financial (SF) product vision,executed for Siemens Medical Health Services. The background section describes the context inwhich the project was carried out and introduces the Siemens Rapid Prototyping process (calledS-RaP). Using S-Rap as a stable framework in a highly dynamic environment, people and projectmanagement issues are be described. All issues will be supplemented by concrete examples,quantitative and qualitative data as much as possible. Following that, the measures to resolve theissues are described. Next, the S-RaP key practices used for managing this project arediscussed. Finally, conclusions and an outlook for research directions on this paper are propsed. 2. BackgroundMany Siemens business divisions face strong competitive pressures to shorten time-to-market oftheir product and service development efforts, a need to showcase the vision of new productfeatures addressing emerging business needs of their customer, or to evaluate novel softwaretechnologies that will be used in products in the medium to long-term future.One of the business divisions is Siemens Medical Health Services (SHS) a leading provider ofadvanced IT systems for the healthcare industry worldwide. One of SHS’s product lines is theSoarian Enterprise suite. Soarian supports clinical (SC) and administrative/ financial (SF) hospitalworkflows. SF is all about streamlining financial and administrative processes and obtaining real-time performance information for hospital business processes. SCR supported SHS in buildingadvanced software features for the SF product vision system. Their marketing and sales staff usethe SF product vision system to stimulate the market at customer events, for request forproposals, and at business meetings. The nature of SHS’s business needs to have new features(typically workflows such as patient check-in, denial management, reverse a charge, …) ischaracterized by the following constraints:• Very strict deadlines for software delivery dependent on concrete dates.• Often only high-level requirements for workflows are known.• Late requirements and software design changes should be accommodated.• The user interface has to be highly usable.Using conventional software development processes (e.g. the waterfall model) would not supportstrict deadlines and requirements exploration while developing the workflows. To address theconstraints, SCR has developed a software process model S-RaP that can address the time,
  2. 2. scope and user acceptance constraints in a very effective and efficient manner. It is based inExtreme Programming (XP) principles [4,5] and adds two more key ideas: 1) Quasi-concurrentexecution of requirements development, user interface design; software design, build and test 2)the use of a single software specification document (the storyboard) throughout .Concurrent rapid prototyping processfor workflow- driven web in terfaces T me i Project Planning Project trackin g Refin ed St ory board , R ned U G ef i I uide ines l Requirements Draf t st orybo ard D evelopment U r equi emen t I r s So ftw are Requir ements in f orm o f story board s Busin ess f eatu res ( D af t r Storyb oard) So ftw are Software Process fe at res u Final Release & Start Bu siness Scope D efinition Sof tware D esign & Build Improvement End ( D aft r Delivery Stor yboar d) R n ed St ory board , ef i Workshop Evolutionary Pr ot typ e o Use Cases (Dra ft St ryboa r d) o UI Sc reen, U guideli e s I n UI D esign Bi ir ectional Feedback d Output R ned St orybo ard, ef i R fined UI gui e li es e d n Proce ssFigure 1: Schematics of the S-RaP software process model (each of the core processes shouldhave iterations indicated).The S-RaP software process consists of a set of core processes and support processes. S-RaP’score process are the Business Scope, Requirements Development; Software Design, Build andTest, User Interface (UI) Design plus Final Release and Delivery. Support processes areorganized into Project Planning, Project Tracking and Software Process Improvement. It is usedthroughout the paper as a guide to visualize where and how the issues occurred and how theyget resolved.Using S-RaP, SCR staff, partnering with SHS, developed a series of workflows such as patientcheck-in, guarantor follow-up, guarantor financial overview, denial management, batchprocessing, a J2EE compliant user interface architecture, a contract engine, migrating a UI fromstatic HTML screens to JSP revamped design including database support as well as tools tocustomize the dataset for customer demonstrations. The whole project had ten distinct releases(usually three to six weeks long). Each of them was delivered on time and w/in budget.
  3. 3. Figure 2: SF product vision releases over 8 monthsHowever, an adaptive software process model and a top-talent project team are not necessarilysufficient to deliver highly time-pressured projects successfully. Only the effective orchestration ofpeople, process and technology factors working towards the goal of the project. The SF productvision project faced a series of very difficult challenges concerning people- and projectmanagement which are discussed in the next section.3. Problems & Solutions to People and Project Management IssuesIn general, the series of SF product vision projects commenced in similar ways: “Can you buildthe following software features a, b, c by date x with a highly usable interface?” The features werespecified in varying degrees of detail from an existing financial/ administrative workflow thatneeded to be redesigned in a new user interface look and feel (e.g. patient check-in), very high-level requirements where only some of the major steps are identified (e.g. bed board or casemanagement concurrent review) to only a vague statement of what the workflow is called (e.g.denial management).
  4. 4. Whatever is known about a software feature is captured in a storyboard, which documents theworkflow, screen design, data requirements per task flow step as well as the user interactionsequence on a screen. Missing or incomplete requirements for a software feature are analyzed,complemented and validated in requirements development. In parallel, the screens in thestoryboard are evaluated and the ones that need any work (re-) designed. Development receivesthe storyboard, evaluates the technical feasibility and prepares estimates on how to fit thesoftware design, build, integration and test of the feature to meet the deadline as specified by thecustomer. In design review sessions, critiques about the work in progress software prototype arefed back for requirements/implementation adjustment. Finally, acceptance testing by thecustomer representative provides an iterative loop for last adjustments to the implementation. Inthis fashion, the SF product vision product prototype is iterated and requirements matured. Theoutcome is a highly usable web user interface matching the defined requirements.Subsequently, the people and project management issues that happened during the SF productvision project are itemized.3. 1 Problems & Solutions to People ManagementOverall, the Soarian Financial product vision produced ten major releases with more than160,000 lines of JSP/Java code, using a project team of twenty to thirty three staff members.. Thecore team is five people consisting of a program manager, two senior and one junior softwarearchitects plus a very experienced lead designer with expertise in hospital financial/administrative workflows.One of the well known wisdoms of software engineering is the people factor which can make asoftware development endeavor succeed or fail. In the following sub-sections, topics such astraining needs, staff management broken down into project staffing, maintaining peoplemotivation and focus, people performance management, and last but not least peoplecommunication.Training NeedsIn order to be able to develop the feature sets as requested by SHS, 28 staff were neededadditionally to the core team over the life-cycle of the SF product vision project. The peoplejoining the team did not have prior exposure neither in the Soarian Financial project nor thehealthcare domain. The key means to bring new hires up to speed was to • give tutorial on the software architecture used and assign them a low-risk development task to facilitate learning on the job. • staff the sub-teams with experienced developers to allow knowledge transfer to beginners. • assign functional testing tasks initially to build domain knowledge.In addition, these efforts were supported by the use of a searchable project mailing list and thecreation of a knowledge database. Overall, the core team spent approximately ten percent of theirworking hours on teaching new hires.Staff ManagementOnce new hires were up to speed, the overall in a dynamic environment needed to be managedthe way to impact positively the SF product vision project. Staff management in this paper isabout project staffing, maintaining people motivation and focus, people performancemanagement and people communication.Project StaffingGiving new hires three to four weeks or longer to get through an initial learning curve is possiblein conventional development projects where the time-to-market does not have to be achieved inthree to six weeks from initial requirements definition to deployment of the software feature.Particularly, the core team found it difficult to find appropriate people to join the project team whowould fit into a very dynamic working environment putting up a lot of stress, but also excitement in
  5. 5. a contribution to enable SHS to be successful with their product demonstrations in the marketplace. Further, not everybody could or would make the commitment to deliver on very toughdeadlines maintaining the high level of productivity and software quality.In total, some forty resumes were reviewed and some fifteen interviews were carried out to hiretop-notch software developers. To quickly find great dedicated people outside of SCR, the coreteam initiated a partnership with a global technology staffing agency. From the fifteen interviewscarried out, five consultants were engaged. Another part of the development force was selectedinternally from within the SCR usually by referral or via networking. A total of twenty three SCRstaff and five consultants contributed to the releases.Maintaining People Motivation and FocusHiring great people who perform is only part of the equation for success in software developmentprojects. The dynamics of a project and pressure to make every milestone took its toll on theteam. The core team who was steering the wheels of the ship was aware of motivation and focusdue to prior project experience in a smaller setting. Consciously, the leader of the core teamasked the other core team members to maintain the pulse on their people that they were workingwith. Any issues on people burning out or too much stress was usually reported in the weeklyinternal project leadership meeting.To make sure that the sub-teams remained motivated to largest degree possible, one techniquewas to rotate the project staff to do different tasks. For instance, we gave project staff theopportunity to not only write code meeting tough deadlines, but also e.g. gather requirements,carry out design reviews with the customer representative to validate a workflow implemented, orrun a software process improvement workshop. Providing people with such opportunities not onlytaps into the creative juices of people but also builds credibility that the project management doesanything possible to alleviate the pressure and facilitate opportunities for professional andpersonal growth. In total, some four process improvement workshops were carried out (usuallyafter each major release). This working session is a two hour event. The goal of the softwareprocess improvement workshop is to identify improvements for people, process and technologyas well as vent concerns and issues. The output is a list of ten to fifteen improvements which aretransformed into an action plan. It is important that the project staff has ownership forimprovements implementation. In a meeting with the project leadership team, the low hangingfruits having the greatest business impact are selected for implementation. For example, an opensource mailing list was suggested to allow rapid communication of code design patterns or codesnippets.Furthermore, another technique to achieve team camaraderie is having a team pizza lunchmonthly, including the customers after a major delivery It is seen as a celebration and alsovirtually “take a deep breath” before pressing on for another delivery In total, seven pizza luncheswere carried out.As to the negative outcomes of the project, there were some issues of people chemistry makingthem unable to work together in a sub-team. Three people needed to be separated andreassigned to another team.
  6. 6. After reallocating the people, their performance was on track again. Unfortunately, three teammembers needed to leave the team due to inconsistent performance and disciplinary issues.Being consistent with the project staff is very closely observed by all team members. If staffmembers are expected to perform on the top, it would be incompatible to keep people on theproject who do not deliver as expected. This would mean a big hit for the morale of the otherswho are all “A” performers.Early on in the project, it became evident that only “A” players could be hired for the SF productvision project. The ideal “A” player for software engineering is technically very strong and has athree plus years experience in the target software technology, is an effective communicator, ateam player but also is self-directed, goal-oriented and has a great potential to lead. Userinterface designers to be “A” level payers need to be familiar with the technology of what designscan be technically implemented, and is versed in creating relationships and bonding with thecustomer. Additionally, interface designers must be prepared to engage with the developmentstaff for any user interface design issue popping up.People Performance ManagementTo deal with a lot of people contributing to the delivery of this project, the project leadershipstarted to evaluate the each person’s performance in terms of technical skills, level of motivationand team capability. The ranking metrics used was 1.. very poor, 2 .. poor, 3 … fair, 4 .. good, 5... very good for every indicator. The evaluation was done by the project leader or the technicallead of each sub-projects. The outcome of the people assessment was that every team memberon the project was between 4 and 5. Three team members assessed lower than four weredropped from the next project. The people performance evaluation provided quantitative datanecessary to assign people for the next release and also to determine who would have customer-facing opportunities. Throughout the year, three major people performance assessments werecarried out. Using this data, technical and project lead could put together teams that wouldbalance each other’s strengths and weaknesses for the benefit of the project. This also helpedminimize the risk of burning out people. Further, the project staff knew always how they wereperforming due to a frequent dialog.People CommunicationOne specific problem encountered by the project teams was to achieve a synchronization of therequirements development, user interface design and software design, build + test. We needed tokeep in mind that we work in three quasi concurrent threads. A consistent communicationbetween all parties is a need that cannot be neglected. Although one single software specificationdocument is used, it cannot record all details of the semantics of what is being specified. Detailsin a workflow (represented by a screen print and textual description of the user interaction) can bemisinterpreted and then development or user interface design efforts are wasted. This iscounteracted by the following means: Every design review is accompanied by a technical leadand a user interface design lead. By doing this, technical implementation feasibility is evaluated inparallel with assessing accuracy of the user interface design of the workflow. The technical leadsubsequently communicates the semantics of the workflow back to the pairs of developersimplementing a component of the SF product vision. Moreover, the technical lead encouragesteam members to come to ad-hoc meetings if there is an issue that needed to be resolved, e.g.on how to implement a secondary workflow.To facilitate maximal interaction among software engineers, customer representatives/ subjectmatter experts and user interface designers, being physically close to each other is significant.Most of the development staff sits only two to five meters apart. For instance, one softwareengineer, located on the another floor, joined the SF product vision several months ago. Afterreviewing his performance, it was noted that he did not seem to be as productive as the otherstaff that were physically closer together.One of the technical leads suggested having him move closer to the rest of the team. Within oneweek, the concerns regarding his productivity disappeared. Close proximity of the whole project
  7. 7. team facilitates the communication flow. It enhances rapid understanding of the semantics of theworkflows as early alerts when developers identify a critical issue that needs to be shared. Next,the user interface design team is just down the hallway with a distance of twenty meters from thesoftware engineers. If there is any question respective the behavior of a user interface control, itcan be clarified w/in minutes. Brief hallway meetings resolved small issues before they becamebig ones. Our experience so far has been that having a closed loop communication with allstakeholders is one of the keys to the success of the S-RaP process. This facilitates minimizingthe risk of misinterpretation of requirements as specified by the customer.Other means employed to make communication work amongst the teams was to clearly definecommunication channels or single points of contact. The project structure designed establishedthe following roles: The technical lead of a team takes charge of any technical issue arising andmaking sure that it gets resolved. Any user interface related questions gets taken care of by theuser interface lead which in turn submits user interface related design decisions to the projectsponsor for decision and approval. A project lead takes care of the tracking and reporting on theproject itself.People issues and their solutions have a direct impact on managing the project in terms ofschedule, cost, and quality. The following subsection is all about the project management issuesthat had the potential to jeopardize the project success as a whole.3.2 Problems & Solutions to Project ManagementSelecting the right measures to keep the project within schedule, cost and budget is a challengethat is not to be underestimated for an effort with tight time constraints. Due to the nature ofSHS’s business needs, any failure on schedule would mean missing important salesopportunities in the market. This fact put additional pressure on the leadership of the SF productvision to do thorough impact analysis for changes.The following problem categories surfaced during the life-time of the SF product vision: Problemsconcerning new requirements, scope management, customer relationship; and peopleperformance management, project planning a well as project tracking and reporting.New, Misinterpreted Requirements & Scope Management.One of the most frequent problems to deal with from a project management perspective in thisproject was the identification of new requirements which either came out of requirementsdevelopment, user interface design or software design, build and test. Due to the rapiddevelopment of a software feature it is an expected phenomenon that requirements gathered atthe beginning of the release will mature over time as they are understood better. To identifysolutions that can cope with this fact is the use of the SF product vision prototype as a boundaryobject itself [2]. The idea therein is to see the requirements as specified in a functioningprototype. Customer representatives and subject matter experts get a hands-on feel for how theworkflow is being implemented. It allows experiencing the user interaction step by step throughthe workflow as well as testing the usability of the system overall. Another source of newrequirements is a design review which involved the developers. They are meetings with a focuson providing feedback on how the product is being perceived by the customers. Reviews helpdrive development into a direction of maximizing customer satisfaction. From these reviews,developers learned about missing steps in a workflow, missing data that need to be provided orabout clarifications about interactions that are needed to make the feature function. Over 100telephone conferences with an average duration of one hour were carried outEvery new requirement was analyzed and re-estimated in terms of effort by all tech leads pairedwith an impact analysis and the viability of fitting it into the current release plan. If there was morethan one requirement, the customer was asked to prioritize the new requirements. Next, theproject sponsor and the responsible project manager negotiated what could be done w/oendangering the current delivery. About ten adjustments in the project plan could be made tobuild in the extra requirement. Twice, it was not possible to adjust the project plan without risking
  8. 8. the failure on already committed dates. If that happened, the new requirement was put into afeature list and built in one of the subsequent releases.A second problem area was misunderstood and misinterpreted requirements. This was causedby the speed of process execution and lack of time spent on clarifying the detailed semantics ofrequirements. It happened twice with building new workflows. The result of the misunderstandingand misinterpretation was a waste of development effort. By frequently reviewing the workflowbuilt in code with subject matter experts, the flaws in the design were caught at a very early stageand corrected immediately. Another successful means is to maintain a continuity of a softwareengineer on a single component because it allows leveraging the healthcare domain expertiseacquired by that engineer.A third problem to deal with in the context of scope management were requests to develop twoadditional releases in the short-term while maintaining the same level of commitment. One was athree week effort which required four staff and another one which was six weeks effort thatneeded four people. In order to address the short-term requests, it was not possible to hire newpeople due to the learning curve they needed to go through. Therefore, the only way to addressthe customer request was to take staff from the current running projects and substitute them withnew hires. To achieve this stretch goal to deliver two additional releases, the project leadershipneeded to carefully re-evaluate the skills of all of the people and make them fit with therequirements of the additional releases. At the same time, the project lead on the running projectsstill needed to have enough staff to guarantee the schedule as expected by the customer. Eachnew team got one senior team member as the lead for the new releases paired with junior staff.Further, the switching of the people to new assignment in the very short-term created someissues of focus. In total, eight out of twenty-five people got switched back and forth between thesub-teams.Project Tracking & ReportingOne of the key problems encountered in the SF product vision was the ability to track progress ofwork accomplished and relate it to the deadline ahead. Short deadlines and the progress in theproject can only be tracked if there is a fine grained control to measure it against.The project plans were planned around the idea of “Miniature Milestones” [3] which are two tothree days deadlines. They help to assess the risk of non-delivery of a software feature.Figure 3: Sample project plan with Miniature Milestones
  9. 9. The miniature milestones paired with cross-interviews facilitated by the technical/ project lead ofthe development staff provide the right set of data to evaluate plan versus actual. This providesan accurate picture on the “real progress” (see figure above). Subsequently, appropriate stepsmanaging the projects can be taken. For example if the progress of development of one workflowis late, there is an opportunity to shift development resources.Another project management technique is to carry out a one hour weekly status report meetingwith the project sub-teams to keep the focus and provide a look-ahead to the next week’sexpectations. Also, the testing of workflows starts as soon as there is a small part of the workflowimplemented. It helps to obtain a “count” on the functional and non-functional software defects.The count is taking into account to have enough time allocated for bug fixing. All in all, thesesimple measures allow a further fine-tuning of the project plan to minimize the risk of non-timelydelivery.Customer RelationshipSHS put great faith and trust into SCR’s capability to deliver the number of workflows, a new userinterface architecture for a new, highly usable web interface and database support. In order tomake sure that faith and trust are supported by facts, a very tight and close project reportingstructure was designed. It was all about managing the expectations the way according theprinciple of “We deliver what we promise”.The project’s toolbox contained the following: Continuous communication on the progressachieved by means of design reviews with the customer representative/ project sponsor.Additionally, every Friday a status report outlining the previous work week achievements, task ofthe following work week plus issues and concerns was provided. On the following Monday or thefirst day of the work, a project leadership teleconference was held to achieve two goals: Reportthe progress from last work week and plan the following work week. That was necessary due tothe continuous involvement the staff from SHS to validate workflows built and also to get SHS todo very early acceptance testing. In total, twenty eight leadership meetings of thirty minutesduration were carried out. The fact that SHS could see an evolving functioning prototypedemonstrated visible progress and built credibility and good-will on both sides. Furthernegotiations concerning new requirements became easier as our partner SHS perceived us astrust-worthy and reliable.From a project leadership perspective, the key is to have “No surprises” in time-pressured rapidprototyping & development projects. Failing on the promise would have a very negative impact onSHS’s business.4. S-RaP Key Practices for Time-Pressured Rapid Prototyping & Development ProjectsOver the lifetime of this project, the following key practices for rapid prototyping & developmentusing S-RaP were identified and applied to drive the development of this project: • Use of single-artifact through software life-cycle: The storyboard is used to capture requirements, UI design specification, coding specification and test case specification. • Focus customer workshop: Is a quick way to obtain a start draft storyboard for a use case of a software feature to be built. • Miniature milestones: Is a defined date in a project schedule prompting a concrete result in a software development project. It usually happens all two to three days. • Integrated multidisciplinary software development teams: Customer representative/ subject matter expert, project manager, developers, UI designers work as an integrated team capitalizing on diverse skills and experiences. • Project leadership meeting: Is a 30 min. meeting at the beginning of each week with attendance of the project manager, tech lead/ chief architect, project sponsor and the UI design lead. The purpose of this meeting is to report progress on the work accomplished and the planning for the current work week. It is a key tool to synchronize all project stakeholders to assure compliance according the schedule.
  10. 10. • Design reviews: Is a meeting with attendance of the UI design lead, tech lead and the customer representative/ subject matter expert. The purpose is to visualize the work in progress and provide the developers with feedback and improvements. It is a key activity to assure that the requirements are implemented as the project sponsor expects to obtain. Quick turnaround of improvements visible in prototype builds confidence. • Staff performance evaluation: Assessing how well people contribute on an ongoing basis provides a useful tool to assign the best people to the most difficult components to develop. • Task rotation: This practice helps to avoid project staff burn-out due to the short deadlines that have to be adhered to. E.g. a developer can become a requirements engineer to work with the customer representative/ subject matter expert. • Software process improvement workshop: Identify proactively improvements relative to technology, people and process. The output of the workshop is used to improve the effectiveness and efficiency of this software process model.5. Conclusions & Future ResearchExtreme programming and a flexible software process model like S-RaP can work togethersynergistically. S-RaP provides a stable framework of reference in a highly dynamic softwaredevelopment environment to manage people and project management very effectively. Applyingthe practices, we have found effective such as the use of a single software specificationdocument, focus customer workshops, project leadership meetings, applying design reviews andusing software process improvement workshops as means to learning throughout the deliverycreates an atmosphere of focus and excitement for all project staff.SCR will continue refining S-RaP and using it as the core model for another large Siemensproduct line development project.6. AcknowledgementsThe authors would like to thank Robin Kavanagh, Cynthia Lazzari and Jamie Moretz from SHSfor the great collaboration on the Soarian Financial vision project. Without their help, feedback,guidance and advice many of the workflows as well as user interface designs would not havebeen implemented the way as they have been. An additional thank-you, we owe to the SCR stafffrom Software Engineering, User Interface Design, Multimedia Technology and Integrated DataSystems as well as our consultant team that were committed till the last minute on this endeavor.7. References[1] Beatrice Hwong, David Laurance, Arnold Rudorfer, Xiping Song; Exploring the EffectivenessPotential of User-Centered Design and Agile Software Development Processes; CHI 2004,Workshop Bridging the Gaps between HCI and Software Engineering I; Vienna, Austria, April2004.[2] Junius Gunaratne, Christopher Nelson, Beatrice Hwong, Arnold Rudorfer, Xiping Song; UsingEvolutionary Prototypes to Formalize Product Requirements; ICSE 2004, Workshop Bridging theGaps between HCI and Software Engineering; Glasgow, Scotland, May, 2004[3] Steve McConnel: Rapid Development, Taming Wild Software Schedule, 1996.[4] Kent Beck, Extreme Programming Explained: Embrace Change, 1999.[5] Stephen Palmer, John Felsing: A Practical Guide to Feature Driven Development, 2004.

×