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

 
 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例子