软件工程与软件自动化学习笔记(更新中)

2018-05-03  本文已影响358人  WangGavin

软件工程的前生今世

被迫产生的软件工程

软件开发

1968年“软件危机”概念出现
质量,进度与成本
人们被迫研究软件生产中的技术手段和管理方法

产生了软件工程

软件工程是应用计算机科学、数学及管理科学等原理 开发软件的工程。它借鉴传统工程的原则、方法,以 提高质量,降低成本为目的。

三要素

一级学科

在中国先是计算机与技术0812,然后才产生软件工程0835

知识体系

2001年SWEBOK把软件工程分为10个领域

跨界

软件工程的研究除计算机软件本身外,还涉及众多其他的领域 ,如管理科学、心理学、经济学、人机工程学等,因此,它是 一门综合性学科。

软件自动化级别

软件自动化级别

主要开发活动所占比例

主要开发活动所占比例

也许未来的软件开发可能真像老师说的那样,给电脑说出需求,立马就生成软件了,那不就是AI写代码吗!

软件工程的发展

万变不离其宗

幽默一则

幽默一则
幽默一则

看起来在实际的公司里也是很常见的

软件开发周期

软件开发的基本活动相同,但组织方式不同,构成了不同的软件生存(开发)周期模型

软硬件生存曲线

从左到右依次是硬件的,理想中软件的和实际软件的

典型的开发周期模型

开发周期模型

瀑布模型不可倒流,迭代模型就是不断的迭代

软件开发基本活动

软件开发基本活动

围绕着变更管理这个轴,不断转动轮子

可行性分析 做不做?

需求分析 做什么?

系统分析与设计 怎么做?

详细设计 怎么做?

image.png

应该就是各种设计图,比如UML类图吧

精通各种编程语言

精通各种编程语言

测试

"给你一台冰箱,如何测试?"

常规 + 机端 = 通过

部署

维护

改正性,适应性,完善性,预防性

管理活动贯穿整个周期

不变的是变化

需求捕获与分析

幽默一则:客户,分析人员,设计人员,开发人员对需求的理解


客户,分析人员,设计人员,开发人员对需求的理解

需求分析的困难性

需求捕获

需求 捕获

需求捕获方法

脑图工具协助捕获

mindManager

没有不变的需求

司机和汽车

如何应对需求变更

变更请求流程

变更请求流程 变更请求表样例

需求分析前的工作

1.确定涉众和用户类型(命名,简要描述,特征,能力)
2.确定涉众代表(命名,简要描述,责任,参与)
3.项目中加入涉众代表(访谈,问卷,评审,角色扮演)
4.创建共同的构想(问题定义,系统范围,用户目标,飞功能需求前景文档)
5.采用传统的需求捕获技术对需求进行捕获
6.组建需求分析队伍(少量,有问题域知识)

需求分析时

有效的需求分析员

有效的需求分析员

1.一个有效的需求分析员需要子啊需求分析过程中和用户简历真正的伙伴关系
2.能够在错综复杂的现象中发现问题背后的问题
3.在陌生的领域内能学得更快
4.有效的需求分析员必须用自己的智慧,行动和真诚去发现需求,挖掘需求
5.要用共同的语言和用户经行交流
6.好的方法和习惯能够让需求分析更加有效

建立真正的伙伴关系

发现问题背后得问题

用共同的语言进行交流

用例设计

用例分析误区

适合做需求分析的人

需求工程

把所有与需求直接相关的活动统称为需求工程

需求工程

扩展阅读

深度解读:揭秘腾讯内部最有效的用户调研和需求分析方法

软件测试

不容忽视的测试

软件测试基本原则

有关测试的几个误区

疲于奔命捉bug

捉bug有组织有纪律

自动化捉bug

CASE

CASE工具由三个步骤组成

测试工具

应用测试工具的目的

日益强大的测试工具

提高软件质量的方法

第三方软件评测

扩展话题: 软件工程在工作中到底起多大作用?

第二章 敏捷开发

方法论来源于恐惧

软件开发的方法论

方法论源于恐惧

处于对项目的超期,成本失控等等因素的恐惧,项目经理们从以前的经验出发,制定了一些控制,监测项目的方法,技巧

重型方法

特征: 正规,严谨,开发人员具有较强的可替代性
侧重点: 计划,过程,中间产物(状态报告)
不同人员偏爱程度不同:管理者,开发人员

轻型方法

特征:迭代,重构,响应需求变化
交付物:代码,可运行的产品,测试用例
管理成本低而高效
开发人员偏爱

方法论轻重的确定

1.没有两个项目会采用完全相同的方法论
2.软件工程是非常灵活的一套方法
3.可考虑因素:项目规模和紧要性
4.提倡“刚刚好”
5.工作重点:沟通,反馈,频繁交付
6.管理目标:有效和灵活

轻重方法的融合

1.自动化技术和工具使得轻重方法之间的界限进一步模糊
2.自动化工具的同步特性支持轻型方法的迭代和重构
3.自动化工具的模型翻译和转换依赖于重型方法的详尽文档和模型
4.大型软件项目往往结合轻型方法和重型方法

瀑布模型被取代了么?

1.所有的软件开发方法论和开发模型都毫无例外地由基本开发活动构成
2.不同地方法论相互结合而非取代
3.从不同地方法论中借鉴适合自己团队地方法和工具

敏捷开发是什么

典型瀑布模型开发

典型瀑布模型开发

将开发过程分为若干活动,每个活动责任明确,活动完成地好坏直接影响着下一活动地好坏

分工明确

活动之间存在着隔阂,管理采用命令式管理,每个活动的交付物可能很多。写一行代码,弄十篇文档的夸张现象可能也有

从瀑布到车轮

从瀑布到车轮

敏捷宣言

1.个体和交互胜过过程和工具
2.可以工作的软件胜过面面俱到的文档
3.客户合作胜过合同谈判
4.响应变化胜过遵循计划

宣言落地

1.不同的敏捷方法采用的实践不同
2.响应变化 -- 快速迭代
3.客户协作--快速迭代
4.可工作的软件--持续交付
5.个体与互动 -- 站会和看板

敏捷特征

1.敏捷目标:灵活和有效
2.开发过程:快速增量迭代
3.管理风格:自组织和自管理
4.响应变化:自适应性

灵活和有效

1.更好的响应变化的需求,更快的开发进度和更高的质量
2.方法的灵活和创新
3.有效的含义

快速增量迭代

1.小步快跑:小版本,小周期
2.随时看到效果
3.收集fankui
4.随时修正
5.维持团队成员开发积极性

自组织团队

1.培养团队是关键
2.自组织与自管理
3.一个团队不只是一群人
4.成员自动自发,默契,协作,互补
5.共同的目标,共同的工作理念和文化
6.建立在团队个人能力和松散管理的基础之上

自适应性

1.需求变更可以为客户创造竞争优势
2.需求是不稳定的和全天候的
3.对需求稳定性的判断和预测很难
4.通过建立过程的自适应性来解决不可预测性
5.原地踏步式的连续适应性变化收效甚微
6.必须是增量式适应

典型敏捷开发方法

SCRUM

团队成员像打橄榄球一样迅速、富有战斗激情、人人你争我抢 地完成同一个目标

SCRUM 开发模型

Product backlog产品需求,具有优先级

Sprint Backlog 拆分出的小任务,等待开发人员主动来领取。

产品负责人

产品负责人

SCRUM master

SCRUM master

开发团队

开发团队

每日站会

每日站会
  1. 每天早上
  2. 15分钟左右
  3. 没人必须发言
    3.1 昨天已做的
    3.2今天要做的
    3.3 遇到的问题
  4. 更新看板

各式看板

各式看板

计划纸牌

计划纸牌

SCRUM总结

  1. 规定了一个非常简单的开发流程
  2. 以团队的自主自发为基础
  3. 主要团队成员应跨职能,全职
  4. 快速,迭代,增量的开发出可交付系统
  5. 可以融合其他敏捷方法中的工程技术手段。
上一篇 下一篇

猜你喜欢

热点阅读