Author Topic: A Survey of project scenario impact in SDLC models selection process  (Read 2045 times)

0 Members and 1 Guest are viewing this topic.

IJSER Content Writer

  • Sr. Member
  • ****
  • Posts: 327
  • Karma: +0/-1
    • View Profile
Quote
Author : Manish Sharma
International Journal of Scientific & Engineering Research Volume 2, Issue 6, June-2011
ISSN 2229-5518
Download Full Paper : PDF

Abstract— In the software industry, a large number of projects fail and billions of dollars are spent on failed software projects. Lacks of poor selection process of software development life cycle (SDLC) models is some of the top reason of such failure. By selecting right software process model a better and high quality product can be found within budget and time. In this paper, an approach is proposed to select an appropriate SDLC model based on different project characteristic categories. In this paper, a comparison approach of SDLC process is introduced, which is based on project characteristic categories and then categories are classified. Paper described about comparison tables of SDLC models, and better selection process of SDLC models.

Index Terms- Process model, Project team, Project type, Project risk, RAD model, SDLC, Spiral Model, Water fall model.

1.  INTRODUCTION
Software Process Model is an abstract representation of a software process[1]. Each process model represents a process from particular perspective, and thus provides only partial information about that process [1]. Software process selection is an approach or method or both by which software process model efficiently selected depends upon the given requirements and give better result rather than a normal selection process. The requirements consist of questions related to the thing that have been requested by the user for the project.  They are sometimes termed as functions or features of the system that will be provided by the project. 
The organization of paper is alienated as section II describe about the definition of SDLC models, which are explained from the requirements point of view only, in section III a comparison based evaluation of SDLC models using 3D- bar graphs, section IV defines a comparison table and finally section V depicts the future work. 

2. SOFTWARE PROCESS MODELS
Software process models are defined only in terms of requirements analysis phase of each model. 
 
2.1 WATER FALL MODEL
The requirements gathering process is intensified and focused specifically on software. To understand the nature of the program(s) to be built, the software engineer ("analyst") must understand the information domain for the software, as well as required function, behaviour, performance, and interface. Requirements for both the system and the software are documented and reviewed with the customer [2].

The major weakness of the Waterfall Model as in figure 1.  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.[8] The Waterfall Model is a poor choice for software development projects where requirements are not well-known or understood by the development team. It might not a good model for complex project or projects that take more than a few months to complete [8].

2.2 SPIRAL MODEL
 
In response to the weaknesses and failures of the Waterfall SDLC Model, many new models were developed that add some form of iteration to the software development process. In the Spiral SDLC Model as in figure 2 , the development team starts with a small set of requirements and goes through each development phase (except Installation and Maintenance) for those set of requirements [8]. Based on lesson learned from the initial iteration, the development team adds functionality for  additional requirements in ever-increasing “spirals” until the application is ready for the Installation and Maintenance phase [2][3].

2.3 RAD MODEL
 
If requirements are well understood and project scope is constrained, the Rapid application development (RAD) figure 3 process enables a development team to create a “fully functional system” within very short time periods (e.g., 60 to 90 days) [2].

2.4 INCREMENTAL MODEL
 
The incremental model figure 4 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 when an incremental model is used; the first increment is often a core product [2].

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 [3].

Read More: Click here...