| 可行性分析 | 您所在的位置：网站首页 › 云容器技术在经济方面的可行性研究 › 可行性分析 |
可行性分析
|
技术可行性，经济可行性，操作可行性，其他可行性，系统流程图，数据流图，数据字典 摘要 本可行性分析基于大学图书馆占座乱象，分析得出搭建图书馆选座助手的必要性。从技术可行性、经济可行性、操作可行性等方面具体分析桌面端、移动端和微信小程序端的优劣，最终通过比较得出基于微信小程序构建该系统更为可行。 本文第一章对大学图书馆占座现象进行现状分析，得出该系统构建的必要性。第二章主要分析技术可行性，主要从系统技术要求、开发人员技术要求和系统结构方面进行论述，其中系统技术要求包括核心技术分析、硬件要求可实现性和用户友好性。第三章主要对经济可行性进行论述，包括项目支出和项目收益方面。其中项目支出包括开发成本和运营成本，项目收益包括经济效益和社会效益。第四章主要论述操作可行性。第五章继续分析其他可行性。最后一章得出结论。 引言 微信小程序（WeChat mini programs）是由腾讯微信事业部开发，2017年1月9日上线，是一种无须下载安装即可使用的应用，可以与微信公众号绑定，用户通过搜索或扫描二维码即可找到并打开应用，体现了”用完即走“的理念。 微信小程序是一种比现有移动端App更加灵活、更加渐变的全新App平台，运行在微信小程序中的应用，无需考虑移动设备的操作系统是IOS或Android，不占用独立内存和存储空间。 高校的图书馆一般是校园中最理想的的学习场所。图书馆不仅蕴藏着丰富的文献和学习资源，而且具备齐全的硬件设施。而如何合理配置这些公共资源的使用，则成为了管理难点。尤其是座位的”占座“问题尤为突出：有的读者用书本、杯子等占座工具占着座位，却一天都不使用，造成了极大浪费。 在这种背景下，本项目小组计划设计基于小程序的图书馆选座助手，通过良好的可视化界面实时展示图书馆座位的状态，并能够实现用户与系统的友好交互。通过网络实现预约座位，解决图书馆排队、占座等问题，希望能够改善图书馆座位资源浪费的情况，并提高图书馆座位资源的利用率。 同时，小程序的读者使用选座、预约、暂离等行为数据，可以剖析用户群体对图书馆资源的使用规律，发掘和提炼出相关信息，以此进一步改进图书馆的硬件资源分配，为图书馆的管理者提供决策依据，形成良好的反馈机制。 1. 现状分析 1.1 桌面端选座系统 现有的自助选座预约系统主要基于设置在图书馆的触屏电脑来实现预约选座和到场签到，多个阅览室，多个楼层需要部署多个触屏电脑，这些硬件设备需要大量的资金和人力进行维护，效费比并不高，同时也会带来高峰期大量用户排队选座、签到等方面的问题。 1.2 移动端App选座系统 相比于桌面端，移动端是更适合选座预约系统的主要载体，选座App也应运而生。选座App基本可以解决上文提到的触屏电脑设备选座的痛点，但是它也存在着一些不足：需要针对IOS和Android两套不同的环境定制开发App；后期维护App需要一定的人力和财力；App的推广效率低，下载、安装程序复杂，用户也容易出现流失。 1.3 移动端小程序选座系统
微信小程序的出现，给自助选座预约系统带来了更优解。从引言中小程序的特点我们可以看出，微信小程序能够更好地契合图书馆预约选座的而需求。首先，微信拥有庞大的用户群体，高校的学生们手机中绝大部分都安装了微信；其次，小程序不需要下载、安装，不需要占用设备的存储空间，大大降低了用户的使用成本；最后，微信小程序推广便捷，可以通过扫描二维码、同学之间互相分享和搜索小程序名称等方式启动。 2. 技术可行性 2.1 系统结构 2.1.1 系统流程图 2.1.1.1 图1：系统流程图（用户）
图1:系统流程图（用户） 2.1.1.2 图2：系统流程图（管理员）
图2:系统流程图（管理员） 2.1.1.3 图3：数据流图 数据流图（用户）
图3:数据流图（用户） 2.1.1.4 图4：数据流图（管理员）
图4:数据流图（管理员） 2.1.1.5 图5：数据流图（违规用户）
图 5:数据流图（违规用户） 2.1.3 数据字典 2.1.3.1 表格1：学生表（Student）
表格1: 学生表（Student） 2.1.3.2 表格2：阅览室座位表
表格2: 阅览室座位表 2.1.3.3 表格3：预定表
表格3:预定表 2.1.3.4 表格4：阅览室表
表格4:阅览室表 2.1.3.5 表格5：黑名单表
表格5:黑名单表 2.1.3.6 表格6：管理员表
表格6:管理员表 2.2 系统技术要求 2.2.1 核心技术分析 2.2.1.1图书馆助手微信小程序开发技术可行性分析 图书馆助手微信小程序，作为一种不需要下载安装即可使用的应用，自身分为两个主要部分独立运行：view模块和service模块。因此，对微信小程序的技术性分析应该围绕这两个模块来进行展开分析。 2.2.1.1.1 View模块开发技术分析
View模块负责UI显示，即做小程序的前端开发。前端开发是创建Web页面或APP等界面呈现给用户的过程，进而实现微信小程序的用户界面交互功能。常见的Web或APP前端开发过程需要用到三项核心技术，分别是HTML，CSS以及JavaScript。而在微信小程序中则使用类似于HTML的WXML来描述页面的结构、使用类似于CSS的WXSS来描述节点的样式，依然使用JavaScript 脚本语言编写逻辑代码。下面分别就WXML、WXSS、JavaScript进行介绍。 WXML 在介绍WXML之前，首先要对HTML进行介绍。 HTML的英文全称是 Hypertext Marked Language，即超文本标记语言。HTML是由Web的发明者 Tim Berners-Lee和同事 Daniel W. Connolly于1990年创立的一种标记语言，它是标准通用化标记语言SGML的应用。用HTML编写的超文本文档称为HTML文档，它能独立于各种操作系统平台(如UNIX， Windows等)。使用HTML语言，将所需要表达的信息按某种规则写成HTML文件，通过专用的浏览器来识别，并将这些HTML文件“翻译”成可以识别的信息，即现在所见到的网页。 在微信小程序中，使用了WXML而非HTML来实现文件的“翻译”识别，它的功能与HTML相对应。二者的区别在于： 开发工具限制：WXML仅能在微信小程序开发工具中预览，而HTML可以在浏览器内预览。 组件封装不同：WXML对组件进行了重新封装，为后续的性能优化提供了可能，同时避免开发 者写出低质量的代码。 是否有DOM树：小程序运行在JS Core内，没有DOM树和window对象，没有办法使用相关API。 WXSS 与WXML对应HTML相类似，WXSS对应CSS，是微信小程序开发特有的与CSS功能近似的语言。 CSS (英文全称：Cascading Style Sheets),即层叠样式表，是一种用来表现HTML等文件样式的计算机语言。CSS不仅可以静态地修饰网页，还可以配合各种脚本语言动态地对网页各元素进行格式化。CSS 能够对网页中元素位置的排版进行像素级精确控制，支持几乎所有的字体字号样式，拥有对网页对象和模型样式编辑的能力。 WXSS对CSS进行了补充和修改： 将图像处理的像素单位从rem改为rpx，rpx可以根据屏幕宽度进行自适应。 使用@import标识符来导入外联样式。@import后跟需要导入的外联样式表的相对路径，用;表示语句结束。 框架组件上支持使用 style、class 属性来控制组件的样式。 JavaScript 无论是Web、app还是微信小程序，都是用JavaScript为界面增加动态功能。 JavaScript是一种属于网络的脚本语言,在微信小程序里 ,常用来为程序界面添加各式各样的动态功能,为用户提供更流畅美观的浏览效果。通常JavaScript脚本是通过嵌入在WXML中来实现自身的功能的。 小程序开发技术框架对比分析 而进行小程序前端开发之前，结合项目本身选择合适的小程序框架是十分必要的一项技术分析。所谓框架（Framework），在软件工程学科中，是构成一类特定软件可复用设计的一组相互协作的类。框架规定了应用的体系结构。它定义了整体结构，类和对象的分割，各部分的主要责任，类和对象怎么协作，以及控制流程。框架预定义了这些设计参数，以便于开发人员能集中精力于应用本身的特定细节。微信小程序发展到今天，主要有原生，Wepy，Mpvue，Taro 这4种框架，以下的对比分析也是在这4种方式中。 原生框架 框架需要技术人员在开发过程中自行搭建，即需要学习小程序的书写格式，目前小程序开发版本模板中支持 slot，但是不支持 npm 包。原生开发也不支持 css 预处理器。总之，原生框架对工程化上支持并不友好，对没有丰富编程经验的小组人员而言，更是难度过大，所以可以排除在外。 其他三个框架 Wepy，Mpvue，Taro这三个框架是面向开源项目开发的，考虑到本图书馆小助手未来可能使用开源插件和UI库以实现某些特定模块的功能，Taro是最近推出的，UI界面需要开发人员自己设计。相较于Mpvue,Wepy框架受众更广泛，热度更高。因此，暂定使用Wepy框架进行图书馆助手小程序的开发。 综合上面的分析，对View模块的开发技术难度不高,大部分技术可以通过查阅微信官方提供的小程序开发手册进行应用，同时开源的框架极大降低了开发的难度，因此是可行的。 2.2.1.1.2 Service模块开发技术分析 与view模块相区别，service模块负责应用的后台逻辑。 View模块实现了小程序的后端开发，通常也称服务器端开发。顾名思义开发的是小程序的后端，并不对用户显示，即对用户而言是透明的。Service模块类似于后勤，负责处理前端的请求，进行逻辑处理和数据交互。在图书馆助手选座功能实现过程中，例如用户提交座位申请，service模块进行逻辑判断，是否申请有效、是否违规，若符合要求则将用户和座位信息分别在数据库中进行更新。 Service模块功能由小程序的.Json代码以及微信提供的相关辅助模块实现。开发人员只需学习.json语言并能理解和应用辅助模块，即可实现这Service模块的技术开发，因此有很高的可行性。 2.2.1.1.3 模块间通信技术分析 在微信小程序中存在一个负责UI与后台进行交互的一个中间层，称之为WeixinJSBridge。它相比之前的微信webview多出publish和subscribe两个公共方法来发布和订阅事件，从而实现两个模块间的通信。这项技术是内嵌在微信小程序开发环境中的，无需开发人员关心，因此是可行的。 2.2.1.1.4 数据库技术分析 图书馆助手的核心功能，是实现用户信息和座位信息的对比更新。在这个过程中，座位和用户作为两个实体，要求一位用户只能选择一个座位，而单个座位只能被一位用户选中，于是一对一的绑定关系就出现了。因此需要一个记录、存储以、更改、删除这种绑定关系的“容器”。 数据库技术即充当了这个“容器”的角色，是实现图书馆助手小程序功能的关键。数据库技术现已发展的十分成熟，各类中小型数据库可以流畅运行在一般通过数据库技术来实现小程序的开发在技术上是完全可行的。 2.2.1.1.5 结论 从技术上层面上来说， 鉴于微信小程序开发技术目前已经发展的十分成熟，可以满足本项目的使用要求。图书馆助手的开发和运营对硬件设备要求并不高，Web和数据库服务器等设备可以通过学校采购得到解决，所需费用并不多。软件方面所需要的操作系统可以采用 windows 系统，也可以采用开源的 linux 系统。系统开发软件采用腾讯官方提供的小程序开发环境。数据库系统采用MySQL数据库系统。因此，这些必须的操作系统、开发环境和数据库系统都具备技术可行性。研发技术力量方面，可以通过咨询、研究同时查阅相关文献资料，也可以请教有经验的开发人员，应该能够达到要求，完全满足系统开发。 2.2.2 硬件要求可实现性 图书馆选座助手运行需要一系列硬件设备的支持，下面将小程序平台与桌面端程序、移动端App平台三者进行对比，分析其硬件要求的可实现性： 2.2.2.1 运行于触屏电脑上的选座系统 根据触屏一体机直接定制选座系统，用户进行的选座操作都在一台触屏一体机上进行。用户的信息可直接储存于硬件设备内，不需要云端服务器的支持，管理员直接将数据库文件导入到触屏电脑内。 若为单阅览室配备选座系统，则一台设备即可实现硬件要求。 若为大型图书馆、多阅览室配备选座系统，则每个阅览室都需要配备触屏电脑，并使用局域网将其连接。除了多台触屏电脑外，还需要路由器/交换机、网络连接线等硬件设备组件局域网，以实现馆内选座信息的共享。 对于触屏电脑的性能要求，选座系统程序对性能要求较低，市面上千元级别的触屏电脑的配置（例：intel双核x86处理器，2G运行内存，>100G储存）都能满足其要求。经过定制化的选座系统都能在硬件设备上流畅运行。 对于触屏电脑的屏幕大小要求，需要彩色LED大尺寸触控显示器，为保证用户的触控体验，显示器的的尺寸至少要达到20寸为宜。 2.2.2.2 App选座系统的用户硬件要求 对于在手机上运行的App选座系统，对于用户而言，选座系统App的功能较为单一，系统占用量低，能够流畅地运行于主流Android移动设备和IOS移动设备上。 同时，安装App需要占用用户手机的一小部分存储空间。 2.2.2.3 小程序选座系统的用户要求 对于微信小程序平台上的选座系统，对于用户而言，只要是满足安装微信的智能移动设备，都能够运行小程序。和App相比，小程序不需要占用额外的存储空间。 2.2.2.4 App选座系统和小程序选座系统的服务器要求 基于移动端的两种方案都需要使用云服务器来对用户的操作进行处理，同时在云服务器上实现数据存储。云服务器的要求主要考虑几个方面： 云服务器性能：选座系统使用人数/同时在线人数越多，就越需要高配置服务器，而配置越高的服务器安全性，稳定性也就越高。对于学院级的图书馆，能够提供100~200位同学的选座服务，双核2G的配置基本能达到要求。 云服务器带宽：在选座系统开始启用阶段，可以先选用较低配置的5Mbps带宽，当用户数量稳定后，可以根据并发量峰值和日常流量为服务器定制合适的带宽套餐。 服务器机房线路：选择服务器机房的时候，应选择多线路（移动、联通、电信）的机房，而且线路能够快速响应连接。这样的话客户无论使用哪一个运营商的网络打开，都能保证访问和下载的流畅性。 云服务器防火墙：云服务器在日常使用过程中存在一定的安全隐患，比如常见的DDOS攻击，会造成服务器瘫痪等一系列问题，这就要求服务器有一定的安全防御机制。 综合上述的要求，项目团队可以从几家云计算服务提供商（如腾讯云、阿里云等）购买合适的云服务器，对于微信小程序的载体，可以直接选择腾讯云的服务。 2.2.3 用户友好性 桌面端选座系统、移动端的App、小程序平台三者在用户友好性方面（如UI美观、易于用户理解、便于操作等）都能够设计出满足要求的选座系统。下面分述其优劣： 2.2.3.1 桌面端触控电脑选座系统 在桌面端，设计在触屏电脑上的选座系统能够充分调用硬件、系统等资源，并且针对大屏幕的触屏进行深度优化，设计美观，贴合大屏幕的UI。在流畅性方面，由于数据存放于本地，或在图书馆内通过小型局域网传输，用户的操作能够得到快速的反馈。在用户现场使用其系统时，使用体验无疑是三者中最好的，但由于设备的限制，只能一对一的保证单用户的良好使用体验。在选座高峰期时，需要用户现场排队有序使用。 2.2.3.2 移动App选座系统
对于在IOS或Android系统上的选座App，用户通过自己的手机就可以选座，解决了前者大量用户并发导致的问题。在移动端的选座系统虽然不及大屏幕触控能够快速直观第传递大量选座信息，但也能通过对移动设备的界面优化保证用户能够精确、快速地选到适合自己的座位。 2.2.3.3 小程序选座系统
相较于App，小程序依托于微信平台，功能形态方面只能通过微信开放的接口去实现功能。但小程序提供的接口对于实现图书馆选座系统已经足够，并不会因为接口的缺失而对用户体验造成影响。同时，在用户易用性方面，小程序独有的”即开即用，用完即走“的设计更贴合用户在日常的学习生活中对选座的需要。 2.3 开发人员技术要求 根据微信小程序的特点，开发人员需要具备下列技术和能力： 熟练使用WXML、WXSS、Javascript、.json语言; 对小程序的开发框架要十分了解并能合理选择; 熟悉微信小程序一系列组件的使用; 熟悉微信特有的API接口; 熟练运用数据库技术。 3. 经济可行性 3.1 项目支出 3.1.1 开发成本 3.1.1.1 人力成本：按代码行数计算，1元/行 桌面端约需要1500行代码 移动端需开发ios端与安卓端，各约需要1500行，共计3000行代码。 小程序开发约需要1000行代码 3.1.1.2 硬件设施： 开发过程中计算机、网线等费用，计为2000元。 桌面端所需触屏设备等：3000元 3.1.1.3固定费用： 小程序开发需要费用如下： 小程序认证服务费：300元/年 云服务器与域名费：按人数大小选择，暂定1核2GB 1核1GB：692.22元/年 1核2GB：1010.94元/年 1核4GB：1329.66元/年 移动端需要费用如下： 服务器租用：暂选双核2G，约5000元/年 APP上架费用： 安卓端：不需要费用 ios端：99美金/年，换算为人民币为693元/年（按汇率为7计算） 3.1.1.4调研费用： 预计发放线上问卷300份，每份成本计为0.5元。线下问卷100份，每份成本计为1元。 3.1.1.5不可预见费用： 按开发费用15%计算。 3.1.1.6表格7：开发成本表：
表格7:开发成本表 3.1.2 运营成本 3.1.2.1系统维护费： 小程序：1人/年，参照北京系统维护人员平均工资6000元/月。 移动端：2人/年，参照北京系统维护人员平均工资6000元/月。 桌面端：1人/年，参照北京系统维护人员平均工资6000元/月。 3.1.2.2 固定费用：
小程序认证服务费：300元/年 云服务器与域名费：1核1GB：692.22元/年 1核2GB：1010.94元/年 1核4GB：1329.66元/年 移动端需要费用如下： 服务器租用：暂选双核2G，约5000元/年 APP上架费用： 安卓端：不需要费用 ios端：99美金/年，换算为人民币为693元/年（按汇率为7计算） 3.1.2.3 硬件租赁费： 根据3.2.2.1内容，桌面端触摸屏设备共需10台，采用租赁形式，计为每台每年300元。 3.1.2.4 硬件维护费： 桌面端触摸屏设备的维护按照每年每台300元计算。 3.1.2.5 不可预见费用： 按总费用的15%计算 3.1.2.6表格8：运营成本表/年
表格8:运营成本表/年 3.1.2.7表格9：年总成本表：
表格9:年总成本表 3.2 项目收益 3.2.1 经济效益 3.2.1.1 系统租赁收益： 预计每年向至少10位用户提供服务，收费10000元/年。 3.2.1.2 广告收入： 预计每年招商至少100条广告，每条收费100元。 3.2.1.3 表格10：年总收益表：
表格10:年总收益表 3.2.1.4 表格11： 年净收益表：
表格11:年净收益表 3.2.1.5 表格12：投资回收期表：
表格12: 投资回收期表 3.2.1.6 总结： 根据成本收益分析，因桌面端硬件部分支出较多，移动端因需考虑ios与安卓两部分用户导致成本较高，故小程序端开发图书馆占座系统收益更多，更为妥当。 3.2.2 社会效益 3.2.2.1 对学校: 优化校园管理，提高校园服务，为同学提供更高效的更便捷的图书馆占座系统，优化同学们的自习体验。 更大程度上利用了图书馆的自习资源，减少了之前因不文明占座而造成的资源浪费，使得物尽其用。 可以有效避免同学们因占座问题所引发的矛盾，有利于营造良好的校园环境。 3.2.2.2 对学生： 优化了学生的自习流程，最大程度上节省了学生的时间。 规范了学生的自习活动，约束了学生的不文明行为。 3.2.2.3 对社会： 减少社会资源的浪费，优化资源配置。 减少校园争端，有利于构建和谐社会。 4. 操作可行性 4.1 系统对组织机构的可行性 本系统最终呈现结果微信小程序形式，若将本系统投入运营，将会优化图书馆占座系统，更有效地运用图书馆座位资源，减少资源浪费。通过占座系统的引入，可以优化图书馆座位的管理，减少座位管理过程中相应人力物力的投入。 4.2 目标用户适应的可行性 本系统充分考虑组织机构和优化需求等方面的因素，能够满足目标用户群体的需求。本系统目标用户为各大高校在校学生。这一部分目标用户学习能力较强，对系统功能学习适应较快，且本系统表现层即用户界面直观友好，操作简单，功能划分清晰全面，用户只需对选座信息管理和个人信息管理业务了解即可短时间内进行操作使用。同时，通过使用该系统可以优化学生的自习体验，节省学生的时间，学生使用该系统的积极性较高。 4.3 接收设备适用的可行性 本系统基于微信小程序，用户只要登录微信即可应用本程序，对用户手机要求比较低。另外，基于微信的小程序开发不受限于ios与安卓系统，不论哪个系统都可通过登录微信进行本程序的使用。 5. 其他可行性 5.1 法律可行性 5.1.1 用户信息（隐私）保护的可行性 该图书馆管理系统主要在校园图书馆内使用，图书馆综合管理系统在使用过程中会使用到部分学生的信息。在使用信息之前，要保证用户在知情的情况下对用户信息进行合理的操作，对重要的用户信息进行加密传输，维护用户信息的安全性。 5.1.2 系统开发模块和软件来源的可行性 对于开发本软件所使用的的硬件，均采用正当途径获得，操作系统均采用正版授权的Windows、MacOS系统。 对于本系统开发所使用的的软件工具，来源于北京大学正版软件共享平台或其他开源软件，相关人员在开发过程中会杜绝盗版、未授权工具的使用，避免侵权与违反法律。 当软件的开发需要借鉴其他开源项目时，开发人员需要关注代码遵循的开放协议，合理使用开源项目。 5.2 系统信息安全性
整个系统完成后，将会有很多师生使用。系统在运行中，会涉及到部分学生信息，甚至还会涉及到学校图书馆整体资源的详细信息。这些信息都是需要不断访问的，还要进行储存，处理，传送。一旦学生信息的安全性被破坏，不仅仅是影响座位系统的运行，还将产生无法想象的危害。因此，安全性对于整个软件系统的设计是至关重要的。 在开发过程中，开发人员需要在数据及安全操作性方面精细化控制，不能过于粗放化。同时，还要对数据进行定期备份，提高系统数据的整体安全。 5.3 密码安全性 系统密码规定为长度8-12位之间，使用数字+大小写字母组合形式，同时避免连续的数字或连续字母这样安全性弱的密码。同时在密码找回方面，要确定用户身份，通过手机验证码等方式保证密码安全，避免非法篡改。在密保问题的设置上，减少使用易于破解的密保问题，以增加密码的安全性。
6. 结论 基于上述分析，通过比较图书馆占座助手的桌面端、移动端和小程序端的技术可行性、经济可行性、操作可行性及其他可行性，得出基于微信小程序搭建该系统更为妥当。在微信小程序上搭建该系统，技术方面更便于实现。在经济方面，微信小程序的投资更少，回报周期更短，能获得更大的利益。其他可行性方面，微信小程序也具有显著地优势。所以，综上所述，基于微信小程序搭建图书馆选座助手系统可行。 Powered by Froala Editor |
【本文地址】