软件工程之美 读后感
项目生命周期
- 规划
- 需求分析
- 设计
- 编码
- 测试
- 运行和维护
软件项目管理金三角
- 时间
- 范围
- 成本
全面提升软件工程能力与实践，打造可信的高质量产品
软件工程的核心
软件工程 = 工具 + 方法 + 过程
做中学 和 教中学
推荐配套书单
-
构建法
作者邹欣是微软的研发总监，同时在多所高校进行了软件工程的教学实践，在此基础上对软 件工程的各个知识点和技能要求进行了系统性整理，形成教材。也是本专栏很多很好的补 充。
-
人月神话
这是软件工程历史上的经典著作，内容发人深省，40 年来一直畅销不衰，里面的观点即使 到现在也不过时。这本书即使你以前看过，隔一段时间再翻看一遍，可能都会有新的感悟。
-
人件
如果说《人月神话》关注“软件开发”本身，《人件》则关注软件开发中的“人”。作者指 出知识型企业的核心是人，而不是技术。
-
知行合一： 实现价值驱动的敏捷和精益开发
作者丛斌有二十多年从事软件工程教学、咨询和研究的经验，所以书写的特别接地气，文章 有很多真实案例，对敏捷开发和 CMMI 都有很深入描述。
-
软件工程——实践者的研究方法》
这是大部分高校采用的软件工程标准教材，可以作为一个参考。
-
持续交付
讲述如何实现更快、更可靠、低成本的自动化软件交付，描述了如何通过增加反馈，并改进 开发人员、测试人员、运维人员和项目经理之间的协作来达到这个目标
-
走出软件作坊
这本书生动的描述了国内小型 IT 企业在发展过程中遇到的一系列项目管理问题，以及作者 是如何去解决这些问题的。
瀑布模型和敏捷开发如何平衡时间成本范围的关系？
瀑布模型
瀑布模型有严格的阶段划分，有需求分析、系统设计、开发和测试等阶段，通常在开发过程 中不接受需求变更，也就是说，我们可以认为瀑布模型的范围是固定的，其他两条边时间和 成本是变量。
所以使用瀑布模型开发，如果中间发现不能如期完成进度，通常选择的方案就是延期（加 班），或者往项目中加人。
然而瀑布的特性决定了它只能从上往下流，而且从上到下走完整个周期很长，所以一旦出现了需求的变更，将会非常痛苦，很多事情需要重头再来。
于是基于瀑布模型，又衍生出 V 模型、原型设计、增量模型、螺旋模型等模型，试图改善瀑布模型存在的一些缺陷。这些改进模型的发展趋势上就是缩短项目周期，快速迭代
敏捷开发
我们再来看敏捷开发，敏捷开发中，是采用固定时间周期的开发模式，例如每两周一个 Sprint，团队人数也比较少。所以，在敏捷开发中，时间和成本两条边是固定，就只有范围 这条边是变量。
这就是为什么在敏捷开发中，每个 Sprint（迭代） 开始前都要开 Sprint 计划会，大家一起选择下个 Sprint 能做完的任务，甚至于在 Sprint 结束时，没能完成的任务会放到下个 Sprint 再 做。
极限编程
如果某个实践好，就将某个实践做到极致
- 如果做测试好，就让每个开发人员都做测试 ;
- 如果集成测试重要，就每天都做几次测试和集成 ;
- 如果简单的就是好，那么我们就尽可能的选择简单的方法实现系统功能 ;
工程方法
**有目的、有计划、有步骤地解决问题的方法就是工程方法。**工程方法不是软件工程独有的，几乎所有工程类别都可能会应用，例如建筑工程、电子工程等，只不过步骤可能略有不同
瀑布模型 (6 个阶段)
一、问题的定义及规划
这个阶段是需求方和开发方共同确定软件开发目标，同时还要做可行性研究，以确定项目可行。这个阶段会产生需求文档和可行性研究报告。
二、需求分析
对需求方提出的所有需求，进行详细的分析。这个阶段一般需要和客户反复确认，以保证能充分理解客户需求。最终会形成需求分析文档。
三、软件设计
根据需求分析的结果，对整个软件系统进行抽象和设计，如系统框架设计，数据库设计等等。最后会形成架构设计文档。
四、程序编码
将架构设计和界面设计的结果转换成计算机能运行的程序代码。
五、软件测试
在编码完成后，对可运行的结果对照需求分析文档进行严密的测试。如果测试发现问题，需要修复。最终测试完成后，形成测试报告。
六、运行维护
在软件开发完成，正式运行投入使用。后续需要继续维护，修复错误和增加功能。交付时需要提供使用说明文档。
瀑布模型在提出后，因为其简单可行，切实有效，马上就在很多软件项目中应用起来，一直到 2000 年前后，都是最主流的软件开发模型，即使到现在，你也能在很多软件项目中看到它的影子
也是从那时开始，有了“软件生命周期”(Software Life Cycle,SLC) 的概念。
软件生命周期是软件的产生直到报废或停止使用的生命周期。而像瀑布模型这样，通过把整个软件生命周期划分为若干阶段来管理软件开发过程的方法，叫软件生命周期模型。
优缺点
