Welcome to TechRiz 

Where tech enthusiasts come for the latest tech news, Free downloads, free tutorials, articles and how to's.

Description:  This is the TechRiz Free Tutorials page. Visit every day to stay informed about the latest tech news, from security alerts to Hardware and software updates. Enjoy your stay.

Week 2

Software (System Development) life Cycle Models

At the end of this lesson you would be able to know the various stages involved in a system life cycle and you would be able to understand the various methodologies available for system development.

Introduction to Life Cycle Models
Activities involved in any Life cycle Model
Preliminary Investigation
Determination of System's requirements - Analysis Phase
Design of System
Development of Software
System Testing
Implementation and Maintenance
Error Distribution with Phases

Different Life Cycles Models
Traditional/Waterfall Software Development Model
Advantages and limitations of the Waterfall Model
Prototyping Life Cycle
Iterative Enhancement Life Cycle Model
Spiral Life Cycle Model
Object Oriented Methodology
Dynamic System Development Method

Introduction to System Development/Software life cycle models 

The trends of increasing technical complexity of the systems, coupled with the need for repeatable and predictable process methodologies, have driven System Developers to establish system development models or software development life cycle models.  

Nearly three decades ago the operations in an organization used to be limited and so it was possible to maintain them using manual procedures. But with the growing operations of organizations, the need to automate the various activities increased, since for manual procedures it was becoming very difficult, slow and complicated. Like maintaining records for a thousand plus employees company on papers is definitely a cumbersome job. So, at that time more and more companies started going for automation.

Since there were a lot of organizations, which were opting for automation, it was felt that some standard and structural procedure or methodology be introduced in the industry so that the transition from manual to automated system became easy. The concept of system life cycle came into existence then. Life cycle model emphasized on the need to follow some structured approach towards building new or improved system. There were many models suggested. A waterfall model was among the very first models that came into existence. Later on many other models like prototype, rapid application development model, etc were also introduced.

System development begins with the recognition of user needs. Then there is a preliminary investigation stage. It includes evaluation of present system, information gathering, feasibility study, and request approval. Feasibility study includes technical, economic, legal and operational feasibility. In economic feasibility cost-benefit analysis is done. After that, there are detailed design, implementation, testing and maintenance stages.

In this session, we'll be learning about various stages that make system's life cycle. In addition, different life cycles models will be discussed. These include Waterfall model, Prototype model, Object-Oriented Model, spiral model and Dynamic Systems Development Method (DSDM).

Activities involved Software Development life cycle model 

Problem solving in software consists of these activities:  

1.                Understanding the problem

2.                Deciding a plan for a solution

3.                Coding the planned solution

4.                Testing the actual program

For small problems these activities may not be done explicitly. The start end boundaries of these activities may not be clearly defined, and not written record of the activities may be kept. However, for large systems where the problem solving activity may last over a few years. And where many people are involved in development, performing these activities implicitly without proper documentation and representation will clearly not work. For any software system of a non-trival nature, each of the four activities for problem solving listed above has to be done formally. For large systems, each activity can be extremely complex and methodologies and precedures are needed to perform it efficiently and correctly. Each of these activities is a major task for large software projects.

Furthermore, each of the basic activities itself may be so large that it cannot be handled in single step and must be broken into smaller steps. For example, design of a large software system is always broken into multiple, distinct design phases, starting from a very high level design specifying only the components in the system to a detailed design where the logic of the components is specified. The basic activities or phases to be performed for developing a software system are:

1.                Requirement Analysis / Determination of System's Requirements

2.                Design of system

3.                Development (coding) of software

4.                System Testing

In addition to the activities performed during software development, some activities are performed after the main development is complete. There is often an installation (also called implementation) phase, which is concerned with actually installing the system on the client's computer systems and then testing it. Then, there is software maintenance. Maintenance is an activity that commences after the software is developed. Software needs to be maintained not because some of its components "wear out" and need to be replaced, but because there are often some residual errors remaining in the system which must be removed later as they are discovered. Furthermore, the software often must be upgraded and enhanced to include more "features" and provide more services. This also requires modification of the software, Therefore, maintenance in unavoidable for software systems.

In most commercial software developments there are also some activities performed before the requirement analysis takes place. These can be combined into a feasibility analysis phase. In this phase the feasibility of the project is analyzed, and a business proposal is put forth with a very general plan for the project and some cost estimates. For feasibility analysis, some understanding of the major requirements of the system is essential. Once the business proposal is accepted or the contract is awarded, the development activities begin starting with the requirements analysis phase.

Following topics describes the above mentioned phases:

1.                Preliminary Investigation

2.                Requirement Analysis / Determination of System's Requirements

3.                Design of system

4.                Development (coding) of software

5.                System Testing

6.                Software Maintenance

7. Error distribution with phases 

Preliminary Investigation 

Fig 2.1 shows different stages in the system's life cycle. It initiates with a project request. First stage is the preliminary analysis. The main aim of preliminary analysis is to identify the problem. First, need for the new or the enhanced system is established. Only after the recognition of need, for the proposed system is done then further analysis is possible.  

Suppose in an office all leave-applications are processed manually. Now this company is recruiting many new people every year. So the number of employee in the company has increased. So manual processing of leave application is becoming very difficult. So the management is considering the option of automating the leave processing system. If this is the case, then the system analyst would need to investigate the existing system, find the limitations present, and finally evaluate whether automating the system would help the organization.

Once the initial investigation is done and the need for new or improved system is established, all possible alternate solutions are chalked out. All these systems are known as "candidate systems". All the candidate systems are then weighed and the best alternative of all these is selected as the solution system, which is termed as the "proposed system". The proposed system is evaluated for its feasibility. Feasibility for a system means whether it is practical and beneficial to build that system.

Feasibility is evaluated from developer and customer's point of view. Developer sees whether they have the required technology or manpower to build the new system. Is building the new system really going to benefit the customer. Does the customer have the required money to build that type of a system? All these issues are covered in the feasibility study of the system. The feasibility of the system is evaluated on the three main issues: technical, economical, and operational. Another issue in this regard is the legal feasibility of the project.

1.                Technical feasibility: Can the development of the proposed system be done with current equipment, existing software technology, and available personnel? Does it require new technology?

2.                Economic feasibility: Are there sufficient benefits in creating the system to make the costs acceptable? An important outcome of the economic feasibility study is the cost benefit analysis.

3.                Legal feasibility: It checks if there are any legal hassle in developing the system.

4.                Operational feasibility: Will the system be used if it is developed and implemented? Will there be resistance from users that will undermine the possible application benefits?

The result of the feasibility study is a formal document, a report detailing the nature and scope of the proposed solution. It consists of the following:

·         Statement of the problem 

·         Details of findings 

·         Findings and recommendations in concise form 

Once the feasibility study is done then the project is approved or disapproved according to the results of the study. If the project seems feasible and desirable then the project is finally approved otherwise no further work is done on it.

Determination of System's requirements: Analysis phase in SDLC 

Requirements Analysis is done in order to understand the problem for which the software system is to solve. For example, the problem could be automating an existing manual process, or developing a completely new automated system, or a combination of the two. For large systems which have a large number of features, and that need to perform many different tasks, understanding the requirements of the system is a major task. The emphasis in requirements Analysis is on identifying what is needed from the system and not how the system will achieve it goals. This task is complicated by the fact that there are often at least two parties involved in software development - a client and a developer. The developer usually does not understand the client's problem domain, and the client often does not understand the issues involved in software systems. This causes a communication gap, which has to be adequately bridged during requirements Analysis.  

In most software projects, the requirement phase ends with a document describing all the requirements. In other words, the goal of the requirement specification phase is to produce the software requirement specification document. The person responsible for the requirement analysis is often called the analyst. There are two major activities in this phase - problem understanding or analysis and requirement specification in problem analysis; the analyst has to understand the problem and its context. Such analysis typically requires a thorough understanding of the existing system, the parts of which must be automated.

Once the problem is analyzed and the essentials understood, the requirements must be specified in the requirement specification document. For requirement specification in the form of document, some specification language has to be selected (example: English, regular expressions, tables, or a combination of these). The requirements documents must specify all functional and performance requirements, the formats of inputs, outputs and any required standards, and all design constraints that exits due to political, economic environmental, and security reasons. The phase ends with validation of requirements specified in the document. The basic purpose of validation is to make sure that the requirements specified in the document, actually reflect the actual requirements or needs, and that all requirements are specified. Validation is often done through requirement review, in which a group of people including representatives of the client, critically review the requirements specification.

Software Requirement or Role of Software Requirement Specification (SRS) 

IEEE ( Institute of Electrical and Electronics Engineering) defines as,

1.                A condition of capability needed by a user to solve a problem or achieve an objective;

2.                A condition or capability that must be met or possessed by a system to satisfy a contract, standard, specification, or other formally imposed document.

Note that in software requirements we are dealing with the requirements of the proposed system, that is, the capabilities that system, which is yet to be developed, should have. It is because we are dealing with specifying a system that does not exist in any form that the problem of requirements becomes complicated. Regardless of how the requirements phase proceeds, the Software Requirement Specification (SRS) is a document that completely describes what the proposed software should do without describing how the system will do it?. The basic goal of the requirement phase is to produce the Software Requirement Specification (SRS), which describes the complete external behavior of the proposed software.

System/Software Design Phase in SDLC 

The purpose of the design phase is to plan a solution of the problem specified by the requirement document. This phase is the first step in moving from problem domain to the solution domain. The design of a system is perhaps the most critical factor affecting the quality of the software, and has a major impact on the later phases, particularly testing and maintenance. The output of this phase is the design document. This document is similar to a blue print or plan for the solution, and is used later during implementation, testing and maintenance.  

The design activity is often divided into two separate phase-system design and detailed design. System design, which is sometimes also called top-level design, aims to identify the modules that should be in the system, the specifications of these modules, and how they interact with each other to produce the desired results. At the end of system design all the major data structures, file formats, output formats, as well as the major modules in the system and their specifications are decided.

During detailed design the internal logic of each of the modules specified in system design is decided. During this phase further details of the data structures and algorithmic design of each of the modules is specified. The logic of a module is usually specified in a high-level design description language, which is independent of the target language in which the software will eventually be implemented. In system design the focus is on identifying the modules, whereas during detailed design the focus is on designing the logic for each of the modules. In other words, in system design the attention is on what components are needed, while in detailed design how the components can be implemented in software is the issue.

During the design phase, often two separate documents are produced. One for the system design and one for the detailed design. Together, these documents completely specify the design of the system. That is they specify the different modules in the system and internal logic of each of the modules.

A design methodology is a systematic approach to creating a design by application of set of techniques and guidelines. Most methodologies focus on system design. The two basic principles used in any design methodology are problem partitioning and abstraction. A large system cannot be handled as a whole, and so for design it is partitioned into smaller systems. Abstraction is a concept related to problem partitioning. When partitioning is used during design, the design activity focuses on one part of the system at a time. Since the part being designed interacts with other parts of the system, a clear understanding of the interaction is essential for properly designing the part. For this, abstraction is used. An abstraction of a system or a part defines the overall behavior of the system at an abstract level without giving the internal details.

While working with the part of a system, a designer needs to understand only the abstractions of the other parts with which the part being designed interacts. The use of abstraction allows the designer to practice the "divide and conquer" technique effectively by focusing one part at a time, without worrying about the details of other parts.

Like every other phase, the design phase ends with verification of the design. If the design is not specified in some executable language, the verification has to be done by evaluating the design documents. One way of doing this is thorough reviews. Typically, at least two design reviews are held-one for the system design and one for the detailed and one for the detailed design.

Development of Software - Coding Stage/Phase in SDLC 

Once the design is complete, most of the major decisions about the system have been made. The goal of the coding phase is to translate the design of the system into code in a given programming language. For a given design, the aim of this phase is to implement the design in the best possible manner. The coding phase affects both testing and maintenance profoundly. A well written code reduces the testing and maintenance effort. Since the testing and maintenance cost of software are much higher than the coding cost, the goal of coding should be to reduce the testing and maintenance effort. Hence, during coding the focus should be on developing programs that are easy to write. Simplicity and clarity should be strived for, during the coding phase.  

An important concept that helps the understandability of programs is structured programming. The goal of structured programming is to arrange the control flow in the program. That is, program text should be organized as a sequence of statements, and during execution, the statements are executed in the sequence in the program.

For structured programming, a few single-entry-single-exit constructs should be used. These constructs includes selection (if-then-else), and iteration (while - do, repeat - until etc). With these constructs it is possible to construct a program as sequence of single - entry - single - exit constructs. There are many methods available for verifying the code. Some methods are static in nature that is, that is they do not involve execution of the code. Examples of such methods are data flow analysis, code reading, code reviews, testing (a method that involves executing the code, which is used very heavily). In the coding phase, the entire system is not tested together. Rather, the different modules are tested separately. This testing of modules is called "unit testing". Consequently, this phase is often referred to as "coding and unit testing". The output of this phase is the verified and unit tested code of the different modules.

System Testing 

Testing is the major quality control measure employed during software development. Its basic function is to detect errors in the software. During requirement analysis and design, the output is a document that is usually textual and non-executable. After the coding phase, computer programs are available that can be executed for testing phases. This implies that testing not only has to uncover errors introduced during coding, but also errors introduced during the previous phases. Thus, the goal of testing is to uncover requirement, design or coding errors in the programs.  

Consequently, different levels of testing are employed. The starting point of testing is unit testing. In this a module is tested separately and is often performed by the coder himself simultaneously with the coding of the module. The purpose is to execute the different parts of the module code to detect coding errors. After this the modules are gradually integrated into subsystem, which are then integrated themselves eventually form the entire system. During integration of modules, integration testing is performed. The goal of this testing is to detect design errors, while focusing on testing the interconnection between modules. After the system is put together, system testing is performed. Here the system is tested against tech system requirements to see if all the requirements are met and the system performs as specified by the requirements. Finally, acceptance testing is performed to demonstrate to the client, on the real life data of the client, the separation of the system.

For testing to be successful, proper selection of test cases is essential. There are two different approaches to selecting test cases-functional testing and structural testing. In functional testing the software for the module to be tested is treated as black box, and then test cases are decided based on the specifications of the system or module. For this reason, this form of testing is also called "black box testing". The focus is on testing the external behavior of the system. In structural testing the test cases are decided based on the logic of the module to be tested. Structural testing is sometimes called "glass box testing". Structural testing is used for lower levels of testing and functional testing is used for higher levels.

Testing is an extremely critical and time-consuming activity. It requires proper planning of the overall testing process. Frequently the testing process starts with the test plan. This plan identifies all the testing related activities that must be performed and specifies the schedule, allocates the resources, and specify guidelines for testing. The test plan specifies manner in which the modules will integrate together. Then for different test units, a test case specification document is produced, which lists all the different test cases, together with the expected outputs, that will be used for testing. During the testing of the unit, the specified test cases are executed and actual result is compared with the expected output. The final output of the testing phases is to the text report and the error report, or set of such reports (one of each unit is tested). Each test report contains the set of such test cases and the result of executing the code with these test cases The error report describes the errors encountered and action taken to remove those errors.

System testing is explained further in the chapter entitled "Testing and Quality Assurance"