No edit summary |
m (Removed protection from "System Development Life Cycle") |
||
| (10 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | == |
+ | == Definitions == |
| + | === General === |
||
| − | The '''System Development Life Cycle''' ('''SDLC''') methodology provides a structured approach to managing [[IT]] projects. It also allows introduction of [[IT security]] planning, including budgeting, review, and oversight. |
||
| + | |||
| + | A '''System[s] Development Life Cycle''' ('''SDLC''') is |
||
| + | |||
| + | {{Quote|[a]n approach used to plan, design, develop, [[test]], and [[implement]] an [[application system]] or a major [[modification]] to an [[application system]].<ref>[[FFIEC IT Examination Handbook]], Audit, Appendix B: Glossary ([http://ithandbook.ffiec.gov/it-booklets/audit/appendix-b-glossary.aspx full-text]).</ref>}} |
||
| + | |||
| + | {{Quote|[t]he scope of activities associated with a [[system]], encompassing the [[system]]'s initiation, [[system development|development]] and [[acquisition]], [[implementation]], operation and [[maintenance]], and ultimately its [[disposal]].<ref>[[CNSSI 4009]].</ref>}} |
||
| + | |||
| + | {{Quote|[g]uidance, [[policies]], and [[procedure]]s for [[system development|developing systems]] throughout their [[life cycle]], including requirements, design, [[implementation]], [[testing]], [[deployment]], operations, and [[maintenance]].<ref>[[A Practical Guide to Federal Enterprise Architecture]], at 69, App. B, Glossary.</ref>}} |
||
| + | |||
| + | === Software === |
||
| + | |||
| + | A '''System[s] Development Life Cycle''' ('''SDLC''') is |
||
| + | |||
| + | {{Quote|a series of prescribed [[procedure]]s 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 [[deliverable]]s that are required, the controls to assure quality and coordinate change and the [[milestone]]s 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 [[deliverable]]s required.<ref>Michigan Dept. of Tech., Management & Budget, 8000 Glossary (Jan. 6, 1997) ([http://www.michigan.gov/dmb/0,4568,7-150-9131_9347-29688--,00.html#C full-text]).</ref>}} |
||
== Overview == |
== Overview == |
||
| Line 10: | Line 24: | ||
Throughout the System Development Life Cycle [[system]] owners must be cognizant of changes to the [[system]]. Since [[system]]s routinely experience changes over time to accommodate new requirements, new technologies or new [[risk]]s, 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 [[user]]s, applying standard [[security patch]]es, or other routine activities. However, [[significant change]]s require an added level of attention and action. Changes, such as [[install]]ing a new [[operating system]], [[port]] [[modification]], new [[hardware platform]]s, or changes to the [[security controls]] should trigger a re-authorization of the [[system]] |
Throughout the System Development Life Cycle [[system]] owners must be cognizant of changes to the [[system]]. Since [[system]]s routinely experience changes over time to accommodate new requirements, new technologies or new [[risk]]s, 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 [[user]]s, applying standard [[security patch]]es, or other routine activities. However, [[significant change]]s require an added level of attention and action. Changes, such as [[install]]ing a new [[operating system]], [[port]] [[modification]], new [[hardware platform]]s, or changes to the [[security controls]] should trigger a re-authorization of the [[system]] |
||
| + | |||
| + | == References == |
||
| + | <references /> |
||
[[Category:Technology]] |
[[Category:Technology]] |
||
[[Category:Business]] |
[[Category:Business]] |
||
[[Category:Definition]] |
[[Category:Definition]] |
||
| + | [[Category:Financial]] |
||
Revision as of 23:01, 31 July 2013
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).