ljx 2018-07-01T16:29:08+00:00 yourmail@mail2.sysu.edu.cn Lesson16 2018-07-01T00:00:00+00:00 ljx https://ishoping.github.io/lesson16 使用 ECB 实现 make reservation 用例的详细设计(包含用例简介,顺序图,类图)

用例简介:

  • 查找
  • 下订单
  • 管理购物栏
  • 支付

    顺序图

    sq

    类图

    class

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

    package

]]>
Final_report 2018-07-01T00:00:00+00:00 ljx https://ishoping.github.io/final_report X3 Final Report
  • 简短的课程学习自我总结(400字以内)
    • 请不用讲述与分析、设计、开发、管理无关的话题
    • 可以包括对同学帮助的致谢(同学姓名请用 github 昵称表示,不许出现真实姓名)
    • 0 ~ 400字,即没有这段也没关系
  • PSP 2.1 统计表
  • 个人分支的 GIT 统计报告(不需要解释原因)- 仅需要提交截图
  • 自认为最得意/或有价值/或有苦劳的工作清单,含简短说明(一句话)
  • 个人的技术类、项目管理类博客清单(只需要名称与 url )

    PSP 2.1 统计表

PSP2.1 Personal SoftWare Process Stages Time(%)
Planning 计划 3
Estimate 估计这个任务需要多少时间 3
Analysis 需求分析 4
Design Spec 生成设计文档 1
Design Review 设计复审 1
Coding Standard 代码规范 0
Design 具体设计 5
Coding 具体编码 60
Code Review 代码复审 3
Test 测试 20
Summary 合计 100

个人分支的 GIT 统计报告(不需要解释原因)- 仅需要提交截图

git

自认为最得意/或有价值/或有苦劳的工作清单,含简短说明(一句话)

  • docker-compose.yml的部署
  • 构建项目目录结构
  • 基于数据库解决访问权限的控制

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

flask入门

]]>
Lesson13 2018-06-08T00:00:00+00:00 ljx https://ishoping.github.io/lesson13 描述软件架构与框架之间的区别与联系
  • 软件架构就是把系统分解为一些部件,描述这些部件的职责及它们之间的协作行为。
  • 架构模式(style)是 特定领域 常见问题的解决方案。
  • 框架是特定语言和技术的架构应用解决方案。
  • 框架是具体语言和技术相关的
  • 框架是一种或多种架构的组合的实现
  • 框架是集成了你的代码和多种第三方解决方案的工具,让你聚焦 业务逻辑代码 而 不是技术实现

    以你的项目为案例

    绘制三层架构模型图,细致到分区

    logic_architecture

结合你程序的结构,从程序员角度说明三层架构给开发者带来的便利

  • 每个层或包的职责是清晰的,模块化并可扩展的。系统分析的每个类会分明确的放置;
  • 提供了隐式的程序复用准则;
  • 每个层涉及的技术是明确的。这使得程序员可以通过快速培训上岗;
  • 通过依赖估计项目变化产生的工作量;
  • 开发次序和重要性是明确的。领域模型、基础模块(用户和基础数据的DTO和Service必须优先开发与测试),
    减少这些模块的错误,特别是领域模型设计失误,是项目成功的关键;
  • 并行开发支持。利用前后端分离,实现并行开发

    研究 VUE 与 Flux 状态管理的异同

    Flux将一个应用分成四个部分。

  • View: 视图层
  • Action(动作):视图层发出的消息(比如mouseClick)
  • Dispatcher(派发器):用来接收Actions、执行回调函数
  • Store(数据层):用来存放应用的状态,一旦发生变动就提醒Views要更新页面
    flux

    vuex基于flux

    vuex

]]>
Lesson9 2018-05-13T00:00:00+00:00 ljx https://ishoping.github.io/lesson9 文档

练习文档

task1

用例建模,画出用例图。
use_case

task2

选择一项业务或用例,给出活动图。
use_case

task3

识别实体和中介实体,按用例构建领域模型。
use_case

task4

对在线订外卖业务对象进行状态建模。
use_case

task5

给出一个场景的系统顺序图,如下订单,取消订单等。
use_case

]]>
Lesson8 2018-05-06T00:00:00+00:00 ljx https://ishoping.github.io/lesson8 1)使用 UML State Model
  • 建模对象: 参考 Asg_RH 文档, 对 Reservation/Order 对象建模。
  • 建模要求: 参考练习不能提供足够信息帮助你对订单对象建模,请参考现在
    定旅馆 的旅游网站,尽可能分析围绕订单发生的各种情况,直到订单通过销售事件(柜台销售)结束订单。
    state

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

    taobao_tuihuo_state

]]>
Lesson7 2018-04-28T00:00:00+00:00 ljx https://ishoping.github.io/lesson7 1、 领域建模
  • 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

      系统的 E-R 模型

      hotel_er

      Mysql 物理数据库的脚本:

-- MySQL Script generated by MySQL Workbench
-- 04/28/18 19:18:29
-- Model: New Model    Version: 1.0
-- MySQL Workbench Forward Engineering

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';

-- -----------------------------------------------------
-- Schema mydb
-- -----------------------------------------------------

-- -----------------------------------------------------
-- Schema mydb
-- -----------------------------------------------------
CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET utf8 ;
USE `mydb` ;

-- -----------------------------------------------------
-- Table `mydb`.`credit cards`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`credit cards` (
  `number` VARCHAR(45) NOT NULL,
  `type` VARCHAR(45) NULL,
  `security code` VARCHAR(5) NULL,
  PRIMARY KEY (`number`))
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`customer`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`customer` (
  `costomer_id` VARCHAR(45) NOT NULL,
  `name` VARCHAR(45) NULL,
  PRIMARY KEY (`costomer_id`))
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`location`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`location` (
  `code` DECIMAL(45) NOT NULL,
  `name` VARCHAR(45) NULL,
  PRIMARY KEY (`code`))
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`hotel`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`hotel` (
  `address` VARCHAR(45) NOT NULL,
  `location_code` DECIMAL(45) NOT NULL,
  PRIMARY KEY (`address`, `location_code`),
  INDEX `fk_hotel_location1_idx` (`location_code` ASC),
  CONSTRAINT `fk_hotel_location1`
    FOREIGN KEY (`location_code`)
    REFERENCES `mydb`.`location` (`code`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`reservations`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`reservations` (
  `reservation_id` VARCHAR(45) NOT NULL,
  `hotel name` VARCHAR(45) NULL,
  `city name` VARCHAR(45) NULL,
  `check in date` DATE NULL,
  `check out date` DATE NULL,
  `numbers of room` INT NULL,
  `price` FLOAT NULL,
  `costomer name` VARCHAR(45) NULL,
  `isSmoking` TINYINT(1) NULL,
  `credit cards_number` VARCHAR(45) NOT NULL,
  `customer_costomer_id` VARCHAR(45) NOT NULL,
  `hotel_address` VARCHAR(45) NOT NULL,
  PRIMARY KEY (`reservation_id`, `credit cards_number`, `customer_costomer_id`, `hotel_address`),
  INDEX `fk_reservations_credit cards_idx` (`credit cards_number` ASC),
  INDEX `fk_reservations_customer1_idx` (`customer_costomer_id` ASC),
  INDEX `fk_reservations_hotel1_idx` (`hotel_address` ASC),
  CONSTRAINT `fk_reservations_credit cards`
    FOREIGN KEY (`credit cards_number`)
    REFERENCES `mydb`.`credit cards` (`number`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_reservations_customer1`
    FOREIGN KEY (`customer_costomer_id`)
    REFERENCES `mydb`.`customer` (`costomer_id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_reservations_hotel1`
    FOREIGN KEY (`hotel_address`)
    REFERENCES `mydb`.`hotel` (`address`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`request`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`request` (
  `request_id` INT NOT NULL,
  `destination name` VARCHAR(45) NULL,
  `check in date` DATE NULL,
  `number of nights` INT NULL,
  `customer_costomer_id` VARCHAR(45) NOT NULL,
  PRIMARY KEY (`request_id`, `customer_costomer_id`),
  INDEX `fk_request_customer1_idx` (`customer_costomer_id` ASC),
  CONSTRAINT `fk_request_customer1`
    FOREIGN KEY (`customer_costomer_id`)
    REFERENCES `mydb`.`customer` (`costomer_id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`room-desc`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`room-desc` (
  `idroom_desc_id` INT NOT NULL,
  `price` FLOAT NULL,
  PRIMARY KEY (`idroom_desc_id`))
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`room`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `mydb`.`room` (
  `room_id` VARCHAR(45) NULL,
  `type` VARCHAR(45) NOT NULL,
  `hotel_address` VARCHAR(45) NOT NULL,
  `room-desc_idroom_desc_id` INT NOT NULL,
  PRIMARY KEY (`type`, `hotel_address`, `room-desc_idroom_desc_id`),
  INDEX `fk_room_hotel1_idx` (`hotel_address` ASC),
  INDEX `fk_room_room-desc1_idx` (`room-desc_idroom_desc_id` ASC),
  CONSTRAINT `fk_room_hotel1`
    FOREIGN KEY (`hotel_address`)
    REFERENCES `mydb`.`hotel` (`address`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_room_room-desc1`
    FOREIGN KEY (`room-desc_idroom_desc_id`)
    REFERENCES `mydb`.`room-desc` (`idroom_desc_id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

简单叙说 数据库逻辑模型 与 领域模型 的异同

领域模型不会排除需求中没有明确要求记录其相关信息的类,也不会排除没有属性的概念类,而数据库逻辑模型则排除。

]]>
Hw6 2018-04-18T00:00:00+00:00 ljx https://ishoping.github.io/hw6 1、 用例建模

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

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

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

支付方法变得多样,不只银行卡支付,还可以用礼品卡支付,微信支付,支付宝支付,而且
搜索酒店时,可以根据酒店级别,价格,位置等条件搜索

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

ID Name Imp Est How to Demo Notes
1 预约 120 8 选择酒店,选择房间类型,确定预约 需要UML顺序图
2 查找 100 5 输入目标城市,点击搜索 需要UML顺序图
3 管理购物车 60 6 进入管理购物车页面,进行添加,修改,删除,查询操作 需要UML顺序图
4 支付 30 3 进入支付页面,选择支付方式,确认支付 需要UML顺序图

2、业务建模

a. 在(任务b)基础上,用活动图建模找酒店用例。简述利用流程图发现子用例的方法。
activity
b. 选择你身边的银行 ATM,用活动图描绘取款业务流程
atm
c. 查找淘宝退货业务官方文档,使用多泳道图,表达客户、淘宝网、淘宝商家服务系统、商家等
用户和系统协同完成退货业务的过程。分析客户要完成退货业务,在淘宝网上需要实现哪些系统用例
taobao  

用例:

  • 退款
  • 管理订单
  • 联系商家和客服

    3、用例文本编写

    在大作业基础上,分析三种用例文本的优点和缺点
    详述:

  • 优点:对用例的描述更为详细,深入
  • 缺点:需要花费大量人力物力来写

摘要:  

  • 优点:简洁,便于快速了解主题和范围,花费时间少,可能只需几分钟
  • 缺点:不够详细,深入

非正式:优缺点同上

]]>
Hw5 2018-04-15T00:00:00+00:00 ljx https://ishoping.github.io/hw5 Flask入门

Flask是python的一个简单易用的web框架
用Flask很容易就写出一个简单的web应用

一个简单的例子

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello, World!'

把代码保存到hello.py中,在命令行中输入以下命令

$ exportFLASK_APP=hello.py
$ flask run
 * Running on http://127.0.0.1:5000/ 

好了,一个简单的helloworldweb应用就实现了,在浏览器输入
http://127.0.0.1:5000/,就会看到Hello, World!了

路由

@app.route('/')
def index():
    return 'Index Page'

@app.route('/hello')
def hello():
    return 'Hello, World'

@app.route(‘/’)把下面的函数当作参数传入,当访问网页首页时,
就会调用index函数来处理,当访问/hello页面时,会调用hello函数
来处理,这样,我们就可以对每个url实现它的处理函数

HTTP方法

我们可以以不同的http方法访问同一个url,http方法有
GET,HEAD,POST,PUT,DELETE,OPTIONS.

from flask import request

@app.route('/login', methods=['GET', 'POST'])
def login():
    if request.method == 'POST':
        do_the_login()
    else:
        show_the_login_form()

当我们用GET方法访问/login时,就会调用show_the_login_form(),
当我们用POST时,就会调用do_the_login()

]]>
作业2 2018-03-22T14:11:00+00:00 ljx https://ishoping.github.io/hw2 作业

1. 简单题

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

  • 降低软件开发的复杂程度,提高软件开发过程的透明性,提高 软件开发过程的可管理性
  • 推迟软件实现,强调在软件实现前必须进行分析和设计工作
  • 以项目的阶段评审和文档控制为手段有效地对整个开发过程进 行指导,保证了阶段之间的正确衔接,能够及时发现并纠正开 发过程中存在的缺陷,使产品达到预期的质量要求

瀑布模型的缺点

  • 强调过程活动的线性顺序
  • 缺乏灵活性,特别是无法解决软件需求不明确或不准确的问题
  • 风险控制能力较弱
  • 瀑布模型中的软件活动是文档驱动的,当阶段之间规定过多的 文档时,会极大地增加系统的工作量
  • 管理人员如果仅仅以文档的完成情况来评估项目完成进度,往 往会产生错误的结论

增量模型的优点

  • 增强客户对系统的信心
  • 降低系统失败风险
  • 提高系统可靠性
  • 提高系统的稳定性和可维护性

增量模型的缺点

  • 增量粒度难以选择
  • 确定所有的基本业务服务比较困难

螺旋模型的优点

  • 设计上的灵活性,可以在项目的各个阶段进行变更。
  • 以小的分段来构建大型系统,使成本计算变得简单容易。
  • 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
  • 随着项目推进,客户始终掌握项目的最新信息, 从而他或她能够和管理层有效地交互。
  • 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

螺旋模型的缺点

  • 很难让用户确信这种演化方法的结果是可以控制的。
  • 建设周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,和当前的技术水平有了较大的差距,无法满足当前用户需求。

简述 UP 的三大特点,其中哪些内容体现了用户驱动的开发,哪些内容体现风险驱动的开发? 三大特点:

  • 用例驱动
  • 以架构为中心
  • 迭代式增量开发

用力驱动和以架构为中心体现了用户驱动的开发
迭代式增量开发体现了风险驱动开发

UP四个阶段的划分准则是什么?关键的里程碑是什么?
UP四个阶段为初始、细化、构造、移交,划分准则为里程碑.每个阶段结束于一个
主要的里程碑(Major Milestone),并在阶段结尾执行一次评估以确定这个阶
段的目标是否已经满足。如果评估结果令人满意的话,可以允许项目进入下一个阶段。

  • 初始阶段里程碑:生命周期目标(Lifecycle Objective) 里程碑,包括一些 重要的文档,如:项目构想(Vision)、原始用例模型、原始业务 风险评估、一个或者多个原型、原始业务案例等。需要对这些 文档进行评审,以确定正确理解用例需求、项目风险评估合理、 阶段计划可行等。
  • 细化阶段里程碑:生命周期体系结构(Lifecycle Architecture) 里程碑。包 括风险分析文档、软件体系结构基线、项目计划、可执行的进 化原型、初始版本的用户手册等。通过评审确定软件体系结构 已经稳定、高风险的业务需求和技术机制已经解决、修订的项 目计划可行等。
  • 构造阶段里程碑:初始运行能力(Initial Operational Capability) 里程碑。 包括可以运行的软件产品、用户手册等,它决定了产品是否可 以在测试环境中进行部署。此刻,要确定软件、环境、用户是 否可以开始系统的运行。
  • 移交阶段里程碑:产品发布(Product Release)里程碑。确定最终目标是 否实现,是否应该开始产品下一个版本的另一个开发周期。在 一些情况下这个里程碑可能与下一个周期的初始阶段的相重合。

IT 项目管理中,“工期、质量、范围/内容”三个元素中,在合同固定条件下,为什么说“范围/内容”是项目团队是易于控制的
因为在合同固定条件下,工期和质量都是在合同中明确确定的,所以只有范围/内容是
项目团队易于控制的

为什么说,UP 为企业按固定节奏生产、固定周期发布软件产品提供了依据?
RUP中的软件生命周期在时间上被分解为四个顺序的阶段:初始阶段(Inception)、
精化阶段(Elaboration)、构建阶段(Construction) 和产品交付阶段(Transition)。
每个阶段结束于一个主要的里程碑(MajorMilestone),并在阶段结尾执行一次评估
以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话,可以允许项目进入下一个阶段,而且每个阶段的每个迭代时间是固定的

2、项目管理使用

使用截图工具(png格式输出),展现你团队的任务 Kanban,请注意以下要求

  • 每个人的任务是明确的。即一周后可以看到具体成果
  • 每个人的任务是1-2项。
  • 至少包含一个团队活动任务

任务

]]>
作业1 2018-03-10T00:27:00+00:00 ljx https://ishoping.github.io/hw1 作业

1. 简单题

软件工程的定义

软件工程:(1)将系统化、规范化、可度量的方法应用与软件的开发、运行和维护的过程,即将工程化应用于软件中。
        (2)对(1)中所述方法的研究。

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

软件危机:六十年代以来,随着计算机应用需求的驱动,系统软件和应用软件有很大的发展,如操作系统,编译系统和大型应用软件等。
由于软件生产的复杂性和高成本,使大型软件的生产出现了很大的困难,即出现软件危机。

COCOMO 模型:构造性成本模型(COCOMO,英文全称为Constructive Cost Model)  
是由巴里·勃姆(BarryBoehm)提出的一种软件成本估算方法。这种模型使用一种基本的回归分析公式,
使用从项目历史和现状中的某些特征作为参数来进行计算。

软件生命周期。

软件生命周期(Software Development LifeCycle)是指软件的产生直到成熟的全部过程。

按照 SWEBok 的 KA 划分,本课程关注哪些 KA 或 知识领域?

软件需求、软件设计、软件工程过程

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

第一级别,初始级:首先,软件的过程有序性程度不高,甚至会出现混乱的情
况,软件是否能够成功主要取决于研发人员本身的实力和努力,项目可能会成
功,但是任务的完成中存在很大的偶然性。也就是说企业不能担保在实施同一
类项目的时候还能按时按期完成任务,研发人员是这一个级别最关键的因素,
企业占到的作用不甚明显。

第二级别,可管理级:公司在管理上已经具备了一定的能力,能够建立比较基
础的项目管理规范,对于项目的实施能够列出相应的计划和流程,并且随着流
程的进行可以对此实施监控和控制。从一级到二级,最大的差别就是企业的管
理有了相当程度的进步,利用管理手段排除了企业在第一级别完成任务时候的
随机性与不确定性,保证企业的项目都能得到成功。

第三级别:已定义级:在第三级别的情况下,企业不仅能够把软件管理和工程
管理两个过程都实现标准化和文档化,而且软件产品的整个生产过程,都是可
见可控的。也就是说,企业根据自身的情况以及自己的流程能够建立一套规范
制度的管理体系与流程,从而保证在同类或者是不同类的项目上都能够得到成
功的实施。在这一阶段,企业的科学管理已经形成企业文化,更是企业内涵。

第四级别:量化管理级:是第三级别的升级版,在第四级别的时候,企业的项
目管理首先是已经形成了完善的制度,而且根据名称,可以平判处,这一级别
最关键的两个字就是“量化”。对项目流程的管理做到量化、数字化、具体化,
对软件过程和产品精度都有定量的控制,实现管理更加细致化,精细化,项目
的质量也能因此保证相对的高质量和稳定性。

第五级别:优化管理级:第五级别优化管理级是软件企业项目管理目前来说的
最高境界。企业能够非常主动的来对流程进行一定程度的改善,将更加先进的
技术运用到其中,让流程优化上升到一个更高的层次。在第四级别的基础上,
还能够利用当前的信息资料来对项目过程中出现的问题进行预防,让每一个项
目都能有非常高的质量。

用自己语言简述 SWEBok 或 CMMI (约200字)

swebok是IEEE计算机学会职业实践委员会主持的一个项目,其目标为:
1.促进世界范围内对软件工程的一致观点
2.阐明软件工程相对其它学科(如计算机科学、项目管理、计算机工程和数学等)的位置,并确立它们的分解
3.刻画软件工程学科的内容
4.提供使用知识体系的主题
5.为开发课程和个人认证与许可材料,提供一个基础
SWEBOK V3在软件工程领域共有15个知识领域:
    软件需求
    软件设计
    软件构造
    软件测试
    软件维护
    软件配置管理
    软件工程管理
    软件工程过程
    软件工程模型和方法
    软件质量
    软件工程职业实践
    软件工程经济学
    计算基础
    数学基础
    工程基础

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

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

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

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

需要的技能:
1.知识:  对具体技术的掌握, 动手能力
例如: 对Java, C/C++/C#, 诊断/提高效能的技术,  对device driver, kernel
debugger 的掌握;对于某一开发平台的掌握。
2.自我管理的能力; 表达和交流的能力; 与人合作的能力;
把任务按质按量完成的执行力; 这些能力在IT 行业和其它行业都很重要。

如何统计每项数据:
记录每项任务开始和结束的时间,就可以知道每个任务所用时间
]]>