Chapter 2 Traditiona Software Deveopment 2.1 History of Project Management Large projects from the past must aready have had some sort of project management, such the Pyramid of Giza or Pyramid of Cheops, which were buit more than 2,500 years BC. We cannot beieve that those types of projects were possibe without some sort of project management. But at east we are not aware of the project management practices that were used back then. The 1950s mark the beginning of project management in the modern sense. Before that, projects were aready using Gantt charts (deveoped by Chares Gantt), but during the 1950s more forma project management techniques were deveoped, documented, and made avaiabe to the community (Fig. 2.1). PERT, Program Evauation and Review Technique, one of the first project management scheduing techniques, was deveoped by Booz Aen Hamiton Inc. as part of the Poaris submarine missie project. It was deveoped to schedue and coordinate arge projects. What you see in Fig. 2.2 is a CPM Network chart created with Microsoft Project. In this favor the nodes represent tasks; in the origina PERT chart the nodes represent events or miestones. Around the same time, the Critica Path Method (CPM) was deveoped at DuPont, originay to pan the shutdown and start-up of chemica factories before and after maintenance. CPM is very simiar to PERT. In CPM, the nodes represent activities or events (an event is an activity with duration of zero) and dependencies are represented by arrows between two nodes. Using Eariest Start- and Finish-time as we as Latest Start- and Finish-Time, one can cacuate the critica path in a CPM network diagram. As project management was becoming more and more important in the 1960s, the Project Management Institute (www.pmi.org) was founded in 1969 to advance the practice, science, and profession of Project Management. The PMI offers certification as certified project manager, which is currenty the most widey recognized project management certification in the industry. The Project Management Institute aso pubishes the PMBOK Guide, which contains the basic concepts and techniques for traditiona project management. T. Stober and U. Hansmann, Agie Software Deveopment, DOI 10.1007/978-3-540-70832-2_2, # Springer-Verag Berin Heideberg 2010 15
16 2 Traditiona Software Deveopment Fig. 2.1 Gantt chart Task 0 Start: 26.01.09 ID: 1 Finish: 30.01.09 Dur: 5 days Res: Task 1 Start: 02.02.09 ID: 2 Finish: 05.02.09 Dur: 4 days Res: Task 2 Start: 26.01.09 ID: 3 Finish: 28.01.09 Dur: 3 days Res: Task 3 Start: 29.01.09 ID: 4 Finish: 04.02.09 Dur: 5 days Res: Task 5 Start: 26.01.09 ID: 5 Finish: 28.01.09 Dur: 3 days Res: Reease Start: 06.02.09 ID: 6 Finish: 06.02.09 Dur: 1 day Res: Fig. 2.2 Simpe CPM network chart Requirements Design Impementation Test Support Fig. 2.3 Traditiona waterfa approach 2.2 Waterfa Approach The waterfa approach is the traditiona approach used in smaer and arger projects for the ast few decades (Fig. 2.3). In the waterfa approach, each phase is competey finished before the next ones starts. In the next few chap. we wi describe and discuss each phase in more detai.
2.2 Waterfa Approach 17 Requirements gathering Requirements anaysis Fig. 2.4 The three steps of the requirement phase Requirements documentation 2.2.1 Requirements Every project starts with the requirement phase, during which a the requirements are coected, documented, and discussed with a the stakehoders. Stakehoders are a individuas or groups of individuas who have an interest in the project or its outcome. This is of course the project sponsor who is funding and promoting the project as we as the future users of the system. But there can aso be others, such as the workers counci, competing activities or interest groups in the company, the purchase department and so on. A stakehoder can aso be a group that has a negative attitude against the project. It is as important that a stakehoders are identified and their requirements are coected, anayzed, and taken into consideration. A communication to a stakehoders must be managed in the best interest of the project. Stakehoder management is usuay divided into the foowing two activities: Stakehoder anaysis is the phase during which a the stakehoders are identified and their interests in the project anayzed and documented. The team needs to po a the stakehoders to get their requirements. A communication pan is put together during stakehoder panning to ensure that a stakehoders are kept invoved, depending on their interest and needs. The requirement phase contains the three steps shown in Fig. 2.4. During the requirements gathering steps, the team identifies a the stakehoders (aso described above under stakehoder anaysis) and interviews them to coect their requirements. The team then anayzes these requirements and documents them in the systems requirements specification. The requirements can be separated into two major groups: Functiona requirements, which are often described as use cases describe a user scenario or interact with the soution, such as A user wants to cacuate todays vaue of his or her stock trading account or As an administrator, I woud ike to change the defaut settings for new accounts. These use cases are then brought to a more detaied eve during the Design phase. Non-functiona requirements, such as the software and hardware environment that it shoud support, but aso the performance characteristics the soution needs to meet.
18 2 Traditiona Software Deveopment The requirements anaysis and documentation is ideay not a inear process, as the team shoud meet with the stakehoders severa times during the requirements phase and present to them their current understanding of the requirements for the soution to coect feedback and potentiay missing requirements. Prototypes or screen mockups are often usefu to ensure that the stakehoders and the team have the same interpretation of the requirements. Often the stakehoders requirements evove during the requirements discussion, as the discussion becomes more concrete. Especiay during the waterfa approach it is important that the requirements are competey captured and agreed on before the team moves to the design phase, as every new or changing requirement means that the team needs to go back to the requirements phase, which may invaidate work that was aready done in an earier phase. 2.2.2 Design Phase During this phase the team creates a detaied design for the compete system as we as for each of the individua components. This is done at a eve that deveopers can directy transate into code in the next phase. 2.2.2.1 Use Cases The high-eve use cases from the requirements phase are taken and detaied. Use cases describe the behavior and interaction of the system with a user or another system. It may depend on the compexity of the overa system how detaied a use case shoud be, but in genera there shoud be a separate use case for each interaction with the system. Use cases are not ony used in traditiona software deveopment approaches but aso in agie ones, they are caed user stories in agie terms. Especiay in agie approaches it becomes very important that user stories are on the one hand very granuar and on the other hand aso compete in the sense that the team coud decide not to impement certain user stories without impacting other user stories. A feature can be described in one high-eve use case and ater on broken down into severa individua ones (Fig. 2.5). There are a ot of different tempates for use cases avaiabe and each team shoud verify which one fits best for its project. Some sections are common for most of the tempates: Name: The name shoud describe, in two or three words, what the use case is about, ike Update userid & password.
2.2 Waterfa Approach 19 Trading account profie updates Update contact information Update notification settings Update userid & password Update checking account detais Fig. 2.5 A high-eve use case broken into severa more detaied ones Number: Often use cases are numbered within a particuar numbering scheme, which shoud aso show to which part of the system the use case beongs. For exampe, the use case update contact information coud have the number 2-4-5, where 2 indicates that it beongs to the Internet Trading Front End of the system, 2-4 indicates that within the Internet Trading Front End this use case beongs to the high-eve use case trading account profie updates. Version: Some tempates suggest keeping a Version number to be abe to identify the current as we as previous versions of this use case. Usuay it is a good idea to aso keep oder versions of the use case around, so one coud go back and see what was changed when. Goa & summary: The goa is a short summary of what this use case shoud achieve, ike user is abe to update the password. Actors: Actors are individuas acting with the system, ike an end user, an administrator, a cerk, or an investment banker, but can aso be another system or a device, ike an account statement printer. Preconditions: The state the system needs to be in before the use case can be executed, ike, for exampe, the user needs to be authenticated or there must be at east one transaction since the ast time the account statement was printed. Triggers: Triggers are conditions that cause the use case to be executed, ike, for exampe, in the case of an account statement, that 30 days have passed since the ast account statement was printed, or the user is requesting the print of an account statement. The preconditions need to be met before the use case is executed. Main Fow: The main fow describes the primary scenario of the use case, this is often aso caed the defaut case where the use case is executed without any error conditions, exceptions, or aternate seections. Aternate fow: Every path that the use case can take that is not the main fow described above. This can, for exampe, be if a user chooses to seect something other than the defaut seections, such as that he or she wants the account statements maied to the home address instead of viewing it onine. Depending on the number of seections a user can make or the number of input streams from other devices or systems, there coud be quite a number of aternate fows. Exceptions and error conditions can aso be described here, but it may aso make sense to put them in a section on their own.
20 2 Traditiona Software Deveopment Post conditions: The state the system needs to be in after the use case was executed. Like after printing the account statement, the data fied to keep the date for the ast printed account statement shoud be updated and the counter for transactions since ast statement shoud be reset to zero. Comments, author, and date: Of course the use case can contain any further remark or comment that is important for this use case, as we as the author and the date it was created and ast updated. In our view, a nice advantage of using use cases is aso that they can easiy be transated into test cases and test scenarios and therefore give the test team an easy entry into understanding the project and what the soution shoud do. In approaches with a test team that is separate from the deveopment team and where the deveopment team is not producing detaied use cases, it is often very hard for the test team to define the test scenarios. They then often have to re-engineer what the architects, software designers, and deveopers wanted to achieve by impementing a particuar function. This can create a ot of frustration with the test team, but aso with the deveopers, as the deveopers need to educate the test team and wonder why the test team doesn t aready know what a particuar function is supposed to do. The reationship between different use cases and different actors is usuay documented using use case diagrams. The use case diagram contains of course the use cases incuding the sequence of actions. It aso contains the actor interactions with the use cases, in our exampe in Fig. 2.6 these are the ca center representative as we as the customer. The associations between the actors and the use cases are represented by soid ines. In the exampe beow you can see that the customer can ony interact with two of the use cases and that the ca center can interact with a four use cases. Update contact information Update userid & password Ca center Update checking account detais Customer Update notification settings Trading Account Profie Updates System Fig. 2.6 Use case diagram
2.2 Waterfa Approach 21 The rectanguar box around the use cases represents the system boundaries to indicate the scope of the system. The use case diagram is aso part of the Object Management Group s (OMG) Unified Modeing Language (UML). 2.2.2.2 UML The Unified Modeing Language (UML) is a popuar way to mode the system using object-oriented methods. UML is the evoution of and based on Rumbaugh s Object Modeing Technique (OMT) [14], the Booch method deveoped by Grady Booch [1], and Ivar Jacobson s Object-Oriented Software Engineering (OOSE) method [6]. From 1995 on Booth, Jacobson, and Rumbaugh a worked for Rationa Software (now a division of IBM), Rationa asked them to jointy work on a modeing anguage that woud drive the further adoption of object-oriented design. The UML 1.0 specification was adopted by the OMG in 1997 and version 2.0 became avaiabe in 2005. UML provides 13 diagrams to mode a software system, which are organized in three major groups (Fig. 2.7): Structure diagrams: cass diagram, object diagram, component diagram, composite structure diagram, package diagram, and depoyment diagram. Behavior diagrams: use case diagram, activity diagram, and state machine diagram. Interaction diagrams: sequence diagram, communication diagram, timing diagram, and interaction overview diagram. The interaction diagrams are derived from the behavior diagrams. cass diagram depoyment diagram structure diagrams composite structure diagram component diagram object diagram package diagram use case diagram activity diagram state machine diagram sequence diagram timing diagram communication diagram Interaction overview diagram interaction diagrams behavior diagrams Fig. 2.7 The different UML diagrams and their reationships
22 2 Traditiona Software Deveopment Severa toos automaticay generate cass definitions and code fragments based on UML diagrams. 2.2.2.3 Fowcharts Fowcharts have been around for decades and were used ong before object-oriented design was invented. They are especiay usefu for procedura anguages, ike Basic or C, and can be used to design the fows of compex systems (Fig. 2.8). Fow charts are buit using the foowing basic eements: Start and end: Each fow chart has a start eement, indicating the start of the process as we as an end eement, indicating the end of process fow. Processing steps: A rectange is used to represent each step where something is processed, ike a vaue increased or two numbers mutipied. Arrows: The fow and the direction of the process from one step to another is indicated using an arrow. Decision points: A rhombus (a uniatera paraeogram) is used to indicate decision points. From a decision point, there are usuay two arrows eading to the next step, one if the resut of the check is true, and another one if it is fase. Input/Output: A paraeogram is used to represent read and write operations. This may be input from the user, from another appication, or from another device. Deveopers can then directy transate the processing fow into code. The project moves to the impementation phase to code the design as documented after the compete design is finished, reviewed, and signed off by the team as we as the stakehoders. Start Read userid & password No Password correct? Yes Dispay statement Fig. 2.8 A simpe fowchart processing a password check End
2.2 Waterfa Approach 23 Fig. 2.9 Usua workfow within the coding phase of a waterfa project. The dashed ine back from Integrate to Write code shoud not be needed in a perfect waterfa project Write code Unit-test Integrate 2.2.3 Impementation Now that the design is finished and perfect (at east it needs to be viewed as perfect), it is transated into code. Deveopers take the fowcharts, UML diagrams, and the other design documents and transate them into code, component by component or object by object. Each component is unit-tested on its own and a code review shoud be done. Usuay the integration is done at the end of the coding phase or at the beginning of the test phase. This is often the time for surprises, as things may not fit or work together as panned, and the team may have to go back to the design phase to make the appropriate changes. Depending on how tough the schedue was, the project may get in troube right at this point, as the pan was to integrate the components to form a perfecty working system. But now there is a deay due to the integration issues (Fig. 2.9). The risk of a big surprise at the end can be reduced by introducing different miestones during the coding phase, at which point in time the system is integrated and needs to provide a certain eve of functionaity. These miestones shoud ideay be foowed by a set of tests to verify that the functionaity works correcty. 2.2.4 Testing After the deveopers have decared that they are done with the coding phase, what is often aso caed DCUT (Design Code Unit Test), the different units and components are put together into an integrated system. As aready mentioned in the previous chap., this is usuay the time where the project goes south due to many surprises and integration issues. This coud be because deveopers have made mistakes during coding, or that a component A behaves sighty differenty than another component B expected it to and now they simpy don t work together. Even with a waterfa approach is it usuay good to have an integration phase at the end of the coding phase or at the beginning of the testing phase. This integration phase shoud be owned by the deveopment team, which needs to prove that a certain number of test cases can be executed without bugs before the test team accepts the deivered code (this is often caed test entry criteria).
24 2 Traditiona Software Deveopment If this is not done, a arge number of testers usuay fai right at the same tasks (ike for exampe no-one can insta the soution), which is a arge waste of resources. It is usuay hepfu if a smaer number of testers start with some basic test cases and, as soon as those can be successfuy executed, the majority of the test team shoud join the phase. The goa of the test phase is to identify bugs in the software before it is reeased to the end user. There are severa studies that show that fixing bugs becomes more expensive the ater they are found in the deveopment cyce and especiay expensive if they are found by a customer. According to Steve McConne [8], fixing a bug that is found during the test phase coud cost 10 15 times more than if that bug had been found and fixed during the impementation phase. But it can become reay expensive after the product is reeased to the end user. Fixing defects in the fied can cost 10 100 times more than fixing the same bugs in the coding phase. I am sure everyone wi agree with this statement, even without sophisticated studies, as it is simpy much more compicated to debug a customer s system in production, to which the support team may not directy get access and cannot simpy ask the customer to enabe certain ogs and traces to get a hande on the issue. On the other hand it is aso not worth whie to test unti there is no more defect in the product, assuming it were possibe to determine when that state were achieved. The right time to hand over the soution to the customer or to reease the product is usuay when the defect arriva curve of a project fattens out. There has been a ot of research on the subject of computing software reiabiity and there are different modes avaiabe, ike Exponentia, Gamma, Power, or Logarithmic, to name just a few. Pau Li, Mary Shaw, Jim Herbseb, Bonnie Ray, and P. Santhanam have compared the different modes in their artice [7]. For our projects we have chosen the Weibu mode and are quite happy with the resuts (Fig. 2.10). The chaenge with most modes is that someone has to estimate the overa number of defects, which is especiay hard for new projects. 2.2.4.1 Deveopment Test Ratio Another discussion that is usuay a hard debate between deveopment and test in a traditiona setup (with separate deveopment and test teams) is the question of the right ratio of testers and deveopers. There is no genera answer to this question. The answer is, for exampe, different for new projects and existing soutions that are being enhanced. In projects that are enhancing an existing soution or software product, the team aso has to ensure that a the existing functionaity sti works. This requires additiona regression test, which is not needed on an anew project. The test effort usuay aso increases the more operating systems, databases, browsers and so on a product supports. Usuay the deveopment effort for this
2.2 Waterfa Approach 25 Fig. 2.10 Defect mode using the Weibu distribution. As you can see in this project the defect arriva rate is foowing the modeed distribution additiona support (especiay when Java is used) is reativey sma, but the additiona test effort to make sure that everything reay works on, for exampe, a new operating system is often significant. First, the focus needs to be on deveopers doing a good job in deivering high quaity code to the test teams. With traditiona waterfa projects there is too often the probem that the given DCUT date comes and of course the deveopment team wants to make the date. So they rush the code into the ibrary and buid system to be abe to caim that they finished on time. But now, with a buk-oad of new, potentiay not we-tested code, nothing works for a few days unti the team was abe to stabiize the drivers. Therefore it is important to get the right mindset with the deveopers. The ratio of deveopers to testers on the one hand reay depends on the eve of quaity the deveopment team deivers, and on the other hand aso depends on the eve of risk that the team and the company are wiing to take. With traditiona projects, the deveoper to tester ratio is more in the area of 1:1 1:3 [13], with agie projects it is more in the area of 1:3 1:5 [16], due to the fact that more testing is required by the deveopment teams and the traditiona test teams are now more focused on regression testing and verification of additiona patforms. As it is more efficient to invest in deveopers deivering high quaity code than in having testers find the bugs, we think that a ow deveoper to test ratio is acceptabe as ong as the deveopment teams ive up to the quaity.
26 2 Traditiona Software Deveopment 2.2.4.2 Panning and Tracking Test Progress The first step in panning the test is to get a good overview of what the features and functions of the soutions are. Based on this ist of features and functions, an overa test pan needs to be deveoped for the overa project. This test pan shoud contain a the different test phases for the project. Usuay a project has the foowing: Integration & function verification test: This is usuay the first test phase after the deveopers say they are done with coding and unit test. The goa of this phase is to ensure that the functions work as expected and that the overa soution is instaabe and fits together. This test phase usuay aso contains any required accessibiity testing. Gobaization verification test: The focus of this phase is to verify that the soution works with the different anguages it supports, especiay those with doube-byte character sets. Transation verification test: Usuay the deveopment and testing is done with one anguage and after most of the functiona defects are resoved, the product is transated into the different supported anguages. In this phase testers capabe of these anguages verify the transation as we as the ook & fee of the transated project, ike, for exampe, does the transated message text sti fit in the box the deveoper assigned to this message or are the ast few characters missing. System verification test: Here the compete soution is tested as a whoe in compex customer-ike environments under oad. The goa is to verify that the soution functions for severa days or weeks without issues such as running out of memory. Performance verification test: The goa is to verify that the soution meets the performance requirements, especiay with regard to throughput and scaabiity. Acceptance test: Soution deveopment projects for a particuar customer often end with an acceptance test phase during that the customer is vaidating if the soution meets his or her specifications and exceptions, before he or she agrees to cose the project. These different test phases are then usuay panned separatey, and test scenarios are deveoped for each of them. But it is important that there is an overarching test pan covering a the phases that ensures that a areas are covered and on the other hand aso ensures that there are no dupicate test cases. There are often speciaized test teams with skis in each of these test areas. The team then estimates the effort it takes to compete these scenarios. This estimate shoud aso incude the time it may take to reappy new buids and retry the test after defects were fixed. Often the test teams don t directy assign efforts in person days or person weeks, but transated them into abstract units ike points. The progress of a test is often tracked and managed using a so-caed s-curve. The start of a test is usuay sow unti the basic probems are resoved, ike, for exampe, instaation or configuration probems that may bock severa test team members from carrying out their functiona test cases (Fig. 2.11).
2.2 Waterfa Approach 27 100% attempted competed Time Fig. 2.11 Test s-curve The test teams reach their highest productivity as soon as these probems are resoved and a the different test cases can be executed in parae. Towards the end of the test, the number of bocking defects becomes smaer and there is ony a sma number of remaining test cases that are sti faiing. Therefore the s-curve is fattening out. The test teams usuay differentiate between attempted test cases, meaning the team started to test the respective test case, and competed test cases, which are those that finished without remaining bugs. 2.2.5 Support The support phase starts as soon as the soution is handed over to the customers or made avaiabe as a purchasabe product. At the same time the responsibiity for supporting the product is often handed over from the deveopment team to a dedicated support team. Depending on the size of the product, there may be a muti-tiered eve of support: Leve 1: Usuay a ca center with a broad set of knowedge across the compete product portfoio the company may offer. Leve 1 is usuay abe to resove simpe probems by pointing customers to the right documentation. Leve 2: Support speciaists with deep knowedge in a product or a sma number of products. They are experts in these products and can resove the probem, uness it is a bug in the product. Leve 3: Deveopers that resove bugs in the reeased software by providing and testing patches. 2.2.6 Advantages and Disadvantages There are ceary severa advantages with the waterfa approach. The biggest one may be that it is reay the most efficient way to carry out a project, if everything is
28 2 Traditiona Software Deveopment designed at the beginning, based on the compete and fina set of requirements. In the coding phase everything is impemented based on the compete and error-free design. As changes become more and more expensive with this approach the ater they are done, it is important that the pan is executed exacty as panned. Every new or changed requirement or design change necessary due to, for exampe, design faws or things that the team just didn t reaize when the design was agreed on, is a significant incrementa cost. If the waterfa mode is executed thoroughy, a very good set of documentation is produced, especiay during the requirement and design phases ike, for exampe, a detaied ist of the requirements, detaied product specifications, and detaied software designs. Like a the deiverabes of one phase, the design documentation needs to be reviewed as we before the project enters the impementation phase. In the waterfa approach, the test teams are usuay separate from the deveopment teams. The test team receives the documentation (and a good specification can be a cear advantage) and verifies the product against that specification. There aso needs to be good product documentation right at the start of the testing phase to aow the test teams to be productive. But it is amost impossibe to carry out arger projects or projects with some eve of innovation without change. It coud be as simpe as a cient becoming more concrete with his ideas and requirements after they have seen a prototype or a first working version of the soution. In the waterfa approach, this means that the team woud need to go back to the requirements and design phase to add these new requirements to the existing design and update the compete code to support the new requirements. The agie concepts accept that change wi happen and therefore tacke the probem in smaer iterations and with eary and continuous customer feedback. Even today, there are certainy projects that are best done with the waterfa approach, especiay sma projects that are cear and mosty repeating something that was done before. If a project works perfecty fine as panned, then there is no probem. But usuay this is not the case. The waterfa approach significanty imits the options, as a significant number of probems usuay surfaces ony very ate in the project, ike in the test cyce. 2.3 Project Management Triange The Project Management Triange is a nice representation of the three main constraints in which a project usuay finds itsef (Fig. 2.12). A change in one of the three constraints has a direct impact on the other two. If, for exampe, one increases the scope of the project, then this usuay means an increase in cost and time. If you are imited by the time and can t finish the project on time, this coud mean that you have to reduce the scope or increase the cost. The chaenge for the project manager is to manage these three constraints without impacting the quaity of the deiverabe. The earier he can detect a potentia
2.3 Project Management Triange 29 Fig. 2.12 Project management triange Cost Quaity Time Scope Projected Defects Projected Vaid Actua Defects Actua Vaid Tota Backog Tota & Vaid Defects 14000 12000 10000 8000 6000 4000 2000 14000 12000 10000 8000 6000 4000 2000 0 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 week 9 week 10 week 11 week 12 week 13 week 14 week 15 week 16 week 17 week 18 week 19 week 20 week 21 week 22 week 23 week 24 week 25 week 26 week 27 week 28 week 29 week 30 week 31 0 Fig. 2.13 Defect trend with a project that sti has too many defects at the point in time when the software shoud have been ready. The projected trend is the dashed ine. The panned date to have the software competey done is at the point where the dashed ine starts to go fat probem the more possibiities and time to react does he have and usuay the cheaper the resoutions are. In traditiona waterfa projects, these probems usuay arise the first time the project is handed over to test. Before that, the deveopment teams may be abe to cover up their probems, but as soon as a test team tries to perform some functionaity it wi become obvious whether a particuar function works or not. Another chaenge usuay arises in the test phase of a waterfa project if more probems are found than expected and the test cannot cose on time. Figure 2.13 shows an exempary defect trend curve of a project where the time to deiver the soution to the customer has arrived, but the team sti continues to find defects at the same rate as before, which is a cear indication for the product not being ready for prime time.
30 2 Traditiona Software Deveopment In a waterfa project, the options the eadership team has in such a situation are fairy imited. As a functions are impemented, even reducing scope is somewhat difficut, as removing functionaity usuay adds extra effort. Adding more resources to a ate project can often resut in a further deay if these additiona resources need to be trained by the existing team. This often eaves ony two options: extending the project unti a probems are resoved and the required quaity is achieved, or scarifying the quaity of the deiverabe. 2.4 Modified Waterfa Modes There are severa modifications of the waterfa mode to address some of the disadvantages identified with the cassic waterfa mode. 2.4.1 Miestones and Reguar Integration One simpe step to reduce the risk compared to the traditiona waterfa approach is to spit the impementation phase into mutipe smaer phases with integration points caed miestones. This way, there are reguar integration points with working code which can be used to check the project against the pan, and the test teams coud even start to test the features deivered in that miestone (Fig. 2.14). At these miestones the working system can aso be used for presentations to the stakehoders to show progress and request feedback. It may aso hep to add a few freeze days before the actua miestone to stabiize the driver and ony et reay important defects into the driver. These drivers coud aso be used for any type of Apha or Beta program. The important part is that these miestones shoud be panned, not ony date-wise, but aso content-wise, which aows a caibration of the project with regard to where it reay stands. Usuay, if you ask deveopers how far they are with a particuar task, they spend 50% of the time on the first 90% and Requirements Miestone 1 Design Miestone 2 Impementation Miestone 3 Test Miestone 4 Support Fig. 2.14 Impementation phase with miestones
2.4 Modified Waterfa Modes 31 need about the same amount of time to compete the remaining 10% of the work, especiay to unit test and resove the defects found during this test. The approach of overapping some parts of the impementation phase with the beginning of the test phase can aso be used to shorten the overa ength of the project, assuming the required test resources are avaiabe. 2.4.2 Incrementa Deveopment The incrementa deveopment approach takes the miestone approach further by not ony breaking the impementation phase into smaer pieces, but by aso taking the whoe deveopment process and repeating it severa times on subsets of the overa project (Fig. 2.15). By doing so the whoe project becomes more fexibe to react to change and changing requirements. As the design for the compete soution is now done in steps and not overa at the beginning, there may be a higher risk that in a ater round the designs and the code that were done before need to be changed again to support requirements that are just addressed in this round. This approach aso addresses the issue of the waterfa approach that it takes unti the test phase to see the first integrated and working code. The project is spit into severa increments, with each of the increments being a sma waterfa project. This way you do not have a big bang towards the end of the project, but have the project broken into smaer parts that can be managed more easiy. Now it is possibe to show working code much earier to the stakehoders and customers as we as receive feedback eary to have enough time to react and incorporate the feedback into the soution or product. A fu deveopment approach from requirements to test is executed in each round. Requirements Requirements Requirements Design Design Design Impementation Impementation Impementation Test Test Test Support Fig. 2.15 Incrementa deveopment approach
32 2 Traditiona Software Deveopment Further Readings 1. Booch G (1993) Object-oriented anaysis and design with appications, 2nd edn. Addison- Wesey, Reading, MA 2. Booch G, Rambaugh J, Jacaobson I (2005) The unified modeing anguage user guide. Addison-Wesey, Reading, MA 3. Centers for MEDICARE & MEDIAID Services: Seecting a Deveopment Approach 2008 http://www.cms.hhs.gov/systemlifecyceframework/downoads/seectingdeveopment Approach.pdf This paper provides a quick overview on some of the traditiona deveopment approaches, ike waterfa, incrementa, prototyping, and others and describes their strengths and weaknesses 4. Hozmann, Gerard: Economics of Software Verification http://spinroot.com/gerard/pdf/paste01.pdf This is an interesting paper on the price of defects and when the test cut off point is to reease a product or soution to the customer 5. IBM Deveoper Works: http://www.ibm.com/deveoperworks This is a great site for a deveopers with a ot of artices, trai versions, best practices on a kind of software deveopment topics. Under the Rationa section you can for exampe find a ot of usefu information about UML and using UML in practice as we as toos to hep you with your software deveopment project using UML 6. Jacobson I (1992) Object-oriented software engineering: a use case driven approach. Addison- Wesey, Reading, MA 7. Li P, Shaw M, Herbseb J, Ray B. Empirica Evauation of Defect Projection Modes for Widey-depoyed Production Software Systems, FSE 2004, http://www-2.cs.cmu.edu/~pauuo/presentations/fsepresent6.ppt 8. McConne S (2004) Code compete, 2nd edn. Microsoft Press, USA 9. Object Management Group: http://www.omg.org The OMG is a non-profit organization driving standardization in the area of software. OMG specifications incude CORBA but aso the Unified Modeing Language (UML). On OMG s website one can for exampe find an introduction to UML or downoad the compete specification 10. Pan J. Software Testing: 1999 http://www.ece.cmu.edu/~koopman/des_s99/sw_testing This artice provides a good overview and summary on the basic testing approaches as we as provides a good ist of references and further inks 11. Project Management Institute: http://www.pmi.org The Project Management Institute (PMI) was founded over 40 years ago to evove the Project Management profession. PMI offers a series of certification programs for Project Managers; the most known one is the Project Management Professiona (PMP). On PMI s website you can of course find information about PMI, the certification program as we as education programs offered by PMI. But you can aso find a number of interesting artices and reports about Project Management 12. Project Management Institute: Guide to the Project Management Body of Knowedge: PMBOK Guide. PMBOK is the standard guide for Project Managers. The techniques and modes presented and discussed in PMBOK are aso what is tested during PMI s Project Management Professiona s certification. It covers the different phases of a project as we as the different knowedge areas, ike scope management, risk management, time management, cost management, quaity management, human resource management, and others
Further Readings 33 13. Rice R. The eusive tester to deveoper ratio, http://www.riceconsuting.com/artices/tester-deveoper-ratio.htm 14. Rumbaugh J, Baha M, Premerani W, Eddy F, Lorensen W (1990) Object-Oriented Modeing and Design. Prentice Ha, Engewood Ciffs, NJ 15. Software Testing Search Engine: http://www.qainks.com This is a good starting point if you are searching for further artices and software around the topic of testing software 16. Sutherand, Jeff; Bount Jake; Viktorov, Anton: Distributed Scrum: Agie Project Management with Outsourced Deveopment, Agie Internationa Conference 2006, http://www.scrumaiance.org/resources/17
http://www.springer.com/978-3-540-70830-8