ISO标准软件工程模板共21页.docx
《ISO标准软件工程模板共21页.docx》由会员分享，可在线阅读，更多相关《ISO标准软件工程模板共21页.docx（29页珍藏版）》请在冰豆网上搜索。
ISO标准软件工程模板共21页
软件工程项目文档模板
单靠“死”记还不行,还得“活”用,姑且称之为“先死后活”吧。
让学生把一周看到或听到的新鲜事记下来,摒弃那些假话套话空话,写出自己的真情实感,篇幅可长可短,并要求运用积累的成语、名言警句等,定期检查点评,选择优秀篇目在班里朗读或展出。
这样,即巩固了所学的材料,又锻炼了学生的写作能力,同时还培养了学生的观察能力、思维能力等等,达到“一石多鸟”的效果。
可行性研究报告（ISO标准）
要练说，得练听。
听是说的前提，听得准确，才有条件正确模仿，才能不断地掌握高一级水平的语言。
我在教学中，注意听说结合，训练幼儿听的能力，课堂上，我特别重视教师的语言，我对幼儿说话，注意声音清楚，高低起伏，抑扬有致，富有吸引力，这样能引起幼儿的注意。
当我发现有的幼儿不专心听别人发言时，就随时表扬那些静听的幼儿，或是让他重复别人说过的内容，抓住教育时机，要求他们专心听，用心记。
平时我还通过各种趣味活动，培养幼儿边听边记，边听边想，边听边说的能力，如听词对词，听词句说意思，听句子辩正误，听故事讲述故事，听谜语猜谜底，听智力故事，动脑筋，出主意，听儿歌上句，接儿歌下句等，这样幼儿学得生动活泼，轻松愉快，既训练了听的能力，强化了记忆，又发展了思维，为说打下了基础。
1．引言
一般说来，“教师”概念之形成经历了十分漫长的历史。
杨士勋（唐初学者，四门博士）《春秋谷梁传疏》曰：
“师者教人以不及，故谓师为师资也”。
这儿的“师资”，其实就是先秦而后历代对教师的别称之一。
《韩非子》也有云：
“今有不才之子……师长教之弗为变”其“师长”当然也指教师。
这儿的“师资”和“师长”可称为“教师”概念的雏形，但仍说不上是名副其实的“教师”，因为“教师”必须要有明确的传授知识的对象和本身明确的职责。
1.1编写目的
[编写本可行性研究报告的目的，指出预期的读者。
]
1.2背景
a.[所建议开发的软件系统的名称；]
b.[本项目的任务提出者、开发者、用户及实现该软件的单位；]
c.[该软件系统同其他系统或其他机构的基本的相互来往关系。
]
1.3定义
[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
]
1.4参考资料
[列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括：
项目经核准的计划任务书、合同或上级机关的批文；
与项目有关的已发表的资料；
文档中所引用的资料，所采用的软件标准或规范。
]
2．可行性研究的前提
[说明对所建议开发的软件的项目进行可行性研究的前提。
]
2.1要求
[说明对所建议开发的软件的基本要求。
如
功能；
性能；
输出；
输入；
基本的数据流程和处理流程；
安全与保密要求；
与软件相关的其他系统；
完成期限。
]
2.2目标
[说明所建议系统的主要开发目标。
如：
人力与设备费用的节省；
处理速度的提高；
控制精度或生产能力的提高；
管理信息服务的改进；
决策系统的改进；
人员工作效率的提高，等等。
]
2.3条件、假定和限制
[说明对这项开发中给出的条件、假定和所受到期的限制。
可包括：
建议开发软件运行的最短寿命；
进行系统方案选择比较的期限；
经费来源和使用限制；
法律和政策方面的限制；
硬件、软件、运行环境和开发环境的条件和限制；
可利用的信息和资源；
建议开发软件投入使用的最迟时间。
]
2.4进行可行性研究的方法
[说明这项可行性研究将是如何进行的，所建议的系统将是如何评价的，摘要说明所使用的基本方法和策略。
]
2.5评价尺度
[说明对系统进行评价时所使用的主要尺度。
决定可行性的主要因素]
3．对现有系统的分析
[这里的现有系统是指当前实际使用的系统，这个系统可能是计算机系统，也可能是一个机械系统甚至是一个人工系统。
]
[分析现有系统的目的是为了进一步阐明建议中的开发新系统或修改现有系统的必要性。
]
3.1处理流程和数据流程
[说明现有系统的基本的处理流程和数据流程。
此流程可用图表即流程图的形式表示，并加以叙述。
]
3.2工作负荷
[列出现有系统所承担的工作及工作量。
]
3.3费用开支
[列出由于运行现有系统所引起的费用开支。
如人力、设备、空间、支持性服务、材料等项开支。
]
3.4人员
[列出为了现有系统的运行和维护所需要的人员的专业技术类别和数量。
]
3.5设备
[列出现有系统所使用的各种设备。
]
3.6局限性
[说明现有系统存在的问题以及为什么需要开发新的系统。
]
4．所建议的系统
4.1对所建议系统的说明
[概括地说明所建议系统，并说明在第2条中列出的那些要求将如何得到满足，说明所使用的基本方法及理论根据。
]
4.2处理流程和数据流程。
[给出所建议系统的处理流程式和数据流程。
]
4.3改进之处
[按2.2条中列出的目标，逐项说明所建议系统相对于现存系统具有的改进。
]
4.4影响
[说明新提出的设备要求及对现存系统中尚可使用的设备须作出的修改。
]
4.4.1.对设备的影响
[说明新提出的设备要求及对现存系统中尚可使用的设备须作出的修改]
4.4.2.对软件的影响
[说明为了使现存的应用软件和支持软件能够同所建议系统相适应，而需要对这些软件所进行的修改和补充。
]
4.4.3.对用户单位机构的影响
[说明为了建立和运行所建议系统，对用户单位机构、人员的数量和技术水平等方面的全部要求。
]
4.4.4.对系统运行过程的影响
[说明所建议系统对运行过程的影响。
]
4.4.5.对开发的影响
[说明对开发的影响。
]
4.4.6.对地点和设施的影响
[说明对建筑物改造的要求及对环境设施的要求。
]
4.4.7.对经费开支的影响
[扼要说明为了所建议系统的开发，统计和维持运行而需要的各项经费开支。
]
4.5技术条件方面的可能性
[本节应说明技术条件方面的可能性
包括：
在限制条件下，功能目标是否能达到；
利用现有技术，功能目标能否达到；
对开发人员数量的和质量的要求，并说明能否满足；
在规定的期限内，开发能否完成。
5．可选择的其他系统方案
[扼要说明曾考虑过的每一种可选择的系统方案，包括需开发的和可从国内国外直接购买的，如果没有供选择的系统方案可考虑，则说明这一点。
]
5.1可选择的系统方案1
[说明可选择的系统方案1，并说明它末被选中的理由。
]
5.2可选择的系统方案2
[按类似5.1条的方式说明第2个乃至第n个可选择的系统方案。
]
6．投资及效益分析
6.1支出
[对于所选择的方案，说明所需的费用，如果已有一个现存系统，则包括该系统继续运行期间所需的费用。
]
6.1.1基本建设投资
[包括采购、开发和安装所需的费用。
]
6.1.2其他一次性支出
6.1.3非一次性支出
[列出在该系统生命期内按月或按季或按年支出的用于运行和维护的费用。
]
6.2收益
[对于所选择的方案，说明能够带来的收益，这里所说的收益，表现为开支费用的减少或避免、差错的减少、灵活性的增加、动作速度的提高和管理计划方面的改进等，包括：
6.2.1一次性收益
[说明能够用人民币数目表示的一次性收益，可按数据处理、用户、管理和支持等项分类叙述。
]
6.2.2非一次性收益
[说明在整个系统生命期内由于运行所建议系统而导致的按月的、按年的能用人民币数目表示的收益，包括开支的减少和避免。
]
6.2.3不可定量的收益
[逐项列出无法直用人民币表示的收益。
]
6.3收益/投资比
[求出整个系统生命期的收益/投资比值。
]
6.4投资回收周期
[求出收益的累计数开始超过支出的累计数的时间。
]
6.5敏感性分析
[敏感性分析是指一些关键性因素，如：
系统生存周期长短、系统工作负荷量、处理速度要求、设备和软件配置变化对支出和效益的影响等的分析。
]
7．社会因素方面的可能性
7.1.法律方面的可行性
[如，合同责任、侵犯专利权、侵犯版权等问题的分析。
]
7.2.使用方面的可行性
[如，用户单位的行政管理、工作制度、人员素质等能否满足要求。
]
8．结论
[在进行可行性研究报告的编制时，必须有一个研究的结论]
结论意见可能是：
a.可行；
b.需要推迟某些条件（例如技术、人力、设备等）落实之后才能开始进行；
c.需要对开发目标进行某些修改之后才能开始进行；
d.不能进行或不必进行（例如因技术不成熟、技术风险太大等）。
需求分析文档（需求规格说明书（ISO标准版））
当需求调查、分析工作告一段落时，你就需要将这些需求进行规格化描述，整理成文，即软件需求规格说明书，也就是SRS。
这是在软件项目过程中最有价值的一个文档。
ISO所提供的标准虽然已经时间久远，但还是颇具参考价值的。
1．引言
1.1编写的目的
[说明编写这份需求说明书的目的,指出预期的读者。
为明确软件需求、安排项目规划与进度、组织软件开发与测试，撰写本文档。
本文档供项目经理、设计人员、开发人员参考]
1.2背景
a.待开发的系统的名称；
b.本项目的任务提出者、开发者、用户；
c.该系统同其他系统或其他机构的基本的相互来往关系。
1.3定义
[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
]
1.4参考资料
[列出用得着的参考资料。
项目经核准的计划任务书、合同或上级机关的批文
项目开发计划
文档所引用的资料、标准和规范。
列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源
]
2．任务概述
2.1目标
[叙述该系统开发的意图、应用目标、作用范围以及其他应向读者说明的有关该系统开发的背景材料。
解释被开发系统与其他有关系统之间的关系。
]
2.2用户的特点
[列出本系统的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本系统的预期使用频度。
]
2.3假定和约束
[列出进行本系统开发工作的假定和约束。
]
3．需求规定
（3．数据描述
3.1静态数据
3.2动态数据
【包括输入数据和输出数据。
】
3.3数据库介绍
【给出使用数据库的名称和类型。
】
3.4数据词典
3.5数据采集）括号内的为小型项目所使用，可不再重新编写数据规格说明书）
3.1对功能的规定
[用列表的方式，逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎么样的处理、得到什么输出，说明系统的容量,包括系统应支持的终端数和应支持的并行操作的用户数等指标。
]
3.2对性能的规定
3.2.1精度
[说明对该系统的输入、输出数据精度的要求，可能包括传输过程中的精度。
]
3.2.2时间特性要求
[说明对于该系统的时间特性要求。
]
3.2.3灵活性
[说明对该系统的灵活性的要求，即当需求发生某些变化时，该系统对这些变化的适应能力。
]
3.3输入输出要求
[解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。
对系统的数据输出及必须标明的控制输出量进行解释并举例。
]
3.4数据管理能力要求（针对软件系统）
[说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。
]
3.5故障处理要求
[列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
]
3.6其他专门要求
[如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
]
4．运行环境规定
4.1设备
[列出运行该软件所需要的硬设备。
说明其中的新型设备及其专门功能，包括：
a.处理器型号及内存容量
b.外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量
c.输入及输出设备的型号和数量，联机或脱机
d.数据通信设备的型号和数量
e.功能键及其他专用硬件
4.2支持软件
[列出支持软件，包括要用到的操作系统、编译程序、测试支持软件等。
]
4.3接口
[说明该系统同其他系统之间的接口、数据通信协议等。
]
4.4控制
[说明控制该系统的运行的方法和控制信号，并说明这些控制信号的来源。
]
项目计划书
随着现代软件工程思想的普及，迭代的、增量的开发生命周期已经被认识并付诸实践，针对这样的生命周期，其项目计划的格式也需要做出相应的调整。
1.文档概述
[在此对整个文档进行概要性描述，另外还应列出该计划的目标、范围、定义、术语、参考资料等内容。
]
1.1目标
[在此描述本项目计划的目标。
]
1.2范围
[简要说明该计划所覆盖的范围，以及与其相关的项目，与该文档有联系的事物。
]
1.3定义与术语
[在此列出在该计划中所涉及的所有术语、定义、缩写词的解释，这些信息也可以引用项目词汇表来提供。
]
1.4参考资料
[在此应列出项目计划中引用的文档列表，对于引用的每个文档都应该列出其标题、文档编号、日期，并且指出这些文档的来源，以方便该计划的阅读者查找。
]
1.5概述
[说明该计划其它部分所包含的内容，以及文档的组织方式。
]
2.项目概述
2.1项目目标
[指出该项目将会交付什么样的产品，能够帮助客户达到什么目标。
]
2.2假设与约束
[列举出制定该计划时所做的所有假设，以及列举出对该项目的解决方案的约束性要求，如特定的操作系统平台、特定的时间、特定的经费范围等。
]
2.3项目交付物
[具体列出该项目完成后，将交付哪些东西，并可以列出每个交付时间。
]
2.4项目计划更新总结
[建议采用表格的形式，将计划的修订过程列出来。
]
3.项目组织
3.1项目组织结构
[建议使用组织结构图的形式，将整个项目团队成员之间的关系与职责明确下来，甚至可以包括管理人员、各种委员会等。
]
3.2外部联系人
[列出开发组织之外的，所有与项目相关的外部人员的姓名、联系电话等资料。
]
3.3角色与职责
[明确项目开发各个任务的负责人或小组。
]
4.项目管理计划
4.1项目估计
[给出关于项目成本、进度的估计值，这些估计值将是项目计划制定的基础，也是今后重新评估、修改计划的基础。
你可以采用任何估算技术。
]
4.2项目计划
4.2.1阶段计划
[主要包括工作结构分解（WBS）、显示各个阶段或迭代时间安排的甘特图、主要里程碑与其验收标准。
]
4.2.2迭代目标
[如果你采用的是迭代式的开发方法，那么在此列出每次迭代的计划，以及每次迭代计划实现的目标。
]
4.2.3发行计划
[列出软件开发过程中各个中间版本的发行时间，包括演示版、Alpha版、Beta版等。
]
4.2.4项目进度表
[使用甘特图或PERT图等方法，表示出该项目的进度计划。
]
4.2.5项目资源计划
[在此处应列出项目所需的人员、设备等资源情况。
应指明所需人员的数量、技能要求，以及如何获取这些资源，是否要对人员进行必要的培训等。
]
4.2.6项目预算
[根据WBS和阶段计划分配成本，得到本项目的财务预算。
]
4.3迭代计划
[根据4.2.2小节的目标，具体列出每次迭代的详细计划。
该部分可以视需要将其单列为专题计划。
]
4.3.1迭代一
4.3.1.1计划
[列出此次迭代的时间线、小型里程碑等。
]
4.3.1.2资源
[列出此次迭代所需的人力、财力、设备等资源。
]
4.3.1.3用例
[列出此次迭代将要实现的用例。
]
4.3.1.4评估标准
[列出此次迭代的各项评测标准，包括功能、性能、容量、质量等。
]
4.4项目监督与控制
4.4.1需求管理计划
[有针对性对制定各类需求元素的管理与跟踪办法。
该部分可以视需要将其单列成为专题计划。
]
4.4.2进度控制计划
[说明如何对项目计划执行情况进行监控，将采用什么措施与管理手段。
]
4.4.3预算控制计划
[说明如何对项目的财务预算进行控制，以保证成本最小化。
]
4.4.4质量控制计划
[说明如何保证项目的质量，以及一些应急的应对措施。
该部分可以视需要将其单列成为专题计划。
]
4.4.5报告计划
[说明项目开发过程中，整个项目团队的报告机制，什么时候、谁、报送什么数据，从而形成规则。
]
4.4.6评测计划
[制定项目开发过程中将要度量与评测的指标，说明如何评测，如何应对。
该部分可以视需要将其单列成为专题计划。
]
4.5风险管理计划
[该部分可以视需要将其单列为专题计划。
]
4.5.1风险总述
[对项目所涉及的风险进行一个概要性描述。
]
4.5.2风险管理任务
[简要地说明在该项目中，风险管理所涉及的内容，可以包括用来确定风险的方法、对风险列表进行分析和确定优先级的方式、将采用的风险管理策略、对最严重的风险所计划的降低/规避或预防的策略、监测风险状态的方式、风险复审的时间表。
]
4.5.3风险管理的组织和职责
[列出与风险管理相关的个人或小组，并对其职责进行描述。
]
4.5.4工具与技术
[列出与风险管理将采用的工具软件或技术。
]
4.5.5纳入管理的风险项
[列出主要的风险项，并描述其影响以及应急措施。
具体可以参考后面的《风险条目跟踪表模板》。
]
4.6收尾计划
[列出在项目后期将要做的事，包括材料存档、汇报总结等。
]
5.相关技术
5.1开发案例
[给出本项目将采用的软件生命周期模型、过程规范等，从而对开发过程给予明确的指导。
该部分可以视需要将其单列为一个专题文件。
]
5.2方法、工具和技术
[列出本项目中将运用的方法、工具和技术，并给出适当的工作指南和说明。
]
5.3产品验收计划
[列出本项目验收工作的一些细节计划，本部分内容可以视需要将其单列为一个专题计划。
]
6．其它支持过程管理
6.1配置管理计划
[在此列出该项目所采用的配置管理过程，通常是单列为一个专题。
]
6.2评估计划
[列出本项目评估时所使用的技术、标准、指标和过程。
这里的评估包括走查、检查和复审。
]
6.3文档计划
6.4质量保证计划
6.5分包商管理计划
7.其他计划
8.附录
9.索引
数据要求说明书
如果在你的项目中有大量要求数据存储、数据采集等方面的需求，那么你就应该专门将这些需求进行整理，以数据要求说明书的形式表现出来。
1．引言
1.1编写目的
[说明编写这份数据要求说明书的目的，指出预期的读者。
]
1.2背景
a.待开发软件系统的名称；
b.列出本项目的任务提出者、开发者、用户以及将运行该项软件的计算站或计算机网络系统；
1.3定义
[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
]
1.4参考资料
[列出有关的参考资料。
]
2．数据的逻辑描述
[对数据进行逻辑描述时可把数据分为动态数据和静态数据。
]
2.1静态数据
[列出所有作为控制或参考用的静态数据元素。
]
2.2动态输入数据
[列出动态输入数据元素。
]
2.3动态输出数据
[列出动态输出数据元素。
]
2.4内部生成数据
[列出向用户或开发单位中的维护调试人员提供的内部生成数据。
]
2.5数据约定
[说明对数据要求的制约。
逐条列出对进一步扩充或使用方面的考虑而提出的对数据要求的限制。
对于在设计和开发中确定是临界性的限制更要明确指出。
]
3．数据的采集
3.1要求和范围
[按数据元的逻辑分组来说明数据采集的要求和范围，指明数据的采集方法，说明数据采集工作的承担者是用户还是开发者。
]
3.2输入的承担者
[说明预定的对数据输入工作的承担者。
如果输入数据同某一接口软件有关，还应说明该接口软件的来源。
]
3.3预期处理
[对数据的采集和预处理过程提出专门的规定，包括适合应用的数据格式、预定的数据通信媒体和对输入的时间要求等。
对于需经模拟转换或数字转换处理的数据量，要给出转换方法和转换因子等有关信息，以便软件系统使用这些数据。
]
3.4影响
[说明这些数据要求对于设备、软件、用户、开发单位所可能产生的影响。
]
概要设计文档
这是ISO提供的规范，是最原始的概要设计说明书的编写格式，其适用于结构化设计思想下的软件设计，不过其中还是有很多具有参考价值的内容。
1．引言
1.1编写目的
[说明编写这份概要设计说明书的目的，指出预期的读者。
]
1.2背景
a.[待开发软件系统的名称]；
b.[列出本项目的任务提出者、开发者、用户。
]
1.3定义
[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
]
1.4参考资料
[列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括：
项目经核准的计划任务书、合同或上级机关的批文；
项目开发计划；
需求规格说明书；
测试计划（初稿）；
用户操作手册（初稿）；
文档所引用的资料、采用的标准或规范。
]
2．总体设计
2.1需求规定（目标）
[说明对本系统的主要的输入输出项目、处理的功能性能要求。
包括]
2.1.1系统功能
2.1.2系统性能
2.1.2.1精度
2.1.2.2时间特性要求
2.1.2.3可靠性
2.1.2.4灵活性
2.1.3输入输出要求
2.1.4数据管理能力要求
2.1.5故障处理要求
2.1.6其他专门要求
2.2运行环境
[简要地说明对本系统的运行环境的规定。
]
2.2.1设备
[列出运行该软件所需要的硬设备。
说明其中的新型设备及其专门功能。
]
2.2.2支持软件
[列出支持软件，包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。
]
2.2.3接口
[说明该系统同其他系统之间的接口、数据通信协议等]
2.2.4控制
[说明控制该系统的运行的方法和控制信号，并说明这些控制信号的来源。
]
2.3基本设计概念和处理流程
[说明本系统的基本设计概念和处理流程，尽量使用图表的形式。
]
2.4结构
[给出系统结构总体框图（包括软件、硬件结构框图），说明本系统的各模块的划分，扼要说明每个系统模块的标识符和功能，分层次地给出各模块之间的控制与被控制关系。
]
2.5功能需求与系统模块的关系
[本条用一张矩阵图说明各项功能需求的实现同各模块的分配关系。
]
[系统模块1]
[系统模块2]
[……]
[系统模块m]
[功能需求1]
√
[功能需求2]
√
[┇]
[功能需求n]
√
√
2.6人工处理过程
[说明在本系统的工作过程中不得不包含的人工处理过程。
]
2.7尚未解决的问题
[说明在概要设计过程中尚未解决而设计者认为在系统完成之前必须解决的各个问题。
]
3．接口设计
3.1用户接口
[说明将向用户提供的命令和它们的语法结构，以及相应的回答信息。
]
[说明提供给用户操作的硬件控制面板的定义。
]
3.2外部接口
[说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持系统之间的接口关系。
]
3.3内部接口
[说明本系统之内的各个系统元素之间的接口的安排。
]
4．运行设计
4.1运行模块组合
[说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说明每种运行所历经的内部模块的支持软件。
]
4.2运行控制
[说明每一种外界的运行控制的方式方法和操作步骤。
]
4.3运行时间
[说明每种运行模块组合将占用各种资源的时间。
]
5．系统数据结构设计
[不涉及软件设计可不包含]
5.1逻辑结构设计要点
[给出本系统内软件所使用的每个数据结构的名称、标识符以及它们之中每个数据项、记录、文卷和系的标识、定义、长度及它们之间的层次的或表格的相互关系。
]
5
升级会员 