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 doesn’t 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.

• Project’s success is highly dependent on the risk analysis phase.

• Doesn’t 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 I’m trying to make are:

• System development is complicated. Although it’s comforting to think that development is as simple as Figure 1 makes it out to be, the fact is that we know that it’s not. If you adopt a development process that doesn’t actually address the full development cycle then you’ve 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 you’re to be successful

• There’s 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 I’ll 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 organization’s 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 Development’s 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 agile 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 you’re 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 you’re 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 don’t 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. You’ll 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 you’ve done system and user testing during construction iterations (as indicated by Figure 6) this likely won’t 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 don’t 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 isn’t 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 software’s 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 building’s 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 user’s 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.

It is generally felt that the programs must be modular in nature.

This helps in fast development, maintenance and future changes, if required.

(g) Testing

Before actually implementing the new system into operation, a test run of the system is done for removing the bugs, if any. It is an important phase of a successful system. After codifying the whole programs of the system, a test plan should be developed and run on a given set of test data. The output of the test run should match the expected results. Sometimes, system testing is considered a part of implementation process.

Using the test data following test run are carried out:

Program test

System test

Program test: When the programs have been coded, compiled and brought to working conditions, they must be individually tested with the prepared test data. Any undesirable happening must be noted and debugged (error corrections)

System Test: After carrying out the program test for each of the programs of the system and errors removed, then system test is done. At this stage the test is done on actual data. The complete system is executed on the actual data. At each stage of the execution, the results or output of the system is analysed. During the result analysis, it may be found that the outputs are not matching

the expected output of the system. In such case, the errors in the particular programs are identified and are fixed and further tested for the expected output.

When it is ensured that the system is running error-free, the users are called with their own actual data so that the system could be shown running as per their requirements.

(h) Implementation

After having the user acceptance of the new system developed, the

5 :: Computer Applications

implementation phase begins. Implementation is the stage of a project during which theory is turned into practice. The major steps involved in this phase are:

Acquisition and Installation of Hardware and Software

Conversion

User Training

Documentation

The hardware and the relevant software required for running the

system must be made fully operational before implementation. The

conversion is also one of the most critical and expensive activities in

the system development life cycle. The data from the old system

needs to be converted to operate in the new format of the new system.

The database needs to be setup with security and recovery procedures

fully defined.

During this phase, all the programs of the system are loaded onto the user’s computer. After loading the system, training of the user starts. Main topics of such type of training are:

How to execute the package

How to enter the data

How to process the data (processing details)

How to take out the reports

After the users are trained about the computerized system, working has to shift from manual to computerized working. The process is called ‘Changeover’. The following strategies are followed for changeover of the system.

(i) Direct Changeover: This is the complete replacement of the old system by the new system. It is a risky approach and requires comprehensive system testing and training.

(ii) Parallel run: In parallel run both the systems, i.e., computerized and manual, are executed simultaneously for certain defined period. The same data is processed by both the systems. This strategy is less risky but more expensive because of the following:

Manual results can be compared with the results of the computerized system.

The operational work is doubled.

Failure of the computerized system at the early stage does not affect the working of the organization, because the manual system continues to work, as it used to do.

(iii) Pilot run: In this type of run, the new system is run with the data from one or more of the previous periods for the whole or part of the system. The results are compared with the old system results. It is less expensive and risky than parallel run approach. This strategy builds the confidence and the errors

are traced easily without affecting the operations.

The documentation of the system is also one of the most important activity in the system development life cycle. This ensures the continuity of the system. There are generally two types of documentation prepared for any system. These are:

User or Operator Documentation

System Documentation

The user documentation is a complete description of the system from the users point of view detailing how to use or operate the system. It also includes the major error messages likely to be encountered by the users. The system documentation contains the details of system design, programs, their coding, system flow, data dictionary, process description, etc. This helps to understand the system and permit changes to be made in the existing system to satisfy new user needs.

(i) Maintenance

Maintenance is necessary to eliminate errors in the system during

its working life and to tune the system to any variations in its work-

ing environments. It has been seen that there are always some er-

rors found in the systems that must be noted and corrected. It also

means the review of the system from time to time. The review of the

Knowing the full capabilities of the system

Knowing the required changes or the additional requirements studying the performance.

If a major change to a system is needed, a new project may have to

be set up to carry out the change. The new project will then proceed

through all the above life cycle phases.