历届比赛-外包大赛s2解决方案

项目背 项目背 项目意 项目目 产品功能目 产品性能目 解决思 业务需求分 需求分析方 功能阶段分 业务情景分 角色组织管 功能需求分 功能模块结 移动客户 管理 组织管理方 项目组结 项目管 开发流 版本规 代码和文档管 管理风险和应 技术设计目 系统结 系统体系架 系统功能架 系统技术架 详细设 数据库设 数据库选 数据安全设 项目商业背 商业商业推广alUniversity产品优 alUniversity产品基本策 alUniversity产品的推广介 可行性分 alUniversity产品风险分 技术可行 经济可行 用户使用可行 法律可行 项目报 系统报 人力成本分 项目用分 费用分 新时代高校正向数字化、开放化的方向发展，这一趋势拓展了传统高校在时间和空间上的维度，也对传统高校提出了更高的要求。为广大学生及教职工提供更为方便、全面、的信息服务势在必行。虽然大部分的高校，甚至二级学院都有 ，但学校的 浏览量并不高，得不到的广泛关注，文件通知下达得不通畅，很多校园公告或者活动海报无法得到及时推送信息发布与交流存在一定的滞时和不畅。特别是学生，作为年轻的一代，更容易接受“掌上”信息。而对于相对传统的校网则关注甚少因此不少学校为了消息的快速传达，更是直接采用飞信的方式。事实上，随着移动互联网的迅猛发展，智能在高校学生和教师当中已经非常普及。随着移动互联技术的普及和的发展，移动办公、学习，正在成为一种重要的业务形式。因此有必要为学校老师、学生，甚至可能涉及的行政，量身打造一款教学、评价互动软件，为老师、学生营造一个不受时间、地域、空间限制的教学、交流、管理和资源共享的互动交流平台。从而提高学校的管理水平与效率，并改善高校学生的学术与生活氛围，改善教师与学生的交流通常度，通过交流平台促进教学，提高教学质量。基于上述分析，我们首先对市场上现有的校园APP产品进行了摸底，搜索了50多所代表性的高等院校，收集和总结了以下在校园APP方面具有代表性的现有产品，见表1.2-1(该表内容太少，高校至少要有20所，功能列表中的功能太少，需要补充！结论不可以放在表格中！！)表1.2-1产品调研（表格的标题放在左上角高高 校园APP 功能列表 查询自习室复旦大学复旦大学人在复大同济大 微同 自动同步课厦门大学厦门大学厦门包打听空教室查询集美大 微集 重要通知推送功江南大学江南大学江达人速递学校大小消息总的说来，大部分高校的校园APP功能比较雷同，缺乏新意。其所具备的功能主要包括以下几类：通知公告：几乎所有的校园APP都有该功能，用于放置学校于公告。校园导航：往往这块功能会被重点介绍，甚至还包括校园内3D地图的路径规划。校园常用信息：大部分校园APP都会包含该功能，用于放置一些学校的常用信息，包括、宿舍地址等等。社团功能：部分校园APP看中社团功能，会开发适用于某些社团的校园APP，用于社团交流沟通。外卖、快递等附加功能：大部分校园App都有外卖模块，提供校园周边的外卖信息，包括小卖部名称、等等。尽管提供了不少有用的信息，但是根据我们在Android和苹果平台的搜查，发现大部分校园APP的量都非常小（最好有量附图）。说明用的人并不多。总的说来，原因不外乎以下几种：大部分信息属于“消费”。比如外卖信息、快递信息、校园常用信息等等，大部分学生看过一次以后就知道了，基本上不会在以后反复查看。未考虑学生的实际消费能力比些APP的校园导航系统做的很好，甚至具有3D地图查看功能。但是这些功能会耗费大量的流量，以学生的消费能力来说，他们并不会常用。更重要的是，大部分学生都很熟悉校园，并不需要导航。因此，曾经做过一个校园导航的APP，但使用对象是参加活动的校外没有深入学生的课堂生活。学生在学校中，大部分时间都在课堂，或者与课堂相关的活动中。但是现有的校园APP却鲜见这部分的功能，几乎与学生的课堂活动脱节。缺乏真正有用的、可反复使用的功能，致使校园APP没有粘性。以上几种原因，最终导致了校园APP的使用度不高。对于学生来说，这种APP可有可无，没有。产品缺乏粘性，用户大部分使用了几次后就觉得没有意义，最终被用户遗弃。在分析了现有产品的特点，并结合校园生活实际可能存在的需求的基础上，我们设计了“ alUniversity”项目（以下简称PU）。该项目具有以下几大功能模块：掌上迎院校通常用信电子海信息推信息推A1-学生APPB-PC掌上签课后点客户 信息推信息推A1-学生APPB-PC掌上签课后点客户 看、资理个人推送服务、计服A2-教师APP作业布学生互签到查系统配课程查登陆模点MOOC整个PU项目包括学生版移动APP端软件、教师版移动APP端软件、PC版浏览器客户端和服务器端。每个部分的主要功能如下所示：A1部分—学生版移动APP端：这是PU最的模块，也是功能最齐全的部分。我们把重点功能都放在这个部分，具体功能将在下面详细介绍。A2部分—教师版移动APP端：教师版的移动APP主要用于签到统计查看、和学生互动、简单作业布置这几项功能。由于资源涉及大的数据流量，因此这部分放在PC版部分。B部分—PCB/S部分PC版的服务器部分主要包括涉及移动APP的所有的数据库设计和数据分发、数据逻辑处理等功能。客户端部分主要包括信息查询、资源、教师、学生以及行政的登陆查看等功能。以下，通过几个实际的应用场景，描述整个系统各个部分的使用：1）电子海报的上传与分发需要登电子海报的学生或者社团登陆PC版的客户端（B部分），上传的电子海报。然后行政登陆PC版的客户端（B部分），对电子海报进行审核。通过后，PC版的服务器端将把给移动端APP（A1部分）。学生移动端APP（A1部分）将会马上收到一个通知，并显示上传的电子海报。学生可以点击查看，并且评分、评论甚至“掌上”报名。2）签到与课后评价在某节课上学生打开AP（A1部分），点击“签到”。上完课后，学生可以马上在APP端进行课后点评。学期课程结束后还可以对进行点评课后老师登陆移动APP（A2部分），布置作业，并点击“发送”。利用服务器端（B部分）将信息转发给学生APP端（A1部分）。学生可马上看到作业信息。同时，老师的APP端可以看到上课签到的统计信息。另外，学生也可以在APP端（A1部分）看到自己的上课签到统计信息，教师也可以在APP端（A2部分）或者PC端（B部分）看到所有学生的签到统计信息。3）掌上互动与资源共享。教师可以通过移动APP与学生APP之间的消息推送进行掌上互动，并可以通过PC端实现资源共享。如上图所示，因为学生人数众多，PU项目将重点放在了A1部分，即针对学生的移动APP。以下简单介绍各个功能模块的主要功能（果我有遗漏某些模块，请补充。注意，这里写的模块名字，要和本文档接下来的各个部分中涉及模块名的地方一致）登陆模块学生通过选择学校、学号和进行登陆。PU限定学生只能根学号登陆，因为学号包含了很多信息，便于后续信息分类推送等功能的实现。掌上迎新模块以系统中的校园静态地图上标示的数字（配有相关信息）作为顺序，引导新生在不同地点按顺序办理不同手续，完成入学时的报名。电子海报模块显示服务器端（B部分）推送过来的校园电子海报，并提供评分、评价以及实名的功能。个人课理模这是学生移动APP端的模块如上图所示该模块的功能最多。主要用于学生个人的课表管理、掌上签到、课后教学评价、学期后评价、MOOC、学生教师掌上互动、掌上作业查看等众多功能。课程查询模块该模块专门用于查询全校性的教师与课程信息。例如，查询计算机学院中含有“软件设计”关键字的课程安排；查询美术学院XXX老师的基本信息等。该模块主要服务于转专业学生与考研学生。院校通知模块该模块用于显示各种通知和公告，主要包括三部分：全校通知、学院通知和毕业生就业通知。利用学号信息，可以将不同消息分类推送至不同的学生APP中。常用信息模块这是一个比较常规的模块，主要是记录了一些学校和学院部分的常用信息。系统配置模块用于对APP的各个模块进行配置和订阅。本项目在分析了已有校园APP产品的特点的基础上结合赛题要求，开始了PU（ alUniversity）项目的设计与开发工作。与现有产品相比，该项目具有以下特点：利用秒级签到，保证用户粘性。校园APP的一大缺点就是缺乏用户粘性。本项目利用课理模块中的掌上签到功能，保证了学生使用APP的频率。掌上签到快速省时，保证了用户粘性更的情况下，通过学校推广和老师的“强制（对于教师而言，省去了口头点名签到的麻烦。特别是学生数众多的公共课称，可以点名时间），可以保证学生每天都使用PU产品。提高教学互动，加快教学评估，促进教学学生通过APP端可以在课堂后，可以通过按赞或者给评分，马上进行教学点评。教室在课前或者课后进行掌上作业布置，学生可以马上接收到，提高了两者间的互动效率。学生在课程结束后，还可以进行掌上评价，为下一个学期的选择提供数据支持。而教师也可以通过PC端进行统计查询。总体而言，PU项目深度结合了教学过程的各个方面，可以有效加快教学评估，促进教学。通过消息的分类推送，变学生接受信息为消息主动推送，提高了校园信息传达的效率。由于PU系统利用仅支持学号登陆，因此，保证了系统可以针对不同的对象（全校学生、某个学院的学生、毕业生等）推送消息。同时，在保证学生使用该APP的高频率的基础上，可使消息的传达更加快速和有效。进一步加深无纸化校园的建设PU系统中的迎新模块和电子海报模块可以使学生丢弃传统的迎新手册，或者在、校舍门口的海报张贴栏。我们希望利用掌上APP，在这两个方面实现无纸化。与MOOC深入整合，为校园O2O进行了初步探索在课理模块学生可以直接查看课程相关的MOOC目前，网易投资了超过1亿元用于网上开放课程MOOC的制作。利用我们的PU平台，可以直接将课程与MOOC相关信息连接，使MOOC信息落地。另外，在课理模块，还可以查看该课程相关的线上资源。这些方面，都可以作为校园O2O平台的初步探索。 亮点（请胡博核实与补充采用MongoDB，搭配Node.js，保证了服务器端的高性能与可扩展性。本项目采用MongoDB作为服务器端数据库，配合Node.js的单线程操作特性，降低系统对服务器的要求和使用，保证服务器端的高性能。使得系统的可扩展性大大提高。采用 的签到有效控使用的服务器端的框架？（每个单独的节，比如第二节，从下一页开始本项目的主要目标，是做一个能深度融入教学，有效提高教学质量，并使师生互动更加方便快速，深度融入学生生活的校园APP软件。我们希望该APP软件是实际有用的，有效的。由于整个PU项目涉及内容较多，为了做好进度项目将分为几期进行。第一期目标产品功能目标：第一期主要实现Android平台上的PU系统开发，并只涉及一个学校（项目团队所在的学校）的师生与使用。如图1所示，实现A1（学生APP端的几大相对简单的模块，包括登录模块、掌上迎新模块、电子海报模块、院校通知模块、常用信息模块、系统配置模块等等。实现A1部分的个人课理模块中的所有模块，掌上签到功能以无线连接实现方式为主。实现A1部分课理模块的部分功能。实现B部分服务器和客户端的大部分功能，包括数据库、消息推送、资源共享，客户端的浏览等等。实现A2部分（教师APP端）的功能，包括签到统计查看、师生互动和布置作业等模块。实现B部分与A1、A2部分的互通互联，后者可接收前者推送出的各种消息。并利用APP的下拉功能，实现消息（包括电子海报、院校通知等模块中所涉及的内容）的实时更新。以团队所在的学校为主，试推行PU项目软件的实施与测试。产品性能目标：在第一期，由于团队自身的服务器受限，服务器可允许的用户数在5万级别。掌上签到时，最大并发可保证500人以上。确保在人数较多的公共课上亦可使用。B部分服务器向A1和A2的APP推送的消息可以实时到达。保证服务器端的高性能。采用MongoDB作为服务器端数据库，配合Node.js的单线程操作特性，降低系统对服务器的要求和使用，保证服务器端的高性能。保证系统的可扩展性。保持系统中各个主要模块和子模块的低耦合性，降低未来对系统升级所需的修改工作和测试工作，方便新算法和新模块的替换。第二期目标产品功能目标：第二期将实现A1和A2部分的iOS设备端的开发。将使用者扩展到杭州市的其它高校，利用其它高校的数据完善系统。着重深挖和开发O2O架构下的应用。除了MOOC以外，还将引入基于智联招聘等招聘的消息推送，以及当当网等相关的推荐等等。产品性能目标：更新服务器，将服务器的承载能力扩大到50万用户级别。扩大掌上签到并发能力，最大并发能达到1万人以上。第三期目标我们希望最终可以在高校中推广PU，每位在校学生都可以查看个人课表、相关课程的MOOC，也可以查看其它高校开设的同一门课程所选用的信息或者查询同一个城市中某个高校开设的计算机类相关课程的信息，比如开间、地点以及教师等，方便跨学考研或者旁听的学生。一旦有了足够的用户，在O2O上进行进一步地挖掘，并考虑更好地模式。考虑本项目开展中需兼顾进度、质量和成本的控制，坚持“基于产品、面向用户、注重效益”的服务，坚持“以问题为导向、用技术作支撑、从业务上优化”的问题解决原则。我们确立了以下图为主的具体解决思路： 开发平台基于目前主流操作系统，现阶段主要主要基于Android操作系统；服务器端选择Node.js开发环境，低层运算使用C++重写完能N设定完善的开发 2.2-1团队项目经理、客户关系经理在多所学校就“校园生活哪里需要信息化”对学生展开调研，对结果中相对普遍的问题加以关注，明确学生最需要的服务。团队成员利用7天时间亲身体验XXX大学教务及生活服务的方方面面流程。切身体验业务活动情况。通过7天的时间，使团队快速理解了用户的需求，并充分了解了教务管理、海报通知发布管理等活动的流程，为产品的业务逻辑设计积累了宝贵资料。项目组召开了多次头脑风暴会议，由于使用了没有拘束的规则，头脑风暴中的项目组成员能够更自由地思考 alUniversity系统的设计，产生了很多的新观点和问题解决方法。例如：采用AprioriTid[3,4]频繁项集数据挖掘推荐算法，SVM支持向量机的数据挖掘模型，更加准确B 获取与甄别，Node.js单线程异步式读写I/O模式，贴近人机交互易懂原则。本项目组特地体验了业界使用的相关软件，并对其现状和功能点做了分析，找到了校园应用种类繁多却使用率低的主要原因，并结合之前的调研成功，进一步明确了项目的功能点以及分期实现规划。通过总结，得 alUniversity在设计中需要注意以下特点现有系统功能点较为分散，主次点不明确，业务面宽但深度挖掘不够。系统必须具有明的特色，以保证具有自身独特性，同时兼具可拓展性，以便之后注入新功能，并为高校生活进一步信息化做准备。类似系统使用率，足见其缺乏用户粘性，使得没有拓展功能的必要和继续做大推广的可能。本项目组所开发的系统必须具有强大的用户粘性，拥有紧扣教学生活的不可替代功能，保证用户的粘性，以便为在后期拓展业务面，向平台型系统迈进。类似项目使用率低，且反响一半，很大一部分是由于系统的流程设计与现有的线程安排不吻合，用户的固有，不仅没有达到方便用户目的，甚至强迫用户改变已有的行为模式，在不具有强大粘性的前提下，最终导致被弃用。本项目组所开发的系统必须与现有工作流程高度吻合，一则降低用户使用门槛，再则降低培训成本，以便可快速投入使用。基于对“alUniversity”的业务需求分析，这里，我方采用应用场景图对系统的整体业务作更为直观的描述，如图3.2-1所示：3.2-1根据客户的业务需求，对该系统涉及的业务角色进行分析、整理、归类、制定角色分类如图3.2-2所示：3.2-2：系统服务：指客户为该系统专设的，如系统管理员、数据员、海报员等。合作企业：指针对该系统与客户公司有合作关系的商户企业。如“毕业生起航”模块上与客户公司有合作的招聘。终端用户：指使用该系统的用户，主要包括学生用户、VIP用户以及教师用户三类。（此处未提及visit用户）对角色进行分类的基础上，进一步分析公司成员、公司合作企业以及终端用户这三类角色间的治理关系，得出该系统的组织管理结构，如图32-3所示：3.2-3：管理员：主要负责服务器系统的安装、配置、管理和工作,为系统安全、平稳运行做技术保障。员：主要负责系统所需数据的和更新，以及对用户的应答。数据员：主要负责院校通知、前哨站与课理数据库的工作，如定期整理通知信息海报员：主要负责电子海报的，以及对VIP用户的回执。学生用户：指本系统中所有的学生用户。VIP用户：指本系统中拥有上传海报权限的组织或团体用户。教师用户：指本系统中所有的教师用户。本系统主要由三部分构成——移动客户端、服务端以及管理端移动客户端：开发Android4.0+、IOS或WindowsMobile平台上的个人校园 aluniversity）应用客户端，提供电子海报、迎新、学习管理等服务。管理端：包括查阅页面、管理页以及海报上传页。查阅页面主要实现产品功能介绍，移动客户端，使用说明以及相关数据（主要为考勤情况）的查看功能；管理页则涵盖用户信息、使用情况统计等功能，方便管理员系统以及对移动端应用各个功能使用情况的统计；海报上传页主要供VIP用户提交上传申请查看回执信息海报员上传海报，以及编辑回执信息等功能。服务端：为所有操作提供数据接口，并且处理实时推送等功能的逻辑运算，并对数据进行加密以保证数据安全。各部分业务功能如图3.3-1所示：3.3-1下面针对移动客户端、管理端进行详细分析，服务端的相关内容参见《技术路线与实现方案》部分。根据客户的业务需求，移动客户端的所有功能对普通学生用户开放。在此，用如图3.3-2的角色用例图进行说明如下：3.3-2学生用户可以通过移动客户端享受到电子海报、迎新、学习管理以及院校通知服务。电子海报管理(E-本系统使用VIP用户上传海报员审核发布的海报征集方式如图3.3-所示：

3.3-3该海报征集方案由拥有VIP用户的组织或团体编辑海报web端，由海报员审核，通过则录入数据库，并给予用户已回执信息；否则在不予发布并在回执信息中说明原因。海报员将由VIP用户上传的海报与海报标准对比，符合此标准则录入数据库，并告知用户发布成功，否则不予上传，并在回执信息中阐明原因。海报标准又发包方统一定制，海报员没有修改的权力。海报标准将在网站上对用户公开。我方推荐的海报标准由海报属性、活动信息和单位信息三部分组成，下面对这三部分进行具体描述。描述海报的分辨率、长宽比、格式等信息为用户提供海报涉及活动的具体信息，具体由以下内容组成：（1）活动名称；（2）活动类别；（3）活动具体时间；（4）活动简介；（5）参与方式；活动信息必须包括以上所有内容。为用户提供发布海报单位的相关信息，具体由以下内容组成：（1）发布单位名称；（2）发布单位单位信息不一定包括单位本模块面向学生用户，集海报查询、海报浏览、活动查看、个性订阅、综合评分、评论交流、实时推送、一键等功能于一体。

3.3-43.3-1一键

图3.3-5迎新信息收集业务流程迎新信息收集方案，由数据员定时收集个信息来源站的信息，并通过Web端录入数据库。事务流程信息具体由以下内容组成：（1）事务名称；（2）办理流程；（3）相关地点；（4）办理时间；事务流程信息必须包含以上所有内容。本模块面向学生用户，集热点区域查看、事务流程查看、流程引导等功能于一体。

3.3-6表3.3-2迎新模块功能设计该功能模块涉及的数据有学生用户信息、相关作业信息、课程信息、教师信息、信息、互动信息、用户评价结果与用户考勤数据等，用户信息、用户课程以及课程信息先来由发包方提供的第数据服务器导入，相关作业信息采用人工录入方式收集，互动信息、用户评价结果与用户考勤数据采用用户征集方式。第数据导入方由数据员获取发包方提供的第数据库服务器接口调整导入协议并加密之后，在Web端完成数据导入，将数据至学习管理数据库。第数据组第数据由学生用户信息、课程信息以及教师信息组成用户信息具体由以下内容组成：（1）用户账号（同学号）（2）用户（初始与学号相同）（3）所在学院；（4）所选课程用户信息必须包含以上所有内容。课程信息具体由以下内容组成：（1）课程（2）课程名称；（3）课程时间；（4）课程周期；（5）所属学院；（6）专业方向；（7）所用（8）同类课程MOOC课程信息必须包含以上所有内容。教师信息具体由以下内容组成：（1）教师账号（工号）（2）教师用户（初始可迭代）（3）所带课程（4）邮箱；（5）学历；（6）研究方向描述；教师信息必须包含以上所有内容。

图3.3-8人工录入方案业务情景由相关教师直接将课程作业与Web端录入。相关作业信息具体由以下内容组成：（1）对应课程（2）提交日期；（3）作业描述；相关作业信息必须包含以上所有内容。

3.3-9学生用户通过移动客户端完成签到从而录入考勤信息，对课程的评价信息也通过移动客户端编辑上传，经由服务端接口录入相应数据库。互动信息由学生通过移动客户端向指定教师发送，并经由服务端接口录入相应数据库，借助第推送平台推送给对应教师。互动信息具体由以下内容：（1）目标教师（2）文本信息；（3）语音信息；（4）发送时间；（5）发送人（6）发送人（2）、（3）可选其一，其余部分必须齐全。用户评价结果具体由以下内容：（1）对应课程（2）对应课程名称；（3）评价分数；（4）具体评价；（5）评价时间；用户评价结果必须包含以上全部内容。用户考勤数据具体由以下内容：（1）对应课程（2）签到时间；（3）对应课程的开间（4）签到所提交的 内容（5）签到用户用户考勤数据必须包含以上所有内容。用例图

3.3-10MOOC用户可以查看选定课程在各大MOOC3.3-3我方考虑对学习管理信息中一下三种数据进行挖掘并作为将来数据挖掘的基础：◎各门课程学生签到的时间；◎各门课程被搜索的次数；◎各门课程所用的◎各门课程对应教师被搜索的次数；◎各门课程发布作业的时间。运用关联规则Apriori算法通过课程评分数据对以上的数据进行挖掘，主要绘制出各门课程在使用不同、由不同老师授课的情况下，评分和热度的关系曲线。通过数据挖掘结果，客户可以得到课程的受欢迎度与、授课老师、课程涉及内容的关系。如经济学类课程使用第四版《微观经济学》的热度较高；李xx教授所授的民法原理课程热度胜过其他同类课程等等。MOOC在2012年席卷了高校，2013年进入中国，这标志教育的线上发展进入了前所未有的告诉时代，同时也对资源和数据提出了要求。各大高校都需要积累学生、教师的以为进入MOOC大军做出相应准备。通过分析数据挖掘获得的结果，客户可以有效地了解自身的优势资源，对线上和线下活动的展开都具有指导意义。对于线下有助于选择推荐，与供应商积极寻求合作，帮助批发商选择受欢迎的。有助于教师改善自己的教学风格，完成更高质量的教学等等对于线上有助于了解哪些课程适合投入MOOC，哪些教师适合开设MOOC课程，引导自身进入MOOC环境，为教育的线上化、课程的大规模化和公开化提供数据参考等等。该模块数据由班级通知、院级通知、校级通知以及就业通知四部分组成，院级通知、校级通知与就业通知采用征集方案如下：

3.3-11院校通知及就业通知数据征集方案由数据员定时收集个信息来源站的信息，并通过Web端录入数据库。班级通知采用征集方案如下：

班级通知数据征集方案，由教师（特指班）为自己所带的行政班编辑通知，并通过Web端录入数据库。院校通知数据由班级通知、院级通知、校级通知与就业通知四部分组成。班级通知由以下内容组成：（1）通知名称；（2）通知内容；（3）通知日期；班级通知必须包含以上所有内容。院级通知由以下内容组成：（1）通知名称；（2）通知内容；（3）通知日期；（4）发布学院；（5）推送学院（发送目标学院）院级通知必须包含以上所有内容。校级通知由以下内容组成：（1）通知名称；（2）通知内容；（3）通知日期；校级通知必须包含以上所有内容。就业通知由以下内容组成：（1）就业类别；（2）薪金水平；（3）工作（4）工作区域；就业通知必须包含以上所有内容。3.3.3管理本部分主要由查阅页、管理页和海报上传页构成，用如图3.3-13的角色用例图进行说明。

图3.3.13管理端角色用例管理端涉及的系统角色是教师、学生用户、VIP用户以及海报员，教师拥有查阅考勤信息并发布作业发布通知以及发布相关资源的权限；VIP用户拥有上传海报并查看回执信息的权限海报员拥有查看借口状况、发布海报、编辑发送回执信息的权限；普通学生用户仅有应用与相应资源的权限。查阅业务描述本模块面向教师用户与普通学生用户，集作业发布、考勤信息查询/、应用详情查看、移动客户端等功能于一体。其中作业发布、考勤信息查询/功能只针对于教师使用，普通学生用户只可使用应用详情查看、移动客户端功能。

图3.3-14查询页角色用例相关资源

表3.3-4查询页功能设计业务描述本模块面向数据员，主要集成查看接口使用情况、数据导入情况以及用户管理功能于一体。

图3.3-15管理页角色用例VIP数据员可以对VIP用户做增删改的操

表3.3-5管理页功能设计业务描述本模块面向海报员与VIP用户，海报员拥有制定标准，发布海报、编辑发送回执信息的权限，VIP用户拥有上传海报，检查回执信息的权限。用例图

3.3-16表3.3-6海报上能设计整个项目由项目经理负责。项目经理下设客户关系经理，测试经理，产品经理，技术经理。其中项目经理负责与 的沟通，并负责整个项目的成本与进度控制。客户关系经理负责与客户的沟通和交流，收集客户的需求。测试经理带领测试工程师队伍完成系统测试任务。产品经理负责需求分析和产品定义。技术经理下设系统架构师和开发工程师，主要完成系统开发。整个项目组的组织结构如图4.1-1所示：（正文字体用小四）4.1-1项目组中成员的具体职责如表4.1-1所示职务职责1项目经理项目进度控制、团队成员分工与管理、成本控胡博2技术经理根据产品定义，负责完成系统编码工作闻铭3产品经理负责需求分析和产品定义王嘉焕4客户关系经理负责客户沟业推广及客户需求的汇吴湖青5测试经理对产品的软件功能、性能及其它方面的测试顾航林

4.1-1在经过了可行性分析，明确了系统开发的必要性，并确定业务需求，完成产品定义后，系统将进入正式开发阶段。在整个系统的开发过程中，如何有效的进行项目管理，是整个项目能否按时保质完成的关键。以下将从与本项目密切相关的开发流理、进度管理、代码和文档管理以及项目管理中的风险和应对等几个方面，具体描述 alUniversity系统的项目管理方案。开发流需求会P图4.2-1开发流良好的开发流以有效定义团队成员的责任和义务提高整个团队的效率，也便于出现问题时的责任。本项目定义的开发流程基本如下：首先由项目经理、客户关系经理和产品经理跟客户代表共同确定产品需求，由产品经理给出快速原型UI。通过需求评审会议后正式确定产品需求。接下来，由技术经理负责开发，期间产品经理进行必要的协助。开发完成后，由测试经理负责本产品的测试，期间技术经理协助修改。最后客户关系经理负责产品的推广、，并收集客户的需求，反馈给产品经理，进入下一轮的系统升级和改造。整个开发流程如图4.2-1所示。版本规划是整个项目管理中重要的组成部分，也是整个项目能否成功完成的主要保障。根据第一章对PU项目的功能模块介绍，以及第二章对产品目标的介绍，我们针对第一期的产品目标做了详细的版本规划。如表4.2-1所示，保证在项目开发中的重要节点/里程碑能按时完成。（下图要根据图1所示的功能模块进行补充和完善，图1中有的功能模块都要在这里有所体现）课电子海报迎新院校通知一键签到海报查询热点区域查看通知查看作业发布海报浏览事务流程查询通知发布个人课程查看活动查看流程引导通知推送教师信息查看综合评分个性订阅作业信息查看个性订阅实时推送课程信息推送课程评价一键课程查询MOOC查看 第一版本 第二版本第三版本表为了保证相关代码和文档不被轻易带出，一旦项目启动，本项目组开发需要签署相关协议。有可能的话，还需要使用指定的无U盘接口的开发平台。在代码的管理上，为了使整个系统的开发有序进行，开发进度和接口控制，所有开发都遵守统一的编码风格，具体编码风格，详见我们的相关文档《PU项目的统一编码风格》（注意，请胡博将之前给过编码风格单独列出成文，并起名为上述名字，作为额外的相关文档）。另外，在项目版本管理上，采用免费的SVN进行统一的版本管理。任何项目的管理过程中都存在一定的风险。为了有效地应对风险，项目组针对可能存在的风险（主要是组织管理风险和需求变更风险）进行了说明，并设定了应对计划，如表4.2-2所示：表14.2-2风险分析表（所有表格的表头都在表的左上角，并注意表格中的内容对齐）风险说明降低风险的策略R1对该项目成员之间的配合不足（包括管理人员、测试员、QA和其他外部的相关各方建立高效的会议与管理制度，实施原则，期间进行团队素质拓展活动R2项目实施期间，出现人力资源缺口组建项目团队前签订人事合同，做好人才储备工作R3团队成员技能和经验项目开发要求吸收有相关通信资格认证的高新技术复合型人才R4项目开发项目开始前进行可行性分析，并且与发包方签订合法协议R5限制使得系统必须以固定的成本交付，影响产品质量效果可与发包公司灵活协商，共同追求产品质量最优化R6项目成本估算确，影响公司收接受专业估算机构进行审核R7无法在规定时间内交付产品制定项目进度管理和项目开发流程对于软件开发过程中经常存在的需求变更，处理流程如图4.2-3所示：4.2-3基于项目总体目标的设计和业务需求分析，制定了以下技术路线总体设计目标。5.1-1集群化数据，提升效系统拥有大量的信息，各个服务模块需要获得相关的实时信息，并将其呈现、。为了方便数据库的实时化、，对于签到功能使用的数据对象，使其属性与数据库字段相互对应，方便了在用户数据上的操作，提升了速度。学习课理模块涉及数据量大且类型复杂，将其整合在同一集合，方便数据的集群管理，提升操作效率，同时为数据挖掘分析提供了便利。模块高聚合，模块间低耦alUniversity系统同时拥有电子海报服务、院校通知服务、学习管理服务、前哨站服务、城市之窗服务五大模块，各个模块之间使用不同的逻辑业务流，学习管理服务模块中可以使用不同的挖掘推荐算法。为了在后期对数据输入、算法模型和优化算法等方面进行方便的升级和改进，降低模块升级对其它部分造成的影响，设计时应保持模块与模块之间的低耦合度，这也可以提升软件的拓展性。采用异步式I/O和分布式集群，提升数据读写效随着用户量的增加，I/O操作的并发量大幅提高，传统的I/O模式不足以满足大量同时读写的需求，智能高性能的服务器以缓解问题。使用异步式I/O配合Hadoop分布式集群结构，在满足高并发读写需求的同时，有效降低了产品成本。可视化的内容包括考勤走势及时间分布、课程相关评价关系曲线等。alUniversity系统在对数据的可视化操作上基于R语言，将挖掘分析之后的结果直观的展示给用户。使在学习管理服务模块中课程搜索功能更为直观高效，教师通过web端查阅考勤情况的数据更加真实，分析更为全面，展示更为友好美观。用户可以在web上更好地享受这一服务，PC更强的显示能力将给用户完整全面的数据体验。实时推送，打造完系统通过调用第推送接口，实现点对点的实时推送，使得用户可以第一时间掌握自己所关心的信息。实时推送配合个性订阅，将给用户带去“一机在手，天下尽知”的完验。如图5.2-1所示，alUniversity系统在数据层有着安全的系统体系，采用面向文档式的MongoDB，为了确保系统的安全，通过Mongodump导出备份数据库，完善数据库的底层机制，同时以XML格式进行数据通信，并使用W3C加密标准XMLEncryption对数据进行加密系统。采用Java、JavaScript为开发平台支持多种控件给应用层是软件开发提供技术支持。系统分为三大部分：分布式服务移动客户端WEB管理端本部分主要负责为移动客户端的以及部分数据查询，同时提供部分数据上传服务 如图5.2-2，我方将移动客户端的功能划分为用户管理、课理、海报管理、院校通知管理、迎新管理、视野信息管理、系统设置等模块。其中：用户管理包含用户登录对的以及对个人订阅的信息，数据交互对象主要是服务端的用户管理接口。管理模块：为用户提供日常信息的管理功能，分析发包客户的实情，课理、院校通知的基本信息均由发包客户现有的数据导入，提供接口即可，海报管理、以及课理的部分数据由用户日常操作获得，数据的交互主要是服务端提供的相关接口。系统设置：对本应用进行设置，包括对应用全局字体、语言设置，对一些模块的基本设置。 如图5.2-3，我方将管理端的功能划分为查询页、海报上传页两部分。其中：查询页：主要实现产品的介绍，教师对考勤信息的查询和，普通学生用户对应用的信息查询和等功能。海报上传页：主要实现VIP用户上传海报，查看海报员所发的回执信息，海报员编辑发送回执信息以及发布海报等功能。如图5.2-4服务端主要为移动客户端和管理端提供数据处理、安全控制等服务。各服务模块描述如下表5.2-1 限并做数据校验，防止数据主要对XML数据传输的安全控制以及对用户的第安全管 如图5.2-4Android上客户端应用我方采用MVC的开发模式，将整个应用划分为视图、控制器、模型三个部分。视图视图在Android中一般采用XML文件进行描述，由Widget中的一些常用控件组成，如Text、EditText、Button等。XML文件可以认为编写，也可以通过DroidDraw进行设计。在开发中，配合使用了AndroidAnimation，使得视图层富有动态效果，同时，为了丰富视图的表现形式以及满足某些业务的需求，我方在部分界面上了WebView进行深度限定。控制器在Android中，每个屏幕对应的是一个Activity对象，因此Android控制层的重任通常落在ActivityActivit中富含对视图中控件一些事件处理的函数，并根据事件处理函数调用相应模型层处理用户数据，并返回给视图层。必要时Activity需要调用Intent实现在各Activity之间的调用以及数据传递。模型我方将对数据库和网络的操作、对数据和图形的处理等放置到模型层中。在网络通信上则采用基于Socket及HttpClient的通信方式并结合REST和SOAP传递数据以保证数据传输的高效性和安全性在系统的数据传输上采用XML格式，并使用Android中轻量高效的PULL技术对XML进行解析。在客户端应用上使用SharedPreferences作为XML的缓存器，结 应用的配置信息以及用户的登录信息。技术详细如表5.2-2 WindowsOSEclipse4.3.0&JavaAndroidADT&AndroidSharedAndroidXMLAndroid数据AndroidHTTPAndroidSmartAndroidAndroidXMLAndroid上驱管理端&服务端技术架 如图5.2-5管理端和服务端在技术构架上也采用MVC的开发模式，将系统分为视图、控制器、模型三层结构。视图层为了管理页增强代码的可阅读性和可性，我方决定使用开源Node.js环境平台构建服务器和管理端。根据客户的需求，管理端我发采用时下较为成B/S架构。在浏览器的兼容性上则全面考虑目前主流的浏览器（IE、Chrome、MozillaFireFox、Opera、Safari等），在视图层的开发上使用EJSWeb模板引擎，同时配合部分的HTML、CSS和JavaScript增强效果。同时考虑到服务端需要为移动客户端提供REST服务，我方将XML作为数据传输的格式。控制器在MVC开发模式中，控制层的作用主要是接受用户请求，然后调用业务逻辑层的BusinessServer（业务逻辑处理类）进行处理并反馈。在技术架构中，为了方便提供REST服务，使用Npde.js的JSON申请开放相应组建接口，使用Connect中间件与用户建立联系，使用Get,Post对用户的请求进行路由，建立Session负责两者的信息交互，并调用业务层中的Business（业务模块）进行处理并反馈。模型层模型层分为两大模块：业务层和数据持久层。业务层主要处理系统的业务逻辑，以及对数据接口提供商数据接口的调用、运行日志的记录及缴费接口的安全控制等。数据持久层：我方采用在Node.js上成Mongoose控件，建立于数据库的有效持续双向传输。同时根据客户对开发成本的要求，以及与业务的适应程度和可扩展性，我方采用MongoDB作为数据库。Monogoose在JavaScript基础对象和MongoDB面向文档型数据库之间建立了一座桥梁使开发可以完全用面向对象的思想去设计与数据库的交互方式，并且通过已有的简单API完成对数据的操作，而不需要考虑集合与文档的结构和分片情况，降低了中间层对数据库的耦合度，方便数据库的移植和分布式处理。管理端技术详情如表5.2-3：WindowsOS系统主要在LinuxNode.jsNpmNode.jsSublimeExpressNode.jsWeb用来备份MongoDB服务端技术详情如表5.2-4WindowsOSSublimeIE6.0+,Chrome10.0+,MozillaFirefoxRforRWindows电子海报服务流程图 电子海报服务模块实现图 如图5.3-1，电子海报上传部分在web端管理页完成（见业务需求分析-管理端），下面将就各功能展开说明：申请首先由VIP用户在web端登录，到海报上传页面，填写相应的海报信息，按要求连同海报一同上传，交由海报员审核。审核海报管理员在web端登录，跳转到海报上传页面，查看上传申请，根据海报上传标准（信息组成请见业务需求分析-移动客户端电子画报管理），审核上上传请求是否符合标准。若符合标准，则发送“通过”信息给相应VIP用户，并将海报上传至数据库；若不符合标准，这发送“未通过”信息给相应VIP用户，同时注明原因。修改VIP用户若收到“未通过”回执信息，可根据注明的原因进行修改，完成后重新申请上传。查看普通学生用户可以在移动端登陆系统，点击“电子海报”，跳转至电子海报界面，下拉刷新，向服务器发送数据获取请求。服务器接受请求后，从数据库 的给用户，完成查看操作。用户可点击任一列表项，跳转到新界面，并显示海报的具体信息。评分、互动、及报名在海报具体信息显示界面，用户可以通过拖曳评分条对海报打分；也可以点击“评论”或“回复”，直接评论海报或者与评论者互动交流；可以点击“分享”，选择平台，确定后，完成；点击“报名”，填写后可以对活动完成报名，系统会将用户的经由服务器上传至相应数据库，VIP用户可在web端查看。个性订阅普通学生用户可在主页面点击屏幕做上交的菜单，右边弹出菜单，点击“订阅”后，选择“电子海报”，可以根据海报的类型进行订阅。数据将经由服务器上传至相应数据库。及时推送当用户订阅的类型有海报更新时，系统调用第推荐平台“个推”，从数据库中相应的数据，推送至指定移动客户端，实现及时推送功能。用户可在每日推荐界面看到推荐信息。本模块由课程及相关信息查询、作业发布及查看、资源上传及、考勤及情况查看/四个部分组成。课程及相关信息查询流程图Figure1课程及相关信息查询实现图 如图5.3-3，课程数据收集方案通过第导入实现（见业务需求分析-移动客户端学习管理）。下面将对各个功能展开说明。课程信息查看普通学生用户在移动客户端登陆后，选择“课理”，可查看个人课程（由教务处系统导入）。点击具体课查看课程的具体信息，信息组成请见业务需求分析-移动客户端-学习管理。教师信息查看在课程具体信息界面，点击“查看教师”，可以看到教师的相关信息，信息组成请见业务需求分析-移动客户端-学习管理。查看进入“课理”，点击具体课程后，在课程具体信息界面，点击查询信息，可查看的名称及相关信息，信息组成请见业务需求分析-移动客户端-学习管理。在信息界面的下方有相应的 ，用户点击后会跳至相应， 相应MOOC课程查看在个人课表界面，课程左上角有“M”字样的课程，表示有相应的MOOC课程资源，点击具体课程，进入课程具体信息界面，屏幕下方有相应的按钮，可到MOOC资源的相应课程。课后评价进入课程具体信息界面，点击对应课程下的“评价”按钮，会跳出评价框。学生可拖曳评分条随时对课程给出评价，也可以编辑文本对课程、、教师给出评价，该数据将经由服务器上传至相应数据库，作为数据挖掘的重要基础。教师互动进入教师信息界面后，界面下方有交互，点击后进入语音留言界面，点击“开始说话”，留言结束后，点击“结束说话”，该语音留言会经由服务器上传至相应数据库，教师用户可在web端查看。作业发布及查看流程图 如图5.3-5，作业发布功能在管理端实现（见业务需求分析-管理端）。下面将对各个功能展开说明。发布作业教师用户在管理端登陆后，点击“发布作业”，编辑作业信息（信息详细组成请见业务流程分析），确定后发布，作业信息将通过服务器上传至数据库，至此发布完成。查看作业普通学生用户在移动客户端登陆系统之后进入课理页面查看个人课表，有作业的课程块右上角有红点标记，点击该红点或者点击右上角菜单中的作业列表，可查看教师发布的作业。资源上传及流程 如图5.3-6，资源上传及功能在管理端实现（见业务需求分析-管理端）。下面将对各个功能展开说明。上传资源教师用户在管理端登陆后，点击“发布资源”，选择资源类型后，添加附件，确定后上传，资源信息将通过服务器上传至数据库，至此上传完成。资源普通学生用户在管理端登陆后，进入“查询页”，选择资源可看到已有的资源列表，选定目标后点击“”，完成资源。考勤及情况查看/流程图 如图5.3-7，考勤功能在移动客户端实现（见业务需求分-析移动客户端-学习管理），考勤情况查看及在管理端实现（见业务需求分析-管理端），下面将对各个功能展开说明。智能考勤系统安装配置时，记录每间教室的所对应的B，将其通过教室与课程对应，事先录入数据库，作为比对标准。普通学生用户在移动客户端登陆系统，进入课理页面，在个人课表中找到要点到的课程，点击签到按钮，系统会自动当前时间与所到的发射器的B，将他们打包上传至服务器，服务器将之与数据库中的记录比对，若B 与时间均正确，签到有效，录入数据库，负责签到失败，返回失败通知。考勤情况查看教师用户在管理端登陆后，进入查询页，选择对应课程和时间，可以查看考勤状况，并可选择以图表（支持饼图、柱状图、频率分布直方图）式展示考勤数据。教师还可在此界面下删除此次考勤记录。考勤情况教师用户在管理端登陆后，进入查询页，选择对应课程和时间，点击，可以此次考勤记录（以excel）形式导出。依照数据来源不同，本模块可分为院校及就业通知与班级通知两部分。院校及就业通知实现图 如图5.3-8，院校及就业通知发布在管理端实现（见业务需求分析-管理端），下面将对各个功能展开说明。数据连接院校及就业通知会通过第数据获取，经由服务器将数据导入数据库通知查看普通学生用户在移动客户端登陆后，若有新通知送达，可以在“每日推荐”页面的上方直接看到；否则用户可进入“院校通知”页面，在相应的下可看到相应。通知推送推送功能基于第推送平台“个推”提供的接口实现数据库更新后，触发“个推”的推送检查事件，院校通知以通知的目标学院为根据，就业通知以用户的个性订阅设置为根据，将通知发送给所有符合条件的用户。个性订阅普通学生用户可在主页面点击屏幕做上交的菜单，右边弹出菜单，点击“订阅”后，选择“电子海报”，可以根据海报的类型进行订阅。数据将经由服务器上传至相应数据库。班级通知服务流程图 如图5.3-9，班级通知功能发布在管理端实现（见业务需求分析-管理端），班级通知查看在移动端实现（见业务需求分析-移动客户端），下面将对各个功能展开说明。通知发布教师用户（班）在管理端登陆后，点击“发布班级通知”，在相应页面中编辑好通知内容后，确认发布，通知通过服务器上传至院校通知数据库。通知推送推送功能基于第推送平台“个推”提供的接口实现数据库更新后，触发“个推”的推送检查事件，以行政班为根据，将通知发送给所有符合条件的用户。通知查看普通学生用户在移动客户端登陆后，若有新通知送达，可以在“每日推荐”页面的上方直接看到；否则用户可进入“院校通知”页面，在“班级通知”下查看班级通知内容。本项目开发选用的数据库是MongoDBMongoDB在应对高并发读写上效率高。本产品保证用户的粘性的模块MongoDB相比传统数据库能适用于Hadoop全数据库全份控制保证数据库环境的物理安全，如交换机、网线的安全；保证使数据库在物理上只有数据库管理员才能接触；使用UPS电源对服务器进行保护，一旦遭遇断电，能够采取措施让服务器安全关闭，防止数据因系统停止造成错误。对账号进行管理，设置策略和权限控制以及用户认证，从账号的安全性方面来数据库的安全性。保证以下几点：避免账号列举。比如，非管理员获得所有数据库用户账号列表—个用户只需要进行数据库的查询工作，那么这个用户使用的权限就只能局限于find语句，而不能有delete、update等语句的使用权限。权限的扩散以及应用范围的是控制的一大；最高权限最小化原则。确保不会分配多余的管理员权限账号。管理员账号的数量和安全性是成正比的；账号安全原则。分配账号的必须符合安全原则的要求。基本密码安全要求包括：长度（8位以上）、复杂性（必须同时包括字母、数字和符号）、结构非连续性等。或者采取 保证用户认证足够安全。是否经过加密，确保认证过程的安全性，用户认证过程是否有日志记录。必要情况下必须采用比如SSL加密；文件的控制。确保文件不会修改、删除。这些文件包括数据库系统文件、数据库文件、日志文件以及备份文件等。服务器与客户端之间的传输过程以XML格式进行数据通信，并使用W3C加密标准XMLEncryption对数据进行加密系统。采取定期的进行数据备份的让数据库遭到破（或者误操作后，恢复数据资源。为了防止为因素如火灾等对数据库进行物理上的破坏，将定期对数据库进行异地备份，能够在意外发生时将损失控制到最小。5.5基于 的WI-FI定 ，一种特殊的Ad-hocLAN的应用，也称为BasicServiceSet(BSS)，一群计算机设定相同的BSS名称，即可自成一个group。每个BSS都会被赋予一个B ，它是一个长度为48位的二进制标识符，用来识别不同的BSS。其的主要优点是它可以作为过滤之用。与 不同， 是指站点的MAC地址，（STA）在一个接入点（AP）在一个基础架构模式，BSS是由IEEE802.11-1999无线局域网规范定义的。这个区域唯一地定义了每个BSS。在一个IBSS中，B 是一个本地管理的IEEEMAC地址，从一个46位的任意编码中产生。地址的/组位被设置为0。通用/本地地址位被设置为1。为每个教室安装无线，构建Ad-hocLAN网络，就可以根据B 唯一性，唯一标示用户所处的地理范围。同时B 获取方便利用JAVA自带的WifiManager和WifiInfo两个类，调用其中已经定义好的函数getB()，即可获取到当前连接的无线的B。“个推”是国内最专业的第消息推送技术服务方案，“个推”系统在低成本下，能够保证APP消息推送的时效性、有效性、稳定性，并且为用户省电省流量。“个推”为企业提供企业级的解决方案，帮助应用开发商快捷、高效的建立自己的推送服务系统，从而专注业务，快速融入市场。“个推”提供企业级的解决方案，依托于已有成推送技术，帮助应用开发商快捷、高效的建立自己的推送服务，并最终完善自己的服务体系快速融入市场。“个推”有一下三种服务模式：提供Android和iOS推送SDK支持WEB及服务器端推送API接入支持和业务整合模式“个推”帮助企业的应用通过低成本互联网通道进行消息推送，提供完善、高效、稳定的服务体系，解决了互联网云端到端的消息互通问题。我方此次仅需使用第一种服务模式，为“个推”的用户，便可以为自己的APP申请推荐服务。申请通过后只需要在APP中加入“个推”提供的SDK即可。“个推”服务用户量在1万以下不收取任何费用，对项目初期的没有任何影响，同时还保证了推送的及时性和准确性。借助第已经成技术，可以缩短系统的整个开发周期。AprioriApriori算法是一种挖掘关联规则的频繁项集算法，其思想是通过候选集生成和情节的向下封闭检测两个阶段来挖掘频繁项集。该关联规则在分类上属于单维、单层、布尔关联规则。该算法首先找出所有的频集，这些项集出现的频繁性至少和预定义的最小支持度一样。然后由频集产生强关联规则，这些规则必须满足最小支持度和最小可信度。然后使用第一步找到的频集产生期望的规则，产生只包含集合的项的所有规则，其中每一条规则的右部只有一项，这里采用的是中规则的定义。一旦这些规则被生成，那么只有那些大于用户给定的最小可信度的规则才被留下来。但为了生成所有频繁项集，算法可能会使用到递归去遍历数据库，同时可能产生大量的候选集，以及可能需要重复扫描数据库。但在初期数据量较小的情况下，采用分布式hadoop系统架构，可以用最小的成本解决这一问题。Apriori算法已普遍应用于高校管理中。对于本系统，针对经典Apriori挖掘算法存在的不足进行改进，先将事务数据库为一个布尔矩阵，用一种逐层递增的思想来动态的分配内存进行，再利用向量求"与"运算，寻找频繁项集。求出各种课程之间的受欢迎程度的关系和它们之间的影响，帮助发包方更好地完成教改，优化课程。4的出世，掀起智能机热潮，功能强大的便携式数据终端（如智能手机）得到了广泛的应用。智能的普及给人民带来了巨大的便利，同时无线局域网的发展也为种种需要数据流量的软件的普及提供了契机。加上近年来校园APP如雨后春笋般层出不穷，自2013年教育部下发的《关于开展高校科研管理信息化工作调研》，更是促进了校园APP的研发。随之带来的便是诸多贴近学生生活的功能。然而在这些功能中有很多都是可有可无，如点外卖，而且偏向开发学生端，而忽视了教职工端。并且功能上黏着性不高，无法保证用户的数量，导致应用成为鸡肋。此外在教务教学与教学方面的涉更是少的，除了一些课程表类型的校园APP，其他APP很少做到教学与教务的结合，真正做到拥有一个学校特色的校园APP。因此具备校园特色的校园APP在这个问题中可以发挥巨大的作用。、网易等这些企业存在已久，而且也们所熟悉，并且无论技术还是上都非常雄厚，而且有一定的口碑和知名度，一旦成功开发校园APP，也会首先被用户选择使用。、超级课程表 等校园APP存在已久，且已具备一定的用户群体。之前就在实用校园APP的用户，难免会有先入为主的观念。、对 由于是需要联网使用的产品，必须在联网的情况下使用，对网络环境提出了新的要求。商业推广通过讨论上网将教务与教学结合的校园APP，保证了用户的黏着性意味着就有了一定数量的用户群里。在这基础上，紧随而至的便是良好的商业前景。如第二阶段开始，逐渐强化完善产品功能， alUniversity转变成OPENUniversity，就会面向全省，甚至的高校，那么出开发者所在高校外，必须后才可使用。这样一来用户群里数量就会不断增大，便会吸引诸多商家企业的眼球，我们不去找他们，他们也会来找我们合作。alUniversity软件本身免费，用户不需支付任何费用即可安装实用产品功能完善，避免同类软件功能重复单一，产品中信息的传输是双向的，且用户的选择权利大，根据自己的喜好和进行个性订阅。产品功能的开发一切以给用户来带便利为重心，加上教务与教学的整合，不可避免的就会牵涉到成绩考核，这就保证了只要 alUniversity被学校认可，那么至少保证了一个学校的师生群体肯定要用这个产品。因此不会出现有应用而没用户的现象，更可吸引诸多商机。alUniversity产品基本策我们的总体策略是：从小做起，不断完善产品—个成功的产品依仗自身的安全性、可靠性等优势，但是一个成功的产品也同时需要成功的 来进行推广。在分析了行业特性之后，我们设计出一套推广计划，有助于 alUniversity产品的成功市场化。免费通常是吸引人眼球的主要方法之一。用户使用免费的产品，无需任何额外的费用即可安装使用（这里主要针对开发团队所在学校，后期产品逐渐完善，功能逐渐强大，我们会面向全省，甚至的高校，那么高校就需要支付一定的费用），抓住了人们的心理特点，对产品的推广有一定的帮助。当然产品面向用户是免费的，然而我们的产品一定程度上也是一个良好的平台，相信会吸引很多商家的眼球。Android、Ios、Windowsphone等主流操作系统对应的应用市场的影响力都比较大，在其应用市场中进行推广，发布产品，同时发布内置应用，列在新品推荐中，更便于用户搜索，提高搜索量，然后在拥有一定能够用户群体后有选择的植入进行。参与范围内的应用产品展示会。向有使用意向的潜在用户推广邮件和，电子邮件具有极低成本的优势，同时也不会造成客户负担。alUniversityalUniversity产品拟与主流操作系统对应的应用商店进行alUniversity产品的项目风险分析方法采用了著名的软件工理践组织SEISoftwareEngineeringInstitute ContinuousRiskManagement）模型。不断地评估HELP产品实施过程中可能造成恶劣的因素；本团队能够在第一时间决定最迫切需要处理的风险并且给出控制风险的策略，并有专员评测并确保风险策略实施的有效性。具体流程如图6.4-1所示：风风alUniversityalUniversity在风险识别期，结合服务外包各个阶段的风险特征来考虑，分为5个阶段：可行性分析阶段该阶段主要是对HELP产品项目决策的过程，包括是否做该项目、如何做、是多少等。如果无法冷静客观地做出科学的分析，将会对后续工作造成不利的影响，甚至会因为不足造成项目中途失败。合同阶段该阶段主要工作来源于供应商选择和合同制定，以及是否采用合理的组织架构将组织起来。该阶段是后续项目实施的基础，对后续工作开展的进度和有效性将起重要作用。开