We have seen that there are a number of software life cycle models. But the purpose of this chapter is not to explore further on these life cycle models. There are certain phases that the software goes through before, during and after the development process. We will see those phases and examine each phase in detail. The when, why and how of these phases are taken care of by the life cycle models. The various phases or steps in the software development life cycle (SDLC) are:
All the above phases will not be there in all projects. Also all the activities described in each phase will not be present in many projects. Depending on the size, nature and complexity of the project, many of the activities and even some phases might not be present. Also in many projects the activities could be performed in an informal manner. For example, small projects will not have a very detailed Requirements Definition Document (RDD) or Systems Analysis Document (SAD). Also in many projects the alpha and/or beta testing phases could be absent. The phases described below are for a fairly large project; but depending on the nature of the project and organizational policies, some of these phases might get clubbed together, omitted or may be practiced under a different name. Now, keeping this in mind, we will see the different phases of software development in a little more detail.
This phase is sort of a Curtain raiser for the project. The project team is formed and the project leader identified. The project is organized—modules identified, the key members are enlisted and the people who will carryout the support functions such as internal quality assurance, configuration management, etc. are identified. The senior members of the project team will sit together and prepare the project plan so as to ensure completion of the project within the cost, time and resource constraints based on the details available. The main tasks in this phase are:
Studying the project proposal and contract document (if it is a contracted work), estimation work papers and other documents available.
Most organizations will have their own software development standards and guidelines, and if the work is done for a particular client, the project will have to follow the standards of that company. In cases where project standards are not available, they must be developed and finalized during this phase. The standards for various phases include:
The output of this phase is the project plan, and the standards for the next phases. This phase is done usually by a high-level team comprising the project leader, management representatives, SCM manager, support team representatives and so on.
Requirements Analysis and Requirements Specification
This is the phase in which the user requirements and specifications are captured and documented. During this phase, a detailed plan for the phase is prepared. The high level activities for this phase are expanded so that each activity spans not more than one or two person-weeks. The dependencies between the various activities of this module are identified and the activities are scheduled. Plans for housekeeping activities like backup/recovery and security are formulated. The resources required are estimated and the team members are allocated the tasks.
One of the main tasks of this phase is to understand the current system (manual or computerized). This is not applicable for a new product development project where the task is to understand the functions that the software is supposed to perform. The task should be undertaken with a view to examining its adequacy and identifying problem areas. The main tasks that are performed in this phase understand the current system by discussing with the users and studying the documentation available. The main areas that are studied are organization objectives, activities, procedures, rules and standards, files and interfaces and so on.
Every existing system, whether manual or computerized, will have some problems or inadequacies. That is why it is being redesigned. Even if the system is functioning smoothly, there could be areas that could be improved in a computerized system. These existing problems and constraints are identified. The existing system, problems and constraints are documented for future reference and the findings are discussed with the client or user.
The next step in this phase is the definition of the user requirements. The main activities that are performed in this phase are diagnosing existing problems and defining the user requirements. To do this, the context of the problems has to be understood, the scope of the problems has to be assessed and the user requirements, application requirements and information requirements have to be determined.
Once the user requirements have been defined, the next step in this phase is the preparation of the Requirements Definition Document (RDD). The RDD is sometimes known as the Software Requirements Specification (SRS). Once the initial draft of the RDD is created, it is given to all the parties of the software project—users, clients, project team and the support functions. After incorporating the suggestions from all quarters, the final RDD is prepared.
The output of this phase is the documentation of the existing system, and the RDD. The requirements analysis and the preparation of RDD will be usually done by the system analysts in collaboration with the users.
In the system analysis phase the proposed system is defined after analyzing various alternatives. The main tasks that are performed in this phase are:
Evaluate alternatives. Perform impact or cost-benefit analysis for:
Select an alternative.
Determine system requirements with respect to:
Discuss the proposed system with the client
In some cases the project management may decide to develop a prototype of the system to demonstrate the understanding of the user requirements and the functionality that will be provided in the proposed system. Prototyping is required if lack of clear understanding of the user requirements is considered as a major risk in the project. Major activities in case of prototyping are:
Once the prototype is developed and the feedback is obtained, the next step is to prepare the Systems Analysis Document (SAD), where the proposed system's functionality is documented. While preparing the SAD, a usability plan is prepared. Usability plan is prepared when the system that is being built uses commercial-off-the-shelf (COTS) packages for performing some tasks in the system. The usability plan will compare the available packages and will be of help in identifying the one that is best suited for the system— cost-effectiveness, amount of customization, method of integration of the selected package into the software system and so on. This plan is needed only if the system uses off-the-shelf packages.
During this phase the project plan and the RDD are refined and updated based on the project progress and changes in the scope of the project. The output of the Systems Analysis phase is the prototype (if developed), the SAD, the usability plan, the updated project plan and the RDD.
High Level Design
High Level Design provides an overview of the whole system identifying all its elements at some level of abstraction. This contrasts with Low level Design which elaborates the detailed design of each of these elements. The following steps are carried out in order to properly design the system:
There are several purposes for high level design.
Preliminary design - In the preliminary stages of a software development the need is to size the project and to identify those parts of the project that might be risky or time consuming.
Design overview - As it proceeds, the need is to provide an overview of how the various sub-systems and components of the system fit together.
In both cases the high level should be a complete view of the entire system breaking it down into smaller parts that are more easily understood. To minimize the maintenance overhead as construction proceeds and the lower level is done it is best that high level design is only elaborated to the degree needed to satisfy these needs. Sometimes a prototype is developed to demonstrate the user interface design, screens, navigation and other features of the system. Developing a prototype in HLD phase is required if it is desired to demonstrate to the user, the design features of the system such as system architecture, user interfaces and system functionality. Sometimes a prototype is developed during the system analysis phase to demonstrate the understanding of the user requirements and the functionality that will be provided in the proposed system. If such a prototype exists, then this prototype is refined during the HLD phase to demonstrate the user interface design, screens, navigation and other features of the system.
It is in this phase that the system components like modules, programs, functions and routines are identified. The system components are identified hierarchically to the level required. The inputs and outputs of the system are defined. These include menus, screens, navigation, levels of help and help screens, reports, error messages, user interface and so on. The programs for each component are identified and classified. The programs can be classified as on-line/batch, reports, transactions, drivers, functions, libraries, etc. The performance requirements for each component are established and the components that can be reused are identified. The following items are produced as a part of this exercise:
The next step in this phase is to define the system architecture. The system architecture is established in terms of security, data access, communication, restart/recovery, audit, and user interface. The system architecture deals with issues like whether the proposed system will be a client/server system or a mainframe system or will it be a geographically distributed system, what technology should be used, how the communications network should be set up and so on. The program dependencies and interfaces are identified and the system architecture for each class of programs is finalized and documented.
Another task in this phase is the finalization of the database/file design. The database/file design is derived from a data model or data store identified during analysis. This should include content, access and organization of the database/files. The contents of each of the tables/files in the database and the access path are defined. The necessary normalization of the database tables is performed to ensure processing efficiency. This step produces the Database Design Document (DDD).
The final task in this phase is the preparation of the HLD document. The HLD document is prepared as per documentation standards for HLD. The documents that have been prepared so far like the design objectives document, the system architecture document, the database design document, etc. are used as the input for the HLD document. The system test plan is a part of the HLD document. So while the HLD is compiled, the system test plan (STP) and system test specification (STS) are also prepared which will form part of the HLD document. The preparation of the initial draft of user documents such as user manual, capabilities manual and tutorials are started in this phase. So this phase produces the following documents:
All these documents produced in this phase are reviewed and if changes are required for any of the items produced during the earlier phases, then those items are updated.
Low Level Design or Detailed Design
Low Level Design (LLD) is like detailing the High Level Design (HLD). It defines the actual logic for each and every component of the system. Class diagrams with all the methods and relation between classes comes under LLD. Programs specs are covered under LLD.
LLD describes each and every module in an elaborate manner so that the programmer can directly code the program based on this. There will be at least 1 document for each module and there may be more for a module. The LLD will contain: - detailed functional logic of the module in pseudocode - database tables with all elements including their type and size - all interface details with complete API references(both requests and responses) - all dependency issues -error message listings - complete input and outputs for a module.
In this phase the copy libraries, common routines and program skeletons to be used are finalized. The HLD is analyzed to understand the system architecture, the components, programs and their interfaces. The standards prepared for LLD phase are studied. The component libraries to be used for each of the programs in the system are identified, so are the common routines and the input and output for these common routines. If program skeletons or templates are planned to be used for various types of programs, then the scope and contents of such skeletons and templates are decided. The specifications for the component libraries, common routines and skeletons are written.
The major task in this phase is writing the specification for each program in the system. Writing program specification is essential for projects involving development in procedural languages. For each program and reusable routine identified in the system, the program logic is determined, the structure chart is prepared (if necessary), the inputs, outputs, error messages and help messages are finalized and the program specification is prepared. As a part of the program specification, the Unit Test Specification (UTS) and Unit Test Plan (UTP) are prepared.
The last step of this phase is the preparation of the LLD document consisting of program specification for all the programs, component libraries, skeletons and templates of the system. At the end of this phase the project plan is updated, the RDD, SAD, HLD, STP, STS and the user documents are refined, based on the changes and additional information obtained during this phase.
Coding and Unit Testing
During this phase the programs, copy libraries, functions and other program elements are coded (or generated) and tested (unit testing). The main people who are involved in this phase are the developers/programmers, the analysts, the QA team and the testers. Among all the life cycle phases, this is the phase that will involve most number of people. The major activities during this phase are:
The output of this phase is the unit-tested programs containing the source code, the test results, the associated documentation, etc.
This is the phase of the software development life cycle where the system testing or integration testing is carried out. The system test is done using the STP, STS and system test data. Many companies do alpha and/or beta testing also.
Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing.
Beta testing comes after alpha testing and can be considered a form of external user acceptance testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.
Usually companies distribute the beta releases free of cost to the people who have enrolled for the beta testing program and in many cases the beta versions will be available for download from the company's web site. New products will have the alpha testing followed by the beta testing. But in the case of new versions of existing products, either alpha or beta testing is done. The tasks in this phase are:
The major players involved in this stage are the QA team, the testers, the development team (for bug/problem fixing), the actual users of the system and so on. If alpha and/or beta testing are present, then the number of people who will be testing the system will increase dramatically. Once the project is successfully tested, audits are performed to ensure that the final product is complete and satisfies the specifications.
Acceptance Testing is a level of the software testing process where a system is tested for acceptability.The purpose of this test is to evaluate the system’s compliance with the business requirements and assess whether it is acceptable for delivery.
In this phase the project team prepares for the acceptance test by ensuring the availability and completeness of all work items needed for acceptance test and loading the acceptance test data. The project team will assist the client/customer in acceptance testing, recording the errors found and fixing them.
Phases, Output and People of the Software Development Life Cycle
The implementation stage of a software development lifecycle starts when software developers get the baseline for their work on the project, which is provided by software architects. Software developers are tasked with coding the requirements of software design and the result of their work proceeds to the next stage of verification.
In this phase, the project wind-up activities are completed. All the resources acquired for the project are released. The main activities in this phase are:
Once the system is developed and tested, it is released to the users. From this point onwards the maintenance phase starts. Once people start using the system, many errors that escaped the testing will be found. The users might ask for new features and enhancements. It is the responsibility of the maintenance team to attend to these requests and to fix the bugs that are found. If the project has not followed any standards and does not have any documentation, then the job of maintaining the system can turn into one of the most difficult assignments that software professionals can have. A very good example of this is the Y2K projects, where people had to fix the problems in programs that were more than 20 to 30 years old, programs that had no documentation and that were developed without any programming standards and naming conventions.
The six software maintenance processes as:
The final phase in the life cycle of a software product or system is retirement. After many years of service, a stage is reached when any further maintenance would not be cost-effective. This could happen because the proposed changes are so drastic that the design as a whole would have to be changed and it would be cheaper to redesign and recode the entire product from scratch. The other reason is that, many changes may have been made to the original design that interdependencies have inadvertently been built into the product, so much so that there is real danger that even a small change to one module will have a drastic effect on the functionality of the product as a whole. Yet another reason is that the documentation may not have been adequately maintained, thus increasing the risk of a regression fault to the point where it would be safer to recode than to maintain. Another reason for retiring a software product is that technological advancements have made the existing system obsolete. The hardware on which the product runs have to be replaced by a different (more powerful and less expensive) machine with a different operating system and it is cheaper to rewrite from scratch than to modify the product. In each of these instances the current product is retired and a new version will be developed and the life cycle continues.
True retirement (removal of the product) is a rare event that occurs when a product has outgrown its usefulness. The client organization no longer requires the functionality provided by the product and it is finally removed from the computer on which it has been in operations mode for many years.
We have seen what is software development life cycle and the various phases involved in the software development process. All these phases may not be present in all the projects and as already mentioned the order in which the various steps are executed will vary. Most of the times, there will be some degree of overlap between the various phases. The software life cycle model that is adopted will determine these things. We have also seen the various activities and outputs of each phase. These aspects are summarized in the above figure.
IBM Mainframe Related Interview Questions
|IBM Lotus Notes Interview Questions||IBM-CICS Interview Questions|
|COBOL Interview Questions||Linux Interview Questions|
|IBM-JCL Interview Questions||IBM Mainframe Interview Questions|
|IBM AIX Interview Questions||IBM WAS Administration Interview Questions|
|IBM Lotus Domino Interview Questions||IBM Integration Bus Interview Questions|
|Mainframe DB2 Interview Questions||Unix Production Support Interview Questions|
Ibm Mainframe Tutorial
Introduction To Software Development
Introduction To Ibm Mainframes
Tso And Ispf
Jes2, ]es3 And Sms
Introduction To Job Control Language (jcl)
The Job Statement
The Exec Statement
The Job And Exec Statements
The Dd Statement
Procedures And Symbolic Parameters
Generation Data Groups (gdg), Compile/link-edit And Run Jcls
Access Method Services (ams)
Additional Vsam Commands
Introduction To Rexx
Overview Of Rexx
Introduction To Cics
Exception Handling In Cics
Developing A Cics Application
Cics Programming Techniques
Basic Mapping Support (bms)
Transient Data Control
Temporary Storage Control
Interval And Task Control
Cics Application Design
Recovery And Restart
System Security And Intersystem Communication
Cics Debugging Facilities And Techniques
Bms Map Definition Macros And Copylib Members
Cics Response And Abend Codes
Data, Information And Information Processing
Introduction To Database Management Systems
Introduction To Relational Database Management Systems
Database Architecture And Data Modeling
Overview Of Db2
Structured Query Language (sql)
Data Security And Access
Db2 Application Development
Qmf And Db2i
Db2 Performance Monitoring, Utilities And Recovery/restart
Overview Of Information Management System (ims)
Introduction To Vs Cobol Ii
Overview Of Application Development In Vs Cobol Ii
Overview Of The Cobol Program
Sorting And Merging Files
Coding Cobol Programs That Run Under Cics. Ims, Db2 And Ispf
Compiling The Program
Link-editing The Program
Executing The Program
Improving Program Performance
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.