软件APP开发流程？
软件生命周期
系统/软件APP开发过程有几个阶段。这些阶段代表了信息技术服务部 (ITS) 的企业系统部门开发的软件的生命周期。主要阶段包括：
规划和要求
分析与设计
规划与建设
测试和文档
实施与培训
维护
每个阶段的长度因项目而异，有时阶段之间的界限并不明确。此外，从一个阶段到下一个阶段的进展并不总是单向或连续的。例如，在编程或测试阶段遇到的新需求或问题可能需要返回到分析/设计或需求阶段。此外，使用原型技术通常涉及从测试阶段回归到分析/设计和编程阶段。尽管如此，这些阶段足以代表正在开发的软件APP的概念进展。
维护阶段实际上可能涉及其部分或所有前期阶段，具体取决于维护项目的范围。一些维护项目相对较小，而其他维护项目可能涉及对现有系统的重大改进。维护请求，软件维护流程；小型维护请求只需遵循其中概述的标准和程序，而大型项目也必须遵循本章中概述的标准和程序。
请求是否会导致重大或维护项目并不总是在提出请求时就显而易见。因此，所有请求都要经过初步审查。初步审查由企业系统管理团队的一名或多名成员进行。如果管理团队确定该请求构成重大项目，则会为该项目指派一名业务分析师。业务分析师将与请求者合作并准备一份概述拟议解决方案的请求摘要。
企业系统使用 Microsoft Project 来跟踪新软件APP的开发进度以及对现有软件APP的重大改进。项目文档的主要步骤或里程碑用于创建项目检查表。最终用户和分析师都使用该列表来记录软件APP开发项目期间各个步骤的批准（签字）和完成日期。项目检查表涵盖了生命周期模型的所有阶段，尽管各个阶段被划分为更独立的步骤（见下文）。
项目计划中包含的典型开发步骤如下：
概念
规划
要求（功能规范）
设计（技术规格）
发展
测试
文档
执行
训练
实施后评估
软件APP开发应遵循以下概述的指导方针，按照所示的一般顺序进行这些阶段。
概念
此步骤从最终用户（项目发起人）提出应用开发请求开始，该请求概括地说明了拟议系统的性质。初始请求只需要求“咨询/分析支持”，因为尚未确定系统是否真正在本地开发。
指派一名业务分析师与赞助商（或用户代表）合作探讨问题或机会。
如果适用，发起人和业务分析师都应参与探索商业替代方案（即第三方软件包）。有些软件APP非常独特，没有可用的商业解决方案，而其他软件APP可能有几种商业替代方案。发起人必须与业务分析师协商，决定是否可以接受任何商业替代方案。可接受的替代方案不仅应满足请求者的功能要求，还应具有经济可行性，在信息技术服务支持的环境中运行，并支持任何必要的现有系统接口。如果选择了商业解决方案，开发过程就此停止。但是，这将开始一个新的过程。请参阅商业软件采购流程。
此步骤的第一个可交付成果是请求摘要文档。
该文件由业务分析师在与赞助商协商后准备。该文件概述了拟议系统的功能，包括有关该系统对大学的潜在好处的声明。虽然这份文件是一般性的，但它应该是全面的，也就是说，它应该尽可能多地概括描述系统所需的功能。
更具体地说，该文件包含以下内容：
问题/改进机会- 客户建议解决的问题或机会的摘要；以问题或机会的角度而不是解决方案的角度来写。
请求描述- 以功能术语描述所提出的解决方案，用于解决上面列出的问题或机会。
战略利益——就大学使命而言
必需- 表明该项目是否需要维持运营或降低风险或成本。
当前 状态- 识别现有系统的当前状态
利益相关者——列出正在实施项目并将获得利益的客户群体。
时间线灵活性- 表示时间线是否具有灵活性。
ITS 资源时间估计- 描述预计所需的 ITS 资源。
发起方的资源时间估计- 描述预期需要的发起方和/或利益相关者的资源
系统减少/增加- 表示对系统数量的影响。
为客户节省的时间- 描述项目为利益相关者的生产力增加的效率。
实施 成本范围– 实施成本的估算。
运营成本- 确定一次性成本、经常性成本和许可成本。
资源风险/依赖性- 识别与项目有关系/依赖性的项目或现有系统。
请求摘要文档经过评分后返回企业系统管理团队进行评估和批准。根据提案的范围和影响，文档可能会转发给 ITS 或其他大学管理小组进行决策。
一旦获得批准，第二个可交付成果就是项目章程。分析师将与赞助商或用户代表密切合作，以确定项目的目标和范围。项目章程由业务分析师准备，包含以下内容：
项目介绍
本节描述建议的解决方案。项目有一个目标，为项目提供目的和方向。这将被用作有关范围或目的的任何问题的一个持续参考点。本节应以每个人都能理解的语言编写。它描述了将实施、更正、安装、替换或以其他方式解决的问题。
项目范围
简短的范围说明，定义项目将交付的内容。然后简要描述项目和功能的拟议“范围内”边界。还列出了“范围外”以建立项目边界。
方法/方式
本节列出了与本项目有关系的其他项目或现有系统。特别是，本项目与其他拟议项目之间的任何依赖关系均已注明。
假设
本节列出了项目所依赖的关键假设（资源、政策、技术、进度安排等）。这些是被视为真实、正确或确定的关键因素。
约束
通常这些包括成本、时间安排、人员配备和质量 - 例如：项目必须在 2014 年 6 月 27 日之前完成，这是 2014 年秋季注册的开始时间，因为该工作将影响横幅注册过程。
风险
识别成功完成项目所涉及的风险。还记录发生的可能性和预期影响的严重程度。
可交付成果（目标）
这是项目范围的更详细版本。它是本项目将要完成的工作。目标陈述阐明了项目范围的边界，并定义了项目范围的边界。必须完成每个目标才能达到目标并实现本项目的目的。
成功标准
这是开展该项目所产生的可衡量的商业价值，并针对将会改进什么、减少什么问题或将给大学带来什么好处等问题提出了量化的、有形的商业利益。
完成的项目章程由项目发起人和 ITS 管理层批准。在某些情况下，该计划可能会转发给管理机构以供决策。
规划
一旦获得项目章程的适当批准，项目将进入规划阶段。此时，企业系统管理团队将任命一名项目经理，负责制定项目计划并指导项目直至完成。
应根据项目章程的范围制定初步规范。项目经理将使用此规范来确定预期的资源以及必须进行任务分配的一般领域。
项目经理在 Microsoft Project 中创建项目计划；确定任务、建立项目时间表并为项目内的任务分配资源。在较大的项目中，经理还可以确定技术主管来指导和监督项目团队成员的工作。
制定沟通计划，详细说明项目团队成员如何沟通和共享信息。根据项目范围，这可能包括使用 SharePoint 等沟通工具、制定定期会议时间表、状态报告要求等。
计划完成后，将进行另一项风险评估，重点关注资源争用，特别是在 ITS 内部。
项目计划提交给企业系统管理层审批。在某些情况下，该计划可能会被转发给 ITS 管理层或理事机构以供决策。
需求（功能规范）
在需求步骤中，开发解决方案的完整详细需求集。需求阶段的可交付成果是功能规范。
功能规范应详尽，并描述拟议系统所有组件的细节。它应以准确、清晰和明确的语言编写，以便功能利益相关者和项目团队的技术成员都能理解。
负责制定规范的分析师必须阅读并完全熟悉项目章程。分析师将根据需要对项目发起人、用户代表和利益相关者进行额外采访。
通常会进行业务流程分析 (BPA)。BPA 是一种分析当前和未来业务流程并记录流程中的活动、办公室和文档的方法。
BPA 至少应包含以下内容：
定义流程边界，分别标记流程输入和流程输出的入口点和出口点，
描述过程活动及其相互关系（通常使用过程流程图）。
确定流程中每个步骤的容量。
识别瓶颈（容量最低的步骤）和其他限制。
功能规范应按组件（模块、屏幕、报告等）组织，详细描述每个组件的功能和处理流程。此描述不仅应包括相关模块内发生的特殊过程，还应包括它们与系统内外其他过程的交互。
规范必须包括：
新系统将与之交互的现有系统的完整列表以及这些交互的性质（即批处理、在线或两者）。
系统每个组件的用户组的分类和特征，以及这些组的安全/访问限制。
系统中要创建的所有新数据元素的描述。
编辑系统中收集或处理的所有数据的标准。
所有在线组件的模型或原型以及有关如何使用组件和所用数据元素的描述。
在线帮助要求的描述。
所有报告和/或下载的模型或布局和说明，包括所引用的数据元素。
数据和/或流程流分析（从功能角度来看）。
任何自动化流程的时间限制和时间表。
记录未来可能要求的任何可能的或设想的增强功能。
功能规范完成后，项目发起人、相关利益相关者和项目团队成员将有机会进行审查。根据审查反馈，对规范进行修改，直到各方都同意规范完整且正确。
完成的功能规范必须得到项目发起人和企业系统管理部门的批准。在某些情况下，该计划可能会转发给 ITS 管理部门或理事机构以供决策。
设计（技术规格）
一旦获得功能规范的适当批准，项目将进入设计步骤。项目经理将审查规范，并根据需要调整项目下一阶段的任务和时间表。
设计阶段的可交付成果是技术规范。
被分配到该领域的分析师将根据功能规范中包含的要求创建技术规范。因此，他们必须考虑其中包含的所有要求。
技术规范包括数据和流程设计规范。这涉及将系统分解为其组件或模块，详细描述每个组件中的逻辑和处理，包括所有编辑和验证标准。
已经为采用 Oracle 或 SQL/DS 关系数据库设计的系统开发了一些特殊标准。
为了减少数据冗余并最大程度地提高数据完整性，关系表应规范化为第三范式 (3NF) 或更高范式。不鼓励使用第二范式 (2NF) 或第一范式 (1NF) 表，并且必须从性能角度进行论证；所有此类例外情况都必须得到相应数据库管理员的批准。
每个关系表都应具有唯一的主索引或键，并且数据应通过该索引/键“聚集”（连续组织）。
只要可行，强烈建议实施参照完整性约束。
所有数据库设计都必须经过适当的数据库管理员审核。
技术规范必须包括：
系统集成点（和影响）。
识别现有数据源。
带有字段/列定义和属性的表、索引和文件定义。
估计文件/表大小要求，包括增长率。
要创建的程序组件的名称和描述。
软件APP各模块的安全需求。
每个组件的错误处理设计。
技术规范完成后，项目团队成员将有机会进行审查。根据审查反馈，对规范进行修改，直到规范完整且正确。
完成的技术规范必须得到企业系统管理部门的批准。
发展
技术规范获批后，项目将进入开发阶段。在此步骤中，开发人员将编写构建系统的实际低级代码。
CFRDC 在线和批处理系统的标准编程语言分别是 PL/SQL 和 SQL*Plus。本地环境中在线和批处理系统的标准编程语言是 .NET C# 和 Java。开发人员必须遵守所用语言的适用标准。有关详细信息，请参阅相应的平台特定标准手册。
开发人员必须查看并熟悉技术规范中包含的信息。开发人员创建编码计划（伪代码、大纲、流程图或任何适合开发人员的方法）。该计划应遵循技术规范。
开发人员应让技术主管（如果已指定）或直接主管审查代码计划。经批准后，开发人员将创建规范中指定的表、索引和其他对象，然后在适当的开发环境中创建程序模块。
尽管生命周期分类方案将测试视为与开发不同的一个阶段，但测试是开发不可分割的延伸，因此测试应该是编程阶段的一个持续部分。开发人员最初负责测试，至少直到异常终止的可能性被消除、所有错误情况都得到令人满意的测试并且所有操作键或按钮都按标签操作。
编码完成后，项目经理指派的项目团队成员将进行代码审查。反馈应纳入代码中。最终审查完成后，团队将发出继续进行的批准。
测试
测试主要是为了确定程序是否真正满足功能要求并且运行时没有错误。测试分为两个级别：单元测试和集成测试。
单元测试涉及测试系统的各个组件。因此，这些测试可以在每个组件完成后进行。集成测试是在所有组件完成且系统安装在类似生产环境中的情况下进行的。
项目经理将指派分析师制定单元测试和集成测试计划。经理还将指派人员按照测试计划进行初步测试。
ITS 通常还要求将最终用户测试作为项目章程的一部分。此测试在预生产环境中进行。项目章程将表明项目发起人是否需要 ITS 协助制定测试计划或准备最终用户测试的数据。
项目清单要求发起人证明已进行系统范围的测试并且结果令人满意。
测试应遵循以下准则：
所有测试文件/表都应该是“真实”数据的代表性样本或横截面（即，一旦系统投入生产）。
应该针对系统中的每个模块测试所有错误情况，并且每个常见的错误情况都必须产生一条标准消息，如平台编程标准中所述。
应该针对系统中的每个模块测试所有操作（插入、更新、删除等）。
应该针对系统中的每个模块测试所有编辑和验证检查。
应该对系统中的每个模块测试所有安全和授权检查。这可能需要将安全类、用户 ID 等从生产环境复制到测试环境
在适用的情况下，所有到其他模块的传输（包括系统内部和外部的传输）都应针对系统中的每个模块进行测试。
异常终止是无法容忍的。为了避免数据异常，分析师和开发人员应非常小心地确保数据按照适当的标准进行初始化、编辑、操作和转换。同样，必须始终避免失控任务、未捕获的错误情况和不正确地终止浏览。通过严格遵守针对相关语言开发的编程标准，可以避免异常终止。
文档
任何项目都需要两种类型的文档：内部和外部。
内部文档包括以下内容。有关文档标准，请参阅相应程序平台的编程标准。
作为项目实施的一部分编写的文件（请求摘要、项目章程、功能规范等）。
实际软件代码中的注释引用了软件APP开发请求、编程日期和作者。
外部文档包括：
批处理系统的作业目录条目。
交互式系统的在线帮助。
处理流程叙述
支持中心文档
综合用户手册通常由项目发起人指定的用户代表准备。这确保文档不仅包含新系统的机械使用，还包含系统使用与运营单位内其他业务流程的关系。项目章程将表明 ITS 将在多大程度上参与为特定项目准备此类文档。
执行
实施是将软件APP投入生产的过程。将系统投入生产所涉及的标准和程序因软件APP的执行环境而异。
训练
系统最终用户的综合培训通常由用户代表准备和执行。这确保培训将根据运营单位业务流程中的新系统的使用情况量身定制。
在大多数情况下，ITS 将使用“培训培训师”模式为少数人（由项目发起人选择）提供初始培训。然后，这些人员将为最终用户社区制定更全面的培训计划。
项目章程将表明赞助商希望 ITS 提供的培训级别和类型。作为项目检查表的一部分，项目赞助商必须证明所接受的培训令人满意。
实施后评估
为确保系统运行良好，用户群体满意，系统实施后大约两到三个月会进行一次实施后评估。评估应以项目发起人、项目团队和其他人员之间的会议形式进行。
这些会议的主要目的是根据功能要求评估已实施的系统，并确定用户在这方面遇到的任何问题或错误。次要目标是评估项目本身的执行情况。此次检查的反馈可用于改进软件APP开发过程。
系统的任何新需求（扩展、增强、改进等）都应遵循软件APP维护流程中概述的指导方针。
定义
主要利益相关者
业务分析师——准备定义项目目标和范围的概念文档。
ITS 发起人- 企业系统管理团队成员（通常是主管），指派业务分析师和项目经理，协助解决重大问题和政策冲突，批准范围变更，签署主要可交付成果并批准进入每个后续项目阶段。
项目经理- 将 ITS 资源分配给任务、处理变更请求、制定时间表、监控项目进度。
项目发起人——为范围变更提供意见，并根据项目需要提供资源/用户代表进行咨询/测试。
请求者——发起服务请求，确定项目发起人。
团队成员——分析师、开发人员和其他被指派完成项目任务的个人。
技术主管——指导工作努力并监督团队成员的工作。
用户代表——根据需要咨询澄清项目、测试系统和培训。
文件
软件APP开发请求- 开始项目的初始请求。
请求摘要- 业务分析师准备的摘要文件，概述了拟议系统的功能，包括系统的潜在好处。
项目章程——由业务分析师准备的文件，定义项目的目标、范围和可交付成果。
项目计划- 一份包含项目任务、分配和时间表的 Microsoft Project 文档。
项目清单——一份列出项目主要里程碑的文件，其中记录了每个里程碑的批准（签字）。
功能规范——所提议系统的详细功能设计。
技术规范- 为支持功能设计而创建的表、文件和程序的详细技术描述。
测试计划- 一份概述用于确保新系统按设计运行的测试场景的文档。