作者通过几天软件开发培训，对开发全过程有更系统全面认识。培训围绕Analysis部分，介绍了澄清需求的方法、分析手段如OOA和Use Cases等，还阐述了各分析方法优缺点。强调要与客户充分沟通，适度分析，团队协作在开发中也很重要。
1. 软件开发培训总结
通过几天的培训，我个人对软件开发的全过程有了一个更系统更全面的认识，同时学习到的不仅仅是软件开发的相关知识，还有成熟的思考问题的方法，整体把握问题的能力。
2. 知识总结
2.1. 关于Analysis部分的培训总结
以下为培训内容要点：
l 澄清需求的方法就是分析；
l 分析的手段是OOA，Use Cases；
l 要澄清需求，必须与客户进行更好、更充分的沟通；
l 分析没有必要特别多（在已有的系统上重新构建的时候例外，这种情况分析很重要）；
l 分析的工作是属于问题域的，虽然有部分解决方案域中内容需要与用户商榷，但是这部分内容应该很少；
l 原型和调查是非常有用的，可以让用户看到界面和功能，但是原型是不能成为最终交付系统的；
l 在分析的开始就要知道那些应该保留，哪些应该丢弃（原始需求）；
l Use Cases有两种表现形式，用例图和文本形式描述；
l Use Cases是简单的并且有效的；
l 原型和调查同样是有效的，但是会提高成本，并且会带来风险；
l OOA方法只有在重新构建系统的时候才十分的有用，否则会混淆分析和设计，将设计带入歧途，并且不易于客户和最终用户理解；
l 过程式的分析（直译为功能式的设计，在OO方法前的一种分析方法），是一种繁琐的，关注重点错误的分析方法（更侧重于解决问题，而不是定义和分析问题，往往会造成很多分析错误），只有当系统的输入输出确定，并且仅仅是以数据处理为主要功能的系统可以采用这种分析方法，当用户明确的提出使用此种方法设计的时候，也会采用，因为我们没有选择的余地。
2.2. 新的认识
l 必须充分的与客户沟通才能做好分析；
l 分析的手段多种多样，要慎重选择，视需而定；
l 往往分析可以将几种手段结合进行，比如，Use Cases + 原型；
l 分析工作要适度，过度的分析会使设计误入歧途，过少的分析会使设计缺乏依据；
2.3. 重要的观点
以下部分观点概括的阐明了做分析方法，以及他们的优点和不足，非常重要：
l Use Cases是简单有效的；
l 原型和调查是有效的，但是会提高成本，带来风险；
l OOA方法并不是非常有效的；
l 过程式分析是一种接近被淘汰的方法，不到万不得已不要使用。
2.4. 收获
以下是设计部分培训的收获：
l 对Use Cases有了新的认识；
l 由于分析必须适度，我们必须体会这个程度，选择一个更好的平衡点；
以下是整个培训过程中获得的收获：
l 作为开发团队的一员，我们必须有一个很好的态度去对待开发中遇到的问题，认真地对待每一个问题，积极地交流与沟通；
l 软件开发是一个团队性的活动，是建立在相互协作和相互信任的基础上的；
l 软件开发团队领导者在开发活动中的地位非常重要。
以下问题在培训中并未明显的提到，但是我觉得很重要：
l 如何从用户描述中发现隐藏在描述后面的需求，也许这个就是分析所要做的工作，但是它并不是一件很容易完成的事。
扫一扫
4万+
到【灌水乐园】发言
