软件项目工作经验总结（精选9篇）
20xx年7月23日，我有幸成为公司一员。我进入公司也快6个月，回首过去的几个月中我也感受到不少的喜悦，尤其在公司度过的时间让我难忘。因为在领导的指导下，同事大力的帮助下，客服了不少困难，因此我也成长了不少。可以说是虚心学习，努力工作，以团队的利益和进度为中心是我一直坚守的原则。虽然说在这短短的几个月中没有辉煌的成果，也算是经历了一段不平凡的考验。因为我在公司感受到了团队的力量，同时也让自己更适合团队工作，尤其是我在技术方面更是突破不少，从以前的认识与了解到今天的熟练，想到此内心无比高兴。尤其是刚进公司的两个月，想想当时的我是多么的笨拙和弱小，因为进入公司以后对于公司需求和业务流程不是很熟悉。在同事不断帮助和指导下让我迅速提升起来以适应公司需求，以至于后来的工作做得非常舒心愉快。
20xx年度个人主要工作内容和任务的完成情况
20xx年度，我的主要工作集中在产品研发及优化领域，现将参与的主要工作内容和任务的完成情况总结如下：
一、新人学习
对公司的整体状况和运营模式进行了解，重点针对合同管理系统的适用领域、场景以及客户群体、一般性需求进行学习。熟悉公司技术团的工作模式、编码规范和研发管理控制流程。通过对公司产品关注领域和业务流程的学习以及研发规范的了解，梳理了技术学习主线，制定了具体的学习目标和时间计划为技术研发工作奠定了基础。
二、公司平台的研发
参与了平台的部分功能研发，主要参与以下功能模块的代码编制、优化和初步的功能验证测试：系统平台对接浪潮系统、系统对接审批事项清单模块,系统管理模块,筹备成立模块、成立登记模块、分支机构管理、组织管理、注销信息管理、变更信息管理等等。在研发中，按照团队规划完成了个人的任务并按照编码规范进行了源码优化。对于部分编码进行分析和重构，对于部分功能模块进行了效率优化和源码简化，提升代码的可读性、可复用性、可移植性。整个研发过程，积极融入团队，提升技术水平的同时进一步加深了对公司产品业务的理解。
三、公司产品平台的优化
参与产品平台的优化。使用技术方法通过重构改进了产品的运行效率。从构建模式、实现方法、代码风格上进行了多方面的知识整理、分析和优化。并以此为契机，强化了效率优化的意识，学习了效率优化的方法，同时，增强了研发中兼顾效率的意识。
20xx年度个人取得的成绩和经验
20xx年是我进入公司的第一年，无论是对于生活阅历还是工作经验以及技术知识都取得了很大的成效与进步。在公司的几个月里我着实成长了许多，尤其是对专业知识技能的提升、此外还增长了一些对行业的认识以及开发流程。
20xx年度个人工作中存在的问题和不足及改进方法
刚进公司的时候我面临很多问题，在工作中遇到非常多棘手的问题，不断请教前辈们.有了他们的帮助和自己坚持努力，我发现我所遇到棘手问题越来越少，就这样我从一个新人慢慢变成一个可以担当一面的团队成员，我再也不怕遇到问题。在未来的一年里我应该多锻炼自己表达能力和加强对普通话的学习，其次，对于技术方面了解不够全面，不够广泛，好多技术都还处于一个熟悉、认知阶段。在未来的日子里我会给自己拟定一些目标和学习、提升路线，让自己技术以及各方面不断的提高。不让自己只局限于技术方面的提升与提高在工作中我体会到了坚持就是胜利，程序员必须有较强的适应能力和承受能力,需要不断的进行学习补充新的知识,只有不断的扩充、更新自己的知识才能应变技术的更新与发展。
提出目前公司存在的各方面问题及合理化建议
公司领导比较给力、很会照顾下属，同事之间也比较容易相处，团队互助性也比较强。但是我们公司对于技术上是不是应该增加一点技术储备方面东西。我希望公司能够一个强大知识库，比如某一天某个人解决了一个极难解决或者比较罕见的问题。有必要保存到知识库里，以备后续之人有一个学习认知的空间。
对自己20xx年度整体表现的客观评价
20xx年度是我在学习中不断总结经验、吸取教训、获得成长的年度。
本年度的工作中，我认真制定工作计划，按时完成工作任务并适时进行总结和分析，关注功能实现、代码规范、效率优化和用户体验。努力开展对本职工作所需专业技术学习，优化知识结构，并不断深化对合同管理业务的理解。团队建设上，我积极融入团队，努力营造良好的团队氛围，和同事关系融洽。
综上所述，对于20xx年的工作整体表现，我对自己的评定是满意的。
2020xx年度工作计划安排
1.在原有体系不变动情况下，配合团队完成社会组织信息系统后续的开发。
2.加强自己工作中阐述问题的能力和分析能力以及解决问题的能力。
3.不断学习新的技术与知识，让自己更能适应新的需求发展变化，给自己制定一个短期目标以计划。
4.努力更正自己开发习惯，提升自己开发技巧。
5.了解技术以外的知识，摆脱自己“机器人”的概念。
个人职业生涯规划
一、短期目标（提升专业技术水平、掌握解决问题的方法）
合理规划自己时间，给自己制定一个工作之余的学习计划，学习目标，在工作不断吸取经验教训加以总结汇总，不断更正自己工作习惯。
二、长期目标（专注改进薄弱环节，掌握提升效率的技巧，深化业务理解）
在不断巩固自己专业知识前提下，加深对业务的理解能力、分析能力、主导能力、不断充实自己各方面知识技能，强化自己薄弱环节。做一个合格高级软件工程师。
1.1教学理念落后
受到传统教育思想的影响，我国高校工程教学长期以来以教师为教学环节中的主体，教师在教学过程中强调知识传授，忽略了对学生实践动手能力、创新能力、团队合作精神和相关人文素质的培养。传统的“面向对象软件工程”课程的教学也存在着上述问题。
1.2传统项目驱动教学方法在实施中的不足
项目驱动教学方法是在具体项目引导下以学生为主体来实施相关教学内容的一种教学模式。当前国内很多高校在开展项目驱动教学时，往往会变成走形式主义，具体表现在：①教师对于学生的工程意识培养不够重视，对项目的选择或者设计比较主观（具体表现在所选择的项目很难或很易），这要么会引起学生有畏惧情绪而产生厌学，要么会使学生很容易地实现该项目（这种情况是因为学生可通过网络轻易完成项目），从而使得该课程项目失去原本意义；②在实施过程中，由于组织不当，会使得学生团队人数过多，搭配不合理，这样使得有些团队因配置了能力很强的学生而使得该项目能够顺利完成，同时另一些团队由于聚集了能力偏弱且自觉性较差的学生而使得该项目最终流于形式，这反而会导致项目驱动教学未能达到应有的教学目标。传统的“面向对象软件工程”课程项目的实施过程中也存在着上述问题。
1.3CDIO工程教育模式在“面向对象软件
工程”课程改革中起到的作用针对上述问题，CDIO工程教育模式摒弃了以教师、教材和课堂为中心的“旧三中心论”，弘扬了以学生、学习和学习效果为中心的“新三中心论”，更强调通过工程实践环节引导学生掌握新知识和动手与创新能力，从而树立起以产品为导向的工程价值观，将IT企业工程师应该具备的核心素质作为整个教育活动的主线。在实施CDIO教学过程中，将更强调学生在教师的引导下进行主动学习和积极认知过程，以构建起与学生已有认知结构相联系的知识体系。
2基于CDIO工程教育模式的教学方法
基于CDIO工程教育模式的项目驱动“面向对象软件工程”课程教学方法（下简称CDIO教学法），以培养学生的基本工程能力和工程综合素质为目标，将“面向对象软件工程”知识体系中的相关知识点渗透到实践的各个环节中，而这些环节和软件工程生命周期完全一致，在各个环节中解决问题的方法则可以采用CDIO的构思、设计、实现和运行理念。我们参照CDIO能力大纲，提出通过“面向对象软件工程”教学和课程项目实践，培养学生如下方面能力：①通过基于案例/项目驱动来学习，要求学生能够深入理解“面向对象软件工程”的知识体系和该课程的基础理论并能在实际项目中加以灵活应用。“面向对象软件工程”的知识体系为学生理解和应用其基础理论解决分析、设计、实现和运行中的实际问题打下基础并提供有效工具；而“面向对象软件工程”理论基础为学生针对实际问题进行发明创造提供动力，为学生发现问题、分析问题和解决问题提供理论支持。②通过“面向对象软件工程”课程中项目的驱动，要求学生创建项目团队，通过课程项目实践各个环节（包括需求分析、设计和实现等环节及在此环节中的各项活动、沟通与协调、文档撰写），培养学生的良好职业素养，以及团队合作、系统思维、工程实践、项目管理和文档写作的能力。③通过“面向对象软件工程”理论学习和课程实践，培养学生的创新意识和能力，以开发出具有鲜明个性的软件作品。
3CDIO教学法在“面向对象软件工程”理论及其课程项目教学设计中的应用
3.1总体设计
目前，“面向对象软件工程”课程教学安排共计54学时，我们将理论教学内容与课程项目实践教学内容结合起来进行设计。在整个教学周期内，按照软件生命周期并结合CDIO、案例与项目驱动的教学法，设计理论课程案例教学过程中的相关活动，配合对应的课程项目实施活动加以有效组织与实践，在整个教学环节结合项目开发活动的进展与深入，要求学生记录自己团队活动中的相关内容，按照我们事先制定的规范撰写并维护项目文档。具体解决方案是：第一，正式课程教学的1~6周，设计项目描述和需求获取与分析、系统设计中的具体活动，这些活动包括分别标识实体对象、边界对象和控制对象；将用例映射成对象；建立对象之间的交互；标识关联、聚集和属性；对单一对象状态依赖行为的建模；对对象之间的继承关系建模；对本阶段的分析对象模型进行评审；基于分析对象模型标识出设计目标，进行子系统分解和标识；将子系统映射到系统构件元素上；标识并存储持久性数据；设计访问控制策略；设计全局控制流；标识服务；标识边界条件；对系统设计进行评审。第二，7~14周，设计对象设计与实现中的活动，这些活动包括学习软件复用和设计模式，并在详细设计中加以应用；对对象之间的接口进行说明，涉及标识遗漏的属性和操作、说明接口类型、签名与可见性，说明接口中相关方法的前置条件、后置条件和不变式等。第三，15~16周，设计测试阶段中的活动。第四，17周，进行相关的总结活动，包括项目文档的静态检查和验收，以及课程项目的动态演示与现场回答问题。
3.2设计课程项目
在设计课程项目中，将考虑提供给学生一个贯穿整个学期的课程教学项目描述，为此我们将选择开发一个基于Web的应用系统。这类系统的实例很多，可以由教师设定或者由学生自选，如教师可根据教学中的需要设定一类基于Web的师生交流系统，以方便实现教师和学生之间关于做项目时的沟通。学生也可以根据个人兴趣选择网游软件开发，或者选择基于Web的电子商务网站系统等。总之，相关项目的设计需要教师事先准备好项目描述或问题定义。为了开发这类基于Web的应用系统，教师需要指定项目使用的环境和工具，主要包括两类：一类是开发环境与工具、数据库管理系统、界面开发工具等，另一类是项目管理工具。这一阶段设计的活动属于CDIO中的构思阶段。
3.3设计理论课程教学过程
首先，在理论课程教学内容设计中，我们主要依据的是第3版的SWEBOK标准（20xx），在CDIO工程教育模式的指导下，完成相关知识体系教学设计。在SWEBOK20xx版中的17个知识点中（其中2个为候补知识点），我们选择了其中10个知识点，并将这些知识点融合到“面向对象软件工程”的理论课程教学中。这些知识点可有效地体现着CDIO的工程教育理念，如软件需求体现了CDIO的构思，软件设计体现了CDIO的设计，软件构造和软件测试体现了CDIO的实现，软件维护体现了CDIO的运作等。其次，在此基础上设计理论教学过程。一方面，以案例/项目驱动教学方法为基础，“面向对象软件工程”课程中相关知识体系及理论学习，要求学生在学习和思考中掌握“面向对象软件工程”的相关知识、术语、理论和技术基础，并通过团队方式共同学习、讨论和完成作业，并以团队形式参加全体同学的各种讨论活动；另一方面，要求学生围绕着项目描述或者待解决的问题描述，完成团队组建、工具选择、项目计划制定，并开始执行需求工程中的.需求获取和需求分析活动，以及在此基础上的系统设计活动，这些阶段的工作结论需要学生加以记录，特别是需求获取与分析的结论和总体设计结论更要以文档形式加以记录。第三，结合案例/项目驱动教学，进一步完成“面向对象软件工程”理论课程。具体做法是一方面引入小型案例，另一方面引入面向应用领域的实际项目，并在项目描述、需求获取和分析活动、系统设计和对象设计中，将该项目的具体情景或者可行的系统设计解决方案引入课堂，在课堂上组织学生参与讨论、分析这些基于场景的案例，将需求阶段和系统设计阶段中涉及的重点知识、术语、过程与步骤等重点和难点融入到案例中来讲解和学习，以便于学生真正理解相关的理论教学内容。这一阶段的活动设计对应着CDIO中的构思阶段。
3.4基于项目驱动的课程实验教学设计
解决软件项目中的问题或实现软件项目中的任务，要求学生以团队方式进行活动，并在整个活动中的各个阶段贯彻CDIO工程教育的理念，即让学生能够对软件项目中的任务完成进行构思，获取与软件项目相对应的软件系统的功能性需求、非功能性需求和系统约束，并以文档方式进行描述；接着，通过设计手段来完成项目任务，用系统来对应将来要完成的任务，并在该系统设计中落实项目的各项要求，这需要通过对系统的总体设计、详细设计等环节来达到，并将设计结论记录在软件设计文档中；在前面构思和设计的基础上，选择合适的程序设计语言、数据库管理系统等基础设施，用编程的方式实现该系统，并完成相应的测试任务，注意在实现过程中，同样要将相关结论以文档的形式加以记录，以备维护之需；在系统实现后，通过部署和运行等方式，让该软件系统（可以看成是本项目的解决方案）呈现出价值。在这一完整过程中，让学生通过项目驱动下的团队活动过程，体验到软件产品从构思、设计、实现到运行（包括维护）所经历的全生命周期过程。这一阶段的活动设计对应着CDIO中的设计、实现阶段。
3.5项目总结与项目验收过程教学设计
项目总结过程的教学设计是以团队为单位进行自我总结并撰写项目总结报告，以个人为单位撰写学习心得，教师主要验收和检查相应的项目总结报告和学生学习心得。项目验收过程的核心是开展两阶段验收活动，即在学期的15~18周中，选择第15周进行一次中期检查，第18周再进行一次期终项目验收。全体主讲教师和辅导教师组成一个答辩小组（一般为4人），他们事先要做好各项准备工作，包括现场点名以确认学生的有效身份并结合点名宣布学生团队的答辩顺序，保证答辩的有效性和合理性；由答辩小组组长宣布评分标准细节和学生是否能够通过本次验收活动的标准。
4实践活动
在“面向对象软件工程”课程教学活动中，共有45位学生（组成了15个团队）全程参与了我们的教学改革过程，现在仅就验收答辩环节进行说明。整个答辩所耗时间共计7个多小时；答辩老师根据实际情况（最低底线是学生必须完成项目要求的最基本功能），充分肯定了学生到目前为止所完成的开发成果，同时建议相关学生利用即将到来的假期进一步完成或完善该应用软件系统的开发，及时修改设计上的缺陷。在本次教改实验过程中，我们充分认识到这一教学过程对教师也提出了更高的要求。教师不仅仅是需要在理论基础教学上过硬，还需要具备软件项目开发的经验，这样才能够做到既能站在理论的高度指导学生分析和解决问题，同时也能给出实实在在的课程项目开发活动中的技术指导。
5结语
论文关键词：软件过程；软件项目管理；流程管理
1引言
长期以来，软件项目高失败率的状况一直困扰着人们，研究表明，软件项目失败的原因主要有两个：一是应用项目的复杂性；二是缺乏合格的软件项目管理人才。实践证明缺乏有效的项目管理是导致软件项目失控的直接原因。软件开发的风险之所以大，是由于软件过程能力低，其中最关键的问题在于软件开发组织不能很好地管理其软件过程，从而使一些好的开发方法和技术不能起到预期的作用。
流程管理作为现代企业管理的先进思想和有效工具，随着市场环境与组织模式的变化，在以计算机网络为基础的现代社会信息化背景下越发显示出其威力和效用。流程管理不仅是一种管理技术，更体现了现代管理的思想。流程管理的重点是：理清和管理好所有主、支流程间的关系，使他们相互协调发挥应有的作用。流程管理增加了部门的透明度，管理的对象不是“部门”和“部门员工”的概念，而是以工序流程为管理对象，注重流程中每一个过程和效率以及和上下游工序的关系，管理重点在于整体流程的完整性和顺畅性。目前，流程管理技术的研究已越来越受到人重视。
运用流程管理方法和技术进行软件项日管理，可以有效地改变软件过程管理混乱的局面首先埘软件项目开发过程进行有效的、规范化的定义；其次，在软件项目开发过程中，所有的活动过程均按照流程所规定的活动的逻辑关系、活动的实现方式来执行，这样可以使得所有的`活动有序和可控；第三，通过明确运作流程，使项目组人员迅速融入项目和开发过程中；第四，关注每个过程的“结果”，使软件项目的所有工作产品均能得到有效的保存，保证了软件产品完整性。
2流程的概念及在软件项目管理中的作用
流程是由活动组成的。基本活动是由个人或团体来完成的，它不需要进行其他的基本活动的转化。流程的各个活动之间有着特定的流向，它包含着明确的起始活动与终止活动，因此是一个动态的概念。从结构上来看，流程有四个基本的构成因素：活动、活动的逻辑关系、活动的实现方式和活动的承担者。流程与“一系列的活动或事件”，“结果”等概念密切相关。流程管理不仅是一种管理技术，更体现了现代管理的思想，原有的以控制、塔式组织为基础的职能行政管理已经不能完全满足于现代企业发展和市场竞争的需要，管理的发展沿着分工理论运行了上百年后，现在又重新回归到整合与系统。
软件项目生命周期的一系列的开发过程是各种各样的流程活动：软件项目的计划编制、系统分析、慨要设计、详细设计、程序编码、测试与维护等活动过程都是一种流程活动：制定软件项目管理流程，重点考虑以下几点：
1)制定的流程能引导项目逐步走向成功；
2)制定的流程能适用软件开发过程；
3)制定的流程能指导项目开发活动.有利于对项日开发活动的管理；
4)制定的流程能以苴观的流程图表示.能使项目组成员清楚的知道软件开发与管理的过程和相互之间关系；
5)流程中的起始活动条件、终止活动条件明确、规范便于控制：
6)流程中的工作产品定义明确、可度趟，评价标准和方法具体、可操作
3软件项目管理总体流程设计
在软件项目开发管理过程中，不仪要努力实现项目的范围、时间、成本和质量等目际，还必须协调整个项目过程，以满足项目参与者及其他利益柑关者的需要和期望；随着软件规模和所涉及的领域不断地扩大，软件项目的管理越来越困难，纵观所有失败的软件项目.基本原因是不能管理其软件过程，在无纪律的、混乱的项目状态下，组织不可能从较好的方法和工具中获益。严谨的软件过程控制管理不仅可以在每个阶段回顾和纠正项目的偏差.别软件项目的风险甚至果断中止项目。且可以将人才流动所带来的不利影响减少到最小。要进行有效的过程控制，必须明确软件项目管理流程。
软件项目管理总体流程设计为项目搜寻、立项、售前合同生成和合同执行等5个主要阶段，分别以pl、p2、p3、p4、p5表示；同时设计了立项完成、合同签定、功能定义、软件开发、项目验收等5个里程碑，分别以tm1、tm2、tm3、tm4、tm5表示，如图l所示。在这些流程中，合同执行流程是软件项目管理的核心，其主要过程有：产品定义、软件开发、测试执行、内部验收、项目实施与验收、项目维护.
4软件项目管理总体流程分析
4.1项目搜寻
项目搜寻是项目立项的基础，项目搜寻阶段的主要任务包括市场信息收集，用户需求跟踪，对潜存的项目进行分析和筛选。
4.2项目立项
立项阶段的主要任务是确认立项的理由，提出立项建议，提供合适的资金和资源，使立项建议成为正式项目。
4.3项目售前
售前阶段从项目立项开始到项目合同的签定结束，主要工作有：制定与客户的交流计划，详细了解客户的背景资料，了解客户启动项目的缘由、目的和期望，编制项目方案建议书，准备合同蓝本。
4.4合同生成
合同生成阶段的主要工作有：项目方案的评估与确定技术合同、商务合同的商定、评估与签署。
4.5合同执行
合同执行是软件项目管理流程的重点，可分为软件开发、测试执行；内部验收、项目验收、系统维护等五个基本工作过程。
4.5.1软件开发
软件开发阶段分为：需求调研、系统分析、系统设计、编码、单元测试等过程。主要从三个方面进行管理：
1)制定项目计划。软件项目计划是一个用来协调所有其他计划，以指导项目执行和控制的可操作文件。它体现了对客户需求的理解，是开展项日活动的基础，也是软件项目跟踪与监控的依据。
2)确定开发过程。根据软件项目和项目组的实际情况，建立起一个稳定、可控的软件开发过程模型，并按照该过程来进行软件开发
3)加强过程控制一过程控制主要包括过程管理、变更控制和配置管理，、
4.5.2测试与执行
项目测试的目的是俭查系统是否符合项目合同与任务书规定的要求、项目测试分集成测试和系统测试，主要进行功能测试、健壮性测试、性能一效率测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试等测试过程在模拟运行环境中进行。
4.5.3内部验收
项目完成集成测试和系统测试后进行项目内部验收.主要有三个步骤：①文档准备。项目经删提交内部验收计划、项目开发总结报告、产品清单：财务主管提交项目财务预算报告。②内部验收测试。内部验收测试的测试内容与方法虽然与系统测试基本相同.但应站在用户验收的角度进行，因为它是试运行的基础。通过这一步。为用户验收作充分的准备。③内部评审。对提交的所有文档及测试结果进行内部评审，完成项目开发总结报告：
4，5，4项目试运行与验收
试运行与用户验收阶段的主要任务是，使所有的工作产品得到用户的确认。主要工作有：①验收前的准备。项目经理负责检查产品的完整性。包括文卡当、介质和中间产品等，以确保现场实施的成功；负责应用软件的现场安装调试，完成安装调试总结报告；负责制定用户验收计划，并得到客户的确认。②用户进行验收测试和系统试运行，进行文档和系统的移交。③用户确认。项目经理负责与客户协测，协助用户进行项目验收，形成用户验收报告。
4 5.5项目维护
软件系统的维护分为两大类：一类是纠错性维护，由于前期的测试不可能暴露软件系统中所有潜在的和隐含的错误，诊断和改正这些错误的过程为纠错性维护。另一类是完善性维护，在软件正常使用过程中，用户还会不断地提出新的需求，为了满足用户新的需求而增加软件功能的活动称为完善性维护。如果需求变更很大，那完善性维护将转变为软件新版本的开发。系统维护的宗旨就是提高客户对软件产品的满意度。确保系统的正常运行是系统维护的根本目的。
4.6软件项目管理的里程碑
项目的考核与评审是软件项目管理流程控制的基础，我们在整个流程中设定五个基线，即确定五个里程碑，它们分别是tm1：立项完成；tm2：合同签订；tm3：产品功能定义完成；tm4：软件开发完成；tm5：验收通过。
如图1所示。各阶段的主要的进入条件和相应的工作结果是里程碑是否达到的重要标志。
5结束语
软件项目管理这门课程是我们软件工程专业学生的一门重要的课程，这门课程的开设必有其重要性。软件项目管理的提出是在20世纪70年代中期的美国。由于开发项目不能按时提交、超出预算、质量达不到用户的要求等原因，70%的项目出现问题。于是，软件开发者开始逐渐重视软件开发中的各项管理。软件项目管理和其他项目管理相比有相当的特殊性。首先，软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。其次，软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。因此，项目管理对软件生产具有决定性的意义。
只有相信团队合作才可能把项目做到最好，从整个项目的过程来看，团队合作中需要沟通、分工、协作和监督。只有做好这四项才算是一个好的合作团队。首先，团队合作最基本的技能就是沟通。沟通的目的就是让别人了解你的想法，因为每个人考虑问题的时候总会有各种各样的偏差，我们只有沟通很好的沟通来综合所有人的好的想法，以减少走弯路，而让事情进行的更顺利。因此我们也开了几次会议来互相了解沟通，当然最重要的是与项目经理的沟通。会议中他很认真负责地跟我沟通，我在沟通中用词不当或犯什么错误时，他都会指出来，并改正我的说法，因此单从与他的沟通中就学到了不少以后工作时将会用到的实在的知识。我们项目每人都是按照他给我们的计划提交相应的文件给他，但质量是参差不齐的，他都会进行审核，然后给出建议，让我们修改优化后，他才会通过。
我在此次课程中负责的部分是质量保证计划书，这是从未了解过的内容。从课程和书本上的知识不足以让我完成质量保证计划书，于是又从网上找了很多模板和每一小项是在说些什么内容来完成我们组的质量保证计划书。在这个过程中我学到了很多。我也感受到软件项目管理是一门非常需要学习的课程。它对软件工程项目的作用是至关重要的。现在，作为学生的我所做的项目虽然都是一些小的项目，但是在小组共同开发的时候还是需要用到项目的管理。如：人员的分配，时间、进度的计划，沟通计划，项目执行变更管理，以及质量管理控制等多种管理。我相信在今后的实习及工作当中，能更好的体验和感受到项目管理的精髓，对软件项目管理有更深入的了解。我也希望，学校的老师能够在今后的教学当中重视软件项目管理课程，多让学生了解实例，去感受、体会软件项目管理所遇到的问题和解决方案，理解软件项目管理的精髓。
对软件项目的管理者来说，他最应该关心的是能否按时优质地交付产品的问题。在计划软件开发的路线时，他必须首先考虑软件基本功能的实现和工程交付期，其次，才考虑产品的卖点，许多工程失败的原因就在于设计者没有时间概念，工程前松后紧或增加了许多次要的技术特征，这样反而对产品质量形成了威胁，总之，最重要的是懂得统筹安排各个环节。
面试程序员理想的方法是由开发小组的其他成员一起来面试，如果谁看不上眼，他都不能加入，否则以后会有很多麻烦。这样做的另一个好处是借此机会互相认识一下，经理一定要把新员工介绍给大家，并且小组每个员工都应该过来握手介绍自己，这是起码的招聘礼节。
程序员需要关心尊重
曾经有个例子，某公司开发人员王某由于刚开始学习编程，技术水平差一点，常常受到经理的“另眼相看”，每次软件出现了问题都怀疑是他的原因，老开他的低级玩笑，这位员工会有怎样的表现就可想而知了。经理通过这种手段能够迫使这一位自动辞职吗?非也，这位员工后来工作非常不负责任，把代码写得既长又重复，且在代码中留下大量的隐患，此时，经理却反而不敢过份得罪他了(否则，留下的巨量代码很难维护)。如果认为某人不适合目前工作，为何不另请高明?既然已经请他作了这件工作，就得尊重他。不能指望开发人员在非工作场合谈吐得体、办事周到、眼观六路、耳听八方，正所谓“尺有所短，寸有所长”，例如要求技术人员在酒席宴上象公关小姐或公关先生一样举止适度，从来不会有好的效果。软件人员普遍喜欢自由而宽松的工作环境，最好不要做过多的无谓的规定，例如不准迟到、上班必须换拖鞋，否则罚款等等。如果确实有人经常上班迟到，工作不认真等，首先应该了解原因，此时多作思想工作是必要的，许多公司的经理们认为“思想工作”是过时的东西了，其实不然，私企职工背负的心理压力其实很重。他们特别需要有人关心，特别需要心理上的“减负”。管理需要合理地使用资金，有的公司在不该花钱的时候花钱，在需要花钱的时候节支，结果却事倍功半。例如，员工向公司提出买台电视、热水器、电风扇等生活设施(甚至是厕所的纸巾)时，公司强调节支，而在组织大家集体乘飞机到外省旅游这种事情上却舍得花钱，这种现象比较普遍，效果却不一定好，因为员工会认为公司集中花一笔钱是在收买人心。所以，关心职工的事情需要过细地作。
心态调整问题
作坊式作业的时候，软件是由一两个程序员写的，软件写完了，虽然在产权上这个软件或许不是自己的，但程序员心里会觉得这个软件就是自己的，对这个软件的感情就象对自己的儿子一样，关于这个软件一切成败荣辱都被看成是自己的，在这种心态下，程序员会不分白天黑夜地超常投入。而现在的软件一般都是十几人、几十人甚至上百人协作完成，软件写成后究竟是谁的?有了荣誉是谁的?都不是太明确，同样，软件有点毛病也不专是哪个人的，而是大家的，既然是大家的事情，那就让大家来做，我为什么多操那个心?如何在大协作的背景下最大限度地提高个人的积极性很值得仔细研究。设计部分大家参与、多开会交流、让程序员直接倾听用户对自己工作的意见等方法不妨一试。
关键词:企业;信息系统;软件外包;关键因素
1 引言
随着现代信息技术的发展与应用,国内各行业的信息化建设全面展开。信息化建设离不开各种信息系统的支持,如办公自动化系统、管理信息系统、电子商务系统、决策支持系统等。企业在开发信息系统时,有些需要外包给软件开发商来完成,企业只有把握好外包中的几项关键因素,才能成功实施软件系统的外包。
2 企业信息系统软件外包成功实施的关键因素
烟草行业卷烟生产经营决策管理系统(即“一号工程”)是20xx年国家烟草专卖局根据行业宏观调控和科学决策信息化建设发展的需要建设的信息化系统。系统建立了行业数据交换体系,通过打扫码、数据库联机方式自动采集行业生产经营基础数据,构建行业业务指标体系和数据分析模型,建立国家局数据中心,实现国家局分析展现应用的界面集成和业务集成。“一号工程”是烟草行业软件外包的一个典型的成功案例[1]。
(1)选择技术实力强、口碑好的软件外包企业
企业在选择软件外包商时,可采取公开招投标方式,对投标单位从技术能力、人员能力及软件过程能力进行综合评估,选择员工作风好、保密观念强、政治觉悟高的企业作为接包方,确保系统数据安全,并与接包方签订《保密责任协议书》,建立安全保密分级管理制度。
如“一号工程”于20xx年通过公开招投标,确定由中国计算机软件与技术服务总公司(即中软总公司)作为项目总集成商,中软总公司委托其下属的中软国际承接项目建设工作。中软总公司是国家规划布局内重点软件企业,实力雄厚;中软国际是国内领先的应用软件和解决方案供应商,在国内IT行业享有较高的声誉。
(2)充分调研与沟通,作好项目需求分析工作
企业在软件外包时必须做好项目需求分析工作。业务部门提出用户需求后,通过与技术部门、软件开发人员多次交流沟通,提出系统的综合要求及标准。开发人员通过分析系统需求,了解用户工作流程并对其进行正确分类,确定系统的`可接受性、可实施性、可测试性;在形成需求报告之前,对后期发现的不明确、不一致的地方要进行修改或补充;最后项目经理应邀请客户代表共同评审需求文档的正确性、完整性和清晰性,使需求文档正确无误地反映用户需求。
(3)明确各部门职责,选派专人参与开发过程,保证项目进度及安全
企业应明确参与部门(如归口管理部门、牵头部门、协作部门等)的具体职责,避免在软件开发出现问题时由于没有建立合理的分工、反馈和跟踪制度出现多方推诿现象;企业还应选派技术人员全程参与开发过程并建立项目进展情况表。企业参与软件开发,不仅可以培养自己的技术力量,还可以及时协调、解决出现的问题,为项目进度提供保障,还能对项目涉及的保密数据进行脱密处理,进而保证项目安全。
例如,“一号工程”在建设过程中成立了项目领导小组,国家局局长姜成康亲自主抓,副局长李克明任组长,信息中心主任高锦任副组长,各单位负责人是领导小组成员。成立了项目实施办公室,做到了分工明确,各司其责。从公开招投标到各阶段的项目建设,每个方案都经过了专家会议的若干次讨论,每一阶段国家局都召开了专门的会议进行部署。李克明副局长亲自参与布置各个阶段的工作,协调各方关系,为项目建设提供了保障。
(4)做好软件测试工作,进一步提高软件产品质量
从技术角度看,各种信息系统开发的最终目的就是得到高质量的软件产品。企业为保证软件产品质量和可靠性,必须做好软件测试工作。通过制定软件测试计划,做好测试准备工作;组建测试团队,包括测试项目负责人、测试分析员、测试设计员、测试程序员、测试员、测试系统管理员、配置管理员;选择合适的测试方法,静态测试或者动态测试,白盒测试或者黑盒测试,重点要进行可靠性及安全性测试;选择测试工具,如Parasoft、Compuware、Xunit等白盒测试工具,LoadRunner、WinRunner、Astra Quicktest等黑盒测试工具;重点做好测试中Bug和需求变更的跟踪和管理,做好Bug分类、缺陷记录、版本控制等工作。
(5)严格做好软件验收工作
软件项目的验收非常重要。企业在接到验收申请后,要认真审查软件系统的运行、文档资料、培训工作等现状,对于符合验收条件的项目,要严格按照验收标准和流程来验收。验收的主要依据是软件需求规格说明书。验收程序分技术测试和文档检查。技术测试由专家组负责。文档检查主要检查招投标书、合同、用户使用报告、信息安全测评报告、系统使用手册等。验收测试范围包括功能项测试、业务流程测试、容错测试、安全性测试、性能测试、易用性测试、适应性测试、文档测试等。
如“一号工程”作为耗时两年半精心打造的信息化项目,验收时非常严格规范。验收委员会由中国工程院院士孙家广、沈昌祥等13名专家组成。中软国际的验收资料齐全完备,在《项目验收总结报告》中详细描述其建设过程,涵盖了从方案论证、软件开发到项目实施与服务、合同完成情况等方面的工作。中烟信息技术公司随即构建了运行维护体系,设立了客户服务、技术支持等部门,在完成日常维护的同时,以电话支持和现场服务等方式为行业基层提供服务或解决操作上出现的问题。
(6)做好商业秘密、核心技术等知识产权保护工作
企业在软件外包开发中,要做好知识产权保护工作。首先,要和接包方签订严格的保密协议,要求他们指定专人负责对核心技术的使用控制;其次,企业要通过技术分析及数据过滤提供尽可能少的核心机密;第三,尽量在发包方本地进行后期的数据装入,以减少商业秘密泄漏的可能。
对于产生的其他知识产权,根据我国《计算机软件保护条例》的规定:“接受他人委托开发的软件,其着作权的归属由委托人与受托人签订书面合同约定;无书面合同或者合同未作明确约定的,其着作权由受托人享有。”对此,企业要与接包方签订书面合同,明确以下3点归属问题:(1)软件作为一个整体的知识产权归属;(2)软件中的代码归属及重用性约束等具体规定;(3)因知识产权归属的法律适用及发生侵权纠纷的具体解决方式,包括责任的承担、损失的追偿等。
3 结语
软件外包对于企业来说,可以提高开发效率、降低成本。充分做好以上几项工作,才能减少外包风险,保证软件产品质量,为企业带来更好的经济和社会效益。同时,企业还要针对软件项目特点,运用适合自身的项目管理模式来加强软件外包项目管理,尤其要规范项目实施过程,才能迅速适应业务需求的变化,提高软件系统的运行效率,提升企业的核心竞争力。
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量风险等进行分析和管理的活动。软件项日管理最早出现于7o年代中期，当时美国国防部专门立项研究软件项目失败的原因，发现70％的项目失败是I如于管理不善引起的。而并不是因为技术能力。从而得出一个结论，即管理是影响项目全局的因素，而技术只影响局部。所以软件项目管理至关重要。在关系到软件项目成功与否的众多因素中，项目规划、需求变化、软件质量、风险管理等都是与项目管理直接相关的因素。因此，提高软件项目管理的能力对软件组织的软件生产力的提高是最为重要的。本人对目前软件企业实施项目管理的状况进行了分析，结合软件项目管理的理论知识，以期找出在软件项目管理中常见的问题。促进软件项目管理的应用研究。完善软件项目管理在软件企业的实施。
1软件项目管理存在的主要问题
1.1项目计划问题
项目计划是—个用来协调所有其他计划，以指导项目执行和控制的文件。项目计划是项目经理实施项目管理控制的基础。制定计划的过程就是—个对项目逐渐了解掌握的过程，通过认真地制定汁划，项目经理可以知道哪些要素是明确的。哪些要素是需要逐渐明确的，通过渐近明细不断完善项目计划。目前的问题主要有：一是项目计划的制定不够严谨，随意性大.可操作性差，因而实施中无法遵循。如项目计划过于粗略.落实粒度(“Breakdown”)不足，不能做到任务、进度、资源三落实。二是缺乏贯穿项目全程的详细项目计划，甚至采用每周来制定下周工作计划的逐周项目计划方式，其实质是“项目失控合法化”。三是项目进度的检查(与进度计划对比)和控制不足。不能维护项目计划的严肃性。
1.2管理意识问题
在软件企业中。项目经理大多是技术骨干，在技术方面的知识比较深厚，但是项目管理知识、项目管理必备的技能，项目管理的经验都有待提高。部分项目经理没有意识到自己是项目经理的角色。不是从总体上去管理整个项目而是埋头干具体的技术工作，其计划不周造成项目组成员任务分配不均.忙的忙、闲的闲，这将影响项目的最终实施。有些项目经理对于一些不服从管理的技术人员，没有较好的管理方法，不好安排的工作只好th己做。
1.3项目干系人相关问题
项目千系人(“STAKEHOLDER”)是指参与项目和受项目活动影响的人，包括项目发起人、项目组、协助人、顾客、使用者、供应商，甚至是项目的反对人。人们的需求和期望在项目的开始直至结束都是非常重要的。不同的干系人其期望和追求的目标往往相差甚远，因此对项目十系人的愿望进行平衡是相当困难的事情。例如政府部门的不少对群众办公的信息系统，上层管理机关往往希望能够采集尽可能多的信息项以便对数据进行多种多样的系统分析，并对信息进行有效控制而增加一些审批流程；基层对外办公的窗口则因为办公速度的压力希望减少信息的输入；而办事群众则希望相关政府机构能够简化工作流程，加快办事速度。如果对项目所有干系人没有进行足够的沟通，使其尽可能地参与项目，则可能因为项目开始时项目范围和一些具体要求不够完整清晰，或某个项目干系人后期认识的变化而提出新的要求，造成工期的延长，成本的增加，甚至项目的完全失败。
1.4项目团队内分工协作问题
由于项目开发的各阶段不同角色、同一阶段不同角色的责任各不相同，项目经理把工作责任分画给团队成员时通常会出现一些不良现象。首先是山于分工不够清晰而造成工作相互推诿、责任互相推卸的现象；另外是出现“自家打扫¨前雪”的现象，即虽然分工比较清晰但是各成员只顾完成自己的那部分任务而不愿意与他人协作。
1.5沟通意识问题
项目沟通管理包括确保及时、正确地产生、收集、存储和最终处理所需项目信息的过程。它是人、思路和信息之间的关键纽带，是成功所必须的。虽然整个项目是项目经理负责，但是在决定这个业务单元山某个或者某两个人完成后，项目经理只能起管理上的控制、建议和指导的角色，不能对具体的内容进行过多的干预在软件企业中，项目经理大多是技术骨干，而项目组成员也都是“高科技人员”，都具有“从专业或学术出发、工作自主性大、自我欣赏、以自我为中心”等共同的特点。因此妨碍沟通因素主要是“感觉和态度问题”，也就是沟通意识和习惯的问题。在系统的实施阶段或软件开发的试运行阶段，项目成员基本上是持续在客户方进行工作，这种情况非常容易忽视沟通。如果没有足够的沟通意识和沟通制度、沟通工具，就有可能造成信息不畅，从而加大项目失败的风险。
1.6项目风险管理意识问题
项目风险管理是指为了最好地达到项目的目标，识别、分配、应对项目生命周期内风险的科学与艺术。风险管理对选择项目、确定项目范围和制定现实的进度计划和成本估算有积极的影响，并有助于项目千系人了解项目的本质，使团队成员参与确定优势和劣势。目前项目风险管理意识的问题主要有两种情况。第一是项目经理没有充分分析可能的风险，对付风险的策略考虑比较简单，在做项目规划时常常没有做专门的风险管理it~’l文档，而是合并在项目计划书中。第二是项目经理没有充分意识到风险管理的重要性。对计划书中风险管理的章节简单应付了事，随便列出几个风险，随便地写一些简单的对策，对后面的风险防范起不了什么指导作用。
1.7项目收尾问题
项目经验总结是项目经理和项目组人员在项目完成后就取得的教训写的报告，是项目收尾的一个重要组成部分。总结在本项目中哪些方法和事情使项目进行得更好、哪些对项目制造了麻烦、以后应在项目中避免什么情况。哪些事情应在后面的'项目中坚持等等。项目经理在项目结束时有些是因为项目人员已经不足或不全，或是因为有新的项目要接没有时问，总体对项目经验总结的重视程度不够。有些是项目经验总结一再拖延，有些是交上来的报告质量较低，敷衍了事。
2加强软件项目管理的建议及措施
2.I制定相符的项目计划
制定计划的精髓不在于写出一份好看的文档，而在于运用您的智慧去应对各种问题和面临风险并尽可能做出前瞻性的思考。计划是用来指导工作的，制定项目计划必须把握项目it~，l的粒度，粒度越细则控制力度越大，但项目管理的成本越高，反之则控制力度越小。凶此必须按照特定的项目量体裁衣，该详细就详细，该简略的就简略，制定相符的项目计划。许多组织都有项目计划制定的指导原则。例如，美国国防部的2l67标准“软件开发计划”用于指导那些为国防部开发软件的开发商制定软件开发计划。电气和电子工程师协会(IEEE)的1058.1标准描述了“软件项目管理计划”的主要内容。表l给出了“1EEFYI，T：，准软件管理计划”的格式。遵循那些标准和方针有利于项41汁划的制定和执行一旦it~，l被负责任地完成，他就可以给闩己一个和管理层或客户交流和协商的基础，帮助其在项目过程中防范各种题的出现，保证项H的按时完成.
2.2使用w BS(WorkBreakdownStructure)和资源负荷直方图，合理分配任务
项目经理应使用工作分解结构WBS将项目工作范围进行分解，为了避免有些虽然工作分解结构WBS没汁合理，但项目任务无法有效、合理地分配给相关成员，可采用资源负荷直方图把工作任务合理分配并达到“负载均衡”。另外.技术骨r在担任项目经理之前，最好能系统地学习项目管理知识，特别是其中的人力资源管理、沟通管理，并且在实际工作中不断提高角已的管理素质，丰富项目管理的经验，提高项目管理的意识。
2.3项目组成员应互相协作、互相配合
项41经理通过使用WBS将工作范尉进行分解.并将工作责任分配给团队成员，同时应强调不同分工、不同环节的成员应当相互协作，共同完成任务。虽然项目的进行有不同阶段的划分，但各阶段还是相互联系的。上一阶段工作的结束不能只交付阶段性成果，往往要通过多次沟通才能更为清晰地披下一阶段成员所接受，其有效性、合理性也要被下一阶段的工作所检查，通过检验有时也有必要对上一阶段的工作结果进行相应的凋整。因此，项H组成员都应根据需要相互协作，相互配合，共同完成任务。
24加强沟通意识
项目沟通管理指出：“管理者要用70％的时问用十与人沟通，而项目经理需要花费90％或更多的时间来沟通”从沟通的效果和效率角度出发，一股应注意下面四种情况：首先是沟通之前对沟通的基本慨念和目标进行清晰的界定其次是不能凯溺十沟通本身，而必须时刻清楚沟通的目的；意到沟通是有成本的，沟通的时间就是成本，客户在为这些成本买单第三是一些规则，包括时和回合的限制、耐心听完对方的I舌，进行“集中”决策。最后是为了做好事件.必须事先进行明确，进行充分的授权。另外，项目经理及其项14组成员要对项14下系人进行分析，项目1：系人分析要记录重要的I：系人的人名、组织、他们各在项目中的角色、每个I：系人的实际情况、他们各自的项目利益大小、以及各自对项目的影响程度，以及管理这些项14 r系人的有关建’义等。通过沟通协调.以驱动他们对项目的支持，减少其对项41的阻力，以确保项41获得成功
2.5加强风险管理意识
项目经理必须通过学项41管理知，掌握项H风险管理的必备知，加强对项14汁划中的风险管理汁划的审核，提高项41组的管理意识。总结本行业项目中常见的风险及其对策作为风险管理汁划中必要的『x【险内容，并切实评估相应对策的有效性和可行性。
2.6重视项目经验总结
项41经理及管理人员应对项目经验总结引起足够重视。在制度上鼓励和JJu强项目经验总结工作，使得项41经验总结及时并且具有指导意义而不是敷衍了事，为以后的项41人员更好地工作提供一个极好的资源和依据。
一、短期目标(提升专业技术水平、掌握解决问题的方法)
合理规划自己时间，给自己制定一个工作之余的学习计划，学习目标，在工作不断吸取经验教训加以总结汇总，不断更正自己工作习惯。
二、长期目标(专注改进薄弱环节，掌握提升效率的技巧，深化业务理解)
在不断巩固自己专业知识前提下，加深对业务的理解能力、分析能力、主导能力、不断充实自己各方面知识技能，强化自己薄弱环节。做一个合格高级软件工程师。
自2月份开始，我一直在跟进xx银行w-nd1s2.0项目的测试工作，至此为止已近6个月时间，从公司内部系统测试、验收测试，再到uat测试，以及投产前的系统压力测试等等。从开始到项目即将结束，一步步走过来。本次项目中，我作为测试环节的主力人员之一，仅对此项目中测试工作进行总结。
一、项目测试进度控制。项目的测试进度主要是按照项目计划进行的，完全按照项目组计划要求完成测试任务、提交测试类相关文档，包括测试案例的完善、制定测试计划、执行测试、缺陷跟踪以及bug回归测试等。协调项目的内部测试工作，本此项目中测试小组一共组织了四轮次系统全面测试工作，认真配合项目工作，共同保证项目质量。项目测试的问题跟踪及处理采用每日进行修改问题回归测试工作，每日同步更新问题跟踪单的模式，按照规划时间完成系统更新测试。
二、项目组内部成员关系处理。在项目工作的这几个月里大家相处融洽，项目组内部共同探讨解决问题的方法，向各模块负责人学习模块功能处理方式，向业务人员了解系统中涉及的业务知识点，两者结合起来进行模块功能测试。鉴于之前辖内对公交易系统和中行对公项目的经验，也向项目组提出了一些完善性意见。
三、协调用户测试方面。用户验收测试是项目测试工作的重要组成部分之一，是项目验收阶段的最终把关阶段，业务人员结合日常业务处理情况对系统进行的尝试性使用过程。本次项目客户测试方面也是我个人觉得不够安全感一个主要方面，客户测试介入力度太小，尽管我们已经很多次电话催促业务人员测试，每次联系相关业务人员进行测试，他们来到项目组开发现场测试，也仅仅一两个小时时间，简单的进行验证操作即可。xx银行利用两批系统培训的时间安排了两次分行集中测试，也算给项目进行了一次全面的测试，从中也暴露出不少系统存在的问题，目前项目组均已解决。
四、测试成效方面。中信x-funds2.0系统测试中，共记录问题及客户新增需求825个，其中bug数量512个、系统完善类问题225个，新增需求类问题88个。组织了四轮次内部系统全面测试工作，兼顾日常系统更新测试工作，最大限度的进行了内部质量把关。配合外包公司一同进行系统压力测试及稳定性测试，测试结果符合客户要求。现中信x-funds2.0系统临近投产实施工作，测试组还将继续配合配合项目投产工作及投产后的补丁更新测试工作。
四、个人得失方面。作为此次项目测试的负责人，对于日常的测试流程、测试任务分配、测试执行、缺陷跟踪、协调内部测试及协调客户测试方面能力均得到了进一步提高，理清了项目整个过程中测试小组的工作过程以及后期的项目移交工作。同时也对各子系统相应的业务知识有了更进一步认知。相关业务知识方面还需要进一步加强，测试技能及测试管理方面还需要进一步完善学习。更好的吸收项目经验，做好以后的补丁测试工作及其他项目的测试工作。
1、估算前的规划
当我们的办公室内堆满了杂乱无章的文件时，恐怕无法知道对于我们真正有用的文件在哪里，当我们的软件相目中收集了各种需求、意见、问题时，我们也很难从中估算出整个项目的规模、工作量以及成本。因此，在估算之前我们首先要对众多信息进行整理、归类分析，从而得到一个条理清晰的项目计划，在这个计划提供的框架内，才可能开始正确的估算。精心的规划是任何一个软件开发项目成功与否的关键，有了规划就有如成竹在胸，之后无论风云变幻，都有应对入流的方法。当然只有正确的规划，才能给软件开发指引正确的方向。
软件项目规划的重点是对人员角色、任务进度、经费、设备资源、工作成果等等做出合适的安排，制定出一些计划(包括高层的和细节的)，使大家按照计划行事，最终顺利地达到预定的目标。
1.1、规划的第一步：确定软件范围
确定软件范围，就是确定目标软件的数据和控制、功能、性能、约束、接口以及可靠性。这项工作和需求分析是很类似的，如果之前已经达成需求分析规约，那么可以直接从《需求分析说明书》中把有用的部分拿来使用。如果还没有开始需求分析，关于确定软件范围的方法方面，我们可以采用许多需求分析技术(如需求诱导)，从客户那里得到一个具体的软件范围。当然如果是一次全新的软件边界探索，就应当考虑软件本身可行性问题，包括团队是否具备在技术、财务、时间、资源上游可靠的保障，软件本身在市场上是否有可靠的竞争优势，等等。
获得软件范围，最直接最可靠的来源就是用户对软件的需求描述。例如，在开发一个C/S架构的铁路供电段数据上报系统中，客户向我们提供了以下的目标软件需求描述：
在供电站总部每天结束前要审核下属节点操作员(30~40个)的供电安全数据报表，要求每个节点必须在下午5：30~6：00之间上传数据。总部系统通过自动分析，整理出整个区内的安全形势报表，并自动反馈到每个节点。各个节点之间通过调制解调器拨号(MODEM)用内部电话线相连，每个节点电脑主机配备一个MODEM。上传数据为制式报表出了制式信息外，系统自动附加操作员姓名、上报时间、上报节点名称。信息一旦上传，节点端就不可以对已提交信息进行修改、删除，只能阅读、查询。节点间数据互相隔离，只有总部才具备对各个节点数据的管理权限，但是对于归档数据(一旦审核完毕的数据，就进行归档)总部不具备删改的权限。系统设置数据库管理员，独立于审核权限，其职责是对历史数据的清理维护。
通过上面的描述，我们通过提炼和简化，得到软件的一下功能：
节点数据录入、查询、上传
总部数据汇总、查询、反馈
总部与节点的互联项目管理培训
总部数据库存储
节点数据的本地存储项目管理论坛
在本例中，软件的性能是潜在的。客户虽然没有明确提出，但是由于数据本身的重要性，要求系统在数据上传、反馈、存储过程中安全可靠。客户要求使用MODEM进行拨号连接，那么鉴于MODEM连接过程中可能会出现，由于拨号断开而道导致的数据丢失，在节点本地存放一份数据副本是有必要的。由于系统要求每天上传数据，总部数据库应当是7X24小时不间断服务的，再加上目前总部只有该系统运行接受数据任务，各节点数据量并不大，那么在建议用户选择服务器时，应当考虑性能稳定可靠，但并不一定要购买大容量磁盘阵列和高性能双CPU主机。由于每天上传数据接近下班时间，那么总部汇总数据应当是自动进行的，一旦分析发现重大问题，可以通过与外部网络的设置，向值班人员发送手机讯息、E-MAIL或其他警示。由于不同人员对于上报数据的权限不同，对于系统用户实行分级管理。不同级别的用户，具有对数据的不同管理权力，从而保证在软件使用过程中不发生混乱。
那么现在一个较为清晰的软件模型已经构造完毕，接下来我们需要进入计划的第二步：确定工作所需资源。
1.2、规划的第二步：确定工作所需资源
软件工作所需资源包括：工作环境(软硬件环境、办公室环境)、可复用软件资源(构件、中间件)、人力资源(包括不同各种角色的人员：分析师、设计师、测试师、程序员、项目经理……)。这三种资源的组成比例，可以看作一个金字塔的模式，最上面是人力资源、其次是可复用软件资源、最下面是工作环境。最上面的是组成比例最小的，最下面的是组成比例最大的部分。
■人力资源
一个项目到底需要多少种职务的人员构成、多少数量的人员总量，再能成为最有创造力的团队呢?这恐怕是最让项目经理头疼的事情了。任何一个软件工程，都必须在确定软件的工作量之后，才能清楚地知道究竟需要多少人力才能以最小成本和最高效率完成任务。在这之前，不能盲目地进行人力扩充，而且绝对不能为了给公司抬高门面，盲目招收高学历。
■可复用软件资源
这是一个容易在计划阶段被忽视的重要资源，很多人总是进入编码阶段才发现可复用资源的价值和存在。经过长期的项目积累或是购买，公司的软件资源库中或许已经积累了大量的可复用资源，但在当前任务中，只能选择有价值的资源。根据不同的应用、时间、来源，可复用软件资源被分为以下几种：
可直接使用的构件：已有的，能够从第三方厂商获得或已经在以前的项目中开发过的软件。这些构件已经经过验证及确认且可以直接用在当前的项目中。
具有完全经验的构件：已有的为以前类似于当前要开发的项目建立的规约、设计、代码、或测试数据。当前软件项目组的成员在这些构件所代表的应用领域中具有丰富的经验。因此，对于这类构件进行所需的修改其风险相对较小。
具有部分经验的构件：已有的为以前与当前要开发的项目相关的项目建立的规约、设计、代码、或测试数据，但需做实质上的修改。当前软件项目组的成员在这些构件所代表的应用领域中仅有有限的经验，因此，对于这类构件进行所需的修改会有相当程度的风险。
新构件：软件项目组为满足当前项目的特定需要而必须专门开发的软件构件。
在采用构件的时候，应当以低成本、低风险为使用前提。如果任何一个漂亮的构件的应用，可能会带来潜在出错的风险或者必须经过复杂修改或者效率低下时，我们都应当毫不犹豫地把它抛弃。我们只采用那些能够满足项目的需要且可直接使用的构件，或者具有完全经验的构件，或者经过稍微修改便可使用的构件。项目经理博客
■环境资源
“工欲善其事，必先利其器”，要得到高效的开发过程，就必须向工作人员提供良好的软硬件环境，包括开发工具、开发设备、工作环境、管理制度。一般管理人员都会购买可以满足需要的软件开发工具和硬件平台，但是工作环境和管理制度往往被忽视。项目管理者联盟
站在人件的角度看，向工作人员提供更轻松自在、安静舒适的办公环境的公司员工往往比整天在狭小隔间中工作的公司员工，产生更高的工作效率。而那些拥有灵活人性化的管理制度的公司，比整天加班的公司更能留住高技术的人才。所以如何在有限资金中，规划一个合理的环境是很重要的事情。转
到此为止，估算前的项目计划已经完成，我们已经形成一个工程开发框架。这是一个有界限的框架，虽然还不够精确，但足以进行估算的工作。
2、估算的对象
目前为止，一个较为准确的软件项目估算的定义是：在给定公差范围内，对于姚开发的软件规模的预测，以及对开发软件所需的工作量、成本和日历事件的预测。这个概念指出了一个事实，即估算是一种大约的估计，是将误差限定在一定范围内的估计。
估算主要包括以下几个重要内容：
规模估算
软件估算首先要将整个工程的规模估算出来，才能进行下面的其他估算。规模，就是一个工程可量化的结果，是用具体数字来体现项目的描述。规模估算的信息来源是清晰、有界限的用户需求。
工作量估算
这是对开发软件所需的工作时间的估算，它和进度估算一起决定了开发团队的规模和构建。通常以人时、人天、人月、人年的单位来衡量，这些不同单位之间可以进行合理的转换。
进度估算
进度时项目自始至终之间的一个时间段。进度以不同阶段的里程碑作为标志。进度估算是针对以阶段为单位的估算，而不是对每一个细小任务都加以估算，对任务的适当分解很重要，分解得越细反而会不准确。因为任何一个软件工程，在各个方面都有与生俱来的不确定性。
成本估算
包括人力、物质、有形的、无形的支出成本估算，其中以人力成本为主要部分。比较容易被忽视的使学习成本、软件培训成本、人员变动风险成本、开发延期成本等，一些潜在成本消耗。
3、估算的策略
在软件估算的众多方法中，存在着“自顶向下”和“自底向上”两种不同的策略，两种策略的出发点不同，适应于不同的场合使用。项目管理培训
3.1、自顶向下的策略
这是一种站在客户的角度来看问题的策略。它总是以客户的要求为最高目标，任何估算结果都必须符合这个目标。其工作方法是，由项目经理为主的一个核心小组根据客户的要求，确定一个时间期限，然后根据这个期限，将任务分解，将开发工作进行对号入座，以获得一个估算结果。项目管理者联盟文章
当然由于这完全是从客户要求出发的策略，而由于软件工程是一个综合项目，几乎没有哪个项目能完全保质保量按照预定工期完工，那么这样一个策略就缺少了许多客观性。但是由于这样完成的估算比较容易被客户、甚至被项目经理所接受，在许多公司我们看到这样一个并不科学的策略仍然被坚定地执行着。项目管理培训
3.2、自底向上的策略
与自顶向下的策略完全相反，自底向上的策略是一种从技术、人性的角度出发看问题的策略。在这样一个策略指引下，将项目充分讨论得到一个合理的任务分解。在将每个任务的难易程度，每个任务依照项目成员的特点、兴趣特长进行分配，并要求进行估算。最后将估算加起来就是项目的估算值。
显然自底向上的这种策略具有较为客观的特点，但是它的缺点就是这样一来项目工期就和客户的要求不一致了。而且由于其带来的不确定性，许多项目经理也不会采用这种方法。项目经理圈子
4、估算的方法项目管理者联盟
显然估算是建立在客观实际上，对未来尽可能合理的一种预测。那么估算本身的不确定性，决定了它不可能是百分之百准确无误的。在项目刚开始时，人们对产品需求、技术、市场预期、人员素质等因素的了解还远远不够，在这种情况下人们很难作出准确的估计。但是依据某种方法进行估计显然比瞎猜好得多。项目管理者联盟文章
估算方法有很多，大致分为基于分解的技术和基于经验模型两大类。基于分解的技术的方法包括功能点估算法、LOC估算法、MARKII等;基于经验模型的方法包括IBM模型、普特南模型、COCOMO模型等。
4.1、FP功能点估算法项目管理论坛
功能点估算法是一种在需求分析阶段基于系统功能的一种规模估计方法。通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。这种方法的计算公式是：功能点=信息处理规模x技术复杂度。信息处理规模包括各种输入、输出、查询、内部逻辑文件数、外部接口文件数等等;技术复杂度包括性能复杂度、配置项目复杂度、数据通信复杂度、分布式处理复杂度、在线更新复杂度等等。项目管理论坛
4.2、LOC估算法
这是一种从技术的角度来估算的方法总称，其中又包含许多方法。这类方法以代码(LOC)作为软件工作量的估算单位，在早期的系统开发中较为广泛使用。基于LOC的估算，又有点也有缺点。优点在于方便计算、容易监控、能反映程序员的思维能力;缺点在于代码行数的含糊不清，不能正确反映一项工作的难易程度以及代码的效率。因此在传统的LOC方法进行了许多改进。其中不断被使用，且不断演化的方法包括以下：
PERT功能点估算法：PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert统计估计，Pert估计可得到代码行的期望值和标准偏差SD。项目管理论坛
类比估算法：类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。
Delphi估算法：Delphi法是一种专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别。对于需要预测和深度分析的领域，依赖于专家的技术指导，可以获得较为客观的估算。通过专家们的互相讨论，还可以博取众长
系统分解：将系统分成若干个易于用LOC估算的部分，将其各个估算结果累加就是LOC的总规模。其中关键是建立起SBS(系统分解结构)，它描述了系统的不同组件。SBS还被使用在其他重要的地方，如系统设计、系统分析等。在进行分解的时候，可以采用自由讨论的形式，可以获得更合理的SBS构成。项目经理圈子
4.3、IBM模型估算法
该模型是Watson和Felix在1977年的，是基于IBM联合系统分布负责的60个项目的总结而得到的模型。该模型是一个静态模型，而参考数据只有60多个项目，因此有很大的局限性。
4.4、COCOMO估算法转自项目管理者联盟
Boehm在其经典著作“软件工程经济学”(softwareengineeringconomics)中，介绍了一种软件估算模型的层次体系，称为COCOMO(构造性成本模型，COnstructiveCOstMOdel)，它代表了软件估算的一个综合经验模型。项目经理博客
COCOMO模型是适用于三种类型的软件项目：(1)组织模式——较小的、简单的软件项目，有良好应用经验的小型项目组，针对一组不是很严格的需求开展工作(如，为一个热传输系统开发的热分析程序);(2)半分离模式——一个中等的软件项目(在规模和复杂性上)，具有不同经验水平的项目组必须满足严格的及不严格的'需求(如，一个事务处理系统，对于终端硬件和数据库软件有确定需求);(3)嵌入模式——必须在一组严格的硬件、软件及操作约束下开发的软件项目(如，飞机的航空控制系统)。
4.5、软件方程式估算法项目管理论坛
软件方程式是一个多变量模型，它假设在软件开发项目的整个生命周期中的一个特定的工作量分布。该模型是从4000多个当代的软件项目中收集的生产率数据中导出的公式。初期的方程式较为复杂，通过，Putnam和Myers的努力又提出一组简化的方程式。当然这种方法也是基于长期的参考数据的积累而得到的。
4.6、WBS估算法w
这是一种基于WBS(工作任务分解)的方法，即先把项目任务进行合理的细分，分到可以确认的程度，如某种材料，某种设备，某一活动单元等。然后估算每个WBS要素的费用。采用这一方法的前提条件或先决步骤是：项目管理者联盟
对项目需求作出一个完整的限定。
制定完成任务所必需的逻辑步骤。
编制WBS表。
项目需求的完整限定应包括工作报告书、规格书以及总进度表。工作报告书是指实施项目所需的各项工作的叙述性说明，它应确认必须达到的目标。如果有资金等限制，该信息也应包括在内。规格书是对工时、设备以及材料标价的根据。它应该能使项目人员和用户了解工时、设备以及材料估价的依据。总进度表应明确项目实施的主要阶段和分界点，其中应包括长期定货、原型试验、设计评审会议以及其他任何关键的决策点。如果可能，用来指导成本估算的总进度表应含有项目开始和结束的日历时间。
除了以上介绍的几种方法外，还有一些其他的方法：类比估算、推测估算、Standard-component估算法、普特南估算法等。当然不同的方法适用于不同的具体环境，有些方法虽然很好但并不一定适合当前的任务。只有量体裁衣，具体问题具体分析，才能得到尽量合理的估算。
5、估算的戒律项目管理者联盟
记住：应该满足于事物的本性所能容许的精确度，当只能近似于真理时，不要去寻求绝对的准确——亚里斯多德
对于任何一个项目经理，都知道要慎重估算，但是我们仍然会看到人力资源的浪费和财力资源的匮乏，在许多项目中存在。对于宝贵的资源，我们不是用得太多，就是根本不够用。因此，有以下前人总结出来的一些经验以供借鉴。
不要追求完美：就像没有人能预测出未来，如果还没有完成，就不要企图完美的结果。更何况估算的太精确，反而会失去灵活机动的空间。
不要为满足预算而估算：如果这个项目的预算根本不能完成100%的任务，那么就不要让你的团队委曲求全。正确地反映客观现状，不仅可以争取应得的权利，而且是完成任务的前提。
不要随意削减估算结果：有很多老板喜欢把项目经理递交的估算，不假思索地砍掉一部分。这是一种不负责任的做法，如果要削减一定要有理由。
客观地估算，不贪多不偷减：就像老板不能随便削减你的估算一样，你也同样不能在估算的时候，贪多或是偷减。贪多必然导致会浪费，偷减必然导致不足。这两个结果恐怕都不是一个合格的项目经理的作为。
客观利用过去的经验：对于以往估算的经验，当然是宝贵的财富，但是如果财富用错了地方就会变成垃圾。在使用经验时，要注意现在和参考经验之间的差异。不要忘记，随着时间的推移，计算机领域技术的更新，许多观念都在发生着改变。项目管理培训