[工学][计算机软件技术基础第三版麦中凡 苗明川 何玉洁]第十一章_软件开发与软件维护.ppt

C++程序设计 软件开发，除了极少量自编自用的应用程序外，更多的是共同开发、他人使用(软件产品)。随着软件规模日益增大，软件开发也不是一般的个人行为，而是一个3~5人的小组甚至几千人的大公司相当一段时间的工作。 开发者、用户、客户(项目的主持人、项目经费的支付人)一般不是一个人。客户以契约的方式委托开发者，然后按合同交付验收，由客户使用最终产品。 软件开发历来都是作为（工程）项目下达给开发小组（或公司）。它当然要有周密的计划、管理协调、分工合作、按时交付，也就是要以软件工程的方法开发软件。 11.1 软件生存周期 软件是部署在特定环境(硬件、操作系统、基础设施)上的一组程序。它在机器上运行，实现人们预期的功能和性能。自然，编制能在机器上正常运行的程序系统就是人们开发软件中心活动。早期人们就以为编程—调试—交付是软件开发的主要活动. 没有需求，无从构架；没有构架，设计不周全。设计审查无误才投入编码—测试—交付，最后还要维护升级，这些客观存在的活动描述了软件生存周期的蓝图，是组织、管理、实现软件工程项目的依据。 从系统观点看软件的开发和维护，很难说那种活动比另一种重要，都是不可或缺的一环。软件有一个特点：错误发现越早，付出代价越少。工作重心自然从编程—调试向两端移动。“问题是什么，我们要采用什么技术、做出什么样的软件解决这个问题”；“市场前景在哪?本产品如何改进以求不遭淘汰”。 传统的生存周期模型 模型是对事物最本质的刻画。传统的软件生存周期模型如11.1所示。这个模型刻画了一个软件从初创到退役所经历的活动，每种活动有哪些成果(不同形态的软件产物)。本模型描述了软件创制和维护的关键活动，与工程技术密切相关。但非软件工程全过程（见下章ISO12207）。缺乏计划、管理、质量保证、配置、文档、培训等工程产品必不可少的活动。但就介绍软件工程技术而言，它是一个很好的模型。 11.2 软 件 需 求 软件需求的目标是把用户的“需要”变成系统开发的“需求”，或称需求规范。这个工作大体上分三步：收集用户、市场、公司对本项目的需要；经过分析建立解题模型；细化模型，抽取需求。请注意，这个需求每一条都是系统测试的验收准则，所以模型要细化到能写出可验收需求的程度，决不能太笼统，如“开发一个办公室系统要灵活、方便好用。”就不是一个好的需求，因为它既不能指导开发，也无法验收。好的需求具有众多特点，归纳下来主要有：一致的，完整的，可理解的，无二异的，和可测试的。 11.2.1 需求工程 软件需求近年已发展成需求工程，即把初始创意到需求文档的确认当做一个工程去做，其内容是： ? 需求工程过程定义：过程模型(按什么步骤得到需求文档)、过程执行者、过程支持和管理(需要的设备条件、资金、计划)、过程质量和改进(本过程的质量目标，改进措施)。 ? 导出需求：按需求来源、导出技术。 ? 需求分析：需求分类(如前所述四种开发类型的哪一种)、概念建模、体系结构的初步设计、需求分配(按设想的体系机构为子系统、大模块写出需求，把总的需求分配到各子部分)、需求磋商。对于风险较大的新技术要做关键机制的原型开发。 ? 写出需求规格说明，其内容包括： 数据需求：数据模型、数据字典、数据库、输入/出数据格式 功能需求：功能列表(计算功能、数据记录、采集、转换功能) 活动图(行为描述) 屏幕原型 支持总的功能的子任务(内部功能) 质量需求：对有特殊质量要求的应写明： 性能需求(实时、嵌入式应用) 好用性需求(儿童、残疾人使用或组合界面) 维护性需求(更改频繁的项目) 安全性需求(安全风险大的项目，如银行、核工厂) 管理需求：当时间紧迫或涉及法律、债务时，可以做以下调整： 指定某种开发过程，限期完成 按策略部分交付核收款，调整开发计划 其他交付物需求：安装、培训文档与教材，用户手册、Help文件或软件 ? 需求确认：模型确认(有评审会确认所作模型正确) 原型确认(作必要测试后，写出可行性报告) 需求确认(合同双方负责人、当事人、开发组联合审查) ? 需求管理：需求追踪(落实到项目计划，保证需求工程过程完成) 需求变更管理(规定管理机制和职责，保证需求变更时相应的其他工作产品也作出必要的调整) 从中看出需求工程完成后，应用项目的大体轮廓、工作量和技术难关都突显出来。项目变得具体、可望可及，而不是寄希望于几个软件开发高手的口头承诺。这是工程开发和软件作坊的基本差别。 对于不是正式