The Software Development Life Cycle outlines the process for successful software development. The concepts of SDLC are part of Project Management, regardless of what PM strategy you use.
This cycle may be a day or a year but in its most simplified form The Cycle looks like –
Specify > Develop > Test and Document > Release
For some development teams the cycle is long and can be years. For others the cycle is short and can be a day or less. Regardless, the same concepts of SDLC still apply. Even for a lone Developer the same concepts apply. It’s just that one person wears most of the hats.
So let’s look at the Process but first we’ll look at the People involved and the Environments the need to be setup.
That is to say the Development Environment, Test Environment, User Acceptance Test Environment and the Production Environment.
Although I will cover the Cycle for distributed applications, my emphasis is on Custom Applications.
Protagonists
The following are the roles involved in the SDLC.
Some of these roles may be taken by the same person. Some roles are performed by multiple people. But all of these roles should be involved in the Development Process.
Users
These are the people who will actually use the product. Users have a tendency to judge software based on familiarity. So even if you produce software which, as a Developer, you believe is way better than what they currently have, they may not agree simply because it is unfamiliar.
So you have three choices when approaching software design to ensure happy users. Either create software which is very close to what they currently use, evolve the software in small steps or spend enough time training users to make them comfortable and familiar with their new systems.
Client
This is the person who will ‘accept’ the product and therefore authorise for the payment of development. This is usually the person who will be most involved in the original needs analysis and Specification Signoff.
In some organisations this person’s view on what is acceptable can be different to the Users’.
I have seen examples where the Client only cared about whether the software could carry out the required functionality but not how well, leaving users frustrated with software which was difficult to use but ticked all the boxes.
Business Analyst (BA)
The BA is the person who will work with the Client to define the required outcomes and business processes and then interface with the Development Team.
The result is a Specification or Logical Design. The BA may then negotiate with Developers to form a Technical Design.
Product Manager
This is the person responsible for the Overall Product.
Quite often this person is responsible for the marketing and overall profitability.
When I say ‘Marketing’, I don’t mean selling but I do include saleability. That is to say that the product does what is required for the market niche and that the quality and pricing make it a viable product. Only once the Product, Placement and Pricing are right can the Promotion be truly successful.
One core responsibility is to oversee the Design Process and determine how proposed changes may affect the product as a whole and how it may affect other users.
This includes the concept of Consistency. The look and feel of the Product should be consistent throughout.
In some cases of Custom Applications the Client may take on the Role of Product Manager.
Project Manager (PM)
This is the person who accepts the specification on behalf of the Development Team and prepares time estimates.
Then delegates the work to members of the Development Team, monitors their progress, and helps them to complete their tasks.
The Product Manager and Project Manager are often one in the same and often referred to as Development Manager.
The PM is ultimately responsible for the budget and delivery.
In some Project Management Methodologies the Project Manager should be the Client, or their representative, even when the Development is contracted to an external organisation.
To me this seems dangerous unless the PM has total authority over the Development Team (DT). If the DT is employed by an external organisation then that organisation can direct Team Members to other tasks, or projects, or assign less capable developers to the project and thereby undermine the PM’s ability to deliver.
I would prefer that for a large project the Client appoint a Project Director who works with the contractor’s PM to monitor progress and set priorities.
Programmer
The Programmer(s) write the software using the Specification Documents as a guide and then Unit Test before delivery to the Test Environment. Programmers should ensure that they test well before passing their work to the Testers.
Tester
Testers use the Specification Documents as a guide to test the software for bugs and compliance to the Spec.
The specification document can be used as a basis for a test plan of changed functionality but a general test plan should be used to test critical functionality to ensure that nothing has been adversely affected that may cause a major disruption.
The extent of the Test Plan is subject to risk assessment. A complete retest of the entire application, for a minor release, is rarely justifiable but testing critical functionality is a vital. The extent of the test plan can also be subject to a code review in which potential effects on other parts of the application can be identified.
Each unit can be returned to the Programmer for fixes and modifications if it does not comply but care should be taken to prevent an ‘Us and Them’ culture between Programmers and Testers.
Programmers and Testers should work closely together with great cooperation and respect. They will often need to negotiate to achieve the required outcomes.
Documenter
To my mind the documentation should be evolving throughout the Cycle with the original Specification (or LD) forming the basis. Programmers should add technical notes and Testers should then flesh out the documentation to become a User Guide.
Software can really only be deemed ready for release when its functionality matches that expressed in the User Guide.
Use Case videos are a great way to train Users but they are also a great way to test. You cannot create a Use Case video in a single take if the software has bugs or even bad navigation.
User Guides or Videos should be easily accessed by Users. Preferably by providing links within the software to take the User directly to the relevant content.
Trainer
This is an important role and, although I see this as Post Development and a Client Responsibility, a software release can fail simply because of lack of training.
Good training starts by providing the users with an overview of the functionality they are learning, a review of the Documentation so that they understand the new processes and know where to go when they need answers and a practical session to ascertain that the Users have a good grasp on the processes.
The Trainer may also be the Documenter and a good source of feedback to the Developers on useability.
Environments
The end result of a software release is an app working in the Production Environment. But before you release a version into Production you first need to Develop and Test so you also need to create a Development Environment and at least one test environment.
With a new application there is no Production Environment so we are going to start with a clean slate and that means an empty database. But if the application is already in Production then we should take a copy of the database and install it in the Development Environment.
Development Environment
Here the developer(s) have their own BE database(s) and can bang away at it and make a mess of the data as they make and correct mistakes. This data should be refreshed with a copy of the Production Data at regular intervals.
Developers should Unit Test with fresh data before sending a new version to the Tester(s).
Test Environment
The Test Environment has its own frequently refreshed copy of the Production Database. There are going to be instances where a bug is discovered that has caused bad data so a new iteration of changes from the Developer with fixes should be accompanied by a fresh copy of the Production Database.
If Developers do not adequately test before sending a version to the Tester(s) then we can see Tester Fatigue. This occurs when the same functionality is found faulty and multiple iterations result in the Tester getting a bit fed up.
At this point, Release Notes should note all changes to functionality and bug fixes for this release.
UAT
An important concept in the SDLC is User Acceptance Testing. Despite thorough testing by the Testers in the Development Team, there can be times where the business processes do not fulfil the User’s expectations. Or the user goes about their data entry in a way not foreseen by the development team.
UAT also provides a sharing of responsibility. If Users just took a release on blind faith and put it straight into production, any issues arising will result in a blame game.
So it is important that the Client takes responsibility for UAT before a new version is released.
Client testers should be able to use the Release Notes and Specification (or User Guide).
There should be an easy method for the Data to be refreshed from Production to the UAT Environment.
The Client is ultimately responsible for UAT.
Product Manager Testing
If an Application is to be released to mass market then UAT may not be an option. In this case it should be the final responsibility of the Product Manager to make a final test before authorising a release.
While Testers should expect to find some issues and need to test multiple iterations, the product, as it arrives to the Product Manager, should rarely need rework but this step forms the backstop.
At this point the Product Manager should ensure that the Documentation matches the Product Functionality and that everything is in place for a Professional Release.
The Processes in Detail
Specify
Before Development can begin we need to create some kind of specification. Without this the developers don’t really know what they are trying to achieve and the testers can’t measure whether they have achieved the required outcome.
This can be as simple as a client making a request for a small change over the phone in which case I would simply outline my takeout from the discussion, put it in an email, and send it to my client so that we have a written understanding.
It is important to get client signoff before starting development to avoid arguments later. Often clients may not really know what they want but it is up to the Business Analyst (who may also be the developer) to elicit the objectives and therefore the required outcomes.
If the required outcomes are stated in writing then there can be no argument but there may still be room for negotiation on method.
Plan
The Management Plan should, where possible, provide an estimate of cost. This cost can them be used for the Business Justification of the Project.
Scope
Scope is the Key to managing cost. If the Scope of work is not well defined then costs can easily escalate. The PM should keep a firm grip on Scope.
Costing
With a New Application, the costing should be reasonably accurate given the previous experience of developing similar applications.
For the rework of Existing Applications it may be next to impossible to predict the issues that will arise. For small amounts of work this should not be a big issue and as the application is subjected to more of these bite size enhancements the predictions can then be based on the previous encounters.
But if there are underlying issues, like a badly designed schema, then costs can be impossible to predict.
For some projects the imperative is vital and the Project simply must succeed regardless of cost. In this case the Client should be kept close and well informed of the issues as they immerge. The Client should have a good understanding of the issues and the solutions as they arise.
Staging
For a large Project, the Project should be broken down into stages with a costing for each. Milestones should be set along the Gant Chart with Deliverables and re-evaluation of progress, budget and business case re-examined at each.
Develop
Physical Design
This is derived from the Logical Design but is a more technical description of the changes. This document can be created before or during the actual development but will invariably evolve during development.
It can be part of or enhancement to the LD and should be used for Testing and Code Review.
Schema Changes
Changes to Table Structures should be automated not made manually. This ensures that changes made in the development environment will reliably flow through to the Test and Production Environments.
I employ the use of DDL or DAO scripts to implement these changes and incorporate this into the app itself. This is executed when a new version is implemented so that it will run reliably in Development, Test and Production with no user intervention.
Versioning
At the heart of controlling schema changes is versioning. The BE database should contain a version number as should the FE User Interface. If, when the FE is launched, the two don’t match then some action needs to be taken.
If the BE is older than the FE then the BE may need changes to its data structure and, in some cases, data updates so the Update Scripts are executed.
Release Notes
The developer should create a list of changes they make to form as set of Release Notes. Commenting in the code should outline the purpose of code and only really needs to go into describing the implementation if there are peculiarities that are not self-evident.
Unit Testing
Developers should test their changes. This should focus on the objects they have changed and any other areas of the software that may be affected.
Test Data, in this case for development, should be refreshed often. In particular if schema changes are made or errors identified or procedures run that have affected data.
Code Review
A code review can be undertaken by another Developer, Tester or Product Manager. The review should, where appropriate, compare the changed code to previous code.
The reviewer should follow through the code with ‘a second set of eyes’ to identify any possible affects that the Developer may not have considered.
The reviewer should find that the commenting is adequate for them to understand the purpose, of the changes, and that the Methodology and Design Patterns are consistent.
Test
There should be no “Us and Them” culture. Testers should work with Developers in an atmosphere of mutual respect. I cannot over emphasise the importance of this concept.
Test Data should be frequently refreshed from the Production database.
Release Notes
Release Notes should have been created by the Developer to form the basis of a test plan. They can be enhanced during testing to provide the Client and Users with a better understanding of changes contained in this release.
Critical Functionality
Even if the changes made by developers should not affect functionality in other areas of the software, Tests should be done on critical functionality. No matter how unlikely, the possibility of Show Stoppers must be eliminated at this stage.
A test plan, that includes Critical Functionality, for the Application as a whole should be created and implemented with every release.
Test Plan
As well as new items identified by the Release Notes the Test Plan should always include Critical Functionality.
A certain level of Risk Assessment may be applied to the scope of this Test Plan but Critical Functionality should be identified and testing of this Critical Functionality should be mandatory for every release.
For new and changed forms the Test Plan should include generic items such as Tab Order and Consistency of Button Placement. For reports, Grouping, Sort Order and Filtering as well as Totals.
Document
User Guide
During Testing, the LD and Release Notes should be enhanced to form or modify a User Guide.
It is not until the User Guide and the Functionality match that a version can be considered ready to release.
The user guide should include a “How To” for each Use Case as well as tips, business rules and notes on functionality that may not be immediately obvious.
Use Case Video
Videos created with Camtasia, or a similar screen video recording application, provide the Users with an efficient way of learning new Use Cases. They also ensure adequate testing of the Use Case. It is not possible to create a ‘Single Take’ Use Case video if the software does not work as intended.
Release Notes
This is a list of changes since the previous release. It started with the BA and was then enhanced by the Developers and Testers.
It should identify to the Users any new or changed functionality.
Release
A release should be authorised by the Product Manager. That is the person with overall responsibility for the Application.
Testers can sometimes become fatigued when the same functionality is returned to the developer several times so “Testing the Testing” will pick up on this.
If the Product Manager finds fault on a regular basis then they need to analyse the process. Does the problem lie with inadequate Specifications, Release Notes or Unit Testing or
So the PM should do a final test to ensure that the functionality meets the spec.
User Acceptance Testing (UAT)
For widely distributed apps as group of Beta Testers may be employed and a system for providing feedback implemented.
For Custom Applications the Client, or their representative, should have their own test environment with an easy method to refresh data from Production.
UAT provides a shared responsibility between Developers and Client which aims to Avoid an ‘Us and Them’ with no fault being assigned to either party.
When provided with a release, it should be first deployed to the UAT environment and, with the assistance of LD and or Release Notes, the User Representative should ensure that all is in order before authorising the release.
UAT should focus on the business processes to ensure they comply with requirements as well as ensuring there are no bugs that may impede users.
UAT should also have an emphasis on the data outcomes. Developers are often not as familiar with the data as the Client who works with it daily and therefore should be better able to identify data that isn’t right.
It is also wise to share the Test Plan, with emphasis on Critical Functionality, with the Client for UAT.
User Observation
Often users employ keyboard/mouse methodology that more technically advanced developers may not even consider and the person responsible for UAT should make themselves familiar with Users by watching over their shoulders to see how they use the software.
It is often not practical for a Developer to go onsite to observe users so it should be emphasised to the client that they should. This helps identify any training need as well as any unanticipated behaviour.
For example, I’ve seen users who, rather than use the Tab key as the Developer intended, use the mouse to move between each control on a form.
At an event registration I’ve seen users enter data for a delegate then print a badge and then, for the next delegate, edit the Name in the current record and print a badge with the same Delegate ID, rather than creating a new record.
Production
We are now ready to release the Version into the Production Environment.
And if we followed the Development Processes we should have a smooth Release.