In this the developer simply builds a product that is reworked as many times as necessary to satisfy the client. This is an adhoc approach and not well defined. Basically it is a simple twophase model. The first phase is to write code and the next phase is to fix it.
This model is totally unsatisfactory for software of any reasonable size.
. The cost of the development using this approach is actually very high as compared to the properly specified and designed. Code soon becomes unfixable and unenhanceable.
This approach may work well on small programming excercises (100-200 lines).
This model has five phases: Requirements Analysis and Specification Design Implementation and Unit testing Integration and System testing Operation and Maintenance
The requirements describe the ―what‖ of a system. as the goal is to document the functions.
Requirements Analysis and Specification :The goal of this phase understand the exact requirements of the customer and to document them properly. This activity is usually executed together with the customer. performance. not the ―how‖.
written in a natural language .
This phase produces a large document. contains a description of what the system will do without describing how it will done.
. The resultant document is known as software requirement specification (SRS) document.
Here. The information contained in the SDD should be sufficient to begin the coding phase. This work is documented and known as SDD document.
. overall software architecture is defined. and the high level and detailed design work is performed.
Design phase :The goal of this phase is to transform the requirement specification into a structure that is suitable for implementation in some programming language.
Implementation and unit testing phase:During this phase. the implementation or coding phase proceeds smoothly. design is implemented.
. If the SDD is complete. because all the information needed by the software developers is contained in the SDD.
In this modules are tested after writing some overhead code. In unit testing small modules are tested in isolation from the rest of the software product.
.During testing the major activities are centered around the examination and modification of the code.
and more accurate and reliable results. Effective testing will contribute to the delivery of higher quality software products. It is a very expensive activity and consumes one-third to one half of the cost of a typical development project.
. lower maintenance costs.
Integration and system testing phase:This is a very important phase. more satisfied users.
whereas software is a part of the system. This is essential to build confidence in the developers before software is delivered to the customer or released in the market.
.System testing involves the testing of the entire system.
when the software is delivered to the customers site.
Operation and maintenance phase:Software maintenance is a task that every development group has to face. installed and is operational. release of software inaugurates the operation and maintenance phase of the life cycle.
.Software maintenance is a very broad activity that includes error correction. This phase may span for 5 to 50 years whereas development may be 1 to 3 years. The purpose of this phase is to preserve the value of the software over time. enhancement of capabilities.
Real projects are rarely sequential. It does not scale up well to large projects. This model is not suitable for accomodating any change.
It is difficult to define all requirements at the beginning of a project.
Due to these weakness. the application of waterfall model should be limited to situations where the requirements and their implementations are well understood.
but with fewer restrictions. A useable product is released at the end of each cycle. Generally.
. but these may be conducted in several cycles. with each release providing additional functionality. the phases occur in the same order as in the waterfall model.
This model has the same phases as the waterfall model.
implementation and test based on the defined priorities. Developers implement the specified requirements in one or more cycles of design.
During the first requirements analysis phase. customers and developers specify as many requirements as possible and prepare a SRS document.
. Developers and customers then prioritize these requirements.
In iterative model we can only create a highlevel design of the application before we actually begin to build the product and define the design solution for the entire product. Hence we can track the defects at early stages. This avoids the downward flow of the defects. Later on we can design and built a skeleton version of that.
. and then evolved the design based on what had been built. In iterative model we are building and improving the product step by step.
In iterative model we can get the reliable user feedback. When presenting sketches and blueprints of the product to users for their feedback. we are effectively asking them to imagine how the product will work.
. In iterative model less time is spent on documenting and more time is given for designing.
Each phase of an iteration is rigid with no overlaps Costly system architecture or design issues may arise because not all requirements are gathered up front for the entire lifecycle
some details can evolve with time. Major requirements must be defined. When the project is big. however.
Requirements of the complete system are clearly defined and understood.
The continuous user participation ensures the involvement of user’s expectations and perspective in requirements elicitation. user involvement is essential from the requirement phase to delivery of the product. analysis and design of the system. Here.
This model is an incremental process model.
. USE CASE etc).
The process is started with building a rapid prototype and is given to user for evaluation. We may use any grouping techniques (like INTERVIEWS. The process continues till the requirements are finalised. FAST. The user feedback is obtained and prototype is refined.
Requirements are captured using any group elicitation technique. Only issue is the active involvement of users for understanding the project.
There are four phases in this model:-
1) Requirements planning phase. 2) User description – Joint team of developers and users are constituted to prepare.
. The team may use different tools to capture information from the other users. understand and review the requirements.
3) Construction Phase:. 4) Cut over phase:.
. installation of the system and user training. Here. we release the product to customer.This phase incorporates acceptance testing by the users.This phase combines the detailed design. coding and testing phase of waterfall model.
If user cannot be involved throughout the life cycle. this may not be an appropriate model.
. The development time of the product may be reduced due to use of powerful development tools. quick initial views about the product are possible due to delivery of rapid prototype.
In this model.
Reduced development time. Increases reusability of components Quick initial reviews occur Encourages customer feedback Integration from very beginning solves a lot of integration issues.
Requires highly skilled developers/designers. High dependency on modeling skills Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.
Depends on strong team and individual performances for identifying business requirements.
RAD should be used when there is a need to create a system that can be modularized in 2-3 months of time.
. It should be used if there’s high availability of designers for modeling and the budget is high enough to afford their cost along with the cost of automated code generating tools. RAD SDLC model should be chosen only if resources with high business knowledge are available and there is a need to produce the system in a short span of time (2-3 months).
An alternative to this is to first develop a working prototype of the software instead of developing the actual software. The working prototype is developed as per current available requirements.
A disadvantage of the waterfall model is that the working software is not available until late in the process.
. thus delaying the discovery of serious errors.
it is reviewed by the customer.
. Because the working prototype has been evaluated by the customer. it is reasonable to expect that the resulting specification document will be correct.
When the prototype is created.
The developers use this prototype to refine the requirements and prepare the final specification document.
Typically this review gives feedback to the developers that helps to remove uncertainties in the requirements of the software and starts an iteration of refinement in order to further clarify requirements.
2) This type of approach of developing the software is used for non-IT-literate people. 3) When client is not confident about the developer's capabilities. Based on this model. he asks for a small prototype to be built. .
. nor can tell properly about what they expect from the software. he judges capabilities of developer.1) When prototype is shown to the user. They usually are not good at specifying their requirements. he gets a proper clarity and 'feel' of the functionality of the software and he can suggest changes and modifications.
since the developer has a better idea about how he should approach the project
. 7) Time required to complete the project after getting final the SRS reduces. 6) Iteration between development team and client provides a very good and conductive environment during project. 5) It reduces risk of failure. as potential risks can be identified early and mitigation steps can be taken.4) Sometimes it helps to demonstrate the concept to prospective investors to get funding for project.
1) Prototyping is usually done at the cost of the developer. That is why. it may be of no use. So it should be done using minimal resources. Please note sometimes the start-up cost of building the development team. sometimes we refer to the prototype as "Throw-away" prototype. It can be done using Rapid Application Development (RAD) tools. focused on making prototype.
. is high. 2) Once we get proper requirements from client after showing prototype model.
3) It is a slow process. 5) Too many changes can disturb the rhythm of the development team. is not always preferred by the developer.
. 4) Too much involvement of client.
Important software projects have failed because project risks were neglected and nobody was prepared when something unforeseen happened. BARRY BOEHM recognized this and tried to incorporate the ―Project risk‖ factor into a life cycle model.
The problem with traditional software process models is that they do not deal sufficiently with the uncertainty. which is inherent to software projects.
The result is the spiral model which is the combination of waterfall and prototyping model. The angular dimension represents the progress made in completing each cycle. The radial dimension of the model represents the cumulative costs. Each loop of the spiral from X-axis clockwise through 360 represents on phase. Each path around the spiral is indicative of increased costs.
One phase is split roughly into four sectors of major activities:PLANNING: Determination of objectives. alternatives and constraints. DEVELOPMENT: Product development and testing product. RISK ANALYSIS: Analyze alternatives and attempts to identify and resolve the risks involved. ASSESSMENT: Customer evaluation.
planning is performed. requirements are documented and validated and customers are involved in assessing the new prototype. a more refined prototype is built. risks are known and somewhat more traditional development approach is taken. risks are analyzed. By the third phase begins. prototypes are built and customers evaluate the prototype. During the second phase.
During the first phase.
Otherwise. then the spiral is terminated. If the plan for the development fails.
An important feature of the spiral model is that each phase is completed with a review by the people concerned with the project. it terminates with the initiation of new or modified software.
. 3) Risk management is one of the in-built features of the model. as well as each loop. Development phases can be determined by the project manager. according to the complexity of the project. This makes the model more transparent. requires a review from concerned people. Each phase. 2) Project monitoring is very easy and effective.1) Spiral Life Cycle Model is one of the most flexible SDLC models in place. which makes it extra attractive compared to other models.
And coping with these changes isn’t a very big headache for the project manager. where business needs may be unstable.
6) A highly customized product can be developed using this.
5) It is suitable for high risk projects.
.4) Changes can be introduced later in the life cycle as well.
1) Cost involved in this model is usually high. 2) It is a complicated approach especially for projects with a clear SRS. 3) Skills required, to evaluate and review project from time to time, need expertise. 4) Rules and protocols should be followed properly to effectively implement this model. Doing so, through-out the span of project is tough.
5) Due to various customizations allowed from the client, using the same prototype in other projects, in future, is difficult. 6) It is not suitable for low risk projects.
7) Meeting budgetary and scheduling requirements is tough if this development process is followed.
8) Amount of documentation required in intermediate stages makes management of project very complex affair.
Computer users have rapidly increased in both number and diversity . They include managers, accountants, engineers, home makers, teachers, scientists, health care workers, insurance adjusters, salesmen, and administrative assistants. Many of these people work on tasks that rapidly vary on a yearly, monthly, or even daily basis. Consequently, their software needs are diverse, complex, and frequently changing. Professional software developers cannot directly meet all of these needs because of their limited domain knowledge and because their development processes are too slow.
EUD is "a set of methods. or extend a software artifact".
End-user development (EUD) helps to solve this problem. at some point to create. In particular. and they often have real-time awareness of shifts in their respective domains. modify. who are acting as non-professional software developers. EUD enables end users to design or customize the user interface and functionality of software.
. techniques and tools that allow users of software systems. This is valuable because end users know their own context and needs better than anybody else.
Moreover. or modeling and diagramming notations. End users usually do not have training in professionals' programming languages. since end users usually write code in order to achieve a short. formal development processes.
Through EUD.or medium-term goal rather than to create a durable software asset that will produce a continuing revenue stream. end users often lack the time or motivation to learn these traditional techniques.
. end users can tune software to fit their requirements more closely than would be possible without EUD.
email filters are sequenced lists of criteria and actions to take)
.Examples of end-user development include the creation and modification of:
3D models created with end-user oriented tools and approaches such as Sketchup Animation scripts used by graphic artists to describe characters. environments and how characters move to produce an intended animation Configuration files that blur the line between programs and data (e..g.
Game modifications to introduce users' own characters. etc.
. — many recent games are distributed with modification in mind Process models used in workflow applications Prototypes and domain-specific programs written by business people. environments. and scientists to demonstrate or test specific theories Scientific models used in computer simulation Scripts and macros added to extend or automate office productivity suites and graphics applications. engineers.
Spreadsheet models. e. Web pages .plain HTML or HTML and scripting
.g.. used for budgeting or risk analysis Visual programming in the form of visual languages such as AgentSheets.
Frees IS resources for higher priority projects May help reduce the hidden backlog Faster design/implementation cycle More acceptable to users Reduces communications problems between users and IS Encourages innovation and creative solutions
Duplication or effort and waste of resources Greatly increased costs Loss of control over data Loss of control of quality in both programs and data Incompatibles prevent sharing Can be used to circumvent control processes. inflexible systems with short lives
. such as the steering committee Generally produces narrow.
inputs and outputs of the system.
. using an over-abstract (and sometimes graphical) model of the actual system.e. In the context of systems design are included. This is often conducted via modelling.
The logical design of a system pertains to an abstract representation of the data flows. Entity Relationship Diagrams. Logical design includes ER Diagrams i.
following requirements about the system are decided.
The physical design relates to the actual input and output processes of the system. Storage requirements. and how it is displayed as In Physical design. Processing Requirements. This is laid down in terms of how data is input into a system.
. how it is verified/authenticated. System control and backup or recovery. Output requirements. Input requirement. how it is processed.
. Process Design is concerned with how data moves through the system. the physical portion of systems design can generally be broken down into three sub-tasks: User Interface Design:User Interface Design is concerned with how users add information to the system and with how the system presents information back to them. secured and/or transformed as it flows into. and with how and where it is validated.
Put another way. through and out of the system.
Data Design:Data Design is concerned with how the data is represented and stored within the system.
through and out of the system.
Process Design:Process Design is concerned with how data moves through the system.
. and with how and where it is validated. secured and/or transformed as it flows into.
expost and impact evaluations of the development interventions implemented with domestic and aid funds. budgeting and policy formulation process.
The Evaluation Information System (EIS) is a webbased central evaluation database that captures the findings and lessons of all on-going. The evaluation information helps Planners and Policy Makers to learn from the past and to improve the design of future programs. The objective of the EIS is to ensure more effective feedback of evaluation findings and lessons into the planning.
The EIS captures project.wise:• • • • • basic evaluation data key issues overall assessment lessons learned and follow-up actions and recommendations