Assignment 1 Q1. One of the biggest software project failures was the project on ERP implementation handed over by Bridgestone Company to IBM. IBM was supposed to play the role of ERP integrator and was required to install the ERP package throughout the company. However after spending $75 million for the system, the company claimed that the project failed on going live. This disrupted its key processes like inventory management and customer delivery. As IBM failed to provide the required services, it resorted to the war of words with its client, Bridgestone. Finally, Bridgestone had to hire the services of SAP directly to resolve its problems (Krigsman, 2013). Bridgestone had to hire SAP directly to resolve its problems which were supposedly created by IBM. So they sued IBM for recovering losses and damages incurred. IBM had adapted another very unusual approach. They engaged in a war of words with its client. Evidently the two major reasons for the failure of the project were that IBM had set wrong expectations and there was communication gap which resulted in very heavy losses for Bridgestone. The stand taken by IBM in this case clearly departed from the standard procedure in dealing with the clients. That Bridgestone had sued IBM for fraud and breach of terms of contract shows that IBM had failed to deliver as per the terms of the contract. Cleary they had set wrong expectations which were treated by Bridgestone as fraud in the lawsuit (Krigsman, 2013). Q2 Part A A conventional approach which is used in the Software Development is known as the Waterfall Model. This is a traditional approach wherein the first stage is the Planning stage. The next stage in the project progress is the design phase wherein the conceptual model is prepared which creates the complete blue print of the project. Once the design is complete, the following phase is the implementation phase. Here the design is given shape in terms of developing the product and often involves programming, testing and debugging. This stage requires on the unit testing and debugging. Once the units are developed, the modules are then integrated and this stage is the integration and system testing stage. The system is subjected to the integration testing and debugging. Here the product is tested for its
completeness. Finally the product is completed and ready for deployment and commissioning. This stage requires the installation, deployment and training the end users on the product (Royce, 1970). Part B Advantages of the Waterfall model are that it is traditional model and there are lot of success stories associated with it. This model is very simple and easy to understand and implement. It is easy to manage as there are clearly defined stages which run sequentially. As the stages are completed one at a time so it can be easily controlled. The stages are predictable in nature and the teams are focussed only on that particular stage. Hence, the resource deployment can be optimized as, for instance, we do not need a programmer at all times (Budgen, 2003). Part C Although, the waterfall model is good in several respects but, it has its own limitations. For one, it is sequential and once a stage is completed the project progresses to the next stage. However, if some flaws are introduced in the previous stages, they get propagated to the next stage as there is no way to review the previous stage. Some software projects do not follow the sequential flow and it is difficult to use waterfall model for such project. For instance, the clients in the software projects often request changes from the initial requirement specifications. In these cases it is difficult to accommodate such changes when using the waterfall model. Part D The below figure depicts the waterfall model (Sommerville, 2011).
In a scenario when requirement stage is considered to be final and in the next design stage it is noticed that some parts in requirement specifications are wrong, then dealing such situations is difficult with waterfall model. As depicted in the above Figure, the requirements stage is the first stage and after that we have the systems design phase. No way can we return to the previous stage as there is no such provision in the waterfall model. However, in our case, when we have clearly noticed that an error is noticed in the design phase, then we need to go back to the requirements phase. Otherwise there is no point to proceed further as this error will get propagated in to the next stages. Hence the following changes in the diagram can be proposed:
The orange lines show that we can go back to the previous stage, if the critical need arises. Thus, not only in the design stage, but if an error is detected at any future stage, and the error is a critical one then one can always go back to the previous stage for correction. There should be a provision such that the updates can be made in the previous stage so that these changes can be propagated to the next stage. If we know that there is an error in the previous stage and if we continue and if the error is critical, then the project is bound to fail. So it is better to rectify these problems at the earliest opportunity. Q3 Agile Methods Part A The incremental model is where one divides the complete requirement into various multiples. It is like several waterfall models each contributing incrementally to the next stage of development. Major advantage is that it is very flexible and if any problem is noticed at any stage, the change can be easily managed. Another advantage is that at the end of each cycle a working model gets prepared so that the client has an early access to a working model. Next cycle just adds a function to the already working model. So the focus is only on the new addition. The chances are that it will be successfully executed as the scope is limited only on that particular addition. At the end the product is readily acceptable to the client (Cockburn, 2001). Part B Test first development is an innovation in Agile Technique. Testing first helps to define the interface early where one can test and the specifications of the behaviour or the functionality
which needs to be tested. So the issues with requirements related to interface and the related misunderstandings are reduced from an early stage. Test first technique also assists programmers to have good understanding of the system requirements. This technique also helps to clarify the requirement being implemented. Normally a test is written as a program instead of data so it can be executed automatically. The test comprises of certain check which shows that the program is working correctly. Since the test program is written in parallel with the code to be tested so once the code is completed the test can be conducted immediately. So in test first technique the development team can assess every scenario and breakdown the task. The tasks represent discrete features of the system and the unit test can be performed (Ambler and Jeffries, 2002).. Part C The reasons as to why the productivity rate of programmers working as a pair might be more than half that of two programmers working individually is as follows: 1. The sum productivity of two programmers would actually increase when they are paired as the chances are that they will produce less defective codes. Usually the same keyboard and mouse slides between the pair programmers working on the same piece of code. They both concentrate on the code and produce better quality work which has lesser number of errors. It mat be possible that the 2 programmers working independently produce more lines of code, but if the codes have large number of defects then the overall time taken is much larger. 2. The pair programmers working together will have increased communication and they would discuss the software before development. The chances are that there work will have lesser false starts and less reworks. Individual programmers may have lesser channels of communication and they may possible chose a wrong approach and then would require a major rework. So although they produced more lines of code but in wrong direction. This will result in more time taken. On the other hand if there are lesser errors and lesser rework required by the output of pair programmers than there will be an overall saving in the time consumed. 3. The output from the efforts of the pair programmers is shown to be of better quality. The pair programmers will encourage refactoring of the code. Usually there will be more efforts to edit and enhance the code to make it more effective, efficient and adhering to coding standards (Cockburn and Williams, 2001)..
Q4 Project Scheduling Part A The given project has following tasks as shown below: Task DurationDepends on T1 1 T2 3 T3 5 T4 3 T1 T5 2 T1 T6 2 T1,T3 T7 3 T2,T3 T8 4 T4,T5,T6 T9 3 T5,T7 T10 2 T7
The activity network chart is given below:
Critical Path:T1:T3:T7:T8:T10 Part B The Gantt Chart is prepared in Excel and is presented herewith. The chart shows the early start time and the Finish time.
T10 T9 T8 T7 T6
Duration EST
T5 T4 T3 T2 T1 0
2
4
6
8
10
12
14
16
The date for the chart is also given below: Task T1 T2 T3 T4 T5 T6 T7 T8 T9 T10
EST
Duration 1 1 1 2 2 6 6 9 9 12
1 3 5 3 2 2 3 4 3 2
The chart was made by selecting the stacked bar graph, and then making the first part invisible. The grid was chosen so that it assists in the visual identification of tasks. Part C In this part I have assumed that the 3 developers are available -- Bob, Sue and Ann, who work for this project. I also assumed that each task would be allocated to only one developer. I allocated the tasks to them to complete the project as early as possible. I have shown this graphically on the staff allocation chart. I started by allocating them to the critical tasks as shown below:
Task T1 T2 T3 T4 T5 T6 T7 T8 T9 T10
EST
Duration 1 1 1 2 2 6 6 9 9 12
1 3 5 3 2 2 3 4 3 2
Allocated Bob Ann Sue Bob Sue Bob Ann Bob Ann Sue
The critical tasks have been highlighted. I have used a drawing tool to accomplish the task by following: •
I used the drawing tool to turn on the grid.
•
The vertical line represents the 0 time. The names are put to the left
•
Then I created horizontal bars of the lengths that are proportionate to the number of
weeks of the task. The width of the bars is made 3/4 of the grid size. The bar names are given in correspondence with the tasks. •
The bars are moved into the grid rows associated with the developer name, and
positioned them accordingly. Based on these instructions I first allocated the work as per the below allocation table:
Task T1 T2 T3 T4 T5 T6 T7 T8 T9 T10
Allocated Bob Ann Sue Bob Sue Bob Ann Bob Ann Sue
Weeks 1 3 5 3 2 2 3 4 3 2
Again the critical tasks are highlighted. Based on this allocation table I have made the graph using a drawing tool. The diagram is shown below:
References Ambler, S. W. and Jeffries, R. (2002). Agile Modeling: Effective Practices for Extreme Programming and the Unified Process. New York: John Wiley & Sons. Budgen, D. (2003). Software Design (2nd Edition). Harlow, UK.: Addison-Wesley. Cockburn, A. (2001). Agile Software Development. Reading, Mass.: Addison-Wesley Cockburn, A. and Williams, L. (2001). The costs and benefits of pair programming. In Extreme programming examined. (ed.). Boston: Addison-Wesley. Krigsman, M. (2013). PR finger pointing: IBM and Bridgestone wrangle over failed ERP.
Royce, W. W. (1970). Managing the Development of Large Software Systems: Concepts and Techniques. IEEE WESTCON, Los Angeles CA: 1–9. Somerville, I (2011).Software Engineering. 9th Edition. Addison Wesley. Available from http://faculty.mu.edu.sa/public/uploads/1429431793.203Software%20Engineering%20by %20Somerville.pdf Zdnet. Available from http://www.zdnet.com/article/pr-finger-pointing-ibm-and-bridgestonewrangle-over-failed-erp/