Wednesday, April 22, 2015

Types of Models


Waterfall Model

The Waterfall Model is the oldest and most well-known SDLC model. The distinctive feature of the Waterfall model is its sequential step-by-step process from requirements analysis to maintenance. The major weakness of the Waterfall Model is that after project requirements are gathered in the first phase, there is no formal way to make changes to the project as requirements change or more information becomes available to the project team. Because requirements almost always change during long development cycles, often the product that is implemented at the end of the process is obsolete as it goes into production. The Waterfall Model is a poor choice for software development projects where requirements are not well-known or understood by the development team.

The sequential phases in Waterfall model are:
Requirement Gathering and analysis: All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification doc.
System Design: The requirement specifications from first phase are studied in this phase and system design is prepared. System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture.
Implementation: With inputs from system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality which is referred to as Unit Testing.
Integration and Testing: All the units developed in the implementation phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures.
Deployment of system: Once the functional and nonfunctional testing is done, the product is deployed in the customer environment or released into the market.
Maintenance: There are some issues which come up in the client environment. To fix those issues patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment.

Agile Model

What is Agile?
Agile model believes that every project needs to be handled differently and the existing methods need to be tailored to best suit the project requirements. In agile the tasks are divided to time boxes (small time frames) to deliver specific features for a release.
Iterative approach is taken and working software build is delivered after each iteration. Each build is incremental in terms of features; the final build holds all the features required by the customer.
Twelve Principals

1. Customer satisfaction by rapid delivery of useful software
2. Welcome changing requirements, even late in development.
3. Working software is delivered frequently (weeks rather than months)
4. Working software is the principal measure of progress
5. Sustainable development, able to maintain a constant pace
6. Close daily cooperation between businesspeople and developers.
7. Face-to-face conversation is the best form of communication (co-location)
8. Projects are built around motivated individuals, who should be trusted
9. Continuous attention to technical excellence and good design
10. Simplicity
11. Self-organizing teams
12. Regular adaptation to changing circumstances

Agile Methods

1.Agile modelling
2.Agile unified process(AUP)
3.Dynamic systems development method)DSDM)
4.Essential unified process(ESSUP)
5.Extreme programming(XP)
6.Feature driven development(FDD)
7.Open unified process(open Up)
9.Velocity tracking

Prototype Model

The Software Prototyping refers to building software application prototypes which display the functionality of the product under development but may not actually hold the exact logic of the original software. Software prototyping is becoming very popular as a software development model, as it enables to understand customer requirements at an early stage of development. It helps get valuable feedback from the customer and helps software designers and developers understand about what exactly is expected from the product under development. Prototype is a working model of software with some limited functionality. The prototype does not always hold the exact logic used in the actual software application and is an extra effort to be considered under effort estimation .Prototyping is used to allow the users evaluate developer proposals and try them out before implementation. It also helps understand the requirements which are user specific and may not have been considered by the developer during product design.

Spiral Model

This model of development combines the features of the prototyping model and waterfall model the spiral model is intended for large, expensive and complicated projects ,aids risk management at regular stages and iterative
1) Determines objectives
2) Identify and resolve risks
3) Development and test
4) Plan the next iteration

Top-Down Model

The Top-down SDLC model was popularized by IBM in the 1970s, and its concepts are used in other SDLC models such as the Waterfall and Spiral Models  In a pure Top-down model, high-level requirements are documented, and programs are built to meet these requirements. Then, the next level is designed and built. A good way to picture the Top-down model is to think of a menu-driven application. The top level menu items would be designed and coded, and then each sublevel would be added after the top level was finished. Each menu item represents a subsystem of the total application.

Bottom-Up Model

In the Bottom-up SDLC model, the lowest level of functionality is designed and programmed first, and finally all the pieces are integrated together into the finished application. This means that, generally, the most complex components are developed and tested first. The idea is that any project show-stoppers will surface early in the project. The Bottom-up model also encourages the development and use of reusable software components that can be used multiple times across many software development projects. Think of a menu driven system where the development starts with the lowest level menu items.

Cocomo Model

Constructive Cost Model, a method for evaluating and/or estimating the cost of software development. There are three levels in the COCOMO hierarchy:

Basic COCOMO: computes software development effort and cost as a function of program size expressed in estimated DSIs. There are three modes within Basic COCOMO:

Organic Mode: Development projects typically are uncomplicated and involve small experienced teams. The planned software is not considered innovative and requires a relatively small amount of DSIs (typically under 50,000).

Semidetached Mode: Development projects typically are more complicated than in Organic Mode and involve teams of people with mixed levels of experience. The software requires no more than 300,000 DSIs. The project has characteristics of both projects for Organic Mode and projects for Embedded Mode.

Embedded Mode: Development projects must fit into a rigid set of requirements because the software is to be embedded in a strongly joined complex of hardware, software, regulations and operating procedures.

Intermediate COCOMO: an extension of the Basic model that computes software development effort by adding a set of "cost drivers," that will determine the effort and duration of the project, such as assessments of personnel and hardware.

Detailed COCOMO: An extension of the Intermediate model that adds effort multipliers for each phase of the project to determine the cost driver’s impact on each step COCOMO was developed by Barry Boehm in his 1981 book, Software Engineering Economics.