敏捷软件开发应用分析（共8篇）
敏捷软件开发应用分析 篇1
1 敏捷开发
1.1 简介
相对于"非敏捷", 敏捷开发方法更强调整个项目团队之间的紧密协作, 认为面对面的沟通比书面的文档更加直接有效。这种兴起于19世纪90年代的开发模式适用于需要频繁交付的软件版本, 一般应用在紧凑、自我组织型的团队中, 使得整个团队能够很好地适应需求变化带来的代码编写和团队组织活动;同时它也更加注重人力在软件产品开发过程中的重要作用。
1.2 适用情形
合理地应用此种方法会给当今软件互联网公司的管理和运营带来事半功倍的效果。在通常情况下, 敏捷开发的适用性可以从以下方面来衡量:
(1) 从产品开发的角度看, 敏捷方法适用于需求萌动并且快速改变的产品, 例如项目初期快速收集得来的需求, 特别是客户对其自身需要毫无概念的情况下, 拟定的需求可能会影响软件未来的开发周期及资金等问题。
(2) 从团队的组织结构角度看, 组织结构的文化、人员、沟通则决定了敏捷方法是否适用。如团队沟通顺畅, 协作良好, 大胆开放, 乐于接触新的管理模式, 可以尝试采用此方法。
1.3 项目管理
适用于敏捷开发方法的管理, 已经有一些成熟的项目管理工具, 可以用它们来帮助规划、跟踪、分析和整合敏捷开发工作。这些工具在敏捷开发中扮演重要的角色, 也是知识管理的一种方法。通常包括:版本控制整合, 进度跟踪, 工作分配, 集成发布和迭代规划, 论坛和软件缺陷的报告和跟踪等。
当前互联网行业内常见的敏捷方法包括:敏捷数据库技术, 敏捷建模, 自适应软件开发, 特性驱动开发, 动态系统开发方法, 精益软件开发, AUP, Scrum, 极限编程, 探索性测试等。常用的项目管理工具包括:JIRA, Microsoft Project, Clarity Process Manager等。
2 Scrum
2.1 Scrum流程简介
Scrum是一种迭代式增量软件开发过程, 通常用于敏捷软件开发的管理。Scrum开发流程中包含了三大角色, 包括同项目经理类似的Scrum主管角色, 主要负责维护过程和任务, 统筹管理项目;第二大角色产品负责人代表了利益所有者, 主要负责确定产品的功能和达到要求的标准, 指定软件的发布日期和交付的内容等, 同时有接受或拒绝开发团队工作成果的特权;而第三类开发团队则包括了所有的开发人员, 主要负责软件产品的开发工作, 团队人数控制在5~10人左右, 每个成员负责不同的技术, 但要求每位成员必须要有很强的自我管理能力和表达能力;成员可以采用任何工作方式, 只要能达到Sprint冲刺的目标即可。
每个周期叫做一次冲刺, 时间一般控制在15到30天, 在一个冲刺的时间内, 开发团队创建可用的软件增量。冲刺周期中的每一天都会举行项目状况碰头的会议, 被称为“Scrum”或“每日站立会议”。会议上, 团队成员需要回答三个问题:今天你完成了哪些工作?下一步你打算做什么?完成你的目标是否存在什么困难?成员回答后, Scrum主管需要记录这些问题。每一个冲刺完成后, 都会举行一次冲刺回顾会议, 在会议上所有团队成员都来总结这个冲刺的工作, 反思成果与问题。举行冲刺回顾会议是为了进行持续过程改进。
2.2 Scrum特点
Scrum提倡所有团队成员坐在一起工作, 改善了交流, 以团队为基础, 有助于创造自我组织的团队, 优化了合作方式;制定了一个非常简单的可重复执行的流程, 强调项目有关的规范, 是现有设计流程的一个总结。
Scrum的一个关键原则是承认客户可以在项目过程中改变主意, 采用了经验方法——承认问题无法完全理解或定义, 关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化, 是最大化生产率的一种方法。
更重要的是, 在项目负责人的带领下, 团队会定期反省如何能够做到更有效, 并相应地调整团队的行为, 不断优化进步。
3 实际应用
3.1 计划管理方法
Scrum在本文的应用中主要是指用作项目计划管理方法。按照每个季度或长期存在的产品的整体计划划分Scrum项目组。每个Scrum组的人员组织形式包括:一个项目负责人, 即项目主管;开发团队;QA团队;以及一个产品经理。
3.2 季度计划
每个季度之初的第一次冲刺会议上, 项目负责人先跟产品经理协商, 列表整个季度的主要计划:按照完成的难易程度分为最低目标, 最高目标。全员参会讨论各个目标的合理性, 头脑风暴对于各个目标的实现方式和方法, 并由项目负责人进行汇总, 最后确定整个季度的最低目标和最高目标。
3.3 冲刺周期的任务拆分
每个冲刺周期的工作计划是从产品经理处提出新的产品需求, 交予项目主管, 同时加上项目主管提出长期工作计划, 制作成的冲刺计划表。计划表中的每个计划按照优先级不同排序完成。项目组全体成员参与冲刺会议, 讨论本冲刺中各项需求计划, 大家都没有异议后, 按照自己负责的领域主动领取冲刺计划表中属于自己领域内的任务项, 并根据难度及能力给出一个预计完成时间。如果遇到大型或较为繁琐的任务, 领取后可自行拆分为一个冲刺周期内可实现的小任务, 然后给出子任务的进度估计, 以及总体任务需几个分期。每个冲刺周期持续时间2周, 如果任务完成冲刺时间还没到可以继续领取剩余的拆分任务项;如果一个冲刺的预期时间内没有完成任务, 也可申请延期。
3.4 月末产品展示会
每个月两次冲刺周期的时间结束后, 月末有一个产品展示活动。各个Scrum项目组分别拿出自己阶段性成果在公司平台范围内做一个分享展示, 并不要求一定是成型的产品, 某个功能的简单优化也可以, 只要能体现出不同和优化的点即可, 主要目的是鼓励交流分享, 鼓励创新和阶段性成果。
3.5 一些其他改进
为了节约时间, 互联网公司在实际应用时, 一般是前面一个冲刺的总结会和下个冲刺的讨论会同时进行, 放在每个冲刺的第一天。其中冲刺总结会相对轻松, 提的意见和建议也并不要求是实际的技术问题, 只要与项目进展相关都可以提。
月末的产品展示会上也是一个各个Scrum组交流的场合, 类似茶话会, 气氛比较轻松。
关于日常考勤, 对于Scrum组中的同事也做出了人性化的调整, 凡是参与Scrum项目的员工, 理论上上下班无需按时间记录考勤, 只需要完成日常工作即可。
4 积极影响
应用敏捷方法不仅可以在项目的开发上带来便捷, 也可以对日常工作的管理工作产生积极影响, 比如:在项目负责人的选择方面:为了适应敏捷开发, 项目组的负责人首先在技术上面应充当领头羊的作用, 可以在任何人遇到疑惑时指出合适的方向, 同时又不应讷于言表, 应当思维活跃清晰, 又善于引导项目组成员发散思维, 重视头脑风暴, 重视团队协作, 有效沟通。
关于技术分享:敏捷方法注重沟通。无论谁掌握着新技术或做出了新的突破都会以实际资金激励的方式鼓励员工组织展开分享。鼓励分享与共赢, 共同进步。鼓励项目组内部的技术分享会, 也会鼓励公司级别非技术层面的综合分享, 可以拿出自己任意领域的知识经验和阅历, 只要可以帮助到团队都会得到支持。
不断创新和学习:重视创新, 无论开发的流程上, 测试的探索上, 还是项目管理上, 都应不断学习, 不断探索新方法新思路;同时在项目组内部也鼓励改革, 尝试新技术新手段。
5 可优化的空间
使用敏捷方法对于项目进展而言遇到的一个很重要的问题是对项目的拆分比较困难:大的需求问题开发起来势必花费较长时间, 做不到短平快就失去了冲刺的意义, 不得不拆分成小问题;但大需求一旦拆分成很多小需求, 每个需求的改动在每个冲刺结束后便不易看到整体上的实质效果, 同时, 在业务方面联系紧密的模块在实际的拆分上面总会互有依赖, 如何减少耦合也是项目拆分时候的难点。
而且目前的敏捷方法还是在开发层面使用广泛, 在管理流程中并没引入设计人员和运营人员参与。目前运营人员扮演的角色还是主要与用户打交道, 以及反馈bug给QA人员, 更偏向于产品的技术支持, 而产品的新需求多数还是产品经理设计出来的, 虽然说基于大量用户数据, 但数据是死的人是活的, 如何使死的数据应运而生出不断变化的需求, 是一个需要考虑的问题;因此考虑是否可以在管理的每个冲刺会议中引入运营人员, 更真实地反应用户遇到的实际问题和真正有用的需求, 会比开会头脑风暴时由业务设计者本身代替用户想的要周到和实际。而目前的设计人员只同产品经理和前端开发人员打交道, 只有当开发提出一个设计需求时, 设计人员才会参与到项目中, 个人感觉也可以增加设计人员在项目中的比重, 多收集反馈, 倾听用户的声音, 同时关注同类产品;用户的反馈可以直接交予设计提前做准备, 这样当开发或者产品提出对应需求时, 设计人员可以有的放矢, 而不是纸上谈兵。
另外, Scrum会议的效率还可以进一步提高, 例如每日的站会可以在项目组内建立讨论组或者QQ群, 借助网络在线交流一下, 本身不会花费很久的时间, 同时在线交流的优势在于交流记录可以留存, 方便周期结束后总结会议上使用。
第三, 不同于KPI, Scrum不是能够明确量化个人任务的管理方式, 其实还是比较注重团队合作, 项目的目标制定也是以Scrum团队为单位, 具体分给个人的工作任务相互之间也是有需求有交集的, 不太适合公司层面的绩效考评, 因为任务完不成只需向项目负责人申请延期即可, 与项目组成员自身关系不大, 在管理层面而言, 并不是一个好的激励团队的方式, 因此, 如果找到一个能更好的挂钩项目组成员绩效的管理方式, 也许会对员工起到更积极的促进作用。
参考文献
[1]韩鹏.小规模团队的敏捷开发研究[J].软件工程师, 2011 (7) :42-46.
[2]陈楠, 陈文培.敏捷开发中相关技术的应用[J].计算机应用与软件, 2011, 28 (4) :202-204.
[3]JIM BIRD.三种敏捷开发方式技术指南[EB/OL].http://www.searchbi.com.cn/showcontent_86688.htm, 2014.
[4]陈国栋, 罗省贤.Scrum敏捷软件开发方法实践中的改进和应用[J].计算机技术与发展, 2011, 21 (12) :97-99.
[5]张智海, 周国祥.Scrum方法的研究与分析[J].合肥工业大学学报 (自然科学版) , 2010, 33 (2) :197-200.
敏捷软件开发应用分析 篇2
关键词：移动互联网；创新应用；敏捷开发
中图分类号：TP311
1 移动互联网应用创新需要敏捷开发
1.1 传统开发和敏捷开发的区别。传统开发方法即生命周期方法，又称结构化范型。它采用结构化技术来完成软件开发的各项任务。瀑布模型是传统方法代表，该模型将软件生命周期定义为六个基本活动：计划制定、需求分析、软件设计、代码编写、上线测试和运行维护，并且规定它们由始至终、相互衔接的固定顺序，犹如瀑布流水，逐级下落。
敏捷开发则是把大项目划分为多个互相关联，但也可独立运行的小项目，并分别完成，子项目的成果都经过单独测试，均具备集成和可运行的特征，因此在实施过程中软件可一直处于使用状态。敏捷开发由几种轻量级的软件开发方法组成，如极限编程，Scrum，精益开发，特征驱动开发，动态系统开发方法，水晶开发等等。[1]
由此可见传统开发模式在结构层次明晰，但流程上较为固定，对各个阶段的准确度要求较高，对软件的实施结果可预见性差。而敏捷开发化繁为简，各模块独立性强并能单独部署，所见即所得，提高投资的可靠性和回报速度。
1.2 移动互联网应用创新特点。美国经济学家熊·彼得说：所谓创新就是要“建立一种新的生产函数”，即“生产要素的重新组合”，就是要把一种从来没有的关于生产要素和生产条件的“新组合”引进生产体系中去，以实现对生产要素或生产条件的“新组合”。[2]创新的目的是对老旧的流程进行改进和革新，从而引领时代发展的潮流。创新分为两类，一类是技术创新，一类是管理创新。而技术创新是工具，其目的是为了实现业务创新。
移动互联网应用创新具有以下特点：
（1）移动互联网应用创新的主要切入点为“提升客户感知”：移动应用创新的技术难度均不复杂，关键在于想法新颖不新颖。从目前来看，绝大部分创新应用是基于移动互联网地理定位、私密性、便捷性等的特点，来改善客户感知，如基于LBS的服务、即时通信、移动商务、应用商店等。而基于客户感知方面的需求往往是要求能短平快实现和解决，这就契合了敏捷开发的特点。
（2）创新需紧跟潮流并具有不确定性：由于互联网环境的迅速变化，如何将app或业务快速推如市场成为创新应用成败的关键，也就是我们说的敏捷度。敏捷开发精神强调程序员与业务管理者之间的直接沟通、紧凑而主动的团队协作，充分发挥软件开发中人的作用，通过软件版本的频繁交付，因此能够很好地适应需求的快速变化。同时，创新性移动应用的最大特点是未来市场的不确定性和难以预测性，在开发中，采用依托于敏捷开发的核心精髓的循环迭代流程，能帮助开发者提高效率、降低成本，并尽可能贴近市场需求。
1.3 传统开发模式无法支撑移动互联网创新。移动互联网应用创新特点对软件开发项目管理提出了如下要求：能够“随即而动”响应不断变化的需求，能够正确快速的接应需求迅速进入开发状态，代码和软件维护的便捷性以保证7*24小时不间断服务，能够迅速提供产品并不断完善。而传统的软件开发方法，将很难实现以上要求：
（1）在实际的软件开发过程中，有时因顾客不能很好的表达自己的需求，或者顾客和开发者理解上的差异，导致大多数情况下软件开发过程需求还会不断随时间变化而变化。瀑布开发模型很难适应这种变化；敏捷拥抱变化，允许变化可以随时随地发生。在敏捷开发中，变化与增加新功能是没有矛盾的。
（2）传统方法开发软件的过程，往往是顾客与开发团队的利益博弈的过程，开发过程中顾客的参与度不高。这也是传统开发模式下最终交付软件与顾客预期存在巨大差距的重要原因。而在敏捷开发中，要求顾客和开发团队一起开发，保障软件和客户目标的一致性。
（3）传统方法学不同开发阶段由不同的人来完成，团队成员参与度不高，不利于软件整体维护。敏捷开发强调简单设计，合作开发，团队每个成员都从开始接触客户到需求分析，程序设计以及编码、维护工作，全程参与全部承担。
（4）传统方法往往要到最后才能得到可执行的产品，而敏捷开发很早就可以得到可执行的产品。
1.4 结论。因此，在绝大部分情况下，移动互联网的创新应用，我们必须采取敏捷开发的模式。
2 敏捷开发实践
2.1 项目介绍。本次创新开发实践的项目名称为“微信客服”。微信由于“一对一”私密性与互动性，在客户服务方面具有独特的优势，它一方面可安全高效地完成用户业务咨询需求，另一方面让用户能感知到自己互动的对象是实实在在的人。通过微信渠道，为用户提供个性化的客户服务，对提升企业形象、增强客户粘度能起到良好的促进作用。
将“微信”作为客户服务的一种渠道是比较大胆的创新探索，为规避投资风险，同时从节约开发成本方面考虑，采取创建小型虚拟团队以极限编程模式进行开发。
2.2 项目实施流程。
（1）与客户沟通，制定开发计划。项目组成立后，程序员团队立即与客户进行沟通，并从“客户感知”的角度出发共同确定系统需求，拟定功能模块，形成简单需求文档。同时制定开发计划：实现三个迭代周期：第一个周期完成话费查询、积分查询、营业厅查询这三个模块；第二个周期完成业务定制、促销活动、在线客服这三个模块；第三个周期完成自定义菜单、后台管理功能两个模块。
（2）结对编程，提高质量。团队成员按照功模块进行简单分工，两两组队，使用基于团队开发的工具如GIT，SVN，共同完成同一功能模块。结对模式是团队成员中进行新老搭配，老成员负责编写代码，新成员负责系统测试及代码走查，以保证代码的准确性性和可读性。
（3）共享代码，共同维护。使用GIT版本管理工具，保证代码的同步更新和合作开发，保证所有成员具有相同的阅读权限，每个成员不仅需清楚自己所编写的代码，也要了解其它队员代码编写情况，同时赋予每个成员都更改代码的权利，任何问题的出现都由全团队成员一起讨论、修改，这样，即使因某个团队成员的离开也不会影响到整个项目的开发进程。
（4）持续集成、测试。每周开展一次集体测试会，邀请客户一起进行测试，在这过程中注意客户的反馈意见，及时变更部分需求，积极进行编码测试，保证开发的质量和避免风险的发生。
2.3 效果和效益评价。整个系统经过一个半月的迭代开发，到最后一个版本发布时，整个系统早已稳定运行。团开发充分注重了安全性、易用性及灵活性，同时敏捷模式使客户对系统所提出的任何要求均按质按量全部实现，获得了客户的高度好评。
如按照原来的流程进行开发，客户必须一次性整理需求，且中途无法变更，导致需求搜集时间过长，拖延开发周期。同时采用传统开发模式，通常采用一次性交付软件的方式，对使用过程中发现的问题或新产生的需求，必须增加投资进行解决或实现。
由此可见，通过敏捷开发的方式，即有效的提高了客户感知，也大量的缩短了开发时间成本和投入成本。
参考文献：
[1]Alistair Cockburn，敏捷软件开发[M].苏敬凯.北京：机械工业出版社，2008，1.
[2]王蕾，曹希敬.熊彼特之创新理论的发展演变[J].科技和产业，2012，6.
作者简介：金杰（1980-），浙江台州人，工程师，现供职于中国电信重庆公司。
敏捷软件开发应用分析 篇3
1 敏捷开发
敏捷开发是由15个科学家共同提出来的,其中包括来自思特沃克公司 ( Thought Works) 著名的软件大师马丁·福勒 ( Martin Fowler)[1]。敏捷开发即一种全新而快捷的软件开发模式,是把人放在第一位,以满足用户不同需求为导向的开发模式[2]。应用敏捷开发的方法,要求团队成员具有很强的主动性,满足了高内聚、松耦合的原则把项目分成了若干个小组。较少的文档准备和分组的新方式缩短了软件开发周期,开发过程中的多次迭代和测试提高了软件的质量[3]。
2 敏捷技术的重要性
从目前敏捷开发的研究现状中,我们可以看到在任何一个软件的开发过程中,任何的一种模式都不是能解决所有问题的万能钥匙,所以在软件开发过程中应全面考虑所有的问题,不管是开发方法、设计模式还是设计架构都是必须考虑的重要因素,而就目前敏捷开发的应用研究来看,敏捷开发的过程,对技术并没有明确的指导思想,这也正是多数项目在应用敏捷开发过程中失败的重要因素。
从根本来说,敏捷开发不仅是一个软件开发过程的方法论,准确地说它更是一种思想,但这种方法是建立在敏捷技术上的,敏捷技术为这一方法的实施提供了可行性,只有敏捷的技术才能支撑敏捷开发的实施[4]。真正的敏捷开发不只是管理层次的敏捷、项目参与人员的敏捷,架构的设计也应该是敏捷的,编程思想也应该是敏捷的,这才是实至名归的敏捷开发。在项目真正进行过程中,为了能更好地发挥敏捷开发的优势应做到管理与技术同步规范。管理与技术是不可分割的,二者相辅相成,技术的敏捷使得敏捷开发方法的实施具有一定可操作性,是敏捷开发方法的基石,如果没有相关技术的支持,敏捷开发是不能完全发挥效应的甚至是不可行的。只有做到管理与技术同步敏捷,在管理的过程中得到相应技术的支撑,敏捷开发方法才能发挥真正的敏捷,才是真正的敏捷思想。
2. 1 简单三层
敏捷开发方法要求在敏捷开发实施过程中,如何保证开发团队的每个开发人员能够独立地进行系统模块开发是敏捷开发能否成功的关键因素。而以往的传统开发技术,并没有将系统模块化,整个系统的耦合性较高,依赖性较强,使用传统的开发技术并不能实施敏捷开发方法,使得敏捷开发提倡的系统各模块之间并行开发成为空想。简单三层却为这一要求提供了可行性。
三层架构由底层至上层分为数据访问层 ( Data AccessLayer,DAL) ,业务逻辑层 ( Business Logic Layer,BLL) ,用户界面 ( User Interface,UI)[5]。简单三层将界面的呈现、业务逻辑的处理以及访问数据库很好的分离开来,因此在系统实现编码过程中不仅可以实现系统各模块的并行开发,而且不要求全能型的开发人员,只需精通其中一层即可参与到项目当中,在保证工作高效且代码质量的同时节约了开发成本[6]。在测试方面,三层也可同步进行,可以解决敏捷开发在测试环节中给项目带来的成本偏高问题,在支持敏捷开发实施的同时,又保证了整个系统的安全,降低了系统的复杂性,无形之中也提高了项目参与人员的积极性,使得敏捷开发能够顺利进行。
2.2 抽象工厂模式
敏捷开发提倡的是拥抱变化,要求在开发过程中进行多次的迭代,项目团队进行周期性的交流沟通,随时应对客户的需求变化,勇敢地面对变化,对于用户的反馈,程序员要有勇气对已经编写好的代码进行适当的修改[7]。敏捷开发里所说的勇于接受变化并不是简单的要求项目团队在客户提出新的要求时,就将之前的系统全部放弃,从头再来,这并不是真正意义上的敏捷开发。但是面对这样的需求敏捷开发只是单纯的提出了要求,并没有对此有进一步的说明和指导,而为了满足更换数据库的需求重新编译数据操作类就相当于项目从头开始,又不是最好的解决办法。如何在面对客户需求的时候,尽可能地减少代码的修改量,代码的复用性是一个关键因素。想要提高代码的复用性,就想到了设计模式,在当前的设计模式中,抽象工厂模式很好地解决了这一问题。
作为创建型模式的抽象工厂模式是23种设计模式中的一种,所谓创建型模式就是不需要自己实例化对象,而是由创建型模式来代替新操作[8]。抽象工厂模式指的是提供一个创建一系列相关或者相互依赖对象的接口,而不需要指定它具体的类[9]。该类设计模式是专门针对需求的变化来达到提高代码复用性目标的一种模式,它就相当于一个实实在在的工厂,只不过与我们现实生活中的工厂不同的是现实生活中的工厂是用来生产产品,但是这里的工厂是用来管理变化的。
使用抽象工厂模式将可变的进行封装,以接口的形式呈现,在三层中应用抽象工厂模式,在不需要修改以前代码的前提下轻松地解决了更换数据库类型这一需求,并且在系统开发完成之后甚至是使用过程中,都可轻松地更换数据库类型,有效地解决了由于需求变化导致开发周期延长,并且为系统的后期维护降低了成本。
2.3 ASP. Net MVC
客户的需求贯穿于整个项目中,虽然敏捷开发中采取先测试再编码的方式有效地应对了客户需求的变化,但是并不排除客户对测试满意,开发完成之后又提出了新要求的可能性存在。对于大多数客户来说需求的变化主要体现在系统功能和界面展示方面,针对这一可能性传统的敏捷开发并没有很好的解决办法,只能重新编写,重新测试,但是这一问题是周而复始的,这样的做法治标不治本。应对这一状况就应考虑到从技术方面入手。
在通常情况下,系统的页面开发都是用网页表格( Web Form) 进行,虽然网页表格 ( Web Form) 操作简单,可以直接拖控件对页面完成布局工作,但是它的页面展示与后台逻辑代码的耦合度较高,在遇到客户对页面布局要求变更的时候,不仅要进行页面布局的修改,还要将相应的页面逻辑进行修改,这无疑多做了很多没有必要的工作,这时ASP. Net MVC框架成了解决这一问题的第一选择。
ASP. Net MVC是微软在2009年对外公开发布的第一个开源的表示层框架[10]。ASP. Net MVC模式是一种表现模式,它可以将 表现层分 成模型 ( Model ) 、控制器( Controller) 和视图 ( View) 三个组件,有效地分离了页面展示与用户界面 ( UI) 逻辑代码,所以ASP. Net MVC是一个更加倾向于用户界面层 ( UI) 的表现层框架,是网页表格 ( Web Form) 的另一种选择[11]。在面对客户对页面展示需求变化的时候,只需更改相应页面的展示效果即可。
3 敏捷技术应用实例
3. 1 项目简介
本校的博士研究生招生工作在2013年之前均是通过工作人员手工的录入以及核对完成的,因此,本校博士招生工作存在效率低下,管理无序,数据安全性较差等诸多问题,实施办公自动化对于我校的博士招生工作具有重大意义。本项目将采用本文所提及的融合敏捷技术的敏捷开发方法对系统进行开发。
3.2 敏捷技术在开发中的具体应用与实现
根据上述分析,博士研究生招生系统的整体架构见下图。
从上图中我们可以看到,本系统结合了简单三层架构、抽象工厂设计模式和ASP. Net MVC框架三大技术,本系统使用2011年发布的ASP. Net MVC3. 0版本[12]。本论文主要从这三个技术的应用上进行详细论述,来论证敏捷技术对敏捷开发的重要性。
3. 2. 1 抽象工厂模式在数据访问层的应用
对于本系统的开发主要是针对学生各种信息的管理与操作,并且录取的学生信息数据库要与我校现有的各种学生工作系统进行衔接,而所用数据库并不相同,对现在已经使用的系统进行修改并不是一个好办法,只有针对目前着手开发的博士研究生招生系统进行完善,来迎合不同数据库的需求。解决这一需求的办法就是抽象工厂模式。本文以考生登录功能为例进行技术应用说明。
创建抽象工厂类,利用 . Net的反射机制获取数据访问层的程序集和命名空间的名称,通过数据访问接口层来创建user_ infor数据表的实体类,并采用缓存技术来提高系统性能,设置当前应用程序指定Cache Key的Cache值的核心代码如下:
由于数据访问层融合了抽象工厂设计模式的思想,所以业务逻辑层调用数据访问层是通过数据访问接口层创建相对应的数据工厂实例,并没有指定具体的数据操作类,因此,在面对更改数据库类型时,只需修改配置文件的程序集和命名空间的Value值即可,配置文件代码如下:
由此可见,应用了抽象工厂模式和反射机制加上配置文件的使用,在不需要修改系统代码的前提下轻松实现了异库移植操作,并且为本项目实施敏捷开发时适应了需求且缩短了开发周期。
3. 2. 2 ASP. Net MVC 框架的应用
在ASP. Net MVC中UI逻辑在Controller组件中进行编译,Controller负责将数据从Model取出传递给View[13]。在本系统里,ASP. Net MVC代替网页表格 ( Web Form)作为三层中的用户界面层 ( UI) ,所以在界面展示编译中,ASP. Net MVC框架中的控制器 ( Controller) 组件则负责与业务逻辑层进行对话,从业务逻辑层调用校验用户的方法来获取数据库中的考生登陆信息。判断登陆是否成功的部分代码如下:
前台的页面布局交由视图 ( View) 组件负责,由于它与控制器 ( Controller) 组件的低耦合性,视图 ( View)的页面展示只需单纯的Html标签即可实现,并且不需要将标签ID传到后台,实现了UI展示与UI逻辑的彻底分离。登录页面的视图 ( View) 核心代码如下所示:
从以上代码我们可以看出,视图 ( View) 页面都是由Html标签实现,所以在更换页面布局的时候就不需要考虑前台标签与后台逻辑的绑定问题,不需要修改用户界面 ( UI) 逻辑代码。
4 结 论
敏捷管理在软件开发中的应用 篇4
1 敏捷管理模式的原则与特点
所谓敏捷开发, 指的是以团队协作为基础, 通过快速响应客户需求变化, 以信息系统的迭代进行开发的新理念。敏捷开发的核心要素便是将开发者本身作为开发过程的一部分, 通过循序渐进的迭代来最终实现系统。已经有不少软件开发实例可以证明:基于敏捷管理的软件开发能够在很大程度上提升信息系统的生产率, 非常适合充满变换的客户需求环境, 也可以为客户解决需求模糊的问题。
敏捷管理的一系列原则保证了信息系统开发的高效, 这些原则计有: (1) 将客户的满意度置于服务的首位, 并以时间的保证和质量的保证为基础; (2) 在软件开发周期中的任何阶段, 均满足系统用户的需求改变, 并以敏捷过程来快速完成变化, 以巩固客户的竞争优势; (3) 软件的部分模块如果已经开发完成, 即可交付用户使用, 尽可能缩短交付时间, 提升客户的满意度; (4) 信息系统的业务人员和开发者, 应该在软件开发的全周期内协同工作, 互相配合; (5) 对于团队所有的成员, 均肯定其价值, 并激励其付出努力, 通过为富于不同技术特长的团队成员提供适用于其提升效率的工作环境和管理体系, 使其能够高效率完成开发目标; (6) 开发团队保持高速沟通, 支持成员之间通过交谈和讨论实现信息的传递; (7) 软件开发的进度是团队考核权重最大的因素; (8) 敏捷管理的重点, 是使开发团队能够恒久地保持高效率; (9) 团队应该及时地西区和引入更优秀的开发技巧与更新近的开发理念; (10) 通过简单化的描述, 为尚未完成的部分指明方向; (11) 团队内部的协调一致, 才能为客户提供最为理想的软件体系次; (12) 软件开发团队应该周期性地进行总结, 对开发进程与开发目标进行调整。
在以上原则的界定之下, 基于敏捷管理模式的信息系统开发具有的最鲜明的特点是: (1) 通过开发者与客户的直接沟通, 快速传递信息, 最大限度提升软件开发对于客户需求的满足; (2) 结合不同的用户需求, 为系统开发拟定不同的周期, 以短周期迭代的模式减少返工; (3) 引入代码重构, 加强代码鲁棒性。
2 敏捷管理在软件开发中的应用
2.1 项目概况
2.1.1 项目简述
针对某公司对于综合管理的要求, 为其开发一套建立一套智能办公环境能源管理控制平台系统。系统的需求简要概述如下。
能源采集模块主要包括能源数据实时采集、能源数据的远程传输。通过能源数据实时采集功能, 实时通信服务器按指定采集周期自动采集用户的能源消耗实时数据和能耗设备状态, 并将采集数据保存至实时数据库同时将结果定时或者即时上传到远程云计算数据中心。
能源监控和管理模块主要包括系统管理、区域管理、能耗分析、能耗测评、数据报表和事件记录。系统管理功能完成用户对系统的基本设置和管理的功能。其中主要包括用户信息、数据导入等。
2.1.2 项目分析
从项目的需求可知, 此信息系统由于涉及到不同部门的数据统计分析, 因此一方面必须能够及时地处理繁多的采集数据与分析数据;另一方面还应能够结合不同权限用户对不同功能模块进行权限的规定与设置, 因此具有一定的复杂性;加之信息系统对时间要求比较紧急、客户需求经常发生更改, 本团队为新组建团队, 尚未磨合顺畅等因素, 因此引入敏捷管理方法进行开发与实现。
2.2 项目实施
2.2.1 敏捷管理模式的引入
结合团队计划, 最初以瀑布式模型在作为此信息系统的开发思路。但是很快发现进展缓慢, 原因在于系统架构尚未完全明确, 模块无法投入测试。以能源采集模块为例, 因为最初难以对所有类型的采集数据进行清晰分类, 造成此模块的管理比较混乱, 最终重新进行。此外对于系统架构的选择也没有及时确定。以上原因造成项目进展落后与原计划。考虑到系统需求多样, 开发团队最终引入了敏捷管理模式ScrumWorks, 并开始重新运作项目。
2.2.2 用户需求的重构
结合敏捷管理模式, 项目团队重新梳理用户的实际需求, 通过信息系统的业务方与开发团队集中讨论和细化, 使业务需求逐渐变得明晰和可量化。在此基础上, 明确信息系统最为关键的功能点, 并及时在需求报告中体现出客户需求的变更。
2.2.3 技术路线的确定
为适应敏捷管理, 系统采用B/S结构引入SSH构架, 以Spring来实现系统所需的服务, 并引入ESB技术作为SOA中介, 通过为J2EE结构中的业务逻辑层底部补充服务层, 实现系统对具体参与调用的软件代码的封装。在整个系统里, 将所有模块的功能都定义成相互之间彼此独立的一个服务, 所有服务都为系统的表示层预留了可被随时调用的网络服务接口。系统的具体业务流程则以单个或多个服务进行组合之后来实现, 最终的实现表示为表示层的一个业务逻辑视图。其优势在于一方面减轻了开发工作量;另一方面通过预留接口, 能够轻易地实现与另外一些系统业务系统的对接, 最大限度地拓展了系统兼容性, 也不再存在版本方面的冲突。在系统框架设计中, 引入了分层化的设计模式, 对于不一样的操作与不一样的处理, 将其分配到不一样的层次中来处理, 在信息系统具体的开发过程中, 为了使层次之间能够彼此保持更大程度的独立性, 不同的层次与层次间, 仅仅以接口来进行通信, 凡属于下一级的层次, 均具备为了满足上层调用而设置的接口, 具有比较好的扩展性、比较强的重用性、和比较通用的可维护性, 基于此框架的智能办公环境能源管理控制系统能够为管理部门的信息化管理提供支持。
2.2.4 开始迭代周期
结合项目本身的需求, 本课题将迭代周期设置为14天。业务方代表每个周期前均应与开发团队通过会议的方式明确每个人的分工, 以及本周期的最终目标。由于客户的需求有时候会发生变动, 因此在会议中也应对上一个周期的变更进行细致的讨论, 如果寻在未能及时完成的工作, 则将其纳入本周期之中。
2.2.5 迭代过程跟踪
由于团队的所有成员均已在迭代周期中明确了自身的责任与工作, 因此在这一阶段, 信息系统的设计比较顺利。通过甘特图, 管理者也能及时获取每一个团队成员的工作进展情况, 管理者可以结合每一名成员的实际能力与特长, 结合其工作进度对工作任务作出调整, 以增加团队效率。
2.2.6 里程碑的实现
为了是使信息系统的进度控制更加精细, 项目组把一些模块的实现作为本课题的里程碑事件, 在几个重要的“里程碑事件”发生之后, 软件开发团队已经向客户提交了信息系统的第一个版本, 而结合用户以后又造价的新的需求, 将以后续的版本来分别一一实现。
3 结语
基于敏捷管理模式的软件开发模式是一个渗透在软件开发全周期的过程, 属于一个必须持之以恒的信息系统构建原则而非一个独立的事件。敏捷开发的最终目标, 是使软件开发能够适应于可累复杂护着模糊的环境, 尽可能的维持其清晰性与简单化。本文所阐述的基于敏捷管理方式的信息系统开发模式十分适合中小型团队的项目, 实践证明, 这种方法可以在极大程度上提升客户满意度, 也能够充分保证信息系统的质量。
摘要：“:敏捷管理”是近年来被广泛推广的一种开发软件的管理方法, 这种方法以实践为基准, 为复杂度不断增加的软件需求提供了新的解决思路。本文在阐述敏捷管理的原则、特点的基础上, 以敏捷方法在信息系统开发中的实践为例, 阐述敏捷管理在软件开发中的作用, 实践证明, 这种方法可以在极大程度上提升客户满意度, 也能够充分保证信息系统的质量。
关键词：敏捷管理,软件开发,客户满意度
参考文献
[1]理查得.科克, 冯斌译.80/20法则[M].中信出版社, 2011:10-12.
[2] (Agile Modeling) Scott.Ambler, 著.敏捷建模[M].张嘉路, 译.机械工业出版社, 2012:17-20.
[3]Ivar Jacobson, Grady Booch, J amesRumbaugh, 著.统一软件开发过程[M].周伯生, 冯学敏, 樊东平, 译.北京:机械工业出版社, 2012, 10.
[4]Kent Beck.Extreme programmin gex plain ed:embrace change.2nd e d.Addison-Wesley Professional, 2011.
敏捷软件开发应用分析 篇5
计算机游戏可以说是与计算机同步发展的最流行的软件。谈到游戏软件，大多数人都认为其神妙莫测，高不可及。而一般游戏软件也确实具有很高的技术难度，随着开发工具及软件开发方法学的不断发展，动手开发游戏也不是十分困难的。五子棋是一种古老而又有趣的游戏，五子棋游戏软件不计其数，并且不断推陈出新。网上就有好多关于实现的复杂算法和设计，其难度让一般初学者望而却步，本文旨在提出一种简单而不愚蠢的敏捷软件开发方法。
敏捷软件开发是一种相对传统软件开发方法而言的轻型方法。认为只要能适应软件需求变化的开发方法都是敏捷的。解决需求变化之路强调以人为本，强调个人能力及素质重于过程，强调能够工作的代码胜过面面俱到的文档。以下是以Delphi为开发工具的一个开发过程。
2 需求获取及系统设计
敏捷开发不再像传统过程把开发过程分成明显的阶段，在开始时，进行简单设计。在需求获取上，不是从细节上过分细致地讨论，而是稍微粒度大些，抽象出关键的、主要的类，简单设计的意思是不做过分设计复杂的算法，尽快做出能工作的软件或原型，在后面需求变化中不断调整目标。根据软件开发的一般步骤，进行需求分析，开始时不可能一步得到最终详尽的软件需求规格说明，只能对需求进行粗略描述：给出五子棋盘，供两个玩家对弈，可以人人对弈，也可人机对弈。从此可以看出，应设置两个类：棋类和玩家类。棋类提供棋盘，接受棋子，供玩家读棋盘状态。考虑到棋手只是一个参与者，只要会给出位置就以了，不必设置类只需增设一全局变量player表示当前棋手是黑或白即可。因此可写出棋类说明如下：
通过编写测试用例容易验证其正确性。
3 界面设计
界面设计与实现相分离，都以接口为中心，面向接口设计。具体的实现依赖抽象的接口，在开发的过程中，算法可能不断改进，可以在基类的基础上进行派生，利于实现封闭-开放性原则。根据类设计的相关原则，下棋、棋盘显示等都不应由棋类负责，其它的功能先由表单实现。根据单一职责原则适当的时刻分离出新的类来。新建表单form1,在其内添加一image对象，设置其picture属性为一棋盘BMP文件。当鼠标按下时，通过对位置的转换向棋类发出行列信息，即可实现下棋。
以上代码已能实现两人在计算机前下棋，但需要人工判赢。
4 不断响应需求变化进行增量迭代
如果要让计算机自动判赢，根据单一职责原则，增设一计算机类，让其判断在一条线上的某类棋子的数目，在棋盘中，有四个方向，在一条直线可能是由一点向两个相反方向的射线组成，根据抽象原则，应设置从某点向八个方向中的某个方向试探的方法。
在判赢时只要函数four(player,x,y)为真即为赢。到此想到，让计算机下棋就是让计算机找合适的、有利的位置，首先能守。当对手的棋子四个一线时，上述函数可以完成此功能。同样，对手的三个棋子相连也是需要防守的，以及两线交叉的致胜点等，因此计算机类增加以下方法：
在procedure TForm1.Image1MouseDown中的form1.drawxy(y DIV 35+1,x DIV 35+1);之后加上computer.select(player)就可实现人机对弈了。此时计算机具有一定的防守和攻击能力。
5 重构让代码清洁，以利于响应变化
代码是最重要文档，为了让代码利于交流、传播，必须不断对代码重构。根据重构的原则，在代码重复时，就要考虑重构，在一个方法中，如果语句行数起过30行，就要考虑重构，来保障代码的清晰易读。发现在computer类中有许多重复的语句，分别对它们进行重构。特别是对select重构时，发现一缺陷，只凭优先级找到的点，太简单，不能实现既对自己有利又堵了对方，另外，每一方法都是进行一遍扫描，即多次双重循环，就考虑用一个双重循环，经过分析设计得出按优先级加权求和的方法，并修改four等返回类型为整数类型。通过重构，代码更简洁清晰，并且以后很容易响应规则的变化，以利于软件的深度开发。以下是计算机类的一部分代码：
通过重构，此程序具有了较高的攻守能力，能达到中级棋手水平。容易增加模块实现网上两个选手的对弈，以及丰富其他功能。
6 总结
敏捷软件开发强调简单设计，不是设计复杂的扩展接口，而是重视代码的质量，及时重构，利于增加功能。代码即为设计，实行结对编程，利于交流和知识的传播。进行敏捷开发不仅是开发的性走之路，也是个人技术、素质提高的最好方式。
摘要：敏捷软件开发是一种相对传统软件开发方法而言的轻型方法,强调以人为本,尽可能少的约束开人员,利于发挥开发人员的的创造性,也是提高软件质量的根本。开发人员必须遵循敏捷开发实践,提高自身水平,游戏软件的开发是进行实践的好方式,本文以五子棋游戏开发为例,给出敏捷开发的一些关键实践,需求的敏捷获取、代码的重构及测试驱动等响应需求变化的敏捷开发方法。
关键词：游戏,敏捷开发,增量迭代,重构
参考文献
[1]Martin R C.敏捷软件开发[M].邓辉,译.北京:清华大学出版社,2003.
[2]Ken Auer Roy Miller.应用极限编程[M].唐东铭,译.北京:人民邮电出版社,2003.
敏捷软件开发应用分析 篇6
关键词：敏捷开发,Web应用,开放框架
1 前言
在互联网技术发展中,以Web应用作为核心的开发框架已经在各领域内广泛使用,不同应用软件的设计让互联网市场竞争越加激烈。现阶段的Web应用开放框架的使用情况正好与敏捷思维相结合。敏捷开放被人们理解为一种以人作为核心的开发形式。本文就将对敏捷开发中的Web应用开发框架简单研究,对于敏捷开发在Web应用开放中的应用全面介绍。
2 敏捷开发
世界内的互联网技术更新速度较快,各种Web应用层出不穷,Web应用市场内的竞争强度逐渐提升。敏捷开发就是Web应用设计人员为了在市场中占据优势所提出的。敏捷开放能够将Web市场只给你对于应用设计的速度及灵活性保证在速度保证的同时还保证应用质量。敏捷开发在实际使用中不会产生大量的数据,让研发人员更够从数据编辑中脱离,让Web应用划分为不同的部分,让开发公司内的全部工作人员共同工作,保证在开发设计过程中Web应用一直保持在可以使用的状态下[1]。
3 敏捷开发中的Web应用开发框架设计与实现
3.1 前端技术框架
3.1.1 功能要求
在Web应用前端技术框架开发中,为让应用能够在第一时间吸引到使用者的注意,经常将页面设计较为独特,这就需要前端技术框架中的组件提供独特风格,最后只需要在页面风格的基础上添加各种元素就可以样页面拥有统一的样式。想要保证页面格式的统一也可以使用Web应用前端技术框架中的模板样式,这种方式的好处及时降低内嵌CSS使用频率,方便后期对代码进行维修[2]。
3.1.2 非功能要求
Web应用前端技术框架不仅仅是在功能上有要求,在实际开发中还需要考虑非功能要求,让Web应用的浏览系统具有兼容性,提升Web应用性能及用户的体验满意度。只有将非功能要求进行满足,才能够保证Web应用在市场中具有较强的竞争力,被各个行业所使用,前端技术框架浏览系统对于标准制定及解码方式间存在较大差别,但是前端技术框架必须能够将不同的浏览器共同识别,同时保证浏览系统的正常运行。
3.2 后端技术框架
在Web应用后端技术框架中主要包括三个层次,分别为表示层、业务层、持久层。每一个层次所要负责的内容存在差异,在模型整合的过程中可以从着三个层次考虑[3]。
3.3 实际Web应用框架形成
3.3.1 Web应用框架形成总体技术
在Web应用中经常使用的分层结构就是后端技术框架的三个层次。表示层能够让不同用户在使用过程中浏览到实际需求的页面,为用户提供更加方便的页面体验。业务层在实际使用中主要是对业务逻辑关系的体现,在不同业务中可能包括一些相对独立的业务逻辑思维方向,通过业务层次就可以将开发中的组件与模式充分利用,保证用户在实际使用中能够有效分清业务间的逻辑关系。
3.3.2 前端技术框架形成
Web应用前端技术框架在实际应用中主要包括对页面、管理人员页面的设计,这样能够让应用在实际使用中具有一定的风格,使用更加舒适的布局形式,设计用户需求的专门标志,通过使用多媒体的形式将应用内容进行播放。应用在实际使用中经常需要设计一个管理人员专门使用的页面,这样可以保证管理人员有效的对信息进行管理与分析,提取出真正需要的信息。如图1所示。
3.3.3 后端技术框架形成
Web应用在后端的应用中,主要就是使用已经成型的技术框架为用户完成业务功能的设计,最终开发出用户满意的应用。不同层次的后端技术框架所需要承担的功能存在差异,例如表示层仅仅需要将用户的身份信息进行验证,保证用户在使用中的字符正确性[4]。
4 结语
敏捷开发中的Web应用开发框架能够让开发公司在市场中具有较强的竞争力,及时根据市场需求开发Web应用。
参考文献
[1]郭广军,羊四清,戴经国,刘永逸.基于Struts框架的Web应用开发技术研究[J].计算机应用与软件,2007,09:209-212.
[2]董永刚,庄骐,王虎.快速交付的WEB应用开发框架研究——WAD开发框架[J].信息与电脑(理论版),2011,No.24609:129-131.
[3]陈继华,岳晓瑞.基于Rails和j Query的Web应用程序敏捷开发[J].数字技术与应用,2010,02:39-40.
敏捷软件开发应用分析 篇7
敏捷开发方法是一种与传统的“瀑布式”模型和CMM截然相反的开发方法。这一开发方法注重开发团队成员之间关系而不是已开发的进程使用的工具为重点, 注重开发的软件产品而不是追求广泛的文档编制, 注重开发过程中与客户的协同工作而不以签订合同的谈判为工作重心, 注重在开发过程中随时调整计划而不同意完全遵循某一开发计划, 以实现所谓开发过程的敏捷[2,3]。
1 敏捷开发概述
敏捷开发是一种以人为核心, 迭代、循序渐进的开发方法。是为了解决项目的复杂性, 以最快的方式实现需求的开发方法。在敏捷开发中, 软件项目的构建被切分成多个子项目和多个子阶段, 各个子项目和各个子阶段的成果都经过测试, 具备集成和可运行的特征, 而各个子阶段是在上一个子阶段经过测试审查完成以后才开始下一个子阶段。
敏捷开发方法的应用是以小组为前提的。小组包含有两种角色:产品所有者 (Productor Owner) 和开发团队, 产品所有者的主要职责包括:确认小组所有成员都在追求一个共同的目标, 告知对于软件系统预期的功能以及展现形式, 确定功能的优先级以便开发团队总是在完成最有价值的工作, 回答开发团队提出的疑问等。开发团队里的人员包括了系统架构师、需求分析师、软件工程师、测试人员以及文档编写者。敏捷开发小组需要定期开讨论会就不合需求之处讨论实施方案。
2 敏捷开发系统实例分析
2.1 项目背景及需求分析
2014年8月, 笔者为某公司开发技术支持信息平台, 以提高该公司运作效率, 节约成本。前期需求分析用了比较长的时间。首先开发团队进驻该公司, 向各个部门管理人员和工作人员深入了解各个岗位的具体工作内容并做了详细记录;其次从该公司人事部门获取了组织机构图及各个岗位的人员安排, 并将软件架构设计及数据结构设计讨论形成完整的方案, 形成了前期需求文档。依照该方案约定, 设计了系统框架, 再次跟客户讨论, 对不合理之处进行了调整。接下来进行功能需求调研, 调研之后发现该公司存在如下问题。
1) 由于该公司业务特性, 大部分员工长期在项目服务机构工作, 甚至有部分海外项目, 短期内无法回本部, 当遇到政策或技术等问题时无法获取本行业相关实时资料, 从而造成了项目潜在风险。
2) 由上级公司以及国家相关部门发布的体系文件、规范标准、法律法规等文件公司必须及时获取并提供给公司全员以作为引导, 但线下资料共享困难, 以至于对国家及总公司的政策响应缓慢。
3) 由于驻外项目组成员工作随意性较大, 公司管理人员对驻外人员管理效率低下, 驻外人员是否在岗, 工作进展等实时情况反馈不及时。
4) 企业管理人员、项目经理、项目成员、各部门工作人员之间沟通、协作困难。
5) 项目员工之间缺乏经验交流。
2.2 系统技术架构
通过本文依托的系统需求, 结合系统目标进行分析, 提出以Microsoft.NET平台为系统架构基础。.NET Framework是一种新的计算平台, 它简化了高度分布式Internet环境中的应用程序开发。.NET Framework具有两个主要组件[4]:公共语言运行库和.NET Framework类库。公共语言运行库是.NET Framework的基础。可以将运行库看作执行是管理代码的代理, 它提供核心服务, 而且还强制实施严格的类型安全以及可确保安全性和可靠性的其他形式的代码准确性[5]。.NET Framework的另一个主要组件是类库, 是一个综合性的面向对象的可重用类型集合。建立在.NET Framework之上的ASP.NET提供了一个Web应用程序模型, 并且包含使生成ASP Web应用程序变得简单的控件集和结构。ASP.NET包含封装公共HTML用户界面元素的控件集, 这些控件在Web服务器上运行, 并以HTML的形式将数据推送至用户界面上。在服务器上, 这些控件公开一个面向对象的编程模式, 为Web开发人员提供了面向对象的编程的丰富性。该系统引入Developer Express控件集合替代ASP.NET控件集, 并结合Java Script脚本语言为用户提供了更好的使用体验以及更为强大的数据提取和处理功能。
为遵循敏捷开发原则, 系统使用Visual Studio2012内集成的Team Foundation Server服务平台, 使系统开发人员进行源代码共享、代码审阅和数据收集, 为更加准确的实现系统功能做好铺垫。
文中系统架构主要基于以Microsoft Visual Studio2012.Net集成开发环境为开发工具。采用面向对象语言C#与Developer Express无缝结合, 为系统通信和相关服务提供支持, 以SQL Server为底层数据支持。为了开发的便利和数据安全的考虑, 系统采用多重数据备份和加密工作。搭建系统的操作系统采用了Windows Server2008 R2虚拟机的形式使用Hyper-V虚拟化技术存放在Windows Server2012服务器系统中。硬件方面采用了双机热备技术, 以保障数据安全性。
2.3 系统功能模块
该系统开发进程遵循敏捷开发原则, 参照针对客户的中期需求调研情况和无纸化办公、解决实际存在的问题为目标, 对主要功能采取逐个突破原则。据此, 将系统功能模块进行了有效划分, 包括门户网站和技术支持平台两个主要板块。技术支持系统以用户管理、项目管理、机构管理、岗位管理、权限管理为核心的系统架构体系, 以及技术支持、公司业务、人员动态、交流论坛四个主要功能以及个人信息、通知通告、证书管理、周月报汇总、证书汇总, 员工信息汇总等辅助功能。
2.3.1 系统架构
系统架构是一步步搭建并走向成熟的, 从页面和代码的分离以及数据结构基础设计到三层架构, 再到现在的多层, 每一步的发展, 使得程序逻辑更加清晰, 代码可复用性更强, 可读性更高, 可维护性更好。用户体验方面, 初期添加新的以部门为顶层的树状组织机构只能由开发人员更改XML数据文件进行添加, 到现在由客户完全自主配置。
2.3.2 开发过程
企业信息系统的开发有其自身的特点。一旦系统架构确定下来, 剩下的工作就是在这个架构体系下, 不断做重复工作实现所有规划的系统功能。
第66页图1为一个敏捷开发小组针对一个功能块的完全开发流程, 前四个角色共同组成开发团队, 最后一个角色是产品所有者。在前期需求调研完成的情况下, 项目经理制定一个灵活的开发计划, 计划的时间不宜太长, 否则因为客户需求的不断变化, 执行起来就会非常困难。开发计划交由需求分析员进行详细设计, 需求分析员需要画出具体图形或者制作静态网页将具体功能设计出初始形状, 在提交由项目经理进行评审。如评审通过, 则向开发组分配任务, 开发组开始功能。当开发组开发完结后交由测试组进行代码整合并集成测试;如评审未通过, 需求分析员需要对详细设计方案进行调整或重新设计。测试组测试无误, 则交由客户代表进行业务层面测试;如测试组发现BUG, 则开发人员需修改代码, 消除BUG。客户代表如测试通过, 则此功能开发完成;如果客户有异议则将问题提交至系统测试组, 再做重新调整。
2.3.3 功能开发实例
该系统开发的第一个主要功能就是技术支持。技术支持是一个信息共享平台, 针对该公司上级单位制定的体系文件、国内外法律法规文件、行业内的成功经验以及公司内部开展的培训课件等体量庞大的文件系统, 建立在线共享平台。
客户代表向项目经理提出要包括9大目录板块 (包括体系文件、法律法规、规范标准、培训课件、事故案例、公司业务、办公文件、知识分享及学习园地) , 每个大目录需要其做到其公司系统管理员可以自行配置, 区分上传文件 (包括下载和查看) 、下载文件 (包括查看) 、查看文件3种不同权限。项目经理制定了1个月的开发计划, 交由需求分析员进行详细设计, 由于在架构设计阶段已经将权限分配体系基础搭建完成, 需求分析员在2天以内设计出了技术支持的功能界面。得到项目经理认可后交由开发组进行开发, 开发组花9天时间将功能原型开发完成。
交测试组进行集成测试, 测试组在向开发组提交并确认了两次代码BUG后交客户代表测试。
当测试组将交由客户代表进行体验层测试时, 客户代表确认了展现形式, 但向某一目录下上传了50个文件, 该目录打开变慢, 继续上传了100个文件后, 技术支持功能打开变得异常缓慢, 并将问题反馈至开发团队测试组。测试组在经过同样测试后得到类似结果并将问题反馈至开发组, 开发组在进行单步调试以后提出两个结论:第一个是文件显示控件在提取大量文件时默认读取了文件数据字段导致变慢;第二个是功能加载将对应数据表中所有数据全部提取以致速度变慢。并就此确定了解决方案, 更改WEB展示风格, 提升了加载速度。
在此交由客户代表测试后, 客户代表提出, 由于公司业务拓展, 需要将第六部分公司业务从技术支持提取出来形成独立功能模块, 每项业务下包含有历年项目, 需将项目按年分类并按从新到旧的顺序排列。针对客户需求, 开发组将项目数据与技术支持数据进行了组合查询, 并在导航树设立虚拟的年份结点, 从而将公司业务功能完成。
如此不断迭代循环, 经过大概两个月的修改以后最终获得了客户代表的认可, 技术支持系统的功能开发就此完成。
2.4 系统应用评价
通过该系统的实施不仅解决了企业资源无法实时共享的问题, 而且帮助管理者提高了管理、监控和决策水平, 缩短了解决问题的时间。同时, 由于系统本身的B/S架构特性, 使得该公司所有员工随时随地都可感受到系统带来的便利。
3 敏捷开发经验总结
3.1 快速适应需求的变化
敏捷开发方法能够尽可能容易和有效地适应变化。尽管大多数人都同意反馈很重要, 但是他们忽视了一个重要的问题, 就是反馈结果往往代表的就是变化。敏捷开发能够驾驭这种变化, 因为推动变化比企图阻止变化更加有效。实际工作中, 开发团队和客户对于软件开发方面往往站在不同的角度, 理解容易产生分歧, 只有不断地沟通才能达到预定目标。在该项目中, 客户不断向开发团队反馈使用中的种种体验方面的问题, 而开发团队则积极响应客户诉求, 同客户一起讨论有效的解决方案。
3.2 降低软件开发风险
来自需求的风险是软件开发项目必须直面的问题。敏捷开发方法同时也要求至少有一位系统实际用户实时与开发团队讨论需求, 回答开发团队的问题, 对开发完成的功能进行确认。这是解决软件开发中需求不确定的切实有效的办法。假如客户只认为给出开发团队模糊需求就撒手不管, 造成的结果极有可能是返工重做或大面积修改, 这也就为软件失败埋下伏笔。
3.3 形成明确的代码规范
敏捷开发对于编程规范的要求很高, 通过制定严格的代码规范来进行团队内部沟通。一个明确的代码规范不仅可以节约时间, 而且可以大幅提升代码的复用性, 同时还可以提升软件品质。软件开发人员的编程习惯不同, 是软件项目失败的重要原因, 彼此短时间读不懂对方代码, 就无从下手, 从而造成大量时间浪费。项目开发团队由项目技术负责人搭建系统架构, 指定代码规范, 经过短时间磨合, 所有成员形成默契, 开发效率不断提高。
参考文献
[1]柴益萍, 龚报钧.中国企业管理发展之路[J].信息管理系统, 1999 (2) :14-15.
[2]Robert C.Mahaney, Albert L.Lederer.Information system projects project management:anagency theory interpretation[J].The Journal of System and Software, 2003 (68) :1-9.
[3]Robert C.Martin.Aglic Software Development Principles, Patterns, and Practices[M].北京:中国电力出版社, 2003.
[4]东方人华.微软Visual Studio.NET程序员开发系列丛书C#编程技术[M].北京:清华大学出版社, 2001.
敏捷开发在政府机关的应用探讨 篇8
1.1 敏捷开发的出现
传统的软件开发方法定义的过程往往大而笨重, 降低了软件开发团队的开发效率和响应变化能力, 形成了过程膨胀即“过程泥潭”。2001年初, 由于看到许多公司的软件开发团队陷入了过程泥潭, 一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则:个体和交互胜过过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划, 这就是“敏捷宣言”。
敏捷开发的方法很多, 有极限编程、Scrum、特征驱动开发、自适应软件开发等。敏捷开发可以应对客户快速变化的需求, 它强调以人为核心、采用迭代的方式、循序渐进地开发软件。在敏捷开发中, 软件项目被切分成多个子项目, 各个子项目的成果都经过测试并可以随时投入运行。敏捷开发要求项目团队全体成员之间形成更加有效的合作关系, 使其灵活性更高, 以适应不断变化的需求。
1.2 敏捷开发的特点
与传统的软件开发方法相比, 敏捷开发主要有两个特点。
1.2.1 敏捷开发是面向人的而不是面向过程的
敏捷开发认为, 人是软件开发中最重要的因素, 而且人工作的环境很复杂。它强调软件开发应当是一项令人愉悦的活动, 因此更加注重调动人的积极性、主动性和创造性, 并培养人在工作中的自豪感。敏捷开发的理念就是信任项目团队能够很好地完成任务, 所有的管理都是围绕这个理念展开的。敏捷开发的目的是建立起一个项目团队 (包括客户、需求分析人员、设计人员、开发人员、测试人员等多种角色) 全员参与到软件开发中。只有这样, 软件开发流程才能在项目团队中得到最广泛的接受。敏捷开发还要求开发人员在技术上进行自主决策, 因为开发人员是最了解什么样的技术是需要或不需要的。
1.2.2 敏捷开发是“主动适应的”而不是“预先设定的”
传统的软件开发方法试图对一个软件项目在很长的时间跨度内做出详细的计划, 并形成详细的文档, 然后依照计划进行开发。这类方法在计划制定完成后往往拒绝变化, 后期的需求变化将会花费极大的代价。敏捷开发则乐于迎接变化, 其实, 它的目的就是成为更适应变化的软件开发流程。
据统计, 很多软件产品提供的功能中, 客户常用的功能只占20%左右, 其他大部分功能是客户很少使用甚至基本不用的。在这种情况下, 采用传统的软件开发方法所设计出的功能, 其实很多是不必要的, 也将浪费很多资源。敏捷开发则要求客户始终参与整个开发过程, 这使得项目团队可以不断地获得客户反馈, 不断地适应需求的变更, 从而使最终的产品充分符合客户的要求, 也极大地减少了资源的浪费。
2 敏捷开发在政府机关的应用探讨
由于条件所限, 笔者所在的政府机关从事软件开发的技术人员较少且大多不是专职, 往往身兼系统运维、科技管理等其他工作, 因此政府机关的软件开发往往具有团队规模微型化、开发时间碎片化、项目文档简单化等特点, 瀑布模型、RUP等传统的软件开发方法已不能适应政府单位软件开发的需要。笔者所在的小型开发团队近年来对敏捷开发方法有选择地进行了应用, 在测试驱动开发、小版本发布、任务投票等方面取得了一些经验。
2.1 测试驱动开发
作为敏捷开发最重要的组成部分, 测试驱动开发要求实现的每一个业务功能都是从测试开始。开发人员首先对需求进行分析, 将需求分解为一个个用户故事, 然后根据用户故事, 从需求的角度来编写测试代码 (主要是单元测试、功能测试) , 最后依据测试代码来编写业务功能代码。
如果没有测试代码, 就不能编写业务功能代码。先写测试代码, 能够让开发人员明确目标, 就是业务功能代码通过测试。当然通过测试并不是结束, 测试覆盖率分析工具还可以直观地显示测试未覆盖到的业务功能代码。在测试没有100%覆盖业务功能代码之前, 尽快完善测试代码显得十分必要。
测试驱动开发还方便了代码的重构。重构是在不改变系统外部行为的前提下, 对程序代码的内部结构进行整理优化, 使得代码尽量简单、易读、可扩展。值得注意的是, 敏捷开发中的重构对代码的每一次改变要尽可能小, 并用单元测试来验证重构是否引起冲突, 并且要求不仅对业务功能代码进行重构, 如果测试代码中有重复, 也要对它进行重构。
刚开始推行测试驱动开发时, 我们的开发人员觉得花费了不少时间在编写测试代码上, 项目开发进度不是很快, 还不如多花些时间在编写业务功能代码上。不过随着项目开发的不断深入, 开发人员发现如果一个业务功能的测试代码写的比较完善, 业务功能代码往往不容易出现缺陷, 开发人员花在缺陷修复上面的时间比较少, 在对代码进行重构时也很容易验证。
2.2 小版本发布
在敏捷开发中, 不会出现拿到客户需求以后就闭门造车, 直到项目开发完成了绝大部分甚至最后才将产品交付给客户的情况, 而是多次发布小版本产品。这样, 客户每隔一段时间就会拿到发布的小版本产品进行试用, 项目团队就可以从客户那里得到更多的反馈来改进产品。
在推行小版本发布后, 很多时候我们发现客户提出的需求往往不那么全面, 一些新的需求往往是在试用发布的小版本产品后才反馈给项目团队。因此, 小版本发布在一定程度上有利于发现新的需求。而对于开发人员, 正因为多次发布小版本产品, 每一个版本新增的功能简单清晰, 不需要很复杂的设计, 也在很大程度上简化了设计。
2.3 任务投票
在敏捷开发中, 每次迭代都要求项目团队在一次迭代期间 (一般两到四周) 内, 完成本次迭代计划里的任务。此时, 选择哪些任务加入本次迭代计划需要项目团队的全体成员投票决定。
在投票会议上, 项目管理人员列出下一步需要完成的任务, 要求项目团队的每个成员对每个任务完成所需要的时间进行现场投票。如果出现不同成员投票结果相差很大的情况, 项目管理人员要求相关成员说出理由, 再由全体成员商量决定该任务完成所需要的时间。在确定每个任务完成所需要的时间后, 项目管理人员根据本次迭代的截止时间要求, 选择合适的任务加入本次迭代计划, 保证迭代计划里的所有任务完成需要的总时间不能超过项目团队全体成员可用于开发的时间。
在推行任务投票时, 我们的开发人员对于一个任务完成所需要的时间进行投票, 往往会出现投票结果相差很大的情况。这主要是因为每个开发人员的经验和能力存在一定的差异, 对一个任务完成所需要的时间会从自己的角度做出估计。敏捷开发要求, 不管是哪个开发人员都要尽可能在项目团队全体成员投票决定的时间内完成该任务。在完成任务的过程中, 开发人员充分调动了自身的积极性、主动性和创造性, 也培养了在工作中的成就感和自豪感。
3需要改进的地方