谬种流传--瀑布模型

最新推荐文章于 2020-09-03 11:10:46 发布
最新推荐文章于 2020-09-03 11:10:46 发布
阅读量192 收藏
点赞数
分类专栏： 乱翻书
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/iteye_11003/article/details/81427100
版权

一些历史事实:

20世纪80年代
美国国防部(US Department of Defense,DoD)就针对软件开发颁布了标准DOD-STD-2167.
这是基于瀑布型与文档驱动的方法.有调查报告表明总成本370亿美元的项目样本中,75%的项目失败或者无法使用,
只有2%的项目能够不做进行一步修正就可使用.

1988年2月
改良的DOD-STD-2167A 发布, 该版本改进了2167标准,更加亲迭代开发(Iterative and Incremental Development (IID)).
由于军方后勤部门不同意,无法将瀑布型流程剔除.但该标准仍被许多人解释为优先采用瀑布型.

1994年12月
2167A被MIL-STD-498取代,该标准描述了递增式的构建,倡导渐进的需求和设计.

2000年
美国国防部颁发了新的软件项目"指导意见" DoD 5000.2,再次推荐渐进交付和IID的应用.

遗憾的是,STD-2167影响了其他国家的标准定义.这些国家还没有了解到DoD后来摒弃了2167标准和瀑布型.

为什么还有人在推行瀑布型?
"对于任何的复杂问题，都有一个简单干净但是错误的解决之道" H.L.Mencken


以上资料源自 Agile&Iterative Development A Manager's Guide-- Craig Larman

iteye_11003
关注
专栏目录
瀑布模型
cspyb的专栏
11-03 5550
  瀑布模型 瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、
UML建模案例，图书馆管理系统
11-13
也不知道与之前传得是不是雷同，反正拿去看看吧。 软件工程这种注重实践得东西。 嗨。
服务，微服务，纳米服务–我的天哪！
danpu0978的博客
04-20 229
显然有一种新的分布式体系结构称为微服务，所以上周我继续阅读了马丁·福勒（Martin Fowler）和詹姆斯·刘易斯（James Lewis）关于该主题的大量文章 。 我对此的反应基本上是： 我想使用新名称（Microservices）比说SOA实际含义要容易得多-re http://t.co/gvhxDfDWLG — Arnon Rotem-Gal-Oz（@arnonrg...
软件经济学四：改进软件开发过程
刘军的专栏
03-17 2463
 本文来源：谢老师的博客 现实中的软件项目过程与计划都是极为复杂的，他们象蛛网一样既互相支持又互相影响。在整个过程体系中，既有并行关系，又有串行关系。而且，随着项目越来越大，计划中所增加的管理性步骤也就越来越多，管理成本越来越高。如何建立合理的过程体系？如何降低管理成本？如何在变动的环境下而不至于发生混乱？事实上，过程体系越复杂，应变能力就越差，但是没有合理的过程，
IEEE Std 1012-2012 系统、软件测试与验证标准
11-07
IEEE Standard for System and Software Verification and Validation IEEE Std 1012-2012 Front Cover -14 Title Page -12 Notice to users -9 Laws and regulations -9 Copyrights -9 Updating of IEEE documents -9 Errata -9 Patents -8 Participants -7 Introduction -5 Contents -3 Important notice 1 1. Overview 1 1.1 Scope 1 1.2 Purpose 2 1.3 Field of application 3 1.4 V&V objectives 4 1.5 Organization of the standard 4 1.6 Audience 6 1.7 Conformance 7 1.8 Disclaimer 7 2. Normative references 7 3. Definitions, abbreviations, and acronyms 7 3.1 Definitions 7 3.2 Abbreviations and acronyms 11 4. Relationships between V&V and life cycle processes 12 5. Integrity levels 15 6. V&V processes overview 17 6.1 General 17 6.2 V&V testing 18 7. Common V&V activities 19 7.1 Activity: V&V Management 19 7.2 Activity: Acquisition Support V&V 20 7.3 Activity: Supply Planning V&V 21 7.4 Activity: Project Planning V&V 21 7.5 Activity: Configuration Management V&V 21 8. System V&V activities 33 8.1 Activity: Stakeholder Requirements Definition V&V 33 The purpose of the Stakeholder Requirements Definition Process is to define the requirements for a system that can provide the services needed by users and other stakeholders in a defined environment. It identifies stakeholders, or stakeholder classes... 33 The V&V effort shall perform, as specified in Table 2b for the selected integrity level, the following Stakeholder Requirements Definition V&V tasks described in Table 1b: 33 8.2 Activity: Requirements Analysis V&V 33 8.3 Activity: Architectural Design V&V 34 8.4 Activity: Implementation V&V 35 8.5 Activity: Integration V&V 35 8.6 Activity: Transition V&V 36 8.7 Activity: Operation V&V 36 8.8 Activity: Maintenance V&V 37 8.9 Activity: Disposal V&V 38 9. Software V&V activities 68 9.1 Activity: Software Concept V&V 68 9.2 Activity: Software Requirements V&V 68 9.3 Activity: Software Design V&V 69 9.4 Activity: Software Construction V&V 69 9.5 Activity: Software Integration Test V&V 70 9.6 Activity: Software Qualification Test V&V 70 9.7 Activity: Software Acceptance Test V&V 71 9.8 Activity: Software Installation and Checkout V&V 71 9.9 Activity: Software Operation V&V 72 9.10 Activity: Software Maintenance V&V 72 9.11 Activity: Software Disposal V&V 73 10. Hardware V&V activities 110 10.1 Activity: Hardware Concept V&V 110 10.2 Activity: Hardware Requirements V&V 110 10.3 Activity: Hardware Design V&V 111 10.4 Activity: Hardware Fabrication V&V 111 10.5 Activity: Hardware Integration Test V&V 112 10.6 Activity: Hardware Qualification Test V&V 112 10.7 Activity: Hardware Acceptance Test V&V 113 10.8 Activity: Hardware Transition V&V 113 10.9 Activity: Hardware Operation V&V 114 10.10 Activity: Hardware Maintenance V&V 114 10.11 Activity: Hardware Disposal V&V 115 11. V&V reporting, administrative, and documentation requirements 147 11.1 V&V reporting requirements 147 11.2 V&V administrative requirements 150 11.3 V&V documentation requirements 150 12. V&V plan outline 151 12.1 Overview 151 12.2 VVP Section 1: Purpose 152 12.3 VVP Section 2: Referenced documents 152 12.4 VVP Section 3: Definitions 152 12.5 VVP Section 4: V&V overview 152 12.5.1 VVP Section 4.1: Organization 152 12.5.2 VVP Section 4.2: Master schedule 153 12.5.3 VVP Section 4.3: Integrity level scheme 153 12.5.4 VVP Section 4.4: Resources summary 153 12.5.5 VVP Section 4.5: Responsibilities 153 12.5.6 VVP Section 4.6: Tools, techniques, and methods 153 12.6 VVP Section 5: V&V processes 154 12.6.1 VVP Section 5.1: Common V&V Processes, Activities, and Tasks 154 12.6.2 VVP Section 5.2: System V&V Processes, Activities, and Tasks 154 12.6.3 VVP Section 5.3: Software V&V Processes, Activities, and Tasks 154 12.6.4 VVP Section 5.4: Hardware V&V Processes, Activities, and Tasks 154 12.7 VVP Section 6: V&V reporting requirements 154 12.8 VVP Section 7: V&V administrative requirements 154 12.8.1 General 154 12.8.2 VVP Section 7.1: Anomaly resolution and reporting 154 12.8.3 VVP Section 7.2: Task iteration policy 154 12.8.4 VVP Section 7.3: Deviation policy 155 12.8.5 VVP Section 7.4: Control procedures 155 12.8.6 VVP Section 7.5: Standards, practices, and conventions 155 12.9 VVP Section 8: V&V test documentation requirements 155 Annex A (informative) Mapping of IEEE 1012 V&V activities and tasks 156 A.1 Mapping of ISO/IEC 15288 V&V requirements to IEEE 1012 V&V activities and tasks 156 A.2 Mapping of IEEE 1012 V&V activities to ISO/IEC 15288 system life cycle processes and activities 158 A.3 Mapping of ISO/IEC 12207 V&V requirements to IEEE 1012 V&V activities and tasks 159 A.4 Mapping of IEEE 1012 V&V activities to IEEE 12207 software life cycle processes and activities 161 Annex B (informative) A risk-based, integrity-level scheme 163 Annex C (informative) Definition of independent V&V (IV&V) 165 C.1 Technical independence 165 C.2 Managerial independence 165 C.3 Financial independence 165 C.4 Forms of independence 165 C.4.1 Classical IV&V 166 C.4.2 Modified IV&V 166 C.4.3 Integrated IV&V 166 C.4.4 Internal IV&V 166 C.4.5 Embedded V&V 167 Annex D (informative) V&V of reuse software 168 D.1 Purpose 168 D.2 V&V of software developed in a reuse process 169 D.2.1 V&V of assets in development 169 D.2.2 V&V of reused assets 169 D.3 V&V of software developed and reused outside of a reuse process 169 Annex E (informative) V&V measures 175 E.1 Introduction 175 E.2 Measures for evaluating anomaly density 175 E.3 Measures for evaluating V&V effectiveness 176 E.4 Measures for evaluating V&V efficiency 176 Annex F (informative) Example of V&V relationships to other project responsibilities 178 Annex G (informative) Optional V&V tasks 179 Annex H (informative) Environmental factors considerations 185 H.1 Introduction 185 H.2 In the agreement processes 185 H.3 In the organizational project-enabling processes 185 H.4 In the project processes 186 H.5 In the technical processes 186 Annex I (informative) V&V of system, software, and hardware integration 188 I.1 Introduction 188 I.2 Examples of system failures caused by integration issues 188 I.2.1 Year 2000 System Integration Issue 189 I.2.2 System architecture integration issues 189 I.3 System, software, and hardware interaction issues 190 Annex J (informative) Hazard, security, and risk analyses 193 J.1 Hazard analysis 193 Annex K (informative) Example of assigning and changing the system integrity level of “supporting system functions” 198 Annex L (informative) Mapping of ISO/IEC/IEEE 15288 and IEEE 12207 process outcomes to V&V tasks 200 Annex M (informative) Bibliography 209
揭穿5个忽悠人的Wi-Fi安全谣言
10-17
Wi-Fi网络早已十分普及，所以也出现了很多貌似可以保障无线网络安全的各种所谓绝招或方法。在网上搜索一下就能发现好多早已过时，而且根本不安全的所谓...这些谬种流传的所谓的Wi-Fi安全技术早已过时而且根本不靠谱...
高考语文易错字音选择题集锦（直接打印）.doc
10-12
12. 字音辨析：如“仆倒”、“仆人”、“风尘仆仆”、“前仆后继”的“仆”，“剥皮”、“剥离”、“剥削阶级”、“生吞活剥”的“剥”，“寥落”、“寥寥”、“谬种流传”、“未雨绸缪”的“寥”，“札记”、“扎营...
山东师大附中高一语文期中试卷[精选].doc
08-19
1. 汉字拼音：试题中涉及到汉字的正确读音，例如“有的放矢”的“矢”应读作shǐ，“谬种流传”的“谬”应读作miù，这些都是对常用词汇拼音掌握的考察。 2. 错别字辨识：如“扎记”应为“札记”，“窜入”应为“羼...
关于GJB438A-97软件设计文档的疑问
logiciel的专栏
05-31 6160
关于GJB438A-97软件设计文档的疑问 [摘要] 本文记录了对GJB438A-97《武器系统软件开发文档》的软件设计文档的一些疑问。 1           引言　　GJB438A-97《武器系统软件开发文档》规定了软件设计文档编制的格式、内容和要求。在工程实践中执行该标准时，感到其中有些要求比较难于理解和实施。GJB438A-97是与GJB2786-96《武器系统软件
美国军工敏捷开发指南
ipmc2017的博客
03-13 494
美国军工是如何实施敏捷的呢？我会花点时间写几篇文章跟大家聊聊。今天先介绍美国国防部发布的DoD IT项目的敏捷使用指南，好比武功秘籍先讲修炼心法，相信这些敏捷导入考虑对5000组织会有借鉴意义。 美国军工敏捷背景 2017年对美国军工软件采购来说是重要意义的一年。美国国防部（DoD）发布了敏捷采购法案（Acquisition Agility Act），改变了以往软件采购模式，鼓励快速使用新兴技术，...
软件开发模型
weixin_33815613的博客
09-18 550
软件工程之软件开发模型类型 1.边做边改模型 2.瀑布模型 3.演化模型 4.增量模型 5.螺旋模型 6.喷泉模型 7.敏捷模型-SCRUM 各种模型的优点和缺点 瀑布模型 文档驱动 系统可能不满足客户的需求 快速原型模型 关注满足客户需求 可能导致系统设计差、效率低，难于维护 增量模型 开发早期反馈及时，易于维护 需要开放式体系结构，可能会设计差、效率低 螺旋模型 风险驱...
IEEE验证相关规范
Grady
09-03 293
system verilog, systemC, UVM, SDF, UPF, IP-XACT https:ieeexplore.org/document
软件工程——瀑布模型、快速原型模型、增量模型、螺旋模型
热门推荐
享受孤独
07-25 6万+
目录 一、瀑布模型 1.1什么是瀑布模型 1.2特点 1.3优缺点 1.4客户需求 二、快速原型模型 2.1什么是快速原型模型 2.2优缺点 2.3快速原型模型的思想产生、原理及运用方式 2.4类型 2.5开发步骤 三、增量模型 3.1什么是增量模型 3.2特点 3.3优缺点 3.4作用 四、螺旋模型 4.1什么是螺旋模型 4.2特点 4.3优缺点 4.4...
图书管理系统——用例图、类图、时序图
开了路虎的驸马
04-23 4万+
一、图书管理系统—-用例图 二、图书管理系统—-类图 三、图书管理系统时序图
CMMI中英文术语对照表
dely96002的博客
05-17 2455
Aability to perform执行的能力: （参见 公共特性/common feature）acceptance criteria 接受标准：为让用户、客户或其他授权组织接受，一个系统或组件所必须满足的条件。[IEEE-STD-610]acceptance testing 接受性测试：用来决定系统是否达到接受标准的正规测试，从而能够使客户决定是否接受系统。[IEEE-STD-61...
【CSS Tricks】像素风字体、图片
09-17
包含像素风中英文字体，鼠标手势普通状态、点击状态和禁用状态，仅用作技术分享学习研究，不可用于其他用途。
卡瓦牙椅E50life中文使用说明书第一部分.pdf
最新发布
09-17
卡瓦牙椅E50life中文使用说明书第一部分.pdf
ChromiumSetup.exe
09-17
ChromiumSetup.exe
Chain of thought 链式思考赋能Transformer模型解决串行计算难题
09-17
Chain of thought（CoT）使Transformer能够执行串行计算，扩展了它们解决问题的能力，超越了仅限并行的局限性。 增强Transformer的表达能力，特别是对于本质上是顺序问题。 原始问题: 大型语言模型（LLMs）在生成最终答案之前生成中间步骤（连续思考，CoT）时，展现出异常的推理能力。CoT有效性背后的机制尚不清楚，尤其是在zero shot和错误推理场景中。   本文的关键见解: • 在没有CoT的情况下，具有有限精度和多项式(n)嵌入大小的恒定深度Transformer只能解决AC0中的问题 • 通过T步骤的CoT，使用恒定位精度和O(log n)嵌入大小的恒定深度Transformer可以解决任何由大小为T的布尔电路可解决的问题 • CoT大幅提高了低深度Transformer在本质上是串行问题上的准确性   本文的解决方案: • 为通过如下特性解决问题的恒定深度Transformer定义了新的复杂性类CoT[T(n), d(n), s(n), e(n)]： T(n) CoT步骤 d(n) 嵌入大小 s(n) 精度位 e(n) 指数位
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值