|
|
5 回复 | 直到 8 年前
|
1
42
软件开发计划是一个计划,用于说明您将如何开发您打算开发和交付的软件。 虽然我知道你们这些年轻的替罪羊都认为军队是一群白痴,但事实上他们在这方面有很多经验,而且他们不像很多商业公司,对必须做的事情有一些想法。其中包括一系列关于需要考虑的事情的非常痛苦的教训,以及由于没有考虑这些事情而失败的项目的礼貌。 我将于2010年4月10日更新。我之前列出的DoD-Std-2167A源代码已经变暗了,所以将您指向mil-std-498是有意义的。不幸的是,1998年,MIL-STD-498被取消,国防部现在希望承包商使用IEEE/EIA-12207。然而,IEEE标准并不像啤酒那样免费。 见 DI-IPSC-81427A 软件开发计划大纲。 当你读到需要解决的问题清单时,你可能会觉得其中一些段落,像海军条例,是用血写的。这种印象是有原因的:他们是。项目失败,因为他们没有及时解决这些问题。 另请参见 http://sepo.spawar.navy.mil/SW_Standards.html :您可以下载包含标准和所有数据项说明(单个文档的规范)的.zip。 (是的,我知道国防部已经从DoD-STD-2167A转向支持IEEE商业标准。然而,根据他们的标准,IEEE对你左肾的一只手臂、一条腿和移植权进行了收费。国防部的标准和啤酒一样是免费的。) 编辑: 固定第一连杆 |
|
|
2
19
“[软件开发]计划是对您需要进行的所有活动的合理详细描述。” 一般来说,这是不存在的。 如果你真的有所有的要求 地 明白了,你有所有的技术问题 地 明白了,你可以写这样的文件。 但是,如果你在做什么 新的 --一些用户还没有安装的东西——或者你正在使用任何新技术,你甚至不能“合理地”详细描述你需要进行的活动。 您可以提供一个概述,概述您需要做的一些事情。但是,当您探索需求时,用户将发现事物、学习并改变他们的想法。修改计划。当您探索技术时,开发人员将发现事情、学习并修改计划。 不可能那么难——人们总是这么做。 该计划的受众是管理层。管理者希望对所有活动进行“合理”的详细描述。当用户和开发人员了解需求和技术时,细节会发生变化。这使得“合理”的测试非常,非常难以满足。当细节不断变化时,“合理”的细节层次是什么? 对计划的更改可以(也可以)每天到达。大多数经理不想每天对计划进行修改。所以太多的细节变得“不合理”。为了创建一个不经常更改的计划,该计划实际上需要是活动的摘要。“软件开发计划”唯一可行的版本是一系列定义的目标,而不是活动,而是要发布给用户的功能。 简言之,人们是这样做的 非常 总是。在30多年的软件开发(其中大部分是作为军事分包商)中,有一个关于计划的幻想,它根本不是由事实产生的。取消的项目有“合理详细”的计划,过于详细的计划,完全没有计划。 实际上,计划往往是取消的主要原因。为什么?有了“合理详细”的活动清单,任何学习都意味着计划是错误的。由于计划与实际执行不符,一定有什么地方出错了。掷硬币如果您认为执行错误,请取消该项目,因为它没有遵循计划。如果你认为这个计划是错误的,那就修正这个计划,使之与现实世界相匹配。计划越详细,就越“正确”,越有可能认为执行不当。 底线 . 软件开发计划可以是一个幻想文档,作为“瀑布式”开发方法的一部分编写,在这种方法中,所有类型的事情都是预先过度指定的,并且更改(从随团队进展而学习)会受到惩罚。 或 软件开发计划是 Agile burndown chart 这只显示了要完成的冲刺。“合理”的详细程度实际上相当低——这只是一个总结。在每次Sprint回顾中都会发生变化。 |
|
|
3
7
Artifact: Software Development Plan
软件开发计划包含 |
|
|
4
5
软件开发计划是一种特定类型的项目计划。虽然WBS很重要,但它只会划伤表面。 综合项目计划应包括:
有关这些计划的更多信息,请参见 The project Management Body of Knowledge. 有关更具体的guidline,请参见 Code Complete 2 . |
|
|
5
0
我觉得在软件开发项目中应该分为两部分
在项目管理中,所有可能的额外事项,如公司目标、项目计划、项目监控、评估、时间表预订、缺陷跟踪等都可以涵盖。 在项目开发中,项目生命周期将像瀑布一样保持。 |
推荐文章