引子:日本和美国的技术交流比国内与美国的技术交流快一步。单纯从个人技术角度上讲,中日两国的程序员技术水平差别不太大,但是成长环境和发展后路,日本企业要好得多。日本的软件管理也比中国强的多。日本软件管理特别规范,严格遵守软件工程流程,比如SDEM90.JCF-98。中国很多企业根本就没有软件工程流程,没有软件项目管理。借此文简单介绍日本的软件项目管理。感谢前公司同事的翻译。
SDEM90(Systems Development Engineering. Methodology 90)是富士通公司的开发标准,并被很多公司采用。最新的综合开发体系是SDAS(System Development Architecture & Support facilities),请参考http://segroup.fujitsu.com/sdas/
*************************************************************************************************************************
目录:0、前言
1、目的
2、系统开发标准的构造
3、SDEM90的构造
4、管理的可视化
5、标准化设计的理想方式
6、SDEM90文件体系
7、SDEM作业体系(WBS1阶段)
**********************************************************************************************************************
0、前言:为了在短时间内高品质地构建企业活动和企业协调中所取得的信息的管理系统,富士通公司提供了[SDAS综合开发系统]。SDAS是从计划工程开始一直到维护工程,为提高系统全部生命周期的生产效率所制作的,关于富士通的思维方法和具体的开发手段的详细体系。
富士通公司为了利用SDAS进行系统开发中的项目实施,提供了作为SDAS基础构造的[系统开发标准DEM90]。
本书是对包含系统开发方法论的系统开发标准SDEM90的一个概要的说明。目的是针对系统开发相关的方法,和项目计划地确定,项目管理各种方法的实施,理解SDEM90的概要、构成、使用方法、适用方法等事项。
系统开发时,很多发生的问题后来还会发生。必须注意使技术方面的困难和时间的紧迫所带来的问题不再发生。在SDEM90中,记述了各个工程中必要的作业项目,通过检查这些作业项目预防作业的疏漏,去除不必要的作业,并根据项目的特点选取合适的作业。并且,通过明确的角色分工,杜绝[这项工作没有给任何人]的事情出现。遵从此过程的项目成员可以专注于各个系统固有的问题,可以进行有效的系统开发。
但是,SDEM90不是像魔法似的开发标准。项目管理的重要性在于,Leader和manager可以很好地观察把握项目的状态,然后预见将要发生的问题,讨论相应的对策。SDEM90希望成为使用者的开发指南,项目标准设计者的良好伙伴。
本书的位置(handbook)
1 目的
重视业务 | |||||||||||||||
这是信息系统的最终目的。坚持面向企业业务效率的观点来开发系统 | |||||||||||||||
精通业务处理的使用部门作为主体,使用者亲自参加信息系统的开发,明确其要求 | |||||||||||||||
重视系统仕样 | |||||||||||||||
除了用户界面,功能、数据、性能、可靠性、维护等所有系统品质在比较早的阶段就明确地仕样化 | |||||||||||||||
开发者得到使用者的确认后,集中进行系统开发。 | |||||||||||||||
保证品质 | |||||||||||||||
系统的设计者对系统的制作过程进行review | |||||||||||||||
系统构成要素的分界过程和统一过程相对应,保证品质的检验和确认。 | |||||||||||||||
设定的品质目标,使全体开发人员认可和管理的 | |||||||||||||||
管理的可视化 | |||||||||||||||
在作业单位内明确角色分工后,设定项目的执行规则 | |||||||||||||||
设定项目管理的指标(品质、开发规模、工数、期限)后,通过开发过程中的测定工作,把问题在早期就解决 | |||||||||||||||
管理系统资产(软件、硬件)的变更过程,保持系统的整合性。 | |||||||||||||||
技术开发评价的基准化 | |||||||||||||||
明确作业的构成要素和相关联的输入输出信息,对重要技术体系化。 |
2、系统开发标准的构造
计算机使用领域以及服务种类的多样化,使系统开发活动变得更加复杂。因此,开发出系统整体构造和每个作业的构成都容易理解的模块是非常必要的 。
为此,SDEM90从空间和时间两个方向分析系统开发整体活动的构造,设定了它的范畴(category)和过程的模型 。
并且,将开发中必要的作业单元用WBS的方式分层表示,还整理了作业成果的文档体系,形成了系统资产的管理基准。
3、SDEM90的构造
1)category
category是明确开发和管理职能的角色和责任
系统开发,就是将人类的活动转换成机械的系统。
相对于人类世界中的企业、业务技能等实体的实际世界,机械世界是计算机的软件和硬件构成的计算机世界
并且设定了使项目平滑进步的开发支援和项目管理技能
从空间上整理了实际世界和计算机世界变换中必要的开发和管理技能的类型。
灰色:实际世界 青蓝色:计算机世界
Category 一览 | ||||||
概念 | 略号 | 大category | 略号 | 小category | ||
实际世界 | A. | 业务 | ||||
接口 | B. | 系统仕样 | 1 | 系统机能 | ||
2 | 数据构造 | |||||
3 | 性能 | |||||
4 | 信赖性/安全性 | |||||
5 | 运营维护 | |||||
6 | 更改 | |||||
计算机世界 | C. | 软件 | 1 | 应用 | ||
2 | 数据 | |||||
3 | 基本软件 | |||||
4 | 环境 | |||||
D. | 硬件 | 1 | 主机 | |||
2 | 工作站 | |||||
3 | 网络 | |||||
4 | 设施 | |||||
开发资源补给 | E. | 开发支援 | 1 | 开发标准 | ||
2 | 技法/工具 | |||||
3 | 培训 | |||||
4 | 系统资产管理 | |||||
5 | 开发用品 | |||||
F. | 项目管理 | 1 | 项目指标管理 | |||
2 | 组织. 重要成员 | |||||
3 | 费用 |
2)工程
工程是对系统生命周期的时间划分
对变化对象系统构成要素进行分解和合成,构建品质保证过程
大工程 | 小工程 | ||
计划(PN ) Planning | SP 系统企划 System Planning | ||
SA 系统分析 System Analysis | |||
设计 (DN) Design | UI 用户接口设计 User Interface Design | ||
SS 系统构造设计 System Structure Design | |||
PS 程序构造设计 Program Structure Design | |||
编程 | PG 编程 Programming | ||
测试(TG) Testing | PT 程序测试 Program Test | ||
IT 集成测试 Integration Test | |||
ST 系统测试 System Test | |||
运营.评价(OE) Oper.& Evaluation | OT 运营测试 Operational Test | ||
ME 维护.系统评价 Maintenance and System Evaluation |
4、管理的可视化
1、角色分工明确化
2、项目指标明确化
3、系统资产管理明确化
5、标准化设计的理想方式
SDEM90是独立于开发对象的系统条件和适用的技术条件的开发模型。通过设计项目固有的开发标准,考虑项目的特性,如系统条件、技术条件和开发条件,遵照以下的顺序将之客户化、实用化。
1、在使用Package和工具的情况下, (省略WBS)
2、在性能、信赖性等风险较少的情况下, 作业时间减少 (要有WBS)
6、SDEM90文件体系
工程 Catogory | SP 系统企划 | SA 系统分析 | UI 用户接口设计 | SS 系统构造设计 | PS 程序构造设计 | PG 编程 | PT 程序测试 | IT 集成测试 | ST 系统测试 | OT 运营测试 | ME 维护.系统评价 | |
业务 | 全公司业务构想计划 | 业务方式设计 | 业务的仕样化,变更管理、调整[UI-IT] | 系统运营的准备 | 临时运营和移植的决定 | 目标达成的评价和业务动向监视 | ||||||
系统仕样 | 1 系统机能 | 信息系统的体系化 | 机能概要设计及实现性的讨论 | 机能的仕样化 | 机能构建的Review, 变更管理[SS-IT] | 使用者手册的制作 | 系统测试仕样书的制作 | 系统机能测试 | 机能性保证 | 适应强化 | ||
2 数据构造 | 数据概要设计 | 数据的仕样化 | 数据仕样的实现程度的Review,变更管理[SS-IT] | 数据资源监视 | ||||||||
3 性能 | 性能容量概算 | 性能容量的详细估算 | 性能处理方式的设计 | 性能构建的Review,变更管理[SS-IT] | 性能测试仕样书的制作 | 性能测试.调整 | 性能保证 | 系统性能的监视 | ||||
4 信赖性/安全 | 安全.故障对策方法的设定 | 安全.故障对策方法的仕样化 | 恢复和重启方式的设计 | 信赖性构建的Review,变更管理[SS-IT] | 信赖性测试 | 信赖性保证 | 故障分析.安全性监视 | |||||
5 运营.维护 | intelligence 配置计划 | 系统运营.维护方法的设定 | 系统运营.维护性的仕样化 | 运营处理方式的设计 | 运营条件的实现程度,维护性的构建的Review,变更管理[SS-IT] | 运营手册的制作 | 运营管理系统机能测试 | 运营测试仕样书的制作 | 运营性保证 | |||
6 移植 | 移植方法的设定 | 移植的仕样化 | 移植处理方式的设计 | 移植仕样的实现程度的Review,变更管理[SS-SP] | 移植手册的制作 | 移植应用机能测试 | 实际数据的移植演习 | 移植 | ||||
软件 | 1 应用 | Package调查 | 应用的计划 | 应用的适用讨论 | 应用的构造设计 | 程序设计,集成测试仕样书制作 | 模块的设计,编码,测试 | 程序测试 | Process机能测试 | 应用的改造 | ||
2 数据 | 内部数据设计 | 集成测试主要文件的制作 | 系统测试主要文件的制作 | 运营测试、移植文件的制作 | ||||||||
3 基本软件 | 基本软件的概要选定 | 基本软件构成的决定 | 开发基本软件的导入 | 运营基本软件的导入 | 基本软件的维护、版本升级 | |||||||
4 环境 | 模块测试环境的建成 | 程序测试环境的建成 | 集成测试环境的建成 | 系统测试环境的建成 | 运营测试环境的建成 | 环境定义体系的维护 | ||||||
硬件 | 1 主机 | 主机机器构成的概要选定 | 主机机器构成的决定 | 开发主机的导入 | 开发主机的运行 | 运营主机的导入 | 运营主机的运行 | 硬件的维护、升级 | ||||
2 工作站 | 工作站机器构成的概要选定 | 工作站机器构成的决定 | 开发工作站的导入 | 开发工作站的运行 | 运营工作站的导入 | 运营工作站的运行 | ||||||
3 网络 | 网络构成方式的设定 | 网络构成方式的决定 | 开发网络的导入 | 开发网络的运行 | 运营网络的导入 | 运营网络的运行 | ||||||
4 设施 | 设施构成方式的设定 | 设施构成方式的决定 | 开发设施的导入 | 开发设施的运行 | 运营设施的导入 | 运营设施的运行 | ||||||
开发支援 | 1 开发标准 | 开发标准的具体化(SP-SA) | 开发标准的具体化(UI) | 开发标准的具体化(SS) | 开发标准的具体化(PS-PT) | 开发标准的具体化(IT-ST)[PT-IT] | 开发标准的具体化(OT-ME)[ST-OT] | |||||
2 技法. 工具 | 信息技术的调查 | 技法.工具的决定 | 支援工具的开发、导入 | 性能测试工具的开发[PT-IT] | ||||||||
3 培训 | 培训计划和UI的目标的培训 | SS目标的培训 | PS-PT目标的培训 | IT目标的培训 | ST目标的培训 | OT目标的培训 | ||||||
4 系统资产管理 | 系统资产管理方法的决定 | 系统资产管理 | 维护手册制作,系统资产管理 | 系统资产管理 | ||||||||
5 开发用品 | 开发用品计划和管理方法的决定 | 开发用品的准备 | 开发用品计划的检查 | 开发用品管理及检查 | ||||||||
项目管理 | 1 项目指标管理 | 项目指标的决定 | 项目指标管理和检查 | 项目指标管理和检查 | 项目的评价 | |||||||
2 组织.要员 | 分析项目的组织结构 | 开发项目体制和运作规则的确立 | 组织管理和检查 | 组织管理和其他工程的体制的检查、决定 | ||||||||
3 费用 | 开发费用管理方法的决定 | 开发费用的预实管理和检查 | 开发费用的预实管理 |