Software Development Life Cycle & Process Models

(1)

International Journal of Engineering Technology & Management Research

Journal homepage: www.ijetmr.org

Abstract—Process Models are basically the building blocks of a software product. Whenever a software product is engineered the software process is carried out under the planning of certain models and these models are termed as process models. This paper is strictly bound to the various Process Models and SDLC, on which all these process models are based.

Keywords—SDLC, Waterfall Model, Incremental Model, Prototype Model, Spiral Model.

INTRODUCTION

Process models are basically the most important part of a software development cycle. Whenever a client reaches a company with his/her requirements the company after a series of planned steps and procedures eventually execute the requirement procedures under a process model (which is selected according to the needs and time slot assigned by the user). In this paper we will cover some important types of models such as Waterfall Model, Prototype Model, Incremental Model, RAD Model, Spiral Model, Evolutionary Model, etc. These models are supposedly used to suit the varied and diverse requirements of the client and also sometimes of surroundings. These models run on the

basic architecture of SDLC (Software Development Life Cycle).

DISCUSSION I. AN OVERVIEW OF SDLC (Software Development Life Cycle) According to SDLC whenever a software product is to be developed/engineered then it have a specific life-cycle that is from its initial state to its final Delivery/ Deployment state.

Every software product starts with a request for the product by the customer. This is called the Product Conception. Starting with this stage it undergoes transformation through a series of identifiable stages until it is fully developed and released to the customer.

After release the product is used by the customer and is finally retired when it is no longer useful. This forms the essence of the life cycle of every software product. Based on this we can define software lifecycle as given in Fig. 1

Software process models are general approaches for organizing a project into activities.

Software Development Life Cycle & Process Models

Paritosh Deore B.E. Student, Branch CSE,

Takshshila Institute of Engineering & Technology Jabalpur (M.P.) [INDIA]

Sanket Raina B.E. Student, Branch CSE,

Prateeksha Gupta B.E. Student, Branch CSE,

Preeti Sharma B.E. Student, Branch CSE,

(2)

Help the project manager and his team to decide:-

 What work should be done;

 In what sequence to perform the work.

These models should be seen as aids to thinking, not rigid prescriptions of the way to do things.

Each project ends up with its own unique plan.

Fig. 1 Software Development Life Cycle SDLC is a series of identifiable steps that a software product undergoes during its lifetime.

FEASIBILITY: Determining if the proposed development is worthwhile.

 Market Analysis:-

Determining if there is a potential market for this product.

REQUIREMENT: Determining, what functionality the software should contain.

 Requirement Elicitation:- Obtaining the requirements from

the user.

 Domain Analysis:-

Determining what tasks and structure are common to this problem.

PROJECT PLANNING: Determining how to develop the software.

 Cost Analysis:-

a) Cost Estimate.

b) Software quality and assurance.

(SQA).

c) Determining activities that will help to ensure quality of the product.

 Work Breakdown Structure:- Determining the sub-tasks necessary to develop the product. It is subdivided into modules. DESIGN: Determining how the software should provide the functionality.

a) Architectural Design:- Designing the structure of system.

b) Interface Design:-

Specifying the interface for the parts of the system.

c) Detailed Design:-

D e s i g n i n g t h e al gori t hm s for the individual parts.

IMPLEMENTATION: Building the software, Coding.

TESTING: Executing the software with

data to ensure that the software works correctly. There are different types of testing in Software Engineering like Unit Testing, Integration Testing, and Alpha & Beta Testing etc.

DELIVERY: Providing the customer

with an effective Software solution.

 Installation:-

Making the software available at the customer’s operational site. Either ON-SITE, wherever the Client requests the software product to be delivered OR OFF-SITE, the client himself has to collect the software product form the Company.

 Training:-

Teaching the client’s company OR the Client to use the software.

 HELP-DESK:-

Answering the questions of the user.

(3)

MAINTENANCE: Updating and improving the software to ensure continued usefulness.

II. PROCESS MODELS

As per the requirements that were generated by client there were many types of process models generated by companies. In this paper we’ll have an overview of the following various process models:-

1. Waterfall model. 2. Prototype model. 2. Incremental model. 3. Spiral model. 4. RAD model.

These are some of the most frequently used models.

THE WATERFALL MODEL The waterfall model is the classical model of software engineering. This model is one of the oldest models and is widely used in

government projects and in many major companies. As this model emphasizes planning in early stages, it ensures design flaws before they develop. In addition, its intensive document and planning make it work well for projects in which quality control is a major concern.

The Waterfall is the oldest paradigm for software engineering. However, over the past two decades, criticism of this process model has caused even ardent supporters to question its efficacy. Among the problems that are sometimes encountered when the waterfall model is applied are:-

Real project rarely follow the sequential flow that the model proposes. Although the linear model can accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the project team proceeds.

TABLE

Comparison of Different Process Models

S NO.rfghtrh PROCESS MODELS

Waterfall Prototype Incremental Spiral

Requirement Specification Beginning Frequently Changed

Beginning Beginning

Understanding Requirements

Well Understood Not Well understood

Not Well understood

Well Understood

Cost Low High Low Intermediate

Guarantee of Success

Low Good High High

Resource Control Yes No Yes Yes

Cost Control Yes No No Yes

Simplicity Simple Simple Intermediate Intermediate

Risk Involvement High Medium Medium Low

Expertise Required High Medium High High

Changes Incorporated

Difficult Easy Easy Easy

Risk Analysis Only at beginning No Risk Analysis

No Risk Analysis

Yes

Overlapping Phases No Yes No Yes

(4)

THE PROTOTYPE MODEL A prototype is an early sample or model built to test a concept or process or to act as a thing to be replicated or learned from. Prototyping is a technique for providing a reduced functionality or a limited performance version of a software system early in its development (Balzer 1983, Budde 1984, Hekmatpour 1987). In contrast to the classic system life cycle, prototyping is an approach whereby more emphasis, activity, and processing are directed to the early stages of software development (requirements analysis and functional specification). In turn, p r ot ot yp i n g c a n m o r e di r e c t l y accommodate early.

Fig. 2 The Prototype Model

A prototype is made first and based on its final product is developed. A prototype is a model or a program which is not based on strict planning, but is an early approximation of the final product or software system. A prototype acts as a sample to test the process. From this sample we learn and try to build a better final product. Please note that this prototype may or may not be completely different from the final system we are trying to develop.

Some of its advantages are that It could serve as the first system, The customer doesn’t need to wait long as in the Linear Model, Feedback from customers are received periodically and the changes don’t come as a last minute surprise. But it also have some disadvantages Customer could

believe the prototype as the working version, Developer also could make the implementation compromises where he could make the quick fixes to the prototype and make is as a working version, Often clients expect that a few minor changes to the prototype will more than suffice their needs. They fail to realise that no consideration was given to the overall quality of the software in the rush to develop the prototype.

THE INCREMENTAL MODEL The incremental model combines elements of the linear sequential model (applied repetitively) with the iterative philosophy of prototyping. The incremental model applies linear sequences in a staggered fashion as calendar time progresses. Each linear sequence produces a deliverable “increment” of the software. For example, word-processing software developed using the incremental paradigm might deliver basic file management, editing, and document production functions in the first increment; more sophisticated editing and document production capabilities in the second increment; spelling and grammar checking in the third increment; and advanced page layout capability in the fourth increment. It should be noted that the process flow for any increment can incorporate the prototyping paradigm. When an incremental model is used, the first increment is often a core product. That is, basic requirements are addressed, but many supplementary features (some known, others unknown) remain undelivered. The core product is used by the customer (or undergoes detailed review). As a result of use and/or evaluation, a plan is developed for the next increment. The plan addresses the modification of the core product to better meet the needs of the customer and the delivery of additional features and functionality. This process is repeated following the delivery of each increment, until the complete product is produced.

(5)

Fig. 3 The Incremental Model

But as we can see some advantages of this model are some working functionality can be developed quickly and early in the life cycle, less costly to change the scope/ requirements. But it have some disadvantages too - More resources may be required, Does not allow iterations within an increment, Defining increments may require definition of the complete system.

THE SPIRAL MODEL

Fig. 4 The Spiral Model

The spiral model is similar to the incremental model, with more emphasis placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements is gathered

and risk is assessed. Each subsequent spiral builds on the baseline spiral.

Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase.

Some advantages are - High amount of risk analysis hence, avoidance of Risk is enhanced, Strong approval and documentation control, Additional Functionality can be added at a later date. It has some disadvantages too such as - Can be a costly model to use, doesn’t work well for smaller projects, Project’s success is highly dependent on the risk analysis phase.

CONCLUSION AND FUTURE WORK After completing this research, it is concluded that:

1. There are many number of software models present that can cater the needs of any software product. 2. All these models were established

between 1970 and 1999.

3. Since every model is a step forward of the previous model thus each model conquers the inability or disadvantages of the previous model.

4. Among the above model Prototype Model may prove to be an ideal model.

Finally, some topics can be suggested for future works:

1. Making a comparison between the software processes management m o d e l s , s o t h a t f u t u r e enhancements could be easily implied.

(6)

2. Requirement Understanding is the most important part of a software process, thus models should be more intended towards the client’s requirement gathering.

3. Since client’s needs changes constantly thus a process model should contain appropriate measures to incorporate those changes without disturbing or affecting the other phases of a software process.

ACKNOWLEDGEMENT This work is carried out with the support of Takshshila Institute of Engineering and technology.. REFERENCES: [1] http://www.ics.uci.edu/~wscacchi/ Papers/SE-Encyc/Process-Models-SE-Encyc.pdf [2] h t t p: / / e n. wi ki p ed i a .o r g/ wi ki / Software_development_process [3] http://www.cs.rit.edu/~hpb/Scia/ Bridge_2005/intro_se_workshop_ materials/s2_process_models.pdf [4] h t t p : / / w w w . c s . t o r o n t o . e d u / ~torsten/THahmann_CSC444_ Tutorial1_SWDevProcesses.pdf [5] http://www.ijcsi.org/papers/7-5-94 -101.pdf [6] http://people.sju.edu/~jhodgson/se/ models.html [7] h t t p : / / c i t e s e e r x . i s t . p s u . e d u / v i e w d o c / s u m m a r y ? doi=10.1.1.22.9145 [8] h t t p : / / w w w . w i z i q . c o m / t u t o r i a l / 1 2 1 0 8 3 S o f t w a r e -Engi neering -P rocess -Model s-Paradigms-I [9] http://www.smccd.net/accounts/ brenner/lsci106/reproces.html [10] ht t p: / / w ww. go o gl e. c o.i n/ url ? sa=t&rct=j&q=&esrc=s&source= web&cd=3&ved=0CEkQFjAC&ur l=http%3A%2F%2Fciteseerx.ist. psu.edu%2Fviewdoc%2Fdown load%3Fdoi%3D10.1.1.89.6886% 2 6 r e p % 3 D r e p 1 % 2 6 t y p e % 3 D p d f & e i = 3 -ALUamqGYvJrAeM2IDwDA&us g = A F Q j C N H H d i W A X -O2orKKMWawoRcE4YgsAg&bv m=bv.41867550,d.bmk&cad=rja [11] http://www.ijcst.com/wp-content/ t h e m e s / p a n o r a m a / p d f 2 / deepshikha.pdf [12] h t t p: / / e n. wi ki p ed i a .o r g/ wi ki / Waterfall_model [13] http://www.ics.uci.edu/~wscacchi/ Papers/SE-Encyc/Process-Models-SE-Encyc.pdf [14] http://www.google.co.in/search? q=incrementing+model+in+softwa re+engineering&hl=en&tbo=d&so urce=lnms&tbm=isch&sa=X&ei= 7GoeUbitE8f3rQfts4GYDw&ved =0CAcQ_AUoAQ&biw=1032&bi h=561 [15] http://www.google.co.in/search? q=spiral+model&hl=en&tbo=d&s ource=lnms&tbm=isch&sa=X&ei = 2 w e U Y D o J s -xrAf11YC4Cg&ved=0CAcQ_AU oAQ&biw=1032&bih=561#imgrc = 3 M p q g N 9 l 8 C u Y B M % 3 A % 3 B k L X S F I 3 Y C U z H N M % 3 B h t t p % 2 5 3 A % 2 5 2 F % 2 5 2 F u p l o a d . w i k i m e d i a . o r g% 252Fwikipedia%252Fcommons% 2 5 2 F 3 % 2 5 2 F 3 3 % 2 5 2 F S p i r a l _ m o d e l _ (B o e h m % 2 5 2 C _ 1 9 8 8 ) . p n g % 3 B h t t p % 2 5 3 A % 2 5 2 F % 2 5 2 F e n . w i k i p e d i a . o r g % = 2 5 2 F w i k i % 2 5 2 F F i l e % 2 5 3 A S p i r a l _ m o d e l _ ( B o e h m % 252C_1988).png%3B730%3B600 [16] http://www.softdevteam.com/Spiral-lifecycle.asp [17] http://www.sdlc.ws/spiral-model/ [18] http://samples.jbpub.com/978076378 5345/85345_CH04_Tsui.pdf [19] http://www.amazon.com/Software- Process-Modelling-Engineering-Knowledge/dp/9812566198