软件过程与管理
软件过程与管理
一、概论
-
软件工程的三要素。
-
软件过程的定义。
-
常见的软件过程分类。常见的软件过程。
IEC12207软件过程分类
ISO/IEC15504软件过程分类
二、软件质量管理
-
软件质量的定义。
软件质量是软件产品满足明确或隐含需要能力的性能和特性的总体。
用户需求是衡量软件质量的基础。
除满足明确定义的需求外，还要满足隐含的需求。 -
ISO/IEC 25010:2023软件质量模型的九个一级质量特性？一级特性对应的二级特性（理解）？
-
朱兰质量管理三部曲。
质量计划 (Quality Plan)：确定项目应达到的质量标准，以及如何满足质量标准的计划安排和方法。
质量保证(Quality Assurance, QA)：确保项目达到有关标准，而开展的有计划、有组织的工作活动。”Is it done right?”
质量控制(Quality Control, QC)：是确定项目结果与质量标准是否相符，并及时纠正产品缺陷的过程。”Is it right done?”
三、软件项目管理
-
基本概念：项目；项目管理；项目管理的六大原则、五个焦点领域和七个绩效域。
项目：一项在独特环境中进行的临时性、独特性活动，旨在创造价值。
项目管理：将知识、技能、工具与技术应用于项目活动，以满足或超越预期的价值。
六大原则：Adopt a Holistic View
采取整体观
Focus on Value
关注价值
Embed Quality Into Processes and Deliverables
将质量嵌入流程和可交付成果
Be an Accountable Leader
成为负责任的领导者
Integrate Sustainability Within All Project Areas
将可持续性融入所有项目领域
Build an Empowered Culture（赋予其自主决策权与行动权限）
建立赋权文化
五个焦点领域启动-Initiating
计划-Planning
执行-Executing
监督控制-Monitoring and Controlling
收尾-Closing
七个绩效域。
Governance-治理
Scope-范围
Schedule-进度
Finance-财务
Stakeholders-利益相关者
Resources-资源
Risk-风险 -
可行性分析：净现值的优点。
净现值 = 第t年的值/(1+r)t
净现值是成本效益分析的有力工具之一
计算净现值的关键是选择合适的贴现率
给定设置的目标回报率，不会做净现值为负值的项目
使得净现值为0的贴现率很重要
使得净现值为0的贴现率称之为内部回报率。
3. 识别软件项目的活动：WBS。
Work Breakdown Structure (WBS, 工作分解结构)
WBS是面向可交付成果的对项目任务的分组,它组织并定义了整个项目范围。是一个分级的树型结构，是对项目由粗到细的分解过程。
上下层次之间的关系
注意层次的深度（一般3-5层）
只有最底层的叶子节点构成了项目的活动集合
WBS可以随着项目的进展而细化
4. 软件工作量估计方法：常见的软件工作量估计方法，记住名称，并理解每个方法。IFPUG功能点方法中信息系统的五大类功能？
专家判断对应用领域或开发环境有丰富知识的人，对执行一项任务所需的工作量做出估计
特别是，对变更一个软件的已有部分所需的工作量进行估计时，最可能使用这个方法
专家评判往往是使用已标识的来自过去类似项目的非正式的类比法和由底向上估计法相结合的方法
类比估计如何描述实例特征
通过选取合适的相似度、相异度的表达式，评价相似程度
由底向上估计
· 将项目逐层拆解为越来越细分的组成单元
· 拆分至单人可在 1～2 周内独立完成的工作单元为止
· 针对最底层的工作活动开展成本估算
· 上层各级工作包的估算值，通过累加其下属底层工作的估算结果得出
自顶向下估计
依托工作量驱动因子，测算项目整体估算成本 / 工时
将总估算值按比例分摊至各细分工作单元
Albrecht/IFPUG function points
-
External input (EI) 外部输入类型
释义：用于更新系统内部数据存储的输入类业务事务。用户向系统提交录入数据，系统会新增、修改内部文件中的数据。 典型场景：新增用户、修改订单、提交表单。 -
External output (EO) 外部输出类型
释义：从系统内部存储提取、加工数据并对外展示输出的业务事务，一般用于生成各类统计报表，输出数据经过系统逻辑计算处理。 典型场景：打印财务报表、导出业务汇总页面。 -
External inquiry (EQ) 外部查询类型
释义：由用户主动发起、仅查询展示信息，但不修改任何内部数据的业务事务。用户输入查询条件，系统根据条件检索并返回对应信息。 典型场景：订单查询、客户信息检索。 -
Logical interface file (LIF) 内部逻辑文件类型
释义：大致等同于系统分析中的 “数据存储”，由当前待评估系统创建、读写与维护，是系统自有业务数据载体。 典型场景：本系统的客户数据库表、商品库存数据表。 -
External interface file (EIF) 外部接口文件类型
释义：数据存储由其他独立应用系统维护，本系统仅能从中读取数据，无权新增、修改该存储内的数据。 典型场景：财务系统读取人事系统的员工档案库、电商系统读取第三方物流系统的配送数据。 -
软件项目的进度安排：甘特图、关键路径法、关键链法、PERT技术。（关键路径法必须全面理解掌握，只需要掌握活动节点，活动箭头不需掌握；后两种方法掌握计算步骤）
关键路径法cpm -
软件项目的资源管理：资源定义，资源分配直方图。
资源是执行项目所需要的任何项和人。
所有项目：场地，文具等
整个项目：项目经理
某项活动：软件开发人员
资源直方图平衡化
通过延迟某些活动的开始日期，来平衡化资源直方图
不增加时间而分开任务是很难的
资源的平衡化是一个很难的问题 -
软件项目的风险管理：风险的定义，风险管理的框架，风险处理的方法。
风险的定义：一个不确定的事件或者情况，若其一旦发生，会对项目的目标，例如，范围、进度、成本和质量，产生积极或消极的影响。
风险是未来可能发生的问题，而不是当前已经发生的事情
风险的产生一般是有原因的，例如，开发人员离职导致项目延期
Risk acceptance(接受风险): 规避该风险所需付出的成本，可能高于风险一旦发生所造成的实际损失成本。
Risk avoidance(规避风险)
Risk reduction(降低风险)该风险予以保留接受，但会采取行动降低风险发生的概率；例如制作原型，能够减少需求理解偏差的风险
Risk transfer(转移风险) -
软件项目的监督和控制：挣值分析。
(1) https://wenku.baidu.com/view/7bcf90280066f5335a81211b.html
(2) https://blog.csdn.net/pmpljp/article/details/19299077
9.软件项目的配置管理：配置管理的任务，配置项。
软件配置管理(Software Configuration Management, SCM)是指一套管理软件开发和维护过程中所产生的各种中间软件产品的方法和规则。它是控制软件系统演变的学科。
软件配置管理的目标
标志变更
控制变更
确保变更正确实现
向受变更影响的组织和个人报告变更
配置项：软件配置管理的对象，一个软件配置项是项目中一个特定的、可文档化的工作产品集。例如，程序，文档等
基线: 已经正式通过复审和批准的某规约和产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程来改变。
四、经典的软件过程管理
- CMM/CMMI
(1) CMM：出发点，体系结构，关键过程域，关键实践活动。
关键过程域(Key Process Area)：一系列相互关联的操作活动，标识了达到某个成熟度级别时所必须满足的条件。
一个软件企业如果希望达到某一个成熟度级别，就必须完全满足该级别的关键过程域的要求，即满足每个关键过程域的目标。
CMM共有18个KPA，每一级都有自己的KPA。
KPA分为三大类：管理过程、组织过程和工程过程。
每个关键过程域 (KPA) 都具有的五种公共特性：
执行约定
执行能力
执行活动
测量和分析
验证实施
(2) CMMI与CMM的区别和联系，CMMI的两种表示方法。
CMMI全称是Capability Maturity Model Integration，即软件能力成熟度模型集成，是CMM的改进。
CMMI有阶段式和连续式两种表示方法
连续式表示法
- PSP：结构，两种日志，评审比测试有效的原因，四个设计模板。
个人软件过程(Personal Software Process，PSP)是一种可用于控制、管理和改进个人工作方式的自我持续改进过程。
日志---时间日志和缺陷日志
评审比测试有效的原因--在评审时发现的错误比测试是发现的多；成本低。缺陷发现的越早，修复的花费越低；且避免缺陷比发现和修复缺陷更有效。
四个设计模板---a操作规格模板，b功能规格模板,c状态规格模板,d逻辑规格模板
LST逻辑规格模板（无）：用于描述系统中各有机组分（方法，项，算法等）的逻辑实现。
SST状态规格模板（UML:状态机图）：用于描述系统中所有可能发生的状态的集合，以及状态之间转换的条件，伴随的动作。。
FST功能规格模板（UML:类图）：描述了系统可以向用户提供对外部可见的行为说明书，以及与这些功能相关的系统行为，变量和内部关系（继承关系）。
OST操作规格模板（UML:用例图、时序图）。描述了系统与外界的交互。描述了用户与待设计系统的正常情况下和异常情况下的交互。
-
MSF：六个角色；过程模型中的五个阶段。
MSF即微软的解决方案。团队是微软作战最小的基本单元。Microsoft Solution Framework
项目场景中的6个角色：产品管理，程序管理，开发，测试，发布管理，用户体验。
5个阶段：构思阶段，计划阶段，开发阶段，稳定阶段，部署阶段。 -
RUP：九个软件过程，四个阶段，六大经验。
Rational Unified Process），统一软件开发过程,面对对象的软件工程的过程框架。
9个过程域：6个是核心3个是辅助：
6个核心过程流：商业建模，需求，分析和设计，实现，测试，部署。
3个辅助过程流：配置和变更管理，项目管理，环境。
4个阶段：初始，细化，构造，交付。(每个阶段做什么，做完的里程碑，中间产品是什么？)
主要活动 里程碑 中间产品
起始（先启/初始）阶段 ² 建立系统的业务模型
² 捕获系统的基本需求
² 确定系统的边界
² 识别关键任务
² 确定系统验收标准
² 进行项目风险评估
² 进行项目资源的估计与效益分析
² 制定项目开发计划于重要里程碑 生命期目标 ² 项目蓝图文档：系统的核心需求、关键特性与主要约束
² 初始的用例模型（完成10%~20%）
² 初始的项目术语表
² 业务用例模型，包括商业环境、验收标准和财政预测
² 初始的风险评估
² 一个可以显示阶段和迭代的项目计划
² 一个或多个原型
² 初始的架构文档
细化阶段（最关键的阶段） ² 细化构想，建立对大多数关键用例的确定理解
² 分析问题域，建立坚实的架构
² 细化机构并选择组件
² 捕获80%的功能需求用例
² 精化风险评估
² 建立可执行的软件原型
² 定义非功能需求
² 制定过程迭代计划和迭代的评价标准 生命期构架 ² 系统架构基线
² UML静态模型、UML动态模型、UML用例模型
² 修订的风险评估
² 修订的用例
² 修订的项目计划
² 可执行的原型
构造阶段 ² 资源管理、资源控制和过程优化
² 完成组件开发并根据已定义的评价准则进行测试
² 利用构想指定的准则对发布的产品进行评估 初始运作功能。
构造阶段的结束时项目开发的第三个重要的里程碑。这个阶段产生的版本通常被称为β版。 ² 可运行的软件系统
² UML模型
² 测试用例
² 用户手册
² 发布描述
交付（转化、产品化）阶段 ² 将软件系统部署到用户环境
² 修复软件的缺陷
² 编制用户手册和其他文档
² 培训用户和维护人员
² 提供用户咨询 产品发布 ² 可运行的软件产品
² 用户手册
² 用户支持计划
六大经验---
迭代式开发，管理需求，基于组件的体系结构，可视化建模，验证软件质量，控制软件变更
五、敏捷软件开发
-
敏捷宣言。
-
常见的敏捷软件过程，SCRUM和极限编程。
---极限编程XP
是一种全新而快捷的软件开发方法。XP团队使用现场客户、特殊计划方法和持续测试来提供快速的反馈和全面的交流。这可以帮助团队最大化地发挥他们的价值。------现场客户，计划游戏，系统隐喻，简单设计，代码集体所有，结对编程，测试驱动，小型发布，重构，持续集成，每周4小时工作制。
XP特别适合于小型的有责任心的、自觉自励的团队开发需求不确定或者迅速变化的软件
---并行争球法---Scrum---增量的迭代的开发过程
整个 开发周期包含若干个小的迭代周期，每个小的的迭代周期称为一个Sprint（2-4周）
---水晶法Crysta----每一个不同的项目都需要一套不同的策略、约定和方法论
~ 产品负责人 Product Owner：负责维护产品订单的人，代表利益相关者的利益。
~ Scrum主管 Scrum Master：为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。一般不翻译。
~ 开发团队 Team: 由负责自我管理开发产品的人组成的跨职能团队。
~ 计划会 Sprint Planning Meeting：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。
~ 每日立会 Daily Standup Meeting：团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。
~ 评审会 Review Meeting：在冲刺结束前给产品负责人演示并接受评价的会议。
~ 反思会/回顾会 Retrospective Meeting：在冲刺结束后召开的关于自我持续改进的会议。
~ 产品订单(product backlog)是整个项目的概要文档。产品订单包括所有所需特性的粗略的描述。产品订单是关于将要创建的什么产品。
~ 冲刺订单(sprint backlog)是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。
~ 燃尽图(burn down chart)是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目。
XP是以开发符合客户需要的软件为目标而产生的一种方法论
~ XP是一种以实践为基础的软件工程过程和思想
~ XP认为代码质量的重要程度超出人们一般所认为的程度
~ XP特别适合于小型的有责任心的、自觉自励的团队开发需求不确定或者迅速变化的软件
极限编程准则：
~ 沟通
~ 简单
~ 反馈
~ 勇气
~ 尊重
~ 谦逊
浙公网安备 33010602011771号