TRADITIONAL VS MODERN SOFTWARE ENGINEERING MODELS: A REVIEW

Year 2014, Vol. 1, issue 1, pp. 49-56 Available online at: http://journal.iecuniversity.com TRADITIONAL VS MODERN SOFTWARE ENGINEERING MODELS: A REVIEW Singh RANDEEP a*, Rathee AMIT b a* Department of Computer Science & Engineering, IEC, University Baddi(H.P), India b Department of Computer Science & Engineering, Panipat Institute of Engineering & Technology Panipat, India Review Article (Received: June 06, 2014) (Paper accepted: June 30, 2014) Abstract: Software development life cycle is the most important element in software development process & it depicts the sequence of steps necessary to develop sustainable and bug free software. All software systems were developed using some technology which spans over a period of time and it accounts for their inception period, development period, productive operation used, upkeep period and retirement time from one generation to another. This article categorizes, classifies and examines various methods that are used as SDLC over a period of time for designing any software systems. This article begins with background and definitions of SDLC then in next section we have discussed the technology aspect of various models and named them as generations. Lastly we have classified them as traditional or modern software life cycle model and shown the comparison of some of most important models. Key words: Software Engineering, SDLC, Life Cycle, Software, Agile Framework, Component-Based Model. 1. Introduction A (software/system) process model is a description of the sequence of activities carried out in a Software Engineering project, and the relative order of these activities [1-3]. It is also called Software Development Life Cycle (SDLC) as it covers the entire lifetime of a product from birth of software to its final de-installation of last release. Typically, it includes various phases from initial development analysis i.e. design, build & * Corresponding author; e-mail: randeeppoonia@gmail.com

50 Year 2014, Vol. 1, issue 1, pp. 49-56 maintain to post-development software testing and evaluation. Any SDLC also tells the models and methodologies that development teams use to develop the software systems and they both finally become the framework for planning and controlling the entire development process. A software model can be easily applied to any project and it has the following added advantages: It provides guideline which helps the organization to plan, arrange necessary staff, a lot budget, schedule and manage software project work over development time, space, and computing environments present inside organization. Prescriptive outline for what documents to produce for delivery to client. Basis for determining what software engineering tools and methodologies will be most appropriate to support different life cycle activities. Framework for analyze or estimate patterns of resource allocation and consumption during the software life cycle Basis for conducting empirical studies to determine what unfavorable affects software development, its cost, and overall quality in advance so that some remedial action can be planned in advance. A software application or an information system is designed to perform a particular set of tasks. Often, this set of tasks that the system will perform provides well-defined results, which involve complex computation and processing. It is very harsh and tedious job to govern the entire development process so as to ensure that the end-product comprises of high degree of integrity and robustness, as well as user approval. Thus, a systematic development process which is able to emphasize on the understanding of the scope and complexity of the total development process is essential to achieve the said characteristics of a successful system. Currently, there are two SDLC methodologies which are utilized by most system developers, namely the traditional development and modern development which is explained in next session. In later sections we compare and contrast these two methodologies in detail and suggested some improvements. Finally, the conclusion is presented. 2. Generations of software Over time a varieties of software process models have been devised and all of them may be classified in following categories depending upon the working principle and the time span in which they were used, as shown in Figure-1 :- 1. Adhoc based : - these were the early models and the working principle of these models is to design the software as a single entity and one or more programmers and later on find bugs and fix them. One such example of these models is Code & Fix Model developed in 1950. This software development process has various limitations

Year 2014, Vol. 1, issue 1, pp. 49-56 51 such as the activities like design prior to coding, to define requirement prior to design and the need for early preparation of testing & modification cannot be implemented. 2. Plan-Driven : - these were the second generations of software development processes and the idea of these model is to define scope, schedule and cost of the project in advance to avoid hazards which results in software failure. This technique emphasis on developing software into various sequential phases and each phase is generally visited only once throughout the life cycle of software development. One popular example of such models is Waterfall developed in 1970. The main idea of waterfall model is to develop the software in various stages in full that consist of requirement analysis, design, development and testing. The main limitation of this model is that it does not allow a programmer to go back and fix any limitation. 3. Iterative Change-Driven : - it is considered as third generation in the field of software development system. Iterative development refers to the overall lifecycle model in which the software is built in several iterations in sequence & each iteration can be considered as a mini-project in which the activities of requirements analysis, design, implementation and testing are conducted in order to produce a part of the final system, often resulting in internal iteration release. It is also referred to as Iterative & Incremental Development (IID) technique. Some examples of this technique are Spiral Model [4-5] developed in 1980 and Agile proposed in 1990. The spiral model typically consists of four iteratively repeatable steps: 1) determining the objectives, alternatives, and constraints, 2) evaluating alternatives, and identifying and resolving risks, 3) development and verification, and 4) planning the next phase. 4. Component-Based : - this is the modern software generation technique and component based development provides the idea: to build Software system form preexisting components. For Example building furniture from existing components, for building components that can be reused in different applications. In CBSE (Component-Based Software Engineering) maintenance is done by replacing of component and introducing new components into system. The development cycle of a component-based system is different from the traditional ones, i.e. the waterfall, spiral and prototype based models. The different steps in the Component Development Process are: 1. Find components which may be used in the system 2. Select the components which meet the requirements of the system. 3. Alternatively, create a proprietary component to be used in the system. 4. Compose and deploy the components using a framework for components. 5. Replace earlier with later versions of components. 2.1 Classification of Software

52 Year 2014, Vol. 1, issue 1, pp. 49-56 Broadly all the software models can be classified into following two categories based on the technology used: 1. Traditional Software Engineering 2. Modern Software Engineering as shown in figure-1. Modern Software Component- Based Iterative Change- Driven Plan-Driven Adhoc-Based Traditional Software Figure 1: Software Engineering Classification 2.1.1. Traditional Software Life Cycle Traditional models of software development have been with us since the inception time of software engineering. These methodologies are generally called as the heavyweight methodologies as they are based on a sequential series of steps like requirements definition, solution building, testing and deployment and they do not allow backtracking. All traditional SDLC methodologies require defining and documenting a stable set of all the requirements at the beginning of a project. There are four phases which are the characteristic of traditional software development method. The first phase is to set up the requirements for the project and determine the length of time it will take to implement the various phases of development while trying to predict any problems that may arise in the project. Once the requirements are laid out, the next phase is to design and architectural planning phase where a technical infrastructure is produced in the form of diagrams or models. These bring to the surface potential issues that the project may face as it progresses and provide a workable road map for the developers to implement.

Year 2014, Vol. 1, issue 1, pp. 49-56 53 Once the team is satisfied with the architectural and design plan, the project moves into the development phase where code is produced until the specific goals are reached. Development is often broken down into smaller tasks that are distributed among various teams based on skill. The testing phase often overlaps with the development phase to ensure issues are addressed early on. Once the project nears completion and the developers are close to meeting the project requirements, the customer will become part of the testing and feedback cycle and the project was delivered after the customer satisfy with it. The traditional software development methods are dependent on a set of predetermined processes and on-going documentation which is written as the work progresses and guides further development [5]. The success of a project which is approached in this way relies on knowing all of the requirements before development begin and means that implementing change during the development lifecycle can be somewhat problematic. However, it also makes it easier to determine the costs of the project, set a schedule and allocate resources accordingly The examples of traditional software engineering models include Waterfall Model, V-Model, RUP etc. Traditional Software Life Cycle technique has following limitations: limited to follow development steps in sequence only. document driven i.e. documents are more important than program. limited user/customer involvement. hard to think all of the requirements in the beginning 2.1.2. Modern Software Life Cycle Generally the main reason of software failure are hidden inside the incorrect or incomplete requirements gathered in early stage of software development, which are once gathered are not updated during SDLC. This rigid conception was modified through the evolution of product requirements during the process of software development. The modern SDLC models makes use of iterative and incremental approach according to which the whole software is build in several iteration in sequence. each iteration can be considered as a mini-project in which the activities of requirements analysis, design, implementation and testing are conducted in order to produce a subset of the final system, often resulting in internal iteration release. The examples of modern software engineering models include Spiral Model, Agile Software Development methodology which make use of various technique such as Extreme Programming (XP), Scrum, extreme testing, Crystal Family of Methodologies, Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), and Feature-Driven Development (FDD).

54 Year 2014, Vol. 1, issue 1, pp. 49-56 SOFTWAR E MODEL Table-1 Modern Software Life Cycle Comparison DESCRIPTION ADVANTAGES DISADVANTAGES Spiral Model Extreme Programmin g Component Based Development Model (CBSD) This model emphasize more on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. Requirements are gathered during the first phase called planning phase. In second phase, risk analysis phase, the system is analyzed to identify risk involved and alternate solutions. A prototype is produced at the end of the risk analysis phase. Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase permits the customer to evaluate the output of the project to date before the project continues to the next spiral. It is an approach of development and delivery of final product to user in very small increments of functionality. This technique relies on constant code improvement by analyzing user feedbacks, user involvement in the development team and pair wise programming. In this technique requirements for the release is gathered and coded before every release. It is as an approach which is based on reusing existing software components. There are basically six steps in this technique and they are: 1: The user requirements are extracted in outline from the more detailed requirement specification. This process as specific requirements limit the number of components that might be used. 2: Now the above step s complete outlined set of requirements is used to identify as many components as possible for reuse. 3: Now requirements are further refined and modified so that they can maximally match with components identified in above step. 4: Now the system architecture is designed. 5: After system architecture is designed, steps 2 and 3 may be repeated. 6: Finally the components are integrated which turns into a complete system. In this model we have high amount of risk analysis to make final product more successful. It is good for large and mission-critical projects where rollback will cost high. In this software is produced in parts early in the software life cycle. It is lightweight methods & suits well small-medium size projects. It provides good team cohesion. It emphasizes more on final product. It is iterative in nature. It provides test based approach to requirements, thus provides quality assurance. CBSE life cycle is shorter as compare to waterfall model. It develops architecture. It is less expensive & time consuming because in this high quality & certified components are reused to form final system, which also reduces risk of failure. In this maintenance is easy to perform because it involves only replacement of components by introducing new component in the system. Time-to-market is less. This model can be a costly to use for small enterprises. Risk analysis must be performed only by highly specific expertise. Also the Project success is highly dependent on the risk analysis phase. This model doesn t work well for smaller projects. Working and maintainance of this technique to large projects is difficult as documentation is essential and it becomes too large to be maintained. High experience and skill is required if we want to avoid code-and-fix. Programming pairs is costly. In this technique test case construction plays important role & it requires specialized skill. The task such as acquiring, analyzing and modeling the application domain is a difficult task. In this technique identifying & classification scheme for the existing software part is difficult. Maintaining or building reusable software components is also a challenging task. Configuring or development of the components is highly dependent & related on particular application. Searching a components library is also challenging due to large size of component database.

Year 2014, Vol. 1, issue 1, pp. 49-56 55 Table-2 Traditional Software Life Cycle Comparison SOFTWA RE MODEL WaterFall Model RUP Model DESCRIPTION ADVANTAGES DISADVANTAGES It is a sequential design process which mainly consist of following four steps in sequence: Analysis Design Implementation Testing & Maintenance The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation. The whole software development lifecycle is broken into cycles and each cycle is always working on a new generation of the product. The RUP divides one development cycle in four consecutive phases: Inception phase Elaboration phase Construction phase Transition phase This model is easy to understand and use. It is widely used and known from a long time to everyone. It reinforces good habits in programmer in the form of - define-before- design & design-before-code. It is document driven and we must prepare documents such as URD, SRD, etc. This model is easy to be used on mature products and weak developer teams. This model is a complete methodology in itself with emphasize on accurate documentation of project. This model resolves the project risks associated with the client's evolving requirements which requires careful change request management. Takes Less time for integration because the process of integration goes throughout the software development life cycle of project. Less development time required because of the reuse of components. This model is completely backed up by online training and tutorial available for the developers. This model is sometimes behaves as Idealized and it doesn t match the reality well in such scenario. It doesn t use iterative nature of exploratory development which is mandatory to obtain good quality of final product. This model is unable to obtain accurate requirements so early in project development phases. In this model the software can be delivered late if we found some errors in late phases of software development. Risk management integration is very difficult in this model. It includes significant administrative overhead, costly for small teams and projects This model requires that the team members should be expert in their field so as to develop software using this methodology. The whole development process is too much complex and disorganized, so cannot be used by everyone frequently. Sometimes the reuse of components is not possible because it may be the case that we are working on some new technology for which no prior component exists. So the time saving that we can made will be impossible to achieve. While working on big projects maintaining integration in whole software development process is somewhat becomes impossible if we are working on multiple development streams & it only add confusion and creates problems in testing stages.

56 Year 2014, Vol. 1, issue 1, pp. 49-56 V-Shaped Model This model is an extension of 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 procedures for testing are developed early in the life cycle before any coding is done. Simple and easy to use. Each phase has specific deliverables. This model has higher success chances over the waterfall model due to the early development of test plans during the life cycle. This model works well in case of small projects where requirements are easily understood. Very rigid like the waterfall model. This model provides very small flexibility to programmer and any later changes are difficult and expensive. In this model no prototypes are prepared early as we directly go to software developement during the implementation phase. This Model does not provide a clear path for problems found during testing phases. Conclusion In this paper we have studied the importance of SDLC in software development with various software development life cycle models. We have also studied their classification with example. Further a comparative study of various important models is shown in Table-1 and Table-2 with their advantage and disadvantage. From our study we find out that modern models outperform traditional models specially with large size projects because of their less time needed in software development and less involved risk which results in less development cost. References 1. Ian Sommerville, "Software Engineering", Addison Wesley, 7th edition, 2004. 2. Steve E., "Software Lifecycles", University of Toronto Department of Computer Science, 2001. 3. Rlewallen, "Software Development Life Cycle ", 2005, http://codebeter.com. 4. Boehm, B.W., A Spiral Model of Software Development and Enhancement, Journal Computer, 21(1988), 5, pp. 61-72. 5. Schmidt D. C., Model-Driven Engineering, IEEE Computer, 39(2006), 2, pp. 2006.