The acquisition life cycle is
[t]he standard process used by the acquisitionorganization for defining how a system will be acquired and maintained from inception to retirement. The Acquisition Life Cycle typically follows the waterfall system development model and includes the following phases: Initiation, Planning, Procurement, System Development, System Implementation, Maintenance & Operations, and Closeout.
Definitions[]
General[]
A System[s] Development Life Cycle (SDLC) is
| “ | [a]n approach used to plan, design, develop, test, and implement an application system or a major modification to an application system.[1] | ” |
| “ | [t]he scope of activities associated with a system, encompassing the system's initiation, development and acquisition, implementation, operation and maintenance, and ultimately its disposal.[2] | ” |
| “ | [g]uidance, policies, and procedures for developing systems throughout their life cycle, including requirements, design, implementation, testing, deployment, operations, and maintenance.[3] | ” |
Software[]
A System[s] Development Life Cycle (SDLC) is
| “ | a series of prescribed procedures or steps for the rational and timely development, operational use, and maintenance of computer software. The procedures define the sequence in which analysis, design, coding and testing methods are applied, the tools used to support those methods, the deliverables that are required, the controls to assure quality and coordinate change and the milestones that enable assessment of progress. Variations in selection of a particular life cycle are influenced by the scope and complexity of projects or applications, the methods and tools to be used, and the controls and deliverables required.[4] | ” |
Overview[]
There are eight distinct phases in the SDLC as depicted in the figure below:
SDLC Process
Throughout the System Development Life Cycle system owners must be cognizant of changes to the system. Since systems routinely experience changes over time to accommodate new requirements, new technologies or new risks, they must be routinely analyzed in respect to the security posture. Minor changes typically have little impact to the security posture of a system. These changes can be standard maintenance, adding or deleting users, applying standard security patches, or other routine activities. However, significant changes require an added level of attention and action. Changes, such as installing a new operating system, port modification, new hardware platforms, or changes to the security controls should trigger a re-authorization of the system
References[]
- ↑ FFIEC IT Examination Handbook, Audit, Appendix B: Glossary (full-text).
- ↑ CNSSI 4009.
- ↑ A Practical Guide to Federal Enterprise Architecture, at 69, App. B, Glossary.
- ↑ Michigan Dept. of Tech., Management & Budget, 8000 Glossary (Jan. 6, 1997) (full-text).