前景与范围文档.doc

前景与范围文档目录1 业务需求31.1 应用背景31.2 业务机遇41.3 业务目标与成功标准41.4 业务风险62 项目前景72.1 前景概述72.2 主要特性82.3 假设与依赖93 项目范围93.1 版本范围93.2 限制与排除104 项目环境104.1 操作环境104.2 涉众114.3 项目属性11词汇表13参考资料131 业务需求1.1 应用背景目前在南京大学软件学院，无论是专业课程还是比赛项目，大部分的软件项目都是组队完成的，这是为了提高学生的创新能力和动手能力，增加软件开发的经验，为将来更好地进入工作岗位。学生每学期都要进行1至4个课程的组队开发项目，因此学生常常需要组队并开发。然而，很多同学因为组队信息范围的局限以及信息时效性的低下，大多数同学经常会遇到想与其组队的同学已经组好队、找不到同学凑足名额、不知道还有哪些同学没有组队、人员分配尴尬、找不到合适的同学等局面。很多同学为找不到合适的队友而苦恼，信息交流范围很局限并且信息时效性不高，因此老师也需要留较长的时间供同学组队，并且最后老师还需要统计组队同学，为没有组好队的同学组队。这着实是件麻烦的事情。同时，组队完成后开始做项目时，组员之间需要通过qq、邮件、msn、短信等工具或软件进行交流讨论或者传递文档，没有固定的软件供组员讨论传递信息，信息交换效率与透明度较低。另外，非同一组的同学也需要进行交流，而同学会因为没有对方邮箱地址、qq号码、手机号码等而无法直接与其交流，甚至会导致影响项目的进度或质量，这也是一个很大的麻烦。另外，老师对同学的组队情况需要助教或自己借助Excel等统计工具整理才能清楚了解，还要为没有组队的同学组队，并且有时会面临着各种各样的状况使得组队结果一改再改。老师平时在TSS上发布信息时，同学无法立刻判断与项目相关与否。老师发布的关于项目的信息不够集中直观，没有平台以提供老师与同学集中进行项目开发所必须的信息交流空间。1.2 业务机遇 南京大学软件学院所有同学都通过学院的一个实行实名制的组队系统进行组队，并且在系统上进行信息的交流，软件学院的老师通过这个组队系统了解同学组队情况，并且通过这个系统向同学发布与项目有关的各种信息。 这样，对于软件学院的同学来说，组队不再是困扰，可以很直观地了解到他人组队的所有情况，不会再遇到不知道哪些同学没有组队等问题，并且可以马上通过该系统与任意一人联系并组队。组队信息交流范围扩大到最大，信息的时效性很高。 另外，同学们在项目进行的过程中可以很轻松地与队友交流信息，个人与个人之间的交流也不会因为没有对方手机号、qq号码或者邮箱地址等联系途径而受到阻碍，信息的交流在该系统上更通畅，信息交换效率与透明度得到很大的提升。 对于老师来讲，不必再为同学们的组队去做任何繁琐的统计工作等，通过组队系统就能很直观地了解同学们组队的情况，并且很方便地为同学们的组队做合适的调整。同时，关于项目的任何信息老师都可以上传，使得项目信息集中地展现，节约同学们寻找时间，提高同学们项目进行的效率，并且很好地和同学们进行沟通互动，工作效率提升。1.3 业务目标与成功标准 业务目标BO-1：在第一版使用后的一年内，同学组队的平均时间减少到2天。BO-2：在第一版使用后的一年内，同学自行组队后剩余人数不超过6人。BO-3：在第一版使用后的两年内，老师通过组队系统集中展现并交流项目的信息 度量标准：对于每个项目，该老师通过组队系统发布的公告的数目占所有关于 该项目的公告的总数（包括通过TSS等）的百分比 计量方法：检查系统中数据库中的公告数目A，检查TSS上以及课堂上老师发 布的关于项目的公告数目B，则百分比为A/（A+B）。 理想标准：百分比达到90%； 一般标准：百分比达到60%； 最低标准：百分比达到30%。BO-4：在第一版使用后的半年内，老师不用任何统计工具了解同学组队情况，只通过 组队系统直观地了解。BO-5：在第一版使用后的两年内，同学通过该系统可以减少小组开会时间 度量标准：对于每个项目，所有小组在使用系统后的开会时间较使用前开会时间减少的百分比 计量方法：随机抽查若干小组前后的开会时间，计算出节省时间的百分比 理想标准：减少50%的开会时间； 一般标准：减少40%的开会时间； 最低标准：减少30%的开会时间。BO-6：在第一版使用后的两年内，大部分学生通过该系统可以和其他人就项目组队、技术问题等进行讨论 度量标准：对于每个项目， 计算出通过该系统与他人进行交流的同学百分比 计量方法：检查系统中记录的每个人的交流时间，计算出通过该系统与他人进行讨论的人数占参与该课程的人数的百分比。 理想标准：有90%通过该系统进行讨论； 一般标准：有80%通过该系统进行讨论； 最低标准：有60%通过该系统进行讨论。 成功标准SC-1：在第一版使用后的三年内，组队系统成为80%的小组的讨论及信息传递的主要工具。SC-2：在第一版使用后的一年内，组队系统成为南京大学软件学院同学进行项目组队的必须系统。SC-3：在第一版使用后的两年内，组队系统成为99%的老师发布项目信息，了解组队情况的主要通道。SC-4：在第一版应用之后的一年内，老师对同学组队效率的调查评价要提高0.8，对同学项目进度的调查评价要提高0.2，而在第一版应用之后的两年内，对同学组队效率的调查评价要提高1.0，对同学项目进度的调查评价要提高0.7。SC-5：在第一版应用之后的一年内，同学对组队效率的调查评价要提高0.8，对项目信息交流方便程度的调查评价要提高0.2，而在第一版应用之后的两年内，对组队效率的调查评价要提高1.0，对项目信息交流方便程度的调查评价要提高0.7。1.4 业务风险RI-1：对于同学之间的交流，同学认为有更加成熟强大的软件可以满足他们的要求，比如 qq、msn等，而不愿使用该系统进行交流，使得系统的许多功能空置。 可能性0.7，影响为4。RI-2：对于项目信息的公布，老师认为在TSS上发布更为方便，而不愿使用该系统发布项 目相关的消息，使得系统不能集中展现项目相关的信息。 可能性0.6，影响为8。RI-3：该系统完全不为老师与同学所接受，弃之不用，使得系统开发的投资回报基本为0。 可能性0.1，影响为10。RI-4：同学们过分依赖该系统，甚至为项目召开的例会等也通过该系统的组内讨论功能进行， 反而降低了信息的交换效率，对其造成负面影响。 可能性0.2，影响为6。RI-5：在组队截止日期前期同学们大量进入该系统寻找合适的队友，使得系统在关键时刻崩 溃。 可能性0.5，影响为9。RI-6：同学们进行组队时因网络中断或者其他原因导致服务中断，使得部分同学在截止时间之前不能完成组队，对同学造成负面影响，使其组队乃至项目受到损失。 可能性0.3，影响为7RI-7：同学们通过该组队系统可以和任意该课程的同学讨论聊天，但是无法控制讨论内容以项目、技术为主，导致同学们将该系统作为结对玩乐的联系工具，对老师的教学、同学们的学习造成负面影响可能性0.4，影响为5 2 项目前景2.1 前景概述 对于南京大学软件学院的同学来说，组队系统是一个基于Internet的应用程序。它可以直观地显示当前已组队同学与未组队同学，搜索任意一位同学以了解其组队与否以及所在项目组的信息，统计已组队与未组队同学数目，参与该课程的任何同学均能创建新的项目组或者向PM申请加入项目组，信息范围广且时效性高；可以方便同学推举出所在组的项目经理；可以让任意两人进行讨论，以便同学及时了解他人组队情况以及方便向他人请教项目技术难题等；可以方便组内同学在项目进行期间的讨论及信息交流；可以直观地看到老师发布的公告，并可以以回复形式对其提出疑问或建议，及时向老师反映当前项目的信息并向老师获取项目的信息。这样，既可以使得同学可以高效快速地组队，又使同学更好地进行信息的交流，以提升项目的质量。 对于南京大学软件学院的老师来说，组队系统是一个基于Internet的应用程序。它可以给同学提供一个组队的平台，并且帮助老师统计同学组队的信息，直观地向老师反映当前组队情况，也使得老师为未分组同学分组的操作更加便捷。同时，老师可以通过这个系统发布各种与项目相关的公告或通知，同学也可以在公告下以回复形式提出疑问或建议、向老师反映当前项目的进度等信息，更好地让同学与老师进行互动。这样，既为老师节省了统计同学分组信息的时间与精力，又能使得项目信息更加集中，师生信息交流更方便。2.2 主要特性FE-1：列举出所有参与该课程的同学名单。FE-2：输入任意一个同学姓名，便可进行搜索，得到该同学组队信息。FE-3：统计出已组队与未组队的同学。FE-4：同学可以自己创立项目组，或者通过向PM申请进入该项目组；而PM也可以在未组队同学名单中邀请同学加入该项目组，有人数限制。FE-5：组队截止日期结束后，未组队同学由老师对其进行分配，比如另外将其组队或者加入到已有项目组中。FE-6：各个项目组可以进行组内讨论。FE-7：任意两人可以进行讨论会话。FE-8：老师可以通过该系统直观地看到同学们的组队情况，包括未分组同学名单、已分组同学的分组情况。FE-9：老师可以发布关于项目的任何公告，公告所有同学可见。FE-10：同学可以以回复形式在各个公告下提出疑问等，老师可以对其以回复形式进行回答等。FE-11：老师可以创建、删除或修改课程的项目组队“房间”，同学在对应的项目组队“房间”中进行组队、交流等。2.3 假设与依赖AS-1：同学做项目过程中需要提交的文档文件等通过TSS上传。AS-2：该系统可以访问TSS内包含各课程学生名单的数据库。AS-3：可与打印机相连，老师可将学生组队名单打印出来。3 项目范围3.1 版本范围特性版本1版本2版本3FE-1完全实现FE-2不实现得到该同学组队与否的信息得到该同学组队与否、所在项目组的信息FE-3完全实现FE-4PM为最初创建项目组的同学，不可变更，且人数最多4人PM可以为该项目组中的任意一人，可变更人数限制可由老师设置FE-5由老师手动分配老师可以手动分配，也可由系统自动分配FE-6完全实现FE-7完全实现FE-8完全实现FE-9老师发布公告，但系统不提示学生，需学生自己发现新公告对参与该项目的学生，系统提示老师发布了新公告FE-10学生回复，但系统不提示老师对该公告的发布老师，当学生回复时，系统提示老师有回复FE-11完全实现3.2 限制与排除LI-1：组队系统仅适用于南京大学软件学院TSS上有记录的课程中的项目开发，由老师或同学自发的组队不适用于该系统。LI-2：该项目仅用于信息的交流，项目文档文件的提交仍在南京大学软件学院的TSS系统上完成。4 项目环境4.1 操作环境 该系统为基于Internet的应用程序，用户包括南京大学软件学院的老师与学生，用户地理分散，可在任意时间访问系统。对于所有学生与老师，都有相对应的账号与密码，以控制访问安全。系统与南京大学软件学院已有的TSS数据库相联系，同时也有自己的数据库。用户访问数据时的最大响应时间视网络而定，因此未知。用户可以容忍偶尔的服务中断。4.2 涉众涉众特征南京大学软件学院老师老师将通过该系统了解同学组队完成情况，并且发布与项目相关的各种公告，通过该系统跟进同学的项目完成情况。老师年龄从20至60不等，教授与计算机、软件相关的知识，对电脑及系统管理有较高的操作能力。南京大学软件学院学生同学通过该系统提供的平台，对各个项目进行组队，寻找合适的队友，同时通过该系统与队友以及其他任意同学进行联系，并且了解老师发布的公告，对其进行疑问等。学生为本科生以及研究生，学习与计算机软件相关的知识，对电脑、网络等有较高的操作能力。4.3 项目属性属性执行者约束因素可调整因素进度计划在项目开始的五个月内（即2010年2月30日之前）完成第一版；之后的一个月内完成第二版（即2010年3月30日之前）；之后的一个月内完成第三版（即2010年4月30日之前），最多可超过期限两个星期特性1.0版本中要求实现的特性必须完全可操