浅谈软件项目管理

     

　　初步接触《软件工程》这门专业课，在我看来：软件工程是一个极具挑战性的项目，在约定的时间内，整个项目小组能够在知足用户需求与软件基本规范的状况下，开发出稳定可靠的软件。可是，在软件开发的过程当中，每每有许多不可规避的风险与未知的状况，例如：软件不能按时交付，软件的成本明显超过预期，软件未能达到用户的需求等等，"若是所用的时间是预计时间的两倍以上或费用超出预算两倍以上的项目为失控项目"，为了有效规避项目在开发过程当中的风险，因此笼统来讲，项目管理指的是：根据特定的规范，在预算的范围内，按时完成指定的任务，运用高效快捷的方法，围绕计划对项目进行监控，在人力、费用和时间上进行控制。做为Team16小组的组长，在整个软件的开发过程当中，实际担任的是"项目经理"的任务，因此下面让咱们几个小节来谈谈软件项目管理。

　　软件管理虽然涉及诸多的因素，例如：成本，质量，时间，资源等，但实际问题能够归结于：人员，问题和过程。当在软件工程开发的过程当中，遇到了问题：须要人员之间的沟通与交流来进行解决，固然：人员是软件工程开发中的核心力量。

1、软件过程控制

　　在国际上，有这几个通用的标准：

　　软件质量保证（SQA-Software Quality Assurance）是创建一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法可以正确地被全部项目所采用。软件质量保证的目的是使软件过程对于管理人员来讲是可见的。ISO9000就是其中的一种，也就是产品的"说明书"。

　　软件配置管理(SCM)是指在开发过程当中各阶段，管理计算机程序演变的学科，它做为软件工程的关键元素。已经成为软件开发和维护的重要组成部分。SCM提供告终构化的、有序化的、产品化的管理软件工程的方法。它涵盖了软件生命周期的全部领域并影响全部数据和过程。

一、软件的质量需求

　　ISO 9001对质量的定义是"客户要求的一种产品或服务所具有的全部特性"。从宏观上来看，软件质量的要求可分为：规定的和隐含的需求，规定的是指：用户明确提出的需求和须要，而隐含的需求是指：须要开发者本身来明确的基本的需求，例如：软件的功能，软件的使用周期等。ISO肯定了六中软件质量的特性：功能性，可靠性，可用性，有效性，可维护性，可移植性。

二、ISO软件质量评价模型

　 从1985年开始，国际标准化组织ISO和IEC就不断地该改进软件质量标准，现有的ISO质量标准，笔者以ISO/IEC 9126-1《产品质量-质量模型》，列出质量的三个方面：

   　　内部质量：在特定条件下时，软件产品知足需求能力的特性。主要指：在软件开发的过程当中的中间产品的质量

　　　外部质量：在已经达成一致的条件下使用时，软件产品知足用户需求的程度；

　　　使用质量：在规定的使用条件下，软件产品使特定用户在达到规定目标方面的能力；

三、笔者的理解

　　若是将：软件看做程序和软件工程的集合体，那么：软件的质量就包括两方面：

　　软件的质量 = 程序的质量 + 软件工程的质量

　　程序的质量偏重于代码的功能性实现，而软件工程的质量则偏重于除去代码自己的其余外界组成因素。

软件工程的质量大体体如今如下几个方面：

　　1.软件的开发成本(Cost)

　　一个软件在开发的过程当中，最主要的与实际相关的即是：人力与物力的消费。成本包括时间与金钱等，虽然古语有云"十年磨一剑"，但在现在高速发展的互联网时代，用如此长的时间周期去开发一个软件，显然是乌托邦幻想的情节。

      2.软件开发过程当中的风险(Risk)

　　软件开发实际是一我的与人之间的集体活动（以笔者的理解），每一个人都会负责相应的模块与本身的责任，这就产生了人与人之间的关系，固然这些关系在特定的条件下，可能如同"级联现象"同样，被各类各样的因素所影响；例如：项目成员的忽然退出(笔者就曾经遇到过这样的状况，结果项目组成员单我的的任务量就增多，同时项目的进度也受到影响)，开发过程没有作很好的备份(固然如今许多软件的开发都依托于github托管 平台，便于管理与控制)，开发难度过大(项目在开始的过程当中，一开始预期的实现效果因为技术人和人的因素，而致使在预约的期限内没法完成，历史上：IBM 推出的System/360 Operating System就是一例)

　　3.软件各模块的质量(partial)

　　在软件开发的过程当中，每每是分模块来进行，任务会进行人员的划分，在项目开发计划的甘特图(时间进度表)中，项目里程碑事件标志着这个子模块时间的结束，"千里之堤毁于蚁穴"，不妨以此类比，内部模块的质量的好坏，里程碑事件的完成标准，项目各模块之间的链接关系等小的事件每每会决定总体部分的质量。

 

四、说说软件测试的那些事(坑)？

   为何要作软件测试？由于当咱们规定了软件质量的标准后，测试则是：软件功能性需求是否获得知足的有效体现，同时：在测试的过程当中也有可能发现未知的bug,有助于程序员写出更高质量的代码~

   固然，也有一种声音，诸如:Sriram Krishnan(一位在Yahoo和微软工做过的程序员)在他的博客中提到: 光看看一些从古至今最成功的软件开发团队就知道了。不管是当今的Facebook，仍是30年前最初的NT团队，不少伟大的产品都是出自没有或不多测试人员的团队。

   可是，这个事情应该一分为二的来看:你不得不认可在现实生活中的确有不少大牛,人家的代码健壮性很强，让你根本就找不到什么bug(不过，通过面向对象OO这门课，你们的代码质量都提高了不少)，可是:另外一方面，你的软件没有通过充分的测试，就推出产品，那么当用户不断地在使用过程当中发现各类各样的问题是，想必用户的好感度会大大下降,不过如今不少手机app，用户与后台开发人员交互地不少，例如：meizu手机所推出的系统专门有一个模块：用户帮助(手机用户能够进行bug的反馈，而且会有工程师来答复，笔者就曾经反馈过bug而且收到了回复)，同理：像新浪微博里的微博小秘书也具有这个特色。

• 软件测试坑点1

　　谁来测试？是这段程序代码的开发人员仍是有专门的测试人员？若是是开发人员想要继续新的功能而不想测试或是专门的测试人员来作，他是否能理解代码的所有的功能意图？开发人员在得知代码有人来测试还对这段代码负责吗？

• 软件测试坑点2

　　测试过程当中，测试方法的选择与用例的多少？在咱们OO这门课中，一次的做业是编写测试用例，使得分支的覆盖率达到100%，因为当时本身的代码规模写的比较大，因此写完全部的测试用例并非一件轻松的事情，那么：在软件开发的过程当中，测试的用例恐怕就不是和笔者的做业一个数量级，那么测试数量如何保证，自动化测试的方法虽然可取但可能存在必定的局限性，John Musa(曾在 AT&T Bell实验室工做)提出：经过评价每一个模块可能使用次数来下降故障率。越是经常使用的组件越要严格测试。这种提议尚可考虑。

• 软件测试坑点3

　　发现bug时的采起措施？一个bug的出现可能隐藏着潜在未知的问题，由于：即便在你充分下降各模块的耦合程度下，各部分之间仍是存在必定的相关性，在这样的状况下，极有可能发生多米诺骨牌效应，当发现问题时，是否应当从新测试全部样例？固然并不可取，一种一种基于估算错误的方法能够参考( 参见Tom Gilb的《Software Metrics》)。

笔者的观点：

　　一个好的软件项目背后必定是开发人员和测试人员的共同努力，依据不一样的软件项目估摸采起不一样的质量标准和测试方法，另外一方面：软件质量应该是一个不断提高迭代的过程，如今市面上的软件都不断地推出更新包，实质也是在解决软件使用中的bug，因此后期的维护与更新必定程度上也体现了软件质量的提高。

     

五、关于软件配置管理

　　定义：软件配置管理(SCM) 是在整个软件工程中应用的一种普适性活动，在卡发的过程当中，变动随时会发生，SCM活动主要应用于:标识变动、控制变动、保证恰当的实施变动、向有关人员报告变动。

　　软件在配置管理中有4个主要的目标:

• 统一标识软件配置项
• 管理一个或多个软件配置项的变动
• 便于构造应用系统的不一样版本
• 在配置随时间演化的过程当中，确保软件的质量

  由此，定义了5个SCM任务：标识，版本控制、变动控制、配置审核和报告。  

　　　标识配置项：利用面向对象的方法，对每一个配置项进行标识，对软件开发过程当中的全部软件项目赋予惟一的标识符，便于对其进行状态控制和管理。

　　　版本控制：存储在开发过程当中，相关数据项的全部版本，便与软件的开发与回退，避免出现：丢失版本或不知版本问题。感受用github托管，会更加方便。

　　　变动控制：经过对变动申请人的变动请求进行评估，造成变动报告，创建工程变动单(ECO),对变动进行实施，同时：创建适当的版本与记录。

　  配置审核和报告：变动控制的补充手段，来确保某一变动需求已被切实实现。配置审核的任务即是验证配置项对配置标识的一致性。配置审核的实施是为了确保项目配置管理的有效性，体现配置管理的最根 　本要求，不容许出现任何混乱现象。

 笔者看来，配置管理：实际是对软件开发过程当中是否进行变动进行评估，对执行的变动进行记录使其变得有条理化与逻辑性，进行有序的变动控制，

     

二、软件的组织模式

软件开发的主体——团队

软件工程的主体是人的活动，当一群有必定的集体目标的人汇集在一块儿为开发出具备必定功能的软件而相互合做时，咱们将其称为团队。团队内部的成员，虽然相互合做但每一个人有具体明确的分工。

     

 

　　传统团队的模式：

　　传统的团队的模式，由Constantine［CON93］提出的四种"组织范型"，以下表。 

     

 

团队类型	具体特征
封闭式范型	按照传统的权利层次来组织小组。这种小组在开发与过去已经作过的产品相似的软件时十分有效，但在这种封闭式范型下难以进行创新式的工做
随机式范型	松散地组织小组，并依赖于小组成员我的的主动性。当须要创新或技术上的突破时，按照这种随机式范型组织的小组颇有优点。但当须要"有次序的执行"才能完成工做时，这种小组组织范型就会陷入困境。
开放式范型	试图以一种，既具备封闭式范型的控制性，又包含随机式范型的创新性的方式来组织小组。工做的执行结合了大量的通讯和基于小组一致意见的决策。开放式范型小组结构特别适于解决复杂问题，但可能不象其余类型小组那么效率高
同步式范型	赖于问题的天然划分，组织小组成员各自解决问题的片段，他们之间没有什么主动的通讯须要

      首先："封闭式范型"更相似于官僚模式，人与人之间存在着：明显的阶级关系，这种方式更像咱们在平时上班中的工做关系，你的行为必然会受到你的顶头上司的约束，虽然规则性和秩序性变得更好，但在这种模式下，很容易变成"老板驱动"的工做模型。

　　我的认为开放式泛型，多是比较稳妥的一种开放方式，比封闭式稍具活性，又比随机式更具备必定的约束性，但同时打破了同步式泛型的无交流，无约束的特色。

 

　　当下的团队模式：

 

　　因为咱们如今尚未进入到实战的模式(进行一个实际软件的开发)，因此恰逢罗杰老师(另外一个实战的班级)，因此经过13级的学长们的博文，总结下初步的感悟：

　　从极限编程提及：

  极限编程(eXtreme Programming,XP)：在传统的开发过程当中，增进沟通和交流的典型方式是经过文档，但XP的提倡者们建议用比较随意的交流和沟通方式。不编写单独的文档，反之增强关键的软件产品(例如软件代码和测试数据)。

  在代码复审(就是让别人来看本身的代码，是否在"代码规范"的框架内正确解决了问题)，经过此点，能够发现：在逻辑、算法、潜在和回归性的错误的基础上，互相传授经验，在了解别人代码的基础上也不断提升本身的能级，而代码复审便是极限编程中的一个重要的观点，下面，引出咱们的"重头戏"——结对编程。

　　什么是结对编程？

     

    结对编程是指：一对程序员肩并肩、平等地、互补地进行开发工做。在现实生活中，也有这样的例子：驾驶飞机（主驾驶和副驾驶）。因此这两我的的具体工做分工为：

    一、"主驾驶"负责具体任务的执行(驾驶飞机，编写程序)。

    二、另外一我的负责导航，建议，维护。

    有一点须要注意：在结对编程的过程当中：两我的之间的角色要常常互换，避免长时间被人注视所致使的压力和长时间的复审所引发的审"美"疲劳。

　　为何结对编程？

  结对编程：就是把后期的软件测试和软件复审的工做挪到了在代码编写时，就同步的进行不间断地复审。而好处能够这样理解：让别人在代码已近完工的状况下，再去作代码的测试还不如：在代码的编写阶段进行代码可行性和逻辑正确性的检查，一方面：这样的代码是两我的中能力较好的完成品(固然是结对编程人员的心血与结晶)，另外一方面：结对编程有助于：在互相讨论，互相合做的基础上进行编码，尤为狮是在遇到问题时：能够一块儿解决，有助于提升效率和互相学习；

　　结对编程真的好吗？

  在这里说说笔者的见解：笔者是一个工做时相对独立的人(不喜欢和认识的人坐在一块儿自习)，基于此种性格：结对编程尚有必定的难度系数。这种透明了程序员的所有工做细节与生活方式，在两个不是很熟悉的状况下，须要有一段时间去磨合。此外，在双方实力差距较大，或者基本不能有效的沟通交流的状况下，效果不必定理想，若是"领航员"没有发挥到本身的实际做用，那么结对的意义便不大了。

  结对编程在现实中，不少大型IT都是两我的合做开始的，例如:Jerry Yang & David (Yahoo! 创始人),何况:从某种意义上，：结对合做也是团队合做的基础,更为重要的是：结对过程当中，两我的之间是平等的关系，交流与反馈，是结对编程的核心吧！(话说：我这学期好像是和某我的在结对编程哎：怎么才发现)

　　另外一种团队: 敏捷开发

     

   敏捷开发的主要流程有：

   第一步：找出完成产品须要作的事情

   第二步：决定当前冲刺要解决的事情

　　　第三步：冲刺

　　　第四步：获得软件的一个增量版本，发布给用户。而后在此基础上不断的发布新功能

敏捷团队的主要特色有：自主管理(本身不断反思并改进不足)，自我组织(在本身事情作完后，帮助其余人)，多功能型（负责多项工做）

能够看到：敏捷团队适用于CMM层次比较高的团队，是一种对开发技术人员更高层次的要求。

        

3、能力评估

   软件过程能力描述了一个开发组织开发软件开发高质量软件产品的能力，此过程能力包括可以达到的质量、效率、工期、成本等。现行的国际标准主要有两个：ISO9000.3和CMM。

   ISO9000.3是ISO9000质量体系认证中关于计算机软件质量管理和质量保证标准部分。

   CMM（能力成熟度模型）是美国卡纳基梅隆大学软件工程研究所（CMU/SEI）于1987年提出的评估和指导软件研发项目管理的一系列方法，用5个不断进化的层次来描述软件过程能力。

ISO9000和CMM的共同点是两者都强调了软件产品的质量。所不一样的是，ISO9000强调的是衡量的准则，但没有告诉软件开发人员如何达到好的目标，如何避免差错。CMM则提供了一整套完善的软件研发项目管理的方法。它可告诉软件开发组织，若是要在原有的水平上提升一个等级，应该关注哪些问题，而这正是改进软件过程的工做。

CMM描述了五个级别的软件过程成熟度（初始级，可重复级，已定义级，已定量管理级，优化级），成熟度反映了软件过程能力的大小。

笔者观点：

软件过程能力更多的说的是：软件的开发能力和软件的质量，质量方面已在上文讨论过，而开发能力更多的与团队中人员的因素有关，一个团队中人的能力。

一个团队中不能仅仅由于：一我的的工做量的多少，或是工做时间的长短，或是一我的职位的高低，这些评估方法都欠妥。一种比较好的方法，是利用两个维度完成任务的等级与贡献率)来综合评价，获得一个较为中和的结果。我的认为CMM的级别体系是一个不断上升，演化的阶段。

　　软件项目管理，软件项目是为了达到目标，必须知足真实的须要。本博文从简单的几个方面对软件项目管理进行介绍，还请诸君一阅~，资历尚浅，还请多多指教！

     

     

     

     

参考文献：

1. http://www.cnblogs.com/xinz/p/3857368.html 现代软件工程第十四章练习与讨论
2. http://wiki.mbalib.com/wiki/%E8%BD%AF%E4%BB%B6%E9%85%8D%E7%BD%AE%E7%AE%A1%E7%90%86 软件配置管理
3. http://www.cnblogs.com/jiel/p/4835963.html 2015年我的和团队博客地址
4. 邹欣，现代软件工程[M] 第二版,人民邮电出版社
5. Roger S.Pressman ，软件工程实践者的研究方法[M],机械工业出版社
6. Bob Hughes Mike Cotterell,软件项目管理[M],机械工业出版社
7. http://baike.baidu.com/link?url=FHk0bzXE_F-TUgP-G7ReQ8fhlNWDihlkeaccjPWf2CZP-NZou5CwEnsj1zs92rsUwAmjZB-KtZvOqpDKqIy7f13Y4xbS8zyUd4lRi-9UFSjTPgDQSJrr4vIaQT8pTocznrZFDW-fPXI8b9M44Y_EnK 软件质量保证