软件过程

对大多数人来说，若要建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根” (Leffingwell 1997) 。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟 ( 期望差异 ) —开发者开发的与用户所想得到的软件存在着巨大期望差异。 在软件工程中，所有的风险承担者 (stakeholder)( 这个词很有意思，原义是赌金保管者。我看过很多的翻译，有翻译成涉众的，也有的翻译成参与者的，但是我想他的主要意思就是和这个项目有密切相关利益的人 ) 都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员 ( 负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人 ) 、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用有效的需求分析过程。软件需求的定义 IEEE 软件工程标准词汇表 (1997 年 )

读软件需求分析首先明确了软件需求包含的三个不同层次，业务需求即组织机构或客户的需求目标，用户需求即用户使用产品必须要完成的任务，功能需求即开发人员需要实现的软件功能。从需求的定义上我们可以知道需求关注的是究竟想开发什么与设计细节实现细节项目规划信息或者测试信息无关 不重视需求过程会给项目带来极大风险，所以在需求过程中我们要注意避免以下几种情况，无足够用户参与，用户需求不断扩展，用户需求不明确或者说模棱两可，不必要的特性即为软件画蛇添足，过于精简的规格说明，忽略了用户分类，不准确的计划，而高质量的需求过程要求产品开发过程中的通力合作同时充分了解其市场，因此要想完成一份优秀的需求就必须具备完整性（功能完整），正确性（准确陈述其功能），可行性，必要性（每项需求都硬把客户真正需要的和最终系统），划分优先级，无二义性（只能有一个明确统一的解释），可验证性等特性。同时需求规格说明也需具备完整性，一致性，可修改性，可跟踪性（即每项软件需求与它的根源和设计元素，源代码，测试用例之间建立起链接链） 再进行软件需求分析时要清楚谁是客户，谁是用户，分清楚业务需求和用户需求。客户有义务说明软件的业务需求，任何其他的说明都应该遵从业务需求的规定，而用户需求则必须从试用产品的用户处收集，业务需求来自风险承担者，用户需求则来自产品的真正使用操作者。对于客户而言客户有权利要求分析人员使用符合客户语言习惯的表达

带图更精彩 ！ 第一章软件工程概论 一、软件 软件：程序、数据及其相关文档 特点：抽象性、无明显制造过程、无老化、对硬件依赖性。 分类：系统软件、支持软件、应用软件 软件设计过程中，随着时间的推移，软件比硬件投入逐渐增大。 发展阶段：设计-系统-工程 过程：软件规格说明、软件开发、软件确认、软件改进 特性：易理解性、可见性、可支持性、可接受性、可靠性、健壮性、可维护性、速度等。 步骤： 1.制定计划：总目标、功能性能可靠性接口要求、可行性研究 2.需求分析和定义：需求定义图表表示、软件需求说明书。 3.软件设计：概要设计，划分模块；详细设计，确定模块内结构及接口。 4.程序编写 5.软件测试：单元测试、组装测试。 6.运行维护：改正性维护、适应性维护、完善性维护。 二、软件开发模型 第一次实验探索开发，再进行进一步的开发。 渐增模型，基于原型。 螺旋模型：制定计划，风险分析，实施工程，客户评估。四个象限轮转，每转一圈产生一个原型。 喷泉模型：可迭代 三、软件生存周期 系统开发生命期：计划阶段，分析阶段，设计阶段，实现阶段，支持阶段。 四、软件工程 软件工程定义：软件工程是开发、运行、维护和修复软件的系统方法。 软件工程三要素：方法、工具、过程。 软件工程项目基本目标：低成本，达到要求，较好性能，易于移植，维护费用低，按时交付。 软件工程七条原理: 1. 分阶段的生存周期计划严格管理

开学第一课我们观看了《梦想改造家》，在这个案例中，冯家的老房子沿街而建，总体呈三角形形状，从某个角度看，老屋单薄得像是纸片。“纸片屋”共有25平方米，对三口之家来说，人均绝对值并不算太低，但被称为最稳固的三角形却带来了一堆麻烦，处处的尖角无可利用，造成了极多的空间浪费，经过设计师王平仲的改造，纸片屋变空中花园。我们在惊叹于设计师的设计外，有没有想过一个建筑设计师的工作流程类似于一个软件架构师的工作流程。 软件架构师并不是普通的程序员，这是软件行业中一种新兴职业，工作职责是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。主导系统全局分析设计和实施、负责软件构架和关键技术决策的人员。 架构师首先要进行需求分析，就像王平仲第一时间去拜访了委托人一样，得到真实可靠的需求。有人认为架构师是在需求规格说明书完成后介入的，只对最终的需求审核和确认，提出需求不清和不完整的部分。但也有人认为架构师要从项目最开始的阶段就参与进来。我个人比较倾向于第二种观点。由于分析人员在与客户交流时，往往不会深入挖掘需求，有很多隐藏的需求客户自己可能意识不到，而架构师则可以依靠敏感的软件嗅觉发现这些需求，另外，分析人员往往脱离开发团队，盲目接受客户需求，而架构师能够清楚把握现有的研发团队能做什么，不能做什么，提前预知风险，降低项目失败的机率

一、CMM简介 CMM，英文全称为Capability Maturity Model for Software，即：软件成熟度模型。 CMM的核心是把软件开发视为一个过程。它是对于软件在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。 根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化，使企业能够更好地实现商业目标。 分级：一级为 初始级 ，二级为 可重复级 ，三级为 已定义级 ，四级为 已管理级 ，五级为 优化级 。 优点： 1、提高软件开发的管理能力，因为CMM可提供软件公司自我评估的方法和自我提高的手段； 2、提高软件开发效率； 3、提高软件质量； 4、提高软件竞争力； 二、初始级（Initial） 特点：软件工程管理制度缺乏，过程缺乏定义、混乱无序。经常由于缺乏管理和计划导致时间、费用超支，管理方式属于反应式，主要用来应付危机，过程不可预测，难以重复。 即使制定了一些软件工程规范，但如果规范未能覆盖基本的关键过程要求，且执行时没有相关资源的支持保证，仍将其视为初始级。 关键词：技术负债 提高：建立项目过程管理，建立各种计划，开展QA活动。 三、可重复级（Repeatable） 特点：基于类似项目的经验，建立了基本的项目管理制度，采取了一定的资源控制手段。管理人员可及时发现问题，采取应对措施。 软件开发的首要问题不是技术问题而是管理过程

一、术语 软件生存周期 项目 里程碑 软件度量 功能点分析 工作分解结构（ WBS ） 软件质量 RMMM 计划（ Risk Mitigation, Monitoring and Management Plan ） COCOMO 模型 项目计划评审技术 软件质量模型 基于时间的缺陷到达模式 软件过程 软件基本过程 软件支持过程 软件组织过程 过程框架 软件能力成熟度模型 统一过程 过程模式 个体软件过程 PSP 团队软件过程 TSP 过程规范 过程模型 配置管理 配置项 基线 预防性维护 适应性维护 二、简答题 试给出在 SEI 的 CMMI 模型中采用过程评估和改进方法的两个优点和两个缺点。 考虑你所在机构中所用的软件过程类型。使用 SEI 模型找出了多少个关键过程域？根据该模型，你所在机构的过程成熟度等级如何划定？ 若过程改进中包括度量人在过程中的工作，并对过程进行彻底的变更，这样的项目是否是不人道的？对过程改进会发生哪些抵触行为？ 给出 SEI 的 CMMI 不能适用的两个领域，并说明理由。 如何将现有的软件开发向敏捷开发方法转换？期间会遇到哪些困难，如何解决？ 分析比较 CMMI 、 ISO15504 和 6sigma 之间的共同点和区别。 软件过程为什么必须进行改进？ 软件工程中引入软件过程的作用和意义是什么？ 软件过程改进中如何管理变革？ 软件过程改进的框架的构成是什么

在现代企业中，信息系统已经越来越成为企业管理的重要支撑。因应各种业务需求对软件系统的要求，大多数企业都形式不同地建立了自己的软件开发团队，视企业的规模从一两个兼顾支援网络硬件、进行简单开发的人员到大规模的专业软件开发组织都有。通常说来,大多数企业内部开发团队是企业内部辅助主营业务的、非赢利性的组织。这类带有普遍性的企业内部软件团队是本文的关注点。 和专业软件公司开发过程一样，企业内部软件开发也涉及对过程、工具、质量、人员等各个层面的管理问题，所以目前成熟的或者正在探讨中的各种软件开发模式都可以被企业内部软件开发借鉴和参照。但是，在服务、非赢利的前提下，企业内部软件开发的各方面都有有别于专业软件公司的特点。目前关于企业内部软件开发模式和管理的探讨比较少，很多人，甚至企业内部开发团队的成员本身，都没有明确企业内部软件开发和专业的软件公司开发工作的不同，在项目管理、文档控制等方面经常教条的模仿专业软件公司的开发模式。这种认识上的模糊性削弱了企业内部软件开发团队在软件的生命周期中本来具有的优势。 1 企业内部软件开发的特点 企业内部软件开发有什么值得注意的特点呢?以下通过在几方面和专业软件公司对照的方法来进行一些分析: 1.1 软件开发团队和用户的利益关系。 专业软件开发公司和用户是商业关系，直接目的是销售产品和服务获得收益，用户本身的收益和软件公司不是明确相关的

12.23 快考试了，要开始复习了。这学期学分绩还是比较重要的。加油，奥力给 一给洛！！ 大纲： 1. 软件过程核心思想 软件工程的两个映射 概念映射：问题空间的概念和解空间的模型化概念之间的映射 业务逻辑映射：问题空间的处理逻辑与解空间处理逻辑之间的映射 软件工程所关注的对象 产品 过程 软件工程所关注的目标 软件工程的核心思想： 分治，复用，折中，演化 软件过程模型 1. 瀑布模型 2. 增量模型 3.演化模型 快速原型法： 包括抛弃式原型和演化式原型 螺旋式模型 敏捷方法 极限编程：一种应用最广泛的敏捷开发模型 敏捷模型与其它模型的分析 软件项目管理 软件开发团队的组织方式 一窝蜂模式 ：没有明确分工，存活的时间一般都不长 **主治医生模式：**一个人带着其它人干 明星模式： 社区模式 ：linux操作系统的社区 交响乐团模式 ：门类齐全，各司其职 爵士乐模式： ： 功能团队模式： 官僚模式： 产品结构分解 ： 项目管理里通常使用产品结构分解作为产品分解的工具 产出物：项目结束时需要提交的最终产品，在项目之初就可以准确预计 项目关注的四方面： 范围，时间，成本，质量 项目管理的主要任务： 可行性分析，进度安排，分线管理，质量管理，项目跟踪与控制 可行性分析与估算： 在项目开始之前，至少i要预估： 需要多少工作量 需要多少时间 需要多少人员 从而得出该项目是否可行 确定范围 ：

软件过程模型类型 瀑布模型--------------------------70年代，结构化 原型模型--------------------------80年代，需求变更 增量模型--------------------------80年代，多版本开发 螺旋模型--------------------------80年代，降低风险 喷泉模型--------------------------90年代,面向对象 统一软件开发过程--------------90年代，完美、完整（RUP） 敏捷过程与极限编程-----------00年代，以人为本 瀑布模型 一种基于里程碑的、阶段性的过程模型 文档是每个阶段的成果体现 每阶段需要评审 输入输出 简单易理解易操作 优点： 需求稳定、变化很小且开发人员能够一次性获取全部需求的项目 软件开发人员具有丰富经验，对于应用领域非常熟悉 软件项目本身的风险很低 缺点： 不接受需求模糊、变更 错误发现太迟 开发进度缓慢 中间成果难利用 抗风险能力弱 快速原型模型 背景：需求分析较难开展，无法固化用户需求 用户熟悉的是业务但不懂得开发的技术，且开发者熟悉具体的开发方法、工具等技术内容 而不明白相关的业务流程 用户和开发者在试用或演示原型过程中加强沟通和反馈，通过反复评价和改进原型，减少双方的误解，降低缺陷引入的几率

一. 摘要 这篇文章详细介绍了一个“多路信号采集系统”的开发过程。“多路信号采集系统”是一个可伸缩的信号采集系统，通道可以选择从0~100路不同的信号源。单个采集板都能够采集10路数据，用户可以根据自己的需求方便地扩展或者收缩信号通道数。本系统可以用于常见的民用或者工业现场监控、仪器仪表等数据采集场合。该系统基于Arm Context M3内核处理器实现，有基板和采集板两大部分组成，基板主要负责整个采集时序的控制，而采集板则完成真是的数据采集并将采集到的数据发送到数据总线，进而传输到主机端。数据传输采用了串口通信的方式（RS485），并采用Modbus协议实现，从而方便地实现了采集板地址的检索、数据量控制、以及CRC校验值确定等功能。软件系统则采用了固件库编程的方式，全程开发均使用C语言完成，从而为以后升级做好准备。开发使用了今日标企业工作平台以及Github代码托管平台相结合完成开发的方式，使用今日标企业工作平台管理项目开发流程，而使用Github则方便地实现了不同地区开发者协作开发的目的。而系统调试则选择了传统的调试方式，先进行单个功能模块测试，再测试系统功能，进而Burning实验。 二. 本文提纲 1. 摘要 2. 本文提纲 3. 项目起始 4. 开发方式选择 5. 系统构架 6. 硬件设计 7. 软件设计 8. 系统调试 9. 总结 三. 项目起始