Java教程

构建之法———其二

本文主要是介绍构建之法———其二,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

《构建之法》后面就介绍了软件工程的总体流程,需求分析、与客户交谈、团队分工以及PM、软件设计以及实现、测试软件以及提升体验,这些都是软件工程不可或缺的步骤。

 需求分析

  软件是虚构的,需求是实体的,如果我们作为软件开发者,我们需要了解并进一步理解我们软件的用户所需求的东西,这个时候,经验与体验就是十分重要的。比如说,一个网站,应该是什么架构,什么商业模式,什么用户划分以及每个用户可以执行的功能,这些都要有所考量。书上总结了以下角度:对产品功能性的需求、对产品开发过程的需求、非功能性的需求、综合需求。对产品功能的需求有很多,就像课表,你可以分类显示课程、分时间显示课程、如何显示课程等;开发过程的需求,就是对开发流程进行限制,比如开发文档的需求,这一块给了我比较新奇的理解,因为我一直以为需求只是面向客户的;非功能性的,也就是对产品来说已经能用了,但需要有附加的性能、服务等需求;综合需求就比较广泛了,无论是对人员的需求还是综合系统的需求都涵盖。

  需求包含前面聊过的软件需求、客户需求,如何分析一个需求还是问题。书中介绍了一种竞争性需求分析的框架——NABCD,N,公开明确的需求,A,下一步特别是独特的做法,B,好处,C,竞争性,D如何进行推广,通过这个框架能初步分析出需求。

  团队分工

  在团队里有很重要的一个角色是PM,这是个重要的角色,因为这是一种需要跨专业的职位,但一位专业的团队经理的功能也是显而易见的,无论是调节分工以解决交流成本问题,还是联系客户分析需求,同时也能做出重大决定。有一个优秀的领导人整个团队都会十分高效,这或许就是领头羊效应。这个领导人首先的富有领导才能,懂得问题的本质与解决,也能解决矛盾,另外对应专业也要有一定能力,但最重要的还是快速学习能力。碰到不会的需要指明方向只有PM能调动团队,不然七嘴八舌没个结果。

  软件设计与实现

  软件构造是个复杂的过程,但总体来说就是分析统一——实现设计——软件测试——编写文档,但这不是一条线的流程,因为很可能因测试不过关而重复无数次,这也是程序员害怕BUG的主要原因,为了尽快达成软件的实现,公司内部、团队内部都会建立每日目标,提交每日报告,以此督促员工的完成工作,只要不歇息,这一个过程将会是十分流畅的。但实际上,会有不少突发事件,包括训练新员工、项目完全重构、项目丢失等十分麻烦的事情,所以项目也不应该十分紧张,留有余地总会是好的。

  我印象颇深的是作者在对风险管理水平的分级,一共四层,第一层一惊一乍的以为是大问题但却不去理会,没有预案;第二层准确来说是拖延,但确实采取行动去防止并解决问题,说是缓和但也只是让时间去解决问题,也没有可取之处;第三层就是有经验的应对,如何解决问题早已心有成竹,不会有大问题;第四次化危机为机遇,这是面对大危机也能自如应对的才能,项目被毙掉了或许就是这个项目的死亡,但提前布局针对前景进行开发工作,而且留有后路,这样就能在危机四伏软件工程中做一只不灭的小强。

转载于:https://www.cnblogs.com/limitCM/p/11006822.html

这篇关于构建之法———其二的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!