基于 nodejs+vue 的 nuct 产品售后管理系统 python-flask-django-php
同时还能为用户提供一个方便实用的nuct产品售后管理系统,使得用户能够及时地找到合适自己的产品。管理员在使用本系统时,可以通过后台管理员界面管理用户的信息,也可以发布产品售后信息,让用户及时了解nuct产品售后信息。这样,用户就可以安全高效地找到nuct产品售后信息。
前端技术:nodejs+vue+elementui,
Express 框架于Node运行环境的Web框架,
语言 node.js
框架:Express
前端:Vue.js
数据库:mysql
数据库工具:Navicat
开发软件:VScode
视图层其实质就是vue页面,通过编写vue页面从而展示在浏览器中,编写完成的vue页面要能够和控制器类进行交互,从而使得用户在点击网页进行操作时能够正常。
代码结构讲解
1、 node_modules文件夹(有npn install产生)
这文件夹就是在创建完项目后,cd到项目目录执行npm install后生成的文件夹,下载了项目需要的依赖项。
2、package.json文件
此文件是项目的配置文件(可定义应用程序名,版本,依赖项等等)。node_modules文件夹下的依赖项是从哪里知道的呢?原因就是项目根目录下的这个package.json文件,执行npm install时会去找此文件中的dependencies,并安装指定的依赖项。
3、public文件夹(包含images、javascripts、stylesheets)
这个文件夹做过Web开发的应该一看就知道,为了存放图片、脚本、样式等文件的。
4、routes文件夹
用于存放路由文件。
5、views文件夹
存放视图。
目录
第1章 概 述 3
1.1 开发背景及研究意义 3
1.2 国内外研究现状和发展趋势 3
1.3 本文主要研究的内容 4
第2章 关键技术介绍 5
2.1 开发环境 5
2.2 nodejs技术 5
2.3 MySQL数据库 5
2.4 express框架 6
2.6 本章小结 6
第3章 系统分析 7
3.1 系统概述 7
3.2 需求分析 7
3.3 可行性分析 8
3.3.1 技术可行性分析 8
3.3.2 经济可行性分析 8
3.4 本章小结 9
第4章 系统设计 10
4.1 系统基本结构设计 10
4.2 数据库设计 11
4.2.1 数据库E-R图设计 11
4.2.2 数据库表设计 13
4.3 本章小结 39
第5章 系统实现及主要代码 40
5.1管理员模块实现 40
5.2客户模块实现 45
5.3受理人员模块实现 45
5.4工程师模块实现 47
5.5厂商模块实现 48
5.6本章小结 49
第6章 系统测试 50
6.1 系统测试的目的 50
6.2 系统功能测试 50
6.2.1 登录注册功能测试 50
6.2.2 用户管理功能测试 51
6.3 本章小结 51
结 论 52
参考文献 53
致 谢 54
随着社会的发展,nuct产品售后的管理形势越来越严峻。越来越多的用户利用互联网获得信息,但产品售后信息鱼龙混杂,信息真假难以辨别。为了方便用户更好的获得本nuct产品售后信息,因此,设计一种安全高效的nuct产品售后管理系统极为重要。
为设计一个安全便捷,并且使用户更好获取本nuct产品售后信息,本文主要有安全、简洁为理念,实现用户快捷寻找产品售后信息,从而解决产品售后信息复杂难辨的问题。该系统以功能性需求,设计了nuct产品售后管理系统,该系统包括个人管理员,客户,受理人员,工程师和厂商五部分。第1章 概 述
通过对本文的开发背景、研究意义以及国内外研究现状和发展趋势的分析,确定本文的研究内容是系统开发的前提。
1.1 开发背景及研究意义
近年来互联网技术的发展使得互联网产品和网站层出不穷,对人才的需求不断提高 [1]。同时,面对过去使用手抄等方式进行记录,工作效率很难得到提高,无法满足现代人们的需求;自从人类进入互联网时代,通过纸质手抄的方式转换成线上无纸化管理,有效的解决了获取信息的渠道,全面提升工作效率。由此,实现一套完整的nuct产品售后管理系统非常必要。
设计和实现了一个基于nodejs的nuct产品售后管理系统。该系统具有良好的扩展性、稳定性、安全性以及可移植性等特点。为方便用户找到适合自己的nuct产品售后信息并进行交流,特制定本nuct产品售后管理系统。
1.2 国内外研究现状和发展趋势
在国内,由于历史环境因素的影响和发展的不平衡,nuct产品售后管理不完善,这对计算机领域的应用以及外部状态信息在nuct产品售后管理中的应用产生了很大的影响。简单的技术可以取代过去的形式或方法,但如果你想设计一个管理计划以更科学的方式重新管理这一环节,你必须放弃传统的管理方法,尽快改变管理方法,改变管理理念以合理运作,使系统更精细,控制成本,提高管理效率。
在国外,系统管理发展迅速。相应的信息系统软件设计和保护的研发也有所增加。随着时代的变化,产品研发得到了推动,系统软件得到了极大的发展。如今,它正朝着智能化、数字化和信息化的方向快速发展。所有大公司都采用了类似的规章制度,促进了公司的快速发展,取得了较好的经济效益。
计算机作为信息科学的媒介和关键,对人类社会的繁荣起着至关重要的作用。*机构和事业单位将根据工作内容选择一套优秀的通信技术和专业办公设备,并利用这些技术和设备快速收集、解决和存储信息,使管理变得方便快捷,实现科学合理的管理目标。
总而言之,nuct产品售后管理系统的发展呈持续上升发展趋势,现在传统式的手工制作和半手动式管理方法转变为信息化管理的转变历程中,必须使用和融合全新的信息技术性来完成传统的系统设计方法,确保系统的效果和品质。
但是这些nuct产品售后管理系统都是由传统企业开发建设而成的,在nuct产品售后信息发布上主要采用人工方式进行管理和维护,这种方法效率低下且容易出错,已经不能满足现在快速多变的社会需求,且大都缺乏有效的安全认证机制和管理机制,用户使用虚假信息注册,使得网站存在大量的虚假产品售后信息,无法保证nuct产品售后信息的安全性[2]。自1993年美国实施National Information Infrastructure以来,网络普及率大幅提高,互联网用户数量快速增长,nuct产品售后管理系统开始快速增长。
第3章 系统分析
系统分析是软件开发的关键。但在实际工作中却往往容易被人们忽视或误解。其实需求分析在软件开发过程中起着重要作用,它不仅为软件产品提供了一个基本框架和基础结构,而且还能够提高软件开发效率及质量。大多数软件的故障都是由于需求分析错误造成的,因为需求分析可以分析用户的业务,并根据用户的需求进行定制分析[10]。
3.1 系统概述
该系统由个人管理员客户,受理人员,工程师和厂商五部分组成。其中:客户,受理人员,工程师和厂商注册登录后台可以进行相应的操作;管理员则是根据不同需求设置了不同功能,可以通过后台管理接口管理用户信息。
3.2 需求分析
需求分析,也称为软件需求分析、系统需求分析或需求分析工程,是指开发人员经过充分的研究和分析,准确地理解用户和项目在功能、性能、可靠性等方面的具体需求,并将用户的非正式需求表述转化为确定系统必须执行的需求的完整定义的过程[11]。
功能需求分析是系统设计的前提,它要求开发者和用户定义开发什么样的体系和系统需要什么样的功能。本文主要介绍了一种基于windows平台实现的旅游景点管理系统。该系统为用户找到景点信息提供了更安全、更高效、更便捷的途径。本系统有五个角色:管理员,客户,受理人员,工程师和厂商,要求具备以下功能:
(1)管理员通过后台管理员界面,实现对个人中心、客户管理、受理人员管理、工程师管理、厂商管理、物料类型管理、物料信息管理、物料入库管理、物料出库管理、产品分类管理、产品信息管理、产品维护管理、故障机管理、受理故障机管理、沟通确认管理、受理流水单管理、电脑单管理、受理机分类管理、整理分类管理、分配工程师管理、工程师反馈管理、装箱返厂管理、邮寄返回机管理、受理返回机管理、电话沟通管理、返回机流水单管理、返回机电脑单管理、返回机整理分类管理、返回机装箱返厂管理、产品维修管理、返回机产品维修管理、装修返回管理、返回机装箱返回管理、通知客户管理、返回机邮寄客户管理、客户取回管理、客户收货管理等操作;
(2)客户登录系统实现对个人中心、故障机管理、受理故障机管理、沟通确认管理、受理流水单管理、电脑单管理、整理分类管理、分配工程师管理、工程师反馈管理、装箱返厂管理、邮寄返回机管理、受理返回机管理、电话沟通管理、返回机流水单管理、返回机电脑单管理、返回机整理分类管理、返回机装箱返厂管理、产品维修管理、返回机产品维修管理、装修返回管理、返回机装箱返回管理、通知客户管理、返回机邮寄客户管理、客户取回管理、客户收货管理等操作;
(3)受理人员登录系统实现对个人中心、故障机管理、受理故障机管理、沟通确认管理、受理流水单管理、电脑单管理、整理分类管理、分配工程师管理、工程师反馈管理、装箱返厂管理、邮寄返回机管理、受理返回机管理、电话沟通管理、返回机流水单管理、返回机电脑单管理、返回机整理分类管理、返回机装箱返厂管理、装修返回管理、返回机装箱返回管理、通知客户管理、返回机邮寄客户管理、客户取回管理、客户收货管理等操作;
(4)工程师登录系统实现对个人中心、分配工程师管理、工程师反馈管理等操作;
(5)厂商登录系统实现对个人中心、装箱返厂管理、返回机装箱返厂管理、产品维修管理、返回机产品维修管理、装修返回管理、返回机装箱返回管理等操作;
3.3 可行性分析
可行性分析是指通过比较项目的主要内容和支撑条件,如市场需求、资源供应、环境影响、资金筹措情况、盈利能力等,预测项目建成后可能产生的资金、经济效益、社会和环境影响,为项目决策提供依据的综合性系统分析方法。可行性研究报告编制的质量直接影响着投资决策的成,而可行性研究报告编制程序又决定了可行性研究报告能否得到有效执行。因此,必须重视可行性研究工作,提高其编制水平。可行性分析应当具有预见性、公正性、可靠性和科学性[13]。
第6章 系统测试
系统测试是检验软件产品是否满足预期需求,确保产品无缺陷的重要手段。系统测试侧重于评估系统是否满足指定的要求,并帮助检查整个系统的功能性需求。通过对系统功能和非功能两个方面的测试用例进行分析与比较可以发现软件存在的问题以及需要改进之处。软件可靠性设计是一项系统性工程,涉及到多个学科领域,因此其难度较大。测试将侧重于功能测试,这是黑盒测试的一部分,黑盒测试的重点是用户提供的要求,而不是系统的实际代码。
6.1 系统测试的目的
系统测试(System Testing)是为了向使用者提供有关被测试产品或服务的质量信息而进行的检查。系统测试还可以提供客观和独立的系统评估,以使运营者能够了解和系统实施所面临的潜在问题。系统测试涉及软件组件或系统组件的执行,以评估一个或多个系统属性。通常这些属性表明被测组件或系统满足系统预期开发需求,在各种预期的时间内,正确响应各种系统输入,在可接受的时间内执行其功能,足够可用,同时可以满足分析设计时要求的程度。在预期的环境中运行,并达到用户期望的总体结果。经过一系列严格功能测试,以发现系统功能方面潜在的问题,保证系统的正常运行。
6.2 系统功能测试
在系统的功能性测试中,开发人员需要按照操作要求使旅游景点管理系统软件的各项功能,并准确记录测试期间的每个功能的运行数据,判定软件系统开发的功能是否符合预期的结果,主要是对MySQL数据库里的数据进行增删改查,从而实现登录、门票预订、管理系统信息等功能。
6.2.1 登录注册功能测试
软件测试的第一步是旅游景点管理系统的用户注册登录功能模块进行测试,测试用户在初次进入软件系统时,是否可以使用注册后登录的功能,具体测试的步骤如表6-1所示。
表6-1 登录注册管理功能测试数据表
编号 测试的功能 步骤 预期结果 实际结果
1 用户注册 正确填写注册信息,然后点击注册按钮 可以完成用户注册 注册成功
2 用户登录 正确输入账号、密码,然后点击登录按钮 可以完成用户登录 用户登录成功
6.2.2 用户管理功能测试
系统的管理层可在此模块进行以下操作:对用户基础信息的修改;对用户的登录密码进行重置;删除用户;新增用户;根据关键词进行检索。以用户名:admin 密码:admin为例对该功能进行测试。测试操作如表5-2所示:
表5-2 用户管理测试过程及结果
测试项 测试用例 测试特性 用例描述 系统反应 测试结果
用户管理操作 用户名:admin
密码:123456 功能测试 添加一个新用户,基础信息与已有用户完全一致 添加失败,提示“该用户已存在” 通过
用户管理操作 用户名:admin
密码:999999 功能测试 添加一个新用户,基础信息与已存在用户均有所不同 添加成功 通过
用户管理操作 用户名:admin
密码:admin 功能测试 修改系统中用户名 修改成功 通过
用户管理操作 用户名:admin
密码:admin 功能测试 删除系统中用户 删除成功 通过
用户管理操作 用户名:admin
密码:admin 功能测试 按关键词搜索用户信息 查找成功 通过
用户管理操作 用户名:admin
密码:88888888 功能测试 重置用户密码 密码修改成功 通过
6.3 本章小结
本章所做的主要工作是对系统进行功能性测试。网站管理系统的正确性是网站的不可或缺的因素,系统的功能性测试是其中必不可少的步骤,也是占有很大比重的部分,这个过程中遇到的最多的问题是当界面跳转的时候系统终止运行。使用Eclipse中的Log Cat功能能够实现对程序每一个步骤进行跟踪,且定位出错误的位置十分方便。通过对各功能模块的测试结果和预期结果的比较,发现系统功能满足项目要求。
结 论
在设计nuct产品售后管理系统的过程中采用express架构技术,采用了nodejs技术来呈现给用户,后台数据采用MySQL数据库来进行存储。
在设计之初,我对系统逻辑功能的具体实现也很纠结,因为我对nuct产品售后管理的概念还比较模糊,期间我也在网上查询了大量的信息,清楚地了解了现实生活中nuct产品售后管理的主要对象和管理需要完成的基本功能。
而在这个过程中也遇到了很多困难,主要有系统逻辑功能的不恰当和系统设计上的错误,当在自己获取信息时无法解决,我会与同学和老师商量和讨论,所以在这个过程中,也让我知道认识到自己的不足和团队的力量是最大的,无论是在学习还是工作中,要融入集体,这样自己才会成长得更快。
当然,在本次设计中,由于时间的不足和本人能力的限制,功能还不完善,对于论文的不足之处,希望在今后的学习中不断改进,使本系统更接近实际操作。
下一篇: centos 7 安装 pgsql14
推荐阅读
-
纯干货分享 | 研发效能提升——敏捷需求篇-而敏捷需求是提升效能的方式中不可或缺的模块之一。 云智慧的敏捷教练——Iris Xu近期在公司做了一场分享,主题为「敏捷需求挖掘和组织方法,交付更高业务价值的产品」。Iris具有丰富的团队敏捷转型实施经验,完成了企业多个团队从传统模式到敏捷转型的落地和实施,积淀了很多的经验。 这次分享主要包含以下2个部分: 第一部分是用户影响地图 第二部分是事件驱动的业务分析Event driven business analysis(以下简称EDBA) 用户影响地图,是一种从业务目标到产品需求映射的需求挖掘和组织的方法。 在软件开发过程中可能会遇到一些问题,比如大家使用不同的业务语言、技术语言,造成角色间的沟通阻碍,还会导致一些问题,比如需求误解、需求传递错误等;这会直接导致产品的功能需求和要实现的业务目标不是映射关系。 但在交付期间,研发人员必须要将这些需求实现交付,他们实则并不清楚这些功能需求产生的原因是什么、要解决客户的哪些痛点。研发人员往往只是拿到了解决方案,需要把它实现,但没有和业务侧一起去思考解决方案是否正确,能否真正的帮助客户解决问题。而用户影响地图通常是能够连接业务目标和产品功能的一种手段。 我们在每次迭代里加入的假设,也就是功能需求。首先把它先实现,再逐步去验证我们每一个小目标是否已经实现,再看下一个目标要是什么。那影响地图就是在这个过程中帮我们不断地去梳理目标和功能之间的关系。 我们在软件开发中可能存在的一些问题 针对这些问题,我们如何避免?先简单介绍做敏捷转型的常规思路: 先做团队级的敏捷,首先把产品、开发、测试人员,还有一些更后端的人员比如交互运维的同学放在一起,组成一个特训团队做交付。这个团队要包含交付过程中所涉及的所有角色。 接着业务敏捷要打通整个业务环节和研发侧的一个交付。上图中可以看到在敏捷中需求是分层管理的,第一层是业务需求,在这个层级是以用户目标和业务目标作为输入进行规划,同时需要去考虑客户的诉求。业务人员通过获取到的业务需求,进一步的和团队一起将其分解为产品需求。所以业务需求其实是我们真正去发布和运营的单元,它可以被独立发布到我们的生产环境上。我们的产品需求其实就是产品的具体功能,它是我们集成和测试的对象,也就是我们最终去部署到系统上的一个基本单元。产品需求再到了我们的开发团队,映射到迭代计划会上要把它分解为相应的技术任务,包括我们平时所说的比如一些前端的开发、后端的开发、测试都是相应的技术任务。所以业务敏捷要达到的目标是需要去持续顺畅高质量的交付业务价值。 将这几个点串起来,形成金字塔结构。最上层我们会把业务目标放在整个金字塔的塔尖。这个业务目标是通过用户的目标以及北极星指标确立的。确认业务目标后再去梳理相应的业务流程,最后生产。另外产品需求包含了操作流程和业务规则,具需求交付时间、工程时间以及我们的一些质量标准的要求。 谈到用户影响的地图,在敏捷江湖上其实有一个传说,大家都有一个说法叫做敏捷需求的“任督二脉”。用户影响地图其实就是任脉,在黑客马拉松上用过的用户故事地图其实叫督脉。所以说用户影响地图是在用户故事地图之前,先帮我们去梳理出我们要做哪些东西。当我们真正识别出我们要实现的业务活动之后,用户故事地图才去梳理我们整个的业务工作流,以及每个工作流节点下所要包含的具体功能和用户故事。所以说用户影响地图需要解决的问题,我们包括以下这些: 首先是范围蔓延,我们在整张地图上,功能和对应的业务目标是要去有一个映射的。这就避免了一些在我们比如有很多干系人参与的会议上,那大家都有不同想法些立场,会提出很多需求(正确以及错误的需求)。这个时候我们会依据目标去看这些需求是否真的是会影响我们的目标。 这里提到的错误需求,比如是利益相关的人提出的、客户认为产品应该有的、某个产品经理需求分析师认为可以有的....但是这些功能在用户影响地图中匹配不到对应目标的话,就需要降低优先级或弃掉。另外,通常我们去制定解决方案的时候,会考虑较完美的实现,导致解决方案括很多的功能。这个时候关键目标至关重要,会帮助我们梳理筛选、确定优先级。 看一下用户影响到地图概貌 总共分为一个三层的结构: 第一层why,你的业务目标哪个是最重要的,为什么?涉及到的角色有哪些? 第二层how ,怎样产生影响?影响用户角色什么样的行为? (不需要去列出所有的影响,基于业务目标) 第三层what,最关键的是在梳理需求时不需一次把所有细节想全,这通常团队中经常遇到的问题。 我们用这个例子来看一下 这是一个客服中心的影响地图,业务目标是 3个月内不增加客服人数的前提下能支持1.5倍的用户数。此业务目标设定是符合 smart 原则的,specific非常的具体,miserable 是可以衡量的,action reoriented是面向活动的, real list 也是很实际的。 量化的目标会指引我们接下来的行动,梳理一个业务目标,尽量去量化,比如 :我们通过打造一条什么样的流水线,能够提高整个部署的效率,时间是原来的 1/2 。这样才是一个能量化的有意义的目标。 回到这幅图, how 层级识别出来的内容,客服角色:想要对它施加的影响,把客户引导到论坛上,帮助客户更容易的跟踪问题,更快速的去定位问题。初级用户:方论坛上找到问题。高级用户:在论坛上回答问题。通过我们这些用户角色,进行活动,完成在不增加客户客服人数的前提下支持更多的用户数量。 最后一个层级,才是我们日常接触比较多的真正的功能的特性和需求,比如引导到客户到论坛上,其实这个产品就需要有一个常见问题的论坛的链接。这个层次需要我们团队进一步地在交付,在每个迭代之前做进一步的梳理,细化成相应的用户故事。 这个是云智慧团队中,自己做的影响地图的范例,可以看下整个的层级结构。序号表示优先级。 那我们用户影响地图可以总结为:
-
基于 nodejs+vue 的 nuct 产品售后管理系统 python-flask-django-php
-
实时音频和视频技术的发展与应用-1.1 双重音频和视频 从架构上看,双人音视频系统相对简单明了。红点代表房间信令服务,房间信令服务的主要功能是管理房间信息,实现容量协商和上下行链路的质量调节,例如当下行信道发生拥塞时,上行线路的码率和分辨率会降低。 在传输信道层面,我们的策略是优先直连,在跨区域、跨运营商的情况下,我们会选择单中转或双中转信道,在策略上尽量保持直连和中转信道同时存在,当其中一个信道的质量不好时,系统会自动切断到另一个信道的流量。 1.2 多人音视频 多人视频通话的产品形态是整个房间不超过 50 人,大盘平均房间规模约为 4.x 人,房间内部最多满足一个大视频和三个小视频(四屏)。根据这一条件,我们在架构中采用了典型的 SFU 小房间设计。 上图中的红点代表房间信令服务,主要用于房间管理和状态信息同步。房间管理主要包括用户列表的管理,例如哪些用户打开了视频/音频,我看了谁,谁看了我,这些都是基于房间管理的信息,然后房间信令服务会将这些信息同步到媒体传输服务进行数据分发。 房间服务的另一个作用是房间级容量协商和质量控制,例如,房间里的每个人一开始都支持 H.265 编码,当某个时刻进来一个只支持 H.264 编码的用户时,房间里所有的上游主播就必须把 H.265 切成 H.264。还有一种情况是,房间里有一定比例的人下行链路信道质量较差,这会导致上行链路房间质量下降。 在传输层面,我们采用的是单层分布式媒体传输网络,大家都选择中转方式,不区分双人和多人,采用 Full-Mesh 传输机制将所有数据推送过去,比如一个节点上的人并不都看另外两个人的视频,但还是会将视频推送给他们。