精华内容
下载资源
问答
  • 原型开发方法 并不是所有系统在系统开发之初都能准确地说明。 基本思想: 在投入大量人力、物力之前,在限定时间内,用最经济方法构造一个系统原型,使用户早期看到未来系统概貌,在系统原型实际运行...

    原型开发方法
    并不是所有的系统在系统开发之初都能准确地说明。
    基本思想
    在投入大量的人力、物力之前,在限定的时间内,用最经济的方法构造一个系统原型,使用户早期看到未来系统的概貌,在系统原型的实际运行过程中与用户一起发现问题,提出修改意见,不断完善原型,使它逐步满足用户的需求。
    原型方法的模型
    虚线部分就是该方法的核心活动——构造原型,该活动是一个和用户密切讨论不断反复的过程,最终确定的原型准确表达了用户的需求。
    原型方法过程模型

    原型方法的优点
    一、增进了用户与开发人员之间的沟通,启迪和发掘用户的真实需求;
    二、用户在系统开发过程中起主导作用,随时提供现场的第一手资料,帮助开发者认识用户的真正需求。
    三、降低开发风险,更有效地辨认用户需求,减少了开发人员对用户需求的误解,避免了较大偏离情况的发生。
    四、帮助开发人员尽早验证系统架构、关键算法、人机交互等设计方案的有效性。
    原型方法的不足:
    一、原型方法不如瀑布方法成熟和便于管理控制。
    二、由于用户的大量参与,也会产生一些新的问题,如原型方法的评估是否完全合理。
    三、原型的开发者在修改过程中,容易偏离原型的目的,使用者在看到原型的功能逐渐完备后,以为原型可以联机使用了,而疏忽了原型对实际环境的适应性及系统的安全性、可靠性等要求,便直接将原型系统转换成最终产品。这种过早交付产品的结构,虽然缩短了系统的开发时间,但损坏了系统的质量,增加了维护代价。

    展开全文
  • 【关键字】软件工程、开发模式、快速开发、软件开发、原型模式 快速原型开发模式基本思想是在系统开发初期,在对用户需求初步了解基础之上,以快速的方法先构造一个可以工作系统原型。将这个原型提供给用户...

    【摘要】本文以作者的实践开发经验为主线,从理论和实际的角度探讨快速原型开发模式在实践开发中的应用,并从软件开发的各个角度、各个时期剖析快速开发模式的优缺点和应该注意的问题。

    【关键字】软件工程、开发模式、快速开发、软件开发、原型模式

        快速原型开发模式的基本思想是在系统开发的初期,在对用户需求初步了解的基础之上,以快速的方法先构造一个可以工作的系统原型。将这个原型提供给用户使用,听取他们的意见。然后修正原型,补充新的数据、数据结构和应用模型,形成新的原型。经过几次迭代以后,可以达到用户与开发者之间的完美沟通,消除各种误解,形成明确的系统定义以及用户界面要求。

    了解快速原型开发模式后,下面结合我开发过学分制收费管理系统项目经验来谈一下我是如何在实际开发过程中实施快速原型开发模式。

    【项目背景】

    随着国家教育事业的发展,很多高校纷纷引进学分制教学体制模式。我所在的学校为跟上时代的步伐,经市教委批准,从2008-2009学年试行学分制改革,2009-2010正式运行。以传统的教学模式相比学分制教学模式有很多明显的优势,学生的自由度也得到了很大的提高。然而一种新的教学模式要取代传统的教学模式,势必会存在很多麻烦和问题。其中学分制教学模式下的收费方式与传统的收费方式就存在很大的差异,任然沿用传统的收费方式已经无法满足学分制改革的要求,因此为推动学分制改革,制定一套符合学分制教学要求的收费管理系统势在必行。有幸这个项目由我们团队负责开发。

    然而事情远没有想象那么简单,学分制改革是学校的大事情,需要财务处、教务处、学工部等行政部门的支持和各二级学院的配合。学分制收费更是与各个部门、学院和学生兮兮相关。试分析可以发现:待制定的学分制收费管理系统必须做到把财务处的各项收费标准信息、教务处的学生选课信息和学工部的助学贷款、缓缴学费、参军等学生信息紧密的糅合起来,并计算出学生预缴费用。由于涉及到的部门比较多,各部门领导又并不具备专业的软件知识,提出的需求并不明确或则是根本无法系统化。如果采用瀑布模式或则是演变模式进行开发,显然会存在着很大的风险,介于此、经项目组研讨决定采用快速原型开发模式进行项目开发。

    【具体实施】

    ㈠      开发工具选择

     经项目研讨后我们决定选择.NET平台采用ASP.NET+AJAX+SQL SERVER2000技术进行开发。主要原因是.NET平台具有一下优势:

    ⑴、技术领先  

      .Net技术于2001年由微软公司推出,与Java构成当前最主流的开发平台,.Net对XML、Web Service、AJAX提供很好的支持,而且,提供了更为便捷的开发、调试、部署环境,同时,与微软的BizTalk、Office、SQL Server2000等系统可以无缝衔接。  

      ⑵、安全性  

      .Net是构建于操作系统之上的虚拟平台,提供了更为强健的安全系统。在系统当中,提供集成Windows验证、基于角色的权限管理机制、SSL传输加密、MD5数据加密等多种安全手段,以提高系统的安全性。  

     ⑶、稳定性  

      作为24*7运行的系统,除了提供良好的性能之外,系统的稳定性也非常重要,系统采用如下方法提高系统性能及稳定性:  

        ①Web服务器采用Windows 2003+IIS6    

        ②模板系统:更新不频繁的数据使用模板系统生成静态页面,减少数据库压力  

        ③站点缓冲:频繁更新的数据,使用缓冲以提高访问速度,减少数据库压力  

        ④系统日志:再好的设计都会有bug,系统日志记录程序运行过程中产生的异常,以方便调试系统,发现潜在的bug  

      ⑷、扩展性  

      采集4层结构,分为数据访问层、业务逻辑层、业务外观层、表现层,各层之间严格遵守"高内聚、低耦合"原则,使系统具备较好的扩展性。  

      数据访问层:完成基本的CRUD(Create/Read/Update/Delete)操作。  

      业务逻辑层:完成各种业务规则和逻辑的实现,调用数据访问层完成CRUD操作。  

      业务外观层:为表示层提供统一的访问接口,分离界面和具体的业务功能。  

      表示层:分为B/S和C/S两中表现形式(暂时只实现了B/S一种模式)。  

      多层分布式设计,当业务和访问量增大时,可以在中间层部署更多的应用服务器,前端部署更多的Web服务器,提高对客户端的响应,而所有的变化对客户端是透明的。

     ㈡ 项目组成员以及分工

    我们项目组由一个项目负责人、一个测试工程师、一个文档管理员、三个编码员(其中一个软件设计师和两个程序员)。具体分工如下表:

    成员
     任务
     输出文档
     
    项目负责人
     需求采集①、控制进度、协调用户关系
     学分制收费研究报告
     
    测试工程师
     集成测试、总体测试
     测试报告
     
    文档管理员
     编写用户手册、编写操作手册、软件服务制定
     用户手册、操作手册

    软件服务说明书
     
    编码员
     软件设计师:需求分析、数据库设计、软件架构、核心代码编写、配合集成测试和总体设计、任务划分、编码质量控制
     需求分析报告、系统设计书、详细设计、软件规范说明书
     
    其他两个编码员:单元代码的编码、单元测试
     
           

    很荣幸我担任的是软件设计师的职务,在此感谢项目组对我的信任。另外在项目研讨的时候,根据项目开发时间紧迫、需求不好把握、需不断的构造软件原型等特点,我们打破常规,将原本属于编码员完成的集成测试任务全部划分给了测试工程师,测试工程师也只需将每次测试结果当做一种需求的方式返回给我们,我们再根据返回的需求微调程序,微调后的程序就基本上能满足要求。但这样做有个很大的前提就是测试工程师要对需求相当成熟。

    ①项目负责人通过与各部门领导沟通和软件演示的方式来采集用户需求。                               

    ㈢工作流程以时间安排

            项目负责人通过与各部门领导的沟通和实际调查,初步确定了软件需求,并提交学分制收费研究报告,同时把软件的核心功能定位于“计算学生的预缴费用,并将这些数据提供给财务收费系统(以.XLS文件导入、导出)”。随后经各部门领导协商,定于4.20日正式提交软件,如果软件能满足要求则立即投入使用。时间很紧迫,为保证第二次原型开发具有充足的时间,经项目组讨论决定制定了以下的工作安排。

    项目名称:学分制收费管理系统       任务安排表

    任务代码 / 名称
     交付的文档
     人员
     计划
     
    开始
     结束
     工期(天)
     
    学分制收费管理系统
     
     
     2009.2.9
     2009.4.19
     69
     
     T1 确定初步需求
     学分制收费研究报告
     项目负责人
     2009.2.14
     2009.2.28
     14
     
     T2 项目研讨会
     
     项目组成员
     2009.2.28
     2009.3.1
     1
     
     T3系统设计
     需求分析、系统设计、详细设计、系统规范说明
     软件设计师
     2009.3.2
     2009.3.9
     7
     
     T4第一次原型构建
     
     编码员
     2009.2.9
     2009.2.16
     7
     
     T5集成测试
     测试报告
     测试工程师
     2009.3.16
     2009.3.17
     1
     
     T6程序微调
     
     编码员
     2009.3.17
     2009.3.18
     1
     
     T7软件演示
     需求分析报告
     项目负责人
     2009.4.18
     2009.4.19
     1
     
     T8项目研讨会
     
     项目组全体成员
     2009.3.19
     2009.3.20
     1
     
     T9需求调整
     
     软件设计师
     2009.3.20
     2009.3.21
     1
     
    T10第二次原型构建
     
     编码员
     2009.3.21
     2009.4.4
     14
     
    T11集成测试
     测试报告
     测试工程师
     2009.4.4
     2009.4.5
     1
     
     T12程序微调
     
     编码员
     2009.4.5
     2009.4.6
     1
     
     T13第二次演示
     需求分析报告
     项目负责人
     2009.4.6
     2009.4.7
     1
     
     T14项目研讨
     
     项目组全体成员
     2009.4.8
     2009.4.9
     1
     
     T15软件完善
     
     编码员
     2009.4.9
     2009.4.14
     5
     
     T16集成测试
     测试报告
     测试工程师
     2009.4.14
     2009.4.15
     1
     
     T17程序微调
     
     编码员
     2009.4.15
     2009.4.16
     1
     
     T18总体测试
     测试报告
     测试工程师
     2009.4.16
     2009.4.18
     2
     
     T19测试微调
     
     编码员
     2009.4.18
     2009.4.19
     1
     
     T20文档整理
     用户手册、操作手册、软件服务说明书
     文档员
     2009.3.22
     2009.4.12
     21
     
     T21软件提交
     
     项目负责人
     2009.4.19
     2009.4.20
     1
     

    在具体的实施的工程当中,我们依照任务安排表严格执行,经过两个多月的开发,学分制收费管理系统终于完成,并在第二次软件演示的时候得到了各部门领导的一致好评。

    【存在的不足】

    虽然开发的系统得到了各部门领导的好评,但在整个开发工程当中仍然存在很多不足。我总结了主要有以下几点:

    ①某些关键的细节⊕在最开始就被忽略,这导致了后期为弥补这个细节花费了大量的时间,同时影响了队员的信心。

    ②程序员经验不足,对需求的理解能力稍差,有时候开发出来的某些复杂的模块根本不能满足要求,这无形中增加了需求沟通和程序修改的时间。

    ③对捕捉程度不够清晰,有时候需求过大,需要的开发时间较长,很难在预定时间内完成,只得加班加点。但有时需求较少,需要的开发时间较少,预先安排的时间有空余。这种情况使得程序员作息正常的作息时间被打乱,虽然开发进度能被很好的把握,但其实开发效率并不高。

     ④第一次原型开发初期,由于时间比较紧,对编码质量没有进行很好的控制,这导致后期的开发当中常常出现一些莫名其妙的错误(比如某个模块运行时间过长)。

    ⊕数据表中的某一个字段不清楚到底该如何处理时将其忽略。

      【后期总结】

    虽然在开发的过程当中存在一些不足,但我仍然学到了很多东西,同时也第一次正真的体验了快速原型开发模式在实践当中的应用,这次的经验在我今后的工作当中也都将产生深远的影响。在项目结束时,关于快速原型开发模式在实践当中的应用,我总结以下几点值得参考性的意见。

    ①在选择项目组成员时,应该本着“少而精”的原则。

    ②在软件开发之前,必须提出核心需求,进而确定软件的核心功能。

    ③在软件开发之前,对开发需时进行认真评估,制定一张符合实际的任务安排表,保证队员正常作息时间。

    ④在软件开发的过程当中,应严格控制原型的构建次数(建议只构建三次),一般在第一次软件演示后就应该基本确定用户需求,第二次软件演示的时就应该基本满足用户需求,第三次软件演示后再通过一些细节方面的修改就可以交付。

    ⑤对于某些暂时模糊的关键性细节应予以认真记录和分析,影响力大、需及时解决的细节必须及时解决,暂时不忙解决的应将涉及到这个细节的所有功能模块放在下一次原型构造时才进行开发与解决。

    ⑥如果开发时间很紧迫,测试工程师应跟踪测试,确保测试与开发同步。

     

    本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/xxxluozhen/archive/2010/10/17/5946410.aspx

    展开全文
  • 移动应用原型创建过程中采用迭代式快速开发方法的重要性。可以从对手身上学到什么,如何从他们的失误中获益。如何为你的应用定义USP,如何通过故事板(Storyboarding)、用户场景和故事图(Story-mapping)为自己挑选出...
  • 若本文对你有帮助,请点赞、关注我哟!...其主要任务是使用原型工具,采用人机交互技术概念、原理、技术与方法,结合工程实际,通过敏捷软件开发的方法,完成小型系统的原型分析与设计,并撰写技术文档,达到使...

    若本文对你有帮助,请点赞、关注我哟!

    大四上学期的课设之一,报告评分不高,仅供参考。要抽人答辩的!但你要是提前离校了,请同学帮你交报告也行。

          《工程技能培训》是软件工程专业的一门实践课,综合运用软件工程、软件需求工程、软件项目管理等有关课程内容,分析和解决实际软件项目开发中需求变更频繁、开发效率低、质量差、交流沟通成本高、效率低等问题。其主要任务是使用原型工具,采用人机交互技术的概念、原理、技术与方法,结合工程实际,通过敏捷软件开发的方法,完成小型系统的原型分析与设计,并撰写技术文档,达到使学生具备综合运用所学的工程技能完成实际项目开发的能力,同时培养学生的合作交流能力。

    设计报告要求(只上一周,考研初试后立马要求交,所以千万不要拖)

    1. 每个团队撰写一份设计报告;
    2. 要求项目“完成的”定义列表、Product Blog列表、Spring Blog列表、用户故事描述、每日立会记录和照片、用户故事的测试描述、燃尽图、系统界面原型、反思改进总结、个人工作汇总(问题清单、任务清单等)【只有按照要求做才能拿较好的分数!】
    3. 每个组员要有不少于200字的个人心得体会

    工程实训的要求

    团队整体要求:

    (1)建立一个3-5人团队,表明担任角色名称,轮换角色,至少担任过2个以上角色。

    (2)录制一段5分钟以内的工作视频文件。

    (3)建立QQ群。

    (4)每天发一张团队开会的照片,照片上标记好成员名字、时间、地点

     

    团队各个角色工作要求:

            产品经理(PO)1人

    (1)制作Product Backlog产品列表,Sprint计划会议内容

    (2)编写用户故事

    (3)使用axure pro绘制界面原型

    (4)项目“完成的”定义列表-DOD最小完成标准

    (5)形成个人实训报告

            敏捷教练SCRUM Master(SM)1人

    (1)怎么解决团队中遇到的问题,非技术的问题,给出解决方法

    (2)如何做好一名敏捷教练,需要的知识、心得体会

    (3)记录每天的指导日志

    (4)编写Scrum指导手册

    (5)形成个人工程实训报告

            开发人员 2人

    (1)每日的站会会议记录,每个人都讲了什么,形成文档;

    (2)使用系统填写每日的工作进展情况,并形成文档;www.leangoo.com

    (3)开发系统,并形成文档,演示系统;

    (4)反思改进会需要改进的问题,并形成文档;

    (5)绘制燃尽图

    (6)形成个人工程实训报告

            测试人员1人

    (1)编写测试案例;

    (2)发现的系统中的缺陷,记录系统缺陷;

    (3)编写系统测试报告;

    (4)形成个人工程实训报告

     

    培训资料:

    (1)京麦团队演示(SCRUM)http://v.youku.com/v_show/id_XOTI2MjA1OTE2.html

    (2)SCRUM视频资料(B站)https://www.bilibili.com/video/BV1Ma4y1e7y9?from=search&seid=16086043415600669724

    (3)AXURE9学习资料(B站)https://www.bilibili.com/video/BV18t411p7ex?from=search&seid=2873936838467609725

    一、项目综合描述

    1、产品的描述

            本次介绍的是医院CRM客户关系管理系统。

            本产品由医院对会员的管理随着会员数量的增加对会员的管理越加困难而发起的,我们希望将本院的慢性病会员通过信息化手段管理起来,能够做到对会员信息的维护,包括个人信息、来访信息、积分信息、问卷信息、画像信息;能够针对院方开展的活动,系统能够提醒会员管理员进行通知跟踪和记录。

            能够针对个性化的营销方案进行人员筛选,系统能够生成待办通知,提醒营销人员通知患者参与活动。

            经分析,系统承载内容如下:用户能够手工维护会员信息建立健康档案、来访信息、问卷信息,用户能够为会员设置标签进行画像,用户能够创建活动和提醒时间,系统能够展示维护的信息,系统能够生成待办提醒和待办任务。

            本产品为此系列产品的第一代产品,是一个新型的可持续迭代的产品。

    2、用户故事描述

    作为院长:

            我是这家医院的院长,随着我们医院引进的人才越来越多,技术水平不断增加,社会慢性病的爆发,导致来医院看病的慢性病会员数量越来越多,通过普通的书本记录已经很难满足如此庞大的需求,所以我们想要通过信息化的手段管理起来,我们希望系统能够做到对会员信息的维护,包括个人信息、来访信息、积分信息、问卷信息、画像信息等等;同时希望系统能够针对我们院方开展的一些活动,系统能够提醒会员管理员进行通知跟踪和记录。以及能够针对个性化的营销方案进行人员筛选,系统能够生成待办通知,提醒营销人员通知患者参与活动。

            同时,我们也希望更加的对客户进行关怀,所以希望在活动管理中可以分类出待开展活动,进行中活动和已结束的活动。同时,大多数慢性病的患者一般比较年纪大,所以我们希望系统的界面能够简洁美观,让年纪稍微大一些的老人的能看懂我们的系统。 

    3、产品的功能

    一级菜单(模块)

    二级菜单(功能)

    子菜单(功能点)

    患者管理

    基础信息管理

     

    会员管理

     

    来访管理

     

    积分管理

     

    问卷管理

     

    画像管理

    标签管理

     

    画像功能

     

    行为分析

     

    统计展示

     

    客户关怀

    活动管理

    待开展活动、进行中活动、已结束活动

    模板管理

     

    待办任务管理

    待办活动通知、待办问卷、待办事务

    系统管理

    角色管理

     

    权限管理

     

    用户管理

     

    会员组管理

     

    字典值管理

     

    积分兑换规则管理

     

    4、角色类和特征

    序号

    角色名称

    说明

    1

    普通用户

    1.具备本系统大部分查看权限

     2

     

    患者管理员

    1.具备患者信息维护权限
    2.具备本系统大部分查看权限

    3

    会员管理员

    1.具备对未成为会员的患者加入会员功能;
    2.具备对已成为本组会员的患者信息进行维护;
    3.具备对本组会员的会员信息、来访信息、问卷信息、客户关怀活动信息进行查看和维护;
    4.具备能够查看本组会员积分信息;
    5.行为分析和统计功能的权限不受本组影响,查看的是全部;
    6.此角色未系统主要使用角色,并且本角色的维护权限都是本组会员

    4

    会员管理主管

    1.具备审核本部门下人员创建的活动权限
    2.具备本系统大部分查看权限
    3.具备本系统会员信息、来访信息、问卷信息、客户关怀活动信息的查看权限

    5

    营销人员

    1.具备行为分析选择方案权限
    2.具备活动方案制定权限
    3.具备本系统大部分查看权限

    6

    营销主管

    1.具备审核本部门下人员创建的活动权限
    2.具备本系统大部分查看权限
    3.具备本系统会员信息、来访信息、问卷信息、客户关怀活动信息的查看权限

    7

    院长

    1.具备全部查询和详情权限,即拥有所有菜单,但无处理操作,只能查询和查看详情

    8

    系统管理员

    1.具备最高权限

    5、功能优先级

    二、运行环境和设备要求

    1、运行环境

           系统可应用于Windows平台或Unix平台,

           系统采用B/S架构,可通过浏览器使用

           运行于局域网环境中,

           系统采用Java SDK版本为6.0,

           系统数据库使用Oracle10g

    2、设备

           数据库服务器2台+存储1台 集群或者热备模式

           PACS数据库服务器2台+存储1台 集群或者热备模式

           LIS独立部署,以便应及时业务不受影响

           应用服务器实现物理三层独立部署

    服务器类型

    CPU

    内存

    存储量

    品牌参考

    HIS数据库服务器

    >2颗INTEL

    XEON E7440处理器,4核,2.4GHZ,16MB高速缓存

    >8G,可扩展至64G

    >1TB

    参考IBM3850 M2系列机器配置

    PACS数据库服务器

    >2颗INTEL

    XEON E5530处理器,4核,2.4GH在,

    8MB高速缓存

    >4G,可扩展至64G

    >2TB

    参考IBM3650 M2系列机器配置

    软件应用服务器

    >2颗INTEL

    XEON E5530处理器,4核,2.4GH在,

    8MB高速缓存

    >4G,可扩展至64G

    >500G

    参考IBM3650 M2系列机器配置

    核心交换机

    千兆以太网交换机

    汇集层交换机

    千兆汇集层交换机

    接入层交换机

    1000M,1000M自适应接入交换机

    其他的硬件可根据实际情况做选型

    三、Product Blog 列表

            产品需求清单(Product Backlog)是Scrum的核心,也是一切的起源。从根本上说,他就是一个需求、故事、或特性等组成的列表,按照重要性的级别进行了排序。他里面包含的是客户想要的东西,并用客户的术语加以描述。产品负责人(Product Owner)负责产品需求清单(Product Backlog)列表的内容、可用性和优先级。

            包括内容:

            (1)功能方面的需求,功能点。

            (2)非功能方面的需求,如性能改进等。

            (3)需要修改的bug,上一版本已知的问题。

            (4)新技术,如支持新的操作系统或平台。

            (5)问题,日后可能新增的项,新功能。

            产品需求清单是不断完善的。在项目进行中随时新增、修改、删除功能,变更优先级。

            医院CRM客户关系管理系统产品需求清单如表3-1所示

                                                                                   表3-1 Product Backlog

    医院crm系统Product Backlog

    ID

    Name

    Imp

    Est

    How to demo

    Notes

    1

    基础信息管理

    190

    8

    登录,进入基础信息界面,查看和修改患者信息信息

    需要位数限制和实名认证

    2

    会员管理

    160

    6

    登录,进入会员界面,查看和修改会员用户

     

    3

    来访管理

    150

    5

    登录,进入来访界面,查看和修改患者来访信息

     

    4

    积分管理

    130

    6

    登录,,进入积分界面,查看和修改会员积分信息

     

    5

    问卷管理

    30

    3

    登录,进入问卷界面,查看和修改调查问卷

     

    6

    标签管理

    40

    3

    登录,进入标签界面,系统分类用户

     

    7

    画像功能

    110

    10

    系统存储会员照片

     

    8

    行为分析

    180

    15

    系统根据会员行为进行智能分析

    需要UML顺序图

    9

    统计展示

    100

    10

    系统将会员数据统计和展示

    使用分页技术,避免大规模数据库查询和查看用户列表设计相似。

    10

    活动管理

    140

    8

    登录,进入活动界面,查看和修改活动信息

     

    11

    模板管理

    20

    6

    登录,进入模板管理界面,查看和修改系统板块分布

     

    12

    待办任务管理

    10

    4

    登录,进入任务界面,查看任务信息

     

    13

    角色管理

    60

    5

    管理员登录,进入角色界面,管理角色

    需管理员登录

    14

    权限管理

    120

    5

    管理员登录,进入权限界面,赋予或撤销账号权限

    需管理员登录

    15

    用户管理

    200

    6

    管理员登录,进入用户管理界面,增加或删除用户

    需管理员登录

    16

    会员组管理

    90

    5

    管理员登录,进入会员组界面

    需管理员登录

    17

    字典值管理

    70

    5

    管理员登录,进入字典值界面,修改字典值

    需管理员登录

    18

    积分兑换规则管理

    50

    7

    管理员登录,进入积分页面,修改积分兑换

    需管理员登录

    四、Spring Blog列表

            Sprint Backlog 主要是从产品任务清单(Product Backlog)中挑选出高优先级的任务,确定本次迭代的任务目标。

            能提取多少产品任务清单中的任务取决于Scrum团队能承诺完成多少。

            (1)承诺总是来自于内部,不能从外部加强。

            (2) 迭代不应当有空闲时间,因此规划的迭代内容要保证工作量是稳定的)

            (3)依赖的因素较多:团队的能力,技术的成熟度,当前迭代增量的情况。

            产品所有者(Product Owner)定义每个迭代的任务说明、目标。使迭代更具有针对性。

            医院CRM客户关系管理系统冲刺任务清单如表4-1所示

                                                                                   表4-1 Sprint Backlog

    Sprint 1 Backlog                          Goal: deliver working version of web page

    ID

    Name

    Imp 

    Est

    description of the task

    Owner

    Status

    1

    基础信息管理

    190

    8

    登录,进入基础信息界面,查看和修改患者信息信息

    李**

    Done

    2

    会员管理

     

    160

    6

    登录,进入会员界面,查看和修改会员用户

    刘**

    In progress

    3

    来访管理

    150

    5

    登录,进入来访界面,查看和修改患者来访信息

    李**

    In progress

    4

    积分管理

    130

    6

    登录,,进入积分界面,查看和修改会员积分信息

    王**

    No strated

    7

    画像功能

    110

    10

    系统存储会员照片

    刘**

    In progress

    8

    行为分析

    180

    15

    系统根据会员行为进行智能分析

    李**

    In progress

    9

    统计展示

    100

    10

    系统将会员数据统计和展示

    李**

    Done

    10

    活动管理

    140

    8

    登录,进入基活动界面,查看和修改活动信息

    张**

    Done

    14

    权限管理

    120

    5

    管理员登录,进入权限界面,赋予或撤销账号权限

    王**

    Done

    15

    用户管理

    200

    6

    管理员登录,进入用户管理界面,增加或删除用户

    张**

    In progress

    五、用例图

                                                                                   图5-1 系统用例图

                                                                                   图5-2 患者管理模块用例图

                                                                                   图5-3 画像管理模块用例图

                                                                                   图5-4 客户关怀模块用例图

    六、燃尽图

            Sprint Burndown Chart 显示了 Sprint 中积累剩余的工作量,他是一个反应工作量完成状况的趋势图。Y轴代表的是剩余工作量,X轴代表的是Sprint的工作日。

            在Sprint开始的时候Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成,但没有完成的任务的工作量是累积工作量,团队会根据进展情况每天更新累积工作量,如果在Sprint结束时,累积工作量降低到0,Sprint就成功结束。

            医院CRM客户关系管理系统燃尽图如图6-1所示

                                                                                   图6-1 医院CRM燃尽图

    七、系统界面原型及介绍

    1、系统主界面

     

                                                                                   图7-1 登录界面

                                                                                   图7-2 系统主界面

    2、患者管理模块界面

    说明

            此模块将患者管理起来,包括对患者基本信息的维护,对来访信息的维护,对会员档案的维护,对积分信息的维护。

            (1)基础信息管理:有权限的用户可对患者的基础信息进行维护,包括新建患者、修改患者信息、查看患者信息、删除患者、批量导入患者信息、选择患者成为会员操作。

            (2)会员管理:有权限的用户,在权限范围内修改会员信息、锁定会员、查询会员信息。

            (3)来访管理:有权限的用户,在权限范围内对来访信息进行增删改查操作

                                       二期:新增的时候要关联活动。同步HIS系统后,将不必自行录入。

            (4)积分管理:积分管理分为,活动积分和消费积分。消费积分为实际消费金额是多少,积多少分;活动积分,按活动设置进行增减积分。

                                       有权限用户可查看积分情况。本积分管理只查看,不操作。

            (5)问卷管理:对会员进行定期跟踪问卷,记录问卷结果,制定好下次计划时间后,到待办任务列表中提醒。

                                                                                   图7-3 患者模块界面

    3、画像管理模块界面

    说明

            此模块是对患者的画像进行管理。可自定义标签类别、标签项内容、可对患者进行批量或单一修改画像内容。包含患者行为分析和统计展示。

            (1)标签管理:有权限的用户可对标签进行添加、修改、删除和修改标签项操作。

            (2)画像功能:有权限的用户可患者批量或单一画像。

            (3)行为分析:有权限的用户可选择患者基础信息和画像信息,根据选择结果筛选出的患者选择营销类活动方案。

            活动分为:会员关怀型和营销型两种。会员关怀型:人员按组区分,补充人员自动添加;营销型:人员一旦定义不可更改。

            (4)统计展示:目前展示了3种图形。

            分别为:

            近一周每组会员消费信息分析

            近半年会员患者及销售情况分析

            会员患者人员占比

                                                                                   图7-4 画像管理模块界面

    4、客户关怀模块界面

    说明

           此模块为此系统的核心模块,主要目标是将医院的活动管理起来,包括活动的管理和活动模板的管理,并做到根据活动信息的填写自动生成待办任务。

           活动分为三个步骤:通知、执行(线下)、记录。

           (1)活动管理

    1.待开展活动:有权限的用户,在权限范围内进行新建活动,保存模板,调用模板,审核活动,注销活动,修改活动,查询操作。

    2.进行中活动:有权限用户可查看权限范围内的活动列表,活动 详情,对活动执行结果可记录。

           3.已结束活动:可查看已结束的全部活动。

           (2)模板管理:有权限的用户,在权限范围内新增模板、删除模板、修改模板、查看模板操作。

           (3)代办任务

           1.代办活动通知:活动的通知提醒都在此功能列表中以活动粒度展示,操作人可对待办通知进行线下通知并在线上记录通知结果。

           2.代办问卷:显示当前用户相关的待办问卷的快速入口,展示近1个月一天内需处理的待办问卷,当前用户点击本模块【处理】按钮可直接进入处理界面。

           3.代办事务:显示当前用户相关的待办事务的快速入口,当前用户点击本模块【处理】按钮可直接进入处理界面。

                                                                                   图7-5 客户关怀模块界面

    5、系统管理模块界面

                                                                                   图7-6 系统管理界面

    八、总结

            对于敏捷开发最优先的目标就是通过尽早地持续地交付有价值的软件来满足客户它要求一个团队能够有足够的毅力来共同协作并在开发过程中能够保持沟通使整个项目中业务人员和开发人员必须每天在一起工作在开发团队中传递信息最有效的方法是面对面的交流不仅如此它还要求团队持续关注技术上的精益求精和良好的设计从而增强敏捷性团队需要定期地对运作如何更加有效进行反思并相应地进行调整校正自己的行为只有这样我们的开发过程和团队合作才会更有效率从而更好地完成工作

    展开全文
  • 设计方法原型法、敏捷开发

    千次阅读 2017-03-13 15:18:58
    原型法和敏捷开发 原型法 定义:又称快速原型法,不属于敏捷开发。...2. 进化型原型 - 此类原型的构造从目标系统一个或多个基本需求出发,通过修改和追加的过程逐渐丰富,演化成为最终系统。

    原型法和敏捷开发


    [快速]原型法

    就是按照客户写的demo。


    分类
    1. 抛弃型原型 - demo的需求客户确认后就抛弃。

          a)探索性 - 为了确认需求;

          b)实验型 - 为了确认规格说明是否可靠。

    2. 进化型原型 - 先构造一个功能简单而且质量bugatti的模型作为核心,然后不断扩充修改,最后发展为最终系统。


    优点:

    1. 由于有用户的直接参与,系统更加贴近实际;

    2. 系统开发循序渐进,反复修改,确保较好的用户满意度;

    3. 开发周期短,费用相对少;


    缺点:

    1. 不适合大规模系统的开发;

    2. 开发过程管理要求高,整个开发过程要经过“修改—评价—再修改”的多次反复;

    3. 用户过早看到系统原型,误认为系统就是这个模样,易使用户失去信心;

    4. 开发人员易将原型取代系统分析;

    5. 缺乏规范化的文档资料


    适用范围:

    1. 用户需求不清,需求经常变化
    2. 规模小,不太复杂
    3. 用户界面

    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发的核心思想

    •以人为本
         敏捷方法认为,人是软件开发中最重要的因素。敏捷开发的理念是充分的信任开发团队能够很好的完成任务,这是管理的中心主题。

    •适应变化
         传统的软件开发强调的是,足够清晰的需求,制定详细的文档,按照预定的计划逐一进行开发、测试。这样的方式在制定好计划之后拒绝变化,无法应对客户对需求的实时更改,后续的维护必将会付出巨大的代价。
         而敏捷方法则是以最简的方式来迎接变化,客户在整个开发过程中都是参与者,开发团队能够在最短的时间内得到客户的反馈,不断适应需求的变更,从而使得最终的产品能够充分的符合客户的要求。

    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发 - XP极限编程

    极限编程(eXtreme Programming)。

    “Extreme”(极限)是指,对比传统的项目开发方式,XP强调把它列出的每个方法和思想做到极限、做到最好;其它XP所不提倡的,则一概忽略(如开发前期的整体设计等)。极限编程强调程序设计团队与业务专家之间的紧密协作、面对面的沟通(比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好的适应需求变化的代码编写和团队组织方法,更注重软件开发中人的作用。


    核心价值观
    •沟通(Communication)
         开发人员和设计人员、设计人员和客户的沟通。
    •简单(Simplicity)
         开发前期的整体设计、兼容等直接忽略,专注于最小化解决方案。
    •反馈(Feedback)
         尽快获得用户的反馈。
    •勇气(Courage)
         拥抱变化。


    12个实践原则
    规划策略
         以业务优先级和技术估计为基础,决定下一版本发布的范围。
    结对编程
         结对者是全职合作者,轮流执行键入和监视;这提供了持续的设计和代码评审。
    测试先行
         在编码开始之前,首先将测试写好,而后再进行编码,直至所有的测试都得以通过。
    重构
         改进软件的设计,重构帮助重新组织代码,重新清晰地体现结构和进一步改进设计。
    简单设计
         系统应设计得尽可能简单。
    代码集体所有权
         代码集体所有权强调的是整个团队,而非个人。
    持续集成
       持续集成的思想是任何时候只有一项任务完成,就集成新代码,构造系统并测试。
    现场客户
         客户是Team成员,在开发现场和开发人员一起工作。
    小型发布
         可以保证频繁地反馈和交流,保证客户有足够的依据调控开发过程,降低开发风险。 
    每周40小时工作制
        XP要求项目团队人员每周工作时间不能超过40小时,否则反而会影响生产率。
    编码规范
         编码规范代替不必要的文档。类型包括:格式、代码结构、命名约定、错误处理、注释。 
    系统隐喻
         系统隐喻是将整个系统联系起来的全局视图,每个迭代的隐喻都会演化扩展。


    适用范围
    XP适合规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题,以最大的灵活性和最小的 代价来满足用户未来的需求,XP在平衡短期和长期利益之间做了巧妙的选择。

    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发 - FDD特征驱动开发

    8个实践原则
    · 领域对象建模
    构造类图。系统设计提供了一种整体框架,把对象分解为类,使得系统可以按照特征迭代增量地进行开发。
    · 按照特征开发
    用户眼中最小的、有用的功能进行开发并跟踪过程。 
    · 类(代码)拥有权
    每一个类都有一个指定的人/角色负责类代码的一致性、性能和概念的完整性。
    · 特征小组
    特征分配给一个确定的开发者,一个特征的实现会涉及到多个类及其所有者,因此,特征的所有者(特征组长)需要协调多个开发人员的工作。特征小组与开发小组类似。但有一个重要的区别:特征小组的组长更像是教练而不是超级程序员。
    · 审查
    检查软件错误的复审方法,这是FDD确保软件设计和代码质量的一个关键技术。
    · 定期构建
    定期地取出已完成功能的代码,组成完整的可以运行的系统。可以使客户观察到系统开发的进度和实现的功能是否是需要的。
    · 配置管理
    最新版本的确认和历史追踪。
    · 可视性进度报告
    项目成员应该根据完成的工作向各级管理报告工作进度。

    XP极限模式和FDD驱动模式的区别

    · 隐寓和模型
    XP是隐喻,即每个人(设计人员,开发人员、客户)都能讲出系统如何工作的。
    FDD是模型,一个全面的领域对象模型,以便特征小组对每一组特征产生更好的设计。
    · 开发团队
    XP通常不超过10人;FDD的理想团队成员数在16~20人。
    · 代码拥有权
    XP任何人都拥有代码,任何人都可以在需要时添加或修改代码。
    FDD整个开发团队拥有代码,类所有者与特征小组修改。
    · 审查
    XP利用双人结对编程来不断地在设计和代码层执行走查和非形式化审查。
    FDD则提倡采用结构化的形式化审查技术。
    · 测试
    XP中的正确性是由运行单元和功能测试来定义的。
    FDD中单元测试是“按照功能构建”过程的一个部分,由主程序员决定做什么更适合。
    · 项目追踪
    XP让项目经理决定项目追踪方法,鼓励减少数据搜集的工作量,鼓励使用大型图表。
    FDD中的按特征追踪项目的方法,描述了工作量小、准确度量项目进度的手段,提供进度图表。

    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发 - Crystal水晶方法

    透明水晶方法,适合于一个小团队来进行敏捷开发,人数在6人以下为宜。


    七大体系特征
    · 经常交付
      项目主办者根据团队的工作进展获得重要反馈;用户有机会发现他们原来的需求是否是他们真正想要的,也有机会将观察结果反馈到开发当中。
    · 反思改进
      如果我们能够经常在迭代会中及时的反思和改进,技术难题应该是不会发生的,或者说发生了,也能够很快的找到解决方案去应对它。
    · 渗透式交流
      若其中一名成员提出问题,工作室内的其他成员可以选择关注或不关注的态度,可以加入到这个问题的讨论当中来,也可以继续忙自己的工作。
    · 个人安全
      个人安全指的是当您指出困扰您的问题时,您不用担心受到报复。个人安全非常重要,有了它,团队可以发现和改正自身的缺点。没有它,团队成员们知而不言,缺点则愈发严重以致于损害整个团队。个人安全是迈向信任的第一步。有了信任,团队协作才能真正的实施,开发效率也就会直线上升的。
    · 焦点
      所谓“焦点”,就是确定首先要做什么,然后安排时间,以平和的心态开展工作。
    · 与专家用户建立方便的联系
      与专家用户持续建立方便的联系能够给团队提供:对经常交付进行配置以及测试的地方,关于成品质量的快速反馈,关于设计理念的快速反馈,最新的(用户)需求。
    · 配有自动测试(auto-test)、配置管理(git)和经常集成功能的技术环境(git)
      自动测试:代码修改后自动测试,并反馈结果。提高效率。
      配置管理:提交的代码可选择某个节点发布和还原。
      经常集成:开发人员可以一天多次合入本地版本到服务器版本,加快发现错误。

    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发 - RUP统一软件开发过程

    RUP(Rational Unified Process),统一软件开发过程,统一软件过程)是一个面向对象且基于网络的程序开发方法论。根据Rational的说法,RUP就好像一个在线的指导者,他可以为所有方面和层次的程序开发提供指导方针、模板以及事例支持。


    六个特点
    · 迭代式开发
    迭代式开发允许在每次迭代过程中需求可能有变化,通过不断细化来加深对问题的理解。
    · 管理需求
    确定系统的需求是一个连续的过程,开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化,用例和脚本的使用以证明是捕获功能性需求的有效方法。
    · 基于组件的体系结构
    组件使重用性成为可能,系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性,提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。
    · 可视化建模
    RUP往往和UML联系在一起,对软件系统建立可视化模型,帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化地对软件系统建模,获取有关体系结构和组件的结构和行为信息。
    · 验证软件质量
    在RUP中软件质量评估是内建于过程中的所有活动,这样可以及早发现软件中的缺陷。
    · 控制软件变更
    RUP通过软件开发过程中的制造出的产品,隔离来自其他工作空间的变更,以此为每个开发人员建立安全的工作空间。迭代式开发中如果没有严格的控制和协调,整个软件开发过程很快就陷入混乱之中,RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。


    、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

    敏捷开发 - SCRUM迭代式增量软件开发过程

    Scrum是一种灵活的软件管理过程,它可以帮助驾驭迭代、递增的软件开发过程,主要用于产品开发或工作管理。


    Sprint(迭代)
        Scrum的项目过程由一系列的Sprint组成
        Sprint的长度一般控制在2~4周
        通过固定的周期保持良好的节奏
        产品的设计、开发、测试都在Sprint期间完成
        Sprint结束时交付可以工作的软件
        在Sprint过程中不允许发生变更


    敏捷方法之极限编程(XP)和 Scrum区别
    区别之一: 迭代长度的不同
    XP的一个Sprint的迭代长度大致为1~2周;
    Scrum的迭代长度一般为 2~ 4周。
    区别之二: 在迭代中, 是否允许修改需求
    XP在一个迭代中,如果一个User Story(用户素材, 也就是一个需求)还没有实现, 则可以考虑用另外的需求将其替换, 替换的原则是需求实现的时间量是相等的。
    Scrum是不允许这样做的,一旦迭代开工会完毕, 任何需求都不允许添加进来,并有Scrum Master严格把关,不允许开发团队受到干扰。
    区别之三: 在迭代中,User Story是否严格按照优先级别来实现
    XP是务必要遵守优先级别的。
    但Scrum在这点做得很灵活,可以不按照优先级别来做。Scrum这样处理的理由是:(1)如果优先问题的解决者,由于其它事情耽搁,那么整个进度就耽误了。(2)如果按优先级排序的User Story #6和#10,虽然#6优先级高,但是如果#6的实现要依赖于#10,则不得不优先做#10。
    区别之四:软件的实施过程中,是否采用严格的工程方法,保证进度或者质量
    Scrum没有对软件的整个实施过程开出工程实践的处方,要求开发者自觉保证。
    XP对整个流程方法定义非常严格,规定需要采用TDD、自动测试、结对编程、简单设计、重构等约束团队的行为。


    参考链接:

    原型法

    敏捷开发



    展开全文
  • 文章目录瀑布模型/改进瀑布模型螺旋模型增量和迭代模型原型法快速和敏捷开发关于选择生命周期模型最后总结 瀑布模型/改进瀑布模型 虽然瀑布模型仍然存在很多问题有待解决,但瀑布模型仍然是最基本和最效...
  • 瀑布模型:设计在开发阶段 瀑布模型有以下优点 ...1)为项目提供了按阶段划分检查点。...2)当前一阶段完成后,您只需要去关注后续...4)它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可...
  • 上一篇原型方法只是一种需求验证手段,如果将其思想运用到整个开发过程,使得每个阶段任务经过反复多次,或者将分析、设计、实施周期反复多次,通过一次次迭代,不断在原来基础上完善和修正,越来越靠近目标...
  • 建造者模式定义又叫生成器模式,它可以将复杂对象建造过程抽象出来(抽象类别),使这个抽象过程的不同实现方法可以构造出不同表现(属性)对象。当创建复杂对象算法应该独立于该对象组成部分时,而且构造过程...
  • 在生成过程中遵循信息对等原则,并引入谓词逻辑使转换过程建立在牢固数学基础之上,更能够保证原型系统正确性和完整性,更易于处理需求变化对系统造成影响,有效降低了软件开发风险,提高了软件开发效率.
  • 螺旋开发方法 如果在每个迭代周期内加入风险分析则产生另一种过程模型:螺旋模型。 螺旋模型核心是将系统建设生命周期分解为多个周期,多次开发完善系统原型,通过每个周期风险分析,实现整个系统风险控制。...
  • DAD 方法在IBM Rational真实运用,除了支撑团队敏捷性以外,对于项目透明度,如风险预估和控制, 架构的原型需求,对于构建过程迭代管理、测试管理、变更管理等是如何融入到开发和测试流程中呢?...
  • 原型法在现在软件开发过程中被广泛使用。首先,我们要明确是,任何一种方法或工具都是为我们开发、生产过程服务,这一点必须清楚,我们不能成为方法或工具奴隶,只要我们认为这个方法论或工具对我们过程...
  • 文章目录软件的开发方法结构化方法面向对象方法面向服务的开发方法原型的开发方法需求分析需求任务需求的过程需求分类应用工具软件设计软件设计任务与活动模块设计原则应用工具 软件的开发方法 ...
  • 信息系统的开发方法

    千次阅读 2017-03-28 19:44:39
    - 基于生命周期开发方法 ...原型开发方法:用最经济方法构造一个系统原型,使用户尽早看到未来系统概貌,在系统原型实际运行中与用户一起发现问题,提出修改意见,不断完善原型,使它逐步满足用户
  •  随着面向对象方法的学习深入,随着软件工程、软件过程学习的深入,逐渐对软件系统分析与设计产生了许多软件过程(文档、项目管理、方法、工具)细节的疑问,乃至最终探寻一种普适性的软件开发过程模型,以下如是...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,288
精华内容 515
关键字:

原型开发方法的开发过程