GBT 8566-2007 信息技术 软件生存周期过程
(新版)信息系统监理师(中级)考试题库(含答案)
（新版）信息系统监理师（中级）考试题库（含答案）单选题1.计划（Plan）、执行（Do）、（）和行动（Action），简称PDCA。
A、测试（Check）B、检查（Check）C、变更（Check）D、分析（Check）答案：B解析：计划（Plan）、执行（Do）、检查（Check）和行动（Action），简称PD CA。
2.某项目预计最快12天完成，最慢36天完成，21天完成的可能性最大。
公司下达的计划是18天完成，要使计划完成的概率达到50%，在计划中需要增加（）天应急时间。
A、4B、6C、8D、22答案：A解析：我们先计算出期望工期【（12+4*21+36）/6】，经过计算得出为22天。
此时我们画图，22天所处的位置是整个图横轴的中心位置，即在横轴50%的位置。
（因为期望工期计算出的为22，所以22肯定是在正中间）如下所示：我们先计算出期望工期【（12+4*21+36）/6】，经过计算得出为22天。
此时我们画图，22天所处的位置是整个图横轴的中心位置，即在横轴50%的位置。
（因为期望工期计算出的为22，所以22肯定是在正中间）如下所示：两个图形经过对比后，我们得知发现18、22都处于50%的位置。
如下所示：最终得出结论：公司计划值，距离22天还差4天。
因此计划中需要增加4天应急时间。
3.根据《合同法》的规定，下列经济合同中属于无效合同的有（）A、甲、乙双方对商品质量标准认识不统一，而错误签订的合同B、甲、丙双方签订的将无标签服装伪造成名牌进口服装的合同C、乙方未经丙方授权，代表丙方与丁签订的合同，经乙方追认的D、显失公平的合同答案：B解析：依据《合同法》的规定，属于下列情形的合同为无效合同：（1）恶意串通，损害国家、集体或者第三人利益（丙、乙双方串通签订的乙公司国有资产无偿转让合同）；（2）以合法形式掩盖非法目的（甲、丙双方签订的将无标签服装伪造成名牌进口4.在网络服务器群的后端，采用光纤通道等存储专用协议连接成的高速专用网络，使网络服务器与多种存储设备直接连接的存储方式是（）A、DASB、NASC、SAN答案：C解析：DAS，直接附属存储，表示一个或数个服务器物理连接到外部RAID的非共享端口上。
软件系统整体实施方案
第一章整体实施方案第一节项目概况1.建设背景合同是经营活动的重要载体，合同管理是经营管理活动的重要组成部分，合同管理信息系统建设是有效提升合同管理效率、防范合同风险、支撑经营决策的有力抓手。
建设贯穿集团全级次的合同管理信息系统，将合同管理信息大数据作为工具，加强对各单位经营管理行为依法合规情况的实时在线监控和风险分析，是提高集团公司战略管控能力的重要手段。
通过建设覆盖全生命周期的合同管理信息系统，与OA系统、XX综合管理系统（在建）等其他信息管理系统的高效协同，能够实现经营管理各领域、各流程、各要素大数据的统计分析，实现信息的集成与共享，提高集团公司经营管理信息化水平。
同时，随着集团的不断发展，业务量的快速增加，集团合同审核、签订、管理数量越来越多，投资、项目、采购、财务、法务等环节都对合同的管理提出不同的管理要求。
实现这些需求迫切必然要加强管理类信息系统的统筹建设。
合同管理数据反映着集团公司及各级单位的经营动态，统筹建设合同管理信息系统，能够实时获取全集团经营数据，及时预警合同有关经营风险，提高集团公司精细化管理能力。
因此，为了进一步有效的防范风险、优化管理、降低成本、提高效益，同时全面提升法制化管理水平，适应集团实现跨越式发展的需要，对合同加强管理和监督，借助网络信息技术，加强合同的动态控制管理、提高履约率已成为集团合同管理工作发展的当务之急。
通过合同信息基础平台建设，推动从信息采集、数据汇聚、统计分析等浅层应用向资源规划、全景展示、智慧决策等深度应用转变，推进合同管理水平的纵深发展，以科技信息技术推进集团合同工作的创新发展，促进集团充分发挥合同在集团改革发展中保驾护航，促进智慧管理发展，有力支撑和服务于智慧XX管理。
2.建设目标系统的建设应综合考虑业务和管理需求，考虑长远目标和近期目标的结合，建立高效率、集约化、智能化的集中统一合同管理信息化平台。
实现合同线上审批、闭环管理和统计分析等合规管理要求和决策支撑能力。
GBT 8566-2007 信息技术 软件生存周期过程
本标准为软件生存周期过程建立了一个公共框架，以供软件产业界使用，它包括在含有软件的系统、独立软件产品和软件服务的获取期间以及在软件产品的供应、运行和维护期间需应用的过程、活动和任务。
软件包括软固件的软件部分。
本标准了描述了软件生存周期过程的体系结构，但并未规定如何实施或执行各过程中包含的活动和任务的细节。
本标准并不打算规定要产生的文档的名称、格式或编写内容。
本标准并不规定一个特定的生存周期模型或软件开发方法。
术语：协定：确定将要建立的工作关系的期限和条件。
审核：由授权人员对软件产品和过程进行的独立评估，以便评估与需求的依从性。
评价：系统地确定一个实体项目满足其规定准则的程度固件：硬件装置和作为只读软件驻留在硬件装置中的计算机指令或计算机数据的组合，该软件不能在程序控制下方便地修改。
合格性认定：证实一个实体是否能够完成规定需求的过程合格性需求：为了证明一个软件产品依从其规格说明且可以在其目标环境中使用，该软件产品必须满足的一组准则或条件。
合格性测试：由开发方进行并由需方见证的测试，以证明软件产品符合其规格说明，并可以在其目标环境中使用。
确认：通过检查和提供客观证据来证实针对某一特定预期用途的需求已经得到满足验证：通过检查和提供客观证据来证实规定需求已经得到满足。
验证：验证检查某样东西是否符合之前已定好的标准，如：文档评审，要检查的东西是文档，检查标准就是文档的评审标准，又如：测试软件，要检查的东西就是软件，检查的标准就是软件的规格说明，包括功能说明，性能要求等。
确认：检查软件在最终的运行环境上是否达到预期的目标。
一般来说，就是调试、验收测试等，这些工作都是在真正的软件需要运行的环境上进行的，在最终环境上运行软件，确保软件符合使用要求。
其实确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。
而验证更多的是从开发方的角度来做评审、测试来验证产品的需求、架构设计等方面是否和用户要求的一致验证是代表你是否正确的做事情，而确认代表你是否做了正确的事情本标准把软件生存周期中可能执行的活动分为5个基本过程、9个支持过程和7个组织过程，每一生存周期过程划分为一组活动，每一活动进一步划分为任务5个基本过程：1、获取过程：为需方而定义的活动，启动，招标，合同，对供方监督，验收等2、供应过程：为供方而定义的活动，启动，准备投标，签订合同，编制计划，执行，交付和完成3、开发过程：为开发方而定义的活动：需求、设计、编码、测试、安装、验收4、运作过程：为操作方而定义的活动：运行测试，系统运行，用户支持5、维护过程：为维护方而定义的活动：问题和修改分析，修改实现，维护评审/验收，迁移，软件退役9个支持过程：1、文档编制过程2、配管管理过程3、质量保证过程4、验证过程：确定软件产品是否满足在以前的活动中施加于它们的要求和条件的过程。
信息化标准制订基础知识
2.标准制定流程
3.标准编写的基本要求
4.附加说明
0.国家信息化标准与应用
软件生命周期 需求 设计 开发 测试 运维
过程质量：GB/T 8566-2007 信息技术 软件生存周期过程 （2007-7-1）、 SJ/T 11234-2001 软件过程能力评估模型（2001-5-1）
3.标准编写的基本要求
3.7.3 规范性引用文件的标示方法 3.7.3.1 注日期的引用文件
a) 国家标准 国家标准号＋国家标准名称＋（对应的国际标准 ＋一致性程度标识）
b) 国际标准
国际标准号＋国际标准中文译名
3.标准编写的基本要求
3.7.3.2 不注日期的引用文件
a) 国家标准 国家标准号＋国家标准名称＋（与最新版 国际标准 对应的国家标准号＋最新版国 际标准＋一致性程度标识） b) 国际标准 国际标准号＋国际标准中文译名
3.标准编写的基本要求
3.9.6 参考文献
参考文献是不同于附录的一个独立的资料性补充要 素，应放在最后一个附录之后。 参考文献的起草应遵照GB/T 7714的有关规定。 参考文献所包含的内容： a) 在标准编制过程中参考过的文件 b) 资料性的引用文件 参考文献中引用原文时，应直接使用原文，无需将 原文进行翻译后列出。 参考文献标示方法与规范性引用文件的标示方法相 同，并对其所有文件进行排序。
3.标准编写的基本要求
3.9.5.2 附录的性质
a) 规范性附录 在这类附录中应给出标准正文的附加条款。 b) 资料性附录 在这类附录中应给出对理解或使用标准起辅助作 用的附加信息。
3.标准编写的基本要求
3.9.5.3 附录的提及
标准中的任何一个附录都应在正文中明确地提及， 而不应孤立地存在。 规范性附录在条文中的提及通常用“见附录”的形 式，资料性附录在条文中的提及通常用“参见附录”的 形式。
计算机软件工程国家标准目录明细
DZ/T 0169-1997 物探化探计算机软件开发规范1997-11-1GA 560-2005 互联网上网服务营业场所信息安全管理系统营业场所端与营业场所经营管理系统接口技术要求2006-1-1GA 662-2006 互联网公共上网服务场所信息安全管理系统上网服务场所端接口技术要求2007-1-1GA 663-2006 互联网公共上网服务场所信息安全管理系统远程通讯端接口技术要求2007-1-1GB/T 11457-1995 软件工程术语1995-1-2 ↓已被下行标准取代GB/T 11457-2006 信息技术软件工程术语2006-7-1 现行GB/T 12504-1990 计算机软件质量保证计划规范1991-7-1 已作废GB/T 12505-1990 计算机软件配置管理计划规范1991-7-1 已作废GB/T 13400.1-1992 网络计划技术常用术语1992-1-2 现行GB/T 13400.2-1992 网络计划技术网络图画法的一般规定1992-1-2 ↓已被下行标准取代GB/T 13400.2-2009 网络计划技术第2部分：网络图画法的一般规定2009-11-1 现行GB/T 13400.3-1992 网络计划技术在项目计划管理中应用的一般程序1992-1-2 ↓已被下行标准取代GB/T 13400.3-2009 网络计划技术第3部分：在项目管理中应用的一般程序2009-11-1 现行GB/T 13502-1992 信息处理程序构造及其表示的约定 1993-5-1 现行GB/T 14079-1993 软件维护指南1993-8-1 已作废GB/T 14085-1993 信息处理系统计算机系统配置图符号及约定1993-8-1 现行GB/T 14246.1-1993 信息技术可移植操作系统界面第1部分:系统应用程序界面(POSIX.1) 1993-12-1 现行GB/T 14394-1993 计算机软件可靠性和可维护性1994-1-1 ↓已被下行标准取代GB/T 14394-2008 计算机软件可靠性和可维护性管理 2008-12-01 现行GB/T 15532-1995 计算机软件单元测试1995-1-2 ↓已被下行标准取代GB/T 15532-2008 计算机软件测试规范2008-9-1 现行GB/T 15534-1995 信息处理系统数据库语言NDL 1995-12-1 已作废GB/T 15538-1995 软件工程标准分类法1995-1-2 已作废GB/T 15853-1995 软件支持环境1996-8-1 已作废GB/T 15936.4-1996 信息处理文本与办公系统办公文件体系结构(ODA)和交换格式第四部分:文件轮廓1996-10-1 现行GB/T 16260 -1996 信息技术软件产品评价质量特性及其使用指南1996-10-1 ↓已被下行标准取代GB/T 16260.1-2006 软件工程产品质量第1部分:质量模型2006-7-1 现行GB/T 16260.2-2006 软件工程产品质量第2部分:外部度量2006-7-1 现行GB/T 16260.3-2006 软件工程产品质量第3部分:内部度量2006-7-1 现行GB/T 16260.4-2006 软件工程产品质量第4部分:使用质量的度量2006-7-1 现行GB/T 16647-1996 信息技术信息资源词典系统(IRDS)框架1997-7-1 现行GB/T 16680-1996 软件文档管理指南1997-7-1 现行GB/T 16682.1-1996 信息技术国际标准化轮廓的框架和分类方法第1部分:框架1997-7-1 现行GB/T 16682.2-1996 信息技术国际标准化轮廓的框架和分类方法第2部分:OSI轮廓用的原则和分类方法1997-7-1 现行GB/T 16684-1996 信息技术信息交换用数据描述文卷规范1997-7-1 现行GB/T 17544-1998 信息技术软件包质量要求和测试1999-6-1 现行GB/T 17917-1999 商场管理信息系统基本功能要求2000-4-1 ↓已被下行标准取代GB/T 17917-2008 零售企业管理信息系统基本功能要求2009-6-1 现行GB/T 18234-2000 信息技术CASE工具的评价与选择指南2001-8-1 现行GB/T 18491.1-2001 信息技术软件测量功能规模测量第1部分：概念定义2002-6-1 现行GB/T 18492-2001 信息技术系统及软件完整性级别2002-6-1 现行GB/T 18714.1-2002 信息技术开放分布式处理参考模型第1部分：概述2002-10-1 现行GB/T 18714.2-2002 信息技术开放分布式处理参考模型第2部分：基本概念2002-10-1 现行GB/T 18714.3-2003 信息技术开放分布式处理参考模型第3部分：体系结构2004-8-1 现行GB/T 18905.1-2002 软件工程产品评价第1部分: 概述2003-5-1 现行GB/T 18905.2-2002 软件工程产品评价第2部分: 策划和管理2003-5-1 现行GB/T 18905.3-2002 软件工程产品评价第3部分: 开发者用的过程2003-5-1 现行GB/T 18905.4-2002 软件工程产品评价第4部分: 需方用的过程2003-5-1 现行GB/T 18905.5-2002 软件工程产品评价第5部分: 评价者用的过程2003-5-1 现行GB/T 18905.6-2002 软件工程产品评价第6部分: 评价模块的文档编制2003-5-1 现行GB/T 20157-2006 信息技术软件维护2006-7-1 现行GB/T 20158-2006 信息技术软件生存周期过程配置管理2006-7-1 现行GB/T 20917-2007 软件工程软件测量过程2007-7-1 现行GB/T 20918-2007 信息技术软件生存周期过程风险管理2007-7-1 现行GB/T 8566-1988 计算机软件开发规范1988-12-1 ↓已被下行标准取代GB/T 8566-1995 信息技术软件生存期过程1995-12-1 ↓已被下行标准取代GB/T 8566-2001 信息技术软件生存周期过程2002-6-1 ↓已被下行标准取代GB/T 8566-2007 信息技术软件生存周期过程2007-7-1 现行GB/T 8567-1988 计算机软件产品开发文件编制指南1988-7-1 ↓已被下行标准取代GB/T 8567-2006 计算机软件文档编制规范2006-7-1 现行GB/T 9385-1988 计算机软件需求说明编制指南1988-1-2 ↓已被下行标准取代GB/T 9385-2008 计算机软件需求规格说明规范2008-9-1 现行GB/T 9386-1988 计算机软件测试文件编制规范1988-12-1 ↓已被下行标准取代GB/T 9386-2008 计算机软件测试文件编制规范2008-9-1 现行GB/Z 18493-2001 信息技术软件生存周期过程指南2002-6-1 现行GB/Z 18914-2002 信息技术软件工程CASE工具的采用指南2003-5-1 现行GB/Z 20156-2006 软件工程软件生存周期过程用于项目管理的指南2006-7-1 现行GJB 437-1988 军用软件开发规范1988-6-1GJB 438A-1997 武器系统软件开发文档1998-5-1GJB 1419-1992 军用计算机软件摘要1993-3-1HB 6464-1990 软件开发规范1991-2-1 已作废HB 6465-1990 软件文档编制规范1991-2-1 已作废HB 6466-1990 软件质量保证计划编制规定1991-2-1 已作废HB 6467-1990 软件配置管理计划编制规定1991-2-1 已作废HB 6468-1990 软件需求分析阶段基本要求1991-2-1 已作废HB 6469-1990 软件需求规格说明编制规定1991-2-1HB/Z 177-1990 软件项目管理基本要求1991-2-1HB/Z 178-1990 软件验收基本要求1991-2-1HB/Z 179-1990 软件维护基本要求1991-2-1HB/Z 180-1990 软件质量特性与评价方法1991-2-1HB/Z 182-1990 状态机软件开发方法1991-2-1MH/T 0019-1999 中国民用航空总局管理信息系统基础信息规范2000-3-1SB/T 10264-1996 餐饮业计算机管理软件开发设计基本规范 1996-10-1SB/T 10265-1996 饭店业计算机管理软件开发设计基本规范 1996-10-1SJ 20681-1998 地空导弹指挥自动化系统软件模块通用规范1998-5-1SJ 20822-2002 信息技术软件维护2003-3-1SJ 20823-2002 信息技术软件生存周期过程配置管理2003-3-1SJ/T 11234-2001 软件过程能力评估模型2001-5-1SJ/T 11235-2001 软件能力成熟度模型2001-5-1SJ/T 11290-2003 面向对象的软件系统建模规范第1部分:概念与表示法2003-10-1SJ/T 11291-2003 面向对象的软件系统建模规范第3部分:文档编制2003-10-1SJ/Z 11289-2003 面向对象领域工程指南2003-10-1YDN 138-2006 基于PC终端的互联网内容过滤软件技术要求2006-8-16YDN 139-2006 基于PC终端的互联网内容过滤软件测试方法2006-8-16。
大学信息系统建设与运行维护管理办法
大学信息系统建设与运行维护管理办法（试行）第一章总则第一条为规范学校信息系统建设与运行维护工作，加强信息系统安全管理，提高信息系统建设与维护水平，根据学校相关文件精神及《软件生存周期过程》（GB/T8566 -2007）、《计算机软件文档编制规范》（GB/T8567-2006）等国家标准，结合学校实际情况以及信息化工作进程，特制定本办法。
第二条本办法所说的信息系统是指XXXX大学信息化工作项目中以及学校各单位建设的面向学校师生和公众的用于满足教学、科研、管理和服务的，主要包括各种业务信息服务的应用系统和面向公众服务的网站等，以下都简称“信息系统”。
第三条适用范围。
凡是列入到学校信息化建设项目中或者在学校信息化基础平台上运行的信息系统以及学校各单位建设的信息系统均适用本办法。
其他信息系统建设管理可以参照本办法执行。
第四条建设原则。
(一)信息系统建设应当遵循“安全稳定，责任明晰；开放共享，互联互通；简洁易用，注重体验”的原则。
(二)各单位在建设信息系统时必须将其网络安全放在首要位置，信息系统的安全与信息系统同步规划、同步建设、同步投入运行。
(三)信息系统的建设与运行维护按照“谁主管谁负责，谁使用谁负责，谁运维谁负责”的总要求进行流程规范和责任明晰；业务系统建设和集成由业务部门主导，公共服务系统建设主要由信息化建设与管理中心负责。
(四)信息系统在建设时应当充分考虑数据共享，减少数据的重复收集，应与公共服务信息系统和其他业务系统之间互联互通，避免建成“信息孤岛”。
(五)信息系统在设计和开发时应当充分考虑当前技术发展潮流，界面应简洁、易用、高效，用户体验良好。
第五条阶段划分。
信息系统的建设与运行维护分为需求分析、系统设计、系统开发、系统测试、安全监测、初步验收、上线试运行和运行维护八个阶段。
第二章单位与职责第六条信息系统建设与运行维护过程中，涉及到的单位主要包括信息化建设与管理中心、建设单位、开发单位和对接单位。
(完整word版)软件生命周期的六个阶段
软件生命周期的六个阶段
1、问题的定义及规划
此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
2、需求分析
在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。
需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。
"唯一不变的是变化本身。
"，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。
3、软件设计
此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。
软件设计一般分为总体设计和详细设计。
好的软件设计将为软件程序编写打下良好的基础。
4、程序编码
此阶段是将软件设计的结果转换成计算机可运行的程序代码。
在程序编码中必须要制定统一，符合标准的编写规范。
以保证程序的可读性，易维护性，提高程序的运行效率。
5、软件测试
在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。
整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。
测试的方法主要有白盒测试和黑盒测试两种。
在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
6、运行维护
软件维护是软件生命周期中持续时间最长的阶段。
在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。
要延续软件的使用寿命，就必须对软件进行维护。
软件的维护包括纠错性维护和改进性维护两个方面。
最新gbt 8566-2007 信息技术 软件生存周期过程培训资料
考试国标知识点（二）：GB/T 8566-2007 信息技术软件生存周期过程本标准为软件生存周期过程建立了一个公共框架，以供软件产业界使用，它包括在含有软件的系统、独立软件产品和软件服务的获取期间以及在软件产品的供应、运行和维护期间需应用的过程、活动和任务。
软件包括软固件的软件部分。
本标准了描述了软件生存周期过程的体系结构，但并未规定如何实施或执行各过程中包含的活动和任务的细节。
本标准并不打算规定要产生的文档的名称、格式或编写内容。
本标准并不规定一个特定的生存周期模型或软件开发方法。
术语：协定：确定将要建立的工作关系的期限和条件。
审核：由授权人员对软件产品和过程进行的独立评估，以便评估与需求的依从性。
评价：系统地确定一个实体项目满足其规定准则的程度固件：硬件装置和作为只读软件驻留在硬件装置中的计算机指令或计算机数据的组合，该软件不能在程序控制下方便地修改。
合格性认定：证实一个实体是否能够完成规定需求的过程合格性需求：为了证明一个软件产品依从其规格说明且可以在其目标环境中使用，该软件产品必须满足的一组准则或条件。
合格性测试：由开发方进行并由需方见证的测试，以证明软件产品符合其规格说明，并可以在其目标环境中使用。
确认：通过检查和提供客观证据来证实针对某一特定预期用途的需求已经得到满足验证：通过检查和提供客观证据来证实规定需求已经得到满足。
验证：验证检查某样东西是否符合之前已定好的标准，如：文档评审，要检查的东西是文档，检查标准就是文档的评审标准，又如：测试软件，要检查的东西就是软件，检查的标准就是软件的规格说明，包括功能说明，性能要求等。
确认：检查软件在最终的运行环境上是否达到预期的目标。
一般来说，就是调试、验收测试等，这些工作都是在真正的软件需要运行的环境上进行的，在最终环境上运行软件，确保软件符合使用要求。
其实确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。
而验证更多的是从开发方的角度来做评审、测试来验证产品的需求、架构设计等方面是否和用户要求的一致验证是代表你是否正确的做事情，而确认代表你是否做了正确的事情本标准把软件生存周期中可能执行的活动分为5个基本过程、9个支持过程和7个组织过程，每一生存周期过程划分为一组活动，每一活动进一步划分为任务5个基本过程：1、获取过程：为需方而定义的活动，启动，招标，合同，对供方监督，验收等2、供应过程：为供方而定义的活动，启动，准备投标，签订合同，编制计划，执行，交付和完成3、开发过程：为开发方而定义的活动：需求、设计、编码、测试、安装、验收4、运作过程：为操作方而定义的活动：运行测试，系统运行，用户支持5、维护过程：为维护方而定义的活动：问题和修改分析，修改实现，维护评审/验收，迁移，软件退役9个支持过程：1、文档编制过程2、配管管理过程3、质量保证过程4、验证过程：确定软件产品是否满足在以前的活动中施加于它们的要求和条件的过程。
GBT 14394-2008 计算机软件可靠性和可维护性管理
计算机软件可靠性和可维护性管理Computer software reliability and maintainability management本标准依据GB/T 8566-2007《信息技术软件生存周期过程》划分软件生存周期，按过程和活动描述软件可靠性和可维护性要目录1.范围 (2)2.规范性引用文件 (2)3.术语和定义 (2)3.1软件可靠性大纲SOFTWARE RELIABLILITY PROGRAM (2)3.2软件可靠性大纲SOFTWARE MANTAINABILITY PROGRAM (2)3.3软件FRACAS SOFTWARE FAILURE REPORTING ANALYSIS AND CORRECTIVE ACTION SYSTEM .. 24.软件生存周期 (2)4.1在软件生存周期基本过程中的可靠性和可维护性管理要求 (2)4.1.1在获取过程中的可靠性和可维护性管理要求 (3)4.1.2在供应过程中的可靠性和可维护性管理要求 (3)4.1.3在开发过程中的可靠性和可维护性管理要求 (4)4.1.4在运作过程和维护过程中的可靠性和可维护性管理要求 (4)5.软件可靠性大纲和可维护性大纲 (4)5.1制定大纲应考虑的主要因素 (5)5.2大纲应包括的主要活动 (5)5.2.1制定大纲目标 (5)5.2.2分析运行环境 (5)5.2.3软件可靠性和可维护性要求的可行性论证 (6)5.2.4选定或制定规范和准则 (6)5.2.5软件可靠性和可维护性分析 (6)5.2.6评审 (7)5.2.7文档和数据 (7)5.2.8培训 (8)5.2.9维护保障要求 (8)5.3示例 (8)5.4裁剪 (9)1.范围本标准规定了软件产品在其生存周期内如何选择适当的软件可靠性和可维护性管理要素，并指导软件可靠性大纲和可维护性大纲的制定和实施本标准适用于软件产品生存周期的基本过程。
2.规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。
第二章 软件生存周期与软件过程
统计性 使用测
试
验证
2.5 统一过程和敏 捷过程
2.5.1统一过程
统一过程描述了软件开发中各个环节 应该做什么，怎么做，什么时候做以及为 什么要做，描述了一组以某种顺序完成的 活动。
统一过程在一个二维空间中描述软件 开发活动，水平轴代表时间，显示了动态 过程的一面。垂直轴代表过程静态的一面 其中活动代表怎么做，用产品表示做什么 ，用人员表示谁来做，用工作流表示什么 时候来描述。
2.3.1 增量模型（渐增模型） (Incremental Model)
先完成一个系统子集的开发，再按同样的开发 步骤增加功能 (系统子集),如此递增下去直至 满足全部系统需求。
系统的总体设计在初始子集设计阶段就应作出 设想。
增量1 需求
设计
和设计
交付客户
增量2
需求
设计 实现和集成
交付客房
增量3
统一过程有四个阶段
1.初始阶段
本阶段确定所设立的项目是否可行。
2.细化阶段
识别出剩余的大多数用例。对当前迭代的每个用例 进行细化，分析用例的处理流程，状态细节以及可能 发生的状态变化。
3.构造阶段
识别出剩余的用例。每一次迭代开发都是针对用例 进行分析，设计，编码，测试和集成的过程，所得到 的产品是满足项目需求的一个子集。由于细化阶段的 软件设计已经完成，这样各项目可以并行开发。
为保证软件质量，瀑布模型每一阶段必 须完成规定的文档，并对文档进行复审， 及早发现问题消除隐患。可参照下图如：
• 传统的瀑布模型过于理想化。事实上， 人在工作过程中不可能不犯错误。
• 在设计阶段可能发生规格说明文档中的 错误。
• 而设计上的缺陷或错误可能在实现过程 中显现出来。
(完整word版)计算机软件开发规范8566-88
标准：计算机软件开发规范GB 8566-88目的：详细规定计算机软件开发过程胡各个阶段及没法儿阶段胡任务、实施步骤、实施要求、完成标志及交付文件。
为软件开人员和管理人员提供一系列之有效的准则、方法和规范.作用：有利于提高开发的控制和管理，缩短开发时间和减少维护次数，便于开发和维护人员之间的协作、交流,是软件开发更加有成效。
软件的生存周期：Systems Development Life Cycle (SDLC）可行性研究与计划需求分析概要设计详细设计实现组装测试确认测试使用和维护按照人们所习惯的粗分方法把上面8 个阶段划分为计划、开发和维护3个阶段,在概述其他两个阶段的基础上重点介绍软件的开发过程2. 软件开发方法求。
瀑布模型瀑布模型阶段任务渐进模型V模型双v模型螺旋模型快速原型（Rapid Prototype)模型：快速原型模型在功能上等价于产品的一个子集。
注意,这里说的是功能上.瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题.一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品.这个产品只是实现部分的功能（最重要的)。
它最重要的目的是为了确定用户的真正需求。
在我的经验中，这种方法非常的有效，原先对计算机没有丝毫概念的用户在你的原型面前往往口若悬河，有些观点让你都觉得非常的吃惊。
在得到用户的需求之后，原型将被抛弃。
因为原型开发的速度很快，设计方面是几乎没有考虑的,如果保留原型的话，在随后的开发中会为此付出极大的代价。
V模型指出:单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求.螺旋模型:沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：（1）制定计划：确定软件目标，选定实施方案,弄清项目开发的限制条件;（2）风险分析：分析评估所选方案，考虑如何识别和消除风险;（3) 实施工程：实施软件开发和验证；（4）客户评估：评价开发工作，提出修正建议,制定下一步计划。
计算机软件及应用软件开发生命周期
9
本章要点
一、生存期模型定义二、常用生存期模型瀑布V模型原型增量螺旋式快速应用开发渐近式阶段三、案例分析
10
WaterFall model
瀑布模型是将软件生存周期各活动规定为依线性顺序联接的若干阶段的模型。
11
WaterFall model
12
13
WaterFall model适合的项目
项目的需求在项目开始前很明确解决方案在项目开始前也很明确类似的项目如：公司的财务系统库存管理系统短期项目
本章要点
一、生存期模型定义二、常用生存期模型三、案例分析
44
案例分析
“School项目”应该采用什么生存期模型？
45
学生成绩管理主要包括数据维护、成绩查询和成绩统计等三大功能模块。其中数据维护应实现班级、学生、课程和课程成绩等信息的录入、修改和删除等功能；成绩查询包括按学生查询其所有课程的成绩、按课程查询所有学生的成绩、按课程和班级查询所有学生的成绩；成绩统计包括按学生统计学分、平均成绩、班级名次和不及格课程门数，按课程统计学生平均成绩、及格率、优良率（80及以上为优良）。
14
本章要点
一、生存期模型定义二、常用生存期模型瀑布V模型原型增量螺旋式快速应用开发渐近式阶段三、案例分析
15
V模型
接收测试
集成测试
系统测试
项目规化
需求分析
总体设计
详细设计
编码和调试
集成测试
单元测试
16
V模型模型适合的项目
项目的需求在项目开始前很明确解决方案在项目开始前也很明确对系统的性能安全很严格的项目类似的项目如：航天飞机等公司的财务系统
26
Spiral Model适合的项目
信息系统监理规划
XXX市自然资源局XXX市市级国土空间规划“一张图”建设项目监理规划XXXX信息科技有限公司2021年5月版本历史目录第一章工程概况 (1)1.1工程项目名称 (1)1.2工程预计总投资 (1)1.3项目预计工期 (1)1.4项目建设单位 (1)1.5项目承建单位 (1)1.6项目测评单位 (2)1.7项目监理单位 (2)1.8工程项目地点 (2)1.9工程项目建设内容 (2)第一部分工业互联网服务与监测系统 (2)第二部分工业互联网政务服务接入系统 (4)第三部分工业互联网标识解析服务系统 (4)第二章监理依据 (5)2.1本项目相关依据 (5)2.2相关政策与法规 (5)2.3技术标准与规范 (6)第三章监理范围 (7)3.1质量控制 (7)3.2进度控制 (7)3.3投资控制 (8)3.4合同管理 (8)3.5信息管理 (8)3.6协调 (8)第四章监理目标 (9)4.1质量控制目标 (9)4.2进度控制目标 (9)4.3投资控制目标 (10)4.4变更控制目标 (10)4.5合同管理目标 (10)4.6信息管理目标 (10)4.7信息安全管理目标 (10)4.8组织协调管理目标 (11)第五章监理内容 (11)5.1招标阶段 (11)5.1.1招标阶段的质量控制 (11)5.1.2招标阶段的进度控制 (12)5.1.3招标阶段的投资控制 (12)5.1.4招标阶段的合同管理 (12)5.1.5招标阶段信息管理 (13)5.1.6招标阶段协调 (13)5.2设计阶段 (13)5.2.1设计阶段质量控制 (13)5.2.2设计阶段进度控制 (14)5.2.3设计阶段投资控制 (14)5.2.4设计阶段合同管理 (15)5.2.5设计阶段信息管理 (15)5.2.6设计阶段协调 (15)5.3实施阶段 (16)5.3.1实施阶段质量控制 (16)5.3.3实施阶段的投资控制 (18)5.3.4实施阶段的合同管理 (18)5.3.5实施阶段的信息管理 (19)5.3.6实施阶段的协调 (19)5.4验收阶段 (19)5.4.1验收阶段的质量控制 (19)5.4.2验收阶段的进度控制 (20)5.4.3验收阶段的投资控制 (21)5.4.4验收阶段的合同管理 (21)5.4.5验收阶段的信息管理 (21)5.4.6验收阶段的协调 (21)第六章监理及人员职责 (22)6.1监理组织结构 (22)6.2监理人员配备 (22)6.3监理人员职责 (23)6.3.1总监理工程师职责 (23)6.3.2专业监理工程师职责 (24)6.3.3监理员职责 (24)第七章监理工作方法及措施 (24)7.1质量控制方法和措施 (24)7.1.1评审 (24)7.1.2测试 (25)7.1.3旁站 (25)7.1.4抽查 (26)7.2进度控制方法和措施 (26)7.2.2进度控制措施 (26)7.3投资控制的方法和措施 (27)7.3.1投资控制方法 (27)7.3.2投资控制措施 (27)7.4信息管理的方法和措施 (28)7.4.1信息管理方法 (28)7.4.2信息管理措施 (29)7.5组织协调的方法和措施 (29)7.5.1监理会议 (29)7.5.2监理报告 (30)7.5.3沟通 (31)第八章监理工具与设施 (31)第九章监理工作制度 (31)9.1人员管理制度 (31)9.2文档资料内审制度 (32)9.3沟通协调制度 (32)9.4开工审核、审批制度 (32)9.5评审制度 (32)9.6应急事件处理制度 (33)第一章工程概况1.1 工程项目名称XXX市市级国土空间规划“一张图”建设项目1.2 工程预计总投资本项目预计总投资为4080000.00元(人民币大写：肆佰零捌万元整)1.3 项目预计工期（1）项目标的第一部分和第二部分内容，即工业互联网服务与监测系统和工业互联网政务服务接入系统，要求2020年2月底前上线试运行，试运行不低于3个月。
系统分析师上午试题分析与解答.docx
系统分析师上午试题分析与解答试题(1)关于用例和类，错误的说法是_ (1)。
(1)A.两者都属于模型图的构成元素B. 存在抽象用例和抽象类C. 类图描述系统的部分静态视图，用钢图描述系统与用户之间的交互视图D. 两者都可以用来描述系统的内部结构试题⑴分析本题考査面向对象分析与设计的基础知识。
用例描述业务场景或事件，系统必须对这些场量或事件提供确定的响应，是用例图的主要结构元素，用例图用来描述系统与外部系统以及用户之间的交互视图。
类是共亭相同属性和行为的对象集合，是类图的主要组成元素，类图是系统静态对象结构的图形描述。
抽象用例通过组合儿个用例公共的步骤降低用例之间的兀余，抽象类是包含一种或多种抽象方法的类，它本身不需要构造实例。
参考答案(1) D . •试题(2)(2) 适用于描述复杂算法的执行流程。
(2) A.活动图 B.状态图 C.类图 D.用例图试题(2)分析本题考査面向对象分析与设计的基础知识。
活动图用来描述一个业务流程，说明活动之间的依赖关系。
状态图显未出对象可能的状态以及由状态改变而导致的转移。
活动图和状态图之间是有关系的。
状态图把焦点集中在过程中的对象身上,而活动图则集中在一个单独过程中的动作流程。
类图通过显示出系统的类以及这些类之间的关系來表示系统，是系统静态对象结构的图形描述。
用例图用来描述系统与外部系统以及用户Z间的交互视图，强调这个系统是什么而不是这个系统怎么工作。
参考答案(2) A试题(3)在面向对象方法中，信息流是通过向参与者或内部对象发送消息形成的。
二用于描述进出系统的信息流。
（3） A.协作图B ・顺序图• C.数据流图D.流程图试题（3）分析•本题考査面向对象分析与设计的基础知识。
状态图描述了一个对彖在其生命周期中可能的状态组合；顺序图用来描述对象按照 时间顺序的消息流来建模用例；数据流图是-•种描述数据通过系统的流程以及系统实施 的工作或处理过程的过程模型；流程图以图形化的方式展示应用程序从数据输入开始到 获得输出为止的逻辑过程。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
考试国标知识点（二）：GB/T 8566-2007 信息技术软件生存周期过程
本标准为软件生存周期过程建立了一个公共框架，以供软件产业界使用，它包括在含有软件的系统、独立软件产品和软件服务的获取期间以及在软件产品的供应、运行和维护期间需应用的过程、活动和任务。
软件包括软固件的软件部分。
本标准了描述了软件生存周期过程的体系结构，但并未规定如何实施或执行各过程中包含的活动和任务的细节。
本标准并不打算规定要产生的文档的名称、格式或编写内容。
本标准并不规定一个特定的生存周期模型或软件开发方法。
术语：
协定：确定将要建立的工作关系的期限和条件。
审核：由授权人员对软件产品和过程进行的独立评估，以便评估与需求的依从性。
评价：系统地确定一个实体项目满足其规定准则的程度
固件：硬件装置和作为只读软件驻留在硬件装置中的计算机指令或计算机数据的组合，该软件不能在程序控制下方便地修改。
合格性认定：证实一个实体是否能够完成规定需求的过程
合格性需求：为了证明一个软件产品依从其规格说明且可以在其目标环境中使用，该软件产品必须满足的一组准则或条件。
合格性测试：由开发方进行并由需方见证的测试，以证明软件产品符
合其规格说明，并可以在其目标环境中使用。
确认：通过检查和提供客观证据来证实针对某一特定预期用途的需求已经得到满足
验证：通过检查和提供客观证据来证实规定需求已经得到满足。
验证：验证检查某样东西是否符合之前已定好的标准，如：文档评审，要检查的东西是文档，检查标准就是文档的评审标准，又如：测试软件，要检查的东西就是软件，检查的标准就是软件的规格说明，包括功能说明，性能要求等。
确认：检查软件在最终的运行环境上是否达到预期的目标。
一般来说，就是调试、验收测试等，这些工作都是在真正的软件需要运行的环境上进行的，在最终环境上运行软件，确保软件符合使用要求。
其实确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。
而验证更多的是从开发方的角度来做评审、测试来验证产品的需求、架构设计等方面是否和用户要求的一致
验证是代表你是否正确的做事情，而确认代表你是否做了正确的事情本标准把软件生存周期中可能执行的活动分为5个基本过程、9个支持过程和7个组织过程，每一生存周期过程划分为一组活动，每一活动进一步划分为任务
5个基本过程：
1、获取过程：为需方而定义的活动，启动，招标，合同，对供方监督，验收等
2、供应过程：为供方而定义的活动，启动，准备投标，签订合同，
编制计划，执行，交付和完成
3、开发过程：为开发方而定义的活动：需求、设计、编码、测试、安装、验收
4、运作过程：为操作方而定义的活动：运行测试，系统运行，用户支持
5、维护过程：为维护方而定义的活动：问题和修改分析，修改实现，维护评审/验收，迁移，软件退役
9个支持过程：
1、文档编制过程
2、配管管理过程
3、质量保证过程
4、验证过程：确定软件产品是否满足在以前的活动中施加于它们的要求和条件的过程。
合同验证，过程验证，需求验证，设计验证，编码验证，集成验证，文档验证
5、确认过程：确定需求和最终的、已建成的系统或软件产品是否满足特定的预期用途的过程。
该过程包括下列任务：
1、为分析测试结果准备选择的测试需求、测试用例和测试规格说明
2、确保这些测试需求、测试用例和测试规格说明反映特定的预期用途的特殊要求
3、测试包括强度、边界和异常输入测试
6、联合评审过程：评价某个项目的一项活动的状态和产品，项目管
理评审，技术评审
7、审核过程：在适当时确定与需求、计划和合同的符合性
8、问题解决过程
9、易用性过程
7个组织过程
1、管理过程：为生存周期过程中的管理包括项目管理而定义的基本活动
2、基础设施过程：为建立生存周期过程基础结构而定义的基本活动
3、改进过程
4、人力资源过程
5、资产管理过程
6、重用大纲管理过程：为组织的重用大纲主管而定义的活动，启动，领域评估，重用评估，策划，执行和控制，评审和评价
7、领域工程过程：领域工程师的活动和任务，领域分析，领域设计，资产供应，资产维护。