A software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process.
The largely growing body of software development organizations implement process methodologies. Many of them are in the defense industry, which in the U.S. requires a rating based on 'process models' to obtain contracts.
The international standard for describing the method of selecting, implementing and monitoring the life cycle for software is ISO 12207.
A decades-long goal has been to find repeatable, predictable processes that improve productivity and quality. Some try to systematize or formalize the seemingly unruly task of writing software. Others apply project management techniques to writing software. Without project management, software projects can easily be delivered late or over budget. With large numbers of software projects not meeting their expectations in terms of functionality, cost, or delivery schedule, effective project management appears to be lacking.
Organizations may create a Software Engineering Process Group (SEPG), which is the focal point for process improvement. Composed of line practitioners who have varied skills, the group is at the center of the collaborative effort of everyone in the organization who is involved with software engineering process improvement.
Waterfall Model
The waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance.
The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.
The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995), although Royce did not use the term "waterfall" in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development—as a way to criticize a commonly used software practice.
Advantages:
- Good if a bug or a glitch is found in the early stages or phases of the model, because if errors are found early, then the process will go smoothly because of little mistakes to correct.
- Most useful in helping to structure, staff, and manage large software development projects in complex
- organizational settings, which was one of the primary purposes (Royce 1970, Boehm 1976).
- The waterfall model is the oldest and most widely used paradigm for software engineering.
- Although the waterfall model is often derived as old fashioned, it remains a reasonable approach when requirements are well understood.
- Waterfall model provides a template into which methods for analysis, design, coding, testing and support can be placed.
- It remains a widely used procedural model for software engineering.
- Easy to explain to the user
- Stages and activities are well defined
- Helps to plan and schedule the project
- Verification at each stage ensures early detection of errors / misunderstanding
Disadvantages:
- As from the slide presentation of one of our instructors, difficulty of accommodating change after the process is in progress is one of the drawbacks of the waterfall model. True, because if one stage is finished, that will remain as is, and if there are errors in that stage, then the errors will be carried out to the next phase, which will cause more work to be done, because there is a possibility that there will still be many errors in the next stage.
- Because in the waterfall model, a phase needs to be perfected before it can proceed to the next one, it is considered a bad practice. Why? Because no phase in a software project can really be perfected. That would be impossible.
- Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. Few business systems have stable requirements.
- Real project rarely follows the sequential flow that the model proposes. Although the waterfall model can accommodate iteration, it does so indirectly. As a result, change can cause confusion as the project team proceeds.
- Appropriate only when the requirements are well-understood and changes will be fairly limited during the design process.
- The waterfall model requires all requirements explicitly, but it is often difficult for the customer to state all requirements explicitly.
- A working version of the program will not be available until late in the project time-span.
The waterfall model assumes that the requirements of a system can be frozen (i.e. basedline) before the design begins. This is possible for systems designed to automate an existing manual system. But for absolutely new system, determining the requirements is difficult, as the user himself does not know the requirements. Therefore, having unchanging (or changing only a few) requirements is unrealistic for such project.
Freezing the requirements usually requires choosing the hardware (since it forms a part of the requirement specification). A large project might take a few years to complete. If the hardware is selected early, then due to the speed at which hardware technology is changing, it is quite likely that the final software will employ a hardware technology that is on the verge of becoming obsolete. This is clearly not desirable for such expensive software.
The waterfall model stipulates that the requirements should be completely specified before the rest of the development can proceed. In some situations it might be desirable to first develop a part of the system completely, an then later enhance the system in phase. This is often done for software products that are developed not necessarily for a client (where the client plays an important role in requirement specification), but for general marketing, in which the requirements are likely to be determined largely by developers.
Waterfall model tends to consume a lot more time compared to other software development models though it is able to pinpoint definite starting and ending points for a given project.
This model assumes the requirements to remain static during the life of the project, so there is little or no chance of incorporating new changes to the software once work begins. If changes are tried to be incorporated it leads to more confusion and further delays.
Its strong points lie in the fact that it is sequential, so there would be no confusion on the steps and the processes are straight down--no need to worry about so many conditions while working on a project. Additionally, this type of model tends to pack up on so much documentation.
Therefore, such tends to be useful for future code revisions and reference. However, its drawbacks become apparent in the length of time a project will be developed and the cost it is able to consume.
Spiral Model
The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.
The steps in the spiral model iteration can be generalized as follows:
1) The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
2) A preliminary design is created for the new system. This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies are decided to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements.
3) A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
4) A second prototype is evolved by a fourfold procedure:
1. evaluating the first prototype in terms of its strengths, weaknesses, and risks;
2. defining the requirements of the second prototype;
3. planning and designing the second prototype;
4. constructing and testing the second prototype.
The Spiral Model is ideal for projects that have a large budget and has a long allotted time for it, because this model has a long process. They also say that the spiral model of systems development is ideal for game development, because game developing usually involves change in requirements while the game is being developed. Because in the spiral model, in very loop, there is a development of a prototype and a risk analysis, then there will be testing every time.
Advantages:
- The process progresses in spiral sense to indicate iterative path followed, progressively more complete software is built as we go on iterating through all phases.
- Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier.
- It is more able to cope with the (nearly inevitable) changes that software development generally entails.
- Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier.
Disadvantages:
- Not ideal for small projects, as it requires a long process and is costly.
- Demands more time
- Highly customized limiting re-usability
- Applied differently for each application
- Risk of not meeting budget or schedule
Agile Methodology
Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.
Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Conceptual foundations of this framework are found in modern approaches to operations management and analysis, such as lean manufacturing, soft systems methodology, speech act theory (network of conversations approach), and Six Sigma.
Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("timeboxes") that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration. Multiple iterations may be required to release a product or new features.
Advantages:
- This method is ideal for small software projects, because the release of every version is in a small span of time.
- Minimizes feature creep by developing in short intervals resulting in miniature software projects and releasing the product in mini-increments.
Disadvantages:
- Short iteration may not add enough functionality, leading to significant delays in final iterations.
- Since Agile emphasizes real-time communication (preferably face-to-face), utilizing it is problematic for large multi-team distributed system development.
- Agile methods produce very little written documentation and require a significant amount of post-project documentation.
References:
http://www.blurtit.com/q533918.html
http://www.freetutes.com/systemanalysis/sa2-advantages-limitations-waterfall-model.html
http://wiki.answers.com/Q/Advantage_and_disadvantage_of_waterfall_model_of_software_engg[url][/url]
http://discuss.itacumens.com/index.php?topic=33422.0
http://www.the-software-experts.de/e_dta-sw-process.htm
http://scitec.uwichill.edu.bb/cmp/online/cs22l/spiralmodel.htm
http://www.builderau.com.au/program/development/soa/Why-use-Agile-Methods-/0,339024626,320275975,00.htm
http://www.agile-software-development.com/2007/09/disadvantages-of-agile-software.html
No comments:
Post a Comment