|
|
|
|
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 |
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 finance and sales.
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 respond violently.“ (This attitude is just as prevalent today.)
This worked fairly well initially when programmers need only worry about their few programming language choices and a database repository. 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.
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.
Some form of documentation of the client's business requirements, the architecture of the solution and tools for the project managers became mandatory.
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 became critical in the successful management of Information Technology that embody knowledge of the driving forces responsible for a successful operation.
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.
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.
Packages of forms for both Waterfall and Agile methodologies are available for purchase.
|
Waterfall Packages |
||
| Package Name | # Forms | Description |
|---|---|---|
|
8 | Provides a functional start to SDLC process best suited for organizations that have never used any methodology. |
|
15 | Provides a robust baseline for small IT and consulting/development shops. |
|
30 | A perfect fit for organizations that want to formalize their often "cobbled together" SDLC process. |
|
60 | For midrange and smaller enterprise-IT shops that desire a major upgrade to its development and documentation methodologies. |
|
100 | Provides a totally integrated SDLC solution for enterprise-IT organizations where stringent controls are desired at every step in the development process. |
|
Agile Packages |
||
| Package Name | # Forms | Description |
|---|---|---|
|
10 | Designed for those organizations to provide the tools you will need to accomplish your planning efforts in the Agile Envision and Speculate phases. |
|
20 | Provides the tools you will need to cover the entire spectrum of the Agile methodology, including the Envision, Speculate, Explore and Adapt phases. |
|
Individual Waterfall Forms |
||
| Form Name | # Pages | Description |
|---|---|---|
| Project Concept/Initiation Phase | ||
| Project Initiation Agenda | 1 | Provides initial project agenda for a "kick-off" meeting, whereby key stakeholders and sponsors, and key business and technology members are identified. |
| Project Charter | 1 | 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 | 9 | 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 | 8 | 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 | 1 | Completing the Value Proposition Template will assist an individual/department determine if there is value in a proposed application, system or product. |
| Project or Issue Submission Form | 1 | A one-page summary that identifies the proposed project, opportunities, business goal, project scope and issues, and alternatives or recommendations. |
| Project Cost-Benefit Analysis | 9 | Provides information that will be performed in the project, including business objectives and project description. |
| Project Team Definition | 5 | Identifies the business and technical groups and individuals responsible for the initiation, analysis, development, testing, installation and approval of the project. |
| Stakeholder Identification List | 6 | Stakeholder identification includes the processes required to identify the people, groups and organizations that could affect or be affected by the project. |
| On-Boarding Checklist | 4 | This template provides capabilities to document a person being hired by your company. |
| Initiate Project Checklist | 8 | This checklist provides sample information to use and verify that major initial project functions and tasks have been completed within the Concept / Initiation phase in the Project Management Life Cycle. |
| Project Resource Plan | 9 | This document provides a centralized source for definition of all resources required for a project. |
| Concept of Operations (CONOPS) | 33 | The Concept of Operations, or CONOPS, is a Capabilities Needs Assessment investigation to gain a Users' and Stakeholders' perspective on a major change initiative. |
| Project Management Plan Template | 24 | The Project Management Plan describes the project management methods and tools employed within a project; which are often incorporated as a set of project management sub plans. |
|
Project Planning Phase |
||
| Project Management Office (PMO) Checklist | 10 | 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 | 14 | Provides information that will be performed in the project, including business objectives and project description, |
| Project Approval Document | 2 | This document formalizes approval for the project by all contributors. |
| Cost Estimating Worksheet | 2 | This Excel spreadsheet provides the opportunity to estimate and budget various IT costs. |
| Development Estimating Worksheet | 4 | 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 | 1 | This Excel spreadsheet provides the opportunity to estimate various capital and expense costs for a project. |
| Configuration Management Plan | 11 | 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 | 2 | 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 | 6 | 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 | 9 | Provides procedures and information to acquire hardware, software, vendors, or other needed items. It assists in determining what to acquire, when, and how. |
| Quality Plan | 10 | Managing project quality requires an approved quality plan encompassing three major quality processes identified below. The quality plan is developed and approved during the project planning phase to confirm major deliverables/milestones acceptance criteria and to manage approved project processes. |
| Project Organization Chart | 1 | Know who the key "players" are on your project via a Visio graphical diagram identifying the PMO personnel, sponsors, stakeholders, and business analysts including the collaborating organizations such as Infrastructure, design, quality assurance, etc. |
| Roles and Responsibilities Matrix | 10 | Displays key project activities and details the responsibilities for each individual or role across every functional department. |
| Required Approvals Matrix | 8 | 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 | 1 | 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. |
| Work Breakdown Structure Resource Planning Template | 8 | 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. |
| Work Breakdown Structure | 1 | 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 | 21 | The Sarbanes-Oxley Act, including COBIT Checklist and Review, provides for a standardized structure for Information Technology (IT) governance, accounting controls and compliance. |
| Request for Information | 23 | 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 | 1 | Identifies the root cause of a problem and the recommendations for a solution. |
| Project Schedule Plan | 6 | 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. |
| Project Manager's Weekly Checklist | 3 | This document provides a weekly checklist for IT project managers to remind them of critical tasks to keep the project running smoothly. |
| List of Opportunities Summary | 1 | Provides a master list communication tool that summarizes project opportunities, including opportunity description, priority, target date for delivery, and owner. |
|
System Requirements Phase |
||
| Managing Scope and Requirements | 8 | 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. |
| Simple Approach to Requirements and Systems Analysis | 24 | The intent of the document is to provide a simplified version of the requirements and systems analysis of the project. |
| Business Requirements Document | 16 | 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 | 14 | 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 | 12 | 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 | 7 | This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. |
| Use Case Template | 21 | Defines the business requirements for the project using a use case methodology, and includes problems or issues to be resolved, objectives or goals, solution(s) to be implemented, and why the solution is being implemented. |
| Requirements Inspection Checklist | 7 | Provides a sample quality assurance document to verify at a glance that major requirement functions and tasks have been completed. |
| Requirements Traceability Matrix | 10 | A method that is used to verify the association between the requirements shown in the Requirements / Specifications and other project documents. |
| Requirements Changes Impact Analysis | 11 | 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 | 8 | 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. |
| Training Request | 2 | This document provides the ability to request training for a specific purpose. |
| Service Level Agreement Template | 19 | 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. |
|
System Design Phase |
||
| System Requirements Specifications | 12 | Provides more details to the project's high-level requirements, including detailed information so that the system can be built to satisfy the system requirements and quality. |
| Analysis and Design Document | 18 | Provides detailed information to perform an analysis and design of a system, including topics of current and future software architecture processes, interfaces, data flow, infrastructures, components, integration, and security. |
| Application Development Project List | 9 | Provides a list of 50+ tasks that need to be considered within an application development project. |
| Technical Requirements Document | 7 | Defines the technical requirements for the project to a sufficient level of detail to develop a system design and to allow testers to test the system. |
| Database Design Document | 13 | The Database Design Document maps the logical data model to the target database management system with consideration to the system's performance requirements. |
| Website Planning Checklist | 14 | Provides a checklist of numerous topics to consider when designing and developing a new website. |
| User Interface Design Template | 13 | Provides a template for structured approach to fill in detailed business and technical information for design and development of a user interface (i.e., a screen). |
| Report Design Template | 10 | Provides numerous topics to fill in detailed business and technical information for the design and development of a report. |
| Code Review Checklist | 9 | The Code Review Checklist provides a company guideline for checking code including pass/fail parameters and recording any comments when the test fails. |
| Conversion Plan | 12 | Describes the strategies involved in the conversion of a system or application. |
|
Testing Phase |
||
| Documentation QA Checklist Template | 6 | Provides the capability to perform a documentation quality assurance review prior to delivery and implementation. |
| Building Test Scenarios | 10 | Testing scenarios are hypothetical stories used to assist an individual to think through a complex problem or system. |
| Test Plan | 12 | This document provides a central artifact to govern the strategic approach of the test effort; it defines the general approach to be employed when testing the software and when evaluating the results of that testing. |
| System Quality Assurance Checklist | 22 | Verifies that various project management, methodology, testing, configuration management, and documentation and records management principles and standards have been applied to a project. |
| Website Testing Summary Template | 12 | Provides summary information and checklists for web quality assurance testing |
| System Test Plan | 13 | Documents all system requirements denoted in the requirements, specifications, and design documentation to plan and execute unit, system, and integration tests that ensure a high level of compliance. |
| User Acceptance Test Plan (UAT) | 17 | Provides management an overview of the system, applications, functions, and features that are to be tested in the UAT process. |
| Testing Bug Report | 1 | This report provides the ability to record details about an individual testing bug detected during unit, system, integration and user acceptance testing. |
| Testing Bug List | 1 | This list provides a status of all bugs detected during unit, system, integration and user acceptance testing. |
| Regression Testing Plan | 12 | Provides general information about systems or applications that require regression testing, including why testing is required, functional business areas affected and testing timeline. |
| Project Acceptance Document | 1 | The document formalizes acceptance of the project, and describes the products and services the customer received. |
|
Project Monitoring and Control Phase |
||
| Change Management Log | 1 | This document is used to record changes to the baseline, including the change type, priority, the owner's name, date submitted, if escalation is required, the date it was approved, and the action / resolution of the change. |
| Action Item Status | 1 | This document provides that status of all project action items, including the item number and description, the assigned, due and resolved dates, the owner, priority and a status of the item. |
| Risk Managment Register | 1 | The Risk Management Log is a management tool that identifies, assesses, and records recommended actions that management must take to alleviate the risk potential down to acceptable levels. |
| Issue Identification and Resolution | 6 | This document is used to individually identify each issue that may impact a project, and identify who created and resolved the issue, the type of issue, potential alternatives and recommendations. |
| Issues Management Log | 1 | The Issue Management Log provides the ability to initially identify the issue, how the issue is assessed by the project team, and what the management responses / actions are to resolve the issue. |
| Project Milestone Status Form | 1 | This document provides a vehicle for capturing the latest status of due date, completion date, and the milestone/task status (in-process, completed or delinquent), milestones, goals, or tasks including the milestone/task description, person responsible for that milestone/task. |
| COBIT Objectives and Audit Activities Report | 5 | This document provides a tracking vehicle for defining and statusing COBIT (Control Objectives for Information and Related Technology) objectives and activities for auditing purposes. |
| Project Status Report | 4 | Summarizes the project status, including project activity, information about the project, planned activities for next period, and deliverable description and status; management changes, risks and issues status. |
| Meeting Summary | 1 | Documents the meeting date and time, participants, meeting minutes, conclusions and action items status. |
|
Production Turnover /Deployment Phase |
||
| Process Guide | 9 | Provides information about system, application or process instructions, procedures, and process flows, which are shown in step-by-step text format as well as visual graphics. |
| Installation Planning Guide | 16 | Provides information for the installation of the system, application or data, including installation strategy, planning and risk factors, and security. |
| Software User Guide | 17 | Provides training or reference information for using the system, product, application or data. The Guide explains the major components, benefits, access information, and navigation instructions. |
| System Administration Guide | 11 | Provides procedures and information to administer and maintain a system, product or application, and includes an overview, data assets, processing, server and database administration, and backup instructions. |
| Operations Guide | 14 | Provides procedures and information to run a system, product or application. It includes scheduled operations, unique tasks, troubleshooting, auditing, and best practices. |
| Production Implementation Plan | 9 | Provides the last step in formal approval and implementation of the project. It identifies the objectives, impacted devices, production delivery steps, technical support information, hardware and software components, testing and acceptance, rollback/contingency plan, and required training and documentation. |
| Production Turnover Approval | 6 | Provides a process that ensures changes to the production environment are planned, approved, tested, executed, and reviewed in a systematic efficient and controlled manner. |
|
Project Closure / Maintenance Phase |
||
| Lessons Learned Template | 4 | The Lessons Learned Template provides an opportunity for reflection after a project has been completed. It is highly beneficial to record what worked well with the project and where improvements can be made. |
| Transition Out Plan | 9 | The Transition Out Plan is used to describe how project deliverables will be brought to full operational status, and integrated into ongoing operations and subsequently maintained. |
| Post Project Survey Questionnaire | 6 | During the Project Closure / Maintenance phase of a project, the Project Management Office (PMO) conducts a survey to gather feedback on the project to improve performance on subsequent projects. This survey will assist the PMO in gathering project sponsors and team member's thoughts on the project. |
| Post Project Review | 8 | Upon completion of a project, good practice is to assess how you did on the project, in conjunction with a Lesson Learned Report. |
| Modification / Change Control Request | 6 | Used to review system / application change requests to evaluate and approve technically sound and secure "changes" to the production environment and to limit potential impact to business capabilities and/or IT operational capacity, architecture, infrastructure, compliance, and schedules. |
| Installation Back-out Rollback Plan Template | 12 | This template identifies specific instructions for going back to a previous application version. |
| Disaster Recovery Plan Information | 25 | Documents a disaster recovery plan as part of an overall contingency plan to complete that restoration task and keep the company running. |
| Certificate of Compliance and Acceptance | 1 | Deliverables provided by outside contractors and developers in accordance with a task order or purchase order, but can be used in any situation where you wish to review the status of deliverables by internal organizations on a given project. |
| Request for New Application/Enhancement | 1 | This document permits a business unit, other departments or auditors to initiate the process of requesting a new application or an enhancement to an existing application. |
| Product Retirement Plan | 10 | Provides detailed instructions for retirement of a system or application, and describes how the hardware, software, data, and documentation associated with the application will be detached from production and archived or migrated. |
| Off-Boarding Checklist | 4 | This template provides capabilities to document a person retiring, transferring or being terminated from your company. |
| Global Application Support Summary | 30 | The Global Application Support Summary provides a vehicle to record critical design, development, production support, Infrastructure, and security data on all applications. |
| Developer Knowledge Transfer Report | 14 | The Developer Knowledge Transfer Report provides a vehicle for conveying details about a system or application for production support developers. |
|
Individual Agile Forms
|
||
| Form Name | # Pages | Description |
|---|---|---|
| Project Charter | 1 | The Project Charter is developed early in the project lifecycle and clearly sets the stage by aligning the team and stakeholders by setting goals and expectations. |
| Vision Statement | 1 | The Vision Statement identifies a future state for the product when the product reaches completion. |
| Risk Management Register | 1 | The Risk Management Register provides a vehicle for recording potential risks on a project. |
| Project Data Sheet | 1 | The Project Data Sheet (PDS) is in terms of scope, schedule and resources, how a project will deliver on a Vision Statement, and is a single summary of key business and quality objectives, product capabilities, and project management information. |
| Theme / Epic Structure (Excel) | 1 | The Theme / Epic Structure provides the ability to graphically identify a hierarchy of an optional high level theme and /or epic and depicts the user stories within that hierarchy. |
| Theme / Epic Structure (Visio) | 1 | This is the optional Visio version of the Theme / Epic Structure (see Theme / Epic Structure (Excel)) to provide ease of working with "drag and drop" objects to update the document. |
| Planning Poker Companion | 2 | The Planning Poker Companion is a method for estimating story points for user stories accomplished by entering values provided by the Agile Team with four optional methods for capturing and displaying results. |
| Story Points Allocation | 1 | Story Points Allocation provides a vehicle for recording story points that have been allocated for each user story. |
| Release Plan | 1 | A Release Plan communicates, to the level of accuracy that is reasonable, when the release will be available, what features will be in the release, and what user stories are included in the release. |
| Sprint Planning & Meeting Schedule | 1 | The Sprint Planning & Meeting Schedule provides a vehicle for recording a status of sprints and associated tasks for a given period. |
| Sprint Backlog Status (Excel) | 1 | Generally, the Sprint Backlog Status as an output of the Sprint Planning & Meeting Schedule to define the work that remains on the project. |
| Sprint Backlog Status (Visio) | 1 | Generally, the Sprint Backlog Status as an output of the Sprint Planning & Meeting Schedule to define the work that remains on the project. |
| 14-Day Sprint Backlog | 1 | The 14-day Sprint Backlog contains the output of a sprint planning meeting. |
| 30-Day Sprint Backlog | 1 | The 30-day Sprint Backlog contains the output of a sprint planning meeting. |
| Product Backlog Grooming | 1 | Product Backlog Grooming is a meeting that is held near the end of one sprint to ensure the backlog is ready for the next sprint. |
| Iteration Retrospective | 1 | An Agile retrospective is a meeting that's held at the end of an iteration. |
| Story Completion Checklist | 1 | The Story Completion Checklist contains the story name, activity, work products and status. |
| Sprint Burn-Up Chart | 1 | A Sprint Burn-Up Chart is a graph that shows the progress of work toward a goal line associated with a value on the vertical axis. |
| Sprint Burndown Chart | 1 | The Sprint Burndown Chart displays the remaining effort for a given period of time. Work remaining is the Y axis and working days is the X axis. |
| Sprint Velocity Chart | 1 | The Velocity Chart shows the amount of value delivered in each sprint, enabling you to predict the amount of work the team can get done in future sprints. |
