型的，或者说它与任何开发模型无关。开发模型本身只是规定了软件生存周期中的若干步骤或阶段，便于开发人员去开发与维护，它并没有规定管理人员的过程管理方法与任务。为此， CMMI管理体系规定采取阶段评审和不符合项的动态跟踪制度，只有前一阶段的不符合项全部改正后，才允许开发人员进入后一阶段的工作。
所谓不符合项，就是在评审中发现的问题项，它与Bug既有联系，又有区别。对于这些不符合项，软件管理部门要列出表格，记录在案，确定责任人，限定改正时间，动态跟踪到底。
2.6 请调查你周围的软件公司采用哪几种软件开发模型进行软件开发。
周围的软件公司采用的软件开发模型有瀑布模型、增量模型、迭代模型、原型模型。其中瀑布模型和原型模型是这些软件公司最常用的，其次是增量模型，最后是迭代模型。
2.7 软件开发模型对你今后的工作，到底具有什么指导意义？
当我们进入IT企业参与软件开发或管理时，若能掌握软件开发模型知识，就会很快了解当前的项目或产品应该采用什么开发模型，由此确定该软件的生存周期和当前项目组的开发状态与进度，从而很快知道项目组成员的工作，也能使自己很快融入该项目组，快速适应IT企业文化，并很快进入角色。
2.8 你对“生命周期模型裁剪指南”有什么看法？ “生存周期模型裁剪指南”是IT企业或软件组织内部根据软件开发模型的普遍原则，结合本单位的开发经验和行业特点的具体实际定制出来的。它有针对性地对选定的软件开发模型中定义的生存周期，进行恰当地裁剪。所谓裁剪，就是对原模型中定义的内容进行增、改、删，去掉对本单位或者本项目不适合的部分，增加对本单位或者本项目适用的内容，同时进一步细化。这样可以缩短开发时间，减少开发成本，具有非常现实的意义。
2.9 “图书馆信息系统”的开发选用什么开发模型合适？
“图书馆信息系统”的开发选用瀑布模型比较合适。因为瀑布模型开发阶段清晰，便于评审、审计、跟踪、管理和控制，而且“图书馆信息系统”在一定程度上符合瀑布模型的条件：
（1）它在开发时间内需求没有变化或很少变化。 （2）分析设计人员对应用领域很熟悉。 （3）低风险项目。
（4）用户使用环境比较稳定。
（5）用户除提出需求以外，很少参与开发工作。
2.10 请详细说明瀑布模型与迭代模型之间的关系。
在宏观上，迭代模型是动态模型，瀑布模型是静态模型。一方面，迭代模型需要经过多次反复迭代，才能形成最终产品。另一方面，迭代模型的每一次迭代，实质上都是执行一次瀑布模型，都要经历初始、精化、构造、移交4个阶段，走完瀑布模型的全过程。
在微观上，迭代模型与瀑布模型都是动态模型。迭代模型与瀑布模型在每一个开发阶段（初始、精化、构造、移交）的内部，都有一个小小的迭代过程，只有经历这一迭代过程，该阶段的开发工作才能做细做好。
瀑布模型与迭代模型之间的这种微妙关系，如下图所示。
图 瀑布模型与迭代模型之间的关系
由图可见，在迭代和瀑布模型中，你中有我、我中有你。 瀑布模型与迭代模型之间的关系，反映了人们对客观事物的认识论：要认识与掌握某一客观事物，必须经历由宏观到微观的多次反复的过程。只有从宏观上反复迭代几次，才能看清全貌，掌握事物的宏观发展规律。只有从微观上反复迭代几次，才能吃透每个细节，掌握事物的微观发展规律。
习 题 3
3.1 为什么说立项（或签订合同）是一切项目的源头，也是软件项目的源头？ 立项的过程就是软件企业决定是否去开发某个项目或产品的过程。只有立项完成以后企业领导部门才会下达“任务书”，开发部门开始组成开发团队，成立项目组。
3.2 立项的具体表现形式是什么？
企业的市场销售部门在市场调研的基础上，分析该产品是否有市场前景，以及企业是否有能力开发出该产品，并具体列出系统的功能、性能、接口和运行环境等方面的需求情况，当前客户群和潜在客户群情况，以及投入产出分析，然后写出立项建议书，召开立项论证会，决定是否立项。
3.3 《立项建议书》的编制者为什么主要是软件公司的市场销售人员，而不是开发人员？ 软件开发出来终归要推向市场的，软件能不能被市场接受是软件开发成功的标准。市场销售人员长期和市场客户打交道，他们最了解客户和市场的需求，最知道什么样的产品具有巨大商机。
3.4 为什么将项目的市场前景、功能、性能、接口、风险作为《立项建议书》的主要内容？
一切软件项目或软件产品，都是为了实现用户需求中的“功能、性能、接口”三项具体目标。软件是否有市场前景，是软件开发是否成功的标志，有了市场软件才能带来利润。风险分析是对开发此软件的政策风险、环境风险、技术风险、技能风险等进行分析，这对公司按时保质保量地完成软件开发，是必不可少的。
3.5 什么叫风险分析？技能风险与技术风险有何区别？ 这里的风险分析是指软件立项过程中对产品开发、销售等可能出现的风险进行分析。分析方法是将一个大风险化解为多个小风险，然后再一个个克服小风险。
技术风险是指采用新技术的风险程度。技能风险是指项目组成员掌握新技术的风险程 度。两者的区别在于一个是说新技术（如新的开发工具，新的设计思想）本身的风险，一个是说人员要掌握这种新技术的风险。
3.6 行业领域业务专家与产品经理有何异同？ 行业领域业务专家是精通某行业领域业务的人，在讲标时能把投标书的内容准确、生动地表述出来，使客户心服口服。而产品经理是某产品需求分析和概要设计的经理或专家，主要负责产品的立项、需求、设计和销售等业务。两者的相同点是：必须精通该产品的功能、性能和接口。不同点是：前者突出熟悉产品的应用业务领域，后者突出熟悉产品的需求与设计。
3.7 《合同》、《任务书》、《立项建议书》三者有何异同？有何关系？ 合同是与固定客户签订的协议书，签订合同后软件公司启动该项目的开发，该软件被称为“订单软件”。
立项建议书是相对“非订单软件”而言的，是相关人员对立项过程的书面描述。 任务书是企业决定开发某个软件时，对此任务的具体部署情况，以书面的形式表达出来，包括正文和附件。
只有立项建议书或合同签订以后才能下达任务书，三者都是软件开发的源头。
3.8 下达任务的时间和方法是什么？
满足以下三个条件中的任意一个，即可下达任务书： （1）企业已签订了项目《合同》。 （2）《立项建议书》已通过了评审。
（3）作为特殊情况，软件组织的上级下达了某个项目的指令性软件开发计划。例如，有跨组织、跨部门的某个大系统项目，软件的需求由它的系统总体设计组分配。
下达任务书的方法是：
（1）下达一份《任务书》的正文。包括任务的下达对象、内容、要求完成的日期、决定投入的资源、必要时包括任命项目经理（技术经理和产品经理）、其他保证措施、奖惩措施等。《任务书》的正文可长可短，若合同或立项建议书很详细，则正文可短。若合同或立项建议书很粗略很短，则正文应该详细，当然也应该很长。
（2）下达一份《任务书》的附件。一般情况下它就是软件《合同》或《立项建议书》，如果是指令性计划，它的格式和内容，也应与《合同》或《立项建议书》基本相同，即附件的内容应覆盖系统的功能点列表、性能点列表、接口列表、资源需求列表、开发进度列表、阶段评审列表等。
3.9 请进行社会调查，收集材料，用事实说明“立项就是决策”的道理。
2003年初冬，山东某软件公司的老总在西安出差，发现西安市的大中型餐厅基本上都有电子点菜系统，客人一点菜，信息马上出现在厨房大师傅眼前，大师傅马上炒菜，服务员很快上菜，他感到很有意思。后来一打听，这个“餐饮系统”是北京某软件公司开发的。于是这位老总又飞到北京，拜访了“餐饮系统”的开发公司，了解到该公司经济效益不错，而且还到几家餐饮店去就餐，亲身体验“餐饮系统”的使用情况，收集用户意见。返回山东后，老总拍着脑袋决定马上立项，快速开发本公司的“餐饮系统”。不到三个月，“餐饮系统”开发完毕，但是在后来的两年中，该系统在山东某市总共只卖出两套，投入与产出比是5︰1。这是为什么？就是因为该城市是中等城市，不像北京、西安是大城市，“餐饮系统”的客户群，实在是少得可怜。
立项就是决策，IT企业的决策必须按照决策程序进行，没有决策程序就要先制定决策程序，不能一个人拍脑袋定决策。
3.10 试述《商业MIS开发任务书》的优缺点及需要如何改进。 选作题，课外作业。
3.11 请在老师的指导下，选定一个项目，写出一份《立项建议书》。 选作题，课外作业。
3.12 对软件项目和产品的“功能、性能、接口”三项指标如何理解？
一切项目或产品都是为了解决自身的“功能、性能、接口”问题，软件项目或产品更是这样。所以，从软件立项、需求、设计、编程、测试、维护，自始至终都要毫不动摇地坚持“功能、性能、接口”三项指标。
3.13 请用PowerPoint工具制作一份“图书馆信息系统”的投标书，并进行试讲。 选作题，课外作业。
3.14 按照老师建议的其他实践项目，2~3人一组，完成项目的《立项任务书》和《投标书》，并进行《投标书》讨论与试讲。
选作题，课外作业。
习 题 4
4.1 为什么需求分析特别重要？ 需求分析特别重要，是因为：
（1）许多大型应用系统的失败，最后均归结到需求分析：要么获取需求的方法不当，使得需求分析不到位或不彻底，导致开发者反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；要么客户配合不好，导致客户对需求不确认，或客户需求不断变化，同样致使设计、编码、测试无法顺利进行。
（2）需求分析的输出文档是《用户需求报告》，它既是软件生存周期中的第一个里程碑，又是客户、软件开发人员和项目管理人员三者必须遵守的一根基线，是三者共同工作的基础，是项目Alpha测试和Beta测试的准则，是供方交付产品和需方验收产品的依据。
（3）需求分析要占用整个软件开发时间或工作量的30%左右。
（4）需求获取中的错误，属于软件开发中的早期错误，它会在后续的设计和实现中进行发散式的传播。
根据以上4个原因，IT企业的高层经理，对需求分析特别重视，常常派经验最丰富的人员去作项目需求。正因为如此，“系统分析员”才是软件行业中的最高技术职称。
4.2 需求分析的目的是什么？需求分析的难点在哪里？ 软件需求分析，其目的是用于说明软件产品或软件项目需要满足的条件和限制。在软件工程项目中首先要获取用户的需求，通过对软件需要的提取、分析、文档化及验证，为进一步的设计和实现提供依据。
需求分析的难点是：在系统的功能、性能和接口方面，开发者与客户达成完全一致的需求，让客户最终签字确认，并保证在项目验收前，需求相对稳定不变。万一需求有一点变化，双方必须履行“需求变更管理程序”，而变更管理程序在签订合同时已经做了规定。要知道，合同是具有法律效力的。
