1.1 软件 = 程序 + 软件工程
- 作为程序员，大家都知道有“程序 = 数据结构 + 算法” 。确实，程序的确是建立在数据结构基础上的一些算法。
- 一些名词：
①软件架构（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软件工程是什么
- 定义：软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。
- 软件工程的目标：创造足够好的软件。即没有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 代码复审
定义：看代码是否在“代码规范”的框架内正确的解决了问题
- 自我复审
- 同伴复审
- 团队复审
代码复审核查表如下：
- 代码符合需求和规格说明吗？
- 代码设计是否周全？
- 代码可读性如何？
- 代码容易维护吗？
- 是否遵从项目设计模式（例如MVP、MVC）
- 是否符合代码规范？
- 有没有对异常进行处理（例如阶乘时输入负数）？
- 边界条件是否处理？
- 代码效能如何（利用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中称为规程或者工作流程。简介如下：
- 业务建模（Business Modeling）：通常利用UML（统一建模语言）描述用户的活动。其结果同城生成一个用例（User Case）
- 需求（Requirement）：有了用例过后，开发人员和用户需要分析软件系统需要哪些功能来满足用户需求。其结果形成需求分析文档。
- 分析和设计（Analysis & Design）：将需求转化为系统的设计（设计系统架构等）。其结果是团队成员需要知道系统要有哪些子系统、模块，他们之间关系如何。
- 实现（Implementation）：工程师按计划实现上一步提出的设计，将开发出的组件（负责的那部分）连同单元测试模块提交到系统中。最后整合各个组件。
- 测试（Testing）：验证组件、组件之间交互的正确性。
- 部署（Deployment）：生成最终版本并发布给用户。
- 配置和变更管理（Configuration andChange Management）：负责管理RUP各个阶段产生的各个工作结果。
- 项目管理：管理风险。
6 微软解决方案框架（Microsoft Solution Framework，MSF）团队模型
MSF
7 需求分析
7.1 软件需求
7.1.1 获取和引导需求
7.1.2 分析和定义需求
7.1.3 验证需求
- 确认用户需要这些功能
- 产品的功能性需求：产品需要实现哪些工程。
- 产品开发过程的需求：要求产品开发过程中必须满足某些约束条件，例如，开发过程中必须产生某种类型的文档，必须在某个时间点达到某种状态。
- 非功能行需求：也叫“服务质量需求”，功能反应时间等，友好的UI等。
- 综合需求：有时不一定单单的一个软件模块就可以满足，例如：“购物网站需要在24小时内把货物发送到用户手中”，该需求牵涉到软件系统、物流系统等。
7.2 软件产品的利益相关者
- 分析软件需求的时候需要考虑以下的利益相关者。
- 用户：直接使用软件的人。例如打车软件的使用者有“乘客”、“司机”。
- 顾客：购买这个软件的人。这些人不一定是软件的直接用户，但却直接利益相关。例如代表甲方向团队提需求的人。
- 软件工程师：软件的各种约束会影响开发效率，所以应当征求其意见。
7.3 获取用户需求-用户调查
如何去有效的收集用户需求，有以下几种常用的用户调用方法：
-
焦点小组模式：找到一群目标用户的代表，加上利益相关者来讨论用户向要什么。
焦点小组 -
深入面谈模式：通过详细的面谈，广泛而深入的了解用户的心理、背景、需求等。通常是一对一的采访。效果往往取决于团队成员的能力。此类研究主要探究用户在使用软件时遇到哪些苦难，需要怎样的改进。
深入面谈 - 卡片分类模式：通常团队收到的需求都是杂乱无章的。将需求写在卡片上，对卡片需求进行讨论->明确定义->归类->排序，这可以帮助我们统一大家对软件需求的认识。
- 用户问卷调查模式：
- A/B测试：如果你的产品已经有一些用户在用，你想对用户界面做一些改进，但是又不知道到底有多少用户会喜欢新的界面，怎么办？这时候可以利用A/B测试的方法，将改进的UI现在5%-10%的用户上运行测试，然后收集数据得出结论。
- 快速原型调研：先设计原型，让用户看。
总结
7.4 竞争性需求分析的框架
想竞争就一定要创新！
- 参考NABCD模型
- N（Need，需求）
创意能解决什么用户需求？ - A（Approach，做法）
- 最好是独特的做法
技术：人脸识别？大规模数据处理？
成本：能找到便宜的资源来维护网站？
人脉：
- B（Benefit，好处）
能给客户/用户带来什么好处？ -
C（Competitors，竞争）
竞争 - D（Delivery，推广）
7.5 功能的定位和优先级
开发之前问自己两个问题：①你为啥在做这个功能而不是另一个功能？②为什么做这个产品而不是别的产品？
功能分析四象限
以一个英汉词典APP来说明上图
- 杀手功能：OCR文字识别技术，可以在屏幕上取词解释，拥有独家权威词典，等等。
- 外围功能：良好的界面设计，在各个平台上都能运行。
- 必要需求：单词短语释义的准确性（如果达不到这一点，用户就不会来使用）。
- 辅助需求：可以做各种皮肤（这也许能让一些用户更喜欢这个软件，但不是决定因素）。
7.6 分而治之
每个项目需要在一段时间内完成诸多任务，满足用户的需求，实现团队的目标，但从哪里入手？这个时候需要一个角色站出来领导大家。这就是PM项目经理。
采用WBS：Work Breakdown Structure方法，一层一层把大型交付件分割为小型交付件。
WBS例子
