软件项目管理实用教程第2章 软件项目立项与规划.pptVIP

立项评审的一般步骤 第二步：举行评审会议。 （1）主席宣布本次评审会议的议程、重点、原则、时间限制等。 （2）立项建议小组陈述《立项建议书》的主要内容。 （3）答辩。评审委员会提出疑问，立项建议小组解答。双方应对有争议的内容达成一致意见。记录员记录答辩过程的重要内容，包括问题、结论、建议等。 立项评审的一般步骤 第三步：评估。 （1）立项建议小组退席。 （2）每个评审委员会成员认真评估该项目，给出同意或不同意立项的结论和意见建议。 第四步：评审会议决议 评审委员会根据少数服从多数的原则，给出评审结论。 主席撰写《立项评审报告》并递交给机构领导。 开源软件许可证 LGPL的大部分条款与GPL相同，差别在于它允许专有软件以动态链接的方式使用LGPL许可的软件。 动态链接是指在运行时调用其接口或功能，共享数据结构，而不把它包含进来作为一部分发布。 LGPL旨在鼓励一些具有高度可重用性的代码（例如函数库）被更多的人使用和改进。 开源软件许可证 MPL是Mozilla基金会推出的，它对软件的再发布做了以下规定： 对于采用MPL的开源软件源代码所做的修改，必须继续以MPL发行。 对于采用MPL的开源软件的可执行形式，可采用其他许可证发行（包括专有软件）。 可以将采用MPL的开源软件的源代码与其它代码结合在一起形成一个广义作品，并将该广义作品以其它许可证发行（包括专有软件）。 开源软件许可证 CDDL是Sun公司在MPL的基础上开发的，在一些条款上做了改进，与MPL没有本质上的不同。 EPL是由Eclipse基金会推出的，在软件再发布上的规定与MPL类似。 2条BSD许可证对软件再发布只做了以下2条规定： 再发布源代码时必须保留原著作权声明和本许可证的条款。 再发布二进制形式时必须在文档或其它附带资料中包含原著作权声明和本许可证的条款。 开源软件许可证 3条BSD许可证比2条BSD许可证多了以下一条规定： 在未得到书面许可的情况下不能使用著作权所有者的名称来签署或推广派生于本软件的产品。 MIT许可证又名X11许可证或X许可证，由麻省理工学院推出，它对于软件再发布只有一条规定： 原著作权声明和本许可证条款必须出现在本软件的所有拷贝或实质性部分中。 开源软件许可证 Apache许可证由Apache软件基金会推出，与BSD许可证很类似，但其条款更为严谨，特别是对授权的描述更加清楚完整，是一个很成熟的商业友好的许可证。 思考题（使用开源软件的典型案例） 案例一：张三下载了开源软件A的可执行形式并将它安装在自己的电脑中使用，并且下载学习其源代码。 案例二：甲公司开发的某软件产品需要动态链接开源函数库B但并不包含B。该软件使用非开源的商业许可证以二进制形式发行。 案例三：乙公司在其专有产品中包含了一个未作任何修改的开源函数库C，该产品调用D的公开的API完成特定的操作。该产品使用非开源的商业许可证以二进制形式发行。 思考题（使用开源软件的典型案例） 案例四：丙公司将开源软件D的一段代码复制到其专有软件产品的一个源代码文件中并做了一些修改。该软件使用非开源的商业许可证以二进制形式发行。 案例五：丁公司将开源软件E的代码稍作改进后使用非开源的商业许可证以二进制形式发行。 思考题（使用开源软件的典型案例） 案例一 案例二 案例三 案例四 案例五 GPL LGPL MPL 2条/3条BSD MIT Apache 允许 允许 允许 允许 允许 允许 允许 允许 允许 允许 允许 不允许 不允许 有条件允许 允许 允许 允许 允许 不允许 不允许 不允许 不允许 不允许 有条件允许 允许 允许 允许 允许 允许 允许 第3节 合同项目立项过程 合同是客户（甲方）和供应商（乙方）之间具有法律效力的“契约”，明确规定了双方的责任和权利。 甲方要提供准确和完整的需求，通过招标选择合格的乙方。 乙方要了解清楚甲方的需求并判断是否有能力满足这些要求，通过投标来争取项目。 双方签署合同。 合同项目立项过程 招标书定义 招标 投标 评标 签署合同 3.1 招标书定义 需求定义 商务条件确定 验收标准确定 采购需求认可 编写招标文件 资料汇集 招标文件的内容 投标须知：主要包括投标文件的组成，投标时间和地点，评标、中标、签署合同的过程和标准等。 项目需求说明：描述项目的功能和技术方面的需求。 案例 3.2 招标 招标者要向供应商发出正式的投标邀请，并向他们发送（或发售）招标文件。 为了使所有投标方对招标文件中的内容有清楚的、统一的理解，招标者可以组织统一答疑。 招标的方式 公开招标。将招标信息在社会上公开发布。优点：可以最大程度地吸引更多的供应商来投标，有利于招标者获得最优的服务或最低价格的产品；缺点：在投标者很多的情况下很耗时，且成本较高。 受限制的招标。只向一些经过筛