前言:想要写出一篇令人眼前一亮的文章吗?我们特意为您整理了5篇图书管理可行性分析报告范文,相信会为您的写作带来帮助,发现更多的写作思路和灵感。
一个班的学生分成若干虚拟的产品团队,每个产品团队按照图1的组织架构搭建。其中开发代表1人,对这个产品团队负责,代表用户的利益;质量设计员1人,负责指导各个小组遵守公司的流程规范;开发小组A和B工作完成某个项目,每个小组人数5~7人,设项目经理、配置管理员、度量协调员各1人,程序员若干;测试小组由1名项目经理和3~5位测试员组成。在此基础上设置变更控制委员会,由指导老师、质量审计员和开发代表组成,负责对软件开发过程中的变更进行审核和授权。通过这种架构基本虚拟了一个比较完整的项目团队。
以一个简单的图书馆图书管理系统为例,开发小组A完成书刊的借阅归还管理,开发小组B完成书刊采购入库管理,两个小组协同完成一个项目,这样的项目并没有标准答案,需要学生积极主动地和开发代表交流完成需求分析,两个小组之间要协调好接口,同时要和测试团队配合修改软件测试发现的缺陷。具体团队的人选由学生自己讨论决定,当然我们在理论教学阶段已经把各个角色的职责定义明确,学生可以根据自己的兴趣选择适合自己的角色。为了调动学生的积极性,我们对项目中的关键角色:开发代表、质量审计员、项目经理、测试经理、配置管理员、度量协调员采取额外的奖惩措施,即:小组成绩在优秀以上的关键角色可以获得加分,否则扣分。在角色选择时,无法避免地会产生冲突,例如:两名同学都要争着当项目经理,这个时候指导老师一般不干预,仅仅规定最后的期限,要求学生在1个小时内组织起团队,这样锻炼学生团队合作的精神。
1软件生命周期管理教学
在教学过程中我们需要培养学生软件生命周期的意识,即让学生认识到一套软件不是听到需求后直接上手写代码,代码写完就意味着项目结束,而是有一套标准的规范和流程来指导整个软件的开发过程。总体来看,软件生命周期由软件定义、软件开发和运行维护三个阶段组成。软件定义阶段详细来说有问题定义、可行性分析和需求分析三个阶段,在教学中我们要求开发代表下发“工作任务书”完成问题的定义,因为项目相对比较明确和简单,我们忽略可行性分析阶段,在需求分析阶段我们要求小组输出最终的经过评审通过的需求规格说明书。这个阶段主要培养学生将问题和需求文档化的能力,这个阶段学生往往“蠢蠢欲动”,急于编写代码,指导老师要参与每个小组需求评审的过程,指出需求中模糊的不够明确的地方,引导学生输出规范的文档。这个阶段同时要输出系统测试用例,系统测试用例要经过测试小组评审和认可。
开发阶段由总体设计、详细设计、编码和单元测试、集成测试和系统测试以及验收测试组成。考虑到项目的规模,我们把总体设计和详细设计合并为一个阶段,只要求学生输出一份设计文档,这个阶段指导老师要关注学生的设计方案是否全面覆盖需求点,一般通过需求跟踪矩阵可以看出。编码和单元测试阶段除了要求学生的代码符合约定的编码规范外,重点是关注单元测试的覆盖率是否满足要求,这个阶段锻炼学生设计和执行白盒测试的能力。集成测试和系统测试因项目规模较小,一般综合为系统测试,由各自的开发小组完成,验收测试由测试小组完成。系统测试一般进行三轮,测试过程中的每个问题要都要由测试人员填写缺陷报告并提交项目经理审核,修改后的验收测试结果也需要提交项目经理审核。质量审计员需要关注每轮测试的缺陷率是否是收敛的趋势,并和项目经理一起给出测试分析报告。
验收小组按照项目系统测试用例进行验收,同时进行发散测试,这个阶段锻炼学生黑盒测试的能力。验收测试的每个问题也要由测试人员提缺陷报告,测试经理审核后转开发经理确认是否是问题,由开发经理转相关开发人员修改,修改后开发经理确认,测试人员回归测试,这样保证每个问题都是闭环。
项目的维护阶段是一个比较长的阶段,在真实项目中,一般占整个软件生命周期的80%,在miniProject项目中,我们通过软件的适应性修改来让学生学习软件维护阶段的相关概念和应该遵守的流程,并强调如何保障软件维护的质量。
2关键软件过程教学
软件的质量需要通过一套完整的流程和过程来保障。在教学实践中,我们把一些软件中的重要流程固定化,使学生体验到高质量的软件项目所必须经历的过程。评审在软件工程贯穿项目的需求、设计、编码的每个阶段,评审组织者一般先进行评审讲解,使各位评审者对需要评审的工作有一个明确的认识,各个评审人单独进行评审后,评审组织者需要对评审意见逐一确认。评审组织者一般为项目经理,需求文档的评审人一般为开发代表、配合小组和测试团队,设计文档的评审人一般为小组内部和需要软件接口配合的小组。通过评审阶段的活动使得学生认识到软件开发不仅是个体行为,而是这个组织的一套有序行为,个人需要在组织规范内行动,通过严格执行组织的流程规范保证软件的质量。
配置管理是软件项目管理中一项基本内容,是软件质量保证的重要一环,这一工作主要由配置管理员执行,其主要职责是控制变更、版本标志、配置审计和配置状态。通过引入配置管理使学生认识到软件版本变化的可回溯性,可跟踪性。软件项目并不仅仅是交付一个产品,其中间的每个阶段的历史、基线和分支对回溯软件的质量,保证软件修改的有序进行有重要的作用。试验中,学生也学会基本软件版本管理工具(如:SourceSafe、SVN)的使用,掌握Checkin、Checkout、update等基本操作,了解基本的团队协作开发的环境。
软件度量是CMM4级的一个关键过程域,为了配合本次课程改革,我们设计了软件度量表,其中包含:需求点的个数、测试例个数、投入人力、测试发现的缺陷等信息,由度量协调员负责这些数据的收集,质量审计员和项目经理在每个阶段需要对收集的这些量化数据分析,分析项目进行过程中存在的问题。通过引入软件度量,我们使学生理解到软件开发过程是可控的,通过一些量化的指标可以了解软件项目的运行状态,为软件项目的管理提供决策依据。
变更控制是减少软件开发的随意性,保障软件质量的一项关键措施。变更控制是指对每个阶段文档基线化后,因为需求的变化、重大缺陷或相互配合导致的软件变更作评审、授权的管理活动。为模拟现实中的变更控制,在软件编码阶段我们假设用户要求追加一个新的小需求。为满足用户的这种变化,开发小组需要评审新增需求对现有软件项目进度的影响、对设计方案的影响,并向变更控制委员会(由指导老师、开发代表、质量审计员组成)提交变更申请,经评审后修改需求文档和设计文档并重新基线化然后配置状态。通过这样一次变更使得学生认识到软件项目中的变更是经常存在的,为了使得变更有序和可控,需要一套流程和规范来管理软件的变更。
教学体会
通过两个班级一个学期的教学实践,学生普遍觉得原来枯燥的软件工程原理在实践中学来的和由老师灌输的有很大区别。所谓“纸上得来终觉浅,绝知此事要躬行”,通过一个miniProject可以将软件工程课程中的很多内容融入到实训中,让学生通过项目实践理解和体会“工程”的思想,并主动规范地执行一些关键的软件过程,一些同学甚至提出了一些对流程优化的小点子,这实际上已经是CMM5级的持续软件过程改进的一些苗头,这说明通过这种方式,学生更愿意积极主动地学习。