The IT Software Development Life Cycle (SDLC) is used in project management to develop (or modify existing) information systems or applications.
Regardless of whether you are looking for information on the SDLC process itself, SDLC documentation, SDLC documents / SDLC forms / SDLC templates, if you can spare about 60 minutes (depending on how in-depth you wish to pursue the subject).
This SDLC tutorial will provide you an invaluable overview of the following topics that hopefully will satisfy your needs:
SDLC Overview
SDLC Phases
SDLC Framework
SDLC Documentation Methodology
SDLC Documentation Process
SDLC Documentation Templates / SDLC Documentation Forms
SDLC Models
The SDLC process provides Information Technology (IT) project managers with the tools to help ensure successful implementation of systems or applications that satisfy strategic and business objectives. SDLC documentation provides a mechanism to ensure that executive leadership, functional managers, and users sign-off on the requirements and implementation of the system.
The process provides management with the capability to design, develop, and implement an intended system and ensure that its completed on time delivery and within budget. The software development life cycle process includes multiple phases from the project viability determined in the Concept / Initiation Phase through the Project Closure / Maintenance Phase of the completed system or application.
Many corporations and government agencies have implemented systems development life cycle (SDLC) frameworks that include methods, processes, workflow, documentation, and tools. These SDLC Frameworks help the organization reduce risks and ensure program and project investments are realized within their budget, scope, time and quality constraints.
Project managers have been taught that there are always two lifecycles at play on any project; these are Project and Product-oriented lifecycles. While project lifecycles facilitates management of the project, product lifecycles guide the design, development, testing, deployment and sustainment of the "deliverables" of the project.
Most Information Technology (IT) project managers are familiar with the term Software Development Life Cycle, which is expressed as the SDLC acronym. A software development life cycle is a product-oriented life cycle that is appropriate when the primary deliverable is software.
However, the term systems development life cycle can be applied more universally, not only across projects where software is the primary deliverable, but other types of IT solutions that involve hardware, network, and storage components, or even business or mechanical systems - where software may only be a small part of the overall solution.
An effective Corporate SDLC will also include defined lifecycles and methods, tools and templates for project management. To be effective, project managers still need to understand how to integrate project, product, and systems development lifecycles to ensure a successful project.
From one organization to another, or even project to project, there will be different needs and influencers promoting one development approach over another. Methods and tools among developers can be an emotional subject. That is not a problem, as there is room for multiple adaptions within the SDLC Framework provided in this course.
Nevertheless, the concepts and approaches provided in this overview are sufficient that they can also be applied without further enhancements.
That is not to imply that tailoring a project is not required. All projects are unique by definition, and two of the most important roles a project manager has during project planning are project integration and tailoring - to ensure the right set of work is planned and executed to achieve the authorized scope of work within the specified constraints of the project (e.g. scope, budget, resources, schedule, quality).
With this in mind, the best SDLC approach for any given project has to be based on the project's constraints, the specific method preferences of the development team, the risk tolerance of executive management, and - perhaps most importantly - access to customers and end-users.
SDLCforms is a collection of “fillable“ IT project management Waterfall and Agile forms and templates developed using the Microsoft Office suite (Word, Excel, PowerPoint, Visio & Project.)
The goals of this SDLC approach are to:
| Deliver quality systems that meet or exceed customer expectations when promised and within cost estimates |
| Provide a framework for developing quality systems using an identifiable, measurable, and repeatable process |
| Establish a project management structure to ensure that each system development project is effectively managed throughout its life cycle |
| Identify and assign the roles and responsibilities of all involved parties, including functional and technical managers, throughout the system development life cycle |
| Ensure that system development requirements are well defined and subsequently satisfied |
The software development life cycle methodology will help to achieve these goals by:
| Establishing appropriate levels of management authority to provide timely direction, coordination, control, review, and approval of the system development project | |
| Ensuring project management accountability | |
| Documenting requirements and maintaining traceability of those requirements throughout the development and implementation process | |
| Ensuring that projects are developed within the current and planned information technology infrastructure | |
| Identifying project risks and issues early and manage them before they become problems |
SDLCforms Waterfall packages range from the Starter Package (8 forms) for the small IT consulting company to the Ultimate Package (100 forms) designed for the enterprise level shop, consisting of every conceivable form to monitor, control and report on application development.
When large computers (mainframes) were first introduced in the 1970s, the Data Processing group (predecessor to Information Technology) generally reported to the head of the Accounting or Finance Department (Controller or VP-Finance) as virtually all computer work was dedicated towards that effort.
The Data Processing group consisted of a small tight group of programmers who could easily communicate with each other with minimal tools to develop software applications. When new work was required, the programmers ventured upstairs to talk to the users, and they retreated to their cubicles to implement the design or minor modification.
Large financial applications were often developed by third party software companies. In-house programmers were taught how to customize and modify this software. Testing of new designs and changes were often an afterthought simply because programmers preferred to write code and detested testing. “We'll catch a problem if the users scream bloody murder.“ (This attitude is just as prevalent today.)
This worked fairly well initially but as computers evolved, numerous new tools were created for application development and other departments within the companies recognized the value of automating their data. Management methodologies were required to develop and modify applications. In lieu of Data Processing, the term Information Technology (IT) became the buzzword reflecting the broad nature of the scope and purpose of the now enriched computer processing.
The initial concepts of Software Development Lifecycles have been around since the 1960s (Elliot & Strachan & Radford (2004)), and some authors would argue an earlier heritage that goes back to the 1940s to 1950s (Birkbeck, University of London. Comparative Development Methodologies).
In the earliest days of computer programming, the only models for developing complex things came out of the construction and manufacturing industries. At the time, it seemed logical that the structured approaches used in those industries would equally apply to developing computing systems. As an example, a developer would first need to understand the customer's requirements, then architect and design a solution, then develop the product, and finally test and deploy or turn-over the new product.
This traditional development process logically progressed in a sequential manner from start to finish, with potentially some overlap for planning and preparation between the major phases of the development effort. Truthfully, at least in this author's opinion, the original programming techniques and early programming languages were so complex and difficult to change that these structured and sequential development approaches made a tremendous amount of sense.
In the last 50 years, many other factors affected the IT culture that demanded stringent methodologies. New laws, such as the Sarbanes-Oxley Act of 2002, were created by Congress in response to major corporate and accounting scandals that cost investors billions of dollars. The legislation established new or enhanced standards for all U. S. public company boards, management, and public accounting firms. Previously, auditors were only interested in examining the company’s books.
Now, they literally are involved in every aspect of Information Technology. IT security and compliance with good practices and COBIT (Control Objectives for Information and related Technologies) are now a very serious and almost dominating factor in all IT decision-making. Many companies now spend considerable monies and resources on IT Governance, the catchword for this effort.
Entirely new fields of expertise in project management are now critical in the successful management of Information Technology that embody knowledge of the driving forces responsible for a successful operation.
Over time, different concepts and ideas have emerged on best practice approaches to developing customer focused software, systems and solutions. All have their strengths and weaknesses, and different SDLC approaches may be appropriate, depending on development team training and preferences, access to customers and end-users, and the degree of control the executive management team desires.
It's unrealistic to expect different organizations will have exactly the same structures, processes, activities, roles and responsibilities, and acceptance criteria for managing their development projects. Nevertheless, there are also a lot of commonalities on the type of work that will occur in each SDLC phase, the artifacts that would be used, and how the work can be described, organized and managed.
Most business systems need to change from time to time, and each new change requirement necessitates executive sponsorship, financial and human resources, IT support, and lifecycle management. By definition, no two projects are alike. In short, corporations and other large entities need Software Development Life Cycle approaches that are flexible enough to be used across all types of business, product, systems and services development needs.
Having said this, it is not expected that “one size fits all“ works when implementing an SDLC Framework.
SDLCforms Waterfall forms consist of the critical project charter, business requirements document, project plan, roles and responsibilities matrix, work breakdown structure (WBS), user acceptance test plan, risk and issues logs, project status report, lessons learned, and dozens more, depending on needs and budgets.
Currently various models are used in the SDLC process. These models include, but are not limited to;
| Waterfall |
| Agile |
| Prototyping |
| Iterative and Incremental |
| Rapid Application Development (RAD) |
| Big Bang |
The best-known and oldest is called the waterfall model. The following is a summary of the phases used in this traditional process:
| 1. | Project Planning Phase |
| 2. | Requirements Definition Phase |
| 3. | Design Phase |
| 4. | Development Phase |
| 5. | Test Phase |
| 6. | Installation & Acceptance Phase |
The process moves to the next step after each step is finished, i.e., the output from a specific phase serves as the initial input for the following phase.
See sample diagram below.
Documentation Consultants has upgraded the traditional waterfall model by providing a more finite definition of the process reflecting today’s concerns.
The following is a summary of the phases used in the Documentation Consultants process:
| 1. | Project Concept / Initiation Phase |
| 2. | Project Planning Phase |
| 3. | System Requirements Phase |
| 4. | System Design & Development Phase |
| 5. | Testing & Acceptance Phase |
| 6. | Project Monitoring And Control Phase |
| 7. | Production Turnover / Deployment Phase |
| 8. | Project Closure / Maintenance Phase |
See sample diagram below.
SDLCforms forms and templates have been developed to a rigorous standard using Microsoft Styles to define the paragraph types. All text and paragraphs are standardized so you can easily make changes to the forms.
The eight phases of the Documentation Consultants‚ SDLC process build upon each other. They take the output from the previous phase, add more information, and produce results that are directly traceable to the previous phases.
The project concept / initiation phase provides the high level determination if the project is worthwhile, via a review of the project charter, business case, cost-benefit analysis, and definition of the team to move the project forward. This phase includes the work that is necessary to determine the feasibility of pursuing defined business strategies as funded programs and projects.
The primary scope of work includes developing a business case, conducting a feasibility study, and performing a cost-benefit analysis. Once those activities are complete, and sponsoring executives have reviewed the analysis and made their final decision to proceed, the project manager will begin to form the project team and review and complete the project initiation checklist.
During this strategic assessment phase, businesses executives will review the mission and past strategies to look for areas of improvement, and possibly assess new market, product or service opportunities. However, there's another level of assessment that must occur before investment decisions can be made on which programs and projects to invest in.
These assessments delve deeper to determine organizational capabilities that are required to support the mission of the entity, and then determine the scope of work required to implement these capabilities, plus the feasibility and cost-benefit of investing in developing those capabilities. Such assessments occur during this phase.
Ideally, the concept phase will be conducted in the fiscal year preceding funding and approval of the actual project. The primary deliverable of this phase is the Business Case. Additional analysis performed during this phase include a cost benefit analysis and a feasibility study.
These artifacts and related analysis are necessary for an executive management team to have the data they need to make sound determinations on the risks, Return On Investment (ROI), and benefits of funding proposed project.
The next activity considered should be the development of a business plan, especially where a new commercial offering is contemplated. The business case helps determine whether there is a unique value proposition that justifies investments in the proposed project idea or initiative, before the organization commits significant time, resources and expenditures.
Assuming the business case analysis indicates there is a unique and viable value proposition, the organization still needs to determine if the project is feasible. Business Analysts conducting a feasibility study assess business and technical information, projected costs and benefits, risks, issues and constraints to determine if the project is practical from an economic and technical perspective.
In addition, where alternative solutions are available, the feasibility study will determine which proposed solution best fits the needs of the organization, and documents recommendations made by the business analysts.
In addition, a detailed cost-benefit analysis may be completed in this phase. The purpose of the cost for-benefit analysis is to provide executives and sponsors with the information and metrics they need determine whether the proposed project has sufficient value to justify commitment of time, resources, and funds.
While the feasibility study includes some cost-benefit information, the project cost/benefit analysis is more detailed and focused solely on economic value of the proposed solution.
This is not to imply that all risks are removed by including a concept phase. To the contrary, until a detailed functional and technical requirements analysis has been completed, during the Requirements and Design Phases, it is truly difficult to assess the total scope of work that may be involved in any given project.
Nevertheless, the deliverables of the concept phase, as described in the previous paragraphs, help ensure that everyone involved with the project understands the parameters under which the project can be judged a success.
From a practical perspective, no executive sponsor or customer is going to open up their checkbooks without some sort of limits imposed in terms of budget, time and resources, and expectations set on the deliverable that are required to make the project a success.
| Form or Template | Description |
|---|---|
| Project Initiation Agenda | Provides initial project agenda for a “kick-off“ meeting, whereby key stakeholders and sponsors, and key business and technology members are identified |
| Project Charter | Provides the business goals, objectives, scope and management direction for starting the project in the Initiation phase. It sets project expectations and processes to ensure agreement on the project approach |
| Business Case Document | Identifies whether there is a potential business value to the proposed project idea or initiative before the organization commits time, resources and expenditures |
| Feasibility Study | A study that uses business and technical information and cost data to determine the economic potential and practicality (i.e., feasibility) of a project |
| Value Proposition Template | Completing the Value Proposition Template will assist an individual/department determine if there is value in a proposed application, system or product, often provided by an outside vendor or contractor, and help in the final decision making process |
| Project or Issue Submission Form | A one-page summary that identifies the proposed project, opportunities, business goal, project scope and issues, and alternatives or recommendations |
| Project Cost - Benefit Analysis | Provides information that will be performed in the project, including business objectives and project description, such as completion criteria, risk assessment, constraints, impact analysis, project success measures, critical success factors, project approach, roles and participants |
| Project Team Definition | This document identifies the business and technical groups and individuals responsible for the initiation, analysis, development, testing, installation and approval of the project |
| Stakeholder Identification List | The Stakeholder Identification List provides the capability to identify the people that could affect or be affected by any project, to analyze stakeholder's expectations and their impact on the project |
| Project Resource Plan | This document provides a centralized source for definition of all resources required for a project, including project team size, required resources, facility needs, resource types and sources, project team organization, resource assumptions, risks and mitigations |
| Concept Of Operations | The Concept of Operations, or CONOPS, is a Capabilities Needs Assessment investigation to gain a Users' and Stakeholders' perspective on a major change initiative. As such, it is both an analysis and a formal document that describes high-level capabilities requirements that have been identified as necessary to achieve the mission of the IT organization, and its subordinate organizations |
| Initiate Project Checklist | This checklist provides sample information to use and verify that major initial project functions and tasks have been completed within the Concept phase in the Project Management Life Cycle |
You can customize the forms (company logo and name, copyright notice, confidentiality statement, etc.), and then optionally add text, paragraphs and tables, as you would with any Microsoft application.
The planning phase establishes an initial view of the intended software product that helps establish the basic project structure, feasibility, risks associated with the project, and describe management and technical methodologies.
This phase is where you will utilize the various tools to provide detailed planning over the life of the project to achieve the following objectives:
| Initially, before any detailed planning commences, the Program Management Office (PMO) must verify that mechanisms (such as accounting and procurement data) are in place to provide the data you will need to accurately collect and display data in the project |
| Establish and document a project organization chart defining the names of the project managers, sponsors, stakeholders, business analysts, testers, and affiliated organizations, so everyone clearly understands who the players are on the project |
| Define the roles and responsibilities of these individuals so it is clear as to everyone's role. Once those roles are defined, create a required approvals matrix of the key project activities |
| Fill in development and project estimating worksheets to determine costs. Review those costs to calculate and verify how much of those monies will be expended in capital or expense, as determined by regulatory taxing agency requirements and internal policies |
| Establish a configuration management plan to manage the project baseline |
| If necessary, prepare a procurement plan for any software, hardware or outside services that will be required in the project |
| Prepare a statement of work defining the business objectives |
| Prepare work breakdown structure (WBS) components in 3 steps: |
| 1. | Provide a WBS activity worksheet to Subject Matter Experts (SMEs)so that they may initially define the scope of work required for each activity and task in the project |
| 2. | Prepare a WBS resource planning template for WBS tasks containing the tasks broken down by estimated hours and % of time required by each skill set. When complete, determination can accurately be made of the total number of hours required of each skill set |
| 3. | Prepare the Work Breakdown Structure delineating the tasks |
| Form or Template | Description |
|---|---|
| Project Management Office (PMO) Checklist | The Project Management Office Checklist provides the capability to determine if the Information Technology (IT) Program Management Office (PMO) has provided the functions and tools to achieve a successful environment in support of both executive management and the project managers responsible for individual IT projects |
| Statement of Work | Provides information that will be performed in the project, including business objectives and project description, such as completion criteria, risk assessment, constraints, impact analysis, project success measures, critical success factors, project approach, roles and participants |
| Project Approval Document | This document formalizes approval for the project by all contributors |
| Cost Estimating Worksheet | This Excel spreadsheet provides the opportunity to estimate and budget various IT costs |
| Development Estimating Worksheet | This Excel spreadsheet provides the opportunity to estimate development costs for prototyping, user interfaces / reports / databases / tables, objects and integration/jobs |
| Project Capital vs. Expense Costs | This Excel spreadsheet provides the opportunity to estimate various capital and expense costs for a project including IT resources, external professional services, hardware, communications, software licenses and supplies |
| Configuration Management Plan | The Configuration Management (CM) Plan informs project stakeholders about how CM is used to manage the project, what tools are used, and how they will be implemented to achieve project success |
| Risk Information Data Collection Form | During the course of a project, potential risks can be identified by a myriad of sources. The Project Risk Information Data Collection Form's purpose is to provide a vehicle for capturing detail information on any of those risks for analysis and evaluation |
| Risk Analysis Plan | Provides a medium to record a risk analysis of the project, and is used to keep track of potential risks that may jeopardize the project's success or completion date |
| Procurement Plan | Provides procedures and information to acquire hardware, software, vendors, or other needed items. It assists in determining what to acquire, when and how |
| Project Organization Chart | Know who the key "decision makers" are on your project via a Visio graphical diagram naming the PMO personnel, sponsors, stakeholders and business analysts including the collaborating organizations such as infrastructure, design, quality assurance, etc. |
| Roles and Responsibilities Matrix | Displays key project activities and details the responsibilities for each individual or role across every functional department |
| Required Approvals Matrix | Provides a matrix of key project activities (e.g., functions, tasks, documents or phases), and who is responsible for approving them |
| Activity Worksheet in Work Breakdown Structure Dictionary Form | The WBS Activity Worksheet is made available to Subject Matter Experts (SMEs) to define the scope of work required for each activity and task within the work breakdown structure. For the entries made in this worksheet, accurate and activity and task descriptions can be compiled and tracked for variance during the course of a project |
| Work Breakdown Structure Resource Planning Template | The Work Breakdown Structure Resource Planning Template provides a matrix of WBS tasks with the estimated duration of each task in hours with % of time required by the various skill sets to contribute to the tasks, summarized by total hours required for those skill sets |
| Work Breakdown Structure | Provides a work breakdown structure table that includes the tasks to be completed within a small project in lieu of a more formal Project Plan |
| COBIT Checklist and Review | The Sarbanes-Oxley Act, including COBIT Checklist and Review, provides for a standardized structure for Information Technology (IT) governance, accounting controls and compliance. COBIT Control Objectives focus on specific, detailed objectives related with each IT process |
| Request For Information | A Request for Information (RFI) is used to solicit information from qualified vendors on the products and services they recommend addressing your business problem or functionality |
| Root Cause Analysis | Identifies the root cause of a problem and the recommendations for a solution, including the date the problem was encountered, summary of the problem, duration of the problem, impacted business units and applications, and the recommended action and follow-up |
| Project Plan | This MS Project document establishes both project execution and project control. It shows when and how a project's objectives are to be achieved by depicting the status of the major products, milestones, activities and resources required on the project |
| List of Opportunities Summary | Provides a master list communication tool that summarizes project opportunities, including opportunity description, priority, target date for delivery and owner |
Waterfall packages can be purchased at extremely low cost, especially beneficial in that you can buy the Ultimate Package of 100 forms at $2.49 per form. Agile packages can be purchased at $4.95 per form.
This phase starts with gathering the high-level requirements and refining them according to project goals.
These requirements define the major functions of the intended application or system. Major functions include critical processes to be managed, including mission critical inputs, outputs, and reports.
The Requirements Definition Phase of the SDLC includes the scope of work necessary to define, analyze and document business and end-user requirements. When developing under a structured type of SDLC, requirements may be further refined within Functional and Non-Functional Requirements documents.
System requirements definition or analysis phase requires deeper thought, when compared to the feasibility studies and cost benefit analysis efforts described in the concept phase, in terms of understanding the capabilities, features and functions end-users will need to support the business enterprise.
The requirements phase is typically divided into two distinct activities: requirements gathering and requirements analysis. In addition, depending on the type of product under development, these two activities are required across business, end-user, functional, and technical needs.
But there's much more to requirements than these rather straightforward activities. Often times, in order to derive the needs of the organization it's useful to first document how things are currently done today. This type of requirements analysis is referred to as the current state or "as is" assessment. The as is assessment helps the business analyst not only document how things are currently done, but also delve deeper into understanding how and where things are not working very well.
Next, the business analyst(s) will work with stakeholders, end-users and customers to-determine what capabilities they require to be more effective in the work or activities they perform, and will therefore seek feedback on how things could be done better in the future. This type of analysis provides a description of the future state, and is often described as a "to be" assessment. This type of analysis can also be called a capabilities needs assessment.
Once the as is assessment and to be analysis are complete, the business analyst will turn their attention to developing a "gap analysis." This is an important step that determines the magnitude of change that is required to move the "system" from how things are done today to how they need to be done in the future. Here we are intensely using the term the system again because the scope of change management any or all the enablers of the business.
As an example, a new business requirements may drive changes in the software that facilitates the business process. However, the software itself can drive changes to the business process, either by providing performance support to the end-users, making the process more efficient, adding new capabilities, and/or providing information more readily than was available before.
The business requirements for the implementation of new features and functions may require changes to the underlying IT infrastructure, including servers, networks, storage devices, etc. Since we are changing business processes the skills and roles of our people may have to change. And, of course, it's possible that new equipment and technologies are also involved to implement the new business requirements.
In short, what may have initially seemed as a relatively simple business requirement can evolve into quite a complex system indeed.
Professional project managers will see this kind of complex project dynamics if they spent any time in IT at all. As a real-world example, this author has managed a project where there were eight seemingly simple business sponsor requirements (e.g. Customer) - each requirement described in one or two paragraphs - drove no less than 70 work orders of new features and functions that had to be implemented in the existing software.
The complexity of the system led to evaluation and procurement of new software testing and performance tools, as manual methods became increasingly slow and expensive. New servers had to be procured and deployed, and no less than four business processes and their related procedures had to be updated to accommodate the new business changes.
And of course, the systems documentation and user guides also had to be updated, plus new training aids and wikis to support the overall deployment had to be developed and deployed.
| Form or Template | Description |
|---|---|
| Managing Scope and Requirements | Provides a checklist of numerous topics to help manage the scope and requirements for a project. The list works to gain customer agreement and scope creep that pushes out project completion and project costs |
| Business Requirements Document | Defines the general business requirements for the project. Identifies business and end user requirements, problems or issues, project information, process information, and training and documentation requirements |
| Business Requirements Presentation To Stakeholders | This document provides a PowerPoint presentation "shell" to incorporate and review the project business requirements with the stakeholders and business units sponsoring the project |
| Functional Requirements Document | Defines the functional requirements for the project including the different levels of business and end user requirements, and the functional areas of the business processes |
| Software Architecture Plan | This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system |
| Use Case Template | Defines the business requirements for the project using a use case methodology, and includes problems or issues to be resolved, objectives or goals, solution to be implemented, and why the solution is being implemented |
| Requirements Inspection Checklist | Provides a sample quality assurance document to verify at a glance that major requirements functions and tasks have been completed |
| Requirements Traceability Matrix | A method that is used to verify the association between the requirements shown in the Requirements / Specifications and other project documents, including design and testing documentation. Testing ensures that the requirements have been implemented correctly based on the design and Requirements Traceability Matrix |
| Requirements Changes Impact Analysis | Provides detailed information to perform an impact analysis of requirement changes, including proposed change implications, system components and elements affected by the change, and estimated schedule and cost impacts |
| Training Plan | Supports the use and maintenance of the specific system or application, and includes information about training courses and the tools and techniques that will be used |
| Service Level Agreement Template | Formalizes an arrangement between your company and the client to deliver specific support services, at specific levels of support, and at an agreed-upon cost |
