当前位置: 首页 > >

软件过程综合实践第1讲

发布时间:

软件过程综合实践
郑大鹏 fszdp1@gmail.com

第1讲 实践要求及开始阶段要点 讲
内容
本实践课要求 如何开始实践项目 目的 了解实践目标、内容、 了解实践目标、内容、组织形式 复*软件项目起始阶段工作内容、 复*软件项目起始阶段工作内容、方法

本实践课要求
本实践属于必修课, 学分 学分; 本实践属于必修课,4学分; 要求综合应用所学软件开发知识, 要求综合应用所学软件开发知识,在四周 内完成一个软件项目 目标:通过本课程,达到以下五项目标。 目标:通过本课程,达到以下五项目标。

本实践课要求
1.能理解客户的总体需求,并进而识别系统 .能理解客户的总体需求, 的范围,发掘系统的详细需求, 的范围,发掘系统的详细需求,编写有关需求 阶段文档; 阶段文档; 2.能根据需求确定系统的测试方案, 2.能根据需求确定系统的测试方案,编写测 试计划,准备测试用例; 试计划,准备测试用例; 3.能根据需求确定系统的设计,并将设计文 .能根据需求确定系统的设计, 档化。理解设计的要素和工作过程; 档化。理解设计的要素和工作过程;

本实践课要求
4.能用所学的程序设计知识,将系统设计转 .能用所学的程序设计知识, 化为代码,并进行测试和排错。 化为代码,并进行测试和排错。所设计的代码 应有良好的风范; 应有良好的风范; 5.理解软件开发的过程, 5.理解软件开发的过程,学会组织和管理一 个软件开发项目。 个软件开发项目。懂得软件项目中不同角色的 定位和工作任务, 定位和工作任务,学会与项目团队成员间的沟 通和协调。 通和协调。

本实践课要求
实践题目: 实践题目:
根据老师列出的题目,挑选一个; 根据老师列出的题目,挑选一个; 信息系统、电子商务网站。 信息系统、电子商务网站。

可以在原来课程设计基础上进一步深化, 可以在原来课程设计基础上进一步深化, 也可以结合毕业设计的选题。 也可以结合毕业设计的选题。 建议以小组为单位完成。每小组4~5人; 建议以小组为单位完成。每小组 人

本实践课要求
小组成员分工( 人一组 人一组): 小组成员分工(4人一组):
项目管理+系统分析 代码编写 项目管理 系统分析+代码编写 系统分析 架构设计+代码编写 架构设计 代码编写 测试+代码编写 测试 代码编写 数据库设计+代码编写 数据库设计 代码编写

代码、文档可以分工完成。要注明完成者, 代码、文档可以分工完成。要注明完成者, 以便评分。代码要注意规范,必须有头注。 以便评分。代码要注意规范,必须有头注。 文档要按照模板格式写。 文档要按照模板格式写。

本实践课要求
项目过程和文档要求 过程实践 文档 项目开发计划 项目范围识别和规 或:愿景 划 需求分析 系统需求规格说明 总体设计(架构设 计) 详细设计 代码实现 测试 交付 系统设计说明 无 系统测试计划 系统使用说明书 10% 10% 权重 10% 30% 40%

本实践课要求
编程要求
功能或特性 界面友好, 风格统一 功能导航、 在线帮助 说明 技能项 界面设计 界面类的定义或使用 菜单导航 在线帮助 输入验证 用户注册和 登录 数据库连接与查询 事件响应方法的设计应 用 5% 10% 5% 5% 10% 5% 5% 5% 5% 15% 权重

本实践课要求
编程要求
业务数据的 显示与输出 数据集合的获取 数据集合的显示 关联数据的显示 打印输出 数据实体类的定义和使 用 业务数据的 采集 单表数据采集 关联数据的采集 5% 5% 5% 5% 5% 5% 5% 15% 20%

本实践课要求
编程要求
业务处理 与外部 连接 业务类的定义使用 事务处理 第三方组件的使用 5% 5% 5% 15%

基础数据的增、删、 5% 改 基础数据 维护 数据加密解密 权限控制 5% 5% 15%

本实践课要求
提交要求

制品名 项目开发计 划或愿 景

提交形式与命名 Word文档 命名: <学号_姓名 >_ProjectPlan.doc <学号_姓名>_Vision.doc Word文档 命名:<学号_姓名 >_SRS.doc Word文档 命名:<学号_姓名 >_Design.doc Word文档 命名:<学号_姓名 >_TestPlan.doc Word文档 命名:<学号_姓名 >_Manual.doc rar压缩文档 命名:<学号_姓名 >_Code.rar

提交时间 第一周星期 二上午

系统需求规 格说明 系统设计说 明 系统测试计 划 系统使用说 明 系统代码

第一周星期 三上午 第二周星期 一上午 第二周星期 三上午 第四周星期 三到星 期五 第四周星期 三到星 期五

本实践课要求
考核方法: 考核方法:

考核项 考勤与纪律 文档 作品 答辩

占总分比例 10% 35% 35% 20%

本实践课要求
考核方法: 考核方法:
一个小组各组员的得分, 一个小组各组员的得分,以小组提交的作品得分为 基准,考虑小组成员的表现进行上、下浮动。 基准,考虑小组成员的表现进行上、下浮动。 表现可以从考勤、完成的工作和答辩表现看出。 表现可以从考勤、完成的工作和答辩表现看出。

答辩:由于元旦放假,答辩必须在 月 日结 答辩:由于元旦放假,答辩必须在12月31日结 如果小组提前完成了的,可以提前于28日 束。如果小组提前完成了的,可以提前于 日 开始进行答辩。最迟不能迟于12月31日下午。 开始进行答辩。最迟不能迟于 月 日下午。 日下午 答辩的条件是必须提交文档和代码, 答辩的条件是必须提交文档和代码,并能演示 代码。 代码。

如何开始实践项目
组队、分工、 组队、分工、选题 业务分析 项目范围识别 系统功能需求识别与记录 系统非功能需求识别与记录 确定核心功能和性能 需求阶段的文档 工作安排

组队、分工、 组队、分工、选题
由于本实践课的目的之一是要模拟真实工 作环境,让大家亲身经历软件开发过程, 作环境,让大家亲身经历软件开发过程, 因此, 因此,要求大家尽量以小组方式开展实践 但每组人数不能太多。建议4人 最多5人 但每组人数不能太多。建议 人,最多 人。 每个人要有明确的分工。 每个人要有明确的分工。在最后完成的文 档和代码中, 档和代码中,每个人要在完成品上注明自 己的姓名。 己的姓名。

组队、分工、 组队、分工、选题
要求大家从老师提供的选题中选择; 要求大家从老师提供的选题中选择; 因为老师作为所有系统的需方, 因为老师作为所有系统的需方,要向学生 解释系统的需要。针对这些题目, 解释系统的需要。针对这些题目,老师事 先已经作了大量的准备。 先已经作了大量的准备。 原则上,每个小组的题目要求不同。 原则上,每个小组的题目要求不同。

业务分析
选定题目后, 选定题目后,首先要了解课题所涉及的业 务领域及其业务运行规则; 务领域及其业务运行规则; 在此活动中,需要反复向需方了解。 在此活动中,需要反复向需方了解。本实 践中,由老师模拟需方的代表。 践中,由老师模拟需方的代表。 所谓业务分析,就是搞清楚业务对象, 所谓业务分析,就是搞清楚业务对象,业 务活动,活动的流程及规则。 务活动,活动的流程及规则。

业务分析
例如,业务服务对象是谁, 例如,业务服务对象是谁,服务内容有那 过程如何,规则如何。 些,过程如何,规则如何。服务活动涉及 那些概念、物品、设施等。 那些概念、物品、设施等。 业务分析的结果可以用文档记录, 业务分析的结果可以用文档记录,也可以 不写入文档。这要看系统业务是否复杂。 不写入文档。这要看系统业务是否复杂。 对于很简单的系统或业务, 对于很简单的系统或业务,业务分析所用 时间可以很短( 分钟)。 时间可以很短(如30分钟)。 分钟

项目范围识别
所谓项目范围识别, 所谓项目范围识别,是指与需方探讨和确 认在业务活动中, 认在业务活动中,那些活动或者活动的流 程由软件完成,那些是在软件之外进行的。 程由软件完成,那些是在软件之外进行的。 也可称为软件系统边界识别。 也可称为软件系统边界识别。 一个必须明白的事实是, 一个必须明白的事实是,开发软件就是在 建造一个基于计算机的系统。 建造一个基于计算机的系统。基于计算机 的系统, 的系统,不一定所有活动都要由软件系统 完成。例如,有些过程必须由人工完成, 完成。例如,有些过程必须由人工完成, 有些由其他的系统(也可能是软件)完成, 有些由其他的系统(也可能是软件)完成, 但在我们要构建的软件系统之外。 但在我们要构建的软件系统之外。

项目范围识别
项目范围识别有时候是很容易的, 项目范围识别有时候是很容易的,有时候 需要认真权衡。例如, 需要认真权衡。例如,有的过程既可以由 人工完成, 人工完成,也可以由机器设备或者软件完 究竟该如何做呢? 成。究竟该如何做呢? 这要考虑系统的成本、工期、业务量、 这要考虑系统的成本、工期、业务量、服 务质量等各种因素。 务质量等各种因素。 既要考虑需方的意愿, 既要考虑需方的意愿,也要给需方合理的 建议。 建议。

系统功能需求识别与记录
确定系统边界后,从边界入手, 确定系统边界后,从边界入手,可以方便 地识别系统需求。 地识别系统需求。 主要考虑有哪些处在边界外的对象或系统 需要与系统发生交互 在交互过程中,需要向系统输入什么, 在交互过程中,需要向系统输入什么,或 者得到什么; 者得到什么; 交互的过程(活动及步骤)是怎样的。 交互的过程(活动及步骤)是怎样的。

系统功能需求识别与记录
用例模型就是基于上述思想的需求模型。 用例模型就是基于上述思想的需求模型。 在用例模型中,系统由用例构成, 在用例模型中,系统由用例构成,操作者 (actor)处在系统边界之外与用例发生交 ) 互。 需求方法中的用例法, 需求方法中的用例法,其大致思路是先识 别系统的操作者, 别系统的操作者,然后分析每个操作者有 哪些用例,将用例的步骤描述出来。 哪些用例,将用例的步骤描述出来。

系统非功能需求识别与记录
用例一般用来描述系统的功能性需求。 用例一般用来描述系统的功能性需求。而 非功能性需求也很重要; 非功能性需求也很重要; 非功能性需求包括性能、伸缩性、 非功能性需求包括性能、伸缩性、可维护 安全性、*台要求等。 性、安全性、*台要求等。 非功能性需求一般也是在分析用例的过程 中发现的, 中发现的,也有一些是在专门的过程识别 需要开发经验和对业务的深入理解。 的。需要开发经验和对业务的深入理解。

系统非功能需求识别与记录
非功能性需求如果与特定的用例有关, 非功能性需求如果与特定的用例有关,也 可以记录在用例文档中; 可以记录在用例文档中; 但很多非功能性需求都是关于全局的, 但很多非功能性需求都是关于全局的,所 以放在用例说明中不合适。 以放在用例说明中不合适。一般将非功能 性需求放在补充规格说明书中。 性需求放在补充规格说明书中。

确定核心功能和性能
系统的功能和性能要求中, 系统的功能和性能要求中,有些对系统是 最核心和根本的, 最核心和根本的,这部分功能和非功能需 求往往会决定系统的成败, 求往往会决定系统的成败,影响系统的总 体设计(架构设计),称为架构因素; ),称为架构因素 体设计(架构设计),称为架构因素; 在项目开始早期,要识别这些关键的需求, 在项目开始早期,要识别这些关键的需求, 以免设计时不能满足要求, 以免设计时不能满足要求,造成返工或者 项目失败。 项目失败。

需求阶段的文档
愿景(Vision):此文档的目的是收集、分析 :此文档的目的是收集、 愿景 及定义要开发系统的高层需求和特性。 及定义要开发系统的高层需求和特性。重 点关注系统各相关方及目标用户的能力需 以及这些需要存在的理由。 要,以及这些需要存在的理由。 关于系统如何满足这些需要的细节, 关于系统如何满足这些需要的细节,在用 例和补充规格说明书中说明。 例和补充规格说明书中说明。

需求阶段的文档
用例说明:功能需求描述; 用例说明:功能需求描述; 补充规格说明:非功能需求描述。包括: 补充规格说明:非功能需求描述。包括:
法律及规章符合要求,包括应用标准的遵从; 法律及规章符合要求,包括应用标准的遵从; 系统的质量特性,包括可用性、可靠性、 系统的质量特性,包括可用性、可靠性、性能 及支持性。 及支持性。 诸如操作系统及环境、 诸如操作系统及环境、兼容性及设计限制等方 面的需求。 面的需求。

需求阶段的文档
系统需求规格说明书( ):包含功能 系统需求规格说明书(SRS):包含功能 ): 和非功能需求说明。可以将前述用例、 和非功能需求说明。可以将前述用例、补 充规格说明的内容集中到此文档中。 充规格说明的内容集中到此文档中。 在上交文档时, 在上交文档时,只需要交这一个文档就行 了。 如果分开写用例说明和补充规格说明, 如果分开写用例说明和补充规格说明,不 写此文档也可以(不必重复)。 写此文档也可以(不必重复)。

工作安排
今天3~4节完成分组和选题,向指导老师了 节完成分组和选题, 今天 节完成分组和选题 解题目的需求; 解题目的需求; 下午到实验室完成愿景或项目开发计划 请大家自备u盘每日备份自己的工作 盘每日备份自己的工作)。 (请大家自备 盘每日备份自己的工作)。 明天早晨1~2节继续到本教室集中授课。 节继续到本教室集中授课。 明天早晨 节继续到本教室集中授课 有关课件和文档模板请上网络教学综合* 台下载。 台下载。

题目: 题目:
郑老师
网上电子商务系统(可以是各种不同业务) 网上电子商务系统(可以是各种不同业务) 医院挂号系统 教务管理系统 图书馆管理系统 汽车运输管理系统 快递业务系统 商业进销存管理系统

题目: 题目:
肖老师
短信管理系统 通用权限管理系统 文件共享系统(网盘) 文件共享系统(网盘) 邮件收发系统 投票管理系统

题目: 题目:
旷老师
中药计价系统 订单管理系统 合同管理系统 网上论坛 客户管理系统 权限管理系统




友情链接: