Softpanorama
(slightly skeptical)
Open Source Software Educational Society
May the source be with you, but remember the KISS principle ;-)
Softpanorama Search
|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
Softpanorama Search
|
| Recommended Links | Recommended Papers | Waterfall model | Extreme programming | Prototyping | Spiral model | |
| Program Understanding | OSS development model | Project Management | Reverse Engineering Links | Humor | Etc |
A software life cycle model depicts the significant phases or activities of a software project from conception until the product is retired. It specifies the relationships between project phases, including transition criteria, feedback mechanisms, milestones, baselines, reviews, and deliverables. Typically, a life cycle model addresses the phases of a software project: requirements phase, design phase, implementation, integration, testing, operations and maintenance. Much of the motivation behind utilizing a life cycle model is to provide structure to avoid the problems of the "undisciplined hacker" or corporate IT bureaucrat (which is probably ten times dangerous then undisciplined hacker). As always, it's a matter of picking the right tool for the job, rather than picking up your hammer and treating everything as a nail.
Software life cycle models describe the interrelationships between software development phases. The common life cycle models are:
The "waterfall model" was probably the first published model and as a specific model for military it was not as naive as some proponents of other models suggest. The model was developed to help cope with the increasing complexity of aerospace products. The waterfall model followed a documentation driven paradigm.
Prototyping model was probably the first realistic of early models because many aspects of the syst4m are unclear until a working prototype is developed. It was advocated by Brooks in early 60th.
A better model, the "spiral model" was suggested by Boehm in 1985. The spiral model is a variant of "dialectical spiral" and as such provides useful insights into the life cycle of the system. But it also presuppose unlimited resources for the project. No organization can perform more then a couple iterations during the initial development of the system. the first iteration is usually called prototype.
Prototype based development requires more talented managers and good planning while waterfall model works (or does not work) with bad or stupid managers works just fine as the success in this model is more determined by the nature of the task in hand then any organizational circumstances. Like always humans are flexible and programmer in waterfall model can use guerilla methods of enforcing a sound architecture as manager is actually a hostage of the model and cannot afford to look back and re-implement anything substantial.
Because the life cycle steps are described in very general terms, the models are adaptable and their implementation details will vary among different organizations. The spiral model is the most general. Most life cycle models can in fact be derived as special instances of the spiral model. Organizations may mix and match different life cycle models to develop a model more tailored to their products and capabilities. there is nothing wrong about using waterfall model for some components of the complex project that are relatively well understood and straitforward. But mixing and matching definitely needs a certain level of software management talent.
|
|||||||
Top Ten Principles of Conventional (Waterfall) Software Management
Freeze requirements before design. This is the essence of a requirements-first process: The project team strives to provide a precise requirements definition and then implement exactly those requirements. Changing requirements can cause significant breakage in the code and test phases; consequently, requirements must be completely and unambiguously specified before the team makes major investments in other design and development activities.
Avoid coding prior to detailed design review. Again, because design changes can also cause significant breakage in the code and test phases, the team needs to ensure that the whole design is mature and complete before beginning the coding phase, when there will be much more resistance to change.
Use a higher-order programming language. Higher-order programming languages avoid a substantial set of error sources (through advanced data typing, interface separation, and packaging and programming constructs) and permit the software solution to be "programmed" in fewer lines of human-generated code.
Complete unit testing before integration. Whereas the design flows "top down," the test process flows "bottom-up": The smallest units are completely tested prior to delivery for integration testing. This sequencing constraint is an attempt to capture more bugs at the unit level, prior to integration, when they can cause substantially more scrap and rework.
Maintain detailed traceability among all artifacts. To ensure that program completeness and consistency can be maintained at each stage, the requirements artifacts need to be traced to design artifacts and test artifacts. When changes are proposed or identified downstream, this provides a full view of the change's actual or potential impact for assessment.
Document and maintain the design. Design without documentation is not design. In early phases, the documentation is the design. In later phases, as code becomes the primary engineering artifact, design artifacts must be updated to ensure consistency and provide a basis for decision making about changes.
Assess quality with an independent team. To maintain a separate reporting chain from the analysts, designers, and testers, the project should assign to an independent team responsibility for ensuring overall adherence to quality standards -- for both the product and the process.
Inspect everything. Inspecting the detailed design and code is a much better way to find errors than testing. Ensure that inspections cover all requirements, design, code, and test artifacts.
Plan everything early with high fidelity. A complete, precise plan down to the "inch-pebble" level that lays out detailed activities and artifacts over the entire schedule is necessary to identify critical paths, manage risks, and evaluate programmatic changes.
Control source code baselines rigorously. Once artifacts get into the coded stage, rigorous configuration management is necessary to maintain baseline control of formal releases in the test process, and to transition the product to a zero-defect state suitable for release.
This article introduces and compares software development methodologies. This information will help you recognize which methodologies may be best suited for use in various situations. The target audience is all personnel involved in software development for the DoD. No attempt has been made to cover methodologies that are most applicable to smaller projects that can be accomplished by five or fewer software engineers. You may learn about several of these in [10]. Since the intended readers should consider government software standards in their use of methodologies, background on these standards is included.
What's the 'spiral model'?
Date: 10 Oct 1998
Archive file: spiral
(1) Barry Boehm, "A Spiral Model of Software Development and Enhancement",
ACM SIGSOFT Software Engineering Notes, August 1986.
(2) Barry Boehm "A Spiral Model of Software Development and Enhancement"
IEEE Computer, vol.21, #5, May 1988, pp 61-72.
Basically, the idea is evolutionary development, using the waterfall model for each step; it's intended to help manage risks. Don't define in detail the entire system at first. The developers should only define the highest priority features. Define and implement those, then get feedback from users/customers (such feedback distinguishes "evolutionary" from "incremental" development). With this knowledge, they should then go back to define and implement more features in smaller chunks.
Internal
External
Software development process - Wikipedia, the free encyclopedia
Comparison of Software Development Methodologies - January 1995
All the contributors to an XP project sit together, members of one team. This team must include a business representative -- the "Customer" -- who provides the requirements, sets the priorities, and steers the project. It's best if the Customer or one of her aides is a real end user who knows the domain and what is needed. The team will of course have programmers. The team may include testers, who help the Customer define the customer acceptance tests. Analysts may serve as helpers to the Customer, helping to define the requirements. There is commonly a coach, who helps the team keep on track, and facilitates the process. There may be a manager, providing resources, handling external communication, coordinating activities. None of these roles is necessarily the exclusive property of just one individual: Everyone on an XP team contributes in any way that they can. The best teams have no specialists, only general contributors with special skills.
Planning Game
XP planning addresses two key questions in software development: predicting what will be accomplished by the due date, and determining what to do next. The emphasis is on steering the project -- which is quite straightforward -- rather than on exact prediction of what will be needed and how long it will take -- which is quite difficult. There are two key planning steps in XP, addressing these two questions:
Release Planning is a practice where the Customer presents the desired features to the programmers, and the programmers estimate their difficulty. With the costs estimates in hand, and with knowledge of the importance of the features, the Customer lays out a plan for the project. Initial release plans are necessarily imprecise: neither the priorities nor the estimates are truly solid, and until the team begins to work, we won't know just how fast they will go. Even the first release plan is accurate enough for decision making, however, and XP teams revise the release plan regularly.
Iteration Planning is the practice whereby the team is given direction every couple of weeks. XP teams build software in two-week "iterations", delivering running useful software at the end of each iteration. During Iteration Planning, the Customer presents the features desired for the next two weeks. The programmers break them down into tasks, and estimate their cost (at a finer level of detail than in Release Planning). Based on the amount of work accomplished in the previous iteration, the team signs up for what will be undertaken in the current iteration.
These planning steps are very simple, yet they provide very good information and excellent steering control in the hands of the Customer. Every couple of weeks, the amount of progress is entirely visible. There is no "ninety percent done" in XP: a feature story was completed, or it was not. This focus on visibility results in a nice little paradox: on the one hand, with so much visibility, the Customer is in a position to cancel the project if progress is not sufficient. On the other hand, progress is so visible, and the ability to decide what will be done next is so complete, that XP projects tend to deliver more of what is needed, with less pressure and stress.
Customer Tests
As part of presenting each desired feature, the XP Customer defines one or more automated acceptance tests to show that the feature is working. The team builds these tests and uses them to prove to themselves, and to the customer, that the feature is implemented correctly. Automation is important because in the press of time, manual tests are skipped. That's like turning off your lights when the night gets darkest.
The best XP teams treat their customer tests the same way they do programmer tests: once the test runs, the team keeps it running correctly thereafter. This means that the system only improves, always notching forward, never backsliding.
Small Releases
XP teams practice small releases in two important ways:
First, the team releases running, tested software, delivering business value chosen by the Customer, every iteration. The Customer can use this software for any purpose, whether evaluation or even release to end users (highly recommended). The most important aspect is that the software is visible, and given to the customer, at the end of every iteration. This keeps everything open and tangible.
Second, XP teams release to their end users frequently as well. XP Web projects release as often as daily, in house projects monthly or more frequently. Even shrink-wrapped products are shipped as often as quarterly.
It may seem impossible to create good versions this often, but XP teams all over are doing it all the time. See Continuous Integration for more on this, and note that these frequent releases are kept reliable by XP's obsession with testing, as described here in Customer Tests and Test-Driven Development.
Simple Design
XP teams build software to a simple design. They start simple, and through programmer testing and design improvement, they keep it that way. An XP team keeps the design exactly suited for the current functionality of the system. There is no wasted motion, and the software is always ready for what's next.
Design in XP is not a one-time thing, or an up-front thing, it is an all-the-time thing. There are design steps in release planning and iteration planning, plus teams engage in quick design sessions and design revisions through refactoring, through the course of the entire project. In an incremental, iterative process like Extreme Programming, good design is essential. That's why there is so much focus on design throughout the course of the entire development.
Pair Programming
All production software in XP is built by two programmers, sitting side by side, at the same machine. This practice ensures that all production code is reviewed by at least one other programmer, and results in better design, better testing, and better code.
It may seem inefficient to have two programmers doing "one programmer's job", but the reverse is true. Research into pair programming shows that pairing produces better code in about the same time as programmers working singly. That's right: two heads really are better than one!
Some programmers object to pair programming without ever trying it. It does take some practice to do well, and you need to do it well for a few weeks to see the results. Ninety percent of programmers who learn pair programming prefer it, so we highly recommend it to all teams.
Pairing, in addition to providing better code and tests, also serves to communicate knowledge throughout the team. As pairs switch, everyone gets the benefits of everyone's specialized knowledge. Programmers learn, their skills improve, they become move valuable to the team and to the company. Pairing, even on its own outside of XP, is a big win for everyone.
Test-Driven Development
Extreme Programming is obsessed with feedback, and in software development, good feedback requires good testing. Top XP teams practice "test-driven development", working in very short cycles of adding a test, then making it work. Almost effortlessly, teams produce code with nearly 100 percent test coverage, which is a great step forward in most shops. (If your programmers are already doing even more sophisticated testing, more power to you. Keep it up, it can only help!)
It isn't enough to write tests: you have to run them. Here, too, Extreme Programming is extreme. These "programmer tests", or "unit tests" are all collected together, and every time any programmer releases any code to the repository (and pairs typically release twice a day or more), every single one of the programmer tests must run correctly. One hundred percent, all the time! This means that programmers get immediate feedback on how they're doing. Additionally, these tests provide invaluable support as the software design is improved.
Design Improvement
Extreme Programming focuses on delivering business value in every iteration. To accomplish this over the course of the whole project, the software must be well-designed. The alternative would be to slow down and ultimately get stuck. So XP uses a process of continuous design improvement called Refactoring, from the title of Martin Fowler's book, "Refactoring: Improving the Design of Existing Code".
The refactoring process focuses on removal of duplication (a sure sign of poor design), and on increasing the "cohesion" of the code, while lowering the "coupling". High cohesion and low coupling have been recognized as the hallmarks of well-designed code for at least thirty years. The result is that XP teams start with a good, simple design, and always have a good, simple design for the software. This lets them sustain their development speed, and in fact generally increase speed as the project goes forward.
Refactoring is, of course, strongly supported by comprehensive testing to be sure that as the design evolves, nothing is broken. Thus the customer tests and programmer tests are a critical enabling factor. The XP practices support each other: they are stronger together than separately.
Continuous Integration
Extreme Programming teams keep the system fully integrated at all times. We say that daily builds are for wimps: XP teams build multiple times per day. (One XP team of forty people builds at least eight or ten times per day!)
The benefit of this practice can be seen by thinking back on projects you may have heard about (or even been a part of) where the build process was weekly or less frequently, and usually led to "integration hell", where everything broke and no one knew why.
Infrequent integration leads to serious problems on a software project. First of all, although integration is critical to shipping good working code, the team is not practiced at it, and often it is delegated to people who are not familiar with the whole system. Second, infrequently integrated code is often -- I would say usually -- buggy code. Problems creep in at integration time that are not detected by any of the testing that takes place on an unintegrated system. Third, weak integration process leads to long code freezes. Code freezes mean that you have long time periods when the programmers could be working on important shippable features, but that those features must be held back. This weakens your position in the market, or with your end users.
Collective Code Ownership
On an Extreme Programming project, any pair of programmers can improve any code at any time. This means that all code gets the benefit of many people's attention, which increases code quality and reduces defects. There is another important benefit as well: when code is owned by individuals, required features are often put in the wrong place, as one programmer discovers that he needs a feature somewhere in code that he does not own. The owner is too busy to do it, so the programmer puts the feature in his own code, where it does not belong. This leads to ugly, hard-to-maintain code, full of duplication and with low (bad) cohesion.
Collective ownership could be a problem if people worked blindly on code they did not understand. XP avoids these problems through two key techniques: the programmer tests catch mistakes, and pair programming means that the best way to work on unfamiliar code is to pair with the expert. In addition to ensuring good modifications when needed, this practice spreads knowledge throughout the team.
Coding Standard
XP teams follow a common coding standard, so that all the code in the system looks as if it was written by a single -- very competent -- individual. The specifics of the standard are not important: what is important is that all the code looks familiar, in support of collective ownership.
Metaphor
Extreme Programming teams develop a common vision of how the program works, which we call the "metaphor". At its best, the metaphor is a simple evocative description of how the program works, such as "this program works like a hive of bees, going out for pollen and bringing it back to the hive" as a description for an agent-based information retrieval system.
Sometimes a sufficiently poetic metaphor does not arise. In any case, with or without vivid imagery, XP teams use a common system of names to be sure that everyone understands how the system works and where to look to find the functionality you're looking for, or to find the right place to put the functionality you're about to add.
Sustainable Pace
Extreme Programming teams are in it for the long term. They work hard, and at a pace that can be sustained indefinitely. This means that they work overtime when it is effective, and that they normally work in such a way as to maximize productivity week in and week out. It's pretty well understood these days that death march projects are neither productive nor produce quality software. XP teams are in it to win, not to die.
Conclusion
Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.
A subsequent article will discuss the common questions and variations within XP. If you have concerns, please write and we'll try to include them in the followup article.
[And Ralph Johnson said that in XP the software life-cycle is: Analysis, Test, Code, Design.]
Ronald E. Jeffries, XProgramming.com
Don Wells, Extreme Programming: A gentle introduction
Many XP Discussions on WikiWikiWeb
Kent Beck, Extreme Programming Explained: Embrace Change
Kent Beck and Martin Fowler, Planning Extreme Programming
Ron Jeffries, Ann Anderson and Chet Hendrickson, Extreme Programming Installed
Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts, Refactoring: Improving the Design of Existing Code
The Standard Waterfall Model for Systems Development
The standard waterfall model for systems development is an approach that goes through the following steps:
This model is widely used on large government systems, particularly by the Department of Defense (DOD).
As part of this standard approach, the party responsible for contracting out the system development (ESDIS for the ECS Contract) can call on a number of tools to help plan and document the system. ECS followed this planning approach, which means that early in the system development, ESDIS set up a standard set of documents for the contractor to supply, as well as a contractual schedule for the major pieces. The development process provided a number of design reviews, notably
Until these reviews were completed, there would be little code developed. After the CDR, the contractor would code to the design.
The standard reference for estimating the cost of the system is the COnstructive COst MOdel (COCOMO) developed by Dr. Barry Boehm while he was at TRW [Boehm, B., 1981: Software Engineering Economics, Prentice-Hall]. This model relates the development time and workforce [man-months] to the "Source Lines of Code" (SLOC). Roughly, for an ECS type of system ECS, the workforce (and therefore cost) scales as the cube of the development time. There are simple versions of the model and much more complex ones. Generally, all of the relationships used to predict these relationships are statistical in nature: Dr. Boehm and other workers in software project cost estimation build a database of project schedules and costs and then regress those against SLOC estimates. The most recent version of Dr. Boehm's work is provided in [Boehm, B., et al., 2000: Software Cost Estimation with COCOMO II, Prentice-Hall.].
There have been a number of criticisms of the standard waterfall model, including
The standard waterfall model is associated with the failure or cancellation of a number of large systems. It can also be very expensive. As a result, the software development community has experimented with a number of alternative approaches, including
These are discussed in considerable detail in [McConnell, S., 1996: Rapid Development, Taming Wild Software Schedules, Microsoft Press]. Commercial software projects often reduce the formality of the full waterfall model. In the last few years, a paradigm known as eXtreme Programming has emerged that emphasizes reducing the cost of software changes, developing test cases before coding, developing code using pairs of programmers, and putting most of the documentation into the code [Beck, K., 2000: Extreme Programming Explained, Embrace Change, Addison-Wesley].
| Waterfall | |
Summary: |
In this type of development, each of the stages (requirements, design, development, and test) are separate and do not overlap. Each stage has a set of exit criteria which must be met before the next stage can begin. Once a stage has been entered, changes to a previous phase should not happen, but if they are required, the changes tightly controlled. |
|
Pros: |
|
|
Cons: |
|
|
Critique: |
|
| V-Shaped | |
|
Summary: |
The V-Shaped model is the same as the Waterfall model except that testing is a consideration throughout the development. Each stage of development is matched with its equivalent stage in testing: Requirements ó System testing, High-level design ó Integration testing, Detailed design ó Unit testing. Looking at how each stage applies to the testing of that stage might affect the way that the particular phase is approached and/or documented. |
|
Pros: |
|
|
Cons: |
|
|
Critique: |
|
| Prototyping | |
|
Summary: |
Prototyping consists of developing a partial implementation of the system to give the users a feel for what the developer has in mind. The users then give feedback on what they think of the prototype - what works and what doesn’t - and the developer can make changes more easily and efficiently than if the changes were to be made later on in development. |
|
Pros: |
|
|
Cons: |
|
|
Critique: |
|
| Incremental | |
|
Summary: |
In an Incremental development, the system is developed in different stages, with each stage consisting of requirements, design, development, and test phases. In each stage, new functionality is added. This type of development allows the user to see a functional product very quickly and allows the user to impact what changes are included in subsequent releases. |
|
Pros: |
|
|
Cons: |
|
|
Critique: |
|
| Spiral | |
|
Summary: |
The Spiral model of development is risk-oriented. Each spiral addresses a set of major risks that have been identified. Each spiral consists of: determining objectives, alternatives, and constraints, identifying and resolving risks, evaluating alternatives, developing deliverables, planning the next iteration, and committing to an approach to the next iteration. (Barry Boehm, "A Spiral Model of Software Development and Enhancement", Computer, May 1988) |
|
Pros: |
|
|
Cons: |
|
|
Critique: |
|
Which is required for any piece of aviation (including spacecraft) flight control
system that is not on an experimental plane.
It doesn't make for the stringent design specification requirements, let alone a
few others.
I definitely do NOT want to be flying on a plane or having one fly over my head
that doesn't meet the DO-178 certification.
[ Parent ]
Copyright © 1996-2009 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Disclaimer:
Last modified: August 12, 2009