The waterfall model

The waterfall model

The classic way of looking at S.E. that accounts for the importance of requirements, design and quality assurance.
The model suggests that software engineers should work in a series of stages. Before completing each stage, they should perform quality assurance (verification and validation). The waterfall model also recognizes, to a limited extent, that you sometimes have to step back to earlier stages.

Limitations of the waterfall model

The model implies that you should attempt to complete a given stage before moving on to the next stage
Does not account for the fact that requirements constantly change. It also means that customers can not use anything until the entire system is complete.

The model makes no allowances for prototyping. It implies that you can get the requirements right by simply writing them down and reviewing them. The model implies that once the product is finished, everything else is maintenance.

Waterfall Strengths
Easy to understand, easy to use Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan, staff, track) Works well when quality is more important than cost or schedule

When to use the Waterfall Model

Requirements are very well known Product definition is stable Technology is understood New version of an existing product Porting an existing product to a new platform.

The spiral model

The spiral model

It explicitly embraces prototyping and an iterative approach to software development.
Start by developing a small prototype. Followed by a mini-waterfall process, primarily to gather requirements. Then, the first prototype is reviewed. In subsequent loops, the project team performs further requirements, design, implementation and review. The first thing to do before embarking on each new loop is risk analysis( includes development cost overruns, operating cost miscalculations or any other factor that leads to less than satisfactory final product) Maintenance is simply a type of on-going development. Intended for large, expensive and complicated projects

Spiral Model Weaknesses

Time spent for evaluating risks too large for small or low-risk projects Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive The model is complex Risk assessment expertise is required Spiral may continue indefinitely Developers must be reassigned during nondevelopment phase activities May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration

When to use Spiral Model

When creation of a prototype is appropriate When costs and risk evaluation is important For medium to high-risk projects Long-term project commitment unwise because of potential changes to economic priorities Users are unsure of their needs Requirements are complex New product line Significant changes are expected (research and exploration)

Prototyping Model
A prototype is a working model that is functionally equivalent to a component of the product. reflects an attempt to increase the flexibility of the development process by allowing the client to interact and experiment with a working representation of the product developmental process only continues once the client is satisfied with the functioning of the prototype

Overview
Identify basic requirements. Determine basic requirements including the input and output information desired. Details, such as security, can typically be ignored. Develop Initial Prototype. The initial prototype is developed that includes only user interfaces. Review The customers, including end-users, examine the prototype and provide feedback on additions or changes. Revise and Enhancing the Prototype. Using the feedback both the specifications and the prototype can be improved. If changes are introduced then a repeat of steps #3 and #4 may be needed.

Types of Prototyping
Throwaway prototype
Creation of a model that will eventually be discarded rather than becoming part of the finally delivered software

Evolutionary prototype
To build a very robust prototype in a structured manner and constantly refine and rebuilt it

Incremental prototype
Final product is built as separate prototypes. At the end the separate prototypes are being merged in an overall design

The evolutionary model

The evolutionary model

It shows software development as a series of hills, each representing a separate loop of the spiral.
Shows that loops, or releases, tend to overlap each other. Makes it clear that development work tends to reach a peak, at around the time of the deadline for completion. Shows that each prototype or release can take
different amounts of time to deliver; differing amounts of effort.

Evolutionary Prototyping Steps

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, the user evaluates for problems and suggests improvements. This loop continues until the user is satisfied

Evolutionary Prototyping Strengths

Customers can see the system requirements as they are being gathered Developers learn from customers A more accurate end product Unexpected requirements accommodated Allows for flexible design and development Steady, visible signs of progress produced Interaction with the prototype stimulates awareness of additional needed functionality

Evolutionary Prototyping Weaknesses

Tendency to abandon structured program development for code-and-fix development Bad reputation for quick-and-dirty methods Overall maintainability may be overlooked The customer may want the prototype delivered. Process may continue forever (scope creep)

When to use Evolutionary Prototyping

Requirements are unstable or have to be clarified as the requirements clarification stage of a waterfall model Develop user interfaces Short-lived demonstrations New, original development With the analysis and design portions of object-oriented development.

Incremental Model

Incremental Model
It introduces the notion of incremental development.
After requirements gathering and planning, the project should be broken into separate subprojects, or phases. Each phase can be released to customers when ready. Parts of the system will be available earlier than when using a strict waterfall approach. However, it continues to suggest that all requirements be finalized at the start of development.

Incremental Model Strengths

Develop high-risk or major functions first Each release delivers an operational product Customer can respond to each build Uses divide and conquer breakdown of tasks Lowers initial delivery cost Initial product delivery is faster Customers get important functionality early Risk of changing requirements is reduced

When to use the Incremental Model

Risk, funding, schedule, program complexity, or need for early realization of benefits. Most of the requirements are known up-front but are expected to evolve over time A need to get basic functionality to the market early On projects which have lengthy development schedules On a project with new technology

Rapid Application Model (RAD)

Gathering requirements using workshops or focus groups Prototyping and early, 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

RAD Model Phases

Requirements planning phase (a workshop utilizing structured discussion of business problems) User description phase automated tools capture information from users Construction phase productivity tools, such as code generators, screen generators, etc. inside a time-box. (Do until done) Cutover phase -- installation of the system, user acceptance testing and user training

RAD Strengths
Reduced cycle time and improved productivity with fewer people means lower costs Time-box approach mitigates cost and schedule risk Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs Focus moves from documentation to code. Uses modeling concepts to capture information about business, data, and processes. Reuse of existing components

RAD Weaknesses
Risk of never achieving closure Documentation never exist Requires a system that can be modularized Developers and customers must be committed to rapid-fire activities in an abbreviated time frame.

When to use RAD

Reasonably well-known requirements User involved throughout the life cycle Project can be time-boxed Functionality delivered in increments High performance not required Low technical risks System can be modularized Experienced programmers and analysts team

Joint Application Development

JAD, is a process originally developed for designing a computer-based system. It brings together end users and IT professionals in a highly focused workshop. The advantages of JAD include a dramatic shortening of the time it takes to complete a project. It also improves the quality of the final product by focusing on the up-front portion of the development lifecycle, thus reducing the likelihood of errors that are expensive to correct later on.

Features of JAD
JAD centers around a structured workshop session. Participants get together in a room to discuss the problem/project. Everyone hears what the rest of the group has to say. JAD can eliminate many of the problems with traditional meetings. Meetings are not well regarded as a productive forum. JAD turns meetings into workshops.
They are less frequent More structured, and productive An agenda provides the structure The facilitator directs the process Visual aids clarify concepts being discussed and the group dynamics, with constant feedback, stimulates creativity

 JAD Purpose: to define the project, design a solution, and monitor the project until it reaches completion. JAD Philosophy: The JAD process is based on four simple ideas:

1. People who actually do a job have the best understanding of that job.
2. People who are trained in information technology have the best understanding of the possibilities of that technology.

3. Information systems and business processes rarely exist in isolation -they transcend the confines of any single system or office and effect work in related departments. People working in these related areas have valuable insight on the role of a system within a larger community. 4. The best information systems are designed when all of these groups work together on a project as equal partners. JAD Scope 1. The JAD should cover the complete development life cycle of a system. 2. The JAD is usually a 3 to 6 month well-defined project. 3. For large-scale projects, it is recommended that the project be approached incrementally, and that separate JAD's be used for each increment.

Basic Components of a JAD Session

JAD sessions:
1. Are more focused. 2. Are conducted in a dedicated environment. 3. Quickly drive major requirements. 4. Help better develop the "look & feel of the interface.

JAD participants typically include:

Project sponsor Project lead Facilitator End users Developers Observers Subject matter experts

Guidelines for a Successful JAD

A clear purpose shared by all team members - the project charter A diverse team, representative of all areas effected by this project. Every person in the group has equal responsibility and decision making power. Every idea is valuable. Throughout the JAD, listen and acknowledge each idea and concern. Evaluating ideas during a brainstorming session will shut down the creative process. The best idea may never get said out of fear of being shot down. Participation by everyone is very important. Encourage quieter members to speak, they often have the best ideas. Don't allow 1 or 2 members to dominate. This is the facilitators responsibility as well as the whole teams' responsibility.

 Listen when others speak, don't interrupt or talk while others are talking (side conversations may have great ideas...we don't want to miss them). Maintain a parking lot to record important issues that are not within the scope of this project. Don't hold meetings, just to hold meetings. Only meet when there is something substantial to talk about. Don't let more than 3 or 4 weeks pass between meetings, you will loose momentum. Remember, each meeting is a motivation for the team to complete tasks assigned. It is no fun to come to a meeting and admit you didn't finish your task. Decisions are reached by consensus. We are here to create a win/win solution...win/lose solutions aren't good enough.

BENEFITS OF JAD
Enhanced communication and relationship between business end users and IT personnel Build consensus and ownership Reduced system cost and development time Improved system quality and productivity Helps project teams get focused and stay focused Helps you get the right job done at the right time!