SDLC MODELS ASSIGNMENT

BYV.SAI KRISHNA

EMPID:3243

System Development Life cycle (SDLC)

What is a SDLC and why do we need that?

System - an organized collection of independent tasks and processes that is designed to work together in order to accomplish specific objectives.  The processes and tasks typically receive input(s) from and provide output(s) to other processes and tasks and even other systems.  The tasks and processes may or may not be supported by automation

SDLC refers to a methodology for developing systems.  It provides a consistent framework of tasks and deliverables needed to develop systems.  The SDLC methodology may be condensed to include only those activities appropriate for a particular project, whether the system is automated or manual, whether it is a new system, or an enhancement to existing systems.  The SDLC methodology tracks a project from an idea developed by the user, through a feasibility study, systems analysis and design, programming, pilot testing, implementation, and post-implementation analysis. Documentation developed during the project development is used in the future when the system is reassessed for its continuation, modification, or deletion.

Water Fall Model:The waterfall model derives its name due to the cascading effect from one phase to the other.In this model each phase well defined starting and ending point, with identifiable deliveries to the next phase.

this model is sometimes also known as the linear sequential model or the software life cycle.

The model consist of six distinct stages, namely:

1. In the requirements analysis phase

(a) The problem is specified along with the desired service objectives (goals)

(b) The constraints are identified

2. In the specification phase the system specification is produced from the detailed definitions of (a) and (b) above. This document should clearly define the product function.

 

in some cases, the requirements analysis and specifications phases are combined and represented as a single phase.

3. In the system and software design phase, the system specifications are translated into a software representation. The software engineer at this stage is concerned with:

· Data structure

· Software architecture

· Algorithmic detail and

· Interface representations

 

The hardware requirements are also determined at this stage along with a picture of the overall system architecture. By the end of this stage the software engineer should be able to identify the relationship between the hardware, software and the associated interfaces. Any faults in the specification should ideally not be passed ‘down stream’

4.In the implementation and testing phase stage the designs are translated into the software domain

· Detailed documentation from the design phase can significantly reduce the coding effort.

· Testing at this stage focuses on making sure that any errors are identified and that the software meets its required specification.

5.In the integration and system testing phase all the program units are integrated and tested to ensure that the complete system meets the software requirements. After this stage the software is delivered to the customer [Deliverable – The software product is delivered to the client for acceptance testing.]

6.The maintenance phase the usually the longest stage of the software. In this phase the software is updated to:

· Meet the changing customer needs

· Adapted to accommodate changes in the external environment

· Correct errors and oversights previously undetected in the testing phases

· Enhancing the efficiency of the software

 

Observe that feed back loops allow for corrections to be incorporated into the model. For example a problem/update in the design phase requires a ‘revisit’ to the specifications phase. When changes are made at any phase, the relevant documentation should be updated to reflect that change.

 

 Advantages

· Testing is inherent to every phase of the waterfall model

· It is an enforced disciplined approach

· It is documentation driven, that is, documentation is produced at every stage

· 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

Disadvantages

The waterfall model is the oldest and the most widely used paradigm.However, many projects rarely follow its sequential flow. This is due to the inherent problems associated with its rigid format. Namely:

· 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)

When to use the Waterfall Model: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.

In the above conditions it is better to use the Water Fall model..

Spiral model:-

The spiral model emphasizes the need to go back and reiterate earlier stages a number of times as the project progresses. It's actually a series of short waterfall cycles, each producing an early prototype representing a part of the entire project. This approach helps demonstrate a proof of concept early in the cycle, and it more accurately reflects the disorderly, even chaotic evolution of technology.

Spiral Model Advantages

· Provides early indication of insurmountable risks, without much cost

· Users see the system early because of rapid prototyping tools

· Critical high-risk functions are developed first

· The design does not have to be perfect

· Users can be closely tied to all life cycle steps

· Early and frequent feedback from users

· Cumulative costs assessed frequently

Spiral Model Disadvantages :

· 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 non-development 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)

Rapid Application development(RAD) model:

RAD is sequential software development model. It contains extremely short life

cycle. If the requirements are well understood then we can choose this model. Here the analysis,

design, implementation and testing phases are compressed into a short and iterative development life

cycles.

Advantages:

This model takes very less time because usage of powerful tools results into reduced software

development life cycle time

·As customer is involved in all stages of development it leads to a product that has high

customer satisfaction.

·Feedback from the customer/client is available at the initial stages.

·It uses reusable components to reduce the life cycle time.

·All functions are modularized so it is easy to work with.

Disadvantages:

·For large projects RAD require highly skilled engineers in the team.

·Absence of reusable components can lead to failure of the project.(Project may not be

complete within the time)

If it is difficult to modularize the project then RAD may not work well.

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

Prototype model

A prototype is a working model that is functionally equivalent to a component of the product. In

some cases the client don't have the clear idea of the software product that is to be developed. In such

cases we choose this model. Here first a prototype of the actual product is developed and it is given to

the client then based on the client response future enhancements are made to the product.

This process is useful when requirements are not clear. This process is flexible and we can make

changes easily so risk is less when compared to other software development models.

Advantages:

· 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

Disadvantages:

· 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 Prototyping:When to use 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.

V-Model:

The V-model is a software development model which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing

Verification Phases

Requirements analysis:

In this phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However, it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase.

System Design:

System engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly.

The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase.

Architecture Design:

This phase can also be called as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in this phase.

Module Design:

This phase can also be called as low-level design. The designed system is broken up in to smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed

functional logic of the module, in pseudo code - database tables, with all elements, including their type and size - all interface details with complete API references- all dependency issues- error message listings- complete input and outputs for a module. The unit test design is developed in this stage.

V-Shaped A dvantages: :

· Emphasize planning for verification and validation of the product in early stages of product development

· Each deliverable must be testable

· Project management can track progress by milestones

· Easy to use

V-Shaped Disadvantages:

· Does not easily handle concurrent events

· Does not handle iterations or phases

· Does not easily handle dynamic changes in requirements

· Does not contain risk analysis activities

When to use the V-Shaped Model:

· Excellent choice for systems requiring high reliability – hospital patient control applications

· All requirements are known up-front

· When it can be modified to handle changing requirements beyond analysis phase

· Solution and technology are known

Incremental SDLC Model:· Construct a partial implementation of a total system

· Then slowly add increased functionality

· The incremental model prioritizes requirements of the system and then implements them in groups.

· Each subsequent release of the system adds function to the previous release, until all designed functionality has been implemented.

Incremental Model A dvantages:

· 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

Incremental Model Disadvantages :

· Requires good planning and design

· Requires early definition of a complete and fully functional system to allow for the definition of increments

· Well-defined module interfaces are required (some will be developed long before others)

· Total cost of the complete system is not lower

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

Agile:

The Agile model to some extent is similar to Water-Fall Model, but in this; the application will be broken down in multiple chunks. All the SDLC phases will be done in chunks followed in multiple iterations.

Reacting against the perceived strict regimentation of the Waterfall Model, the Agile model appeared in the 1990s. Its developers believed the Waterfall model was too slow and bureaucratic and did not comfortably accommodate the ways systems/software engineers actually work best. Agile, put simply, is where software is developed progressively with each new release adding more capabilities

It appeared under different names and flavors such as: Scrum (in management), Crystal Clear, Extreme Programming (XP), Adaptive Software Development, Feature Driven Development, and DSDM.

Agile aims to reduce risk by breaking projects into small, time-limited modules or time boxes ("iterations") with each iteration being approached like a small, self-contained mini-project, each lasting only a few weeks. Each iteration has it own self-contained stages of analysis, design, production, testing and documentation. In theory, a new software release could be done at the end of each iteration, but in practice the progress made in one iteration may not be worth a release and it will be carried over and incorporated into the next iteration. The project's priorities, direction and progress are re-evaluated at the end of each iteration

Agile's aims and characteristics include:

·Customer satisfaction by rapid, continuous delivery of useful software

·Working software is delivered frequently (weeks rather than months)

·Working software is the principal measure of progress.

·Even late changes in requirements are welcomed.

·Close, daily, cooperation between developers and customers

·Face-to-face conversation is the best form of communication.

·Projects are built around motivated individuals, who should be trusted (rather than micro-managed)

·Continuous attention to technical excellence and good design.

·Simplicity

·Self-organizing teams

·Regular adaptation to changing circumstances

Advantages

·Promotes teamwork and cross training.

·Functionality can be developed rapidly and demonstrated.

·Resource requirements are minimum.

·Suitable for fixed or changing requirements

·Delivers early partial working solutions.

·Good model for environments that change steadily.

·Minimal rules, documentation easily employed.

·Enables concurrent development and delivery within an overall planned context.

Disadvantages

·Not suitable for handling complex dependencies.

·More risk of sustainability, maintainability and extensibility.

·An overall plan, an agile leader and agile PM practice is a must without which it will not work.

·Strict delivery management dictates the scope, functionality to be delivered, and adjustments to meet the deadlines.

PDCA(Plan Do Check Act)Model:

PLAN

Establish the objectives and processes necessary to deliver results in accordance with the expected output. By making the expected output the focus, it differs from other techniques in that the completeness and accuracy of the specification is also part of the improvement.

DO

Implement the new processes. Often on a small scale if possible.

CHECK

Measure the new processes and compare the results against the expected results to ascertain any differences.

ACT

Analyze the differences to determine their cause. Each will be part of either one or more of the P-D-C-A steps. Determine where to apply changes that will include improvement. When a pass through these four steps does not result in the need to improve, refine the scope to which PDCA is applied until there is a plan that involves improvement.

Advantages:

NO.1.Minimum possibility of an "error":

Possibility of an error is reduced to a minimum,when you complete the whole cycle.(planning,doing the work then checking all the steps carefully and finally taking action, in case there is something more to be done or some corrections to be made).

No.2.On - time corrective action:

Another great benefit of PDCA is, that you can take corrective action, in case something has not gone as per the plan.You can correct it before your mistake is noticed by someone else,(like your client or boss) and you face an embarrassing situation.

No.3.Optimum utilization of time:

PDCA cycle also enables you to optimally utilize your time.You need not waste time in trying to find out questions like at what stage of the project are you in ? or how much time will a particular step take or where does the fault lie? etc.You will be in complete hang of things.This will help you and your colleagues save lot of time.

No.4.Improved productivity:

Your productivity will improve naturally, as there will optimum utilization of your time and energy.You would know the inputs you have to give at different stages of your work.Thus making your task much more simpler and faster for you.

No.5.Appreciation for your work:

Your seniors and juniors, will appreciate not only your talent but also your efficiency and smart way of functioning.You might even motivate many other to follow your example.This will benefit the organization as a whole.And you will be given credit for that.