The Software Development Life Cycle (SDLC) also, sometimes referred to as the Systems Development Life Cycle or Applications Development Life Cycle is defined as:
A term used in systems engineering, information systems, software engineering or application development to describe a process for planning, creating, testing, and deploying an information system, process or application.
We will define the actors, stages and purpose of the SDLC components. Every instance of the SDLC process is unique to the environment that employs this problem solving and project management process. Each SDLC process does have standard principals determining the style and type of SDLC methodology. These words should serve as a guide in defining SDLC roles and responsibilities of business 'actors'. These 'actors' are representations of business work functions. Please do not consider these as people, groups or departments at this stage, rather just functions of the SDLC process. Outlined below is the customized Leale Solutions implementation of the 'V-Model SDLC'. The 'V-Model' is an adaptation or extension of the more traditional 'Waterfall SDLC' model. The 'V-Model' demonstrates the relationships between each phase of the SDLC and its associated phase of testing. The horizontal and vertical axes represent time or project completeness and level of abstraction. Herein we also define the stages of the V-Model SDLC methodology we have adopted here at Leale Solutions.
There may be some terms which are foreign to you so we want to define them ahead of time. Below we have defined terms which represent actors, components and functions that are vital elements of the SDLC process.
SDLC - A term used in systems engineering, information systems, software engineering or application development to describe a process for planning, creating, testing, and deploying an information system, process or application.
Business Analyst (BA) - This role is responsible for analyzing, documenting and communicating the urgency, scope, scale and 'mood' of business requests and projects as well as analytics, status and reporting of business and projects. BAs also assess business models and their integration with technology.
Project Management Office (PMO) - This 'grouping', often abbreviated to PMO, is a group or department within the enterprise that defines and maintains standards for project management. The PMO is responsible for the repetitive, standardized functions and processes in the execution of business projects. The PMO is the primary source of documentation, leadership, guidance, metrics and reporting related to projects and project management enterprise wide.
Business Project Manager - This role is responsible for managing the accomplishment of the stated business project objectives. Key business project management responsibilities include creating clear and attainable project objectives (goals) from interviews with executives and business users, building the project requirements, and managing cost, time and scope of the project, as well as the quality of the results. A Business Project Manager is often the representative of business users and their desires.
Technical Project Manager - As with the Business Project Manager, this role is responsible for managing the accomplishment of the stated project objectives. Key project management responsibilities include creating attainable goals from functional requirements documentation and interviews, building the technical project requirements and documentation with the development staff, and managing the constraints of the technical project management including time, scope, and quality. A Technical Project Manager is often associated directly with IT and is a liaison between business users the PMO and IT resources.
Application / IT Development - This role is responsible for interpretation of the technical requirements and the construction, development, testing and quality of the code developed to produce the solution detailed in the technical requirements.
Technical Testing / QA - This role is responsible for the testing, verification and validation of required functionality and purpose of code and code modules (Unit Testing) and larger scope functions which use more than one component or system (Workflow Testing) and integrations with existing applications and systems (Regression and Systems Testing).
Business Department Testing / User Acceptance Testing (UAT) - This role is responsible for the testing, verification and validation of required functionality from a business user paradigm.
Concept Documentation - Conceptual documentation is a tool used by Business Analyst and Business Project Managers to express high level business ideas and concepts to business executives and decision makers in an effort to gain acceptance and support from the executive / business decision person or group. This documentation is used by the executive / business decision person or group to determine the validity of the business need and justify the resources to take the next step, which is, Business / Functional Requirements Documentation.
Business / Functional Requirements Documentation - This documentation is a tool of the Business Analyst and Business Project Managers which is used to define the goals of a project, product or system from a detailed business user viewpoint. This documentation should determine and define any gaps in understanding and functionality between 'current' and 'ideal' state. This documentation should contain a roadmap outlining the necessary steps to accomplish the goals outlined within. This documentation is critical to support the next stage, technical requirements.
Technical Requirements Documentation - This documentation is a tool used by Technical Project Managers and Development staff to accurately define the detailed technical blueprint that will be followed to build the solution(s) which will result in the 'ideal' state as mutually decided upon in the SDLC process.
Traceability Matrix - This is a tool contained within the Technical Requirements Documentation used by the Technical Project Manager, Business Project Manager and Development staff to ensure that each individual business requirement (detailed in the Business / Functional Requirements Documentation) is directly related to a single or series of technical requirements (as documented in the Technical Requirements Documentation) which ensures that each business requirement will be fulfilled when the application development steps are complete and tested.
Unit Testing - Unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control or test data, usage code or procedures, and operating procedures are tested to determine if they are fit for use, are error free and perform the appropriate actions or results.
Regression Testing - Regression testing is software testing that seeks to uncover new software bugs, or regressions, in preexisting applications or systems after new changes such as enhancements, patches, configuration changes or upgrades, have been made to them. The purpose of regression testing is to ensure that new changes do not introduce new faults, software bugs or cause unintended results.
To reiterate, each instance of a working SDLC is slightly different while adhering to the same principals. The purpose of the SDLC is to provide a repeatable framework for managing business projects especially when the business requirements dictate that a technology implementation or solution is needed. The beauty of the SDLC process is the flexible structure it brings to business challenges. As a general rule of thumb, from a process and compliance perspective, the larger the project, the tighter adherence to the SDLC process. The stages and percentages per stage displayed below allow for variances from project to project. These variances are fluid and allow for increase or decrease depending on the conditions, severity and importance of the project. Resource allocation is a key element which is displayed in an 'ideal' scenario below.
To begin this process, we need executive / business sponsorship. The tasks that lay ahead require resources to document, scope and execute. This first stage is dedicated to developing a common language and documentation in an attempt to receive allocation of resources to continue. The majority of responsibility falls on the business analyst and business project manager(s). IT has minimal interaction.
During this stage, requirements from a business user perspective are discussed and documented. This is a formal process involving interviews, reconciling requests and new additions. This documentation is reviewed and approved as complete and accurate by the business sponsor prior to the next phase initiation. This is vital as these requirements form the foundation of understanding that the technology implementation will be built upon. Again, the majority of responsibility falls on the business analyst and business project manager(s). IT has minimal interaction.
Here begins the 'idea' sessions where the business requirements documentation is reviewed with IT and the ideas of possible solutions are sewn, and then formally documented. We call these candidate solutions. In order to ensure the requirements that were relayed to IT are valid, and complete enough to produce a candidate solution, these ideas are documented and presented to the business sponsor for verification. The candidate solutions include high level estimations of total work effort and 'time to market' capabilities. Ie. 2000 man hours of work effort and at current capacity, the project can be completed in roughly 5 months. It is the responsibility of the business sponsor to choose (if multiple candidate solutions are presented), accept and sign off on the acceptance of the candidate solution. During this phase the technical project managers work hand in hand with the BAs and business project managers to exchange ideas and facilitate the 'technology creative process'. In no way does this mean that the goal it to produce the 'coolest' solution. This means that the project managers and BAs work together to remove barriers so that IT can work as efficiently as possible to produce creative ideas.
Iterative Development Cycle Begins - It is worth noting that even as detailed and process oriented as the SDLC is, there are almost always additions, exceptions and mistakes. Stages 4, 5 and 6 often work as a self-contained iterative cycle wherein interpretation of requirements, coding and unit testing are performed in more than one cycle to get the desired effect and result. The iterative nature of this problem solving process is what brings the SDLC to life. This allows for bending and flexing. Change is inevitable and these allowances provide a vehicle to embrace changes along the way.
At this stage, technical project managers work closely with the development staff to identify and document the technical requirements of the chosen candidate solution. Here, technical project manager(s) will employ a traceability matrix. The traceability matrix is documentation that ensures the relationship between business / functional requirements map directly to a technical requirement. This is vital to guarantee fulfillment of all items deemed 'in scope'. The traceability matrix also provides easy access to each detailed technical requirement for work effort estimation purposes. The detailed and aggregate of the work estimate details are used to show the scope and delivery window of the entire project. The majority of responsibility at this stage is spent by the technical project manager and IT development staff documenting and estimating the requirements and scope.
Here is where the brick laying actually happens. The technical project manager and IT development staff absorb all of the work here.
During this stage, the technical project manager is working with the IT development staff and technical tester / QA resources to ensure that the individual work functions are producing the desired result. It is common to involve BAs, business project managers and even UAT resources at this time; however, the bulk of the work effort resides with the IT development staff, technical project manager and technical testing team.
Iterative Cycle Ends - The iterative development cycle is generally limited to the interpretation of technical requirements, application development and unit testing stages of the SDLC but is not limited to these stages. At times the cycle can reach as far back as functional requirements and as far forward as UAT testing. The flexibility of the SDLC makes this possible. However, the process is most efficient by keeping these iterations as short and small in scope as possible.
At this stage there is generally 'real' code to test. This comes in the form of a required business workflow or phased business implementations. Here the technical testing resources employ a fresh set of eyes in the form of the business project managers, and UAT resources. The majority of the work effort here is split between the technical testers, BAs and the business project manager(s).
Once at this stage, the UAT resources put the solution through the paces. Here they absorb the largest work effort. BAs and business project managers are involved through this process to report defects, test and assists as well.
This is where we begin this process over again if necessary. The larger the scope of changes, the tighter adherence to this process should be considered.
Our goal was to outline our adopted version of the SDLC with emphasis on the roles and responsibilities during the SDLC process. This is a guide to outline an ideal state of SDLC process as we have adopted it here at Leale Solutions. To reiterate, each instance of a working SDLC is slightly different while adhering to the same principals. The purpose of the SDLC is to provide a repeatable framework for managing business projects especially when the business requirements dictate that a technology implementation or solution is needed. The beauty of the SDLC process is the flexible structure it brings to business challenges. As a general rule of thumb, from a process and compliance perspective, the larger the project, the tighter adherence to the SDLC process. We openly admit and accept that during the SDLC process there are variances. These variances are fluid and allow for increase or decrease depending on the conditions, severity and importance of the project.
As a partner that understands the challenges which come with projects of all sizes, our recipe for success is the Software Development Life Cycle. We are continuously challenging our own process, pushing to sharpen the saw and improve through clear communication, documentation and by following industry standards and best practices. Embracing a SDLC philosophy to scientifically address business challenges in the same way repeatedly, is the key to project success regardless of the size and scope.