初步接触《软件工程》这门专业课，在我看来：软件工程是一个极具挑战性的项目，在约定的时间内，整个项目小组可以在满足用户需求与软件基本规范的情况下，开发出稳定可靠的软件。但是，在软件开发的过程中，往往有许多不可规避的风险与未知的情况，例如：软件不能按时交付，软件的成本明显超过预期，软件未能达到用户的需求等等，"如果所用的时间是预计时间的两倍以上或费用超出预算两倍以上的项目为失控项目"，为了有效规避项目在开发过程中的风险，所以笼统来说，项目管理指的是：根据特定的规范，在预算的范围内，按时完成指定的任务，运用高效快捷的方法，围绕计划对项目进行监控，在人力、费用和时间上进行控制。作为Team16小组的组长，在整个软件的开发过程中，实际担任的是"项目经理"的任务，所以下面让我们几个小节来谈谈软件项目管理。
软件管理虽然涉及诸多的因素，例如：成本，质量，时间，资源等，但实际问题可以归结于：人员，问题和过程。当在软件工程开发的过程中，遇到了问题：需要人员之间的沟通与交流来进行解决，当然：人员是软件工程开发中的核心力量。
一、软件过程控制
在国际上，有这几个通用的标准：
软件质量保证（SQA-Software Quality Assurance）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的。ISO9000就是其中的一种，也就是产品的"说明书"。
软件配置管理(SCM)是指在开发过程中各阶段，管理计算机程序演变的学科，它作为软件工程的关键元素。已经成为软件开发和维护的重要组成部分。SCM提供了结构化的、有序化的、产品化的管理软件工程的方法。它涵盖了软件生命周期的所有领域并影响所有数据和过程。
1、软件的质量需求
ISO 9001对质量的定义是"客户要求的一种产品或服务所具备的所有特性"。从宏观上来看，软件质量的要求可分为：规定的和隐含的需求，规定的是指：用户明确提出的需求和需要，而隐含的需求是指：需要开发者自己来明确的基本的需求，例如：软件的功能，软件的使用周期等。ISO确定了六中软件质量的特性：功能性，可靠性，可用性，有效性，可维护性，可移植性。
2、ISO软件质量评价模型
从1985年开始，国际标准化组织ISO和IEC就不断地该改进软件质量标准，现有的ISO质量标准，笔者以ISO/IEC 9126-1《产品质量-质量模型》，列出质量的三个方面：
3、笔者的理解
如果将：软件看作程序和软件工程的集合体，那么：软件的质量就包括两方面：
软件的质量 = 程序的质量 + 软件工程的质量
程序的质量偏重于代码的功能性实现，而软件工程的质量则偏重于除去代码本身的其他外界组成因素。
软件工程的质量大致体现在以下几个方面：
一个软件在开发的过程中，最主要的与实际相关的便是：人力与物力的消费。成本包括时间与金钱等，虽然古语有云"十年磨一剑"，但在如今高速发展的互联网时代，用如此长的时间周期去开发一个软件，显然是乌托邦幻想的情节。
软件开发实际是一个人与人之间的集体活动（以笔者的理解），每个人都会负责相应的模块与自己的责任，这就产生了人与人之间的关系，当然这些关系在特定的条件下，可能如同"级联现象"一样，被各种各样的因素所影响；例如：项目成员的突然退出(笔者就曾经遇到过这样的情况，结果项目组成员单个人的任务量就增多，同时项目的进度也受到影响)，开发过程没有做很好的备份(当然现在许多软件的开发都依托于github托管 平台，便于管理与控制)，开发难度过大(项目在开始的过程中，一开始预期的实现效果由于技术人和人的因素，而导致在预定的期限内无法完成，历史上：IBM 推出的System/360 Operating System就是一例)
在软件开发的过程中，往往是分模块来进行，任务会进行人员的划分，在项目开发计划的甘特图(时间进度表)中，项目里程碑事件标志着这个子模块时间的结束，"千里之堤毁于蚁穴"，不妨以此类比，内部模块的质量的好坏，里程碑事件的完成标准，项目各模块之间的连接关系等小的事件往往会决定整体部分的质量。
4、说说软件测试的那些事(坑)？
为什么要做软件测试？因为当我们规定了软件质量的标准后，测试则是：软件功能性需求是否得到满足的有效体现，同时：在测试的过程中也有可能发现未知的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，所以后期的维护与更新一定程度上也体现了软件质量的提升。
5、关于软件配置管理
定义：软件配置管理(SCM) 是在整个软件工程中应用的一种普适性活动，在卡发的过程中，变更随时会发生，SCM活动主要应用于:标识变更、控制变更、保证恰当的实施变更、向有关人员报告变更。
软件在配置管理中有4个主要的目标:
-
统一标识软件配置项
-
管理一个或多个软件配置项的变更
-
便于构造应用系统的不同版本
-
在配置随时间演化的过程中，确保软件的质量
由此，定义了5个SCM任务：标识，版本控制、变更控制、配置审核和报告。
标识配置项：利用面向对象的方法，对每个配置项进行标识，对软件开发过程中的所有软件项目赋予唯一的标识符，便于对其进行状态控制和管理。
版本控制：存储在开发过程中，相关数据项的所有版本，便与软件的开发与回退，避免出现：丢失版本或不知版本问题。感觉用github托管，会更加方便。
变更控制：通过对变更申请人的变更请求进行评估，形成变更报告，建立工程变更单(ECO),对变更进行实施，同时：建立适当的版本与记录。
配置审核和报告：变更控制的补充手段，来确保某一变更需求已被切实实现。配置审核的任务便是验证配置项对配置标识的一致性。配置审核的实施是为了确保项目配置管理的有效性，体现配置管理的最根 本要求，不允许出现任何混乱现象。
笔者看来，配置管理：实际是对软件开发过程中是否进行变更进行评估，对执行的变更进行记录使其变得有条理化与逻辑性，进行有序的变更控制，
二、软件的组织模式
软件开发的主体——团队
软件工程的主体是人的活动，当一群有一定的集体目标的人聚集在一起为开发出具有一定功能的软件而相互合作时，我们将其称为团队。团队内部的成员，虽然相互合作但每个人有具体明确的分工。
传统的团队的模式，由Constantine［CON93］提出的四种"组织范型"，如下表。
|
团队类型 |
具体特征 |
|
封闭式范型 |
按照传统的权利层次来组织小组。这种小组在开发与过去已经做过的产品类似的软件时十分有效，但在这种封闭式范型下难以进行创新式的工作 |
|
随机式范型 |
松散地组织小组，并依赖于小组成员个人的主动性。当需要创新或技术上的突破时，按照这种随机式范型组织的小组很有优势。但当需要"有次序的执行"才能完成工作时，这种小组组织范型就会陷入困境。 |
|
开放式范型 |
试图以一种，既具有封闭式范型的控制性，又包含随机式范型的创新性的方式来组织小组。工作的执行结合了大量的通信和基于小组一致意见的决策。开放式范型小组结构特别适于解决复杂问题，但可能不象其他类型小组那么效率高 |
|
同步式范型 |
赖于问题的自然划分，组织小组成员各自解决问题的片断，他们之间没有什么主动的通信需要 |
首先："封闭式范型"更类似于官僚模式，人与人之间存在着：明显的阶级关系，这种方式更像我们在平时上班中的工作关系，你的行为必然会受到你的顶头上司的约束，虽然规则性和秩序性变得更好，但在这种模式下，很容易变成"老板驱动"的工作模型。
个人认为开放式泛型，可能是比较稳妥的一种开放方式，比封闭式稍具活性，又比随机式更具有一定的约束性，但同时打破了同步式泛型的无交流，无约束的特点。
由于我们现在还没有进入到实战的模式(进行一个实际软件的开发)，所以恰逢罗杰老师(另一个实战的班级)，所以通过13级的学长们的博文，总结下初步的感悟：
从极限编程说起：
极限编程(eXtreme Programming,XP)：在传统的开发过程中，增进沟通和交流的典型方式是通过文档，但XP的提倡者们建议用比较随意的交流和沟通方式。不编写单独的文档，反之加强关键的软件产品(例如软件代码和测试数据)。
在代码复审(就是让别人来看自己的代码，是否在"代码规范"的框架内正确解决了问题)，通过此点，可以发现：在逻辑、算法、潜在和回归性的错误的基础上，互相传授经验，在了解别人代码的基础上也不断提高自己的能级，而代码复审即是极限编程中的一个重要的观点，下面，引出我们的"重头戏"——结对编程。
什么是结对编程？
结对编程是指：一对程序员肩并肩、平等地、互补地进行开发工作。在现实生活中，也有这样的例子：驾驶飞机（主驾驶和副驾驶）。所以这两个人的具体工作分工为：
1、"主驾驶"负责具体任务的执行(驾驶飞机，编写程序)。
2、另一个人负责导航，建议，维护。
有一点需要注意：在结对编程的过程中：两个人之间的角色要经常互换，避免长时间被人注视所导致的压力和长时间的复审所引起的审"美"疲劳。
为什么结对编程？
结对编程：就是把后期的软件测试和软件复审的工作挪到了在代码编写时，就同步的进行不间断地复审。而好处可以这样理解：让别人在代码已近完工的情况下，再去做代码的测试还不如：在代码的编写阶段进行代码可行性和逻辑正确性的检查，一方面：这样的代码是两个人中能力较好的完成品(当然是结对编程人员的心血与结晶)，另一方面：结对编程有助于：在互相讨论，互相合作的基础上进行编码，尤其狮是在遇到问题时：可以一起解决，有助于提高效率和互相学习；
结对编程真的好吗？
在这里说说笔者的看法：笔者是一个工作时相对独立的人(不喜欢和认识的人坐在一起自习)，基于此种性格：结对编程尚有一定的难度系数。这种透明了程序员的全部工作细节与生活方式，在两个不是很熟悉的情况下，需要有一段时间去磨合。此外，在双方实力差距较大，或者基本不能有效的沟通交流的情况下，效果不一定理想，如果"领航员"没有发挥到自己的实际作用，那么结对的意义便不大了。
结对编程在现实中，很多大型IT都是两个人合作开始的，例如:Jerry Yang & David (Yahoo! 创始人),况且:从某种意义上，：结对合作也是团队合作的基础,更为重要的是：结对过程中，两个人之间是平等的关系，交流与反馈，是结对编程的核心吧！(话说：我这学期好像是和某个人在结对编程哎：怎么才发现)
另一种团队: 敏捷开发
敏捷开发的主要流程有：
第一步：找出完成产品需要做的事情
第二步：决定当前冲刺要解决的事情
第三步：冲刺
第四步：得到软件的一个增量版本，发布给用户。然后在此基础上不断的发布新功能
敏捷团队的主要特点有：自主管理(自己不断反思并改进不足)，自我组织(在自己事情做完后，帮助其他人)，多功能型（负责多项工作）
可以看到：敏捷团队适用于CMM层次比较高的团队，是一种对开发技术人员更高层次的要求。
三、能力评估
软件过程能力描述了一个开发组织开发软件开发高质量软件产品的能力，此过程能力包括能够达到的质量、效率、工期、成本等。现行的国际标准主要有两个：ISO9000.3和CMM。
ISO9000.3是ISO9000质量体系认证中关于计算机软件质量管理和质量保证标准部分。
CMM（能力成熟度模型）是美国卡纳基梅隆大学软件工程研究所（CMU/SEI）于1987年提出的评估和指导软件研发项目管理的一系列方法，用5个不断进化的层次来描述软件过程能力。
ISO9000和CMM的共同点是二者都强调了软件产品的质量。所不同的是，ISO9000强调的是衡量的准则，但没有告诉软件开发人员如何达到好的目标，如何避免差错。CMM则提供了一整套完善的软件研发项目管理的方法。它可告诉软件开发组织，如果要在原有的水平上提高一个等级，应该关注哪些问题，而这正是改进软件过程的工作。
CMM描述了五个级别的软件过程成熟度（初始级，可重复级，已定义级，已定量管理级，优化级），成熟度反映了软件过程能力的大小。
笔者观点：
软件过程能力更多的说的是：软件的开发能力和软件的质量，质量方面已在上文讨论过，而开发能力更多的与团队中人员的因素有关，一个团队中人的能力。
一个团队中不能仅仅因为：一个人的工作量的多少，或是工作时间的长短，或是一个人职位的高低，这些评估方法都欠妥。一种比较好的方法，是利用两个维度完成任务的等级与贡献率)来综合评价，得到一个较为中和的结果。个人认为CMM的级别体系是一个不断上升，演化的阶段。
软件项目管理，软件项目是为了达到目标，必须满足真实的需要。本博文从简单的几个方面对软件项目管理进行介绍，还请诸君一阅~，资历尚浅，还请多多指教！
参考文献：
-
http://www.cnblogs.com/xinz/p/3857368.html现代软件工程第十四章练习与讨论
-
http://www.cnblogs.com/jiel/p/4835963.html 2015年个人和团队博客地址
-
邹欣，现代软件工程[M] 第二版,人民邮电出版社
-
Roger S.Pressman ，软件工程实践者的研究方法[M],机械工业出版社
-
Bob Hughes Mike Cotterell,软件项目管理[M],机械工业出版社
-