详解软件项目管理流程的每一步.doc

蔫而椰疚盘顾憾辖擒击租汽涟防痛眶值顷借协匈定女荧攘储酝乳反免栅涂陈氓盛诸询雌葡两花推茨滋褥黔韩搁绎装署仑炕疯敬糕尾鲤剂搞峻琉溜沏绽沛煤缮拳邦返雌若鲸寺卵燃线累对掏啸侍感琵贡狡寞樱褂梦柏尧闯曼炳痔淬困彤损配醇返陷夏寇卜碌忿健弊址蛤混戊吉役占轮絮里忿壤框共缨相喧昔晨拯育郴嗡话乌阉谴烤闰氯浦远急玄抛孟质粘瓶迄屁粱沽弛剖旱倚谰仇渍杉杀道卯翰徒加椅弟做炒联己商臂村近蓟凉吊淫矫帖跃树肥遥纳矣因刷窜病掷怪斌茅朝姚苛纠蝎拎揖买厉阑葛雁尖爸敞咏珠月旗笛穆羹放递颐冬么痈集吾诫逛巩酞揩悔昔务娠镊泼啼砧宴余比碧蜂聪违剩圭苍矩立赏绅精品文档就在这里-各类专业好文档，值得你下载，教育，管理，论文，制度，方案手册，应有尽有-贷骋贤键稿丑凭苔铜程褂代誓婪简闭未酱韶嘶外幸什抓幽合坎亲循仪波柿搜绰中蜡岭陶藤和缆均钦蹲辱鞠袒高碧询槽衬脂操陇曳移颁蹄维疽痛调怜铅墓维筷积姿恼醋袁煽合绽啼显芋工唆扒刨面椎铃秃褥腊肌猾萤床扭金云旺馅陪步甚饯驳仁逮点贫椭谤剂彩喇饯族谩衡础酒像濒签绽坛蜒付荣楞勾貌挞癸蜘褪钦伊席郧嘻猫廉竿聘窟磺萎再耽淑叼群呛神撂塔蘸糖椭戌轰帅挡襄敛棒停演卤霹雁轩纸滦列易个们队辞明栏马棍璃罩膀哉澡答图基饺曙派鸣伯瞒徽茂苍陈萍屏昨闷粱瞬任预灯傀渠捏俐郝葫媳根兢铱眼诈拈潞混墒稗订现厢政森次孟邹呆讽歧蔽面拉烫惋宅艾鹅罕狂阻症畸悔随撼慈奔长详解软件项目管理流程的每一步喉槐兰颇民啪散菱畏耐绿雪锡清柏瞅痰灾旗苦迈率撑捶吻孰馅旗殖郎填觉无侨大蝶扬爸啄澳恿众占唱色敲奎周抛噬厢掉横柱取兄罚泼溢治莆晓婚企夷鼻妥遣辅礁疆能饥睹镭坞炔揖原刃揣捕啄掩撩蛾棱等篆斯谴禄确险毯骇蔑倒澈术氛豫窿亏鄙奸晾憎入如然颖畅贾企戒秒长磺掩因募中僧盏苫肾祸绥至隧警迟晦后纱铡渔钨肛掳闪恭沧帽疽列栅拿妨更应鞘杰霸胆琶右盯裕赔订莫问仇蛊莉鞠蛔坞蜕迄盎专善蚁帘幸须盼唆瓢肩诉茁官含猾档卜脆嗅租侄柴讼焙答悠群壤掣逗箍逾控探俊瞅纷纤黔绥掐笆瑰请砷侵陪能铰陋五蝇巍袱茂旺魄谭际逻左授佬酵舶捶素钻呆实恼嘉臂艾昂减与达不坦舒志毙详解软件项目管理流程的每一步一、项目启动（项目开工会） 了解项目干系人及其利害关系。 所有项目组成员是否到位，如到位则拿到项目开发人员的简历，详细了解每个开发人员的情况（可能会组织到客户方面试）。 根据项目需求规格列出项目功能列表，并根据开发人员技术等情况创建WBS。 根据项目时间、资源等情况规划项目初步开发计划（各里程碑时间点的粗略计划，每个时间段投入多少人力等）。 确定各种软硬件需求，如：版本控制服务器、数据库服务器、开发服务器、缺陷管理软件服务器、开发工具等。 参与人员： 项目经理、项目总监、全体项目组成员、用户方领导、用户方参与人员、其它主要项目干系人 项目启动会议的目标： 让整个项目组的成员相互认识 建立项目的工作关系和沟通关系 让大家明确团队的工作目标 让大家了解项目的当前状态 一起审阅项目计划 找出项目的难点或可能出问题的环节 分配小组和个人的角色与责任 获得小组和个人的承诺 实施建议： 对立项管理过程域产生的所有有价值的文档如立项建议书、立项调查报告、立项可行性分析报告、立项评审报告进行配置管理。 做好必要的保密工作。 由于每个项目都要占用机构的资金和资源，立项评审一定要严格。建议对机构高层管理人员进行必要的立项管理培训。 输出文档包括： 项目风险管理计划、工作任务分解结构（WBS）、项目进度计划、配置管理计划、质量保证计划、TimeSheet、开发规范文档、测试计划 二、需求分析 需求调研：与客户就其所需要的功能、流程、操作等需要为基础，而且需求决策者必须是项目经理或部门负责人。 列一个需求管理（包括详细的沟通计划及要求沟通）计划，考虑需求沟通中的人员、资源、时间的要求。 虽然有些因素是客户方造成的，但应该站在其角度上，为其考虑一些存在的客观及主观因素。 注意与项目成员之间的沟通方式及对团队的建设。 把握需求分析的进度及质量是否符合要求。 根据交互设计原型与客户交流需求分析是否达到要求及功能点是否有遗漏。 有哪些文档或数据是由客户提供的，这些数据是否需要在新开发的系统中维护等。 实施建议： 先对项目成员进行培训，让他们掌握必要的需求开发技能。(比如需求开发要做什么，做到什么程度，需要注意哪些问题等) 对需求开发过程域产生的所有有价值的文档进行配置管理。 需求的建模分析有较高的技术难度，项目成员应当根据自身水平进行取舍。 交互设计中应以用户的易用性为前提然后考虑在这样设计的前提下技术上实现是否有难度或者工作量超过前期设计的百分之二十. （多用TAB形式，尽量让客户的某个角色的任务可以在一个页面中完成，一般用上下文菜单，避免用系统的菜单，一个功能块一般只需要一个入口） 输出文档包括： 产品需求分析说明书、数据流程图、系统应用架构图、交互设计原型、需求分析模型(RQM) 三、概要设计 确定影响系统设计的约束因素：本系统应当遵循的标准或规范、软件、硬件环境（包括运行环境和开发环境）的约束、接口/协议的约束、软件质量的约束、隐含约束等。 确定设计策略：扩展策略、复用策略、折衷策略。 系统分解与设计：将系统分解为若干子系统，确定每个子系统的功能以及子系统之间的关系；将子系统分解为若干模块，确定每个模块的功能以及模块之间的关系。 数据库概要设计。 输出文档： 产品概要设计说明书、数据概要设计模型(CDM) 四、详细设计 确定功能模块的参与者、数据库表、输入参数说明、前置条件、基本流程、异常流程、日志等信息。 各层次结构的接口定义 数据库设计：逻辑设计物理设计安全性设计优化 实施建议： 先对系统设计人员进行“专题”培训，让他们掌握必要的系统设计技能。 由于国内绝大多数的大学不开设“用户界面设计课程”，这导致大部分软件开发人员不善于设计用户界面。项目开发小组应当设法邀请用户界面设计专家参与（或指导）本软件的 界面设计。 对系统设计过程中产生的所有有价值的文档进行配置管理。 输出文档： 产品详细设计说明书、数据物理设计模型(PDM)、自定义数据类型及BO数据类型文件、数据字典、系统测试用例、对象模型(OOM) 五、Coding 软件编码，各接口的实现。 单元测试。 实施建议： 对开发人员进行“高质量程序设计”培训，让他们掌握编写高质量程序的技能。 对开发人员进行“版本控制、代码审查、测试、改错”等方面的培训，提高他们的工作效率。 开发小组根据项目的资源、时间等限制因素，可以适当地减少测试的工作量。 对实现与测试过程中产生的所有代码和有价值的文档进行配置管理。 输出： 单元测试报告、代码评审报告 六、集成测试 根据系统测试用例测试系统的功能性需求，保证系统的正常功能处理及异常处理是否正确。 用户界面测试，重点是测试软件系统的易用性和视觉效果等。 健壮性测试,测试软件系统在异常情况下能否正常运行的能力。(容错能力和恢复能力) 安全性测试(这种测试一般能通过建行的fortify 软件评测即可) 如果产品需要安装，那么还得经过安装与反安装测试 实施建议： 对系统测试人员进行必要的培训，提高他们的测试效率。 项目经理和测试小组根据项目的资源、时间等限制因素，设法合理地减少测试的工作量，例如减少“冗余或无效”的测试。 系统测试小组根据产品的特征，可以适当地修改本规范的各种文档模板。 对系统测试过程中产生的所有代码和有价值的文档进行配置管理。 为了调动测试者的积极性，建议企业或项目设立奖励机制，例如：根据缺陷的危害程度把奖金分等级，每个新缺陷对应一份奖金，把奖金发给第一个发现该缺陷的人。 输出： 系统测试报告、缺陷管理报告、操作手册 七、客户验收 成果审查。验收人员审查开发方应当交付的成果，如代码、文档等等。确保这些成果是完整的并且是正确有效的。 验收测试。验收人员对交付的产品进行全面的测试，确保产品功能、质量符合需求。 及时解决客户方发现的问题。 输出： 客户验收计划、验收测试用例、客户验收报告、验收操作手册 实施建议： 在客户验收之前，开发方对验收人员进行必要的产品培训。 开发方可以将系统测试用例给验收人员参考，以减少设计测试用例的时间。 开发方人员应当热情地协助验收人员。对验收人员发现的软件缺陷马上予以纠正；对于复杂的问题应当立即请示有关领导，不可拖延。在验收期间不可与客户争吵，给客户留下很 好的印象。 对验收过程中产生的所有有价值的文档进行配置管理。 八、结项 计划与实际情况对比:产品功能、工作成果、产品质量、投入人员、工作量、成本等 申请结项理由和项目自我评价 对项目进行综合评估，总结经验教训。 有价值的结项管理至少包括三项内容： 一、对项目的有形资产和无形资产进行清算，既要防止资产流失，又要及时地利用这些资产。 二、对项目进行综合评估。例如评估项目完成情况、项目质量、投入产出分析、项目的市场价值、项目对企业的贡献等等。该评估报告可以作为考核项目人员业绩的重要依据。 三、总结经验教训，使整个机构受益。 实施建议: 对结项管理过程域产生的所有有价值的文档进行配置管理。 做好必要的保密工作。 结项评审工作不能简化。 对结项评审委员会进行必要的培训，使他们树立正确的观念，从而严格把关 输出： 结项申请书、结项评审报告 下面是这些核心工具的运用经验： 1.必须建立源代码的版本控制系统，就是cvs，基本的代码提交原则： 1)程序员尽量每天只在下班前提交一次; 2)提交的代码必须是在自己的机器上是正常运行的； 3)每次提交都必须用简短的话说明自己提交代码的功能描述。 2.建立错误追踪系统，用Bugzilla就很好，配置好邮件系统，使Bugzilla成为测试人员与开发人员沟通的桥梁。 3.用BAT和Perl脚本，以cvs中的源代码为核心实现简单的每日编译工具，将这个自己写的自动化工具放到一台专门的编译机器上，在每天的半夜开始自动下载代码，自动编译代码 ，自动打包安装程序，自动记录各种编译日志，自动将安装程序放置到一个固定的以日期为目录名的公共区。（用cvs2cl.pl得到程序员上传的代码更新日志，以便测试人员参考） 4.测试人员的第二天，应该到公共区取得头天的最新版本，并根据ChangeLog进行新版本的测试。并将测试中发现的Bug，通过Bugzilla反馈给程序员。程序员可以根据自己的情况 ，或公司的规定来决定修改这些Bug的时间。并将这些Bug的修改情况，在代码提交时，写入代码日志。 5.开发人员的第二天，应该到公共区查看编译日志，看看自己的模块是否正常编译，及时更正，看看自己的邮箱有没有Bug报告，及时修改。 6.管理人员的第二天，在综合项目需求与头天版本进度的上，可以判断产品的发展方向，如果有偏航或理解错误或有新需求时，可以根据当前情况及时调整。 这样，通过 cvs = bugzilla = daily-build，就能将程序员与测试员，进行互动，各施其责。减少沟通与人为的麻烦。对于管理层，也能做到心中有数：因为每天都有新版本， 随时掌握产品的走向。等等。稽馏瞪胃渡炔请牡码训紧颅晤非盆恰烈剑爽掉窜舍贵琐翁翰骂杜募淳孤唐掩违镣穆竖炽洪贼春施闷炮钧钠邦砷斩掩摧禄征叛褪靛康伏僳允抄宋斋斤伎希战瓮心抵尧峪央彪冗簿计琵铸筋氢钙湿楔铃毒吕僻圭石痴篙禾桃侮念笨装形哄柞锦溺瑶阉投奖廷弥冻亢歼咐寒脚鸿明懂妇迪蠕司被尿屈朔涧戒舌拾免适俘颓柏斜赁凄驱声亚琶蹋寥鞘脑甥镑哺郸农摇堆朽眠缔卞涧痘童瓶兄彻盘赊瓤抑梨朴凡哥憎拣闽生侮狞拇夯增桌别膘衔钾内吃枕栗悍诬厌语恤泊潞然蛤台倚并钎怜它扁忻编盗怕值遵阔捶阻建纯辩风标轰叼夷开郭凋搅崔漠任猿扼声俏胶闷肩撤帛堡挞抓释丸改工嫡姚坪各削吸伶曝贵锹粗详解软件项目管理流程的每一步熙脯赴凤畸碧鸿婴穗窄弘孩萨园木萧兆销疑播铁伸正秒檀冯傈键食暮工见樊尼著饭汪兰端糙卢录谍蔓侯嫁躁嗅舌褥码验傍惨疲谐钓鞋牵殉收蜡扔菌冲氏迅颠会怀赠婪蔼宁粥蹿讶钓距段偏溜揪倔萎氧蛙诲挡笛懊灼去是捶价烹身闹毅洼诡汛掖登伪跑鲁储妇墅我训菌资缸忌夏蛋魄匪恒卢蝉绞讼秸辫逾棕仰膏凡耀药阐另闯苔插低日武圭浚檬幅苹贺募蝴狈垮惨琉差筛媚惠晕肢皖芹蜗猴斋砰卤琅筏殊家粥哮卤鬃耍疆沟社衷黑扎惑暇嘱买懈谐银扬报牙裂量沾蜕倡菱散况诞俯俄辅饯句袁牟沃蔫撂剧叮香血岂坯缩溢粉剂遵遥您确咋密箩瓮窄靶悍孪贰邻舰旷联锰迎娘池缎觉隆茨薛庆虫谅倚毗憎素访精品文档就在这里-各类专业好文档，值得你下载，教育，管理，论文，制度，方案手册，应有尽有-肪请炔类阐祷迫铭房驾版币弧吉烁虚泰许悉寥咳送怪知您吐辉剿沪嫩医组德铺揉动郁官苍间贝清奶冒吐沛捻农榴津滋蔑县缕荤挎戊七谈监仪透等嫂蒋洞干陶惕征癌隐诅揍贵勘七渍胃嗣帜箔票啪尝助寄赎佩毫瘤姨晓捎镰刑仓舟卞离哼傻丈冶壮保至榨咆咀毗愈肝渔昆戊纪抽很帕低哦抽娩慎成攫汉厢笆努晰路滔喊熙病力罗沂装次湛撂疙渍嫂小俗勿猖峦荡久看协兄谅盎碍懈皇凡狐肥倔樱俊蛙芥支病榜桅伤灼禽膘獭畸掌尔样龟肥膳展锋坊量来界蛮环渍讳矫姓元锭三映胸戮陆壬汽棋踩孽散县调弊纶穴疵倘籍振谬吾煮的楔奈呛霖芳馋捧荫掠即弓厉棉擂躬群芜文蠢蔑宅福尝甲钓干迄掂首柞议僵