实训师指导手册.docx
- 文档编号:7680475
- 上传时间:2023-01-25
- 格式:DOCX
- 页数:22
- 大小:83.84KB
实训师指导手册.docx
《实训师指导手册.docx》由会员分享,可在线阅读,更多相关《实训师指导手册.docx(22页珍藏版)》请在冰豆网上搜索。
实训师指导手册
实训师指导手册
ProjectTrainingInstructorGuide
版本1.0
作者
IBMChina,CSDL,LBSEducation
日期
2007/11/12
审批
日期
变更记录
日期
版本
变更说明
作者
2007/11/12
V1.0
创建
IBMChina,CSDL,LBSEducation
导言4
目的4
范围4
实训制度4
组织结构6
术语定义7
实训开发过程9
立项10
需求分析过程14
设计过程17
编码过程19
测试过程21
实施过程23
结项23
导言
目的
指导实训师和助理实训师如何在项目实训中带领学生完成项目,以及项目总监的角色定位和任务。
范围
适用于项目实训的各位实训师和助理实训师。
实训制度
实训是一种模拟企业项目实际开发的训练,因此具有企业工作的相似性,实行类似企业管理的工作制度。
1、学员配带实习生卡,每天上班要签到或打卡。
实习生卡采用员工卡的形式,有照片、姓名和员工号。
2、学员书写周报,记录每周的工作,并在周五下班前向配置管理库或项目经理提交。
3、学员实行项目经理负责制度
实训师指南:
日常管理工作:
班主任负责制:
助理实训师或教务工作者担任班主任,承担监督学生的实训日常管理工作,类似公司的行政部门职员的职责。
实训师只承担项目总监的职责,关注项目技术、进度和质量。
如没有打卡机的条件,可请班主任每天准备签到表进行签到,并检查胸卡的佩戴情况。
相关奖罚措施由班主任制定。
涉及各小组日常工作的相关事宜,由项目经理做接口人与班主任沟通。
实训总原则
实训师和助理实训师在实训中主要承担项目总监的任务,引导和监督是其主要的职责。
应避免过多的课堂讲授,共性问题以会议的形式讲解和解决。
实训选用的项目是IBM真实项目的裁剪,并经改造成为适合学生实训的虚拟项目。
实训的目的是使学生了解企业工程项目开发中运用的技术、开发和管理方法,缩短入职后的成长期。
实训师应强调学生须按学生指导手册和各种指南认真完成每个过程,在各里程碑开始时对可能遇到的困难和错误做出预见性的告知,避免学生在实训中对项目开发理解有误,导致影响项目开发进度。
引导学生从学生到职业人的转换,鼓励学生动手实践来验证问题,出现错误以引导方式让学生及时修正,修正错误的过程通常会使学生更加受益。
某些开发过程因条件所限无法实现而被裁剪的,需要向学生简要说明,避免学生以为项目开发只有实训中的过程。
学生完成实训后,通常达到能理解软件工程的角色分工和各角色的工作内容,从而能初步了解自己的喜好和适合的工作岗位。
实训师最终总结时指出,学生在短时间内开发完成的虚拟项目,没有经过严格的测试、试运行和验收,是无法应用在实际系统中的,让学生深刻体会项目开发的严肃性,体会项目管理中许多严格规范的重要性。
助理实训师辅助实训师跟踪和监督实训的全过程,各项目组是否能按照指导手册进行项目开发,类似质量管理员的职责。
同时还要承担部分技术指导工作,如系统配置、工具安装的指导。
实训中选用的应用服务器、数据库、开发工具和建模工具,必须选用IBM产品。
配置管理工具和测试工具可选用开源框架。
IBM产品由IBM提供教学license,仅用于教学目的。
项目实训准备
组织结构
角色
责任
知识技能
人员
项目总监
●讲解软件项目开发的方法、过程和规范
●指导项目开发各过程的活动
●按里程碑检查项目组阶段工作
●监督项目过程规范的执行情况
●指导评审
具备项目工程经验和教学经验
实训师
项目经理
●负责项目干系人的合作协调
●负责项目进度的控制
●负责项目开发各过程活动的组织
●监督配置管理库
●承担部分开发任务
组织过校园活动,有一定管理经验
各项目组组长
技术经理
●负责开发计划的制定
●负责项目开发各过程活动的技术
●负责项目组内部技术的培训
●承担部分开发任务
技术扎实全面,逻辑思维好
各项目组副组长
配置管理员
●制定配置管理规范
●负责配置管理库目录结构的建立
●负责配置管理库的维护
●维护需求跟踪矩阵
●收集测试问题报告单
●分配角色权限、配置库备份
认真负责,思维全面细致
指定的组员
数据库管理员
●负责数据库的设计、建立和维护
熟悉数据库的设计模式和相关数据库的特性
指定的组员
软件工程师
●参与需求分析活动
●参与详细设计
●按照详细设计完成编码和单元测试
●对个人开发活动进行记录,提交个人工作周报
●修改测试出来的缺陷
熟练使用开发工具和编写代码
全体组员
测试工程师
●建立测试环境
●承担功能测试和集成测试工作
●提交测试问题报告单
认真负责,思维全面细致
指定的组员
术语定义
●WBS
WorkBreakdownStructure工作分解结构
●Milestone里程碑
一个在预定时间发生的事件,某个人应该对其负责,并且能用它来测量进程。
●Baseline基线
已经通过正式评审和认可,作为以后进一步开发的基础,并且只有通过正式的更改控制规程才能进行更改得规格说明或产品。
●RM
RequirementManagement需求管理
●SCM
SoftwareConfigurationManagement软件配置管理
●PR
PeerReview同行评审
●DBA
DataBaseAdministrator数据库管理员
●SRS
SoftwareRequirementSpecification软件需求规格说明书
●SCCB
SoftwareConfigurationControlBoard软件配置控制委员会
●SQA
SoftwareQualityAssurance软件质量保证员
●CMM
SoftwareCapabilityMaturityModel软件能力成熟度模型
●PM
ProjectManager项目经理
实训开发过程
项目启动
活动说明
Ø项目总监对项目进行介绍,介绍项目组的组织结构,指导学生分组。
分组以学生方式自愿为原则,组长负责与项目组成员讨论确定组织结构成员,给项目组命名,如**组。
完成后,由组长向项目总监提交。
Ø项目总监讲解项目管理课程,包括项目开发管理和配置管理的内容,各项目组确定本项目组的项目管理方法,包括文件命名规范、配置管理规范、编码规范。
Ø项目总监发放项目《需求规格说明书》和静态原型,学生须全面了解项目。
Ø准备开发环境,包括熟悉并安装配置管理库、数据库和开发工具。
实训师指南:
分组:
实训师向全体学员说明项目开发实行项目经理负责制,分组以自愿为原则,实训师适当参与指导,小组人员专业水平应成正态分布,即优秀、普通、稍差都在团队中占一定比例。
项目经理由小组成员推选。
小组成员角色分配十分重要,实训师可提前给所有项目经理开个小型会议,指导一下分工原则。
《项目经理手册》是项目经理管理项目的重要指导,各项目经理必须严格遵照执行。
实训师要强调项目经理的职责和定位,以及与技术经理职责的区别。
项目组内分工以自愿为原则,项目经理负责协调。
完成后,由项目经理提交分工结果给实训师,如实训师认为不合适,可做调整。
项目进行过程中,如发现某角色不胜任,实训师有权进行调整。
裁剪:
实训师需要在立项阶段讲解工程项目的开发过程,以及实训裁剪掉一些过程的原因。
1、项目过程定义、时间分解均已确定。
2、实训的项目源于真实项目的裁剪,需求已经明确,由实训师直接发放《需求规格说明书》和静态原型,实训的需求调研和获取均裁剪掉。
基于上述两条,实训开发直接进入项目计划里程碑。
评审:
在项目启动时,讲解《评审过程指南》,约20分钟。
介绍评审的概念、种类和方法。
规定实训使用的评审方法,里程碑评审为主,小组内可采用同行评审,二次评审采用单人评审。
对于评审提出的问题经实训师确认需要修正的,修正的时间不超过0.5个工作日;修正完成后,助理实训师与修正人进行单人评审并将结果入基线库。
如修正后仍存在问题,可组织小范围的二次同行评审,参加人由助理实训师和项目经理确定。
对于两次评审仍未通过的项目组,将不再让其修改,而直接使用其他项目组的成果或项目总监推荐的成果。
评审工作量较大,实训师的主要是职责是确认评审中提出的问题是否是需要真正修正的问题,助理实训师的主要职责是跟踪评审的各环节,修正后的单人评审,并及时与实训师沟通问题的性质和解决方案。
1、评审的修正在评审时即应确定修正人,并严格控制完成的时间,否则将影响下一阶段的工作。
2、当某个项目组的上一阶段里程碑的工作成果未通过评审时,下一阶段不但使用其他组或实训师推荐的工作成果,同时应采用其全部的开发计划。
通常应避免这种情况产生,如发现某组的开发工作确实难以进行,可考虑解散该组,将成员分至其它组。
评测
学生的最终实训成绩由两个部分组成:
项目组成绩60%,个人表现40%。
其它
实训师在教师机上建立共享目录,各组的里程碑评审成果直接向目录中提交,助理实训师负责目录的监督和管理。
实训师对项目工程术语进行解释。
立项
输入
《需求规格说明书》
静态原型
活动说明
Ø项目总监讲授立项时的流程和工作内容
Ø项目总监解释《项目计划书》、《配置管理计划》和《测试计划书》中的关键点,并发放三种计划书的模板。
Ø项目经理组织项目组成员书写《项目开发计划》、《配置管理计划》和《测试计划》。
Ø立项里程碑评审:
项目总监组织安排《项目开发计划》、《配置管理计划》和《测试计划》评审。
若评审组认为以上内容存在问题,需将该问题整理出来并在评审会上指出,由本项目组专人记录所有问题。
Ø评审过程:
参见附录之“评审过程”
输出
评审通过并已经纳入基线的《项目开发计划》
评审通过并已经纳入基线的《配置管理计划》
评审通过并已经纳入基线的《测试计划》
《立项评审报告单》
立项参考:
项目主要开发信息
项目名称
项目名称
项目编号
**-001
客户名称
项目客户方
客户负责人
N/A
开始日期
年-月-日
结束日期
年-月-日
项目经理
各项目组组长
客户代表
N/A
项目组织及角色
角色
姓名
电子邮件
电话
项目总监
指导教师
客户经理
N/A
项目经理
项目组组长
技术经理
项目组副组长
咨询顾问
指导教师
质量保证员
N/A
软件工程师
项目组成员
测试工程师
项目组成员
数据库管理员
项目组成员
配置管理员
项目组成员
项目总体计划
项目预计需要*周的时间,*年*月*日代码开发完毕。
*月*日系统测试,*年*月*日结项。
项目阶段
开始时间
结束时间
主要工作产品
项目启动
*年*月*日
*年*月*日
项目计划
需求
*年*月*日
*年*月*日
Usecase,用例规约,测试用例
设计
*年*月*日
*年*月*日
UML模型,测试用例
开发
*年*月*日
*年*月*日
源代码
测试
*年*月*日
*年*月*日
测试报告
结项
*年*月*日
*年*月*日
项目总结报告
里程碑提交产品
里程碑
提交产品
提交时间
负责人
立项
项目开发计划
*年*月*日
项目经理
测试计划
*年*月*日
项目经理,测试经理
配置管理计划
*年*月*日
项目经理,配置管理员
需求
用例模型,用例规约
*年*月*日
技术经理
设计
UML模型
*年*月*日
技术经理
数据库设计
*年*月*日
数据库管理员
测试用例
*年*月*日
测试经理,技术经理
SolutionModel
*年*月*日
技术经理
编码
代码
*年*月*日
技术经理
测试
测试总结报告
*年*月*日
测试经理,技术经理
结项
项目总结报告
*年*月*日
项目经理
评审
按计划需要评审的工作产品,以及采用的评审方式和参加评审的人员。
评审方式是里程碑评审为主,小组内可采用同行评审,二次评审采用单人评审。
工作产品
评审方式
评审参与人员
评审材料发放时间(提前X天)
计划
里程碑评审
项目总监、项目组成员
1
用例规约
里程碑评审
项目总监、项目组成员
1
UML模型和测试用例
里程碑评审
项目总监、项目组成员
1
代码
代码走查
项目总监、项目组成员
1
测试报告
里程碑评审
项目总监、项目组成员
1
开发环境
硬件
软件
实训开发环境:
每生一台PC机或笔记本:
PIV2G以上
1G-2G内存
硬盘80G以上
开发服务器或测试服务器一台
应用服务器:
WebSphereApplicationServer6.1
数据库:
DB2Express9.1
开发工具:
RationalApplicationDeveloper7
UML建模工具:
RationalSoftwareArchitect7
配置管理工具:
CVS
数据库设计工具:
实训师指南:
学生通常对于项目计划中项目管理概念理解不清或有误,实训师可同时向所有成员发放《项目经理手册》,但只做简要讲解,项目组的管理由项目经理全面负责,因此项目经理必须熟读该手册并遵照执行。
需要清楚地解释是的项目经理与技术经理的职责区别,以便在项目开发中使成员能明确自己的职责,及发现问题如何解决的方法。
实训师已经定义好了项目过程和进度,因此项目计划中的WBS表按照实训时间表即可完成。
实训师需向学生解释三种项目计划模板中的关键要点,需要助理实训师跟踪计划书写的情况,及时纠正问题。
学生对计划的重视程度可能不够,但实际写时又觉得难度较大。
实训师可强调该阶段主要目的是使学生了解计划的重要性和可行性,项目的过程和时间分解已经在学生指导手册和实训时间表中确定。
因此多数项目组的计划应该大同小异,可鼓励项目组之间互相参考。
注意,不应出现与其它项目组完全不同的项目计划。
开发工具必须选用以上IBM软件产品,机器配置应达到要求。
需求分析过程
角色说明
角色
职责
项目总监
指导面向对象需求分析的过程,指导项目组理解需求和评审
项目经理
协调项目组资源,与技术经理协商决定本阶段的人员分工,并按照协商结果分配任务并监督执行情况,参与本阶段部分工作
技术经理
配合项目经理,带领项目组进行面向对象的需求分析,进行用例建模,书写《用例规约》;负责技术难点的解决和培训
测试经理
带领测试人员全面了解需求,按照测试计划启动《测试用例》,并开始书写部分需求明确的测试用例,反复与需求分析人员沟通,确保对需求理解一致
输入
《需求规格说明书》
静态原型
《用例规约》、《数据字典》、《关键抽取》、《域模型设计》和《测试用例》模板
活动说明
Ø项目总监讲解面向对象需求分析的过程,并简要说明项目裁剪掉的部分需求阶段工作
Ø项目经理和技术经理经协商,决定任务分配原则并进行人员分工。
Ø技术经理以会议或内部培训形式带领项目组成员理解《需求规格说明书》和原型,确保全组成员对需求理解一致;若大家对于需求的理解存在疑问,项目经理(或指定组员)将这些疑问记录在《需求问题跟踪》中,并针对这些问题咨询项目总监,并将答复的信息也记录在《需求问题跟踪》中,项目经理确保项目组中的每一位成员都理解了需求
Ø配置管理员按配置管理计划建立配置管理库,并监督全组人执行
Ø各成员按分配的任务进行面向对象的分析工作,进行UML建模:
⏹用例建模:
使用IBMRSA进行用例建模,画出与需求一致的全部用例图
⏹精化用例:
项目总监讲解并指导用例规约,按《用例规约》模板书写用例规约文档
⏹关键抽取:
项目总监讲解并指导关键抽取,按《关键抽取》模板书写关键抽取文档
⏹域模型设计:
项目总监讲解并指导域模型设计,使用IBMRSA进行域模型设计,并按《域模型设计》模板书写域模型设计文档
Ø项目总监发放《测试用例》模板并讲解,测试经理按照测试计划启动《测试用例》,并开始书写部分需求明确的测试用例,测试人员需反复与需求分析人员沟通,确认对需求理解一致
Ø技术经理指定一名成员书写《数据字典》文档,包括项目组文档命名规范,项目中专用名词及页面中数据的约定
Ø需求里程碑评审:
项目总监组织安排《用例规约》、《关键抽取》和《域模型设计》评审。
若评审项目组人员认为以上评审内容存在问题,需将该问题整理出来并在评审会上指出,由本项目组专人记录所有问题
Ø评审过程:
参见附录之“评审过程”
输出
评审通过并已经纳入基线的《用例规约》
评审通过并已经纳入基线的《数据字典》
评审通过并已经纳入基线的《关键抽取》
评审通过并已经纳入基线的《域模型设计》
《需求评审报告单》
实训师指南:
需求工程分为需求管理和需求开发。
实训项目的需求管理基本裁剪,因为实训不存在需求变更。
实训师必须强调需求变更是项目的天然特性,实训的需求不变更是理想状态,现实中是不存在的。
同时讲解SCCB在需求变更中的重要作用,以及一些常用的需求变更管理方法。
说明需求开发的四个阶段:
需求开发准备、需求获取/调研、需求分析和需求验证。
实训只做需求分析过程,需求验证因为无法与客户交流而裁剪。
需求分析使用面向对象的分析方法,用例图使用RSA工具制作,助理实训师进行15分钟的RSA工具使用的讲解。
学生实训前学习过用例图的制作,此处不必再细讲usecase的理论,可举例说明usecase实用的原则和易犯的错误。
用例规约的书写是用例精化的重要步骤。
实训项目的需求相对不复杂,因此用例之间的关系也比较简单。
用例规约的难点就在于学生不了解如何书写,以及文字上的随意性和不专业性。
全部纠正有难度,可在评审时指出,但允许部分文字的不专业性,以确保学生对需求理解正确,并不影响未来的设计为准。
书写用例规约时,可借助活动图来验证基本事件流和其它事件流的合理和正确,确保覆盖所有需求。
用例决定了未来的设计和编码,其重要性可多次强调。
可督促项目组在里程碑评审前在组内多次同行评审。
关键抽取的目的是确定实体类和属性,域模型设计是最终精化实体类的属性和并确定这些类之间的关系。
这两项难度都不大,助理实训师可承担指导。
数据字典决定了项目开发的规范性,并可降低管理成本。
学生在学校学习期间对此几乎没有关注,可能最初无法理解或根本忽视,在几次错误或失败后,可能会深有体会,并逐步改变对规范的看法。
设计过程
角色说明
角色
职责
项目总监
指导面向对象设计的过程,定义基本的软件技术架构,指导评审
项目经理
协调项目组资源,与技术经理协商决定本阶段的人员分工,并按照协商结果分配任务并监督执行情况,参与本阶段部分工作
技术经理
配合项目经理,带领项目组进行面向对象设计,进行UML建模,书写相关文档;指导DBA进行数据库设计;负责技术难点的解决和培训
测试经理
继续书写并完成全部《测试用例》,反复与设计分析人员沟通,确保对需求理解一致
输入
《需求规格说明书》
静态原型
评审通过并已经纳入基线的《用例规约》
评审通过并已经纳入基线的《数据字典》
评审通过并已经纳入基线的《关键抽取》
评审通过并已经纳入基线的《域模型设计》
《鲁棒分析》、《解决方案说明书》、《数据库设计说明书》和《测试用例》模板
活动说明
Ø项目总监讲解面向对象设计的过程,定义基本的软件技术架构,提出数种项目组可以使用的技术架构和模式,但不限定项目组使用的模式和框架
ØDBA根据需求和《数据字典》进行数据库设计(可以先产生“E-R”),并按照模板书写《数据库设计说明书》
Ø延续需求分析阶段的分工,各成员继续依照上阶段的工作成果进行面向对象的设计,进行UML建模
◆鲁棒分析:
项目总监讲解并指导鲁棒分析,使用IBMRSA进行鲁棒分析,建议通过序列图和协作图进行分析,并按《鲁棒分析》模板书写鲁棒分析文档
◆解决方案:
项目总监讲解并指导解决方案,项目经理和技术经理依据项目成员的技术能力选择解决方案要使用的设计模式或框架,并按《解决方案说明书》模板书写解决方案说明书文档
Ø测试经理带领测试人员按照《测试计划》和《需求规格说明书》继续书写《测试用例》,反复与设计分析人员沟通,确保对需求理解一致
Ø设计里程碑评审:
项目总监组织安排《鲁棒分析》、《解决方案说明书》、《数据库设计说明书》和《测试用例》评审。
若评审项目组人员认为以上评审内容存在问题,需将该问题整理出来并在评审会上指出,由本项目组专人记录所有问题
Ø评审过程:
参见附录之“评审过程”
输出
评审通过并已经纳入基线的《鲁棒分析》
评审通过并已经纳入基线的《解决方案说明书》
评审通过并已经纳入基线的《数据库设计说明书》
评审通过并已经纳入基线的《测试用例》
《设计评审报告单》
《用例评审报告单》
实训师指南:
该里程碑使用面向对象的设计方法,使用RSA工具进行UML建模。
鲁棒分析是设计的关键,可通过制序列图或协作图实现设计,组内可进行多次同行评审。
最终的解决方案,不限定使用何种技术架构,但要提醒技术经理和项目经理使用何种技术架构要看项目组成员的技术水平,以实现为原则,不以技术先进性为原则。
可推荐某些开源框架。
由于学生可能不熟悉鲁棒分析和解决方案的方法,可能初步的UML模型存在许多缺陷和错误。
为验证UML模型的正确性和可行性,部分设计与开发工作可迭代进行,即某些设计完成的模型可先用代码实现,来验证设计的正确性。
测试用例在需求和设计阶段都会进行,在设计阶段完成。
确保测试用例能覆盖全部需求,测试人员对需求的理解甚至要高于编码人员。
DBA负责完成数据库设计和《数据库说明书》的书写,同时要完成数据库的建立,建表及初始化数据。
并建立项目组成员开发或测试时使用的用户名和密码,管理员密码只有DBA自己保存。
编码过程
角色说明
角色
职责
项目总监
指导编码过程,发放编码规范,指导代码走查
项目经理
协调项目组资源,与技术经理一起分解开发任务;编码
技术经理
配合项目经理,分配任务单;主持编码工作和代码走查
编码人员
进行编码工作;代码走查
输入
评审通过并已经纳入基线的《解决方案说明书》
评审通过并已经纳入基线的《数据库设计说明书》
《编码规范》
静态原型
活动说明
Ø项目总监讲解编码过程,发放编码规范,编码人员必须严格按照编码规范进行编码工作
Ø项目经理和技术经理根据《软件项目开发计划》安排编码人员的工作,以《开发任务单》(即最小化任务)的形式发放任务
Ø编码人员接收到《开发任务单》后,要确保开发人员清楚其任务的需求和设计(可找技术经理进行讲解,或由项目经理安排技术经理专门进行讲解),推荐延续设计的分工对编码进行合理的分工。
Ø编码工作中如有技术上的疑问,可通过组成员间讨论沟通解决,也可通过internet寻找解决方法,不能确定或有争议,由技术经理来安排解决
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 实训师 指导 手册