• PSP2.1统计表
  

• 个人分支的GIT统计报告
  10张图，共计49次commit

• 自认为最得意/或有价值/或有苦劳的工作清单，含简短说明（一句话）
  1、负责制定前端代码的分类内容，提前完成一些组件、功能模块以供其他组员使用
  2、完成购物车列表组件，由于没有现成的第三方组件可以使用，自己专研完成了。
  3、二次封装RN的fetchAPI，实现超时取消功能
  4、前端小组有人离职，接手他的烂摊子
  5、独自完成与后端的API测试

• 个人的技术类、项目管理类博客清单（只需要名称与 url ）

react-native安卓开发遇到的坑

• 使用ECB实现make reservation 用例的详细设计（包含用例简介，顺序图，类图）
  1.用例简介
  make reservation系统的用例图如下：

  主用例：{Find hotel, Make reservation, Manage basket, Pay}
  子用例：{Select city location, Select check-in date, Choose hotel, Choose room type, Confirm reservation, Select credit cards, Select location, Sort list of hotels, Specify number of people and rooms, Enter name and email}

  顺序图如下：

  uml类图如下：

• 将逻辑设计类图映射到实际项目框架的包图。用树形结构表述实现的包和类

  包图如下：

• 描述软件架构与框架之间的区别与联系

一.软件框架
软件框架是面向领域（如ERP、计算领域等）的、可复用的“半成品”软件，它实现了该领域的共性部分，并提供了一些定义良好的可变点以保证灵活性和可扩展性。也就是说软件框架是领域分析结果的软件化，是领域内最终应用的模板。
开发人员通过软件框架行为调整机制，将领域中具体应用中所特有的软件模块绑定到该软件框架的可变点上，从而得到了最终的应用系统，这个过程称为软件软件框架的例化，软件框架的存在使得开发人员将主要的精力放在系统所特有的模块的开发上，从而提高软件的生产率和质量。
软件框架的行为调整机制是指如何针对具体的应用调整该框架的可变部分、如何在可变点加入特定应用模块所采用的方法和规则。
二.软件架构
软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。
软件架构并不仅仅关注软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解、经济以及技术的限制和权衡等。
当软件工程具一定规模时，软件开发不完全是以数据结构+算法的形式存在，而是基于技术选择和用户需求等众多因素将软件“分而治之”，架构师的主要任务是将软件分割成不同的模块，并定义模块之间的接口。
三.两者联系
1）为了尽早验证架构设计，或者处于支持产品线开发的目的，可以将关键的通用机制甚至整个架构以框架的方式进行实现；
2）业界（及公司内部）可能存在大量可供重用的框架，这些框架或者已经实现了软件架构所需的重要架构机制，或者为未来系统的某个子系统提供了可扩展的半成品，所以最终的软件架构可以借助这些框架构造。

• 以你的项目为案例
  • 绘制三层架构模型图，细致到分区
  • 结合你程序的结构，从程序员角度说明三层架构给开发者带来的便利
    1.开发人员可以只关注整个结构中的其中某一层；
    2.可以降低层与层之间的依赖；
    3.利于各层逻辑的复用。
    4.项目结构更清楚，分工更明确，有利于后期的维护和升级
• 研究 VUE 与 Flux 状态管理的异同
  Flux状态管理：
  Flux 通过强制单向数据流来解决大项目中数据流混乱问题，但官方的依赖包里，核心只有一个dispatcher和一些语法糖，Flux可以说更像是一种设计模式，而不是一个具体的框架或者库。
  它分为四层：view视图层、action层、dispatcher派发层、store仓库层 数据流动：view——>action——>dispatcher——>store返回——>dispatcher——>view(接收的方法：register（）)
  Flux 使 Views 查询 Stores（而不是 Models），用户交互触发的 Actions 被提交到一个 Dispatcher 中。当 Actions 被派发后，Stores 将会随之更新自己并且通知 Views 进行修改。这些 Store 当中的修改会进一步促使 Views 查询新的数据。即在相对独立的组件中，action -> state -> view 的单向数据流能得到保证。
  Vue状态管理：
  Vuex 是一个专为 Vue.js 应用程序开发的状态管理模式。它采用集中式存储管理应用的所有组件的状态，并以相应的规则保证状态以一种可预测的方式发生变化。
  数据流动：vueComnent——>(dispatch)Action——>（commit）——>Mutations——>（mutate）State——>（render）VueComponent
  与 flux 对比，最大的区别是Vuex把action细分成了action和mutation，分别应对异步场景和同步场景，由store自身充当dispatcher（负责注册/分发action/(mutation)。即如果把 action 和 mutation 看作一层（Flux里的action），二者结构完全一致。

• 练习文档编写
  • 选择一个你喜欢的 移动App 或 其中某业务
  • 参考 Asg_RH 文档格式 编写软件描述
  • 文档要包含一个业务的完整过程

我们组选择的是建模练习文档是 鲨鱼记账APP

• 建模要求包括（用例图、XX业务或用例的活动图、XX领域模型、XX对象的状态图、XX场景的系统顺序图与操作协议）
  用例图： 记账活动图： 记账领域模型： 记账状态图： 记账系统顺序图：
• 建模者答案：
  • 收集建模者答案URL
  • 建模者不能是本团队成员（至少有一个答案）
  • 给建模者给出评价与建议

（1）使用UML State Model

• 建模对象：参考Asg_RH 文档， 对 Reservation/Order 对象建模。
• 建模要求： 参考练习不能提供足够信息帮助你对订单对象建模，请参考现在 定旅馆 的旅游网站，尽可能分析围绕订单发生的各种情况，直到订单通过销售事件（柜台销售）结束订单。

（2）研究淘宝退货流程活动图，对退货业务对象状态建模

• a. 阅读 Asg_RH 文档，按用例构建领域模型。
  • 按 Task2 要求，请使用工具 UMLet，截图格式务必是 png 并控制尺寸
  • 说明：请不要受 PCMEF 层次结构影响。你需要识别实体（E）和 中介实体（M，也称状态实体）
    • 在单页面应用（如 vue）中，E 一般与数据库构建有关， M 一般与 store 模式 有关
    • 在 java web 应用中，E 一般与数据库构建有关， M 一般与 session 有关

• b. 数据库建模(E-R 模型)
  • 按 Task 3 要求，给出系统的 E-R 模型（数据逻辑模型）
  • 建模工具 PowerDesigner（简称PD） 或开源工具 OpenSystemArchitect
  • 不负责的链接 http://www.cnblogs.com/mcgrady/archive/2013/05/25/3098588.html
  • 导出 Mysql 物理数据库的脚本
  • 简单叙说 数据库逻辑模型 与 领域模型 的异同

-- +---------------------------------------------------------
-- | MODEL       : lesson7
-- | AUTHOR      : chenwen
-- | GENERATED BY: Open System Architect
-- +---------------------------------------------------------
-- | WARNING     : Review before execution
-- +---------------------------------------------------------

-- +---------------------------------------------------------
-- | CREATE
-- +---------------------------------------------------------
CREATE TABLE `Destination`
(
cityname VARCHAR(30) NOT NULL,
PRIMARY KEY (cityname)
);

CREATE TABLE `Traveller`
(
User_Id INTEGER NOT NULL,
email VARCHAR(30) NOT NULL,
name VARCHAR(30),
phoneNumber VARCHAR(30) NOT NULL,
cityname VARCHAR(30) NOT NULL,
PRIMARY KEY (User_Id)
);

CREATE INDEX idxTraveller1 ON Traveller
(
cityname
);

CREATE TABLE `CreaditCard`
(
Card_id INTEGER NOT NULL,
count INTEGER NOT NULL,
Holder VARCHAR(30) NOT NULL,
User_Id INTEGER NOT NULL,
PRIMARY KEY (Card_id,User_Id)
);

CREATE TABLE `Hotel`
(
hotel_id INTEGER NOT NULL,
HotalName VARCHAR(30) NOT NULL,
cityname VARCHAR(30) NOT NULL,
PRIMARY KEY (hotel_id)
);

CREATE INDEX idxHotel1 ON Hotel
(
cityname
);

CREATE TABLE `Room`
(
Room_Id INTEGER NOT NULL,
roomType VARCHAR(30),
PRIMARY KEY (Room_Id)
);

CREATE TABLE `SelectedHotel`
(
Hotel_id INTEGER NOT NULL,
HotelName VARCHAR(30) NOT NULL,
PRIMARY KEY (Hotel_id)
);

CREATE TABLE `Time`
(
Time_Id INTEGER NOT NULL,
start_time VARCHAR(30) NOT NULL,
end_time VARCHAR(30) NOT NULL,
Hotel_id INTEGER NOT NULL,
PRIMARY KEY (Time_Id)
);

CREATE TABLE `OrderForm`
(
Order_Id INTEGER NOT NULL,
User_Id INTEGER NOT NULL,
PRIMARY KEY (Order_Id,User_Id)
);

CREATE TABLE `SelectedHotel_OrderForm`
(
Hotel_id INTEGER NOT NULL,
Order_Id INTEGER NOT NULL,
PRIMARY KEY (Hotel_id,Order_Id)
);

数据库逻辑模型 与 领域模型 区别：
1、领域模型：就是从现实世界到信息世界的第一层抽象，确定领域实体属性关系等，使用E-R图表示，E-R图主要是由实体、属性和联系三个要素构成的。

2、逻辑模型：是将概念模型转化为具体的数据模型的过程，即按照概念结构设计阶段建立的基本E-R图，按选定的管理系统软件支持的数据模型（层次、网状、关系、面向对象），转换成相应的逻辑模型。这种转换要符合关系数据模型的原则。目前最流行就是关系模型（也就是对应的关系数据库）

逻辑模型是系统设计，以及实现的一部分，描述的是对用户需求在技术上的实现方法。用户不需要关心系统的逻辑模型，但是会关注领域模型，因为领域模型反映的是问题域的相关业务概念以及其关系，领域模型是用户业务描述的高度抽象，来源于业务需求的描述，可以帮助需求分析人员更好的理解业务需求。

1、用例建模

• a. 阅读 Asg_RH 文档，绘制用例图。 按 Task1 要求，请使用工具 UMLet，截图格式务必是 png 并控制尺寸

• b. 选择你熟悉的定旅馆在线服务系统（或移动 APP），如绘制用例图。并满足以下要求： 对比 Asg_RH 用例图，请用色彩标注出创新用例或子用例 尽可能识别外部系统，并用色彩标注新的外部系统和服务

红色为创新用例，绿色为外部系统

• c. 对比两个时代、不同地区产品的用例图，总结在项目早期，发现创新的思路与方法

确定主功能后，需要揣摩用户使用产品时的心理和需求究竟是什么，从而发现新功能；比如去哪儿就在筛选酒店方面，做出了进一步过滤，只过滤出顾客需要的酒店，减少顾客浏览、选择酒店需要花费的时间，还有到店付，到店付可以让顾客实地考察后才决定是否真的住下。

• d. 请使用 SCRUM 方法，在（任务b）用例图基础上，编制某定旅馆开发的需求 （backlog）

2、业务建模

• a. 在（任务b）基础上，用活动图建模找酒店用例。简述利用流程图发现子用例的方法。 使用流程图时，对每一个状态都思考这个状态下会做什么，如果有多个操作复合起来，那就能发现子用例。
• b. 选择身边的银行 ATM，用活动图描绘取款业务流程
• c. 查找淘宝退货业务官方文档，使用多泳道图，表达客户、淘宝网、淘宝商家服务系统、商家等用户和系统协同完成退货业务的过程。分析客户要完成退货业务，在淘宝网上需要实现哪些系统用例 淘宝网需要实现：生成退款单、管理退款单、同意/不同意退款处理。

  3、用例文本编写

• 在大作业基础上，分析三种用例文本的优点和缺点

1.Brief
摘要，即一段简洁的概要，通常用在主功能场景。
优点：简洁，每个场景只有一段文字，一眼就可以读懂发生了什么。
缺点：缺乏细节，过于简单，不能对所有情况进行说明，只适合最早期的开发

2.Casual
非正式，即有多个非正式的段落文本。
优点：编写较为简便，比Brief详细,可以有多段文字来表述场景，有利于进一步认识问题。
缺点：不够正式，只是用于开发阶段，需要在后续阶段精化，不能作为最终报告产物。

3.Fully
详述，即详细地编写用例所有步骤和各种变化，同时具有补充部分，如前置条件和成功保证。
优点：非常详细，考虑了大部分情况，有严格的书写格式规范，几乎任何情况都能从中找到对应的描述。
缺点：因为非常详细，所以编写它相当耗时；在一开始的开发阶段难以考虑得足够周全。

解决方法：navigationOptions对象下的属性headerTitleStyle设置alignSelf:’center’， 一般即可解决问题，如果还未解决，需要修改your_project_name/node_modules/react-navigation/src/views/Header/Header.js文件中的title样式属性

2、ScrollView设置水平翻转时出现RDS

错误原因如下图所示 临时解决方法：
将react-native版本回退到“0.49.5”版本（在package.json里修改，修改后在project目录下执行npm install命令），0.50版本上的的Android6.0、7.0几乎都会遇到此问题（即便时最新的稳定0.54.0版本也没修复此问题）
更新：将react-native版本升级到0.54.2或更高版本可解决该问题

3、react-native-swiper组件在安卓机上设置高度无效

解决方法： 在Swiper组件外层嵌套一个View，设置View的高度即可

4、安卓下网络图片加载失败

检查以下几点：
1.Android Manifest文件设置网络连接许可android:name=”android.permission.INTERNET”
2.请求网络图片时一定要指定图片的大小（本地图片不用）
3.关键字是 uri 而不是 url ！！！！

5、安卓下使用react-native-swiper设置垂直滑动无效

horizontal={false} 没有效果，只是分页器变到了右边，但切换滑动时依旧是水平效果，而不是垂直效果。这是官方的问题。
临时解决方法步骤：
1.在 projectname/node_modules/react-native-swiper/package.json 文件里将“version”一行的版本改成 1.5.14；并在dependencies里添加 2.在 projectname/node_modules/react-native-swiper/src/index.js 添加
import { StyleSheet } from ‘react-native’
import VertViewPager from ‘react-native-vertical-view-pager’ ；
将641行开始的return语句块替换成下面的 3，还是在 projectname/node_modules/react-native-swiper/src/index.js里，将467行的
if (Platform.OS !== ‘ios’) 替换成
if (Platform.OS !== ‘ios’ && this.props.horizontal === true)

6、安卓使用react-native-swiper有时会出现RDS，报错提示是property ‘x’ of undefined

报错位置在react-native-swiper/src/index.js文件的400行左右
解决方法有两种：
第一种（优解）：将该附近代码替换成以下
第二种：使用react-native-swiper时设置autoPlay属性为{false}，生成离线包时再根据需求是否换成{true}

• 简述瀑布模型、增量模型、螺旋模型（含原型方法）的优缺点。

瀑布模型的优点：有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究，从而提高了大型软件项目开发的质量和效率。
瀑布模型的缺点：（1）开发过程一般不能逆转，否则代价太大；（2）实际的项目开发很难严格按该模型进行；（3）客户往往很难清楚地给出所有的需求，而该模型却要求如此。（4）软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心。

增量模型的优点：（1）采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源；（2）如果核心产品很受欢迎，则可增加人力实现下一个增量；（3）可先发布部分功能给客户，对客户起到镇静剂的作用。
增量模型的缺点：（1）并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构；（2）增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。

螺旋模型的优点：（1）设计上的灵活性,可以在项目的各个阶段进行变更；（2）以小的分段来构建大型系统,使成本计算变得简单容易；（3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性；（4） 随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。
螺旋模型的缺点：（1）采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失；（2）过多的迭代次数会增加开发成本，延迟提交时间；（3）很难让用户确信这种演化方法的结果是可以控制的。

• 简述 UP 的三大特点，其中哪些内容体现了用户驱动的开发，哪些内容体现风险驱动的开发？ UP的三大特点是：迭代式增量开发，用例驱动，以系统架构为中心
  用例驱动体现了用户驱动的开发：开发过程中用例和场景的使用被证明是捕获功能性需求的卓越方法，并确保由它们来驱动设计、实现和软件的测试，使最终系统更能满足最终用户的需要。
  迭代式增量开发体现了风险驱动的开发：为了有效地控制风险，UP以渐进的方式进行演进，软件生命周期的每个阶段可以划分为多个迭代，每个迭代确定一个内部里程碑（或一个发布）。
• UP 四个阶段的划分准则是什么？关键的里程碑是什么？

划分准则：四个阶段根据开发生命周期中不同的关键里程碑划分
关键里程碑：

• 先启阶段：生命周期目标（Lifecycle Objective）里程碑，用于评价项目基本的生存能力。
• 精化阶段：生命周期架构（Lifecycle Architecture）里程碑，为系统的结构建立了管理基准，并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及防范的主要风险的解决方案。
• 构建阶段：初始运作能力（Initial Operational）里程碑，该里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统运作。
• 移交阶段：产品发布（）里程碑。此时要确定目标是否实现，是否应该开始另一个开发周期。
• IT 项目管理中，“工期、质量、范围/内容” 三个元素中，在合同固定条件下，为什么说“范围/内容”是项目团队是易于控制的

因为在合同固定的条件下，工期和质量都在合同中有了明确的规定，不能随意更改，项目的范围/内容则可以根据软件开发过程中遇到的情况，项目团队与客户商议做出稍微的调整。

• 为什么说，UP 为企业按固定节奏生产、固定周期发布软件产品提供了依据？

UP的软件生命周期从时间上分为四个阶段，每个阶段包括一个主要的里程碑。阶段是两个主要里程碑的分隔，在各个阶段结束时，执行评估阶段目标是否满足以决定是否进入下一个阶段。因此UP提供了固定节奏的生产。
UP是一个风险驱动的生命周期模型，为了有效地控制风险，UP以渐进的方式进行演进，首先解决高风险的问题，这主要是通过迭代来实现。在软件生命周期中，每个阶段可以划分为多个迭代，每个迭代确定一个内部里程碑（或一个发布）。因此，UP也为固定周期发布软件产品提供了依据。

2、项目管理使用

• 使用截图工具（png格式输出），展现你团队的任务 Kanban，请注意以下要求
  • 每个人的任务是明确的。即一周后可以看到具体成果
  • 每个人的任务是1-2项
  • 至少包含一个团队活动任务
    前端计划 后端计划 团队成员 团队活动 总体计划

• 软件工程的定义

(1)将系统化、规范化、可度量的方法应用与软件的开发、运行和维护的过程，即将工程化应用于软件中。

(2)对(1)中所述方法的研究。——IEEE[IEE93]

• 阅读经典名著“人月神话”等资料，解释 software crisis、COCOMO 模型。

software crisis：软件危机。由于计算机技术和应用发展迅速，整个社会对计算机应用的需求越来越大，知识更新周期加快，软件开发人员经常处在变化之中，不仅需要适应硬件更新的变化，而且还要涉及日益扩大的应用领域问题研究；但软件的生成却还沿用“手工作坊”的生产方式，人工编程生产，生产效率不够高，生产能力极其低下，从而在计算机软件的开发和维护过程中会遇到一系列严重问题，这些问题统称软件危机。

COCOMO模型：结构性成本模型。模型按其详细程度可以分为三级：基本COCOMO模型，中间COCOMO模型，详细COCOMO模型。其中基本COCOMO模型是是一个静态单变量模型，它用一个以已估算出来的原代码行数(LOC)为自变量的经验函数计算软件开发工作量。中级COCOMO模型在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。详细COCOMO模型包括中间COCOMO模型的所有特性，但更进一步考虑了软件工程中每一步骤（如分析、设计）的影响。软件工程的定义其实核心就是要规范化软件开发过程中的每一个环节，COCOMO也是重要的一种方法来衡量软件开发的成本，它们的存在是为了应对软件危机的出现，也是历史发展的必然性。

• 软件生命周期。

Systems Development Life Cycle，SDLC) 又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期。周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。

• 按照 SWEBOK 的 KA 划分，本课程关注哪些 KA 或 知识领域？

SWEBOK的Version 3将KA划分为：软件需求、软件设计、软件构建、软件测试、软件维护、软件配置管理、软件工程管理、软件工程过程、软件工程模型和方法、软件质量、软件工程专业实践、软件工程经济学、计算基础、数学基础、工程基金会。

本课程关注：软件工程管理、软件工程过程、软件工程模型和方法、软件质量。

• 解释 CMMI 的五个级别。例如：Level 1 - Initial：无序，自发生产模式。

Level 1 – Initial 过程不可测，极少的控制和反馈
Level 2 – Managed 过程定格，能反馈
Level 3 – Defined 过程标准化，积极主动的
Level 4 – Quantitatively Managed 过程可度量且可控
Level 5 – Optimizing 过程不断改进优化

• 用自己语言简述 SWEBok 或 CMMI （约200字）

CMMI－Capability Maturity Model Integration，能力成熟度模型集成。 CMMI是美国产业界、政府和卡内基梅隆大学软件工程研究所（CMU/SEI）于2002年1月推出的集成了软件工程（SW）、系统工程（SE）、集成化产品和过程开发（IPPD）等学科的综合成熟度模型； CMMI的表现形式有2种 阶段式 ，成熟度级别：应用于跨多个过程域的组织过程改进的成果。五个成熟度级别1-5。 连续式 ，能力级别：应用于单个过程域中的组织过程改进的成果。四个能力级别0-3。 CMMI的5个组织成熟等级为（1）初始级、（2）已管理级、（3）已定义级、（4）量化管理级、（5）优化级 CMMI的过程域定义了每个成熟度等级应该达到的水平，没达到定义水平，则不通过该级别。 CMMI可以保证软件开发的质量与进度，有利于成本控制，有助于提高软件开发者的职业素养，能够就解决人员流动所带来的问题，并且有利于提升公司和员工绩效管理水平。

2、解释PSP各项指标及技能要求

• 阅读《现代软件工程》的 PSP: Personal Software Process 章节。

Personal Software Process 章节

各项指标

1. 项目大小，一般用代码行数来表示，也可以用功能点；在实际产品中写了多少代码，不包括空行/注释/单字符行 。
2. 花费时间，可以用小时, 天，月，年来表示 ，一组人所花费的时间可以用 (人数*时间) 来表示，例如某项目花费了10个人·月。
3. 质量如何，交付的代码中缺陷的比例 。
4. 是否按时交付，以标准方差来看，稳定的交付时间更为重要 ，能保证团队的协同性。

• 按表格PSP 2.1，了解一个软件工程师在接到一个任务之后要做什么，需要哪些技能，解释你打算如何统计每项数据？ （期末考核，每人按开发阶段提交这个表）

待做事项

• 计划
  • 估计这个任务需要多少时间
• 开发
  • 分析需求
  • 生成设计文档
  • 设计复审 (和同事审核设计文档)
  • 代码规范 (为目前的开发制定合适的规范)
  • 具体设计
  • 具体编码
  • 代码复审
  • 测试（包括自我测试，修改代码，提交修改）
• 记录时间花费
• 测试报告
• 计算工作量
• 事后总结
• 提出过程改进计划

所需技能

1. 规划能力，对任务/项目进行统筹管理，合理安排过程时间；
2. 理解能力，要能理解需求，分析需求；
3. 书面表达能力，能撰写各种各样的文档；
4. 编码测试能力，要对底层的数据结构算法等具有设计，具备编码能力进行开发，能构思出高质量的输入来进行测试。
5. 总结能力，对时间花费、工作量进行计算，事后进行总结，反思并提出改进方案；
6. 执行力，严格按照计划来行事。

统计方式

1. 将项目明确划分阶段，确定每个阶段的工作任务和结束指标；
2. 每次完成阶段的工作任务后，对自己花费的时间计时记录下来，利用代码统计工具对完成的代码进行统计；
3. 项目完成后，统计之前的记录的结果进行分析。