构建之法第五章读书心得
这一章我们主要学习了团队和流程。团队简而言之就是开发一个软件工程的团队,那么团队究竟怎样在一起开发这一软件便有了多种多样的方法。
比如所有人都一起做的一窝蜂模式,但这样模式弊端很大,虽然都做了许多工作,但结合起来的成果可能还没有单人做的进度快。慢慢的发展出了一些其他的模式,比如我们在学校中,一个学霸主力,其他人打酱油,但这并不好。之后也出现了明星模式,社区模式等更好的模式
写了再改模式:这种便是我们学生中最为普遍的一种模式。不管代码怎么样,先写出来,甚至连语法错误都没有考究,整体做完后再针对问题进行修改。这种方法看似简单,但实际并不高效,会在查找和修正错误上浪费许多时间。对于以后工作中,复用性高,规模打的软件开发而言,这种模式显然不合理。
瀑布模型:瀑布模式就像其他行业的流水线一样,单向,有条理,规范性强,但它的不可逆性会很大程度上影响软件的后期功能扩充和维护。但如果产品需求明确,并且开发把握度高的情况下,这种模式也是可以采用的。不过对于那些用户需求不明确,需求扩展度较高的项目来说,采用瀑布模式就不能满足开发需求
Rational统一流程,即后面的统一建模:统一建模是近年来发展起来的一种软件设计模式,通过需求分析,建立多个模型,设计,最终实现软件的开发,已经是一种较为成熟的软件开发手段。它主要有以下四个阶段:
初始阶段——此阶段的目标是分析软件系统大概的构成,系统与外部系统的边界在哪里(我们的系统究竟和什么别的外部实体打交道),大致的成本和预算是多少,系统的风险主要来自哪里。成功度过初始阶段的项目会达到生命周期目标(LifecycleObjective)里程碑
细化阶段——它的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,按优先级处理项目中的风险。团队要确定项目的具体范围、主要功能、性能、安全性、可扩展性等非功能需求。同时为项目建立支持环境,包括创建开发案例、创建模板并准备工具。细化阶段结束时,项目到达了第二个重要的里程碑:生命周期结构(Lifecycle Archi-tecture)里程碑
构造阶段——在这一阶段,团队开发出所有的功能集,并有秩序地把功能集成为经过各种测试验证过的产品。构造阶段结束时是第三个重要的里程碑:初始功能(Initial Operational)里程碑。此时的产品版本也常被称为“beta”版
交付阶段——这时候,团队工作的重点是确保软件能满足最终用户的实际需求。交付阶段可以有迭代(beta1,beta2等),基于用户的反馈,团队利用这些迭代对系统进行修改、调整。除了对功能的调整,团队还要注意处理用户设置、安装和可用性等问题。在交付阶段的终点是第四个里程碑:产品发布(Product Release)里程碑