zoukankan      html  css  js  c++  java
  • 结对项目之需求分析与原型设计

    结对项目之需求分析与原型设计

    结对者
     031402509胡泽善
     031402524王智强
     本次作业pdf文档

    使用工具:AxureRp 8.0
     在《构建之法》的第八章中,介绍了NABCD模型。
    NABCD模型(p154~p157):

    目的:在竞争性地环境中做实用并且创新的项目;
    具体的解释如下

    • N需求(need),解决用户的需求;
    • A,做法(approach),解决需求的手段;
    • B,好处(benefit),产品会给客户/用户带来什么好处;
    • C,竞争(competitors),市场竞争,看清优劣事态;
    • D,推广(delivery),如何把产品交到用户手中;

    结对设计过程

     按照本次作业的要求,我们两人来自不同的课设小组,我们的结对是比较主动和积极的,在本次作业发布的第三天,我们就互相联系,约定结对,在规定的时间内,共同合作,完成本次作业。
    下面是我们在结对原型设计中的照片记录:



     首先,我在此先用NABCD模型简要分析一下我们两人的设计过程:

    N
     在第二次作业的博客中,描述了目前毕业生选择导师系统给用户/客户带来的困扰,以及介绍了在当前选导师过程中人工分配遵循的五大规则(详细请见博客)。目前的 选择和分配本科毕设导师的流程复杂繁琐不透明,因此,用户希望我们设计出一种新的毕设选导师的原型系统,让选择和分配导师的过程能够信息化起来,让师生之间可以双向选择。


    A
     明白客户需求之后,我和我的“对友”便开始了分析和讨论如何解决问题、满足需求的方法:

    1. 首先在web端和app之间,我们选择了后者;
    2. 然后,我们参考以往使用过的多个类似的带选择性的软件或者网页,结合大二选专业导师的经历,总结并粗略模拟出整个选择和分配的过程;这其中主要就分为导师与同学的相互了解以及学生先选择导师,导师再挑选学生,最后无法匹配的人工确定。
    3. 确定整个软件的设计核心,然后完善这个软件(包括登入,学生主页,老师主页,后台管理等)接下来就是将这个过程通过原型设计工具AxureRp展示出来;
    4. 对模型做修改,不断完善。(完)








     特别地,我们采用的做法中有以下两个亮点

    设计亮点1:标签选择。
     针对博客中所述的,在现状中,每个老师对应期望的学生数不同,且学生不太了解老师的课题选择和研究方向的问题,我们在已有的学生绩点这一指标的基础上,又设置了第二个用于学生和老师之间互相了解、促进选择的指标,那就是标签。通过学生所选标签和导师研究领域的交集,算出学生与导师之间的匹配度,并在简介页面中以星级的形象形式显示,供双方参考!
    设计亮点2:互动增多。
     互动可以更好地增进彼此的了解程度,这一点我们在大二选专业导师的时候深有体会,出于这么目的,我们在软件中设计了问题调查(老师考察学生,帮助老师选择)、公共讨论区(某老师回答,所有学生可见),私信(学生老师互动)。这里面既满足了老师了解学生,学生了解老师又满足了双方互相私人交流的渠道。

    B
     改变了原先手动的人工分配模式,不仅实现了资源信息化,并且通过我们的设计,使得学生对于老师的课题选择和研究方向有了比较全面地了解,老师不仅可以查阅学生的个人简历,学习绩点,而且还能通过私信或者讨论区回复的新式,和学生之间有所交流;标签的设计使得选择过程变得不再盲目。


    C
     这个原型设计如果说存在竞争压力的话,那应该是来自不同对的同学,在同一个命题的情况下,不同对的同学之间以客户在评论中所表现出来的满意度作为竞争的指标,满意度最终以本次作业的考核成绩这一形式呈现。


    D
     就像博客中说的那样,如果客户接纳,该方案将作为我们结对项目的第三次作业。如果客户不接纳,下周我们的结对就将无法继续编码本次的内容,将完成老师命题的作业。如果能够完成,相比不人性化的传统选择导师方式,只要我们成功推荐给学校使用并让同学们和导师了解,很快就能收到欢迎。

    效能分析和PSP:
     在《构建之法》的第二章中,详细讲解了效能分析和psp,在此,我简单概括如下:

    效能分析(P29~P34):

    • 效能分析的对象是:程序;
    • 效能分析的目标是:降低程序复杂度。
    • vsts会提供方便的效能分析工具,使得设计者很快地找出程序的效能瓶颈,便于改 进程序,改进程序的流程为“效能测试,分析,改进,再效能测试”。
       此处由于我们的产品原型并没有实际的代码和成品,无法进行真正的效能分析。但是我们可以预测在我们的产品中最有可能出现瓶颈的是对学校的教师简介、学生简介的调取以及对软件操作的保存。因为学校的服务并不仅仅是供我们使用,从平时打开教务处个人详情的速度上看,数据的传输速率很有可能成为我们软件的瓶颈。对此我们可以考虑单独架设服务器。

    PSP(P34~P37,即个人软件开发流程):

    • 对象是:软件工程师
    • 目标是:记录工程师如何实现需求的效率。
    • Psp有很多种版本,在书中介绍了psp2.1版本的软件工程师的任务清单,psp包括计划,开发,报告三个部分。
       同样,我们的项目目前处于原型阶段,无法提供诸如开发、记录用时的具体信息,但是我们可以完成的是对于项目用时的估计。

    总结:

    项目部分 app 服务器
    1 登陆模块 数据库的搭建
    2 标签选择模块 用户信息录入(考虑到用户固定,无需注册)
    3 教师主页 讨论区服务
    4 学生主页 学生及老师初始简介的导入
    5 教师详情页 私信服务
    6 学生详情页 用户信息的记录及修改服务(包括标签等)
    7 管理模块 /
    8 私信模块 /
    预计时间 45d 30d
  • 相关阅读:
    CodeForces 55D Beautiful numbers(数位dp+数学)
    hdu 2089 不要62(数位dp入门)
    Git版本控制
    Git初始化-添加提交以及查看状态
    linux-高并发与负载均衡-lvs-3种模型推导
    Scrapy中选择器的用法
    Scrapy命令行详解
    Scrapy框架基本用法讲解
    MaxCompute教程
    Scrapy安装报错
  • 原文地址:https://www.cnblogs.com/iphone2s/p/5875792.html
Copyright © 2011-2022 走看看