1引言

更多信息查看https://www.jianshu.com/u/ab8c0a646fac

1.1软件的特点

抽象、不会磨损、可移植、复杂、昂贵

1.2软件危机

成本估算不准确
用户通常不满意
软件质量不可靠
软件维护性差
没有文档
软件应用快于发展

问题1:
请用你所见、所闻、所经历的事例来描述软件危机的现象或表现。
答：

1. 由于需求的不明确，立项想做的软件功能过于庞大，能力略有不足，没有明确的目标，成员之间的合作不清晰，花费了大量时间经历最终没能产生想要的结果。
2. 美国银行信托软件系统开发案
   美国银行1982年进入信托商业领域，并规划发展信托软件系统。项目原订预算2千万美元，开发时程9个月，预计于1984年12月31日以前完成，后来至1987年3月都未能完成该系统，期间已投入6千万美元。美国银行最终因为此系统不稳定而不得不放弃，并将340亿美元的信托账户转移出去，并失去了6亿美元的信托生意商机。

问题2:软件工程与计算机科学有什么不同
我觉得是不一样的，软件科学更像是一门科学，它研究的是如何提高程序的运行效率，用更少的代码写出更高效的程序，而软件工程更像是一门社会科学，它研究的是如何将软件的编写者——人有机的结合起来，开发出对用户更友好，更易于使用的软件

1.3职业道德

公众感：与公众利益一致
客户和雇主：与公众利益一致的前提下，保证客户和雇主的利益
产品：达到行为标准
判断力：公正、独立
管理：合乎道德
职业感：尊重公众利益
同事：公平对待
自己：学习，讲道德

问：
你是否经历过、见过、闻过软件伦理方面的案例，或者你是否曾经因某个软件团体好的职业道德与从业规范而受益过、或因某个软件团体好的职业道德与从业规范而受损过，请分享你的故事。
答：
类似换脸软件已推出数年，也曾引发一些争议，过去的关注点多是对明星肖像权的侵权方面，但越来越多的人意识到自己的脸或自制视频可任由软件开发者运用或改动，这强烈冲击着人们的心理底线，从而引发公众担忧个人权利的共鸣。

问：
你认为单位分配给每一位员工的工作邮箱是属于个人还是单位，单位是否有权查看员工的工作邮箱。
你的观点请说明你的观点。
答：
工作单位分配给，员工的工作邮箱是属于单位的，工作单位有权查看工作邮箱里的邮件，但员工个人也需要做到仅仅在工作邮箱中谈论与工作相关的事情

2软件过程

2.1软件过程

人员：客户（提供开发经费）、开发人员、用户

工作流：
需求工作流：需求文档

分析工作流：规格说明文档：目标产品将要做什么

设计工作流：设计文档：具体设计什么产品，先是架构设计，再是具体设计

实现与集成工作流：编码实现：源代码和注释，

测试工作流：基于执行测试（运行代码）和非执行测试（不运行代码、文档）

交互维护：纠错性维护、完善性维护和适应性维护

退役阶段：不要了

2.2软件测试

软件开发人员和质量保障人员共同完成

非执行测试

测试文档和代码（不执行）

测试方法:
走查，审查

基于执行测试

测试代码（执行）

2.2.1测试物

正确性
实用性：被满足的程度
可靠性
健壮性：
性能：

选择：
1.软件测试是破坏性的

问：
测试团队和开发团队是否应该处在一个团队中，应该是怎样一种管理结构br> 答：
不应该在一个团队中，应该是两个相互独立的团队。程序员团队一般在自己检查时，无法发现自己的错误。相反测试团队可以更加客观。

3软件需求

3.1什么是需求

确定客户需要什么而不是客户想要什么。

能力水平层次：
1.被动型
2.主动型
3.引领型

3.2获取需求

1.准备阶段：收集什么，方式、时间地点人物
2.需求抽取、记录、分析
3.需求文档：功能性需求（下定单功能），非功能性需求（性能）
4.需求确认：开发方和需求方都认可

3.2快速原型

快速获取业务需求的方法和手段
是目标软件系统的一个模型，不是实现一个系统

看老师的视频演示，感觉就是一点一点慢慢来，启发客户

问：
你见过或做过软件系统的快速原型吗，请描述一下，快速原型对软件系统的分析与设计有帮助吗br> 答：
有的，在进行游戏开发的过程中，经常要用到快速原型来确定交互方式和玩法框架。快速原型对需求的明确有着重要的作用，有利于高效地确定需求。

4面向对象范型

模块：一系列计算机语句，有边界标识符，一个类，一个方法

模块内部：内聚
模块之间：耦合

4.1内聚（cohesion）

模块内部的交互程度

高内聚好

从高到低：（好到坏）
信息性内聚
功能性内聚
通信性内聚
过程性内聚
时间性内聚
逻辑性内聚
偶然性内聚

偶然性内聚：不同执行时，所做事情毫不相干，所以需要拆分成多个模块

逻辑性内聚：接口理解困难，难以划分识别

时间性内聚：相同的时间内完成不同操作，这些操作之间没有联系，但和其他模块有较强的关联度，所以不可重用

过程性内聚：不同操作按照指定顺序执行，不可重用

通信性内聚：不同的操作有相同的输入或者输出（二选一），但中间执行的内容完全不同，弱重用性

功能性内聚：只具有一个功能，一个操作，较强的可重用，较小的回归错误。更容易扩展

信息性内聚：有自己的接口，自己的代码，但都基于相同的数据

问：
哪些可以作为一个模块，哪些不能
可以：函数，类，方法
不可以：集合

4.2耦合(coupling)

模块之间的联系

低耦合好

从到低到高（好到坏）
数据耦合
印记耦合
控制耦合
公共耦合
内容耦合

内容耦合：一个模块可以直接访问另一个模块的内部数据 public

公共耦合：两个模块存取相同的公共变量

控制耦合：一个模块向另一个模块传递控制信息，会造成逻辑性内聚（例如，参数是求平均值或求最高值），需要拆分

印记耦合：对于传入的集合（包含多数据），只对数组内部部分信息进行操作

数据耦合：所有传入的数据都被使用

4.3数据分装与信息隐藏

功能在模块内部实现，不对外表现，将信息隐藏起来，对外提供访问的接口（类似于类）

设计抽象，类似只写接口类，先不考虑实现

问：类是抽象数据类型，抽象数据类型不只有类，例如数据结构也是抽象数据类型

4.4类的继承

类就是支持抽象的数据类型
对象就是类派生出来的实例

例如：
人有属性，身份证…
学生也有属性，学号,身份证…

学生继承了人

人又称基类、父类、超类
学生又称子类、派生类

4.5类的聚合

一类聚合关系Aggregation:

一个电脑类聚合了cpu类，键盘类等等，键盘等类是可以拆分出来单独存在（白色菱形表示）

一类聚合关系Composition

一个windows窗口类聚合了Textarea类，Menu类等等，这些类是不可以拆分出来单独存在（黑色菱形表示）

4.6类的关联Association

关联关系有个动词表示关系
Student—–take—->Course

Brrower—–Borrows/returns/renews/reserves———->Book

关联关系要将数量关系表达出来

多重关系：1 —–> 0…*

结构化范型是要进行不同的操作，转账，存款，数据和操作是分离的，没有放在一起
但面向对象范型是分装起来的，只提供对外接口
合同设计，又称职责驱动设计
例子：母亲节送花
我只需要告诉花店，花店会为我们做好一切工作。

4.9UML

Unified modeling language
具体使用在第五章

5面向对象分析

用例建模：有哪些功能，不考虑顺序，获得用例图
类建模：实体类以及实体类的属性，获得类图
动态建模：关于实体类的操作，获得状态图

5.1用例建模

棉鞋功能需求
包括：参与者，用例，参与者和用例的关系

参与者：人，外部设备 例如：学生
用例：描述系统做什么，但不知怎么做，例如：下定单，借书
关联：用一条直线表示

5.2用例图

代理关系：agency

包含关系include：

考试不及格要重考，make up exam

5.3类图

实体类和他们之间的关系
类，类的结构，类之间的关系

两种方法
1.名词抽取
2.CRC(Class-Responsibility-Collaboration)

5.3.1名词抽取

第一步：简要描述问题
第二步：从描述中抽取名词，作为候选类

5.4动态建模

生成状态图，是对类图的补充，
状态图是动态建模的产物
每一个状态图对应一个类
不是所有的类都需要状态图

8维护

发布后的任意改动称为维护

8.1维护的必要性

第一种维护：纠错维护：才占总维护量的17.5%
第二种维护：客户要求提高性能（完善性维护）60%
第三种维护：适应性维护，如改变运行环境 18%

8.2对维护人员的要求

软件的总成本发生在维护阶段75
维护难度最大，而维护人员的工资和水平不高

9软件生命周期模型

没有一个软件舍命周期适合所有的软件项目。
需求—->分析—->实现

开发人员犯错，客户需求改变

统一软件过程的特性：
第一个：迭代：先开发第一个版本，再开发第二个版本，以此递进
第二个：增量：划分为多个构件，首先开发最重要的方面例如先考虑7个最重要的需求，再考虑7个次要的需求

实际中，迭代和增量是同时进行的，一个软件分为多个构件，每个构件多个版本迭代开发。

快速模型

快速原型可能取代规格说明阶段，但是不能取代设计阶段
快速模型必须快速的建立

同步与稳定模型

只有微软一家使用

没有明确的客户，需求来于有潜在客户。分为3到4个模块，并行开发。每天结束前进行同步，模块的集成和测试，之后不对该模块进行改动

优势：需求满足，集成模块

瀑布模型

文档驱动
缺点：产品不满足客户需求，因为中途客户没有办法介入修改业务功能。只有开发结束后，客户才可提出更改

螺旋模型

在瀑布模型或者快速模型的基础上，在每一个阶段开始前进行风险分析，风险过大，停止
项目开始之前风险分析–>需求调研—->需求验证—>风险分析—->分析—->分析验证—>风险分析—>实现

优势：风险驱动降低风险
缺点：适合大型的内部系统，要求开发人员分析风险和处理风险

来源：是文迪啊呀