欢迎来到天天文库
浏览记录
ID:56751782
大小:2.83 MB
页数:67页
时间:2020-07-07
《浙江大学城市学院软件开发.doc》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库。
1、统计数字软件开发中应该包含的主要知识体系管理(开发过程管理,人员组织,质量控制等等)应用领域知识(行业知识)计算机知识(开发工具,设计方法,测试方法等)软件工程构成了软件管理知识体系的核心,开发规范定位为软件工程的过程实践。软件工程的知识体系主要来源于长期的软件开发实践(克服软件危机),即防范和规避软件开发过程中的主要风险。软件开发规范主要针对软件开发生命周期的主要阶段分析和讨论起应遵循的规范。丹佛国际机场1995年2月28日,耗资43亿美金的丹佛国际机场(简称DIA)正式投入使用。它占地137平方公里,拥有五个标准跑道
2、,设计旅客吞吐量为1.1亿人,货邮吞吐量630万吨,飞机起降130万架次。是世界上第一座全部用计算机设计建造和管理的机场。丹佛机场的设计规划、良好的运营以及优质的服务一直具备良好的口碑,因此丹佛机场成为北美最为优秀的机场之一:*根据美国联邦航管指出,在过去三年,丹佛国际机场为全美国15大机场中延迟时间最短的机场;*2003年丹佛机场获得了北美服务最好机场的称号;*丹佛国际机场(DIA)连续四年被商务旅行杂志的读者评选为“北美最佳机场’。丹佛国际机场的自动行包处理系统案例《科学美国人》的一篇文章吧DIA项目失败完全归咎于软
3、件产业,认为这个产业缺乏严格的标准和足够的实践经验。如果真有个天衣无缝的开发过程,是否就能消除项目中所有的去不确定性?对这项风险的深入思考可以发现由于行包自动处理系统位于关键路径上,它的任何拖延都会延误机场的开业,并直接导致每月3300万美元的损失(这是从一开始就能算出来的)。因此结论就很明显了,应该把它从关键路径上移开,这是一项关键的风险缓解措施。如果在项目初期花几百万美元准备一套备用的行包处理系统,也不至于造成如此大的损失。什么是风险?风险:未来可能发生的导致项目不好的结果的事件或者不好的结果本身。风险识别风险的发现
4、过程是应对风险的第一个环节;一般我们可以采用下面的过程来识别风险:风险识别当灾难来临的时候,这个三个步骤以相反的顺序出现,根源导致该情景的发生,最后变成我们不愿看到的后果。风险识别过程-灾难性后果分析灾难头脑风暴头脑风暴指有计划的集体想象活动:群策群力,发挥集体的创造性,使新的思想得以浮现。风险识别过程-灾难性后果分析风险识别的头脑风暴用一些小手段来帮助人们度过思维短路。1.以噩梦的形式指明问题:询问所有人,对于这个项目,他们最担心的是什么。如果他们会满身冷汗地从梦中惊醒,梦中的情景会是什么?2.使用水晶球:假设你拥有一
5、个能够预知未来的水晶球,看见世人在嘲笑你的愚蠢,那么他们在笑你什么?3.转换视角:请大家描述他们对项目最好的梦想,然后把这些美梦全都反过来,大家一齐讨论“是什么使美梦不能成真”。4.寻找不应被责备的灾难。如果大家都做了正确的事,项目会因什么而失败?5.寻找应该被责备的失败。6.设想部分失败:项目整体是成功的,但是某一方特别不满。头脑风暴是快速而猛烈的,所以你应该安排至少一个人来记录所有的意见。风险识别过程-场景构造情景构造根据记录下来的灾难,想想它可能在哪种或者哪几种情景下出现。风险识别过程-根源分析根源分析根源分析最好
6、由一组人进行。事实上根源分析并不像乍看上去那么轻松。因为“根源”本来就是一个复杂的概念风险识别过程中的文化性障碍不要成为那个消极的人;不要提出问题,除非你有解决方案;不要说任何事可能是一个问题,除非你能证明它是;不要做拆台的人;不要明确指出问题,否则你就会是那个负责解决的倒霉蛋这些障碍告诉我们必须把识别过程制度化正式化;软件项目的核心风险五种核心风险:1.进度安排的先天错误;2.需求膨胀/需求变化;3.人员流失;4.规约崩溃;5.低生产率;软件项目的核心风险进度安排错误:如果没有认真地估算产品的规模,那么你预计的进度就是
7、空中楼阁。如果管理者提出或者接受一个存在严重问题的日程安排,证明他的工作绩效很有问题。应该牢记:项目的超期不应归咎于开发者的低效率。实际上,整个开发团队很可能已经发挥出了最高的工作效率——除了管理者之外。*对项目统计可以发现一半的项目由于日程安排错误导致的项目延期至少是30%--《与熊共舞-软件项目风险管理》p.130需求膨胀:打算完全按照现在的要求交付产品,而不允许任何变动,在现实中这个是不可能的。更合理的逻辑应该是这样的:“你说你想要X;经验告诉我们,在开发过程中需求可能会有些变化,到最后你想要的东西可能跟X稍微有点
8、不同。所以,我们将针对X制定计划,并且允许一定限度的改变。”限度有多大?按照上世纪90年代中期,美国国防部提出了一组关于运转良好的项目应有的行为方式的量化数据。他们的定量分析结果是:合理的需求变更应该在每月1%以下。如果你的项目有20,000个功能点,为期2年,你就准备完成25000个功能点。(20000×(1.00
此文档下载收益归作者所有