软件项目管理设计方案黄初航.docx
- 文档编号:29114829
- 上传时间:2023-07-20
- 格式:DOCX
- 页数:12
- 大小:61.51KB
软件项目管理设计方案黄初航.docx
《软件项目管理设计方案黄初航.docx》由会员分享,可在线阅读,更多相关《软件项目管理设计方案黄初航.docx(12页珍藏版)》请在冰豆网上搜索。
软件项目管理设计方案黄初航
论软件工程管理中的个性问题及其解决之道
班级:
09003501
学号:
0900350112
姓名:
黄初航
专业:
软件工程
指导老师:
王海舰
2018年5月31
目录
开头语3
一、软件工程管理的定义3
二、软件工程管理的意义4
三、个性问题及其解决之道5
3.1用案例引入话题——浪潮山东出入境业务管理系统工程5
3.2个性问题一——需求的不确定性7
3.2.1需求不确定性概述7
3.2.2需求不稳定性解决之道7
3.3个性问题二——成本估算<隐性成本高)8
3.3.1成本估算概述8
3.3.2成本估算难题解决之道9
3.4个性问题三——沟通问题10
3.4.1沟通问题概述10
3.4.2沟通问题解决之道10
四、总结11
五、参考文献11
六、致谢11
摘要
文章中我们讲述了软件工程管理的定义以及它的意义,并着重讲述了软件工程管理中的三个个性问题以及它们的解决之道。
三个个性问题包括:
成本估算问题<隐性成本高),需求不确定问题,还有沟通问题。
关键词:
软件工程管理个性问题成本估算需求沟通
开头语
这个学期上了软件工程管理这个课程,课堂上王老师精彩幽默地给我们讲授了有关工程管理的知识,其中很大部分是老师亲身经历过的工程,以及老师对这些工程的经验总结。
我觉得这样的课程让我学到了很多书本上学不到的知识,老师的经验总结更是对我们以后再软件工程管理方面起到指导和警示的作用,能够帮助我们少走弯路。
同时,在工程管理实验中,我们通过模拟工程实战,更加加深了对软件工程管理过程和意义的认识。
在工程实践中,我们也遇到了以前没有遇到过的问题,并尝试着运用所学的知识去寻找出解决问题的方法。
我们从书本上可以学习到软降工程管理的理论知识,比如对工程管理的认识,工程管理流程的认识等等,但是我们不能够学习到软件工程中会出现的所有各种问题,以及对这些问题的解决方法。
我们只能通过别人的经历,或者更多的自己的实践,总结,积累,使自己的经历成为我们的收获,才能为我们以后遇到的问题提供一个解决的思路。
这就是我写这篇文章——《论软件工程管理的个性问题及其解决之道》的原因。
我们打算通过下面这几点来叙写:
①软件工程管理的定义;②软件工程管理的意义;③个性问题及其解决之道;④总结。
由于本文的题目为软件工程管理的个性问题及其解决之道,所以我们将着重写第三小点。
下面就让我们开始吧!
一、软件工程管理的定义
对软件工程管理的理解,下面有一段比较简洁的定义:
软件工程管理是为了使软件工程能够按照预定的成本、进度、质量顺利完成,而对人员、产品、过程和工程进行分析和管理的活动。
从上面的定义我们可以认识到,软件工程管理的根本目的是为了让软件工程尤其是大型工程的整个软件<即从分析、设计、编码到测试,到维护全过程)都能在管理者的控制之下,以预定成本按期,按质的完成软件交付用户使用。
而研究软件工程管理为了从已有的成功或失败的案例中总结出能够指导今后开发的通用原则,方法,同时避免前人的失误。
在课堂的学习和资料的阅读中,我们理解到软件工程管理的内容主要包括如下几个方面:
人员的组织与管理,软件度量,软件工程计划,风险管理,软件质量保证,软件过程能力评估等。
这几个方面都是贯穿、交织于整个软件开发过程中的,其中人员的组织与管理把注意力集中在工程组人员的构成、优化;软件度量把关注用量化的方法评测软件开发中的费用、生产率、进度和产品质量等要素是否符合期望值,包括过程度量和产品度量两个方面;软件工程计划主要包括工作量、成本、开发时间的估计,并根据估计值制定和调整工程组的工作;风险管理预测未来可能出现的各种危害到软件产品质量的潜在因素并由此采取措施进行预防;质量保证是保证产品和服务充分满足消费者要求的质量而进行的有计划,有组织的活动;软件过程能力评估是对软件开发能力的高低进行衡量;软件配置管理针对开发过程中人员、工具的配置、使用提出管理策略。
从上面所讲述的软件工程管理的定义中,我们可以得出一个属于自己的对软件工程管理的认识:
用科学的方法管理和指引软件开发的进行,使之能再预期的时间成本内得出符合期望的软件产品。
有了对软件工程管理的认识,我们就可以更加深刻的认识到它在软件开发中的重要意义了。
下面我们要讲述的就是它的重要意义。
二、软件工程管理的意义
通过对软件工程管理的认识,我们知道,一个好的科学的软件工程管理能够使软件开发能够按照预期的计划进行,但是一个不规范的软件工程管理,可能会导致的就有下面的后果:
软件未能在既定的时间内完成、软件开发的之处大大超出预算等等。
这些后果在这里说的可能会有点轻描淡写的嫌疑,但是当把这样的后果放在一个大型的工程中时,它的损失将是巨大的。
它可以在如下的一些资料和数据中体现出来。
软件工程管理的提出是在20世纪70年代中期的美国,当时美国国防部专门研究了软件开发不能按时提交,预算超支和质量达不到用户要求的原因,结果发现70%的工程是因为管理不善引起的,而非技术原因。
于是软件开发者开始逐渐重视起软件开发中的各项管理。
到了20世纪90年代中期,软件研发工程管理不善的问题仍然存在。
据美国软件工程实施现状的调查,软件研发的情况仍然很难预测,大约只有10%的工程能够在预定的费用和进度下交付。
某年度据统计,美国共取消了810亿美元的商业软件工程,其中31%的工程未做完就被取消,53%的软件工程进度通常要延长50%的时间,只有9%的软件工程能够及时交付并且费用也控制在预算之内。
软件工程管理和其他的工程管理相比有相当的特殊性。
首先,软件是纯知识产品,其开发进度和质量很难估计和度量,生产效率也难以预测和保证。
其次,软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。
Windows这样的操作系统有1500万行以上的代码,同时有数千个程序员在进行开发,工程经理都有上百个。
这样庞大的系统如果没有很好的管理,其软件质量是难以想象的。
由上面所叙述的可以知道,软件工程管理的方法将直接影响到软件工程的成败。
软件工程管理作为一种管理手段,就是为了使软件工程能够按计划进行,并保质保量的完成而对成本,人员,进度,质量,风险等等进行分析和管理的一系列活动。
软件开发有不可预知的特点,所以它是极具挑战性和创造性的行业。
管理上没有成熟的经验可以供借鉴,而短剑工程管理对于软件企业,尤其是以应用开发与系统集成为主的软件行间企业,是行之有效的一个方法。
因此,决定一个软件工程的成功与否,软件工程管理是一个举足轻重的作用。
目前,软件工程管理已经是工人的软件开发企业的核心竞争力之一。
我们已经知道软件工程管理在软件开发工程中这么重要的一个角色,但是要做好它并不是那么容易的一件事情。
软件工程管理不同于其他管理,因为它要管理的是一个软件开发的工程,而软件开发又是一个不可预知的过程,给一个未知的过程制定一个成本,进度,人员,风险等等的估算,这是软件工程管理的难点问题所在。
在软件工程管理的过程中,随时可能会遇到一些未能预知的问题,怎样在遇到这些未知问题的时候去解决这些问题,这也是软件工程管理该做的事情。
下面我们将讨论的内容即为软件工程管理中的个性问题及其解决之道。
三、个性问题及其解决之道
3.1用案例引入话题——浪潮山东出入境业务管理系统工程
前面我们也说到了,软件开发是难以预知的过程,它是一个产品从无到有的创造过程。
这个结果是让人感到兴奋和有趣的,但是它的过程就没有那么轻松了。
软件开发的特点就是创造性!
我们要做的就是要实现我们期望的某种功能,而此前又没人做过的东西<除非是自己的案例学习,或者是盗版……在这里不是我们讨论的话题)。
软件工程的这个特点使得它具有了许多不确定性,这也使得软件工程管理不同于其它的各种管理。
也是产生软件工程管理中一些个性问题的一个原因。
在课堂上老师给我们的各种案例中,我最喜欢的就是浪潮软件山东出入境业务管理系统工程。
这个工程的大概情况我们可以回顾一下:
2005年7月,浪潮软件拿下了这个工程。
这个系统的旧版本也是浪潮软件做的,但是到这个时候原班人马大多离职,留下的书面材料也很少。
为了应对新工程,事业部东拼西凑了一个10人的工程组开始工作。
2个月后,工程组成员借口天天加班要求增加待遇,未果,工程迟迟没有进展。
8月份,公司将该工程转入行业应用事业部,由原本做烟草行业软件的一个团队接手。
这是一个年轻的队伍,但干劲很大,客户也重燃希望,对工程给予充分重视,派人进驻工程组,一则随时确认需求,二则督促工程进展。
由于采用了一种新技术,初期工程进展顺利,很快拿出核心系统的初步版本,但客户组织评审后发现距离实际要求差异很大,随后进入了无休无止的需求变更阶段,工程预算大大超标。
离系统预定上线时间越来越近,工程组几乎没有时间休息,加之客户方人员对工作指手画脚,双方矛盾日趋激化,尤其是年轻的工程经理虽然是个技术高手,但工程管理经验欠缺,年少气盛的他终于忍无可忍,和客户大吵一架。
客户马上找到公司领导,要求撤换工程经理。
几经协调,事件终于平息,但上线时间一拖再拖。
07年9月,系统终于上线了,但却发现运行速度奇慢,出入境办证大厅人满为患,前来办证的人怨声载道,投诉不断。
出入境的领导急了,找到浪潮领导说如果不尽快解决系统性能问题,他就派人把浪潮门口的路封了。
请允许我用大篇幅的文字来陈述这个案例,但是它是很有学习价值的,这也是我喜欢这个案例的原因。
因为这个案例几乎囊括了所有在软件工程管理中可能会出现的问题。
包括:
团队配置管理问题:
原班人马大多离职,留下的书面材料也很少;
人员沟通管理问题:
成员天天要求加薪未果,工程迟迟没进展;
需求管理问题:
软件系统进入了无休止的需求变更阶段;
成本管理问题:
工程预算大大超标;
风险管理问题:
工程经理和客户大吵一架,客户要求撤换工程经理;
进度管理问题:
系统上线时间一拖再拖;
质量管理问题:
系统运行速度极慢;
这些问题也许在工程进行前很多都预料不到会发生,但是工程一开展,各种问题就出现了。
而这些问题的出现并不是没有预防办法、解决办法。
课上我们讨论了,老师也给我们讲解了。
但是这里举出这个案例并不是要我们深入去研究它,因为我们不能通过研究这个案例就能学到应付所有软件工程管理中的问题的办法,因为其他案例很大可能出现与这里不一样的问题。
我们举这个例子的目的有:
1、说明软件开发的不确定性引发软件工程管理中会出现的各种个性问题。
2、说明软件工程管理主要包括哪几个内容。
3、引出软件工程管理中的个性问题以及他们的解决之道的话题。
上面的案例中出现的问题仅仅是软件工程管理中个性问题的一些实例体现。
本文将从以下几个比较重要的几点讲软件工程管理的个性问题以及相应的解决方法。
3.2个性问题一——需求的不确定性
3.2.1需求不确定性概述
软件的研制是一种人的智力创造,软件的产品是一种信息的产品,是无形的。
人的认识过程是不断深化的。
所以,在一般情况下,当客户在看到软件最终产品之前是无法判断其是否是所希望的软件产品,一旦他看到最终产品时才发现与自己的期望相差甚远。
它的原因可以归结为以下几点:
<1)用户的需求可以分为三个层次,即:
基本的需求、预期的需求和兴奋的需求,其中预期的需求是明示的,而基本的需求和兴奋的需求往往是非明示的。
所谓兴奋的需求是指这些特征在用户的期望范围之外,并且当其存在时将是非常令人满意的。
<2)即使是用户明示的需求,往往因应用领域与用户问题的多样性和复杂性,用户在表述需求时常常带有不确定性与模糊性的因素。
<3)随着开发进程的推进,用户对所建应用系统理解的不断深入,对原来模糊的或非明示的需求有了新的认识,随时会提出需求的变更,因此需求的变更具有不可预测性。
<4)用户要求的实效性和多变性,以及用户所描述的需求本身具有内在的矛盾及其潜在的冲突性,由于开发人员的领域知识的局限性,导致引发需求的误解。
<5)用户需求的获取过程与描述形式往往采用非形式化的自然语言,以及自然概念中存在的本质矛盾,使需求的规范描述发生困难。
<6)需求分析方法论和分析工具的缺乏,及其应用范围的局限性,也影响着需求的准确性和需求变更的可控制性。
因此,用户需求的不确定性是客观存在的,是不可避免的。
3.2.2需求不稳定性解决之道
解决需求不稳定性的传统方法有采用瀑布式开发模型,快速模型等。
瀑布模型为软件开发和维护提供了一种有效的管理框架,它在消除非结构化软件、降低软件的复杂度、促进软件的工程化方面起着显著的作用,以至于它广为流行。
但是,它并不能有效的解决软件需求不明确或者不正确的问题,缺少解决这些问题的灵活性。
用户常在软件开发完成后才发现所开发的系统不是他们所需要的,由此引发的工程返工和纠正花费高额带价。
快速模型是为了弥补瀑布模型的不足提出的,它针对需求获取的的初级阶段往往不够清晰的情况,将开发活动分成为建立模型和实现最终软件的两个阶段。
建立原型阶段作为实验开发,快速地建立一个待开发软件的原型系统,然后请用户对原型系统进行评价并对软件需求提出修改或确认,这种修改或确认可能会反复多次;实现最终软件阶段是根据最终确认的软件需求,设计和实现软件的最终系统。
显然,原型开发方法在克服瀑布模型缺点、减少由于需求获取的初始阶段软件需求不明确而给开发工作带来风险方面,具有显著效果。
但是,快速原型技术仅解决了初始阶段的需求获取问题,没有解决实现最终软件阶段的需求变更的问题,其原型的适应性和可信度存在一定的问题。
软件发开模型不能很好的解决需求不稳定性的问题。
但是我们可以辅以工程管理的方法来更好的解决它。
在没有建立软件过程管理的软件开发组织中,主要的管理手段是实施工程管理,工程管理的好坏是工程成功的关键。
工程的生命周期分为识别需求、提出解决方案、执行工程和结束工程四个阶段。
识别工程的需求和界定工程的范围是建立工程计划的关键。
工程计划实施过程中必须强调反馈和控制,跟踪工程的需求源,对工程需求的变化进行控制。
同时,工程经理一定要向客户强调一点,工程成功不是开发方努力就可以了,它必须要有客户的紧密合作,把需求的不确定因素纳人工程管理的全过程中。
针对浪潮软件出入境管理系统需求变更时期无休止的情况,课堂上老师也说了,解决这样的问题的方法还有,在工程实施前先跟客户进行足够的沟通,可以事先签署有关需求变更额度的合同,在工程进行的时候双方都遵守这个合同,这可以有效的解决需求变化大和混乱的问题。
我觉得这个也是一个可以帮助解决需求不确定性的方法,也适用于其它软件开发工程。
3.3个性问题二——成本估算<隐性成本高)
3.3.1成本估算概述
前面我们也有说道,软件开发是一个难以预知的过程,要给一个未知的,从未进行过的工程进行成本估算,这并不是一个简单的问题。
成本估算的困难很多有一个很重要的原因,那就是软件开发的隐性成本高。
所谓的隐性成本,是指在工程预算时并没有将其考虑在内,但它确实在将来的开发活动中会导致额外的成本开销。
一个软件工程的阶段性完成并不意味着它不会带来后续的成本,因为不同的实现<实现不具唯一性)所带来的软件稳定性和可维护性都将不同,而不良实现所带来的隐性成本往往在预算时无法合理地被考虑,这进一步又意味着什么呢?
第一,它将导致对工程进行计划更困难。
这是显然的,因为看不到隐性成本的存在,自然在计划时不会将其列入其中。
第二则更为严重,由于隐性成本的不可见性,往往很容易造成被忽视,进而不能掌握软件开发的特点,对软件开发中的困难也表现得不理解。
甚至一味地认为只要投入时间和人力就一定能开发出高质量的软件产品,孰不知很有可能因为更多的投入而造就更大的隐性成本。
隐性成本的存在往往很容易导致工程师因为工作而影响生活,而进一步带来更大的隐性成本。
试想,应该没有某个工程在预算时将工程师的生活质量真正地考虑在内,即使有,这种考虑或许也没有考虑到点子上。
3.3.2成本估算难题解决之道
解决成本估算难题,我们可以采用下面的三种方法,要想使软件开发成本估算问题得到良好的解决,它们都是必须考虑的,具体如下:
1、评估应细致,全面,可参考类似工程的成功案例。
2、适用专业水平高的评估人员进行质量评估。
3、沟通很重要。
为什么是这三个呢?
因为前面也说道了,软件的隐性成本高是导致成本估算难题的一个重要原因。
因为隐性成本是不可见的,但是它又是存在的,所以我们必须进行细致的评估。
一个表面上好的软件其设计未必就好,而设计不好则早晚会出问题,从而带来隐性成本。
所以,我们也很需要一个专业的质量评估。
这里所说的专业水平不能简单地理解为评估人具有什么样的学历,或通过了什么样的认证,而是需要他对软件行业有深刻的理解和丰富的经验,以及拥有自己的软件设计思想。
通常这类评估人也应当对于软件设计有着精神上的追求<否则他的水平也不会高到哪),很显然这种人是一种稀缺资源!
设计质量评估所需的专业性也正是因为实现不具唯一性这一特点所造成的,合格质量评估者的缺乏使得质量评估变得更加困难。
一个开发团队,如果不具备胜任的质量评估者,则很有可能整个团队在开发过程中不知道软件质量的真实状况,而只是停留在关注被发现的缺陷之上,进而无法涉及质量问题的核心——不良设计。
真正高水平软件工程师的缺乏也加剧了软件行业的困难,由于缺乏这些“领头羊”,工程组在开发过程中无法有目的地朝着高质量设计的方向前进,而只能是以完成工作为目标。
结果很有可能是工程组多走弯路,以及工程面临更高的隐性成本。
此外,沟通在成本估算中也是很重要的,前面也有说道,隐性成本的存在往往很容易导致工程师因为工作而影响生活,而进一步带来更大的隐性成本。
试想,有哪个工程在预算时将工程师的生活质量真正地考虑在内,即使有,这种考虑或许也没有考虑到点子上。
所以,我们需要团队内的多沟通才能帮助解决这个问题。
3.4个性问题三——沟通问题
3.4.1沟通问题概述
在前面讲到的一些内容中,我们也有提到过沟通问题的重要性,也许读者对它的印象还不够深刻,但是它又软件工程管理中的一个重要的个性问题,所以我们有必要把它也当做一个重点来写。
为什么这样说呢,因为软件开发工程的主要资源为人,它往往是要做某个东西的人请另外的一些人帮他们做,我们可以这样通俗地解释:
需要这个东西的人<我们成他为客户)他也许知道自己想要的是怎么样的,但是他也许不知道怎么做这个东西。
做这个东西的人<开发团队)也许知道怎样做,但是他们不明确客户想要的到底是怎样的。
而解决这个问题的方法只有沟通。
此外,软件开发是一个脑力密集型工作,它的成果是需要聚集每一个开发团队成员的想法和智慧。
对于一个大型工程来说,如果团队成员之间不能够进行良好的沟通,把他们的思想融汇到一起,也是难以得到一个完好的成果的。
因此,在软件工程管理中,沟通管理也是一个需要我们足够重视的个性问题。
沟通的好坏将直接影响到软件的质量,甚至软件的成败。
3.4.2沟通问题解决之道
工程沟通计划是工程整体计划中的一部分,它的作用非常重要,也常常容易被忽视。
经常出现的问题是工程经理凭自己的经验进行口头安排与交待,工程成员按经理的指示被动地、应付式地完成信息沟通工作。
这种问题的原因主要是工程计划阶段工程经理嫌麻烦或不重视没有进行严格的沟通计划。
一种高效的体系不应该仅仅靠口头传授,落实到规范的计划编制中很有必有。
在软件工程管理中,工程干系人众多,没有沟通管理计划,沟通必然混乱。
计划前,团队里应建立起一种相对稳定的、可以重复执行的沟通管理计划,只要能训练成员重复执行,沟通过程必然能逐渐演化和成熟,沟通就有实现可管理的可能。
在软件工程管理中,工程经理应在沟通中担任主持协调者,调解人,聆听者,解释者等诸多角色。
我们可以借助microsoftproject2003作为辅助沟通工具,并通过灵活运用多种沟通方式,直接与工程组成员沟通,避免中间环节,发展良好的沟通技能,善于运用倾听和反馈,召开高效的工程会议等方法和策略进行工程沟通管理。
我们可以采用的沟通方法有:
<1)会议沟通。
这个是一个成本比较大,但是很有效的方法。
通常可以借助它来解决比较重大,复杂的问题。
<2)E-mai沟通。
可以用它来解决一些较小的问题,或者资料数据的交流。
特别适用于团队成员内部交流。
<3)口头沟通。
这种沟通方法往往能加深彼此之间的友谊,加速问题的冰释。
适用于工程经理与客户之间的沟通。
<4)电话沟通。
比较常用而经济的沟通方式。
或许还有其它的一些沟通方式,但是上面这几个是比较有效而且比较适用的方法。
我们可以借助它们来解决软件工程管理中的沟通问题。
四、总结
文章中我们讲述了软件工程管理的定义以及它的意义,并着重讲述了软件工程管理中的三个个性问题以及它们的解决之道。
很显然,在工程管理中,个性问题肯定不止这三个,我们还可以通过查找并学习相关资料的了解它们。
在文章中我主要叙写了这三个,是因为我觉得它们是我在软件工程管理课程和课程实践中感受比较深刻,而且比较重要的。
也许这里讲的解决方法也还是不够全面的,对于软件工程管理,我们只能通过别人的经历,或者更多的自己的实践,总结,积累,使自己的经历成为我们的收获,才能为我们以后遇到的问题提供一个解决的思路。
五、参考文献
【1】软件工程管理教材PPT桂林电子科技大学王海舰
【2】软件工程管理之工程沟通与冲突管理首都经济贸易大学信息学院
【3】软件开发的特点——软件质量保证第一步李云博客
六、致谢
在这个学期里,王老师通过自己的经历,还有工程经验,给我们讲授了这门精彩的软件工程管理课程,使我感受很深。
从中也学到了很多软件工程管理的知识。
除此之外,王老师还给我们讲了有关生涯规划和毕业就业的问题,给了我人生路上的指导。
感谢王老师给我们讲授的知识教诲。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 项目 管理 设计方案 黄初航