软件项目主要阶段及各个阶段主要工作.doc

软件项目关键分为哪些阶段？各个阶段关键做哪些工作？
本人在两个中小型软件开发企业工作过几年, 也做过几年项目管理工作。走过部分弯路也得出部分项目管理方面体会, 在此进行总结, 期望能够与其她部分项目管理人员或对项目管理有爱好同事共同探讨部分中小型项目管理问题及方法。 
大部分中小型软件开发企业软件项目常常碰到部分问题可能包含: 项目时间紧、 项目组组员常常加班; 项目需求变更频繁; 项目进行过程中可能就有项目团体组员离职或调离到其她项目组; 项目反复性建设问题严重, 每个项目都需要从框架开始重新开发, 难以重用已经有项目结果等等。我认为经过很好计划和管理能够在一定程度上提升项目成功率或者说提升项目质量, 降低开发成本, 缩短项目开发时间。 
我了解项目管理有两个大划分方法一是通用项目管理体系, 也就是PMP中所说5个项目管理过程组9个知识领域44个项目管理过程; 二是具体业务领域按项目生命期划分各阶段管理。本文关键从项目生命期各阶段管理方面进行总结。 
    我个人分析一个软件项目生命期大致需要经过步骤（这只是我个人一个划分, 有可能不是很全方面）: 可行性分析、 需求、 设计、 开发、 测试、 实施、 维护、 总结。 
    下面我针对每个阶段谈一下自己体会。 

    一、 可行性分析 
    通常项目都是经过外部招标形式得到。对于有些企业在应标时候对项目就要有个取舍。假如在特殊时期为了生存可能只要不是太赔项目都会尽可能承接。 
    不过通常项目在承接前最好在经济、 技术等方面进行可行性分析, 而且这种可行性分析最好是管理者、 市场、 技术等人员都参与, 因为市场人员通常不懂（或不通）技术, 技术不懂（或不通）市场, 所以只有大家在一起共同分析讨论才能够得出比较可行结果。可行性分析结果首先能够作为是否承接项目依据, 其次也能够作为承接项目方法或与用户谈判依据。比如经分析项目工作量很大, 假如按标书金额开发有可能会赔, 那么能够与用户探讨是否未来能有个二期项目; 另外假如用户要求时间比较紧, 可是经分析极难按标书时间完成, 那么也能够和用户同共探讨是否能够在正式签定协议时延长系统交付时间等。当然这些与用户探讨工作通常是需要企业高层领导出面协调, 有时单独靠项目组是没有能力达成理想结果。 
    另外在此阶段最好对项目成本和需要资源进行一下估算。 

    二、 需求 
    需求实际要细分为需求调研、 需求分析、 需求确定、 需求管理等。 
    因为对于需求要想说清楚可能需要较长篇幅, 所以在此不进行展开。 
在此只是先强调一下需要相当关键, 假如早期需求做不够仔细会给项目后期工作带来很多隐患。 
而且我提议每个项目不管多大也不管项目时间要求多紧急一定要有一个比较具体需求文档。 
在需求比较确定以后提议再对项目成本进行估算。同时对需要资源及相关里程碑进行说明。 

    三、 设计 
    对于大部分中小型项目因为时间和人力问题加上需求变更比较频繁, 所以有时极难书写一个比较具体设计文档。不过假如没有设计文档一是为后期维护可能会带来部分问题, 尤其是当原来开发人员或主力开发人员离职或调离到其她项目组时; 另外没有经过具体设计项目可能也会存在部分风险。 
    所以提议无须为了文档而文档, 除了项目验收要求外, 提议设计文档依据项目特点有选择地包含以下部分内容说明:  
    系统网络情况。 
    系统安全策略及备份策略。 
    系统相关软硬件环境说明。 
    与其她系统关系。 
    关键库表及关键字段说明。 
    系统中关键数据关联关系说明。 
    关键字段校验规则。 
    项目中技术论证及名种技术结合方法。 
    系统关键技术说明。 
    部分技术使用过程中注意点。 
    异常处理机制。 
    事物处理机制。 
    日志统计方法及标准。 
    框架中相关命名说明。 
    共通功效描述及调用方法。 
    关键算法。 
    系统性能处理方案。 
    并发考虑及处理。 
    系统用户及角色权限设计说明。 
    系统关键配置说明（如数据库服务器, 应用服务器等等, 如有必需可另加附件进行说明）。 
    个人认为对于中小型项目假如不是用户要求有时无须在设计文档中对全部数据库表及字段都进行说明, 能够只说明比较关键部分数据库表及字段以及相关数据库关联关系就可。因为在用数据库建模软件（如Powerdesigner）进行数据库设计时候能够对每个表及每个字段加注释进行说明, 在使用开发工具（如: pl/sql）进行开发时候自然能够看到每个数据库表或字段说明。而且通常中小型项目在开发过程中可能需要常常性地修改数据库表设计, 假如还有文档描述数据库设计那么每次修改时除了修改数据库之外还要维护设计文档一致性, 假如项目忙忘记了修改就会造成文档和数据库不一致, 有时这种不一致文档可能还不如没有, 因为它可能会误导其她人员了解。 
    另外也能够经过开发过程规范来降低设计文档内容。这个将在下面开发步骤进行具体说明。 

    四、 开发 
    整个项目有一个合理框架是很关键。框架具体包含哪些内容在此极难解释清楚, 不过我想最起码整个框架应该把项目所采取多种技术（如java中Hibernate、 Struts、 Spring结合）比较合理地组织起来, 并为具体模块开发提供部分工具类等, 同时整个框架应该含有很好可扩展性、 可维护性和很好性能。框架最好由项目组中技术最强人（在此称她为技术责任人）进行搭建及维护。 
    另外对于整个项目有一个统一命名规范（类和方法按什么方法命名, 全部文档都加上时间作者等）并进行遵守是很必需, 这么一个人开发代码其她人很轻易就能够读懂。 
    在整个项目进行全方面开发前最好先向项目组全体组员讲解需求及项目框架机制、 使用方法及注意事项, 再说明相关规范。然后每一个开发人员根据了解开发一个简单功效。然后大家再一起（或者由技术责任人）看一下每个人对于框架使用是否合理, 规范了解是否有误, 编码习惯是否需要更正等等。在讨论并达成共识后再进行具体功效开发。 
    另在具体开发过程中尽可能在关键算法处加部分注释进行说明。 
    提议定时进行部分代码走查工作。尽可能由技术责任人负责这份工作, 当然也能够进行相互检验等。代码走查好处很多, 如可发觉部分不好编码习惯; 提升整个系统代码可读性; 发觉部分bug; 借鉴他人好编码思绪或技术等。 

    五、 测试 
    有些企业有独立测试或质量确保部门, 有企业只是由开发人员自己完成测试工作。在此假设企业有一个独立测试部门进行系统测试工作。 
    首先开发人员一定要养成单元测试习惯。对自己开发模块功效进行单元测试过以后再提交测试组进行结合测试、 系统测试甚至性能测试。单元测试很关键, 在进行单元测试时候假如条件许可能够使用junit等部分工具, 或其她部分代码覆盖率工具帮助分析测试用例覆盖程度。另外在此再提一点, 通常项目可能是整体开发完以后才进行性能测试, 可是这时测试出性能问题了却因为临近上线或试运行时期, 不一定有充足时间进行修改, 另外也可能因为整个项目已经都使用了某种影响性能技术或方法, 要想改变要付出很大代价。所以提议假如条件许可能够在开发过程中（甚至搭建项目框架时）使用部分轻量级开源性能测试工具由开发人员对可能影响性能功效进行测试。 
    对于测试部门测试人员要尽早地参与到项目中来, 提议在需求阶段就介入。早介入好处一是能够对需求了解比较深入, 知道原始需求是怎么来, 中间经过哪些改变, 这么会比在开发结束后一次性地讲解能够愈加好地把握需求, 愈加好地书写测试用例及测试计划。另外有些人也比较推荐在需求时候就开始书写测试计划和测试用例, 因为我之前项目特点我没有这么试过。 
    项目组设计人员一定要把部分关键测试点、 数据及功效关联关系对测试人员说清楚。 
测试过程中有一个bug管理系统并对bug进行跟踪是很必需, 在此就不展开说明了。 
另外在补充一点, 最好是在项目结束后能对产生全部bug进行一下分类。然后经过分析得出部分规律。经过在以后项目中采取部分方法进行项目质量提升。 

    六、 实施 
    对于包含多个子系统长久开发项目, 在系统设计和开发过程中要优化处理关联性强系统, 同时有一个（或多个）系统成熟了就试运行或上线, 无须等全部系统都好了再上线。一是因为时间长了开发人员可能调离至其它岗位, 维护代价会增大; 二是子系统用户可能会改变而造成需求变更; 三是时间长了用户对系统需求会有陌生感, 也可能会产生新需求; 四是时间长会给打消用户对使用系统主动性; 五是较早地让用户看到系统也能够减轻因双方了解偏差而造成系统需求变更影响。 

    七、 维护 
    争取把用户提过全部修改都进行统计, 并争取全部修改都请用户签字（不一定提一个修改就签字一次, 能够统一统计然后定时把一段时间内修改善行签字确定）, 假如做不到全部修改都签字也尽可能做到对于重大修改请用户签字。签字好处很多: 让用户看到项目组所做工作; 假如修改内容比较多能够经过双方高层领导沟通再新进行系统二期或三期开发; 有了签字有时用户对需求变更会相对少部分等等。 
    另外对于全部修改除了签字留档外争取定时把全部修改内容再整理到需求文档中, 保持需求文档与正式环境功效一致性。这个工作很有必需, 可能带来以下部分好处: 方便测试人员在回归测试时了解系统功效; 假如维护人员调离其她接手人员比较方便了解系统功效等。 

    八、 总结 
    在此不对项目验收进行单独说明。只是说一下项目结束（有些项目可能要连续进行维护, 在此关键指系统已经上线并稳定运行）后要进行总结工作。 
提议每个项目结束后都召开一个项目总结会。项目总结会提议与项目相关全部些人都参与。由项目经理进行关键总结, 但每个参与人员最好也都进行总结。能够从管理和技术两大方面对项目中每个阶段成功与失败进行总结, 目是总结经验教训, 提升每个人项目经验, 提升项目组成熟度, 使以后项目愈加成功。在此要强调一下, 通常项目总结时大家都喜爱只说成功, 而极少提到失败或所走部分弯路, 而往往对这些失败总结更能使大家收获更多, 当然这也要看组织文化, 我提议假如可能尽可能激励大家多总结部分失败经验教训。 
    另外项目结束后假如有时间最好是把项目中部分有重用价值文档放到企业组织过程资产库中。 
    假如项目框架比较合理也能够剔除项目中业务相关功效代码, 整理出项目框架并加以简明说明文档供本项目组其她项目或其她项目组使用。 

    九、 项目经理职责分析 
    对于中小型规模项目, 项目经理可能既要充当管理人员角色又要充当开发甚至实施人员角色, 基础上软件项目生命期每个阶段都要参与。 
    不过我认为以下部分工作（其实远不只下面所列）项目经理一定要重视:  
    项目整体需求把握。 
    项目框架把握。 
    项目团体建设。 
    与其她职能部门协调工作。 
    项目例会。 
    用户关系维护。 
    定时向项目相关人员汇报进度。 
    总而言之项目经理要对项目成败负责, 要对项目组员发展负责, 要对用户负责, 还要对企业负责, 所以项目经理一定要有责任心、 要有全局观。 

    最终是相关本文几点说明:  
    本文关键从宏观上对软件项目生命期每个阶段可能碰到问题及相关处理想法进行探讨。所以本文写有点杂, 而且对很多内容只是点到, 并未展开, 假如可行可能在后续文章中单独对一些阶段（如: 需求、 开发）或一些工作（项目团体建设、 技术交流、 职员职业生涯计划等）再进行展开叙述。 
    本文关键针对中小型企业项目生命期管理想法。我相信对于很多大企业管理方法远比我所提到正规得多。 
    因本人写作水平有限, 写比较粗糙, 也期望大家共同探讨, 多提宝贵意见。