The 5 Phases of Software Life Cycle (SLC) | Intermediate Business Programming with C++

Problem Analysis and Specification Phase (Software Requirements Specifications)
Design Phase (Software Design)
Coding Phase (Implementation of Design)
Testing, Execution and Debugging Phase (Software Testing)
Maintenance Phase (Software Maintenance)

Note: The approach to software life cycle listed above is sometimes referred to as the "waterfall" approach where one phase follows immediately after the other.

Note: Each of these phases produces documents. As the project progresses, these documents will have to be written and then rewritten. Some believe that documentation is so important that when discussing the 5-phases a sixth phase should be added: the documentation phase.

Note: Errors in the software system can be created in any one of the 5-phases. Some of the causes of these errors are:

faulty system's analysis
communication errors between the stakeholders and the developers
feature "fluff" where the stakeholders request features that are not needed
deliberate deviation from the specifications by the computer system's staff
logical design errors
coding errors
non-compliance with the specifications
incomplete and inaccurate testing
procedure errors
documentation errors
errors caused by insufficient time and money devoted to each phase

Note: In a large corporation's information technology dealing with a large project, the specification phase could take 2 months, the design phase could take 4 months, the coding phase could take 3 months and the testing phase could take 3 months. This would be followed with user training that might take 1 month.

The maintenance phase starts this process all over so you can see that software development can take a long time and in fact never end.

Some projects can take years to complete. In fact some projects can take so long that the reason to begin the project is no longer important and the project is canceled.

Note: Although not discussed during this course, a user's manual should be created. Its construction should begin during the first phase and should continue until after the project is completed.

Note: Although not discussed in this course, part of the phases should be a training phase both of those who are to create the program as well as those who will use it. In addition some testing should be conducted in each phase with the major testing taking place during the Testing Phase. The quality assurance should continue throughout the project.

Note: In a software development and maintenance organization, the different types of positions available can be:

Software or Systems Quality Assurance Engineer
Software or Systems Analysts
Software or Systems Designer
Programmer
Software Tester
Software Maintenance Technician
Systems Security Engineer
and team leaders for each of these groups.

Try to determine which of these positions best meets your qualifications and professional goals.

Note: Some new terms have been added that better describe how the SLC is implemented. These terms are: White Box SLC, Grey Box SLC and Black Box SLC. By these terms the following is meant:

White Box SLC means that all of the phases of the SLC are done by the IT employees of the company for whom the system is being developed.
By Grey Box SLC is meant that some of the phases or parts of a phase are done internally by the IT employees of the company for whom the system is being developed while other phases or parts of these phases are out sourced to other companies like the Coding Phase or the Testing Phase.
By Black Box SLC is meant that most if not all of the phases are performed by one or more outside IT companies. While almost the entire project is out sourced, the company's employees may participate somewhat by providing necessary information for the out sourced contractors.

Problem Analysis and Specification Phase

In this phase the analyst, the security and the quality assurance engineers attempt to do each of the following and to create software requirements specification documents that address these issues:

Obtain a formal statement of the software requirements.
Obtain copies of the major reference documents.
Determine what platform the final project will run on and what computer language as well as what version of the language the project must be written in.
Determine who the users and other stakeholders will be, what type of User Interface (UI) will be required and how often the program will be used.
Determine what level of fault tolerance and security will be required and whether the final project will be open to judification in a court of law.
Develop benchmarks that will be used to evaluate the final system.
Collect sufficient data to be used for testing through the entire project during each of the phases as well as in the Testing Phase.
Ask questions of the users, those in management and other stakeholders who will monitor the project to ensure that what is truly being requested is understood.
Determine whether the specifications must be written in the design phase using one of the formal methods like: Z, VDM, Larch, UML or some other design methodology and if so then the specifications must be written to support that methodology.
Write descriptions of the input and output and then show it to the client, the users and other stakeholders for their verification.
Write and then rewrite the system specifications as they become better known.
Ask the client, the users and other stakeholders after each rewrite whether the newly written specifications are closer to what the real needs are.
Ask the clients, the users and other stakeholders whether their stated specifications are a real requirement or whether some of it is "fluff" i.e. something that would just be nice to have.

To be a good analyst you need to have:

analytical skills
technical skills
managerial skills
interpersonal and communications skills as the most important skills that are needed

At the end of this course, you need to ask yourself:

Do I want to do Problem Analysis and Specification? If you do, then you need to study OOA in more depth and seek to become certified as a Business Analyst.
Do I have the necessary skills to be successful doing this phase?

Note: During this course you will prepare a specification document for each programming homework but you will not be required to act as a systems analyst.

Note: This phase is sometimes referred to as the System Requirements Specification (SRS) phase. Part of this phase can include an analysis process called: Object Oriented Analysis (OOA) and System Security Specification.

Note: As part of the SRS should be a determination and documentation of the training needs of the system users in order to increase the possibility of a successful project.

Note: It is recommended that you read the following book:

Wiegers, Karl; Software Requirements 2nd Edition; Microsoft Press; Redmond, WA 2003; ISBN 0-7356-1879-8

Design Phase

In this phase sometimes be called Object Oriented Design (OOD), the programmer attempts to:

Identify the objects in the problem's specification and their data types to identify the data structures and then to create graphics and charts that describe these data structures.
Identify the multiple modules needed to solve the problem and then to create a graphical representation that describes the relationships between these modules.
Identify the User Interface components (there may be more than one i.e. a customer UI v.s. an employee UI) and design how each of these UIs will appear.
Identify the security components that will be required.
Create for each module an algorithm (that is a sequence of steps), that when applied in the programming language, will solve a particular part of the problem.
Develop the algorithms so that they are:
- Definite and unambiguous
- Simple
- Finite
But most importantly understand that the design should create a program that is well structured and where:
- program = algorithms + data structures
Develop the design using the Design Tools

At the end of this course, ask yourself:

Do I want to do Design? If so, then you should take additional courses in OOD.
Do I like to analyze things in their smallest details? If so, then you should study OOA.
Do I like to write descriptions of these minute details, to draw pictures of these tiny details and then to describe what I see to others?
Do I have the people skills to do the design phase?

Note: The need to off shore programming may decrease in the future because several companies are offering tools that take the designs that are created in UML 2.0+ and converting these design documents into C++ or C# programs as will be demonstrated later when UML charts in Visual Studio .NET 2005 will be used to write the definitions of classes. It is also possible with tools like these to convert C++ or C# program into UML design documents as will be seen later when Visual Studio .NET 2005 is used to convert class definitions into UML documents.

Design Tools

Some of the design tools:

Abstract Data Type Description (a collection of standardized symbols like UML that illustrate the overall relationships between the major pieces of the program including the data)
Human Interface (a collection of sample or potential screens and reports that shows what the user will see.)
System Flowcharts (a collection of standardized symbols that illustrate the relationships between all of the programs in the system)
Structure Chart (a collection of standardized symbols that illustrate the overall relationships between the major pieces of the program to include the movement of data between the individual modules if any)
Flowchart (a collection of standardized symbols that express the logic flow of a program.)
Pseudo Code (a mixture of natural language (not necessarily English), terms, symbols and other features commonly used in one or more high-level languages that express the logic flow of a program.

Abstract Data Type Description

These descriptions could include data type descriptions using UML data charts like the following:

CustomerRecord
-firstName
-lastName
-accountNumber
-currentBalance
+addCustomer()
+modifyCustomer()
+changeBalance()
…

TransactionRecord
-accountNumber
-transactionAmount
-accountType
+addTransaction()
+modifyTransaction()
…

Human Interface

This may include reports like the following:

Southern Warehousing Monthly Accounts
Open table as spreadsheet
Customer Name	Account Number		Starting Balance		Ending Balance
Customer One	1111111		XXXX.XX		XXX.XX
Customer Two	2222222		XXXX.XX		XXXX.XX
Customer Three	3333333		XXXX.XX		XXXX.XX
....	....	....		....
	Totals		$XXXXX.XX		$XXXXX.XX

System Flowchart

System flowcharts show the interrelationship between different parts of the total system and the program being written:

image from book

Structure Chart

A structure chart shows the modules of the program being written and their relationships and in some cases the movement of data between the modules:

image from book

Flowchart

Flowcharts show the modules and their interrelationships, the program's logic and the variable names.

image from book

Pseudo-Code

Pseudo code show the modules their interrelationships, the programs logic and the variable names but it does this using words:

 START   PROCESS Initialization   PROCESS Report Heading   Read fname, lname, accout_no, start_balance, transaction_type   DOWHILE(More Records)    PROCESS Detail Record    Read fname, lname, accout_no, start_balance, transaction_type   ENDDO   PROCESS Report Totals END Initialization   total_previous = 0.00   total_current = 0.00 Return Report Heading   Display Company Name, Report Name, Column Headers Return Detail Line   Display name, account_no, start_balance, end_balance Return Case 'D'   total_previous = total_previous + start_balance   end_balance = start_balance + transaction   total_current = total_current + end_balance Return Case 'W'   total_previous = total_previous + start_balance   end_balance = start_balance - transaction   total_current = total_current + end_balance Return Invalid Case   Display Error Message Return Detail Record   CASEENTRY Opcode     CASE 'D'       PROCESS Case 'D'     CASE 'W'       PROCESS Case 'W'     Case other       PROCESS Invalid Case   ENDCASE   PROCESS Detail Line Return Report Totals   Display total_previous, total_current Return

Coding Phase (Implementation of the Design)

In this phase the programmer:

Encodes the program modules into the previously selected language and version that was selected in the Specification Phase using the data types, the logic, the modular design, the security issues and the variable names selected in the Design Phase.
While creating the modules, writes the code in a: Well structured, documented and stylistic manner
Combines the program modules into a complete software system.
Ensures the program quality and that the code is correct, readable and understandable by reading the code in each module and in the combined program.
Hand verifies the logical correctness and the integration of the various parts of the program by using the sample data generated in the Specification Phase.
Translates the program from the source code into machine code using the selected language's compiler to determine if there are any syntax or warning errors.

At the end of the course, ask yourself:

Do I want to do Implementation of the Design phase (i.e. do you want to do the Coding Phase? If you do, then you should study OOP.

Well-Structured, Documented and Stylistic Programs

The code needs to satisfy the following criteria (This list is sometimes referred to as the developer's requirements to distinguish it from the program requirements):

The program should have opening comments.
Each module should be documented like the program with opening comments.
There should be internal comments that explain each key section of the program and each module.
Each module and each variable should use meaningful names. If the name is one word, then it should be in lower case. If a name contains more than one word, then the first word should be in lower case and the first letter of the remaining words should be in upper case while the other letters in these words should be in lower case.
The documentation of the program and of each module should be formatted in a style that enhances its readability by meeting the following criteria:
- Each program statement should be on a separate line.
- Upper and lower case should be used in a way that enhances readability.
- The placement of each { symbol and its corresponding } should be listed on separate lines from the other code and listed in the program so that they are vertically aligned.
- There should be an indentation of the lines that are enclosed within a { and its corresponding }
- The indentation of statements that are more than one line should be written so that after the first line they are indented more with respect to the first line.
- There should be vertical alignment of the names of the variables when they are defined.
- There should be blank lines inserted between definitions, declarations, statements, and blocks of code.
- The placement of the definitions and declarations of variables should be near the top of the section where they are first used.
- There should be a separation of the operators from their operands by spaces.
- The output should be labeled so that the user understands what they are being asked or what they are viewing

Testing, Execution and Debugging Phase

This phase is sometimes referred to as the Software Quality Assurance (SQA) phase. By Software Quality Assurance is meant:

A systematic, planned set of actions necessary to provide adequate confidence that the software development process or the maintenance process of a software system product conforms to established functional technical requirements as well as with the managerial requirements of keeping the schedule and operating within the budgetary confines.

In this phase the programmer or the Software Quality Assurance (SQA) staff checks each of the following:

Checks for Validation. That is the SQA staff tries to answer the question: "Are we building the correct product?" To do this the QA staff needs to check that the documents, the program modules, etc. to see if they match the requirements of the users and other stakeholders.
Checks for Verification. That is SQA staff tries to answer the question: "Are we building the product correctly?" To do this SQA staff needs to check that the product is correct and complete as well as whether the parts are consistent with each other and whether they are consistent with the documents of the preceding phases.

In addition to testing during the Testing Phase, the SQA staff is aware that errors may occur in any of the phases and therefore they test each phase.

The SQA staff is aware that errors may occur for various reasons to include:

Software Requirements Specifications don't accurately reflect given information or the user's and other stakeholder's needs/requests
Logic errors in algorithms
Incorrect coding or integration
Failure to handle boundary data or test values

The SQA staff knows that there are different kinds of testing types which are required and uses them where appropriate.

The SQA staff knows that no matter how much they test the program, there will still be bugs and they strive to keep the number of errors within acceptable limits

At the end of the course, ask yourself:

Do I want to do Testing, Execution and Debugging? If so, then you may become a member of the Software Quality Assurance or Software Testing group.
Do I have the skills to be successful in this area? If so, then you may want to take additional courses in software testing and software quality assurance. In addition you might want to consider becoming a Certified Software Quality Assurance Engineer.

Note: The quality assurance staff might want to consider the purchase of one of the many testing software programs to support the testing process.

Note: Testing done by the coding team may not yield quality testing because of their involvement in creating the code. In addition there may also be problems when the testing is conducted by members of the same company as the coding team. Sometimes it is necessary to contract with an outside testing company in order to gain quality testing.

Note: One of the major causes of programs not passing the testing process is that the project had difficulty meeting SRS deadlines and staying within budget.

Note: One of the problems may be that the program passes the testing phase yet did not meet the SRS. In fact testing may determine that there is a need for recoding of the program and maybe even determine that there needs to be a completely new SRS.

Note: This discussion of SQA may seem to imply that software quality assurance does not begin until after the coding has been completed. What should be noted is that, the testing may need to begin as soon as the SRS has been accomplished or even as part of the SRS.

Note: The SQA budget may be as much as 20% - 30% of the total cost of the program. It may be determined when considering the costs that the SQA should be handled by an outside SQA firm.

Note: I recommend that you read the following book:

Galin, Daniel; Software Quality Assurance; Pearson Education; London, England; 2004; ISBN 0-201-70945-7

Testing Types

Testing consists of many different types of tests to include:

Unit tests that include:
- The most rigorous and time intensive part of the testing and is the most fundamental and the most important
- Testing the program components in isolation
- Verification that each individual program unit works as designed
- Testing for errors to include:
  - syntax errors
  - warning errors
  - linking errors
  - run-time errors
  - logical errors
  - system and data security leaks
Integration tests that include:
- Testing that determines if the units combine correctly
- Testing the component interfaces and information flow
- Testing that determines whether the data moves correctly from one unit to another
System tests that include:
- Testing that determines whether the overall system is working correctly
Black box (or functional) tests that include:
- Testing that determines whether the set of test data works.
- Testing of the output produced for various inputs for correctness without considering the structure of the program component itself.
- Testing a program unit as if it is a black box that accepts inputs and produces outputs, but ignores the inner workings of the box.
White box (or structural also called glass-box because the tester looks inside of the program components) tests include:
- Testing of specific sections of the program to determine if each section is working correctly
- Testing the performance by examining the code's internal structure.
- Selecting test data carefully so that specific parts of the program units are exercised.
- Testing that may include the following of the values from one variable to the next by using the debugger and its jump points.
- This testing is more expensive that Black Box because the tester looks at the interior workings of each individual part of the program.

Testing is frequently subdivided into two general types:

Alpha Testing that is done in-house by staff members (This group is frequently called the Software Quality Assurance or Testing staff.)
Beta Testing that is done outside of the company and is done by "real people" where the system developers try to determine:
- Is it possible for "real people" to interact with the program as it is designed and meet the system requirements specification?
- Do "real people" get the correct outputs for specific inputs?

Note: I recommend that you read the following book:

Craig, Rick et al; Systematic Software Testing; Artech House Publishers; Boston, MA; 2002; ISBN 1-58053-508-9

Maintenance Phase (Adding Enhancements)

As a future programmer, it is important for you to know some of the reasons for the need of the maintenance phase. These reasons can be:

that some of the previous phases were done incorrectly.
that the original program specifications or the business plan has changed.
that because of poor program structure, poor program documentation or poor program style you are required to redo some of the program or all of the program.
that the testing did not catch all of the bugs before the release so that some or all of the program needs to be redone‥
that marketing or management was trying to hurry the development of the program before it was completed so that they could deliver the product.

It is important for you to know:

that the fixing of bugs is difficult, time consuming and never ending.
that the process of removing bugs impedes implementation of program enhancements.
that some of the reasons that maintenance may fail are:
- the code does not agree with the documentation.
- changes were made to the program but there is no documentation to indicate what or why the changes were made.

It is also important for you to know that this phase can be the:

Largest % of computer center's budget
Largest % of programmer's time
Largest % of software development costs
Only type of IT positions open at some companies

At the end of the course, you need to ask yourself:

Do I want to do maintenance?
Do I have the skills necessary to do this type of work?