Software ProcessSoftware Process

Introduction to SDLCIntroduction to SDLC

Systems Development Life Cycle (SDLC) adheres to Systems Development Life Cycle (SDLC) adheres to important phases that are essential for developers, such as important phases that are essential for developers, such as planning, analysis, design, testing and implementation, planning, analysis, design, testing and implementation,

There are several Systems Development Life Cycle Models There are several Systems Development Life Cycle Models in existence. in existence.

The oldest model, that was originally regarded as "the The oldest model, that was originally regarded as "the Systems Development Life Cycle" is the waterfall model: a Systems Development Life Cycle" is the waterfall model: a sequence of stages in which the output of each stage sequence of stages in which the output of each stage becomes the input for the next. becomes the input for the next.

These stages generally follow the same basic steps but These stages generally follow the same basic steps but many different waterfall methodologies give the steps many different waterfall methodologies give the steps different names and the number of steps seem to vary different names and the number of steps seem to vary between 4 and 7. between 4 and 7.

There is no definitively correct Systems Development Life There is no definitively correct Systems Development Life Cycle model, but the steps can be characterized and Cycle model, but the steps can be characterized and divided in several stepsdivided in several steps

Initiation/Initiation/planningplanning

To generate a high-level view of the To generate a high-level view of the intended project and determine the goals intended project and determine the goals of the project. of the project.

The feasibility study is used to present the The feasibility study is used to present the project to upper management in an project to upper management in an attempt to gain funding. attempt to gain funding.

Projects are typically evaluated in three Projects are typically evaluated in three areas of feasibility: economical, areas of feasibility: economical, operational, and technical. operational, and technical.

It is also used as a reference to keep the It is also used as a reference to keep the project on track and to evaluate the project on track and to evaluate the progress of the MIS team. progress of the MIS team.

The goal of systems analysis is to determine The goal of systems analysis is to determine where the problem is in an attempt to fix the where the problem is in an attempt to fix the system. system.

This step involves breaking down the system in This step involves breaking down the system in different pieces and drawing diagrams to analyze different pieces and drawing diagrams to analyze the situation. the situation.

Analyze project goals, break down functions that Analyze project goals, break down functions that need to be created, and attempt to engage users need to be created, and attempt to engage users so that definite requirements can be defined. so that definite requirements can be defined.

Requirement Gathering requires individual/team Requirement Gathering requires individual/team from client as well as service provider side to get from client as well as service provider side to get a detailed and accurate requirements.a detailed and accurate requirements.

Requirements gathering and Requirements gathering and analysisanalysis

DesignDesign In systems design functions and operations are described in In systems design functions and operations are described in

detail, including screen layouts, business rules, process detail, including screen layouts, business rules, process diagrams and other documentation. diagrams and other documentation.

The output of this stage will describe the new system as a The output of this stage will describe the new system as a collection of modules or subsystems.collection of modules or subsystems.

The design stage takes as its initial input the requirements The design stage takes as its initial input the requirements identified in the approved requirements document (SRS). identified in the approved requirements document (SRS).

For each requirement, a set of one or more design elements For each requirement, a set of one or more design elements will be produced as a result of interviews, workshops, and/or will be produced as a result of interviews, workshops, and/or prototype efforts. prototype efforts.

Design elements describe the desired software features in Design elements describe the desired software features in detail, and generally include functional hierarchy diagrams, detail, and generally include functional hierarchy diagrams, screen layout diagrams, tables of business rules, business screen layout diagrams, tables of business rules, business process diagrams, pseudocode, and a complete entity-process diagrams, pseudocode, and a complete entity-relationship diagram with a full data dictionary. relationship diagram with a full data dictionary.

These design elements are intended to describe the software These design elements are intended to describe the software in sufficient detail that skilled programmers may develop the in sufficient detail that skilled programmers may develop the software with minimal additional input.software with minimal additional input.

Build or codingBuild or coding

Modular and subsystem programming Modular and subsystem programming code will be accomplished during this code will be accomplished during this stage.stage.

Unit testing and module testing are done Unit testing and module testing are done in this stage by the developers. in this stage by the developers.

This stage is intermingled with the next This stage is intermingled with the next in that individual modules will need in that individual modules will need testing before integration to the main testing before integration to the main project.project.

TestingTesting

The code is tested at various levels in software testing. The code is tested at various levels in software testing. Unit, system and user acceptance testing are often Unit, system and user acceptance testing are often

performed. performed. This is a grey area as many different opinions exist as to This is a grey area as many different opinions exist as to

what the stages of testing are and how much if any iteration what the stages of testing are and how much if any iteration occurs. occurs.

Types of testing:Types of testing: Data set testing. Data set testing. Unit testing Unit testing System testing System testing Integration testing Integration testing Black box testing Black box testing White box testing White box testing Module testing Module testing Regression testing Regression testing Automation testing Automation testing User acceptance testingUser acceptance testing

Operations and Operations and maintenancemaintenance

The deployment of the system includes The deployment of the system includes changes and enhancements before the changes and enhancements before the decommissioning or sunset of the decommissioning or sunset of the system. system.

Maintaining the system is an important Maintaining the system is an important aspect of SDLC. As key personnel aspect of SDLC. As key personnel change positions in the organization, change positions in the organization, new changes will be implemented, which new changes will be implemented, which will require system updateswill require system updates

Management and controlManagement and control

The Systems Development Life Cycle (SDLC) The Systems Development Life Cycle (SDLC) phases serve as a programmatic guide to project phases serve as a programmatic guide to project activity and provide a flexible but consistent way to activity and provide a flexible but consistent way to conduct projects to a depth matching the scope of conduct projects to a depth matching the scope of the project. the project.

It is critical for the project manager to establish and It is critical for the project manager to establish and monitor control objectives during each SDLC phase monitor control objectives during each SDLC phase while executing projects. while executing projects.

Control objectives help to provide a clear statement Control objectives help to provide a clear statement of the desired result or purpose and should be used of the desired result or purpose and should be used throughout the entire SDLC process. throughout the entire SDLC process.

Control objectives can be grouped into major Control objectives can be grouped into major categories (Domains), and relate to the SDLC categories (Domains), and relate to the SDLC phases as shown in the figure. phases as shown in the figure.

SDLC Phases Related to Management Controls

To manage and control any SDLC initiative, each To manage and control any SDLC initiative, each project will be required to establish some degree of project will be required to establish some degree of a a Work Breakdown StructureWork Breakdown Structure (WBS) to capture and (WBS) to capture and schedule the work necessary to complete the schedule the work necessary to complete the project. project.

A A work breakdown structure (WBS)work breakdown structure (WBS) in in project managementproject management and and systems engineeringsystems engineering, is a , is a tool used to define and group a tool used to define and group a projectproject's discrete 's discrete work elements (or work elements (or taskstasks) in a way that helps ) in a way that helps organize and define the total work scope of the organize and define the total work scope of the projectproject

The WBS and all programmatic material should be The WBS and all programmatic material should be kept in the “Project Description” section of the kept in the “Project Description” section of the project notebook. project notebook.

The WBS format is mostly left to the project The WBS format is mostly left to the project manager to establish in a way that best describes manager to establish in a way that best describes the project work. the project work.

Strengths of SDLCStrengths of SDLC

Control.Control. Monitor Large projects.Monitor Large projects. Detailed steps.Detailed steps. Evaluate costs and completion targets.Evaluate costs and completion targets. Documentation.Documentation. Well defined user input.Well defined user input. Ease of maintenance.Ease of maintenance. Development and design standards.Development and design standards. Tolerates changes in MIS staffing.Tolerates changes in MIS staffing.

Weakness of SDLCWeakness of SDLC

Increased development time.Increased development time. Increased development cost.Increased development cost. Systems must be defined up front.Systems must be defined up front. Rigidity.Rigidity. Hard to estimate costs & project Hard to estimate costs & project

overruns.overruns. User input is sometimes limited.User input is sometimes limited.

Waterfall ModelWaterfall Model

The The waterfall modelwaterfall model is a sequential software is a sequential software development process, in which progress is development process, in which progress is seen as flowing steadily downwards (like a seen as flowing steadily downwards (like a waterfall) through the phases of Initiation, waterfall) through the phases of Initiation, Analysis, Design (validation), Construction, Analysis, Design (validation), Construction, Testing and maintenanceTesting and maintenance

The first formal description of the waterfall The first formal description of the waterfall model is often cited to be an article published model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995).in 1970 by Winston W. Royce (1929–1995).

Maintenance

Waterfall Model

Disadvantages of the Waterfall Disadvantages of the Waterfall Model. Model.

As it is very important to gather all possible requirements As it is very important to gather all possible requirements during the Requirement Gathering and Analysis phase in during the Requirement Gathering and Analysis phase in order to properly design the system, not all requirements are order to properly design the system, not all requirements are received at once, the requirements from customer goes on received at once, the requirements from customer goes on getting added to the list even after the end of "Requirement getting added to the list even after the end of "Requirement Gathering and Analysis" phase, this affects the system Gathering and Analysis" phase, this affects the system development process and its success in negative aspects. development process and its success in negative aspects.

The problems with one phase are never solved completely The problems with one phase are never solved completely during that phase and in fact many problems regarding a during that phase and in fact many problems regarding a particular phase arise after the phase is signed off, this particular phase arise after the phase is signed off, this results in badly structured system as not all the problems results in badly structured system as not all the problems (related to a phase) are solved during the same phase. (related to a phase) are solved during the same phase.

The project is not partitioned in phases in flexible way. The project is not partitioned in phases in flexible way. As the requirements of the customer goes on getting added As the requirements of the customer goes on getting added

to the list, not all the requirements are fulfilled, this results in to the list, not all the requirements are fulfilled, this results in development of almost unusable system. These requirements development of almost unusable system. These requirements are then met in newer version of the system; this increases are then met in newer version of the system; this increases the cost of system development the cost of system development

Prototyping ModelPrototyping Model

Software prototypingSoftware prototyping, an activity during certain software , an activity during certain software development, is the creation of prototypes, i.e., incomplete development, is the creation of prototypes, i.e., incomplete versions of the software program being developed.versions of the software program being developed.

A prototype typically simulates only a few aspects of the A prototype typically simulates only a few aspects of the features of the eventual program, and may be completely features of the eventual program, and may be completely different from the eventual implementation.different from the eventual implementation.

The conventional purpose of a prototype is to allow users of The conventional purpose of a prototype is to allow users of the software to evaluate developers' proposals for the the software to evaluate developers' proposals for the design of the eventual product by actually trying them out, design of the eventual product by actually trying them out, rather than having to interpret and evaluate the design rather than having to interpret and evaluate the design based on descriptions. based on descriptions.

Prototyping can also be used by end users to describe and Prototyping can also be used by end users to describe and prove requirements that developers have not considered.prove requirements that developers have not considered.

The process of prototyping involves the The process of prototyping involves the following steps following steps

Identify basic requirements Identify basic requirements Determine basic requirements including the input and output Determine basic requirements including the input and output

information desired. Details, such as security, can typically be information desired. Details, such as security, can typically be ignored. ignored.

Develop Initial Prototype Develop Initial Prototype The initial prototype is developed that includes only user The initial prototype is developed that includes only user

interfaces. interfaces. Review Review

The customers, including end-users, examine the prototype The customers, including end-users, examine the prototype and provide feedback on additions or changes. and provide feedback on additions or changes.

Revise and Enhance the Prototype Revise and Enhance the Prototype Using the feedback both the specifications and the prototype Using the feedback both the specifications and the prototype

can be improved. Negotiation about what is within the scope can be improved. Negotiation about what is within the scope of the contract/product may be necessary. If changes are of the contract/product may be necessary. If changes are introduced then a repeat of steps #3 ands #4 may be neededintroduced then a repeat of steps #3 ands #4 may be needed

Software prototyping has many Software prototyping has many

variantsvariants Throwaway Prototyping:Throwaway Prototyping: Throwaway or Rapid Prototyping refers to the creation Throwaway or Rapid Prototyping refers to the creation

of a model that will eventually be discarded rather of a model that will eventually be discarded rather than becoming part of the final delivered software. than becoming part of the final delivered software. After preliminary requirements gathering is After preliminary requirements gathering is accomplished, a simple working model of the system is accomplished, a simple working model of the system is constructed to visually show the users what their constructed to visually show the users what their requirements may look like when they are requirements may look like when they are implemented into a finished systemimplemented into a finished system

The steps in this approach are:The steps in this approach are: Write preliminary requirements Write preliminary requirements Design the prototype Design the prototype User experiences/uses the prototype, specifies new User experiences/uses the prototype, specifies new

requirements. requirements. Writing final requirements Writing final requirements Developing the real products.Developing the real products.

Evolutionary PrototypingEvolutionary Prototyping is quite different is quite different from Throwaway Prototyping. from Throwaway Prototyping.

The main goal when using Evolutionary The main goal when using Evolutionary Prototyping is to build a very robust Prototyping is to build a very robust prototype in a structured manner and prototype in a structured manner and constantly refine it.constantly refine it.

"The reason for this is that the Evolutionary "The reason for this is that the Evolutionary prototype, when built, forms the heart of the prototype, when built, forms the heart of the new system, and the improvements and new system, and the improvements and further requirements will be built.”further requirements will be built.”

Evolutionary Prototypes have an advantage Evolutionary Prototypes have an advantage over Throwaway Prototypes in that they are over Throwaway Prototypes in that they are functional systems. Although they may not functional systems. Although they may not have all the features the users have have all the features the users have planned, they may be used on an interim planned, they may be used on an interim basis until the final system is delivered.basis until the final system is delivered.

The spiral model was defined by Barry Boehm in his The spiral model was defined by Barry Boehm in his 1988 article "A Spiral Model of Software 1988 article "A Spiral Model of Software Development and Enhancement". This model was Development and Enhancement". This model was not the first model to discuss iterative development, not the first model to discuss iterative development, but it was the first model to explain why the but it was the first model to explain why the iteration matters.iteration matters.

As originally envisioned, the iterations were As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client starts with a design goal and ends with the client (who may be internal) reviewing the progress thus (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the each phase of the project, with an eye toward the end goal of the project.end goal of the project.

Spiral modelSpiral model

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2

Prototype 3Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

Code

Unit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternatives,identify, resolve risks

Determine objectives,alternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW

Spiral model of the software Spiral model of the software processprocess

Phases in "Spiral Model" Phases in "Spiral Model" Plan:Plan: In this phase, the objectives, alternatives and constraints of the In this phase, the objectives, alternatives and constraints of the

project are determined and are documented. The objectives and other project are determined and are documented. The objectives and other specifications are fixed in order to decide which strategies/approaches specifications are fixed in order to decide which strategies/approaches to follow during the project life cycle. to follow during the project life cycle.

Risk Analysis:Risk Analysis: This phase is the most important part of "Spiral Model". This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies are developing a cost effective project are analyzed and strategies are decided to use them. This phase has been added specially in order to decided to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the solution in order to deal with the potential changes in the requirements. requirements.

Engineering:Engineering: In this phase, the actual development of the project is In this phase, the actual development of the project is carried out. The output of this phase is passed through all the phases carried out. The output of this phase is passed through all the phases iteratively in order to obtain improvements in the same. iteratively in order to obtain improvements in the same.

Customer Evaluation:Customer Evaluation: In this phase, developed product is passed on In this phase, developed product is passed on to the customer in order to receive customer’s comments and to the customer in order to receive customer’s comments and suggestions which can help in identifying and resolving potential suggestions which can help in identifying and resolving potential problems/errors in the software developed. problems/errors in the software developed.

This phase is very much similar to TESTING phaseThis phase is very much similar to TESTING phase. .