This action might not be possible to undo. Are you sure you want to continue?
A Software Development Life Cycle Model is a set of activities together with an ordering relationship between activities which if performed in a manner that satisfies the ordering relationship that will produce desired product. Software Development Life Cycle Model is an abstract representation of a development process. In a software development effort the goal is to produce high quality software. The development process is, therefore, the sequence of activities that will produce such software. A software development life cycle model is broken down into distinct activities. A software development life cycle model specifies how these activities are organized in the entire software development effort. We discuss each software development life cycle model in detail. 1. 2. 3. 4. 5. 6. Waterfall Software Development Life Cycle Model Prototyping Software Development Life Cycle Model Iterative Enhacement Model The Spiral Model Object Oriented Methodology Dynamic System Development Method
Waterfall Software Development Life Cycle Model
The simplest software development life cycle model is the waterfall model, which states that the phases are organized in a linear order. A project begins with feasibility analysis. On the successful demonstration of the feasibility analysis, the requirements analysis and project planning begins. The design starts after the requirements analysis is done. And coding begins after the design is done. Once the programming is completed, the code is integrated and testing is done. On succeeful completion of testing, the system is installed. After this the regular operation and maintenance of the system takes place. The following figure demonstrates the steps involved in waterfall life cycle model.
The Waterfall Software Life Cycle Model
With the waterfall model, the activities performed in a software development project are requirements analysis, project planning, system design, detailed design, coding and unit testing, system integration and testing. Linear ordering of activities has some important consequences. First, to clearly identify the end of a phase and beginning of the others. Some certification mechanism has to be employed at the end of each phase. This is usually done by some verification and validation. Validation means confirming the output of a phase is consistent with its input (which is the output of the previous phase) and that the output of the phase is consistent with overall requirements of the system. The consequences of the need of certification is that each phase must have some defined output that can be evaluated and certified. Therefore, when the activities of a phase are completed, there should be an output product of that phase and the goal of a phase is to produce this product. The outputs of the earlier phases are often called intermediate products or design document. For the coding phase, the output is the code. From this point of view, the output of a software project is to justify the final program along with the use of documentation with the requirements document, design document, project plan, test plan and test results. Another implication of the linear ordering of phases is that after each phase is completed and its outputs are certified, these outputs become the inputs to the next phase and should not be changed or modified. However, changing requirements cannot be avoided and must be faced. Since changes performed in the output of one phase affect the later phases, that might have been performed. These changes have to made in a controlled manner after evaluating the effect of each change on the project.This brings us to the need for configuration control or configuration management. The certified output of a phase that is released for the best phase is called baseline. The configuration management ensures that any changes to a baseline are made after careful review, keeping in mind the interests of all parties that are affected by it. There are two basic assumptions for justifying the linear ordering of phase in the manner proposed by the waterfall model. For a successful project resulting in a successful product, all phases listed in the waterfall model must be performed anyway. Any different ordering of the phases will result in a less successful software product. • • • Requirements – defines needed information, function, behavior, performance and interfaces. Design – data structures, software architecture, interface representations, algorithmic details. Implementation – source code, database, user documentation, testing.
Project Output in a Waterfall Model
As we have seen, the output of a project employing the waterfall model is not just the final program along with documentation to use it. There are a number of intermediate outputs, which must be produced in order to produce a successful product. The set of documents that forms the minimum that should be produced in each project are:
Requirement document Project plan System design document Detailed design document Test plan and test report Final code
installation manual etc. 4. basedline) before the design begins. Reviews are formal meeting to uncover deficiencies in a product. This prototype is developed based on the currently known requirements. Advantages of Waterfall Life Cycle Models 1. Development of the prototype obviously undergoes design. having unchanging (or changing only a few) requirements is unrealistic for such project. The goal of prototyping based development is to counter the first two limitations of the waterfall model discussed earlier.e. 3. an then later enhance the system in phase. the client can get an "actual feel" of the system. a throwaway prototype is built to understand the requirements. Freezing the requirements usually requires choosing the hardware (since it forms a part of the requirement specification). In order to certify an output product of a phase before the next phase begins. but for general marketing. A large project might take a few years to complete. If the hardware is selected early.) Review reports Except for the last one. in which the requirements are likely to be determined largely by developers. But for absolutely new system. The waterfall model stipulates that the requirements should be completely specified before the rest of the development can proceed. these are all the outputs of the phases. coding and testing. determining the requirements is difficult. since other certification means are frequently not available. This is possible for systems designed to automate an existing manual system. Therefore. This is clearly not desirable for such expensive software. The basic idea here is that instead of freezing the requirements before a design or coding can proceed. 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). By using this prototype. In some situations it might be desirable to first develop a part of the system completely. But each of these phases is not done very formally or thoroughly. reviews are often held. then due to the speed at which hardware technology is changing. Reviews are necessary especially for the requirements and design phases. • All requirements must be known upfront • Deliverables created for each phase are considered frozen – inhibits flexibility • Can give a false impression of progress • Does not reflect problem-solving nature of software development – iterations of phases • Integration is one big bang at the end • Little opportunity for customer to preview the system (until it may be too late) Advantages Simple goal. 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 Limitations of the Waterfall Life Cycle Model The waterfall model assumes that the requirements of a system can be frozen (i. 2. as the user himself does not know the requirements. it is quite likely that the final software will employ a hardware technology that is on the verge of becoming obsolete. The review reports are the outcome of these reviews. since the interactions with prototype can enable the client to better understand the requirements of the desired system. . Software manuals (user manual.
Adjusting scope during the life cycle can end a project Not suitable for complex projects Not suitable for projects of long duration because in long running projects requirements are likely to change. Cannot accommodate changing requirements. Easy to manage. It is also an effective method to demonstrate the feasibility of a certain approach. The process model of the prototyping approach is shown in the figure below. Disadvantages It is difficult to measure progress within stages. Works well when quality is more important then cost/schedule. Well understood milestones. Simple to understand and use. Prototyping Software Development Life Cycle Model Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements. Clearly defined stages. Attempt to go back 2 or more phases is very costly. Easy to arrange tasks. Works well for projects where requirements are well understood. No working software is produced until late in the life cycle. Risk and uncertainty is high with this process model. Customers/End users already know about it. which doesn't allow to identify any technological or business bottleneck or challenges early. Each phase has specific deliverable and a review. This might be needed for novel systems where it is not clear that constraints can be met or that algorithms can be developed to implement the requirements. Very risky. since one process can not start before finishing the other. . Process and results are Well documented. Percentage completion of functionality can not be determined in mid of the project because every functionality is undergoing some phase. In such situations letting the client "plan" with the prototype provides invaluable and intangible inputs which helps in determining the requirements for the system. Integration is done as a "big-bang” at the very end. Users can only judge quality at the end.
Disadvantages 1.Practically. These factors helps to reduce the cost of developing the prototype. 3. the experience of developing the prototype will very useful for developers when developing the final system. 2. the users get a better understanding of the system being developed. The prototype are usually not complete systems and many of the details are not built in the prototype. original development With the analysis and design portions of object-oriented development. 5. This loop continues until the user is satisfied • • When to use • • • • • • Requirements are unstable or have to be clarified As the requirements clarification stage of a waterfall model Develop user interfaces Short-lived demonstrations New. This experience helps to reduce the cost of development of the final system and results in a more reliable and better designed system. In addition. this methodology may increase the complexity of the system as scope of the system may expand beyond original plans. as users have natural tendency to change their mind in specifying requirements and this method of developing systems supports this user tendency. Quicker user feedback is available leading to better solutions. Users are actively involved in the development 2.Leads to implementing and then repairing way of building systems. the cost of testing and writing detailed documents are reduced. • • • • • A preliminary project plan is developed An partial high-level paper model is created The model is source for a partial requirements specification A prototype is built with basic and critical attributes The designer builds – the database – user interface – algorithmic functions The designer demonstrates the prototype. some argue that prototyping need not be very costly and can actually reduce the overall development cost. 4. Advantages of Prototyping 1. the user evaluates for problems and suggests improvements. On the other hand. The goal is to provide a system with overall functionality. It provides a better system to users.Prototyping Model The basic reason for little common use of prototyping is the cost involved in this built-it-twice approach. Errors can be detected much earlier as the system is mode side by side. Advantages . Since in this methodology a working model of the system is provided. However.
In the first step of iterative enhancement model. coding and testing the implementation. Highly skilled resources are required for risk analysis. since testing each increment is likely to be easier than testing entire system like in the waterfall model. Initial Operating time is less. Can be costly to use. Risk analysis is better. the increments provides feedback to the client which is useful for determining the final requirements of the system. An advantage of this approach is that it can result in better testing. A project control list is created which contains. Better suited for large and mission-critical projects. The process is iterated until the project control list is empty. Management complexity is more.Each step consists of removing the next step from the list. End of project may not be know which is a risk. where each increment adds some functional capability to the system until the full system is implemented. and performing an analysis of the partial system obtained after this step and updating the list as a result of the analysis. The basic idea is that the software should be developed in increments. implementation phase and analysis phase. At each step extensions and design modifications can be made. The process involved in iterative enhancement model is shown in the figure below. a simple initial implementation is done for a subset of the overall problem. During life cycle software is produced early which facilitates customer evaluation and feedback. Iterative Enhacement Model The iterative enhancement life cycle model counters the third limitation of the waterfall model and tries to combine the benefits of both prototyping and the waterfall model. in an order. This subset is the one that contains some of the key aspects of the problem which are easy to understand and implement. These three phases are called the design phase. all the tasks that must be performed to obtain the final implementation. Furthermore. Designing the implementation for the selected task. Disadvantages Not suitable for smaller projects. This project control list gives an idea of how far the project is at any given step from the final system. Project’s progress is highly dependent upon the risk analysis phase. as in prototyping. It supports changing requirements. and which forms a useful and usable system. at the time the final implementation of the system will be available. The Iterative Enhancement Model .
Each entry in that list is a task that should be performed in one step of the iterative enhancement process. More management attention is required.The project control list guides the iteration steps and keeps track of all tasks that must be done. System architecture or design issues may arise because not all requirements are gathered. Risks are identified and resolved during an iteration. Progress can be measured. The structure of the spiral model is shown in the figure given below. The radial dimension represents the cumulative cost incurred in accomplishing the steps dome so far and the angular dimension represents the progress made in completing each cycle of the spiral. up front for the entire life cycle. The next step is to develop strategies that resolve the uncertainties and risks. simulation and prototyping. Defining increments may require definition of the complete system. The tasks in the list can be include redesign of defective components found during analysis. Finally the next stage is planned. Easier to manage risk . Each phase of an iteration is rigid with no overlaps. With every increment operational product is delivered. Although cost of change is lesser but it is not very suitable for changing requirements. Parallel development can be planned. Testing and debugging during smaller iteration is easy. Selecting tasks in this manner will minimize the chances of errors and reduce the redesign work. Spiral model This is a recent model that has been proposed by Boehm. Advantages Some working functionality can be developed quickly and early in the life cycle. This step may involve activities such as benchmarking. The next step in the spiral life cycle model is to evaluate these different alternatives based on the objectives and constraints. The spiral has many cycles. Results are obtained early and periodically. the activities in this model can be organized like a spiral. As the name suggests. and should be simple enough to be completely understood. Disadvantages More resources may be required.High risk part is done first. Next. Each cycle in the spiral begins with the identification of objectives for that cycle and the different alternatives are possible for achieving the objectives and the imposed constraints. This will also involve identifying uncertainties and risks involved. challenges & risks identified from each increment can be utilized/applied to the next increment. and each iteration is an easily managed milestone. Issues. . Less costly to change the scope/requirements. Does not allow iterations within an increment. the software is developed by keeping in mind the risks.
The spiral model works for developed as well as enhancement projects. resolve risks. Quadrant 2: Evaluate alternatives. including plans for the next cycle. Spiral Model Description The development spiral consists of four quadrants as shown in the figure above Quadrant 1: Determine objectives. Quadrant 3: Develop. the next step will follow the basic waterfall approach. For example. simulation-oriented or some other approach. and constraints. An important feature of the model is that each cycle of the spiral is completed by a review. which covers all the products developed during that cycle. The next step may be evolutionary development that involves developing a more detailed prototype for resolving the risks. Quadrant 4: Plan next phases. prototype-oriented. alternatives. identify. if the program development risks dominate and previous prototypes have resolved all the userinterface and performance risks. . its performance or user-interface risks are considered more important than the program development risks. The risk driven nature of the spiral model allows it to accommodate any mixture of specification-oriented. next-level product.The next step is determined by remaining risks. verify. On the other hand.
The focus here is on risk mitigation. Boehm notes that if the alternative chosen is ―operationally useful and robust enough to serve as a low-risk base for future product evolution. administering user questionnaires. cost. design. risk. .. external and internal) risks remain. Identify. for example. Quadrant 2: Evaluate Alternatives. The outcome of the evaluation determines the next course of action. let’s briefly address each one. maturity. To better understand the scope of each spiral development quadrant. and resolve risks) is performed. Investigate implementation alternatives—namely design. schedule. support. . is oriented toward software development. Quadrant 4: Plan Next Phases The spiral development model has one characteristic that is common to all models—the need for advanced technical planning and multidisciplinary reviews at critical staging or control points. This may involve prototyping. procure. and procure/ modify 3. Alternatives. technology. analytic modeling. activities to develop. If appropriate. cost. integration. Once the system or product’s objectives. of development efforts to date.‖ This brings us to Quadrant 3. and reviews plans and identifies COIs/CTIs to be resolved for the next iteration of the spiral. As a result. Resolve Risks Engineering activities performed in this quadrant select an alternative approach that best satisfies technical. progress. .e. the basic ―waterfall‖ approach may be employed—meaning concept of operations. verify. hardware.Although the spiral. reference checking. resolves critical operational and/or technical issues (COIs/CTIs). Verify. merits. . the concept is equally applicable to systems. Dr. identify. benchmarking. alternatives. reuse. Establish an understanding of the system or product objectives—namely performance. and Constraints Activities performed in this quadrant include: 1. functionality. and constraints are understood. Boehm describes these activities as follows: . Next-Level Product If a determination is made that the previous prototyping efforts have resolved the COIs/CTIs. and ability to accommodate change. support. 2. the subsequent risk-driven steps would be the evolving series of evolutionary prototypes going toward the right (hand side of the graphic) . next-level product are performed. development. schedule. Quadrant 2 (Evaluate alternatives. . as depicted. Each cycle of the model culminates with a technical review that assesses the status. Each alternative is investigated and prototyped to reduce the risk associated with the development decisions. Investigate constraints imposed on the alternatives—namely technology. incremental development approaches may also be applicable. simulation. and training. or combinations of these and other risk resolution techniques. and risk. the option of writing specifications would be addressed but not exercised. and risk constraints. and test of the next system or product iteration. If critical operational and/or technical issues (COIs/CTIs) such as performance and interoperability (i. more detailed prototyping may need to be added before progressing to the next quadrant. Quadrant 3: Develop. Quadrant 1: Determine Objectives.
Process is complex Spiral may go indefinitely. difference. Once this is done. This methodology asks the analyst to determine what the objects of the system are. For example in case of a Banking System. Large number of intermediate stages require excessive documentation. manipulated and created. Disadvantages Management is more complex. and what responsibilities and relationships an object has to other objects. how they behave over time or in response to events. Allows for extensive use of prototypes Requirements can be captured more accurately. Object-oriented analysis has the analyst look at all the objects in a system. In simple terms. their commonalties. For this. Object Modeling is based on identifying the objects in a system and their interrelationships. Development can be divided in to smaller parts and more risky parts can be developed earlier which helps better risk management. the coding of the system is done. An object-oriented approach to the development of software was proposed in late 1960s. first the system to be developed is observed and analyzed and the requirements are defined as in any other method of system development. Once this is done. Not suitable for small or low risk projects (expensive for small projects). the objects in the required system are identified. Object Oriented Methodology We live in a world of objects. These objects exist in nature. Object Oriented Process The Object Oriented Methodology of Building Systems takes the objects as the basis. Object-Oriented development requires that object-oriented techniques be used during the analysis. organized. Advantages Changing requirements can be accommodated. The basic steps of system designing using Object Modeling may be listed as: . They can be categorized. End of project may not be known early. Therefore. and how the system needs to manipulate the objects. combined. Users see the system early. described. a chequebook is an object. in business. Object Modeling is somewhat similar to the traditional approach of system designing. in man-made entities. a customer is an object. and implementation of the system. an object-oriented view has come into picture for creation of computer software. and in the products that we use. in that it also follows a sequential process of system designing but with a different approach.Subsequent implementations of the spiral may involve lower level spirals that follow the same quadrant paths and decision considerations. and even an account is an object.
The class defines the basic attributes and the operations of the objects of that type. To implement this concept. Based on this system study. For example. This concept is known as creating a class. As the basic philosophy of Object-Oriented method of system analysis is to perceive the system as a set of interacting objects. Object Design In this phase. Just as every programming language provides various data types and various variables of that type can be created. Here the implementation of these objects is decided as the data structures get defined and also the interrelationships between the objects are defined. . system analysis is the first phase of development in case of Object Modeling too. Only the model of the system is prepared based on the idea that the system is made up of a set of interacting objects. It is a template where certain basic characteristics of a set of objects are defined. the details of the system analysis and system design are implemented. a bigger system may also be seen as a set of interacting smaller subsystems that in turn are composed of a set of interacting objects. At this stage the implementation details are not taken care of. the analyst prepares a model of the desired system. As already discussed. the process-based structural programming is not used. instead objects are created using data structures. the analyst takes care of specifications as observed in system analysis as well as what is required out of the new system by the end user. In this phase. in case of objects certain data types are predefined. The important elements of the system are emphasized. Let us here deviate slightly from the design process and understand first a few important terms used in the Object-Oriented Modeling. similarly. The Objects identified in the system design phase are designed. System Design System Design is the next development stage where the overall architecture of the desired system is decided. the developer interacts with the user of the system to find out the user requirements and analyses the system to understand the functioning. the stress lies on the objects comprising the system and not on the processes being carried out in the system as in the case of traditional Waterfall Model where the processes form the important part of the system. System Analysis System Design Object Design Implementation System Analysis As in any other system development model. we can define a data type called pen and then create and use several objects of this data type. While designing the system as a set of interacting subsystems. but it only creates a template. For objects to be actually created instances of the class are created as per the requirement of the case. Defining a class does not define any object. Class: A class is a collection of similar objects. This model is purely based on what the system is required to do. While designing the system. The system is organized as a set of sub systems interacting with each other. Object Oriented Philosophy is very much similar to real world and hence is gaining popularity as the systems here are seen as a set of interacting objects as in the real world.
Among other benefits. The methodology supports and uses three basic Models: Object Model . While the Object Model is most important of all as it describes the basic element of the system. the class objects and the interrelationships of these classes are translated and actually coded using the programming language decided upon. Some of these are: Reusability . there are all the benefits of using the Object Orientation. The designer also decides on whether the classes need to be created from scratch or any existing classes can be used as it is or new classes can be inherited from them. A new type of class can be defined using a similar existing class with a few new features. while defining a pen class for a stationery shop. The databases are made and the complete system is given a functional shape. Coming back to our development process.This model describes the objects in a system and their interrelationships. Of all these. the characteristics of concern to the system under observation are picked up and the class definition is made. where a set of similar objects are observed and their common characteristics are listed. For instance. The attributes of no concern to the system are left out. This concept is used to apply the idea of reusability of the objects. all the three models together describe the complete functional system. whereas a pen class for a manufacturing firm would be containing the other dimensions of the pen like its diameter. considering a Window on the screen as an object. pen type etc. The abstraction of an object varies according to its application. the attributes of concern might be the pen color.. Implementation During this phase. This model observes all the objects as static and does not pay any attention to their dynamic nature. This is achieved by defining classes and putting them into a library of classes where all the classes are maintained for . This is known as abstraction. every object exhibits some characteristics and behavior. When observed closely. Here the clicking of the button is an event to which the window responds by changing its state from the old size to the new size. the analyst makes use of certain models to analyze and depict these objects. As compared to the conventional system development techniques.The classes once defined can easily be used by other applications. Inheritance: Inheritance is another important concept in this regard. While developing systems based on this approach. Dynamic Model . This would save the developers time and effort as the classes already existing are reused without much change. the designer decides onto the classes in the system based on these concepts. ink color. OO modeling provides many benefits. in the Object Designing phase of the Development process. its shape and size etc.This model basically describes the data transformations of the system.This model depicts the dynamic aspects of the system. the size of the window gets changed when resize button of the window is clicked. The complete OO methodology revolves around the objects identified in the system. a class vehicle can be defined with the basic functionality of any vehicle and a new class called car can be derived out of it with a few modifications. This describes the flow of data and the changes that occur to the data throughout the system.Abstraction: Classes are built on the basis of abstraction. The objects recognize and respond to certain events. For instance. It portrays the changes occurring in the states of various objects with the events that might occur in the system. the objects. Functional Model . For example.
The concept of inheritance helps the programmer use the existing code in another way. thereby reduces the development cost and cycle time. Inheritance . Encapsulation separates the internal functioning of the object from the external functioning thus providing the user flexibility to change the external behaviour of the object making the programmer code safe against the changes made by the user. It provides nice structures for thinking and abstracting and leads to modular design. New applications can use the existing modules. Whenever a new class is needed the programmer looks into the library of classes and if it is available. Object Oriented Methodology designs encourage more re-use. Programmer has to spend less time and effort and can concentrate on other aspects of the system due to the reusability feature of the methodology. . Object Oriented Methodology approach is more natural. Because of this.Encapsulation is a technique that allows the programmer to hide the internal functioning of the objects from the users of the objects. where making small additions to the existing classes can quickly create new classes. V-shaped model The V-Model is a systems development model designed to simplify the understanding of  the complexity associated with developing systems. allows changes more easily. The objects in the system are immune to requirement changes. Therefore. it can be picked up directly from there. Data Hiding .future use. it is easier to produce and understand designs. In systems engineering it is used to define a uniform procedure for product or project development. The systems designed using this approach are closer to the real world as the real world functioning of the system is directly mapped into the system designed using this approach. Advantages of Object Oriented Methodology Object Oriented Methodology closely represents the problem domain.
Reduction of Total Cost over the Entire Project and System Life Cycle: The effort for the development. The VEE represents the sequence of steps in a project life cycle development. Improvement and Guarantee of Quality: As a standardized process model. understandability and verifiability. the frictional loss between user. This reduces the acquirers dependency on the supplier and the effort for subsequent activities and projects. Thus. It summarizes the main steps to be taken in conjunction with the corresponding deliverables within computerized system validation framework. acquirer. It permits an early recognition of planning deviations and risks and improves process management. Validation". estimated and controlled in a transparent manner by applying a standardized process model. thus reducing the project risk. V  V stands for "Verification and Model topics . production. The following objectives are intended to be achieved by a project execution: Minimization of Project Risks: The V-Model improves project transparency and project control by specifying standardized approaches and describing the corresponding results and responsible roles. The results obtained are uniform and easily retraced. The right side of the VEE represents integration of parts and their verification.Overview The V-model is a graphical representation of the systems development lifecycle. operation and maintenance of a system can be calculated. the V-Model ensures that the results to be provided are complete and have the desired quality. supplier and developer is reduced. and creation of system specifications. Objectives The V-Model provides guidance for the planning and realization of projects. Uniform product contents will improve readability. The left side of the "V" represents the decomposition of requirements. Defined interim results can be checked at an early stage. It describes the activities and results that have to be produced during product development. Improvement of Communication between all Stakeholders: The standardized and uniform description of all relevant elements and terms is the basis for the mutual understanding between all stakeholders.
on-going operation and maintenance. and eventual retirement. from conception to retirement. All design elements and acceptance tests must be traceable to one or more system requirements and every requirement must be addressed by at least one design element and acceptance test. The  specification stream The specification stream mainly consists of: User Requirement Specifications Functional Requirement Specifications . a concept of operations that describes user needs and the operating environment.  The process emphasizes requirements-driven design and testing.Systems engineering and verification.  It involved early and comprehensive identification of goals. Such rigor ensures nothing is done unnecessarily and everything that is necessary is accomplished. measuring its effectiveness in addressing goals (system validation). thorough and testable system requirements. rigorous acceptance testing of the implemented system to ensure it meets the stated requirements (system verification). detailed design. system upgrades over time. implementation. Systems Engineering and verification The Systems Engineering Process (SEP) provides a path for improving the cost effectiveness of complex systems as experienced by the system owner over the entire life of the system.
configuration or coding. Forsberg and H. Applications Off-Core alternatives (illustrating upward and downward iterations and Time and Maturity dimension). Design Specifications The testing stream generally consists of: Installation Qualification (IQ) Operational Qualification (OQ) Performance Qualification (PQ) The development stream can consist (depending on the system type and the development scope) of customization.K. Source . Mooz 2004 .
 was developed for satellite systems involving The V-Model first appeared at Hughes Aircraft circa 1982 as part of the pre-proposal effort for the FAA Advanced Automation System (AAS) program. As the V-model is publicly available many companies also use it. It was taken over by the Federal Ministry of the Interior for the civilian public authorities domain in summer 1992. . It was the foundation of Sequential Thematic Organization of Publications (STOP)  created by Hughes in 1963 and used until Hughes  was divested by the Howard Hughes Medical Institute in 1985. software.  This has proven to be an important aspect of the model. now INCOSE as of 1995). One fundamental characteristic of the US V-Model is that time and maturity move from left to right and one cannot move back in time. The  expansion of the model to a dual-Vee concept is treated in reference. especially as it pertains to the scope outside of the realm of the System Development Lifecycle normal parameters. as documented in the 1991 proceedings for the National Council on Systems Engineering (NCOSE. for the Federal Ministry of Defense. as well as software developers within the region. hardware. and human interaction. as shown in the figure. It has now found widespread application in commercial as well as defense programs. The need for this new level of latent defect detection was driven by the goal to start automating the thinking and planning processes of the air traffic controller as envisioned by the Automated Enroute Air Traffic Control (AERA) program.  The US V-Model. but independently. The reason the V is so powerful comes from the Hughes culture of coupling all text and analysis to multi dimensional images. The V-Model while rigid in process. The concept of the V-Model was developed simultaneously. In project management it is a method comparable to PRINCE2 and describes methods for project management as well as methods for system development. in Germany and in the United States in the late 1980s: The German V-Model was originally developed by IABG in Ottobrunn. It eventually formed the test strategy for the Hughes AAS Design Competition Phase (DCP) proposal. Nowadays it is still the standard for German federal administration and defense projects. in cooperation with the Federal Office for Defense Technology and Procurement in Koblenz. near Munich. can be very flexible in application. Its primary use is in Project Management  and throughout the project lifecycle.The V-model is used to regulate the software development process within the German federal administration. All iteration is along a vertical line to higher or lower levels in the system hierarchy. It was created to show the test and integration approach which was driven by new challenges to surface latent defects in the software.
Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle. Little flexibility and adjusting scope is difficult and expensive.  The V-Model provides concrete assistance on how to implement an activity and its work steps. so no early prototypes of the software are produced. planning and preparation of a concept for these tasks are regulated in the V-Model. they must be regulated in addition. repair and disposal of the system are not covered by the V-Model.  At each project start. However. The organization and execution of operation.  Limits The following aspects are not covered by the V-Model. The V-Model addresses software development within a project rather than a whole organization. maintenance. recommendations and detailed explanations of the activity. RAD Model . or the V-Model must be adapted accordingly  : The placing of contracts for services is not regulated. Each phase has specific deliverables. The change control board meets once a year and processes all received change requests on The V-Model. A change control board publicly maintains the V-Model. this being possible because the V-Model is organization and project independent. Works well for small projects where requirements are easily understood. Software is developed during the implementation phase. defining explicitly the events needed to complete a work step: each activity schema contains instructions. the V-Model can be tailored into a specific project V-Model. . Advantages Simple and easy to use.Advantages These are the advantages V-Model offers in front of other systems development models: The users of The V-Model participate in the development and maintenance of The V-Model. like the waterfall model. Model doesn’t provide a clear path for problems found during testing phases. Disadvantages Very rigid.
detailed requirements analysis is done that attempts to capture the system requirements in a Requirements Specification. A complete. prototyping tools. (The concept can be applied to hardware development as well. The most popular object-oriented programming languages. which inherently fosters software re-use. or extremely expensive to implement? What if errors in the design are encountered during the build phase? The elapsed time between the initial analysis and testing is usually a period of several months. C++ and Java. language development environments such as those for the Java platform.) These products include requirements gathering tools. If the requirements are well understood and defines. Users are forced to “sign-off” on the specification before development proceeds to the next step. But. computer-aided software engineering tools. groupware for communication among development members. Development Methodology The traditional software development cycle follows a rigid sequence of steps with a formal sign-off at the completion of each.RAD is a linear sequential software development process model that emphasis an extremely short development cycle using a component based construction approach. and the project scope is constraint. and testing tools. are offered in visual programming packages often described as providing rapid application development. the RAD process enables a development team to create a fully functional system with in very short time period. . what if the design phase uncovers requirements that are technically unfeasible. reiterative user testing of designs The re-use of software components A rigidly paced schedule that defers design improvements to the next product version Less formality in reviews and other team communication Some companies offer products that provide some or all of the tools for RAD software development. RAD usually embraces objectoriented programming methodology. What if business requirements or priorities change or the users realize they overlooked critical needs during the analysis phase? These are many of the reasons why software development projects either fail or don’t meet the user’s expectations when delivered. RAD (rapid application development) is a concept that products can be developed faster and of higher quality through: Gathering requirements using workshops or focus groups Prototyping and early. This is followed by a complete system design and then development and testing.
Process Modeling: The data object defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. where does the information go. who process it and so on.RAD is a methodology for compressing the analysis. Resource requirements may be more. effective informal communication and simple project management. Application Generation: Automated tools are used to facilitate construction of the software. 3. Advantage and Disadvantages RAD reduces the development time and reusability of components help to speed up development. what information is generated. This reduces overall testing time. RAD is based on Object Oriented approach and if it is difficult to modularize the project the RAD may not work well. Suitable for project requiring shorter development times. build. Processing descriptions are created for adding. RAD Model Phases RAD model has the following phases: 1. who generates it. iterative development cycles. But new components must be tested and all interfaces must be fully exercised. deleting or retrieving a data object. design. end users. Testing and Turn over: Many of the programming components have already been tested since RAD emphasis reuse. combined with short. Use of tools and frameworks. This has a number of distinct advantages over the traditional sequential development model. If commitment is lacking RAD will fail. Cycle time can be short with use of powerful RAD tools. unity of vision and purpose. even they use the 4th GL techniques. The attributes (character of each entity) are identified and the relation between these data objects (entities) is defined. iterative development cycles. . and test phases into a series of short. optimizes speed. All functions are modularized so it is easy to work with. For large projects RAD require highly skilled engineers in the team. Both end customer and developer should be committed to complete the system in a much abbreviated time frame. Changing requirements can be accommodated. Progress can be measured. modifying. Suitable only when requirements are well known. Suitable for systems that are component based and scalable.RAD projects are typically staffed with small integrated teams comprised of developers. Productivity with fewer people in short time. Requires user involvement throughout the life cycle. Business Modeling: The information flow among business functions is defined by answering questions like what information drives the business process. Small teams. 4. 5. Disadvantages Management complexity is more. Data Modeling: The information collected from business modeling is refined into a set of data objects (entities) that are needed to support the business. 2. and IT technical resources. Advantages Time to deliver is less.
More risk of sustainability. Strict delivery management dictates the scope. Enables concurrent development and delivery within an overall planned context. Resource requirements are minimum. Functionality can be developed rapidly and demonstrated. Suitable for fixed or changing requirements Delivers early partial working solutions. and adjustments to meet the deadlines. functionality to be delivered. Minimal rules. documentation easily employed. an agile leader and agile PM practice is a must without which it will not work.Extreme/Agile Development Advantages Promotes teamwork and cross training. Good model for environments that change steadily. maintainability and extensibility. . Disadvantages Not suitable for handling complex dependencies. An overall plan.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.