chapter1

概念软件 = 程序+数据+文档

软件是计算机系统中与硬件相互依存的另一部分。包括程序数据相关文档的完整集合
1. 能够完成预定功能和性能的可执行指令（program
2. 使得程序能够适当地操作信息的数据结构（data）
3. 描述程序的操作和使用的文档（document）

软件危机

定义：软件在开发和维护中遇到的一些列问题

如何开发软件如何维护数量不断膨胀的已有软件

表现
进度难以控制

需求在开发初期不明确

文档资料不完整、不合格

可维护性差

价格昂贵

原因：客户软件开发人员管理人员方法和工具

软件工程
研究和应用如何以系统化的、规范的、可度量的方法去开发、运行和维护软件。即把工程化应用到软件上
软件生存周期计划、分析、设计、实现、测试、集成、交付、维护

计划：确定待开发系统的总体目标和范围，研究系统的可行性和可能的解决方案，对资源、成本及进度进行合理的估算

分析：分析、整理和提炼所收集到的用户需求，建立完整的分析模型，编写成软件需求规格说明和初步的用户手册

设计：决定软件怎么做：软件体系结构数据结构用户界面和算法

实现：编码

测试：对软件进行测试

运行和维护

软件工程三要素
1. 工具（系统）
2. 方法（技能）
3. 开发过程（框架）
软件过程
1. 瀑布
  1. 特点：
    1. 自上而下，相互衔接的固定次序
    2. 上一阶段的变换结果是下一阶段变换的输入，相邻的两个阶段具有因果关系
  2. 问题：
    1. 各个阶段完全固定产生大量文档，增加了工作量
    2. 线性的开发模型，增加了风险
    3. 早期的错误等后期测试才能发现
2. RUP 中心思想：用例驱动架构为中心迭代和增量
3. 扩展的iconix
  1. 愿景业务建模需求分析健壮性分析关键设计最终设计实现
4. scrum
  1. 四个会：计划会每日立会评审会反思会
统一建模语言 UML

chapter2 踏上iconix软件过程之路

需求工程

通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持
1. 需求开发：需求调查需求分析需求定义
2. 需求管理：需求确认需求跟踪需求变更控制
愿景
1. 找到软件项目的老大：要改善的组织中最有权力的干系人
2. 得到老大对项目的期望（愿景）
3. 描述出愿景的度量指标

chapter3 业务建模

把视角从软件系统转向客户组织，站在客户角度看问题
步骤：
1. 明确为谁服务：选定愿景要改进的组织
2. 要改进的组织是什么现状：业务用例图现状业务序列图
3. 如何改进：改进业务序列图
从外部看，组织是价值的集合，用业务用例图来建模；从内部看，组织是系统的集合，用业务序列图来建模
业务用例图：从高层次了解组织的业务构成，组成：业务执行者业务组织业务用例
1. 业务执行者：在组织之外与组织交互的人群或组织
2. 业务用例：组织为业务执行者提供的价值
业务序列图：从细节上了解组织的业务流程
1. 以面向对象的思想看业务流程
2. 组成：业务执行者业务工人业务实体
3. 作用
  1. 识别业务对象
  2. 确定业务对象间的职责，协作及交互顺序
  3. 通过序列图来了解现状，为业务的优化提供依据
业务序列图和改进业务序列图的价值
1. 业务序列图展现现有业务流程，为优化提供直接依据
2. 改进业务序列：模拟出新系统的出现对组织现行业务流程造成的影响，评估新系统的可行性或提前进行相应的准备工作

现状：业务专家的介绍
改进：老大的痛处和愿景；业务专家的抱怨；需求分析师的经验和智慧

chapter4 需求分析，用例分析法

主流分析方法：原型法用例法
域建模
1. 意义：统一术语
2. 步骤：
  1. 根据需求文档，提取出名词和名词短语
  2. 排除列表中重复、相似的术语
  3. 排除超出系统范围的术语（系统范围外和系统本身）
  4. 画出第一版域模型图
  5. 整理第一版域模型
3. 域建模间的关系：泛化关联
4. 域模型不等于数据模型
系统用例
1. 步骤
  1. 绘制系统用例图
    1. 确定系统边界
    2. 识别系统执行者
    3. 识别系统用例
    4. 确定用例之间的关系
  2. 编写系统用例描述
  3. 更新域模型
2. 从业务组织转向新系统
3. 组成：系统主执行者系统副执行者系统边界系统用例用例关系
4. 用例关系
  1. 泛化
  2. 包含
  3. 扩展
5. 用例描述
  1. 组成：干系人利益基本路径扩展路径业务规则
  2. 主语只能是执行者或系统
  3. 非功能性需求rups
    
    可靠性可用性性能可支持性

chapter5 健壮性分析

优点
1. 帮助完善用例分析结果；
2. 完善域模型，
3. 向需求分析走向系统设计做过度
三种元素
边界类实体类控制器类
交互规则
1. 执行者只可以和边界对象通话
2. 边界和控制器互相对话（名词动词）
3. 控制器和控制器相互通话（动词 - 动词）
4. 控制器和实体对象相互通话
步骤
1. 创建一个空的健壮性图
2. 将用例描述关联到健壮性图上
3. 从基本路径的第一句开始画健壮性图
4. 贯穿整个用例基本路径，一次一个句子，画执行者、适当的边界对象和实体对象以及控制器和各元素之间的连线
5. 将每一个扩展路径画在健壮性图上，并以红色标示出

chapter6 关键设计

步骤
1. 将现有的域模型直接作为第一版静态类模型
2. 基于用例描述和健壮性分析结果，画出每个用例的序列图
3. 整理静态类图和序列图
4. 关键设计复核，迭代更新用例图、类图和序列图

chapter7 详细设计

三层体系结构
1. 用户界面层
2. 业务逻辑层
3. 数据访问层

chapter8 敏捷开发

敏捷宣言
1. 个体和交互胜过过程和工具
2. 可以工作的软件胜过面面俱到的文档
3. 客户合作胜过合作谈判
4. 响应变化胜过遵循计划
虽然右项也有价值，但认为左项具有更大的价值
敏捷 = 理念 + 优秀实践 + 具体应用

理念：核心思想 value + team + adapting
1. value：聚焦客户价值消除浪费
2. team：激发团队潜能，加强协作
3. 不断调整以适应（Adapting）变化
优秀实践：敏捷的经验积累
具体应用：能够结合自身灵活应用

chapter9 scrum敏捷过程一

scrum是一个增量的、迭代的敏捷开发过程
迭代式开发的好处
1. 通过将高技术风险的需求在早期迭代里实现，有助于尽早暴露问题和及时消除风险
2. 通过提供功能渐增的产品，持续从客户获得反馈，根据反馈及时调整，使得最终产品更加符合客户的需要
3. 通过小批量减少排队，提供更灵活、快速的交付能力
4. 平滑人力资源的使用，避免出现瓶颈
scrum敏捷开发过程

项目整个开发周期包括若干个小的迭代周期，每个迭代周期称为一个sprint

使用产品backlog来管理项目的需求，产品backlog是一个按照商业价值排序的需求列表，体现形式通常为用户故事（userstory）

团队从产品backlog中挑选最有商业价值的需求，经过sprint计划会议上的分析、讨论和估算得到任务列表，称为sprint backlog

在每个迭代结束时，scrum团队将交付潜在可交付的产品增量

敏捷人员组成：
1. PO：产品负责人
2. SM：敏捷教练
3. T：开发团队
4. Stakeholders：干系人
四个会：计划会每日立会评审会反思会
敏捷团队：po sm team

chapter10 scrum敏捷过程二

产品backlog 产品backlog是需求动态管理的载体
pbi的deep特征
1. 详略得当
2. 涌现的
3. 做过估算
4. 排列了优先级
燃尽图：
scrum组成
1. 三个角色：产品负责人敏捷教练团队
2. 四个会议：迭代计划会议每日立会迭代评审会议迭代回顾会议
3. 三个产物：Product Backlog ， Sprint Backlog，燃尽图
scrum特点
1. 适于在不确定性高的环境中开发复杂产品
2. 简洁有效
3. 项目信息对所有干系人高度透明
4. 便于快速发现问题，促使团队和组织持续改进
请简述Scrum软件过程中有哪些角色，及其职责？
1. PO(Product Owner 产品负责人)、职责：
  （1）代表利益相关人（如用户、Marketing、管理者等），对产品投资回报负责
  （2）确定产品发布计划
  （3）定义产品需求并确定优先级
  （4）验收迭代结果，并根据验收结果和需求变化刷新需求清单和优先级
1. Scrum Master(Scrum教练)、职责：
  （1）辅导团队正确应用敏捷实践
  （2）引导团队建立并遵守规则
  （3）保护团队不受打扰
  （4）推动解决团队遇到的障碍
  （5）激励团队
1. Team(开发团队)，职责：
  （1）负责估计工作量并根据自身能力找出最佳方案去完成任务且保证交付质量
  （2）向PO和利益相关人演示工作成果（可运行的软件）
  （3) 团队自我管理、持续改进

chapter11 敏捷工程实践

用户故事

用户故事：作为一个XXX客户，我需要XXX功能，能够带来XXX好处。（角色功能价值）
用户故事的3c原则
1. 卡片：作为XX，我希望XXX，这样可以XXX
2. 对话：不描述到细节，由团队通过持续对话细化，激发大家的深度理解
3. 确认：有明确的验收标准
invest标准
1. 独立性
2. 可协商
3. 有价值
4. 可估算
5. 短小
6. 可测试
测试驱动开发TDD
1. 定义：以测试为编程的中心，它要求在编写任何代码之前，首先编写定义代码功能的测试用例，编写的代码要通过用例，并不断进行重构优化
2. 要求TDD要求测试可以完全自动化运行
3. 关键：
  1. 测试代码和源代码一样需要简介，可读性好
  2. 测试用例的设计要保证完备，覆盖被测单元的所有功能
  3. 每个测试用例尽量保持独立，减少依赖，提高用例的可维护性
  4. 当功能单位较大时，为降低难度，可分解为多个更小的功能单位，并逐一用tdd实现
4. 好处
  1. 和代码同步增长的自动化测试用例，能为代码构筑安全网
  2. 保证代码重构质量
  3. Tdd有助于开发人员优化代码设计
  4. 提高代码可测试性

软件工程总结--文字篇相关推荐

CSS3实战-文字篇
text-shadow的大作用多颜色阴影效果,用逗号分隔text-shaodow即可. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Tr ...
多媒体阅读软件ReadM(文字篇)-详解
ReadM是目前我见过得最强大阅读软件,它可以多种格式电子书文件如PDB.TXT.DOC等文字格式.编码模式可以说是相当全的,基本上电脑上有的txt编码,这个软件全都包括了,不需要再去一个一个的转换, ...
Markdown编辑小技巧——文字篇（一）
1.编辑需求: 撰写文章,离不开大大小小的标题.序号以及把某处段内词句强调出来,给读者更有效的视觉共鸣. 先介绍常用的文字编辑方案,标题.斜体.删除线 .有序和无序标题等都会介绍. 2.文字编辑: 加 ...
Bootstrap笔记(七) 排版 - 文字篇
排版 - 文字文字对齐大小写转换文字样式重设色彩去除文字装饰响应式字型大小文字对齐 Bootstrap提供了以下文字对齐类别範例: <!DOCTYPE html> < ...
软件工程之结构化设计篇
1 软件设计的基本概念完成了需求分析,回答了软件系统能"做什么"的问题后,软件的生命周期就进入了设计阶段.软件设计阶段,研发人员将集中精力研究如何把需求规格说明书里归纳的分析模型 ...
软件工程导论第二篇学习心得
通过这门课程,自己对于软件的认识更加深入.例如软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题.这些问题表现在以下几个方面: (1)用户对开发出的软件很难满意. (2)软件产品的质量往 ...
Windows server 2019 安装域服务器和升级域控制器以及客户机加入域，能和服务器互通——配置详解过程（文字篇）注意红体字
需求:服务器和客户机个一台准备工作:1.关闭你的主机防火墙.2.更改你的主机IP地址为静态ip(同网段).3.给你的电脑的超级管理员配置密码.4.更改你的主机名(这里是为了方便区分服务器和客户机)( ...
前端实现数字快速递增_天正CAD教程之递增文字应用实例
好课推荐: 1.CAD2014:点击查看 2.室内&全屋:点击查看 3.CAD2019:点击查看4.CAD2018:点击查看5.Bim教程:点击查看 6.室内手绘:点击查看7.CAD三维:点击 ...
大二下学期软件工程概论总结
软件工程概论这门课可以算是我本学期最辛苦的一门课了.但与此同时这门课给我带来的收获和其他课程相比,也不是一个量级的. 这学期我通过课上的学习与作业项目的完成过程,了解到软件开发由项目的确定到项目的需求 ...
最新特效移动文字代码大全
1.从右向左移从右向左移代码: <marquee scrollAmount=1 direction=left>从右向左移</marquee> 2.从左向右移从左向右移代 ...

软件工程总结--文字篇

chapter1

chapter2 踏上iconix软件过程之路

chapter3 业务建模

chapter4 需求分析，用例分析法

chapter5 健壮性分析

chapter6 关键设计

chapter7 详细设计

chapter8 敏捷开发

chapter9 scrum敏捷过程一

chapter10 scrum敏捷过程二

chapter11 敏捷工程实践

用户故事

软件工程总结--文字篇相关推荐

最新文章

热门文章