软件项目管理(二)：软件项目立项与规划

一、发现项目机会

  • 客户的需求和问题就是选择项目的依据，是项目投资机会 。
  • 通常投资者是从以下几个方面发现项目投资机会：
  1. 市场需求。进行市场分析，客观地分析市场现状（市场容量的大小，供求情况），预测未来市场的发展趋势（高速成长，平稳发展，还是逐渐衰退），了解主要竞争对手的产品、市场份额和发展战略。
  2. 国家政策和产业导向。国家、行业和地方的科技发展和经济社会发展的长期规划与阶段性规划，这些规划一般由国务院、各部委、地方政府和主管厅局发布。国内企业应重视这些政策规划。
  3. 客户发布的项目招标。及时得到行业中客户单位的招标信息，进行可行性分析并投标。

二、可行性分析

  • 识别出的项目机会只能作为候选项目，还必须对其进行可行性分析，才能确定能否将其作为一个项目来实施。
  • 技术可行性分析的目的是确定能否利用现有的或可能拥有的技术能力来实现项目目标。

2.1 技术可行性分析

  • 项目总体技术方案分析 。分析项目所采用的技术方案是否合理，包括项目所依据的技术原理，主要技术、方法和过程，项目拟采用的质量标准等。
  • 软件组织水平与能力分析 。
  1. 研发能力：技术水平，研发成果；
  2. 生产和市场营销能力；
  3. 资金管理能力：资金回收和支付，银行贷款；
  4. 其它能力：已获得的各种认证和资质。
  • 项目技术来源分析 。
  1. 自主研发：拥有完全的自主知识产权和决策权；
  2. 合作开发：要明确技术成果的所有权和使用权；
  3. 使用其它组织或个人的技术（包括开源软件）。如果使用了专利，要进行专利分析。
  • 项目负责人及技术骨干的资质分析 。项目负责人和技术骨干的学历、专业、职称、行业资质、项目研发经历、近期主要研发成果、获得的主要奖励等。
  1. 例如，系统集成商必须具有一定的人员资质，如系统集成商三级要求：
  2. 企业从事软件开发、系统集成等业务的工程技术人员不少于 100 人，且本科学历人员所占比例不少于 80% 。
  3. 企业总经理或负责系统集成工作的副总经理具有 4 年以上从事信息技术领域企业管理工作经历；企业具有已获得信息技术相关专业高级职称，且从事计算机信息系统集成工作不少于 4 年的技术负责人。

2.2 使用开源软件

  • 开源软件经过三十多年的发展，已经异常丰富。
  • 使用开源软件的好处：
  1. 节省成本，提高开发效率。
  2. 开放和自由。开源软件通常符合开放标准，使用户不会被个别商业公司的专有标准束缚。例如， OpenOffice 符合开放标准 OpenDocument Format ，使用户对自己的文档有完全意义上的所有权。微软被迫公开了 OOXML 格式并力推其成为开放标准。
  3. 灵活可定制。拥有源代码，可以进行定制、修改和扩展。
  4. 公开透明。适用于涉及国家或商业安全的领域。
  5. 良好的学习平台。通过阅读源代码、文档、社区网站上的讨论等，可以理解开源软件的架构、设计，观察技术决定的决策过程等，对于开发人员技术水平的提高有很大促进作用。

　2.2.1 寻找合适的开源软件

  • 除使用通用搜索引擎外，还可以使用一些专业性网站提供的目录和搜索服务。例如：
  • www.osalt.com ，一家专门针对现有的商业软件来推荐相应的开源软件的网站。
  • 开源项目托管网站，如 SourceForge ,Google Project Hosting ，提供了分类浏览和搜索功能。
  • 一些网站（如国内的 www.open-open.com ）对流行的开源软件进行了汇总和索引。

　2.2.2 开源软件与自由软件

  • 1985 年， Richard Stallman 成立自由软件基金会（ FreeSoftware Foundation, FSF ），该组织对自由软件做了如下定义：
  • 自由软件赋予使用者四种自由 :
    1. 使用该软件的自由；
    2. 研究和改写该软件来符合使用者自身的需求的自由；
    3. 复制和散布该软件的自由；
    4. 改写并发布改写后软件的自由。
  • 1989 年， FSF 发布了通用公共许可证（ General Public License ， GPL ），对自由软件的使用和分享方式进行了规范的定义，保证了自由软件的永续自由，即所谓“ Copyleft ” 。促进了开源运动。
  • GPL 具有“传染性”，即一个软件一旦使用了遵守 GPL 的自由软件的代码，那么这个软件也必须遵守 GPL 。因此许多商业公司出于保护自身知识产权的目的，不敢使用和参与开发自由软件。
  • Stallman 认为保护软件的专有权是“不道德的”。
  • 开源软件在自由软件的开放、共享与商业组织利益之间寻求一种平衡。一些开源软件许可证允许商业组织在使用开源软件的过程中，不泄露其技术机密。使开源软件有了更大的发展。
  • 1998 年，开源软件促进会（ OpenSource Initiative ， OSI ）成立，成为促进开源软件运动的权威组织。该组织对开源软件有明确定义，并负责对开源软件许可证进行认证。
  • 一种提法：自由和开源软件（ Freeand Open Source Software ， FOSS ）。

　2.2.3 使用开源软件的质量风险

  • 绝大多数开源软件许可证都有免责条款。意味着如果软件出现质量问题，没有人为用户负责。
  • 要把住质量关：使用优秀的、成熟度高的开源软件。
  • 除常规的评价方式（如测试）外，还可利用开源项目特有的一些信息来评价其成熟度，例如项目领导者、开发者社区的规模和活跃程度、用户的规模、是否有安全补丁机制、文档是否丰富等。
  • 有一些开源软件成熟度评价模型（如 OpenBRR ）采用定量的方法（数学模型）进行评价。

　2.2.4 使用开源软件的服务风险

  • 开源软件不提供技术支持和服务承诺。
  • 可利用开源项目社区解决一些技术问题，但很有限。
  • 可购买软件支持服务（也称为“订阅”）。例如 Linux 操作系统有 Redhat 公司提供发行版并出售订阅服务， MySQL 数据库有 Oracle 公司出售订阅服务。
  • 一些公司（如 OpenLogic ）提供了广泛的开源软件服务 , 包括管理咨询、法律保障、技术支持、培训等。

　2.2.5 使用开源软件的法律风险

  • 如果用户只是自己使用开源软件（无论是只运行开源软件的二进制形式还是修改源代码后供自己使用），则在一般情况下不会有风险。
  • 如果用户要传播开源软件，例如把开源软件（无论是原封不动的还是修改过的）包含在自己的产品中进行再发布，则可能有一定的风险。
  • 这些风险来自三个方面：软件著作权、软件专利、许可证。

　（1）开源软件的著作权

    • 除了很少一部分属于公共领域（ publicdomain ）的开源软件不受著作权保护外，绝大部分开源软件都是有著作权的。
    • 开源软件的著作权所有者一般通过软件许可证把权利授权给用户，同时也要求用户遵守特定的约束。
    • 开源软件的开发者众多且分散，因此其著作权来源复杂，容易产生侵权现象。

   （2）开源软件的专利

    • 开源软件可能包含有软件专利。
    • 专利持有者通常通过许可证把专利使用权授予用户，但有些许可证并没有对专利授权做出明示。
    • 由于开源软件代码来源复杂，可能带有未经授权的专利。

   （3）防止侵犯著作权和专利的方法

    • 通过各种渠道调查清楚开源软件是否涉及著作权和专利方面的问题和纠纷。
    • 利用第三方资源来规避风险，例如“开放发明网络”公司可以向受到有关 Linux 的专利诉讼的公司提供援助， Redhat 公司可以为购买了支持服务的用户提供开源担保，代替用户处理侵犯著作权和专利的法律问题。

   （4）开源软件许可证

    • 开源软件许可证把各种权利赋予用户，同时对开源软件的传播进行了不同程度的约束。
    • OSI 认证的开源许可证有几十种，同时推荐了 9 种最常用的，分别是： GNU 通用公共许可证，简称 GPL ； GNU 宽通用公共许可证，简称 LGPL ； Mozilla 公共许可证，简称 MPL ；通用开发和发布许可证，简称 CDDL ； Eclipse 公共许可证，简称 EPL ； 3 条 BSD 许可证； 2 条 BSD 许可证； MIT 许可证； Apache 许可证。
    • 要详细解读所使用的开源软件的许可证，遵守其约束。
    • GPL 是目前应用最为广泛的许可证，据统计，有 60% 以上的开源软件采用了它。
    • 如果作品 A 使用了 GPL 许可证，只要作品 B 包含了作品 A 的全部或一部分或者其派生作品，那么作品 B 就是基于作品 A 的作品。作品 B 如果要发行，也必须使用 GPL 许可证。
    • 使得一个开源软件作品及其派生作品在传播过程中永远保持其自由和开放。 GPL 对最终用户非常友好，但专有软件厂商或对代码有保密要求的用户不适合使用 GPL 许可的开源软件。
    • LGPL 的大部分条款与 GPL 相同，差别在于它允许专有软件以动态链接的方式使用 LGPL 许可的软件。
    • 动态链接是指在运行时调用其接口或功能，共享数据结构，而不把它包含进来作为一部分发布。
    • LGPL 旨在鼓励一些具有高度可重用性的代码（例如函数库）被更多的人使用和改进。
    • MPL 是 Mozilla 基金会推出的，它对软件的再发布做了以下规定：
    • 对于采用 MPL 的开源软件源代码所做的修改，必须继续以 MPL 发行。
    • 对于采用 MPL 的开源软件的可执行形式，可采用其他许可证发行（包括专有软件）。
    • 可以将采用 MPL 的开源软件的源代码与其它代码结合在一起形成一个广义作品，并将该广义作品以其它许可证发行（包括专有软件）。
    • CDDL 是 Sun 公司在 MPL 的基础上开发的，在一些条款上做了改进，与 MPL 没有本质上的不同。
    • EPL 是由 Eclipse 基金会推出的，在软件再发布上的规定与 MPL 类似。
    • 2 条 BSD 许可证对软件再发布只做了以下 2 条规定：
    1. 再发布源代码时必须保留原著作权声明和本许可证的条款。
    2. 再发布二进制形式时必须在文档或其它附带资料中包含原著作权声明和本许可证的条款。
    • 3 条 BSD 许可证比 2 条 BSD 许可证多了以下一条规定：
    1. 在未得到书面许可的情况下不能使用著作权所有者的名称来签署或推广派生于本软件的产品。
    • MIT 许可证又名 X11 许可证或 X 许可证，由麻省理工学院推出，它对于软件再发布只有一条规定：
    1. 原著作权声明和本许可证条款必须出现在本软件的所有拷贝或实质性部分中。
    • Apache 许可证由 Apache 软件基金会推出，与 BSD 许可证很类似，但其条款更为严谨，特别是对授权的描述更加清楚完整，是一个很成熟的商业友好的许可证。

　2.2.6思考题(使用开源软件的典型案例)

  • 案例一：张三下载了开源软件 A 的可执行形式并将它安装在自己的电脑中使用，并且下载学习其源代码。
  • 案例二：甲公司开发的某软件产品需要动态链接开源函数库 B 但并不包含 B 。该软件使用非开源的商业许可证以二进制形式发行。
  • 案例三：乙公司在其专有产品中包含了一个未作任何修改的开源函数库 C ，该产品调用 C 的公开的 API 完成特定的操作。该产品使用非开源的商业许可证以二进制形式发行。
  • 案例四：丙公司将开源软件 D 的一段代码复制到其专有软件产品的一个源代码文件中并做了一些修改。该软件使用非开源的商业许可证以二进制形式发行。
  • 案例五：丁公司将开源软件 E 的代码稍作改进后使用非开源的商业许可证以二进制形式发行。

           

三、合同项目立项过程

 合同 是客户（甲方）和供应商（乙方）之间具有法律效力的“契约”，明确规定了双方的责任和权利。
 甲方要提供准确和完整的需求，通过招标选择合格的乙方。
 乙方要了解清楚甲方的需求并判断是否有能力满足这些要求，通过投标来争取项目。
 双方签署合同。

 

3.1 招标书定义

  • 招标文件的内容
  1. 投标须知：主要包括投标文件的组成，投标时间和地点，评标、中标、签署合同的过程和标准等。
  2. 项目需求说明：描述项目的功能和技术方面的需求。
  3. 项目招标文件模版

3.2 招标

 招标者要向供应商发出正式的投标邀请，并向他们发送（或发售）招标文件。
 为了使所有投标方对招标文件中的内容有清楚的、统一的理解，招标者可以组织统一答疑。

　　3.2.1招标的方式

  • 公开招标 。将招标信息在社会上公开发布。优点：可以最大程度地吸引更多的供应商来投标，有利于招标者获得最优的服务或最低价格的产品；缺点：在投标者很多的情况下很耗时，且成本较高。
  • 受限制的招标 。只向一些经过筛选合格的供应商发出投标邀请。针对性较强。
  • 直接谈判 。直接与某一个供应商谈判，只适用于某些特殊情况。

3.3 投标

 项目分析
 可行性分析
 编写和递交投标书

　　3.3.1 项目分析

       

　　3.3.2 可行性分析

      

　　3.3.3 投标书

  • 投标书应按照招标文件的要求来编制， 对招标文件提出的要求和条件做出实质性响应 。对于软件项目来说，投标书的主要内容一般可以分为两大部分：商务标部分和技术标部分。
  • 项目投标书模版

3.4 评标

  • 评标就是根据招标文件中规定的条件对投标者进行评估，从中选择能够提供最优服务和最合理价格的供应商。
  • 评标由招标者组建的评标委员会负责，根据我国的招投标法，评标委员会由招标者的代表和有关技术、经济等方面的专家组成，成员人数为 5 人以上单数，其中技术、经济等方面的专家人数不得少于成员总数的三分之二。
  • 评标
    1. 公正性 ：评标活动应当独立进行，保证公平、公正地对待所有投标者。
    2. 保密性 ：凡属于对投标书的审查、澄清、评价和比较的有关资料以及中标候选人的推荐情况等均要严格保密。
    3. 过程 ：对投标书进行详细审查，与投标者代表进行会谈，已有软件成果的演示和测试，参观开发现场等。
    4. 结果 ：通常是对投标者的各个方面进行量化打分，按照分值将投标者排序。

3.5 签署合同

 经过评标确定中标者后，招标者应向中标者发出中标通知书，并同时将中标结果通知所有未中标的投标人。
 双方就合同条款进行协商，达成共识后签字盖章，合同生效。

　3.5.1合同的类型

  • 按照计价方式，合同可以分为两种类型：
  • 固定价格合同： 由合同双方商定一个确定的项目总价格，该价格是固定不变的，除非合同条款产生了变化。这种合同对甲方来说是低风险的，对乙方来说则有一定风险。适用于那种可以准确定义需求并且有较少风险的项目。
  • 成本加酬金合同： 就是甲方向乙方支付项目的实际成本，再加上商定的管理费和利润。对甲方来说是有风险的，对乙方来说则是低风险的。适用于那种需求不确定性高和有风险的项目。

　3.5.2合同的一般内容

  • 双方的权利与义务；
  • 供应的商品与服务；
  • 技术成果的归属；
  • 项目的质量要求；
  • 项目的 各种期限；
  • 保密约定；
  • 验收标准和方法；
  • 价格和付款方式；
  • 违约处理方法；
  • 解决争议的方法

四、通用产品项目立项过程

微软公司的新产品项目立项阶段的步骤：
1、新产品项目的提议
2、市场分析预测
3、技术可行性分析
4、确定产品研发实施步骤
5、高层论证和审批
通用产品项目立项的一般过程

4.1 产品构思

  • 立项建议小组要在宏观上搞清楚“开发什么”、“怎样开发”、“怎样赚钱”等重要问题。
  • 产品构思的主要内容：
  1. 待开发产品的主要功能；
  2. 待开发产品的技术方案；
  3. Make-or-Buy 分析；
  4. 开发计划；
  5. 市场营销计划。
  • Make-or-Buy分析
  1. 确定产品中的哪些部分应当自行研发、采购或外包开发。
  2. 做 Make-or-Buy 决定的依据包括：
• 成本（包括初始成本和后续维护成本）；
• 风险；

• 工作效率；

• 知识产权；

• ……

 

4.2 立项调查

  • 立项调查的目的是为产品构思和可行性分析提供充分的、有价值的信息。
  • 立项调查的主要内容有 ：
  1. 用户和 市场调查；
  2. 政策调查 ；
  3. 竞争对手和同类产品调查。
  • 立项调查的方式
  1. 从 Internet 上搜索相关资料；
  2. 从出版物中提取信息；
  3. 与用户交谈；
  4. 向用户群体发调查问卷；
  5. 与同行、专家交谈，听取他们的意见。
  • 立项调察要坚持客观性。
  • 对调查得到的信息进行整理，最好形成一份 《 调查报告 》 。

4.3 申请立项

  • 立项建议小组根据产品构思、立项调查和可行性分析结果完成 《 立项建议书 》 ，提交给有决策权的机构领导。
  • 立项建议书模版

4.4 立项评审

 机构领导组织立项评审委员会，并确定一位主席。立项评审委员会一般由机构领导、各级经理、市场人员、技术专家、财务人员等组成。
 主席应当具有比较丰富的评审经验，负责主持评审会议，并负责撰写 《 立项评审报告 》 。

 

立项评审的一般步骤

　　第一步：评审准备

（ 1 ）评审委员会主席确定评审会议的时间、地点、设备和参加会议的人员名单（包括评审委员会成员、立项建议小组、记录员、旁听者等），并通知所有人员。
（ 2 ）主席将 《 立项建议书 》 及相关材料发给所有评委，各评委必须在举行评审会议之前阅读完毕，并及时与立项建议小组交流。

第二步：举行评审会议。

（ 1 ）主席宣布本次评审会议的议程、重点、原则、时间限制等。
（ 2 ）立项建议小组陈述 《 立项建议书 》 的主要内容。
（ 3 ）答辩。评审委员会提出疑问，立项建议小组解答。双方应对有争议的内容达成一致意见。记录员记录答辩过程的重要内容，包括问题、结论、建议等。

 第三步：评估。

（ 1 ）立项建议小组退席。
（ 2 ）每个评审委员会成员认真评估该项目，给出同意或不同意立项的结论和意见建议。

第四步：评审会议决议

（1）评审委员会根据少数服从多数的原则，给出评审结论。
（2）主席撰写 《 立项评审报告 》 并递交给机构领导。

第五步：机构领导终审

（1）此时机构领导具有一票否决权，可在 《 立项评审报告 》 中签署最终审批结论和意见。
（2）《 立项评审报告 》 模版

五、 项目授权和启动

5.1任命项目经理

  • 项目经理是项目团队的核心和灵魂，全面负责项目的管理，他的管理能力、经验水平、知识结构、个人魅力都对项目的成败起着关键的作用。
  • 一般地，项目的首要建议人被任命为项目经理，但如果他确实不适合这个职位，也可以物色其他人选，但应给项目建议人一定的奖励。

5.2项目筹备

  • 项目经理要选择人员，组成项目团队。
  • 项目经理要善于和机构领导、财务和人力资源部门协商，尽可能给项目争取必要的资金和资源。
  • 机构的资金和资源是有限的，可能难以完全按照 《 立项建议书 》 的要求给项目分配充足的资金和资源。

六、 项目计划

 项目计划（ Project Planning ） 也称 项目规划 ，其目的是为项目的开发和管理工作制定合理的行动纲领，使所有人员按照该计划有条不紊地开展工作。
 谁在什么时候进行项目计划？
 当项目经理完成了项目筹备，必要的资金和资源已经到位，那么项目经理和核心成员即可组成一个项目计划小组，开始进行项目计划。

项目计划的步骤

6.1 项目估计

  • 做项目计划之前，应该对软件规模、项目工作量进行估计。如果这些要素估计得比较准确的话，那么后续制定的项目计划就比较合理。对于一些外包项目而言，项目估计得到的数据是双方讨价还价的依据。
  • 项目估计几乎不可能成为一门精确的科学。但依据某种方法（规则）进行估计显然比随意进行项目计划好得多。
  • 有关项目估计方法将在第 5 章“成本管理”中讲述。

6.2 制定项目计划

  • 项目计划分为两类：一是全局的计划书（ OverallPlan ），通常就称为 《 项目计划 》 ；二是一些下属计划书（ SubordinatePlan ），例如配置管理计划、质量管理计划、阶段开发计划和测试计划等。
  • 下属计划书是对 《 项目计划 》 的补充，其内容不可与 《 项目计划 》 冲突。通常 《 项目计划 》 由项目经理负责制定，由机构领导审批。而下属计划书一般由项目成员制定，由项目经理审批即可。
  • 项目计划的主要内容
  1. 项目目标与范围；
  2. 过程模型与技术方法；
  3. 人力资源计划；
  4. 软硬件资源计划；
  5. 财务计划；
  6. 进度计划；
  7. 下属计划。
  8. 《 项目计划 》 模版

6.3项目计划审批

  • 项目经理把 《 项目计划 》 递交给机构领导。
  • 机构领导认真阅读该 《 项目计划 》 ，如果没有异议，就签字批准，使其成为正式文件；如果有不同意之处，就和项目经理沟通，并请项目经理及时修改。
  • 如果是合同项目，要请甲方代表共同审批项目计划。

6.4项目计划变更控制

  • 《 项目计划 》 不是一成不变的。
  • 一般的，若下列情况发生，应当变更 《 项目计划 》 ：
  1. 进度偏差超过了容许的误差，如 20% ；
  2. 费用偏差超过了容许的误差，如 20% ；
  3. 项目过程模型发生了显著的变化；
  4. 用户需求发生了重大的变化；
  5. 发生了不可抗拒的变化，如公司裁员、机构调整、产品发展战略调整等。
  • 项目计划的变更应遵循严格的变更控制流程（第 7 章）。

七、 选择合适的项目方法

选择项目方法有时也称为“项目分析”或“技术策划”。

7.1 分析项目特征

（ 1 ）系统的需求是否明确和固定？
有一些软件产品的需求是比较明确的，而且随着时间的推移不会产生太大的变化；而另外一些软件产品的需求会频繁地变更，且隐含着很多的不确定性。

（ 2 ）系统的规模和复杂性如何？
系统要解决的问题的规模和复杂性对项目方法的选择有很大影响。

（ 3 ）项目团队的经验和技能如何？
项目团队是否有开发类似系统的经验？是否有可供复用的软件资产？是否具有开发系统所需的技能？

（ 4 ）软件产品是什么类型？
不同类型的软件产品要用不同的方法学和技术来实现，对软硬件平台的要求也有很大差别。例如实时控制系统可能要使用时态逻辑、Petri网这样的技术，嵌入式控制系统要求软件对存储器的使用要严格控制，管理信息系统通常是面向数据的，需要使用数据库和合适的开发平台。

（ 5 ）系统是不是安全性关键的？
如果系统的故障会造成巨大的经济损失，甚至会危及人的生命，那么系统的安全性和可靠性要求就很高，测试工作必须做得非常充分，在开发过程中可能还需使用诸如Z和VDM之类的形式化方法，并考虑使用n版本技术。

7.2 选择过程模型

  • 过程模型特征总结
  1. 线性模型是 计划驱动 的，强调严格按照计划执行， 要求在项目之初就明确需求和解决方案 。
  2. 迭代型 / 适应型 / 极限型模型是 价值驱动 的，强调不断为用户提供实际价值以及过程的适应性和敏捷性， 允许随着项目的进展逐渐明晰需求和解决方案 。

7.3制订技术计划

  • 技术计划一般包含如下内容。
  1. 待开发系统的特征；
  2. 选择的过程模型；
  3. 开发方法；
  4. 需要的软件工具；
  5. 系统运行的硬件 / 软件环境；
  6. 需要的培训。

八、软件外包

软件外包 就是企业为了专注核心竞争力业务和降低软件项目成本，将软件项目中的全部或部分工作发包给提供外包服务的企业完成。
利用软件外包可以合理地配置资源，最大限度地从社会分工合作、资源共享中获益。
在软件项目的立项阶段，项目负责人通常要进行 Make-or-Buy 分析，确定待开发产品的哪些部分应当“采购”、“外包开发”或者“自主研发”。
如果需要外包开发，就要执行相应的外包管理流程。

8.1软件外包管理过程

8.2案例分析

  • “ 软件缺陷管理和度量系统 ” 项目
  1. 甲方项目招标需求说明书
  2. 乙方项目建议书

本章内容小结

  • 理解 在发现项目机会时，需求信息的几个来源。
  • 了解技术可行性分析的几个方面。了解怎样合法地使用开源软件。
  • 理解 合同项目的立项过程。
  • 理解 通用产品项目的立项过程。
  • 掌握 项目启动过程。
  • 了解项目计划的主要内容。
  • 理解 怎样选择项目的过程模型和技术方法。
  • 了解软件外包

主要参考文献

1. 蔡俊杰 . 开源软件之道 . 电子工业出版社， 2010.4
本书第5章介绍了怎样正确使用开源软件，包括法律因素（许可证、著作权、专利等），特别是对常用开源许可证的对比介绍比较到位。

2. 林锐 . 软件工程与项目管理解析 . 电子工业出版社， 2003.10
本书特色是所讲的软件工程和项目管理知识是从实际企业而来，比较实用。第2章和第3章讲述了项目的立项和规划。


原文链接：https://blog.csdn.net/yongchaocsdn/article/details/80367729

posted @ 2022-01-26 17:21  艾薇-Ivy  阅读(2290)  评论(0)  编辑  收藏  举报