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

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.

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.

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

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.

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.

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.

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
		Prepare a risk analysis plan defining the process for identifying and resolving risks. Incorporate a risk information data collection form so that once risks are identified each risk can subsequently be quantified, analyzed and resolved
		Prepare a project plan to establish project control by defining the sequence, estimated schedule and responsibilities for implementing each task

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.

The design phase starts with approved requirements as its initial input. Design elements are built for each requirement or requirement set. Design elements describe the software functions and features in detail. It usually includes functional diagrams, screen layouts, business rules, business process diagrams, and an entity-relationship diagram with a full data dictionary.

Design elements describe the software in sufficient detail that the developer can build the software with minimal additional input.

The technical specialists begin to translate the requirements into specific design solutions that will create the systems, features, and functions that are necessary to achieve the business and functional requirements. In the previous requirements definition phase, the focus was on defining specific capabilities desired by and in support of the organization, and its customers and end-users.

In the system design phase the attention turns to defining systems and technical requirements.

This is also the phase where prototyping is likely to occur, as a prototype can serve as a bridge between requirements, design and development. A prototype can be as simple as a mockup of the proposed screen layouts, while a more complex prototype may have selected business rules instantiated as work flows within the application with active fields to capture and show data or information.

Once the project is approved and properly planned, for a fairly large project, requirements gathering, analysis and documentation can take 6 to 8 weeks to complete. In addition, the Design Phase can also take 6 to 8 week to complete, with perhaps a couple of weeks in overlap between the Requirements and Design Phases.

What this means is the first 10 to 12 weeks of the project will be spent on requirements and design related activities before development can start. Add in another 2 to 4 weeks for initial project planning, and development should not be expected to start until 12 to 14 weeks into the project.

Short changing these activities in a Structured, Waterfall approach to development will almost always lead to Scope Creep, as the project team will not have taken sufficient time to fully gather, analysis, document and vet their findings. Scope creep is where the project expands beyond the approved budget and schedules - not a good thing to have happen.

Software features and functions are tested during the test phase, generally in a separate test environment. There are various types of tests (e.g., unit, integration, system, stress), but all test cases are run to verify the correctness and completeness of the software. Successful test execution validates the efficiency and effectiveness of the requirements and design.

The testing phase actually overlaps with requirements, design and development phases. It's critical that the test plan, test scenarios and test cases reflect all the business, end-user, customer, and architecture and design requirements - as defined within the Requirements traceability matrix (RTM). There are many types of testing that may have to be included in the overall test plan.

For example, there is at least one self-proclaimed expert who states there are at least 100 different types of software tests that can be conducted. Over the course of your project management careers you may be exposed to any number of these testing requirements.

The Testing Phase of the SDLC includes the scope of work necessary to analyze and document testing requirements to ensure the solution will implement desired capabilities and perform in accordance with all customer, business, and end-user requirements.

End-users will test and validate conformance of the user interfaces, screens, data fields, data flows, and reports that enable the business processes and/ or user functionality. Technical testers will ensure the underlying hardware, software, network, database, work flow, and security components conform to architectural, design and performance requirements.

Independent Software Quality Assurance (QA) tests will confirm the development team has followed the organization's quality processes and procedures, and that the solution meets established quality metrics. Another independent group will conduct additional tests to verify the solution meets requirements, and validates the system meets the customer's needs.

Defects and bugs that are uncovered during testing will be documented and prioritized. All critical defects will be fixed prior to going into production.

The project monitoring and control phase is where you become the watchdog over the project via data that is collected from project, technical, and frequent status meetings, including the identification of risks, issues and action items that may be identified as the project evolves.

It is important to accurately keep record of changes that have occurred to the baseline over the life of the project. These changes will be very important when you are assessing what modifications to your processes, in conjunction with lessons learned sessions with stakeholders, are required to improve subsequent projects.

Tools that should be utilized and continually updated include:

		The risks, issues and action item status will all be displayed in a project status report to ensure that all stakeholders are continually aware of the status of these items
		A Change Management Log to record those changes
		An Action Item Status containing action items that you will most likely assign and track in your frequent status meetings. This continuous status will afford you the opportunity to keep your foot on the neck of individuals to ensure they complete these action items accurately and in a timely manner
		Record risks in a Risk Management Log capturing the risk, impact on the project, probability of occurrence, timeline, the response and action completed to resolve any risks before they become a threat to completion of the project within budget and schedule
		Issues are one of the most critical aspects accounting for project failure. First of all, utilize a form to collect pertinent data on any potential issue, and then add all issues to a issue management log to ascertain the status of any issue at a glance
		Keeping track of project milestones is another critical factor. Identify all project milestones in a project milestone status form, and continually update same with any changes to that baseline, including the milestone/task status
		Whenever the project Manager or technical managers hold meetings, the minutes of these meetings should be documented in a meeting summary for wide dissemination

This phase provides for production installation and customer acceptance of the software, and requires that all test cases were run to verify the successful software execution, correctness, and completeness.

The Production Turnover/ Deployment Phase of the SDLC includes the scope of work necessary to deploy the final solution into its target production environments plus create guides for installation, system administration, system operations and end-user functionality.

In addition, a detailed plan needs to be created for implementing the solution across the organization. The Production Implementation Plan is especially important when the solution will be deployed across a number of environments that are maintained by different organizations.

In addition, a production turnover approval process is required to ensure the receiving organizations have agreed the solution is operating as intended, that their sustainment organizations are trained and ready to assume responsibility for maintaining the solutions, that their help desk organizations are properly trained and ready to support end-users, and formal acknowledgment that the customers or end-user organizations have assumed full control over the solutions.

This approval may not come until after a warranty period has expired to ensure the sustainment and supporting organizations have had adequate time for knowledge transfer, and that no critical bugs show up in the deployed solution.

This phase includes activities spanning deployment of the solution and production turnover to the support and product sustainment groups. Deployment typically involves installation and configuration of software on centralized servers that can be accessed by end-users across the corporate networks or via Internet access. However, today software is also deployed as a component of standalone products, equipment or systems.

In those cases, deployment will also include the activities to ship the product out to customers and inter-users, plus assembly of the final solution, where required.

The folks who manage the production environment and sustain the deployed solution are not usually the development folks who were maintaining the engineering and test environments or the software during the development and testing phases. In the production turnover phase, various "Guides" are developed and provided to the production support team to help them understand how to install, maintain, backup and recover the system.

The production support staff also have to be trained fully before they can install and manage the new software or system. In addition, for business-critical applications, it's important that every step involved in standing up the new system, migrating production data, testing the new system, and bringing down the old system are planned, approved and managed carefully.

The consequences of a failure at this stage are the shutdown of critical business processes that are enabled by the system, and resulting disruption to the business as a whole. Finally, inter-users must also be trained on both the new system or system enhancements and any changes to the affected business processes.

This phase provides for the business and technical personnel to evaluate how well the project was executed, and to quickly request minor changes once the production baseline has been established.

This final phase of the systems development life cycle is required to achieve the following objectives:

	Effectively transition the solution to the receiving organization
	Ensure the organization has a record of all critical design, development, production support, Infrastructure, and security data on all components of the solution
	Track and ensure knowledge has been effectively transferred to all sustainment and support personnel as well as end-users
	Obtain formal acceptance of the system from the customer
	Capture both project and product oriented lessons learned during the project
	Implement a process to capture new customer's desired enhancements
	Implement an effective Disaster Recovery Program
	Implement a process to retire the solution when the system no longer meets organizational needs

The Sarbanes-Oxley (SOX) Act of 2002 established new accountability standards for corporate boards and auditors. It came as a result of large corporate financial scandals. SOX demanded stringent methodologies in response to major corporate and accounting scandals that cost investors billions of dollars. All publicly-traded companies are now required to submit an annual report of the effectiveness of their internal accounting controls to the SEC. SOX is all about corporate governance and financial disclosure. Provisions of the Sarbanes Oxley Act (SOX) detail criminal and civil penalties for noncompliance.

The Sarbanes-Oxley Act, including COBIT (Control Objectives for Information and Related Technology), provide for a standardized framework for Information Technology (IT) governance, accounting controls, and compliance.

COBIT provides management and business process owners with an Information Technology governance model that helps in understanding and managing the risks associated with IT. COBIT helps bridge the gaps between business risks, control needs, and technical issues. It is a control model to meet the needs of IT governance and ensure the integrity of information and information systems.