Your SlideShare is downloading. ×
Waterfall Model vs Software Stability Modeling
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Waterfall Model vs Software Stability Modeling

4,127
views

Published on

Published in: Technology

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

  • Be the first to like this

No Downloads
Views
Total Views
4,127
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. CmpE 203 Fall 2009 Assignment 2 Comparative Study – Software Development Methodologies: Waterfall Model vs Software Stability Model Shivanshu Singh <shivanshukumar@gmail.com> SJSU ID: 006488300 CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 1 of 17
  • 2. CONTENTS Abstract ................................................................................................................................ 3   1   Introduction .................................................................................................................... 3   2   Related Areas .................................................................................................................. 4   2.1   Iterative Waterfall Model............................................................................ 4   2.2   V Model ...................................................................................................... 5   2.3   Incremental Development and prototyping ................................................ 6   3   Existing Approach .......................................................................................................... 6   3.1   Existing Approach ...................................................................................... 6   3.2   New Approach ............................................................................................ 8   4   Criteria .................................................................................................................. 10   4.1   Ease of Use ............................................................................................... 10   4.2   Development Costs ................................................................................... 10   4.3   Flexibility.................................................................................................. 10   4.4   Dynamic Analysis..................................................................................... 10   4.5   Testability ................................................................................................. 11   4.6   Proper Regulation& Requirement Fulfillment ......................................... 11   4.7   Size of Development................................................................................. 11   4.8   Quality of Product..................................................................................... 11   5   Comparison .................................................................................................................. 11   6   Analysis .................................................................................................................. 13   7   Discussion .................................................................................................................. 14   8   Conclusion .................................................................................................................. 15   Memo .............................................................................................................................. 16   References............................................................................................................................. 17   CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 2 of 17
  • 3. Abstract The traditional software development methodology of the Waterfall Model has been in used since a long time and has been the guideline for development for many a software projects in the past. Also, the figures related to the success rates and costs involved in undertaking the projects in the past using this development methodology are available now as this model has been used on a fairly large scale. The traditional software development figures state that almost 33% of projects undertaken have failed and we are not aloof from the humungous development and maintenance costs. Here I examine the old approach with the new software development methodology called Software Stability Model, contrasting the aspects of both these models to see what the new approach has to offer over the old one and how they fare in comparison to one-another. 1 Introduction The Software Stability Model is a new way of designing and developing software and does not go by the old school methods of software development. Instead of the application specific development approach followed by the waterfall and the related development models, the software stability model focuses on the overall picture and has a holistic approach to developing software, designing keeping in mind the ultimate goals of the software that we are developing rather than concentrating on the specific application. The focus is on longevity of software and a generis development which can be reused in any related context, there by reducing the maintenance costs which traditionally have accounted for more than 80% of the total cost of ownership of any enterprise class software. The software stability model has the concept of designing the software around Enduring business concepts or EBTs, which are realized through its workhorses, Business Objects or BOs, which are in turn implemented through the Industrial Objects or IOs which are the application and domain specific components of the system and implement the BOs. The software developed is stable over time and changes in the business environment can easily be reflected in the software by either changing the IOs or restructuring the BOs. If the business scene changes such that the system has to now ctaer to different goals then the related EBTs can be added / deleted according to the system needs and the development / maintenance costs hence get reduced as the system is never restructured completely to accommodate such changes. In this report I have described the traditional approach of Waterfall development model, its related variations and steps taken by the software industry to try to fix the problems with traditional waterfall model and also the new approach of Software Stability Model. Then I have shown how they fare as compared to one-another and analysis and discussion on the various metrics and criteria that have been used to judge the two approaches. CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 3 of 17
  • 4. 2 Related Areas There are a number of related areas, which aim at providing a software development methodology, especially w.r.t. traditional waterfall development model. The discipline of software engineering realized the ill effects of waterfall model, though being simple, its largely inadequate and people have tried to attempt variations of this model which might provide better results and address the concerns. Some of the related work is as follows: 2.1 Iterative Waterfall Model The traditional waterfall model is a sequential development model in which we simply go from one phase to the other as shown in Figure 1 - Traditional Waterfall Model but if we have to go back a phase to something we cannot do that, it’s a very rigid model and changing anything is just not possible if we are past any phase which calls for obvious defects in the system. Maintenance is also high on costs as we need to redo the whole process if we have to do so, as stated by the model. Requirements Analysis Design Coding Testing Maintenance Figure 1 - Traditional Waterfall Model Requirements Analysis Design Coding Testing Maintenance Figure 2 - Iterative Waterfall Model Whereas in the iterative waterfall model (Figure 2 - Iterative Waterfall Model), one can go back a phase if one has to if changes are required. However still the process is fairly rigid. If we have to for example, go back from coding to requirements specification for CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 4 of 17
  • 5. some reason, which maybe changes in customer requirements due to change in business scene or any such thing, we still have to go back the entire thing and redo whatever was done till now since the design we very requirements and application / domain specific without any flexibility whatsoever. Also, the model lack any guidelines on what has to be done and what can be optional, the level of documentation required is also up for individual interpretation, which sometimes if overdone may result in unprecedented costs or if underdone may result in humungous maintenance costs as no one would know how the system was developed. 2.2 V Model Another approach to solving the problems with the traditional waterfall model was the V model. Figure 3 - V Model [1] The V model was good w.r.t. the traditional waterfall model since it gave an equal emphasis to testing the software at each level than doing it all at the very end and redoing everything if something was wrong. The V model is however dead now.[1] The main reasons why the V model is inadequate is because it is too rigid and presents a very unrealistic view of the software development process to the project manager isolating him/her from the real world issues and misleading the project to consequences which are either very costly or are complete failures. The model lays heavy emphasis on testing but it still does not provide any flexibility to change the system, moreover the testing is done in a disjoint fashion and on tangibles. Unit testing being done as a separate activity for each component and each unit of the system can be extremely time consuming and costly.[2] CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 5 of 17
  • 6. 2.3 Incremental Development and prototyping Moving on from the traditional waterfall model, another approach, which claims to promise fast deliverables and through testing at various units of deliverables is the incremental and prototype based approach to software development. This approach is good for specific types of development e.g. when software has to be released in increments while adding functionality over time. The increments aim at solving the problem in a set of smaller stages of the software development cycle. Though much better than the traditional waterfall model, it is still not adequate when it comes to parallel development and a lot of testing effort is required in this. Moreover the testing will not be proper as the holistic system testing will only be partial else the costs involved will be huge due to redoing the same process in subsequent iterations of any given iteration. 3 Existing Approach Described in this section, are the two approaches software modeling and development. Presented here are the basic concepts related to each one of them and an example of a system as in, both traditional development (waterfall) methodology and according to the Software Stability approach. 3.1 Existing Approach The existing approach to software development is a sequential application specific approach to software development. It is simple and easy to understand though, but it is not quite efficient and may lead to blunders if development is not done with utmost care. The model hardly does anything to aid an efficient software development. It is a domain specific approach to software development and is application centric. For example: Lets consider the case of a company doing “corrective action” to reduce its costs. Traditionally this system would go through requirements specifications, analysis and then design, which would produce a class diagram such as this one: CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 6 of 17
  • 7. Figure 4 – Corrective Action - Traditional Software development Key Features: • Development Style o Sequential: This system is developed sequentially and it has no scope of parallel development except for the fact that the classes can be developed parallely but that is almost always done by distributing the work amongst individual developers. No further level of concurrent development can be done. o Application Specific: with only one application of corrective action being implemented here. The system needs to be changed or an entirely if a new scenario is added to the application of if the same corrective action of cutting costs is done else where say in military, where the military wants to do a corrective action of stopping smuggling of arms. • Testing o When: Done at the very end and is not done throughout the project development lifecycle. It is done only after the final product is made, if ay changes required we need to go back and make changes at the very first step. o What: Tangible classes are tested. • Scope CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 7 of 17
  • 8. Limited to just the application specific classes and the model has no way which can guarantee if the system developed actually meets the requirements that were set forth. 3.2 New Approach The new approach i.e. Software Stability Model has concepts such as EBTs: the ultimate goals of the system, the BOs: the business objects that help realize the goals or the EBTs and the IOs: the Industrial Objects, classes which implement the business objects. Modeling here ensures that the ultimate goals (which map to the system requirements) are met. Since they are enduring themes, they are stable and constant over time and so the system’s IOs can be changed according to changes in scenario while ensuring that the system is still meeting the requirements. Below is a mapping from the Waterfall Model to the Software Stability Model of software development. Requirements EBTs / Stable Analysis Patterns 2+ EBTs form an Architectural Testing BOs / Stable Design Patterns Pattern Design Maintenance Knowledge Map Implementation Application Level & Testing IOs / Industrial Objects   Dynamic Deployment Analysis Waterfall Model Software Stability Model Figure 5 - Mapping between Waterfall Model and Software Stability Model The example of corrective action as mentioned above, if done using the stability modeling approach would result in a system design as shown in Figure 6 – Corrective Action - Software Stability Modeling. CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 8 of 17
  • 9. Figure 6 – Corrective Action - Software Stability Modeling Key Features: • Development Style o Concurrent – all at one: The software is developed in a concurrent fashion, where an EBT and all related BOs and corresponding IOs are implemented at once. High degree of parallel development is possible, as the different EBTs and related BOs and IOs can be parallely developed and integrated later with only a little effort, saving on time and resources. o Generic: The software is not application specific since it implements the EBTs and BOs which are stable over time. The system therefore is easily customizable with change in needs and only a part of the system needs to be reworked, i.e. the IOs according to the new requirements than having to change the entire system. • Testing o When: At all stages right from requirements specifications to coding the system. CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 9 of 17
  • 10. o What: The BOs and the EBTs and not the tangible classes: IOs as the system is good if the core i.e. the EBTs and BOs work fine. IOs come and go an testing them does not ensure anything. • Scope The system is made on the concepts of EBTs and BOs ensuring that even if changes are made to the IOs the system is stable and is actually still meeting the original requirements. 4 Criteria There are several important criteria that can be used to evaluate the effectiveness of a software development methodology and the product produced through it, as such. Presented below are some such criteria and their respective weights which tell us how important that particular criteria is in contrast to the rest of them being used to draw a comparison later in this report. 4.1 Ease of Use The model of development being followed should be easy to understand as this is essential to the development, if the methodology is not very well understood, it will not be followed correctly leading to problems later on. Weight: 10% 4.2 Development Costs The development costs incurred during the development have to be as low as possible and the development methodology should promote this, the more cost effective a development methodology is the better would be the solution and makes more business sense. Weight: 15% 4.3 Flexibility The development methodology needs to be flexible enough to accommodate changes in requirements during the development process. Since in today’s world, the business changes very rapidly, such changes should be absorbed dynamically. The Methodology should hence be quite flexible and not rigid. Weight: 20% 4.4 Dynamic Analysis Another criterion for judging the ability of a development model is the capability to analyze the implementation in a dynamic fashion, and improving upon it on the go. The system CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 10 of 17
  • 11. should be such that you can evaluate the final implementation for aptness and change it if the need be. Weight: 20% 4.5 Testability The software development model must facilitate testability if the system is not adequately tested the chances are that the system will malfunction resulting in business losses of varying degrees. Weight: 10% 4.6 Proper Regulation& Requirement Fulfillment The model should provide guidance to the software development and should have checks in place to see if the software development is going in the right way and if the software being developed is consistent with the requirements and goals to be met. Weight: 15% 4.7 Size of Development The costs, complexity, efficiency and reliability are affected to a large extent on the size of development that has to be done for building a software. If this size is less than profits are more, the system is more thoroughly tested and its cost effective as well. Weight: 5% 4.8 Quality of Product The more thoroughly the system can be tested the more quality is reflected and if this quality assurance is done right throughout the development lifecycle, the better and more robust the system will be. Weight: 5% 5 Comparison This table presents a comparison of the Waterfall Model with the Stability model based on the criteria mentioned above and comes out with a score for each model for each criterion and a total score. Score Sl Criterion Waterfall Model Software Stability Model No. On a scale of 10 Weighted On a scale of 10 Weighted Ease of Use 1. 8.5 8.5 5 5 (10%) Development Costs 2. 2 3 8 12 (15%) Flexibility 3. 1 2 9 18 (20%) CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 11 of 17
  • 12. Dynamic Analysis 4. 1 2 9 18 (20%) Testability 5. 2 3 9.5 9 (10%) Proper Regulation & 6. Requirement Fulfillment 6 4.5 8 12 (15%) Size of Development 7. 5 2.5 8 4 (5%) Quality of Product 8. 5 2.5 9.5 4.75 (5%) TOTAL SCORE 28 82.75 Table 1- Comparison between Waterfall Model and Software Stability Model based on the given criteria     Figure 7 - Chart depicting the weighted value comparison between the waterfall model and the software stability model according to the various comparison criteria ( Higher score = Better )     Figure 8 - Overall Score comparison of the Waterfall Model with the Software Stability Model. (Higher score = better)   CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 12 of 17
  • 13. 6 Analysis Waterfall Model: The Waterfall model is a rather simple model and so its easy to understand and follow. The model is very structured and extremely organized. It gives a clear path of developing any software to a software development team. The stages of analysis and design move through rather quickly and more quickly than that in the Software Stability Modeling approach. This however is misguiding at times and the methodology as such doesn't have any guidelines to the way this analysis and design has to be done. It depends more on individual perception of it rather than anything else, making the system vulnerable to picking up certain design problems and owing to the process model, these will never surface until the software is actually developed or tested or even worse, deployed in a production environment. The Waterfall model is very strict and its this strictness of it that calls for problems. The system relies heavily on upfront, very accurate and complete requirements specification, which will remain constant throughout, which hardly is the case in any typical software development project. Also, since there is no way to go back to correct the design issue if its detected in the later development or testing stages, a rework needs to be done which costs a lot of time and money. Moreover the emphasis laid on documentation is very flexible. Though there are certain deliverables recommended to be completed at each stage of development, there is no minimum or maximum set. What this may lead to is too less or at time too much of documentation, where the former may limit the understanding of the system internals from future users and developers and maintainers, the latter may result into huge costs due to just the documentation, which in turn may result into delays in the work processes at some stage or the other as a lot of documentation has to be parsed through to get to anything. The system developed is very domain and application specific and making changes to fit in the change in requirements costs a lot of money. The Waterfall model scores low on this front as compared to the Software Stability Model as Software Stability aims at the ultimate goals than catering to application specific and rigid development. Software Stability Model: The Software Stability Model being new and by the virtue of its method is difficult to understand at first and also since we are used to developing the software in the traditional way, there is a paradigm shift which may take some time to get accustomed to and to start thinking in terms of ultimate goals and business objects that realize those goals. The approach taken over here, is developing with the ultimate goals in mind and developing and testing it all at once and so it provides a better way to develop software as the costs are lower in this case; the model guides the development and also makes sure that the design meets the CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 13 of 17
  • 14. requirements. If the design in going in a way that the rules of the model are not met then that means that the design is flawed, so it has an inherent ability to correct itself. The testing done in this approach is done right from the requirements specification level all the way downwards. Since the underlying goals and their business objects are tested instead of testing tangible application specific objects, the testing is more thorough as it tests the functionality at its core. The cost are also lower as compared to the waterfall model and as concurrent development is possible as well as scaling is inherent. The system is naturally scalable as well sine we can add as many EBTs – vertical scalability and more IOs to the existing BOs – horizontal scalability. Testing is done throughout the requirements specification to implementation phases. Maintainability is high as the system’s IOs can be changed to suite a new scenario or a new application, which is done without changing any of the BOs or the EBTs, and thus is just a small fraction of costs as compared to the costs involved in doing the same if we were to develop the software following the waterfall model. Also, the model provides us with the capability of dynamic analysis, which is to evaluate the implementation and changing / refining the system based on this evaluation and then continuing this process. This enables high quality of the software being developed. All these factors make it much more cost effective at the end than the Waterfall model. The product developed is much more efficient and maintainable – stable over time, making it a better development methodology. 7 Discussion The criteria mentioned above, which are being used to evaluate the two software development methodologies, were chosen because hey cover the various aspects of any software development process and also go ahead to compare the various key properties of the product that comes out as a result of following any software development methodology. Certain criteria e.g. Scalability and Stability were not chosen as they are inherent in the Stability Model and are the added values that it provides. Evaluating and comparing two methodologies on ground of the added pluses of one of the approaches does not bring out the right comparison; having them as a separate measure will just move the focus away from many other things that matter. Other criteria such as Requirements fulfillment and Flexibility were chosen to be included in the list of criteria being used for evaluation because both of these are very essential in today’s world of software engineering. The ever changing and quickly adapting business scene needs to be implemented through the related software almost immediately and the adaptation time should be minimum with low costs. The maintenance costs of any traditional software have been the largest CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 14 of 17
  • 15. chunk of the total costs of any software development projects and this has to stop. Maintainability is hence an important factor. The comparison drawn out over here has been done from a fair perspective however being a software engineer myself I cannot help but praise the good qualities of Software Stability Model an the numerous flaws that the waterfall model has, which have also been recognized by the industry.[3] 8 Conclusion The comparison made above between Waterfall model and the Software Stability Model shows us how they fare in comparison to one another. While Waterfall model has the advantages of being a rather simple model to follow and provides some guidance in terms of what to do to o about a systematic development of any software, it has many inherent flaws. It is rigid and very application specific and may result into humungous maintenance costs. The Software Stability model on the other hand not only guides the whole process, it also has an element of self-correcting the design inbuilt into it. The focus is not on an application or domain specific development but to cater to the ultimate goals, thus providing better streamlines with the requirements and a lot lesser maintenance costs. I have been involved with studying , designing and developing with both Waterfall Model as well as Software Stability Model and so based on my experience and the study and the comparison in this report, I come to find that The software stability model goes a long way in ensuring the success of the project than the waterfall model. The waterfall model may be suitable for very small scale development but any enterprise level software or for that matter any regular software of today is better off with the Software Stability Modeling approach. CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 15 of 17
  • 16. Memo From Shivanshu Singh Dated To Prof. M. E. Fayad 10/11/2009 Comparison between Waterfall Model and Software Stability Model – Methodologies Subject of Software Development. Description The traditional software development methodology of the Waterfall Model has been in used since a long time and has been the guideline for development for many a software projects in the past. Also, the figures related to the success rates and costs involved in undertaking the projects in the past using this development methodology are available now as this model has been used on a fairly large scale. The traditional software development figures state that almost 33% of projects undertaken have failed and we are not aloof from the humungous development and maintenance costs. Examined here are the old approach in comparison with the new software development methodology called Software Stability Model, contrasting the aspects of both these models to see what the new approach has to offer over the old one and how they fare in comparison to one- another. Major Findings • Though Waterfall Model is a fairly simple model to use when Software Stability is not and requires effort to master, and while waterfall is a much more structured and organized model of development, the Software Stability model is much better in terms of development costs, flexibility in development and in meeting the requirements of the business by developing software with the ultimate goals as the focus than doing it in a domain specific and application instance specific way. • Software Stability is harder to follow than Waterfall model but is significantly better, it also enables features like stability over time and scalability to be inbuilt into the system being developed which the waterfall model lacks. • Considering 8 criteria of evaluation used in the report and the weighted average of individual scores for each methodology for each criterion, the Software Stability Model scores about 75% as compared to the Waterfall Model, which scores about 25%. Conclusion While Waterfall model has the advantages of being a rather simple model to follow and provides some guidance in terms of what to do to o about a systematic development of any software, it has many inherent flaws. It is rigid and very application specific and may result into humungous maintenance costs. The Software Stability model on the other hand not only guides the whole process, it also has an element of self-correcting the design inbuilt into it. The focus is not on an application or domain specific development but to cater to the ultimate goals, thus providing better streamlines with the requirements and a lot lesser maintenance costs. The study and the comparison in this report, shows that the software stability model goes a long way in ensuring the success of the project than the waterfall model. The waterfall model may be suitable for very small scale development but any enterprise level software or for that matter any regular software of today is better off with the Software Stability Modeling approach. CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 16 of 17
  • 17. References                                                                                                                 [1] http://www.harmonicss.co.uk/index.php/tutorials/software-engineering/56?task=view [2]Brian Marick, "New Models for Test Development" [3] McConnell, Steve (2004). Code Complete, 2nd edition. Microsoft Press. ISBN 1-55615-484-4. CmpE 203 Fall 2009 | Assignment 2 | Shivanshu Singh 006488300 Pg 17 of 17