系统开发生命周期
在系统工程，信息系统和软件工程， 这系统开发生命周期（SDLC），也称为应用开发生命周期，是计划，创建，测试和部署的过程信息系统.[1]系统开发生命周期概念适用于一系列硬件和软件配置，因为系统只能由硬件，仅软件或两者组合组合组成。[2]在此周期中通常有六个阶段：需求分析，设计，开发和测试，实施，文档和评估。
概述
系统开发生命周期由许多明确定义且独特的工作阶段组成，这些阶段由系统工程师和系统开发人员用于计划，设计，构建，测试和交付信息系统。就像在装配线上制造的任何东西一样，SDLC旨在通过在计划的时间范围和成本估算中传递各个明确定义的阶段的系统来生产基于客户需求的高质量系统。[3]计算机系统很复杂且经常（尤其是随着最近的兴起面向服务的体系结构）链接不同软件供应商可能提供的多个传统系统。为了管理这种复杂性，已经创建了许多SDLC模型或方法论瀑布，螺旋，敏捷软件开发，快速原型制作，增加的，并同步和稳定。[4]
可以沿敏捷到顺序方法的敏捷范围描述SDLC。敏捷方法，例如XP和Scrum，专注于轻巧的过程，这些过程允许在开发周期中快速变化（不必遵循SDLC方法的模式）。[5]迭代方法论，例如合理的统一过程和动态系统开发方法，专注于有限的项目范围，并通过多次迭代扩展或改进产品。诸如瀑布之类的顺序或大型设计（BDUF）模型（BDUF）模型着重于完整而正确的计划，以指导大型项目和风险成功，可预测的结果。其他模型，例如变形发展，倾向于专注于一种以项目范围和功能开发的适应性迭代为指导的发展形式。
在项目管理一个项目可以通过项目生命周期（PLC）和SDLC，在此期间发生略有不同的活动。根据泰勒（Taylor，2004年）的说法，“项目生命周期涵盖了项目，而系统开发生命周期的重点是实现产品要求”。[6]
SDLC本身不是一种方法，而是软件应用程序生命周期中阶段的描述。从广义上讲，这些阶段是：调查，分析，设计，构建，测试，实施，维护和支持。所有软件开发方法都遵循SDLC阶段，但是这样做的方法在方法论之间差异很大。在Scrum框架中，[7]例如，可以说一个用户故事经历了一个为期两周的冲刺中SDLC的所有阶段。另一个例子将其与瀑布方法进行对比，其中每个业务需求（在称为业务需求规范的文档中记录在SDLC的分析阶段）被翻译成功能/功能描述（在设计阶段记录在名为的文档中功能规范）随后全部构建为一个解决方案功能的集合，通常在三到九个月或更长时间内。这些方法论是不同的方法，但它们都包含诞生要求的SDLC阶段，然后在维护和支持的最后阶段穿越生命周期阶段，此后，整个生命周期通常会再次开始使用后续版本软件应用程序。
历史和细节
这产品生命周期描述以非常刻意，结构化和有条理的方式构建信息系统的过程，重申产品生活的每个阶段。根据Elliott＆Strachan＆Radford（2004）的说法，系统开发生命周期“起源于1960年代，以发展大规模的功能业务系统大规模的时代商业集团。信息系统活动围绕沉重数据处理和数字运算例程”。[8]
几个系统开发框架部分基于SDLC，例如结构化系统分析和设计方法（SSADM）为英国政府生产政府商务办公室在1980年代。从那以后，根据Elliott（2004）的说法，“传统的生命周期方法已越来越被替代方法和框架所取代，这些方法和框架试图克服传统SDLC的某些固有缺陷”。[8]
阶段
系统开发生命周期框架为系统设计师和开发人员提供了一系列活动。它由一组步骤或阶段组成，其中SDLC的每个阶段都使用上一个结果的结果。[9][10]
SDLC遵守对开发人员必不可少的重要阶段，例如规划，分析，设计， 和执行 - 并在下面的部分中解释。这包括评估当前使用的系统，信息收集，可行性研究以及请求批准。已经创建了许多SDLC型号，包括瀑布，喷泉，螺旋，建造和固定，快速原型，增量，同步和稳定。[11][12]其中最古老的是瀑布模型，一个阶段序列，其中每个阶段的输出成为下一个阶段的输入。[10]这些阶段可以以不同的方式进行表征和分割，包括以下内容：[9][10][13][14]
- 初步分析：从初步分析开始，提出替代解决方案，描述成本和收益，并提交提出建议的初步计划。
- 进行初步分析：发现组织的目的以及所研究问题的性质和范围。即使问题仅指组织本身的一小部分，也要找出组织本身的目标。然后查看所研究的问题如何适合他们。
- 提出替代解决方案：挖掘组织的目标和特定问题后，可能已经发现了几种解决方案。但是，替代建议仍然可能来自采访员工，客户，供应商和/或顾问。研究竞争对手在做什么也可以获得洞察力。
- 成本效益分析：分析和描述实施拟议更改的成本和收益。最后，关于是否原样离开系统，改进或开发新系统的最终决定将由该系统以及其余的初步分析数据指导。
- 系统分析，需求定义：将项目目标定义为预期应用程序的定义功能和操作。这涉及收集和解释事实，诊断问题以及建议对系统的改进的过程。通过分析最终用户信息需求以及消除这些需求中的任何不一致和不完整性，将进一步帮助项目目标。
- 一系列步骤随后是开发人员：[15]
- 事实的收集：通过文档，客户访谈，观察和问卷获得最终用户需求。
- 对现有系统的审查：确定当前系统的优缺点，以便继续前进并避免新系统中的缺点。
- 对拟议系统的分析：找到第二步中描述的缺点的解决方案，并使用任何特定的用户建议准备规格。
系统设计中的角色：客户，UX设计师，项目经理，业务分析师，软件开发人员，质量检查专家
- 发展：实际代码在这里写。
- 集成和测试：所有模块都汇集到一个特殊的测试环境中，然后检查是否有错误，错误和互操作性。
- 接受，安装，部署：这是初始开发的最后阶段，该软件被投入生产并运行实际业务。
- 维护：在SDLC的维护阶段，对系统进行评估/评估，以确保其不会过时。这也是对初始软件进行更改的地方。
- 评估：一些公司不认为这是SDLC的官方阶段，而另一些公司则认为这是维护阶段的扩展，并且可以在某些圈子中称为实施后审查。这是评估开发系统以及整个过程的系统。需要回答的一些问题包括新实施的系统是否满足最初的业务需求和目标，如果系统可靠且容忍故障，以及该系统是否按照批准的功能要求进行功能。除了评估发布的软件外，评估开发过程的有效性也很重要。如果管理层不满足的整个过程（或某些阶段）的任何方面，这是改进的时候。
- 处理：在此阶段，制定了计划，以停用系统信息，硬件和软件的使用，并过渡到新系统。这里的目的是正确移动，存档，丢弃或破坏正在替换的信息，硬件和软件，以防止未经授权披露敏感数据的任何可能性。处置活动确保正确迁移到新系统。特别强调了先前系统处理的数据的正确保存和归档。所有这些都应根据组织的安全要求完成。[16]
在下图中，系统开发生命周期的这些阶段分为十个步骤，从定义到创建和修改IT工作产品：
并非每个项目都需要顺序执行这些阶段；但是，这些阶段是相互依存的。根据项目的大小和复杂性，可以将阶段组合或可能重叠。[9]
系统调查
首先，研究了IT系统建议。在此步骤中，考虑所有当前将受到影响以及应如何处理的优先级。在完成任何系统计划之前，可行性研究应进行确定创建新的或改进的系统是可行的解决方案。这将有助于确定完成所需的成本，收益，资源需求和特定用户。一旦管理层批准可行性研究的建议，开发过程才能继续。
以下代表可行性研究的不同组成部分：
分析
目标分析是确定问题的位置，以试图修复系统。此步骤涉及分解该系统分别分析情况，分析项目目标，分解需要创建的内容，并尝试吸引用户，以便可以定义确定的要求。
设计
在系统设计，详细描述了设计功能和操作，包括屏幕布局，业务规则，过程图和其他文档。此阶段的输出将将新系统描述为模块或子系统的集合。
设计阶段将其作为初始输入为批准的需求文件中确定的要求。对于每项要求，访谈，研讨会和/或原型工作将产生一组或多种设计元素。
设计元素详细描述了所需的系统功能，它们通常包括功能层次图，屏幕布局图，业务规则表，业务过程图，伪代码以及具有完整数据词典的完整实体关系图。这些设计元素旨在详细描述系统，以便熟练的开发人员和工程师可以使用最小的额外输入设计来开发和交付系统。
环境
环境是系统开发人员可以在SDLC中构建，分发，安装，配置，测试和执行系统的控制区域。每个环境都与SDLC的不同区域保持一致，并旨在具有特定目的。此类环境的示例包括：
- 发展环境，开发人员可以在试图与他人的工作合并之前彼此独立工作；
- 共同的构建环境，可以将合并工作作为一个组合系统一起构建；
- 系统集成测试环境，可以测试系统集成对其他上游或下游系统的基本测试；
- 用户接受测试环境在业务利益相关者可以根据其最初的业务需求进行测试的地方；和
- 生产环境，在其中最终将系统部署到其预期的最终用户最终使用中。
测试
该代码在不同级别的测试软件测试。通常执行单位，系统和用户接受测试。这是一个灰色区域，因为关于测试的阶段是什么以及发生了多少迭代，存在许多不同的意见。迭代通常不是瀑布模型的一部分，但是在部署前进行纠正和验证修复程序的手段已纳入此阶段。
以下是可能相关的测试类型，具体取决于正在开发的系统类型：
培训和过渡
一旦通过适当的测试稳定系统，SDLC就可以确保对系统进行适当的培训或在将系统过渡到其支持人员和最终用户之前对系统进行或记录。培训通常涵盖那些将负责支持该系统的人的运营培训，并为那些将系统运送到生产操作环境后使用该系统的最终用户的培训。
在培训成功完成后，系统工程师和开发人员将系统过渡到其最终生产环境，该环境旨在由其最终用户使用，并在其支持和运营人员的支持下使用。
运营和维护
这部署该系统包括在系统的退役或日落之前的各种更改和增强。维护该系统是SDLC的一个非常重要的方面。随着关键人员改变组织的立场，将实施新的更改。系统开发有两种方法：传统方法（结构化）和面向对象。信息工程包括传统的系统方法，该方法也称为结构化分析和设计技术。面向对象的方法将信息系统视为彼此集成的对象集合，以建立完整而完整的信息系统。
评估
SDLC的最后阶段是衡量系统的有效性并评估潜在的增强功能。
系统分析和设计
系统分析和设计（SAD）是开发信息技术系统（ITS）的过程，该过程有效地使用硬件，软件，数据，流程和人员来支持公司的业务目标。它是计划新业务系统或通过定义其组件或模块以满足特定要求来替换现有系统的过程。系统分析和设计可以视为元开发活动，该活动可以设定舞台并束缚问题。可以利用SAD来在功能和非功能分析域中在竞争高级要求之间设置正确的平衡。系统分析和设计与分布式企业体系结构，企业I.T.体系结构和业务体系结构，并在很大程度上依赖于诸如分区，界面，角色和角色以及部署/操作建模等概念来得出高级系统描述。然后，这种高级描述将进一步分解为可以分析，设计和构建并集成以实现业务目标的组件和模块。SDLC和SAD是完整生命周期产品和系统规划的基石。
面向对象的分析
面向对象的分析（OOA）是分析任务（也称为问题域）的过程，以开发概念模型然后可以用来完成任务。典型的OOA模型将描述可用于满足一组客户定义要求的计算机软件。在解决问题的分析阶段，程序员可能会考虑书面要求声明，正式愿景文件或对利益相关者或其他有关方面的访谈。要解决的任务可以分为几个子任务（或域），每个子任务代表不同的业务，技术或其他感兴趣的领域。每个子任务将分别分析。实施约束，（例如，并发，分配，持久性，或在分析阶段不考虑如何构建系统；相反，它们是在面向对象的设计（OOD）期间解决的。
OOA产生的概念模型通常由一组用例， 一个或多个嗯班级图，还有一些交互图。它也可能包括某种用户界面小样。
面向对象设计的输入由输出提供面向对象的分析。意识到输出人工制品不需要完全开发作为面向对象设计的输入；分析和设计可能并行进行，实际上，一个活动的结果可以通过迭代过程在短反馈周期中为另一个活动提供。分析和设计都可以逐步执行，并且可以连续生长伪影，而不是一镜头完全开发。
一些典型的（但对于所有类型的设计分析）输入伪像，以对象为导向：
- 概念模型：概念模型是面向对象分析的结果，它捕获了问题域中的概念。明确选择概念模型独立于实施细节，例如并发或数据存储。
- 用例：用例是对事件序列的描述，这些事件序列会导致系统做有用的系统。每个用例都提供一个或多个方案这传达了系统应如何与称为参与者的用户互动以实现特定的业务目标或功能。用例参与者可能是最终用户或其他系统。在许多情况下，用例进一步详细说明了用例图。用例图用于识别参与者（用户或其他系统）及其执行过程。
- 系统序列图：系统序列图（SSD）是一张图片，显示了用例的特定场景，外部参与者生成的事件，其顺序和可能的跨系统事件。
- 用户界面文档（如果适用）：显示和描述的文档看起来和感觉最终产品的用户界面。拥有此功能不是强制性的，但是它有助于可视化最终产品，因此可以帮助设计师。
- 关系数据模型（如果适用）：数据模型是一个摘要模型，描述了如何表示和使用数据。如果对像数据库不使用，通常应在设计之前创建关系数据模型，因为选择的策略对象相关映射是OO设计过程的输出。但是，可以并行开发关系数据模型和面向对象的设计工件，并且工件的生长可以刺激其他工件的完善。
生命周期
管理和控制
SDLC阶段是项目活动的程序指南，并提供了一种灵活但一致的方法，以实现与项目范围相匹配的深度。在本节中描述了每个SDLC阶段目标，其中包含关键交付成果，推荐任务的描述以及有效管理的相关控制目标摘要。对于项目经理而言，在执行项目时，在每个SDLC阶段建立和监视控制目标至关重要。控制目标有助于提供有关所需结果或目的的明确声明，并应在整个SDLC过程中使用。控制目标可以分为主要类别（域），并与图中所示的SDLC相相关。[17]
为了管理和控制任何SDLC计划，每个项目都将被要求建立一定程度的工作分解结构（WBS）捕获并安排完成项目所需的工作。WBS和所有程序化材料应保存在项目笔记本的“项目说明”部分中。WBS格式主要留给项目经理以最能描述项目工作的方式建立。
WBS中必须定义一些关键领域，作为SDLC策略的一部分。下图描述了将以项目经理建立的方式在WBS中解决的三个关键领域。[17]该图显示复盖范围跨越了SDLC的许多阶段，但是相关的MCD具有与SDLC相的主要映射子集。例如，分析和设计主要是作为采集和实施域的一部分进行的，系统构建和原型主要作为交付和支持的一部分进行。
工作故障结构化组织
工作崩溃结构（WBS）的上部应以摘要方式确定项目的主要阶段和里程碑。此外，上一部分应概述项目的完整范围和时间表，并将成为最初的项目说明的一部分，从而导致项目批准。WBS的中间部分基于七个系统开发生命周期阶段，作为WBS任务开发的指南。WBS元素应包括里程碑和“任务”，而不是“活动”，并具有确定的时期（通常为两个星期或更长时间）。每个任务必须具有可测量的输出（例如文档，决策或分析）。WBS任务可能依赖一个或多个活动（例如，软件工程，系统工程），并且可能需要与项目内部或外部的其他任务密切协调。需要承包商支持的项目的任何部分都应有一个工作陈述（SOW）书写以包括来自SDLC阶段的适当任务。SOW的发展不会在SDLC的特定阶段发生，而是开发出来的是包括SDLC流程中外部资源（例如承包商）可能进行的工作。[17]
基线
基准是系统开发生命周期的重要组成部分。这些基线是在SDLC的五个阶段中的四个阶段建立的，并且对迭代模型的性质。[18]每个基线被认为是SDLC中的里程碑。
- 功能基线：在概念设计阶段建立。
- 分配的基线：在初步设计阶段建立。
- 产品基线：在细节设计和开发阶段建立。
- 更新的产品基线：在生产施工阶段建立。
互补方法
补充软件开发方法系统开发生命周期是：
| SDLC | rad | 开源 | 对象 | 贾德 | 原型 | 最终用户 | |
|---|---|---|---|---|---|---|---|
| 控制 | 正式的 | 错误 | 虚弱的 | 标准 | 联合的 | 用户 | 用户 |
| 大体时间 | 长 | 短的 | 中等的 | 任何 | 中等的 | 短的 | 短的 – |
| 用户 | 许多 | 很少 | 很少 | 变化 | 很少 | 一个或两个 | 一 |
| MIS员工 | 许多 | 很少 | 数百个 | 分裂 | 很少 | 一个或两个 | 没有任何 |
| 交易/DSS | 交易 | 两个都 | 两个都 | 两个都 | DSS | DSS | DSS |
| 界面 | 最小 | 最小 | 虚弱的 | 视窗 | 至关重要的 | 至关重要的 | 至关重要的 |
| 文档和培训 | 重要 | 有限的 | 内部的 | 在对像中 | 有限的 | 虚弱的 | 没有任何 |
| 完整性和安全性 | 重要 | 重要 | 未知 | 在对像中 | 有限的 | 虚弱的 | 虚弱的 |
| 可重复使用 | 有限的 | 一些 | 也许 | 重要 | 有限的 | 虚弱的 | 没有任何 |
长处和短处
现代计算世界中很少有人会严格使用瀑布模型因为他们的SDLC，许多现代方法已经取代了这一想法。有人会争辩说，SDLC不再适用于诸如敏捷计算之类的模型，但它仍然是技术圈中广泛使用的术语。SDLC实践在传统的系统开发模型中具有优势，可以使自己更适合结构化环境。使用SDLC方法论的缺点是何时需要迭代开发或（即Web开发或电子商务），利益相关者需要定期审核该软件的设计。
比较SDLC的优势和劣势：
| 优势 | 弱点 |
|---|---|
| 控制 | 增加的发展时间 |
| 监视大型项目 | 增长成本 |
| 详细的步骤 | 系统必须在前定义 |
| 评估成本和完成目标 | 刚性 |
| 文档 | 难以估计成本，项目超支 |
| 定义明确的用户输入 | 用户输入有时有限 |
| 易于维护 | 小平行性 |
| 发展和设计标准 | 文档和标准的自动化有限 |
| 容忍人员配备的变化 | 不容忍需求的变化 |
| 早期罐装结果的项目几乎没有价值 |
SDLC的替代方法是快速应用开发（RAD），它结合了案例工具的原型，联合应用开发和实施。RAD的优点是速度，开发成本降低以及积极参与开发过程。
系统生命周期
系统生命周期系统工程是系统或提议的系统的视图，该系统解决其存在的所有阶段，包括系统构想，设计和开发，生产和/或构造，分配，操作，维护和支持，退休，淘汰，淘汰和处置。[20]
概念设计
这概念设计阶段是检查确定需求，定义潜在解决方案的要求，评估潜在解决方案的要求，并开发了系统规范。系统规范表示将为系统设计提供总体指导的技术要求。因为本文档决定了所有未来的发展，所以阶段才能完成，直到概念设计回顾已经确定系统规范正确满足了激励需求。
概念设计阶段的关键步骤包括：
- 需要识别
- 可行性分析
- 系统需求分析
- 系统规范
- 概念设计评论
初步系统设计
在系统生命周期的此阶段，执行所需系统功能的子系统是根据系统规范设计和指定的。定义了子系统之间的接口，以及总体测试和评估要求。[21]在此阶段完成时，制作了开发规范，足以执行详细的设计和开发。
初步设计阶段的关键步骤包括：
- 功能分析
- 要求分配
- 详细的权衡研究
- 系统选项的合成
- 工程模型的初步设计
- 开发规范
- 初步设计评论
例如，作为VITI银行的系统分析师，您已被任命检查当前信息系统。维蒂银行是一家快速发展的银行斐济。偏远农村地区的客户发现难以访问银行服务。他们需要几天甚至几周才能前往某个地点访问银行服务。有了满足客户需求的愿景，银行已要求您的服务检查当前系统，并提出有关如何提供当前系统以满足其需求的解决方案或建议。
细节设计和开发
此阶段包括开发详细设计，将初始设计工作带入完整的规格形式。这项工作包括系统与其预期环境之间的接口规范，以及对系统后勤，维护和支持要求的全面评估。细节设计和开发负责生产产品，过程和材料规格，并可能导致开发规范的实质性变化。
细节设计和开发阶段中的关键步骤包括：
- 详细的设计
- 详细的合成
- 工程和原型楷模
- 开发规范的修订
- 产品，过程和材料规范
- 关键设计审查
生产和施工
在生产和/或施工阶段，该产品是根据产品，过程和材料规格中指定的要求制成或组装的，并在操作目标环境中进行了部署和测试。进行系统评估是为了纠正缺陷并调整系统以继续改进。
产品构建阶段的关键步骤包括：
- 生产和/或系统组件的构建
- 验收测试
- 系统分布和操作
- 操作测试和评估
- 系统评估
利用和支持
一旦完全部署，该系统将用于其预期的操作角色，并保持在其操作环境中。
利用率和支持阶段的关键步骤包括：
- 在用户环境中的系统操作
- 更换管理层
- 改进的系统修改
- 系统评估
淘汰和处置
必须连续评估系统的有效性和效率，以确定产品何时符合其最大的有效生命周期。[22]考虑因素包括：持续存在运营需求，操作要求和系统性能之间的匹配，系统淘汰与维护的可行性以及替代系统的可用性。
也可以看看
参考
- ^选择开发方法。 2014年7月17日检索。
- ^Parag C. Pendharkara；James A. Rodgerb；Girish H. Subramanian（2008年11月）。“对软件开发工作的Cobb – Douglas生产功能的实证研究”。信息和软件技术.50（12）：1181–1188。doi：10.1016/j.infsof.2007.10.019.
- ^“系统开发生命周期”。折叠。检索2013-06-14.
- ^“软件开发生命周期（SDLC）”.
- ^“ SDLC概述：模型和方法”。检索2021-12-12.
- ^泰勒，詹姆斯（2004）。管理信息技术项目。 p。 39。
- ^“什么是Scrum？”。 2019年12月24日。
- ^一个bGeoffrey Elliott＆Josh Strachan（2004）全球业务信息技术。第87页。
- ^一个bcd美国司法部（2003年）。信息资源管理第1章。简介。
- ^一个bcEveratt，G.D。； McLeod，R JR（2007）。“第2章：软件开发生命周期”.软件测试：整个软件开发生命周期的测试。约翰·威利（John Wiley＆Sons）。第29-58页。ISBN 9780470146347.
- ^Unlelkar，B。（2016）。敏捷实践的艺术：项目和组织的综合方法。 CRC出版社。第56-59页。ISBN 9781439851197.
- ^S.K. Land;Smith，D.B。;沃尔兹（J.W.）（2012）。对精益六西格码软件流程的实际支持定义：使用IEEE软件工程标准。约翰·威利（John Wiley＆Sons）。 pp。341–3。ISBN 9780470289952.
- ^凯，罗素（2002年5月14日）。“ QuickStudy：系统开发生命周期”.计算机世界.
- ^Taylor，G.D。（2008）。物流工程简介。 CRC出版社。 pp。12.6–12.18。ISBN 9781420088571.
- ^“第5章”。信息系统控制和审核（PDF）。印度特许会计师研究所。2013年8月。5.28。
- ^Radack，S。（n.d。）。“系统开发生命周期（SDLC）”（PDF）。国家标准技术研究所。
- ^一个bcde美国众议院（1999）。系统开发生命周期政策。第13页。存档2013-10-19在Wayback Machine
- ^B. S. Blanchard，＆Fabrycky，W。J.（2006）系统工程和分析（第4版）新泽西：Prentice Hall。第31页
- ^一个bPost，G。，＆Anderson，D。，（2006年）。管理信息系统：通过信息技术解决业务问题。（第四版）。纽约：麦格劳 - 希尔·欧文（McGraw-Hill Irwin）。
- ^Blanchard和Fabrycky（2006）。系统工程和分析，第四版。 Prentice Hall。 p。 19。
- ^Joahn Gouws博士（2007）。工程简介，系统工程。 Melikon Pty Ltd.
- ^坎宁安，詹姆斯。“ HERC维护”.法戈.xxi（北大街）：49。存档原本的2013年1月21日。检索5月13日2009.
进一步阅读
- 卡明斯，哈格（2006）。信息时代的管理信息系统。多伦多，麦格劳 - 希尔·瑞尔森
- Beynon-Davies P.（2009）。业务信息系统。帕尔格雷夫，贝辛斯托克。ISBN978-0-230-20368-6
- 计算机世界，2002年，于2006年6月22日从万维网检索：
- 管理信息系统，2005年，于2006年6月22日从万维网检索：
外部链接
- 敏捷系统开发生命周期
- 退休金福利担保公司 - 信息技术解决方案生命周期方法
- DOD集成框架图IFC（正面，背部）
- FSA生命周期框架
- HHS企业绩效生命周期框架
- 开放系统开发生命周期
- 系统开发生命周期演变建模
- 零偏差生命周期
- 综合防御AT＆L生命周期管理图表，美国国防部这一概念的形式。
下议院
类别