1.1 软件 = 程序 + 软件工程

1. 作为程序员，大家都知道有“程序 = 数据结构 + 算法” 。确实，程序的确是建立在数据结构基础上的一些算法。
2. 一些名词：
   ①软件架构（Software Architecture）：软件系统各个方面的设计，常用的有分层架构，其架构如下
   分层架构

• 表现层（presentation）：用户界面展示与一些交互操作。
• 业务层（business）：实现一些业务逻辑。
• 持久层（persistence）：提供数据，SQL语句放在这一层。
• 数据库（database）：保存数据。
  优点在于解耦明确
  ②软件设计与实现（Software Design, Implementation and
  Debug）。
  ③配置管理（Software Configuration Management）。
  ④软件测试（Testing）：用来保证软件的正确性、完整性、安全性和质量。
  ⑤需求分析（Requirement Analysis）：软件开发的第一步，需要完成的内容一般有项目背景及目标、运行环境、数据库描述、功能性需求描述（例如登录注册）、非功能性需求描述（用户界面需求、软件环境需求）等。
  ⑥软件维护（Software Maintenance）：在出问题的时候打补丁。
  ⑦生命周期（Software Life Cycle，SLC）：软件团队从需求分析开始到设计（软件架构）、实现（写程序，即写数据结构和算法）、软件测试，到最后发布软件以及软件的维护。

1.2软件工程是什么

1. 定义：软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。
2. 软件工程的目标：创造足够好的软件。即没有BUG的软件。BUG的存在会直接影响用户满意度、可靠性。那什么是BUG（缺陷）呢？简单来说就是软件的行为和用户的期望不一样。

2.1单元测试

目的：如何保证自己写的代码的质量。
测试方法：利用JUnit库进行测试，其提供了各种方法进行单元测试。

• 判断程序结果是否与期望一致。

//测试方法
    @Test
    public void factorial() throws Exception {
//判断是否相同
        assertEquals(1,new Math().factorial(0));
    }

• 判断是否程序超时,如果程序运行时间超过2秒便不会通过测试

    @Test(timeout = 2000)
    public void sort() throws Exception{
        int a[] = new int[50000];
        Random random = new Random();
        for(int i = 0;i<a.length;i++){
            a[i] = random.nextInt(a.length);
        }
        new Sort().sort(a);
    }

2.2 性能分析

性能分析在Java中一般采用JProfiler，对于该软件我目前没有进行了解（主要没找到破解版。。。）。

2.3 PSP（Personal Software Process）

• 个人开发流程，下图给出整个流程
  个人开发流程
  注意：往往具有一定开发经验的开发人员，会在 需求分析 与 测试上画多一点时间，而编码（Coding）上时间用的较少。

3.1 软件工程师的成长

• 积累软件开发相关的知识，提升技术技能（对具体技术的掌握例如Java）
• 积累问题领域的认识和经验
• 对通用的软件设计思想和软件工程思想的理解。
• 提升职业技能：自我管理的能力、交流能力、团队合作能力
• 实际成果：你参与的项目用户评价如何，你在其中起什么作用。软件开发的工作量和质量由以下几点来衡量：①代码行数②花了多久时间③质量如何（BUG多吗？）

3.2 软件工程师的职业发展

就软件工程师而言，有很多证明个人能力的办法和模型：

• 考取证书：例如CCF

4.1 代码规范

目的是为了大家都能看懂，毕竟在现在程序往往不是一个人完成。保证简明、易读、无二义性。

4.2 代码风格规范

4.2.1 缩进

采用4个空格而不是tab的方式，因为tab在不同的情况下会显示不同的长度，干扰阅读体验。

4.2.2 行宽

限制在100字符以内

4.2.3 括号

在复杂的条件表达式中，利用括号表达优先级。

4.2.4 断行

建议采用下列格式

if (condition)
{
DoSomething();
}
else
{
DoSomethingElse();
}

但我一般用下面这个各式

if (condition) {
DoSomething();
} else {
DoSomethingElse();
}

4.2.5 命名

对于java而言：

• 包：域名反转做包名，例如com.jacob
• 类：每个单词首字母大写。
• 方法：第一个单词首字母小写，其余大写
• 属性：第一个单词首字母小写，其余大写
• 常量：所有字母都大写

4.3 代码复审

定义：看代码是否在“代码规范”的框架内正确的解决了问题

• 自我复审
• 同伴复审
• 团队复审
  代码复审核查表如下：

1. 代码符合需求和规格说明吗？
2. 代码设计是否周全？
3. 代码可读性如何？
4. 代码容易维护吗？
5. 是否遵从项目设计模式（例如MVP、MVC）
6. 是否符合代码规范？
7. 有没有对异常进行处理（例如阶乘时输入负数）？
8. 边界条件是否处理？
9. 代码效能如何（利用Jprofile）？

5.1 团队模式

5.1.1 主治医师模式

• 首席程序员：负责主要模块的设计和编码
• 其他程序员：从各种角度来支持他
  不过该模式在学校一般会变成一神带几坑

5.1.2 明星模式

5.1.3 社区模式

每个人参与自己感兴趣的项目，贡献力量。
好处在于：“众人拾柴火焰高”

5.1.4 业余剧团模式

• 在团队中，不同的人挑选不同的角色。

5.1.5 功能团队模式

• 很多软件公司的团队模式最后都转化为功能团队模式，简而言之就是具备不同能力的同事们平等协作，共同完成一个功能。

功能团队模式

5.2 开发流程

• 一群人在一起做软件开发，总是要有一些方式和方法

5.2.1 瀑布模型

• 当软件行业还在年幼的时期时，它从别的行业借鉴了不少经验和模型。在那个“硬”的时代，产品大都遵循分析-设计-实现-销售-维护。这个模型描述的是单向的、不可逆的生产过程。
  相邻步骤回溯的瀑布模型

5.2.2 生鱼片模型

• 各模块像生鱼片那样部分重叠（解决了各个步骤之间分离的缺点）

  
  生鱼片模型
• 那么问题来了，到底是哪些部分重叠呢？

5.2.3 Rational Unified Process（统一流程）

• 重计划，重事先设计。
• 要完成一个复杂的软件项目，团队的各个成员要在不同的阶段做不同的事情，这种不同类型的工作在RUP中称为规程或者工作流程。简介如下：

1. 业务建模（Business Modeling）：通常利用UML（统一建模语言）描述用户的活动。其结果同城生成一个用例（User Case）
2. 需求（Requirement）：有了用例过后，开发人员和用户需要分析软件系统需要哪些功能来满足用户需求。其结果形成需求分析文档。
3. 分析和设计（Analysis & Design）：将需求转化为系统的设计（设计系统架构等）。其结果是团队成员需要知道系统要有哪些子系统、模块，他们之间关系如何。
4. 实现（Implementation）：工程师按计划实现上一步提出的设计，将开发出的组件（负责的那部分）连同单元测试模块提交到系统中。最后整合各个组件。
5. 测试（Testing）：验证组件、组件之间交互的正确性。
6. 部署（Deployment）：生成最终版本并发布给用户。
7. 配置和变更管理（Configuration andChange Management）：负责管理RUP各个阶段产生的各个工作结果。
8. 项目管理：管理风险。

6 微软解决方案框架（Microsoft Solution Framework，MSF）团队模型

MSF

7 需求分析

7.1 软件需求

7.1.1 获取和引导需求

7.1.2 分析和定义需求

7.1.3 验证需求

• 确认用户需要这些功能
• 产品的功能性需求：产品需要实现哪些工程。
• 产品开发过程的需求：要求产品开发过程中必须满足某些约束条件，例如，开发过程中必须产生某种类型的文档，必须在某个时间点达到某种状态。
• 非功能行需求：也叫“服务质量需求”，功能反应时间等，友好的UI等。
• 综合需求：有时不一定单单的一个软件模块就可以满足，例如：“购物网站需要在24小时内把货物发送到用户手中”，该需求牵涉到软件系统、物流系统等。

7.2 软件产品的利益相关者

• 分析软件需求的时候需要考虑以下的利益相关者。

1. 用户：直接使用软件的人。例如打车软件的使用者有“乘客”、“司机”。
2. 顾客：购买这个软件的人。这些人不一定是软件的直接用户，但却直接利益相关。例如代表甲方向团队提需求的人。
3. 软件工程师：软件的各种约束会影响开发效率，所以应当征求其意见。

7.3 获取用户需求-用户调查

如何去有效的收集用户需求，有以下几种常用的用户调用方法：

1. 焦点小组模式：找到一群目标用户的代表，加上利益相关者来讨论用户向要什么。
   焦点小组
2. 深入面谈模式：通过详细的面谈，广泛而深入的了解用户的心理、背景、需求等。通常是一对一的采访。效果往往取决于团队成员的能力。此类研究主要探究用户在使用软件时遇到哪些苦难，需要怎样的改进。
   深入面谈
3. 卡片分类模式：通常团队收到的需求都是杂乱无章的。将需求写在卡片上，对卡片需求进行讨论->明确定义->归类->排序，这可以帮助我们统一大家对软件需求的认识。
4. 用户问卷调查模式：
5. A/B测试：如果你的产品已经有一些用户在用，你想对用户界面做一些改进，但是又不知道到底有多少用户会喜欢新的界面，怎么办？这时候可以利用A/B测试的方法，将改进的UI现在5%-10%的用户上运行测试，然后收集数据得出结论。
6. 快速原型调研：先设计原型，让用户看。

总结

7.4 竞争性需求分析的框架

想竞争就一定要创新！

• 参考NABCD模型

1. N（Need，需求）
   创意能解决什么用户需求？
2. A（Approach，做法）

• 最好是独特的做法
  技术：人脸识别？大规模数据处理？
  成本：能找到便宜的资源来维护网站？
  人脉：

3. B（Benefit，好处）
   能给客户/用户带来什么好处？

4. C（Competitors，竞争）

   
   竞争
5. D（Delivery，推广）

7.5 功能的定位和优先级

开发之前问自己两个问题：①你为啥在做这个功能而不是另一个功能？②为什么做这个产品而不是别的产品？

功能分析四象限

以一个英汉词典APP来说明上图

• 杀手功能：OCR文字识别技术，可以在屏幕上取词解释，拥有独家权威词典，等等。
• 外围功能：良好的界面设计，在各个平台上都能运行。
• 必要需求：单词短语释义的准确性（如果达不到这一点，用户就不会来使用）。
• 辅助需求：可以做各种皮肤（这也许能让一些用户更喜欢这个软件，但不是决定因素）。

7.6 分而治之

每个项目需要在一段时间内完成诸多任务，满足用户的需求，实现团队的目标，但从哪里入手？这个时候需要一个角色站出来领导大家。这就是PM项目经理。
采用WBS：Work Breakdown Structure方法，一层一层把大型交付件分割为小型交付件。

WBS例子