环保部:京津冀及周边地区部分企业废气未处理直接排
The systems development life cycle (SDLC) describes the typical phases and progression between phases during the development of a computer-based system; from inception to retirement. At base, there is just one life cycle even though there are different ways to describe it; using differing numbers of and names for the phases. The SDLC is analogous to the life cycle of a living organism from its birth to its death. In particular, the SDLC varies by system in much the same way that each living organism has a unique path through its life.[2][3]
The SDLC does not prescribe how engineers should go about their work to move the system through its life cycle. Prescriptive techniques are referred to using various terms such as methodology, model, framework, and formal process.
Other terms are used for the same concept as SDLC including software development life cycle (also SDLC), application development life cycle (ADLC), and system design life cycle (also SDLC). These other terms focus on a different scope of development and are associated with different prescrptive techniques, but are about the same essential life cycle.
The term "life cycle" is often written without a space, as "lifecycle", with the former more popular in the past and in non-engineering contexts. The acronym, SDLC, was coined when the longer form was more popular and has remained associated with the expansion even though the shorter form is popular in engineering. Also, SDLC is relatively unique as opposed to the TLA SDL which is highly overloaded.
Phases
[edit]
 | This section includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. (January 2023) |
Depending on source, the SDLC is described as different phases and using different terms. Even so, there are common aspects. The following attempts to describe notable phases using notable terminology. The phases are somewhat ordered by the natural sequence of development although they can be overlapping and iterative.
Conceptualization
[edit]During conceptualization (a.k.a. conceptual design, system investigation, feasibility), options and priorities are considered. A feasibility study can determine whether the development effort is worthwhile via activities such as understanding user need, cost estimation, benefit analysis, and resource analysis. A study should address operational, financial, technical, human factors, and legal/political concerns.
Requirements analysis
[edit]Requirements analysis (a.k.a. preliminary design) involves understanding the problem; what is needed. Often this involves engaging users to define the requirements and recording requirements in a document known as a requirements specification.
Design
[edit]During the design phase (a.k.a. detail design), a solution is planned. The plan can include relatively high-level information such as describing the major components of the system. The plan can be include relatively low-level information such as describing functions, screen layout, business rules, and process flow. The design phase is informed by the requirements of the system. The design must satisfy each requirement. The design may be recorded in textual documents as well as functional hierarchy diagrams, example screen images, business rules, process diagrams, pseudo-code, and data models.
Construction
[edit]During construction (a.k.a. implementation, production), the system is realized. Based on the design, hardware and software components are created and integrated. This phase includes testing sub-components, components and the integration of some components, but typically does not include testing at the complete system level. This phase may include the development of training materials including user manuals and help files.
Acceptance
[edit]The acceptance phase (a.k.a. system testing) is about testing the complete system to ensure that it meets customer expectations (requirements).
Deployment
[edit]The deployment phase (a.k.a. implementation) involves the logistics of delivery to the customer. Some systems are deployed as a single instance (i.e. in the cloud) and deployment may be ad hoc and manual. Some systems are built in quantity and are associated with manufacturing process and commissioning. This phase may include training users to use the system. It may include transitioning future development to support staff.
Maintenance
[edit]During the maintenance phase (a.k.a. operation, utilization, support) development is largely inactive although this phase does include customer support for resolving user issues and recording suggestions for improvement. Fixes and enhancements are handled by returning to the first phase, conceptualization. For minor changes, the cycle may be significantly abbreviated compared to initial development.
Decommission
[edit]Decommission (a.k.a. disposition, retirement, phase-out) is when the system is removed from use; when it reaches end-of-life.
Practices
[edit]Management and control
[edit]
SDLC phase objectives are described in this section with key deliverables, a description of recommended tasks, and a summary of related control objectives for effective management. It is critical for the project manager to establish and monitor control objectives while executing projects. Control objectives are clear statements of the desired result or purpose and should be defined and monitored throughout a project. Control objectives can be grouped into major categories (domains), and relate to the SDLC phases as shown in the figure.[5]
To manage and control a substantial SDLC initiative, a work breakdown structure (WBS) captures and schedules the work. The WBS and all programmatic material should be kept in the "project description" section of the project notebook.[clarification needed] The project manager chooses a WBS format that best describes the project.
The diagram shows that coverage spans numerous phases of the SDLC but the associated MCD (Management Control Domains) shows mappings to SDLC phases. For example, Analysis and Design is primarily performed as part of the Acquisition and Implementation Domain, and System Build and Prototype is primarily performed as part of delivery and support.[5]
Work breakdown structured organization
[edit]
The upper section of the WBS provides an overview of the project scope and timeline. It should also summarize the major phases and milestones. The middle section is based on the SDLC phases. WBS elements consist of milestones and tasks to be completed rather than activities to be undertaken and have a deadline. Each task has a measurable output (e.g., analysis document). A WBS task may rely on one or more activities (e.g. coding). Parts of the project needing support from contractors should have a statement of work (SOW). The development of a SOW does not occur during a specific phase of SDLC but is developed to include the work from the SDLC process that may be conducted by contractors.[5]
Baselines
[edit]Baselines[clarification needed] are established after four of the five phases of the SDLC, and are critical to the iterative nature of the model.[6] Baselines become milestones.
- functional baseline: established after the conceptual design phase.
- allocated baseline: established after the preliminary design phase.
- product baseline: established after the detail design and development phase.
- updated product baseline: established after the production construction phase.
In the following diagram, these stages are divided into ten steps, from definition to creation and modification of IT work products:
See also
[edit]- Application lifecycle management
- Decision cycle
- IPO model
- Object-oriented analysis and design
- Software development process
- Systems analysis and design
References
[edit]- ^ Image by Mikael H?ggstr?m, MD. Reference: Mohapatra, Dr. Hitesh; Rath, Dr. Amiya Kumar (2025-08-14). Fundamentals of Software Engineering. BPB Publications. ISBN 978-93-6589-338-0.
- ^ SELECTING A DEVELOPMENT APPROACH. Retrieved 17 July 2014.
- ^ Parag C. Pendharkara; James A. Rodgerb; Girish H. Subramanian (November 2008). "An empirical study of the Cobb–Douglas production function properties of software development effort". Information and Software Technology. 50 (12): 1181–1188. doi:10.1016/j.infsof.2007.10.019.
- ^ US Department of Justice (2003). INFORMATION RESOURCES MANAGEMENT Chapter 1. Introduction.
- ^ a b c d e U.S. House of Representatives (1999). Systems Development Life-Cycle Policy. p.13. Archived 2025-08-14 at the Wayback Machine
- ^ Blanchard, B. S., & Fabrycky, W. J.(2006) Systems engineering and analysis (4th ed.) New Jersey: Prentice Hall. p.31
Further reading
[edit]- Cummings, Haag (2006). Management Information Systems for the Information Age. Toronto, McGraw-Hill Ryerson
- Beynon-Davies P. (2009). Business Information Systems. Palgrave, Basingstoke. ISBN 978-0-230-20368-6
- Computer World, 2002, Retrieved on June 22, 2006, from the World Wide Web:
- Management Information Systems, 2005, Retrieved on June 22, 2006, from the World Wide Web:
External links
[edit]
- The Agile System Development Lifecycle
- Pension Benefit Guaranty Corporation – Information Technology Solutions Lifecycle Methodology
- DoD Integrated Framework Chart IFC (front, back)
- FSA Life Cycle Framework
- HHS Enterprise Performance Life Cycle Framework
- The Open Systems Development Life Cycle
- System Development Life Cycle Evolution Modeling
- Zero Deviation Life Cycle
- Integrated Defense AT&L Life Cycle Management Chart, the U.S. DoD form of this concept.
