2022年软件开发中的项目管理分析研究.docx

《2022年软件开发中的项目管理分析研究.docx》由会员分享，可在线阅读，更多相关《2022年软件开发中的项目管理分析研究.docx（7页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、精选学习资料 - - - - - - - - - 软件开发中的工程治理争论引言：软件行业从20世纪 60岁月开头操作系统的研发,到20世纪 90岁月中期行业快速进展；从原有的作坊式开发到目前团队协作完成,从早期的技术力气竞争到现有的工程成本掌握竞争,从面对结构到面对对象再 到面对服务架构,工程治理被提到肯定的高度,如何有效的经营工程来降低风险、掌握成本,确保工程进度流畅,在有效的时间内保质、保量的完成验收；成为不少工程治理人士的追求目标；结合个人工程治理实践,本人有几点治理留意事项与大家一起共享；工程治理留意事项 开发模型确定一个工程的好坏,开发模型优良是工程胜利重要保证,有了好的开发模型我们

2、可以很好的掌握工程进度、降低风险；所以我们在工程开头前第一需要确定工程的开发模型；这里我们建议采纳迭代式的开发模型；我 们知道原有早期传统的开发模型是一个文档驱动的流程,它将整个软件开发过程划分为次序相接的几个阶段,每个阶段都必需完成全部规定的任务后才能够进入下一个阶段；工程开头第一完成系统需求规格说明书,之后才能够进入概要设计阶段,编码就在系统设计完成之后进行；这就意味着只有当全部的系统模块全部开发完成之后,我们才进行系统集成,对于一个由许多个模块组的复杂系统来说,这是一个特别艰难而漫长的 工作,且存在着潜在的风险；如：需求或者设计中的错误无法在工程早期发觉,只有在系统交付客户之后才能发觉原

3、先对于需求的懂得 是错误的,系统设计的错误也只有在测试阶段才能被发觉；对于工程风险的掌握才能较弱,往往工程风险只能随着工程终止才能逐步降低,同时也只有经过系统测试 之后,才能确定设计是否能够真正满意系统需求；软件工程经常延期完成或开发费用超出预算工程开发进度往往会被意外发生的问题所打乱,需要进行返工 或其他一些额外的开发周期,造成工程延期或费用超支；工程治理人员专心于文档的完成和审核来估量工程的进展情形所以工程经理对于工程状态的估量往往是不精确的,当他回答系统已完成了80%的开发任务时,剩下20%的开发任务实际上消耗的是整个工程80%的开发资源；在传统的瀑布模型中,早期是无法发觉,需求和设计中

4、的问题,只有当系统第一次集成后,这些设计缺陷 才会在测试中暴露出来,需求缺陷就需要等到系统与用户见面后,方可暴露；从而导致一系列的返工：重新 设计、编码、测试,进而导致工程的延期和开发成本的上升；为明白决传统软件开发流程中的问题,我们建议采纳迭代化的开发方法来取代瀑布模型；在瀑布模型中,我们要完成的是整个软件系统开发这个大目标；在迭代化的方法中,我们将整个工程的开发目标划分成为一 些更易于完成和达到的阶段性小目标,这些小目标都有一个明确的阶段性评估标准；迭代就是为了完成肯定的阶段性目标而所从事的一系列开发活动,在每个迭代开头前都要依据工程当前的状态和所要达到的阶段性名师归纳总结 1 / 4 第

5、 1 页,共 4 页- - - - - - -精选学习资料 - - - - - - - - - 目标制定迭代方案,整个迭代过程包含了需求调研、软件设计、软件实现、版本集成、软件测试、软件发布 和产品交付等各种类型的开发活动,迭代完成之后需要对迭代完成的结果进行评估,并以此为依据来制定下 一次迭代的目标；开发方案制定确定好工程的开发模型,一整套配套可行的工程开发方案是开发过程中进度掌握的标准,同样是用户、公 司治理层明白工程进展的依据；通常工程治理人员、需求人员和用户依据用户原始需求 可以是工程方案书 或者是建议书）,一起定义整个工程过程中的工程迭代过程个数以及每个迭代过程的开发目标和范畴；如何

6、进行迭代过程的划分和范畴有效定义呢？是我们迭代开发方案制定的首要任务,我们这里举荐两种划 分原就；一、用户需求至上原就,也就是依据用户需求的优先级,进行逐个模块击破,每一个迭代是用户需求一个的 模块,当然模块小时或者人员充分时,也是在一个迭代中完成两个或者三个模块；二、当用户需求没有鲜明优先级时,我们可以采纳功能逐步求精开发法,类似于我们早期采纳快速原型开发,划分多个迭代,确定每个迭代需要达到的功能的完善层次,例如,第一第一个迭代仅完成系统的原型开发,其次迭代就紧接着完成各业务基本功能,然后逐步完善直至满意用户需求；无论怎样划分我们的迭代过程,总之需要把握一个原就,框架尽早规划,版本快速集成；

7、工程只要进入软 件实现过程早期 ,建议实现周版本的概念,确保一周一个版本,一来便利工程治理人员明白工程进度、质量,从而依据前期工程完成情形和近期的用户需求变动准时调整方案；二来可以尽早将系统与用户见面,准时 发觉对于用户需求懂得不正确之处,同时仍可以激发用户潜在需求,细化需求；在软件实现过程后期,就可 以依据需要调整集成版本频率；所以,虽然每个迭代开发过程中的开发活动是可以挑选性的裁减,但通常软 件实现、版本集成和软件测试是每个迭代不行缺少的活动,否就迭代过程将失去它的含义；迭代过程个数和范畴确定后,就需要与每个迭代过程中的开发活动相关者协商争论进度支配,先明确各开 发活动的起始、截至时间,然

8、后在依据开发活动的详细需求进行任务细化；假如期望能将工程进度掌握在计 划之中,任务越细越好,每个任务跨度不要太大,一天一个任务最好；当然这种情形是很能实现的；的确,我这里说的是一种比较抱负的情形,但并不是不行能；在这里我们就可以明白到迭代开发方案给我们带来的 好处；工程开头了需求通常都是很泛,不太明确；与用户沟通,可能他认为自己已经表达了全部需要；实际或许他的确已经充分描述了他所知道的需求业务需求）,但完善我们的系统,除了基本业务需求外仍有很多非功能性需求,比如：系统性能需求、界面显示需求、系统操作流程需求等等,特别是目前 B/S架构的开发模式,界面需求已经越显示出它的重要性；而这些需求在工程

9、早期,在没有任何可见事务的情形下,用户很难意识到它的重要性；我们只有逐个迭代的细化,每一个迭代过程完成既是需求进一步细化的依据又是一早期,在没有任何可见事务的情形下,用户很难意识到它的重要性；我们只有逐个迭代的细化,每一个迭代过程完成既是需求进一步细化的依据又是一个新系统的开头,每个迭代开头前都要依据上个迭代的成果和所要达到的阶段性目标细化定制；组内成员配置工程启动之前除工程治理者着手方案制定外,同时也需要对其工程组那成员配置进行规划,界定其职责；名师归纳总结 2 / 4 第 2 页,共 4 页- - - - - - -精选学习资料 - - - - - - - - - 通常我们需要几种角色：技

10、术组长：负责技术难题攻关,组间沟通和谐；需求人员：负责将用户需求转换成工程内的功能需求和非功能需求,编制工程需求规格说明书,针对每个迭 代集成版本与用户沟通猎取需求的细化；设计人员：负责对需求规格说明书,进行系统设计；开发人员：实现设计,完成用户功能；集成人员：负责整套系统的编译集成,督促小组系统功能提交,准时发觉各模块集成问题,起到各小组之间 的沟通的纽带；测试人员：对于集成人员集成的版本进行测试,尽可能的发觉程序缺陷,以及未满意需求的设计；文档整理人员：负责对小组内产生文档的整合,统一；系统环境人员：负责系统编译环境、运行环境规划；编制系统环境说明书；保护人员：系统验收后,保护人员,建议保

11、护人员早期进入工程参加工程测试以便顺当承担起工程保护职责；工程组启动初期需求人员第一依据迭代方案第一个迭代方案进行需求调研编制功能需求规格说明书,通过 工程下到工序人员评审后进入软件设计、编码；留意,这里需求确认并不是指工程中的整体需求,仅仅是指 该迭代过程中表达的需求；整个过程类似如工程开发流程,这里只是细小流程,逐步完善,渐进提交；工程中沟通通常工程中口头沟通是最为常见的,包括工程组内部、外部沟通,这种沟通快捷、便利；一般的小问题或 者是简洁问题的懂得特别有效,但问题复杂或是此次沟通需要后续使用,那么该种沟通就存在问题,就需要 以书面方式加口头相结合最为有效；即可在本次沟通中便利、快捷的领

12、悟,也可以为后续工作供应依据；通常用户对于工程进度却是有要求,不仅需要提交周方案和总结,仍需要定期汇报工程的完成情形,对于 即将延时的里程碑,需要提前至少三天时间提出工程延时申请；那么从这里我们可以吸取,与用户的沟通间 隔除每周进行工程方案和总结外,对于用户认可的工程开发方案,需要在里程碑需要向用户汇报,对于即将 延时的开发进度,尽可能早的通知用户方的工程负责人知道,便利用户方的工程负责人有预备的与其领导沟 通,可以有效预防工作被动状态显现；工程组内部沟通不是越多越好,你会发觉当内部的沟通时间没有规律或是沟通时间过长,这样其实也会严 重影响工程成员的开发进度,但沟通又是必不行少,何种间隔最为相

13、宜了？这是不好定的,我们通常以评审 作为沟通的基础,平日的沟通建议工程组成员在每天工作过程遇到问题,将其记录下来,然后在以邮件方式 发送给需要沟通或者询问者；大家可以每天下班之前收取邮件,对于可以直接回答的问题就直接以邮件方式 回复,对于无法直接答复而只需与提出问题者争论的问题,就可以在其次天上班前进行商量确定；而需要众 人一起争论的问题,就放到每周会议上争论；特别紧急的话就可以立刻约齐人员争论,通常有良好的沟通方 式话,这种特别紧急的问题是不常见的；名师归纳总结 3 / 4 第 3 页,共 4 页- - - - - - -精选学习资料 - - - - - - - - - 名师归纳总结 4 / 4 第 4 页,共 4 页- - - - - - -