Software Development Life Cycle Models

Software Development Life Cycle Models The Systems Development Life Cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project from an initial feasibility study through maintenance of the completed application. Various SDLC methodologies have been developed to guide the processes involved including the waterfall model (the original SDLC method), rapid application development (RAD), joint application development (JAD), the fountain model and the spiral model. Mostly, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely particular plan was followed. This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall model. Waterfall Life Cycle Model Advantages à ¢Ã¢â€š ¬Ã‚ ¢ Simple and easy to use. à ¢Ã¢â€š ¬Ã‚ ¢ Easy to manage due to the rigidity of the model each phase has specific deliverables and a review process. à ¢Ã¢â€š ¬Ã‚ ¢ Phases are processed and completed one at a time. à ¢Ã¢â€š ¬Ã‚ ¢ Works well for smaller projects where requirements are very well understood. Disadvantages à ¢Ã¢â€š ¬Ã‚ ¢ Adjusting scope during the life cycle can kill a project à ¢Ã¢â€š ¬Ã‚ ¢ No working software is produced until late during the life cycle. à ¢Ã¢â€š ¬Ã‚ ¢ High amounts of risk and uncertainty. à ¢Ã¢â€š ¬Ã‚ ¢ Poor model for complex and object-oriented projects. à ¢Ã¢â€š ¬Ã‚ ¢ Poor model for long and ongoing projects. à ¢Ã¢â€š ¬Ã‚ ¢ Poor model where requirements are at a moderate to high risk of changing. V-Shaped Model Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. Testing is emphasized in this model more so than the waterfall model though. The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation. Requirements begin the life cycle model just like the waterfall model. Before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering. The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together. The low-level design phase is where the actual software components are designed, and unit tests are created in this phase as well. The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use. Advantages à ¢Ã¢â€š ¬Ã‚ ¢ Simple and easy to use. à ¢Ã¢â€š ¬Ã‚ ¢ Each phase has specific deliverables. à ¢Ã¢â€š ¬Ã‚ ¢ Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle. à ¢Ã¢â€š ¬Ã‚ ¢ Works well for small projects where requirements are easily understood. Disadvantages à ¢Ã¢â€š ¬Ã‚ ¢ Very rigid, like the waterfall model. à ¢Ã¢â€š ¬Ã‚ ¢ Little flexibility and adjusting scope is difficult and expensive. à ¢Ã¢â€š ¬Ã‚ ¢ Software is developed during the implementation phase, so no early prototypes of the software are produced. à ¢Ã¢â€š ¬Ã‚ ¢ Model doesnt provide a clear path for problems found during testing phases. Spiral Model The spiral model is similar to the incremental model, with more emphases 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 are gathered and risk is assessed. Each subsequent spirals 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. Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral. In the spiral model, the angular component represents progress, and the radius of the spiral represents cost. Advantages à ¢Ã¢â€š ¬Ã‚ ¢ High amount of risk analysis à ¢Ã¢â€š ¬Ã‚ ¢ Good for large and mission-critical projects. à ¢Ã¢â€š ¬Ã‚ ¢ Software is produced early in the software life cycle. Disadvantages à ¢Ã¢â€š ¬Ã‚ ¢ Can be a costly model to use. à ¢Ã¢â€š ¬Ã‚ ¢ Risk analysis requires highly specific expertise. à ¢Ã¢â€š ¬Ã‚ ¢ Projects success is highly dependent on the risk analysis phase. à ¢Ã¢â€š ¬Ã‚ ¢ Doesnt work well for smaller projects. 1. The Scope of Life Cycles As we described in the book The Enterprise Unified Process (EUP) the scope of life cycles can vary dramatically. For example, Figure 1 depicts the Scrum construction life cycle whereas Figure 2 depicts an extended version of that diagram which covers the full system development life cycle (SDLC) and Figure 3 extends that further by addressing enterprise-level disciplines via the EUP life cycle. The points that Im trying to make are: à ¢Ã¢â€š ¬Ã‚ ¢ System development is complicated. Although its comforting to think that development is as simple as Figure 1 makes it out to be, the fact is that we know that its not. If you adopt a development process that doesnt actually address the full development cycle then youve adopted little more than consultantware in the end. My experience is that you need to go beyond the construction life cycle of Figure 1 to the full SDLC of Figure 2 (ok, Retirement may not be all that critical) if youre to be successful à ¢Ã¢â€š ¬Ã‚ ¢ Theres more to IT than development. To be successful at IT you must take a multi-system, multi-life cycle stage view as depicted in Figure 3. The reality is that organizations have many potential projects in the planning stage (which Ill call Iteration -1 in this article), many in development, and many in production. 2. Iteration -1: Pre-Project Planning Iteration -1, the pre-Inception phase in the Enterprise Unified Process (EUP), is the pre-project aspects of portfolio management. During this phase you will: 1. Define the business opportunity. You must consider the bigger business picture and focus on market concerns. This includes exploring how the new functionality will improve your organizations presence in the market, how it will impact profitability, and how it will impact the people within your organization. This exploration effort should be brief, not all projects will make the initial cut so you only want to invest enough effort at this point to get a good gut feel for the business potential. A good strategy is to follow Outside-In Developments focus on identifying the potential stakeholders and their goals, key information to help identify the scope of the effort. 2. Identify a viable for the project. There are several issues to consider when identifying a potential strategy for the project. For example, do you build a new system or buy an existing package and modify it? If you decide to build, do you do so onshore or offshore? Will the work be solely done by your own development team, by a team from a system integrator (SI), or in partnership with the SI? What development paradigm traditional/waterfall, iterative, or agile will you follow? Will the team be co-located, near-located within the same geographic region, or far-located around the world? As you can see there are many combinations of strategy available to you, and at this point in time you may only be able to narrow the range of the possibilities but be forced to leave the final decision to the project team in future iterations. 3. Assess the feasibility. During Iteration -1 you will want to do just enough feasibility analysis to determine if it makes sense to invest in the potential project. Depending on the situation you may choose to invest very little effort in considering feasibility, for many systems just considering these issues for a few minutes is sufficient for now, and for some systems you may choose to invest days if not weeks exploring feasibility. Many organizations choose to do just a little bit of feasibility analysis during Iteration -1, and then if they decide to fund the project they will invest more effort during Iteration 0. In my experience you need to consider four issues when exploring feasibility: economic feasibility, technical feasibility, operational feasibility, and political feasibility. Your feasibility analysis efforts should also produce a list of potential risks and criteria against which to make go/no-go decisions at key milestone points during your project. Remember that a gile teams only have a success rate of 72%, compared to 63% for traditional projects, implying that almost 30% of agile projects are considered failures. Therefore you should question the feasibility of the project throughout the life cycle to reduce overall project risk. 3. Iteration 0/Warm Up: Project Initiation The first week or so of an agile project is often referred to as Iteration 0 (or Cycle 0) or in The Eclipse Way the Warm Up iteration. Your goal during this period is to initiate the project by: 1. Garnering initial support and funding for the project. This may have been already achieved via your portfolio management efforts, but realistically at some point somebody is going to ask what are we going to get, how much is it going to cost, and how long is it going to take. You need to be able to provide reasonable, although potentially evolving, answers to these questions if youre going to get permission to work on the project. You may need to justify your project via a feasibility study. 2. Actively working with stakeholders to initially model the scope of the system. As you see in Figure 5, during Iteration 0 agilists will do some initial requirements modeling with their stakeholders to identify the initial, albeit high-level, requirements for the system. To promote active stakeholder participation you should use inclusive tools, such as index cards and white boards to do this modeling our goal is to understand the problem and solution domain, not to create mounds of documentation. The details of these requirements are modeled on a just in time (JIT) basis in model storming sessions during the development cycles. 3. Starting to build the team. Although your team will evolve over time, at the beginning of a development project you will need to start identifying key team members and start bringing them onto the team. At this point you will want to have at least one or two senior developers, the project coach/manager, and one or more stakeholder representatives. 4. Modeling an initial architecture for the system. Early in the project you need to have at least a general idea of how youre going to build the system. Is it a mainframe COBOL application? A .Net application? J2EE? Something else? As you see in Figure 5, the developers on the project will get together in a room, often around a whiteboard, discuss and then sketch out a potential architecture for the system. This architecture will likely evolve over time, it will not be very detailed yet (it just needs to be good enough for now), and very little documentation (if any) needs to be written. The goal is to identify an architectural strategy, not write mounds of documentation. You will work through the design details later during development cycles in model storming sessions and via TDD. 5. Setting up the environment. You need workstations, development tools, a work area, for the team. You dont need access to all of these resources right away, although at the start of the project you will need most of them. 6. Estimating the project. Youll need to put together an initial estimate for your agile project based on the initial requirements, the initial architecture, and the skills of your team. This estimate will evolve throughout the project. 4. Release Iterations(s): The End Game During the release iteration(s), also known as the end game, we transition the system into production. Not that for complex systems the end game may prove to be several iterations, although if youve done system and user testing during construction iterations (as indicated by Figure 6) this likely wont be the case. As you can see in Figure 9, there are several important aspects to this effort: 1. Final testing of the system. Final system and acceptance testing should be performed at this point, although as I pointed out earlier the majority of testing should be done during construction iterations. You may choose to pilot/beta test your system with a subset of the eventual end users. See the Full Life Cycle Object-Oriented Testing (FLOOT) method for more thoughts on testing. 2. Rework. There is no value testing the system if you dont plan to act on you find. You may not address all defects, but you should expect to fix some of them. 3. Finalization of any system and user documentation. Some documentation may have been written during construction iterations, but it typically isnt finalized until the system release itself has been finalized to avoid unnecessary rework Note that documentation is treated like any other requirement: it should be costed, prioritized, and created only if stakeholders are willing to invest in it. Agilists believe that if stakeholders are smart enough to earn the money then they must also be smart enough to spend it appropriately. 4. Training. We train end users, operations staff, and support staff to work effectively with our system. 5. Deploy the system. See my article entitled System Deployment Tips and Techniques. 6. Briefly on different Phases: 7. Feasibility 8. The feasibility study is used to determine if the project should get the go-ahead. If the project is to proceed, the feasibility study will produce a project plan and budget estimates for the future stages of development. 9. Requirement Analysis and Design 10. Analysis gathers the requirements for the system. This stage includes a detailed study of the business needs of the organization. Options for changing the business process may be considered. Design focuses on high level design like, what programs are needed and how are they going to interact, low-level design (how the individual programs are going to work), interface design (what are the interfaces going to look like) and data design (what data will be required). During these phases, the softwares overall structure is defined. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase. 11. Implementation 12. In this phase the designs are translated into code. Computer programs are written using a conventional programming language or an application generator. Programming tools like Compilers, Interpreters, Debuggers are used to generate the code. Different high level programming languages like C, C++, Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen. 13. Testing 14. In this phase the system is tested. Normally programs are written as a series of individual modules, these subject to separate and detailed test. The system is then tested as a whole. The separate modules are brought together and tested as a complete system. The system is tested to ensure that interfaces between modules work (integration testing), the system works on the intended platform and with the expected volume of data (volume testing) and that the system does what the user requires (acceptance/beta testing). 15. Maintenance 16. Inevitably the system will need maintenance. Software will definitely undergo change once it is delivered to the customer. There are many reasons for the change. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to accommodate changes that could happen during the post implementation period. Why an SDLC? When you pay your telephone bill your payment is processed by a system. That system has evolved over many years and continues to evolve in order to meet the changing needs of the business. When the phone company cashes your check that check is also processed by a system which itself is evolving. These two systems are composed of manual activities and automated components. They also exist in the context of many other systems with which they must interface. Each system works so well individually because it is composed of a rigorous set of tasks which result in well-defined outputs. Regardless of who is doing the task, the result is essentially the same. As staff turnover occurs the system provides continuity to the way of doing business. Each system can interface with the other because the division of activities between the bank and the phone company are well defined, as are the interfaces. Thus, no matter which bank the check is drawn on, the process is the same; no matter which phone company sends in the check, the process is the same. The precision and completeness of the task lists, the data, the division of responsibilities and the interface definitions are required because of the complexity of these systems. But what about the process that creates and maintains these systems? Software systems development is, from a historical perspective, a very young profession. The first official programmer is probably Grace Hopper, working for the Navy in the mid-1940s. More realistically, commercial applications development did not really take off until the early 1960s. These initial efforts are marked by a craftsman-like approach based on what intuitively felt right. Unfortunately, too many programmers had poor intuition. By the late 1960s it had become apparent that a more disciplined approach was required. The software engineering techniques started coming into being. This finally brings us to the SDLC. What evolved from these early activities in improving rigor is an understanding of the scope and complexity of the total development process. It became clear that the process of creating systems required a system to do systems. This is the SDLC. It is the system used to build and maintain software systems. As with the phone billing system, an SDLC system is needed because the development process is composed of many complex tasks which must be done in the right order to produce a successful result. If there is no SDLC each team must reinvent it based on their own experiences and judgments. The complexity of the tasks has led to increased specialization. These specialists (e.g.,data base analysts, network designers, testers) must have well-bounded tasks with well-defined outputs and well-defined interfaces to the rest of the development team. This is provided by the SDLC. Systems also have a long life. The billing system and check processing system will probably never be de-automated. These systems will outlive their development teams. As staff turnover occurs, continuity is required in how the systems are supported. This is provided by the SDLC. Another issue is systems integration. Can you imagine if the architects designing a sky-scraper each had their own ways of creating and documenting the buildings plans? The plumbing, wiring, heating systems, floors, walls, etc., would never come together. Most computer systems interface with other computer systems. The degree of system integration is rapidly increasing. The descriptions of functions and data at the interfaces must be produced and documented in a consistent manner, in much the same way as architects must have a standard way of documenting plans. This is provided by the SDLC. You would not dream of trying to process phone bills or checks without a system due to the complexity of the process, the need for specialization, the need for continuity and the need to interface to the rest of the world. We have seen here that the process of developing systems has the same characteristics. Therefore, we need a system to build computer systems the SDLC. SYSTEM ANALYSIS AND DESIGN 1.1 INTRODUCTION Systems are created to solve problems. One can think of the systems approach as an organized way of dealing with a problem. In this dynamic world, the subject System Analysis and Design (SAD), mainly deals with the software development activities. 1.2 OBJECTIVES After going through this lesson, you should be able to define a system explain the different phases of system development life cycle enumerate the components of system analysis explain the components of system designing 1.3 DEFINING A SYSTEM A collection of components that work together to realize some objectives forms a system. Basically there are three major components in every system, namely input, processing and output.   1.4 SYSTEM LIFE CYCLE System life cycle is an organizational process of developing and main- taining systems. It helps in establishing a system project plan, be- cause it gives overall list of processes and sub-processes required for developing a system. System development life cycle means combination of various activi- ties. In other words we can say that various activities put together are referred as system development life cycle. In the System Analy- sis and Design terminology, the system development life cycle also means software development life cycle. Following are the different phases of system development life cycle: Preliminary study Feasibility study Detailed system study System analysis System design Coding Testing Implementation Maintenance 1.5 PHASES OF SYSTEM DEVELOPMENT LIFE CYCLE The different phases and related activities of system development life cycle. (a) Preliminary System Study Preliminary system study is the first stage of system development life cycle. This is a brief investigation of the system under consideration and gives a clear picture of what actually the physical system is? In practice, the initial system study involves the preparation of a System Proposal which lists the Problem Definition, Objectives of the Study, Terms of reference for Study, Constraints, Expected benefits of the new system, etc. in the light of the user requirements. The system proposal is prepared by the System Analyst (who studies the system) and places it before the user management. The management may accept the proposal and the cycle proceeds to the next stage. The management may also reject the proposal or request some modifications in the proposal. In summary, we would say that system study phase passes through the following steps: problem identification and project initiation background analysis inference or findings (system proposal) (b) Feasibility Study In case the system proposal is acceptable to the management. 2 :: Computer Applications In a system the different components are connected with each other and they are interdependent. For example, human body represents a complete natural system. We are also bound by many national systems such as political system, economic system, educational sys- tem and so forth. The objective of the system demands that some output is produced as a result of processing the suitable inputs. A well-designed system also includes an additional element referred to as control that provides a feedback to achieve desired objectives of the system. 3 :: Computer Applications Next phase is to examine the feasibility of the system. The feasibility study is basically the test of the proposed system in the light of its workability, meeting users requirements, effective use of resources and of course, the cost effectiveness. These are categorized as technical, operational, economic and schedule feasibility. The main goal of feasibility study is not to solve the problem but to achieve the scope. In the process of feasibility study, the cost and benefits are estimated with greater accuracy to find the Return on Investment (ROI). This also defines the resources needed to complete the de- tailed investigation. The result is a feasibility report submitted to the management. This may be accepted or accepted with modifications or rejected. The system cycle proceeds only if the management accepts it. (c) Detailed System Study The detailed investigation of the system is carried out in accordance with the objectives of the proposed system. This involves detailed study of various operations performed by a system and their relationships within and outside the system. During this process, data are collected on the available files, decision points and transactions handled by the present system. Interviews, on-site observation and questionnaire are the tools used for detailed system study. Using the following steps it becomes easy to draw the exact boundary of the new system under consideration: Keeping in view the problems and new requirements Workout the pros and cons including new areas of the system All the data and the findings must be documented in the form of detailed data flow diagrams (DFDs), data dictionary, logical data structures and miniature specification. The main points to be discussed in this stage are: Specification of what the new system is to accomplish based on the user requirements. Functional hierarchy showing the functions to be performed by the new system and their relationship with each other. Functional network, which are similar to function hierarchy but they highlight the functions which are common to more than one procedure. List of attributes of the entities these are the data items which need to be held about each entity (record) (d) System Analysis Systems analysis is a process of collecting factual data, understand the processes involved, identifying problems and recommending feasible suggestions for improving the system functioning. This involves studying the business processes, gathering operational data, understand the information flow, finding out bottlenecks and evolving solutions for overcoming the weaknesses of the system so as to achieve the organizational goals. System Analysis also includes subdividing of complex process involving the entire system, identification of data store and manual processes. The major objectives of systems analysis are to find answers for each business process: What is being done, How is it being done, Who is doing it, When is he doing it, Why is it being done and How can it be improved? It is more of a thinking process and involves the creative skills of the System Analyst. It attempts to give birth to a new efficient system that satisfies the current needs of the user and has scope for future growth within the organizational constraints. The result of this process is a logical system design. Systems analysis is an iterative process that continues until a preferred and acceptable solution emerges. (e) System Design Based on the user requirements and the detailed analysis of the existing system, the new system must be designed. This is the phase of system designing. It is the most crucial phase in the developments of a system. The logical system design arrived at as a result of systems analysis is converted into physical system design. Normally, the design proceeds in two stages: Preliminary or General Design Structured or Detailed Design Preliminary or General Design: In the preliminary or general design, the features of the new system are specified. The costs of implementing these features and the benefits to be derived are estimated. If the project is still considered to be feasible, we move to the detailed design stage. Structured or Detailed Design: In the detailed design stage, computer oriented work begins in earnest. At this stage, the design of the system becomes more structured. Structure design is a blueprint of a computer system solution to a given problem. 4 :: Computer Applications Same components and inter-relationships among the same components as the original problem. Input, output, databases, forms, codification schemes and processing specifications are drawn up in detail. In the design stage, the programming language and the hardware and software platform in which the new system will run are also decided. There are several tools and techniques used for describing the system design of the system. These tools and techniques are: i. Flowchart ii. Data flow diagram (DFD) Data dictionary Structured English Decision table Decision tree Each of the above tools for designing will be discussed in detailed in the next lesson. The system design involves: i. Defining precisely the required system output ii. Determining the data requirement for producing the output iii. Determining the medium and format of files and databases iv. Devising processing methods and use of software to produce output v. Determine the methods of data capture and data input vi. Designing Input forms vii. Designing Codification Schemes viii. Detailed manual procedures ix. Documenting the Design (f) Coding The system design needs to be implemented to make it a workable system. This demands the coding of design into computer understandable language, i.e., programming language. This is also called the programming phase in which the programmer converts the program specifications into computer instructions, which we refer to as: programs. It is an important stage where the defined procedures are transformed into control specifications by the help of a computer language. The programs coordinate the data movements and control the entire process in a system.