软件开发项目管理的案例解说(一)
来源:广州软件开发 编辑:广州软件开发公司 日期:2017-03-20
软件开发项目的需求和范围管理 - 系列 (一)
引言
在今年第一期的程序员杂志中,我对软件开发项目管理的重要性和进行管理的十大工作内容作了一个介绍。你应该已经很清楚地知道今天绝大多数的软件开发已经不是简单地编写一些程序而已,而是一个综合了对多人合作的运作进行必要管理的流程。只要你经历过任何由多人参加的软件开发工作,你一定对整个开发过程是否具有良好的管理对团队的士气以及对开发结果所造成的影响深有体会。一个软件公司或开发团队对软件项目进行管理的素质和水平,是影响到项目是否能够成功完成、开发出来的软件是否能够真正满足市场或客户要求的关键因素。懂得软件开发的项目管理知识不仅仅是项目经理的责任,也是所有开发人员应该掌握的本领之一。
从这一期开始,我将在这里用理论与案例解析相结合的一个系列的介绍文章,来阐述软件开发项目管理的更多指南和实践方法。这一期我们从如何进行软件开发需求和范围管理开始,接下来在以后的几期中再分别讨论软件开发项目的计划制定、质量控制、以及项目的执行与驱动的管理指南、等等。
常有的项目需求和范围管理的挑战
在软件开发项目进行的早期阶段,项目经理以及开发团队的领导们在制定项目计划时所经常碰到的一个令人头疼的问题是:如何有效地设定一个开发项目的范围,也就是如何确定所需要开发的软件的功能范围、质量的要求范围等各种所必须满足的条件以及相应的工作范围。很多项目管理人员和开发团队的领队往往被这个问题所困惑、无法有效地从大量的、貌似互不相连的各种技术、市场、用户的要求中得出明确的需求总结,从而妨碍了制定完善的项目计划。
其实这个问题并不是软件开发所独特具有的。任何大型和复杂的项目、包括各种高科技和工程开发项目,都会面临这个典型的问题。是否能够妥善处理这个挑战、并制定出相应的合理的开发项目的计划,是衡量一个开发团队的管理水准的衡量之一。
五年前我在从事微软的新一代嵌入式操作系统(Windows XP Embedded) 产品开发的项目管理时也碰到同样的问题和挑战:在众多的各种需求中,怎样确定哪些工作是我这个开发项目必须要包含的?怎样保证最主要的需求分析不被漏掉?怎样在开发之前建立整个团队对软件的质量期望的共识、事先确定软件必须达到的质量要求?
有效的需求和范围管理的运作流程
我们所采用的开发管理方法就是类似于我在《软件开发项目管理》一书中所总结的方法和运作流程来对付这个挑战:
1) 从需求分析总结确定大方向:
首先,对照任何一个软件开发项目所应该考虑到的九个需求范围的因素,逐步分析和判断这九个因素中对我这个项目影响最大的几个因素是什么、以及每个因素对我这个项目的具体要求,由此确定和总结出所开发的软件产品的功能范围,同时并确定哪些功能是不在这个项目的范围之内。下图是对这九个需求分析的因素的总结:
根据这个管理指南和原则,我的项目计划的第一步就是首先对所有这些因素进行一个全面的总结,然后把它写在一份“软件需求规范书”(Software Requirement Analysis Specification) 里。这份项目计划的早期文件然后经过整个开发团队坐在一起像开“诸葛亮会议”一样进行审核,对所有的需求总结进行合理性与可行性的逐条分析和评判讨论,并为每条需求进行重要性与优先权的设定。有的无法可以立即确定的,还得通过开发团队进行必要的技术验证、或向我们的市场营销部门或直接向客户进行调查询问来进一步确证。通过几次这样的审核会议,整个项目团队能够很快对项目的具体目标以及主要的工作任务达到共识。
为了方便于该规范书让全体团队成员阅读、并便于在团队审核会议上的逐条讨论,我将这个总结用一个表格将所有的需求分析根据以上需求因素的范围给列出来,作为产品设计规范书的早期内容。这个总结做出来之后,大家就可以逐条审阅和讨论。
下面,我用这个项目的历史作为一个案例来举例说明如何制定这些内容 (为了不透露公司的实际产品的开发战略,案例对具体内容作了改动、并用中文说明以便于读者阅读)。 以下是这个表格的使用举例:
Item
条款 Product Requirement Areas:
产品需求的范围 Comments or Issues
(注解及问题): Priority
(优先顺序)
1 Business Requirements (商业需求):
A Windows XP Embedded (XPE) Studio tools Target Designer (TD) and Component Designer (CD) shall be the application development tool suite to enable embedded device developers to design special purpose devices that are based on the X86 platform, and be able to develop embedded applications on desktop and easily deploy to devices and boot immediately…
视窗嵌入式操作系统的一整套应用开发工具要能够为嵌入式设备开发商们提供一个能够在英特尔X86平台上运行的开发环境,使得他们能够在桌面计算机上使用目前已有的通用型软件开发工具方便地进行嵌入式应用软件的开发,然后很容易地将应用软件安装部署在嵌入式设备、并能够立即启动运行… 对这个商业需求所应该达到的要求,需要与市场部门进行协商和确证 P1
B 视窗嵌入式操作系统在开发早期需要能够同时支持来自世界范围的早期应用开发者的样板产品的开发,特别是对6种主要语言的应用软件开发的支持… 对是否需在最初版本的发行时要支持世界范围的各主要语言,需要向营销部门确证。 P2
C 视窗嵌入式操作系统的核心必须是与Windows XP Pro在运行上完全兼容的,任何开发商所开发的应用软件应该都能在XPE的嵌入设备上运行… P2
D 视窗嵌入式操作系统的开发工具必须满足各小型开发商使用现有开发工具的市场要求,使得他们能够不仅在Windows XP Pro上进行开发,也能够在Windows 2000 上进行开发…
E 视窗嵌入式操作系统产品的发行必须通过Windows 2000 Logo鉴定验证的各种要求,包括产品的初始安装、升级安装、消除等各种要求…
:
…
2 Non-Requirements – Standards (非功能需求 - 标准):
A 视窗嵌入式操作系统必须满足微软本身在世界范围内产品发行的本地化标准、包括不同文化、政治、地域等因素带来的各种要求,各软件组件本地化翻译必须通过公司的本地化名称检测… P1
B 开发工具所生成的各种设备接口的驱动组件必须包括支持相关的嵌入式设备在业界的标准,诸如销售记帐器专有的标准、多媒体机顶盒的标准,等等
:
…
2 User Requirements (使用者需求):
A XPE 产品的开发工具的客户和使用者是那些目前已经在X86平台上进行应用软件开发的开发商。他们对使用开发工具如Visual Studio应该很熟悉,但不见得了解操作系统的所有组件结构,对嵌入式操作系统的要求可能更不熟悉。 需要与客户教育部门协商决定对用户的培训的要求以及使用说明书的要求 P1
B …
3 Functional Requirements (功能需求):
A XPE 产品的开发工具为客户解决的第一个最主要的开发问题是:为客户提供一个能够快速、简易地生产基于Windows XP Pro基础上的嵌入式设备所需要的、经过客户个体化了的轻型操作系统。 整个生产个体化的轻型操作系统的功能必须要经过对使用方案的确证。见使用方案总结的一章。 P1
B XPE 产品的开发工具为客户解决的第二个最主要的开发问题是:客户要能够方便地加入他们所开发的嵌入式应用软件,然后将整个操作系统的映像部署到嵌入式设备上。 加入客户应用软件的功能必须要经过对使用方案的确证。见使用方案总结的一章。 P1
C XPE 产品的开发工具为客户解决的第三个最主要的开发问题是:客户要能够将他们自己的嵌入式应用软件进行模块化的组件生成,使得他们能够有效地控制操作系统映像的大小,满足小型嵌入式设备的生产需要。 P1
D XPE 产品的开发工具应该将开发商进行开发的设计过程用专门的文档储存下来,使得开发商能够很快地一个设计重新载入开发工具,在为不同的设备进行开发时能够很方便地使用已有的类似的设计。 P1
E …
4 Performance Requirements (性能需求):
A XPE 产品的开发工具在使用者变换显示界面时不能有超过分之一秒的延迟。 P1
B XPE 产品的开发工具在下载操作系统的组件的数据库信息时,显示列表的刷新的延迟不能超过1秒。 P1
C XPE 产品的开发工具在生成新操作系统时的总体时间不应超出5分钟,而且必须要有生成进度显示(Progress Bar)。 P2
E …
5 Quality Requirements (质量需求):
A XPE 产品的开发工具在开发阶段必须经过代表软件质量的12个质量属性的测试验证。 具体测试要求见测试计划文件。 P1
B 开发工具在发行前必须通过发行的里程碑终点衡量质量标准。 具体要求见里程碑终点衡量文件(Exit Criteria)。 P1
C 开发工具所碰到的任何使用错误必须显示于此相关的准确错误信息(Error Message)。所有错误信息必须包括3个部分:出现的具体错误,造成错误的原因,以及如何采取纠正的步骤以消除或避免错误。 参见本规范书中对错误信息设计要求的部分。 P2
D …
等等
因为篇幅关系,上面这个表格只是一个经过彻底简化了的内容,九个方面的需求分析中的每个方面我只列了几个因素,而实际的文件每个方面的因素至少有几十个之多。但从这个哪怕是十分简单的例子中你也可以看得出来,在开发项目进行计划的第一步,作为项目经理或团队的管理人员,对所有影响到一个项目的各种因素进行思考和验证的重要性。参照以上图1 中的需求管理的考虑因素,从九个方面对开发的要求进行分析和总结,可以帮助你很好地照顾到和把握住应该考虑的各种因素、而不至于遗漏掉重要的东西,从而达到对项目的工作范围起到良好的控制和管理的目的。将这些因素用列表的方法总结出来,可以有效地引导项目参加者和团队成员一起来帮助审核各个需求分析,它同时对整个开发团队在项目的早期建立开发目的和任务的共识也极有帮助。
2) 从使用方案进一步确定功能需求:
光有一个高层次的需求总结对确定开发项目的范围还是不够的。要建立完整的开发计划,项目经理或开发团队的领导人员还必须对每个具体的软件功能进行确定。那么怎样从一个高层次的需求总结得出具体的功能设计呢?
答案是,最有效的方法根据高层次的需求总结,设计出完整的使用方案,我们把它叫做User Scenarios。所谓的使用方案设计就是,将用户会怎样使用你的软件为解决某个具体问题的整个过程给想象和设计出来,而且应该是一个完整的、从头到尾的使用过程。有了这个过程的总结,再从它的基础上进一步确定每个功能的具体需求。这些具体的功能需求也是需要用文字总结之后,经过整个团队的审核和确证才确定下来。这样的审核与确证可能要来来回回好几次才能最后确定。但是一旦确定之后,它就是一个较为成熟的总结了,它应该包含了整个开发团队对开发的目的的共同认识和意见的回馈,它同时也是对整个开发项目的范围的一个较为完整的确定。
采取我在软件开发项目管理一书中所阐述的从使用方案到功能设计的“三步法”,有了完整的功能需求总结之后,才进行最后的功能设计。这样你就可以保证,所设计和开发的每个功能都有于此相对应的功能需求、有于此相对应的使用方案,而不是毫无目标的、仅仅是因为看起来很“酷”而开发的功能。请参见《软件开发项目管理》有关这方面的论述。
3) 从软件的质量属性来帮助确定范围:
对软件开发项目的范围进行管理的另一个步骤和有效方法是,针对软件质量的12个属性进行对照,由此向客户、市场部门、或领导确定哪些是重要的、我这个项目是必须达到的要求;哪些是次要的、我这个开发可以疏忽的。这个管理方法的指南原则是,代表了一个软件质量的所有属性有的是有冲突的 – 见下图:
质量标志之间相互融合或对立的关系
图中所示的“+”号表示两个不同的质量标志属性相互融合、不矛盾。如果加强某一行的一个质量的属性,那么这个努力会使得所相对的带“+”号的纵栏里的另一个质量的属性也得到加强;“-”表示两个不同的质量标志属性互相对立,要满足其中一个就无法同时再满足相对的另一个。如果加强某一行的一个质量的属性,那么这个努力会使得所相对应的带“-”号的纵栏里的另一个质量的属性受到负面的影响。
例如,如果一个软件的开发和设计做了大量提高其重复使用性的功能,那么这些工作对提高这一软件的灵活性、兼容性、多用转换性等也有巨大的帮助。但是,为提高其重复使用性所必须做的设计上的一些改动,对这个软件本身的效率性的提高则很可能造成负面效果,像额外的程序码必然造成的对运行速度的影响,同时,额外的程序编码也会使“害虫”增多,影响到软件整体的稳定性能。
在有限的开发资源和有限的项目时间情况之下,你往往无法满足代表高质量象征的所有属性。所以你要向客户确证,到底哪些质量属性对他们来说是最重要的。在向客户了解开发质量的要求或分析赢得市场竞争的条件时,制定出满足这些质量需求的侧重点和所要照顾到的优先顺序,并知道避免相互矛盾的质量要求的开发需求。你由此将开发的计划根据客户的要求来安排,将软件的开发和测试的重点围绕着满足客户对质量的期望来做。这样做也就避免了花费时间和精力去做不必要的浪费性劳动,将你的开发项目的工作范围制定得更为紧凑、更讲究效益。一旦确定了满足不同质量要求的优先顺序,你就可以对各个工作注明优先代号,如P1 到P3,如上面表格中的例子。你的开发计划也能够根据这个优先顺序来制定了- 但然是先完成最重要的P1的工作。
总结
使用项目管理的本领在项目的计划阶段能有效的帮助你控制和确定一个软件开发的范围,从而能帮助你的开发团队集中力量开发对客户或赢得市场最重要的东西、并且避免无效开发的浪费。做好一个开发项目管理中的范围管理,也是帮助你建立合理的项目计划和时间表的基础。做好这个工作的技巧在于,按照本文所阐述的三个方法和步骤,先从需求分析的因素考虑出发,从高层次先确定开发项目的各个任务,然后根据功能设计的“三步法”从使用方案来确定具体的功能;最后将所要开发的软件根据质量属性的重要性向客户或领导确证它们的优先权和重要性,由此得出工作重点和范围。这样的开发项目管理方法能够有效地帮助你管理你的开发的范围。
在下一期的文章里,我再来讨论如何在做完范围管理的基础上,制定合理的开发计划和时间表。
相关阅读