| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/jssf/infor_computation17-31/homework/10454 |
|---|---|
| 我在这个课程的目标是 | 学会软件开发的功能，会修改简单的代码，可根据现有代码实现改编满足需求 |
| 此作业在哪个具体方面帮我实现目标 | 了解学习软件工程的方法论 |
| 其他参考文献 | http://www.laputan.org/mud/ https://www.cnblogs.com/xinz/archive/2012/10/05/2712602.htm https://www.cnblogs.com/xinz/archive/2011/11/21/2257663.html |
| 作业正文 | https://i-beta.cnblogs.com/posts/edit |
软件工程的方法论
敏捷流程
1）介绍：什么是敏捷开发？
一群开发经验丰富和才华横溢的开发人员通过关注其他公司和别的开发团队并且结合自身的项目经验，创建了敏捷开发宣言，让软件开发工作变的更容易更轻松。
Scrum是一种迭代式增量软件开发过程。SCRUM是由Schwaber和Jeff Sutherland创建的，SCRUM是一个面向业务的框架来管理你的软件开发流程。有许多不同类型的SCRUM，需要记住的是主要目标是有效的进行工作并且不需要遵守规则。
2.Scrum/Sprint 开发步骤：
1）找出完成产品需要做的事情–Product Backlog, Backlog 翻译成“积压的工作”, “待解决的问题”, “产品订单”都可以。
2）决定当前的冲刺需要解决的事情–Sprint Backlog.
3）冲刺 (Sprint).在冲刺阶段, 外部人士不能直接打扰团队成员。一切对交流只能通过SCRUM MASTER 来完成。 这一措施较好地平衡了 “交流”和 “集中注意力”的矛盾。
3.Scrum对团队的要求：self-managing——>self-organizing——>cross-functional
4.总结：
1)Sprint/Scrum 对项目的众多需求采取分而治之的办法, 能让相关人员集中精力, 在一定期限内解决部分问题。
2）Scrum/Sprint 能成功实施的关键在于 ScrumMaster。 一个好的ScrumMaster 能在两种语境 (描述软件项目的商业语境，描述实现细节的技术语境) 自如地翻译和切换，事实上是一个强有力的PM。
3)敏捷方法通过保持较小的迭代长度，以及通过以不同的方式观察这些变化来进一步实现目标。 在多次迭代中不断总结, 改进团队的流程和产品功能。在敏捷项目中，每次迭代都会不断修改计划。如果潜伏着坏消息，那么它往往会更早出现，这时仍有时间对此做些事情。实际上，这种风险控制是迭代开发的关键优势。
4)它明确地指出不同人在一个项目中的投入和责任的不同
5)它不能解决软件开发的所有问题，至于具体项目进度如何跟踪, 如何管理测试工作，如何管理复杂项目, 还要靠战斗在一线的团队成员见招拆招，想出合适的办法。
6）敏捷方法是适应性而非预测性的。 工程方法倾向于尝试在很长一段时间内详细计划软件过程的很大一部分，这在情况发生变化之前一直很好。因此，他们的天性是抵抗变化。但是，敏捷方法欢迎改变。他们试图成为适应并繁荣发展的过程，甚至达到改变自己的地步。
7）敏捷方法以人为本，而不是以过程为导向。工程方法的目标是定义一个流程，该流程无论碰巧正在使用该流程的人，都能很好地工作。敏捷方法断言，任何流程都无法构成开发团队的技能，因此流程的作用是支持开发团队的工作。
MSF
MSF基本原则及具体做法:
（1）推动信息共享与沟通（Foster open communications）
a)所有信息都保留，并公开，讨论要包括所有涉及的角色，决定要公开，并告知所有人。b)对牵涉到技术机密、安全性等信息要采取必要的保护措施。
（2）为共同的远景而工作（Work toward a shared vision）
要明确项目的目标是什么。（a）这个目标必须是明确的，没有二义性；（b）这个目标不是当前就能达到，必须是通过努力才能达到的；（c）这个目标不是空泛的，它应该对项目成员每天的工作都有指导作用。
（3）充分授权和信任（Empower team members）
（a）给某人权力和权威；给予某人更多自信和自尊。（b）在一个高效的团队中，所有的成员都应该能得到充分的授权，他们有权力在自己的职权范围内按照他们自己的承诺完成任务，同时，他们也充分信任其他同事也能实现各自的承诺。
（4）各司其职，对项目共同负责（Establish clear accountability and shared responsibility）
团队中的每个角色都有自己的职责，如果出了问题，这个角色就要负责任。
（5）重视商业价值（Focus on delivering business value）
一个项目的商业价值只有在它被成功地发布并运行时才能体现出来，所以，MSF过程模式包括了开发和发布阶段。
（6）保持敏捷，预期变化（Stay agile, expect change）
软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。要注意，我们是预期变化，不是期望变化。
（7）投资质量（Invest in quality）
对质量的重视，引起对质量的投资，引起对人、过程和工具的投资。
（8）学习所有的经验（Learn from all experiences）
比较系统地总结团队的成功经验和失败教训，同时也客观评价团队的一些特性和团队的开发过程管理，这样能促使团队成员以客观、向前看、解决问题的心态来参加“事后诸葛亮”会，避免主观臆断或相互指责。
软件开发过程
软件开发过程是随着开发技术的演化而随之改进的。
从早期的瀑布式（Waterfall）的开发模型到；
后来出现的螺旋式的迭代（Spiral）；以致最近开始兴起的敏捷软件开发（Agile）；
他们展示出了在不同的时代软件产业对于开发过程的不同的认识，以及对于不同类型项目的理解方法。
应建立的价值观
作为有理想的软件工匠，我们一直身体力行，提升专业软件开发的标准，并帮助他人学习此工艺。通过这些工作，我们要建立如下价值观：
不仅要让软件工作，更要精益求精；不仅要响应变化，更要稳步增加价值；不仅要有个体与交互，更要形成专业人员的社区；不仅要与客户合作，更要建立卓有成效的伙伴关系。
项目有一个大泥球的解决办法：
首先，构建程序要有自己的结构，学会使用框架，可以大大的提高我们的编程速度。只有构建程序的人才能看到程序的内部外观。
另外，体系结构可以视为一种风险，可以更好地利用资源来满足瞬息万变的市场窗口，也可以将其视为为获得制胜优势奠定基础的机会。不成熟的体系结构在不断发展的系统中可能是一个优势，因为数据和功能可以在不受人工体系结构约束的情况下迁移到系统中的自然位置。
瀑布
瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
瀑布型与敏捷开发的区别：
瀑布型与敏捷开发的区别大多在于效率，瀑布型太过于繁琐，不是那么的便捷，每次出错只能一级一级的慢慢上报，而没有“敏捷”面对面沟通的迅速，也能更清楚的表达问题所在。
教堂
一套业务系统是不能完全满足用户业务需求的。对每个用户都要进行需求分析，概要设计，详细设计等必要的环节，是必须的。就像教堂的建成一样，需要很多年的时间才可以竣工，而且也需要很多环节的高度配合，每一步也要走的精准。