敏捷开发下的软件架构设计与持续优化
2015-05-21 06:17
337 查看
过往的软件开发, 往往都是由架构师将他对产品的理解,利用 UML
来体现软件的架构设计。
这种方式的问题是:因缺乏使用者与团队成员间的互动参与,使得对外并未能完整的将使用者需求,映射到软件架构中;
而对内所提供的软件架构设计文档,
对实际开发的工作,
指导意义并不大(因为,厚重的架构设计文档,便如老太婆的裹脚布般;又臭又长)。更严重的问题是,由于架构设计耗费太长的时间,如此再加上开发、测试的时间,团队往往会太晚才会发现软件架构上的重大缺陷。而由于太晚才发现软件架构上的缺陷,所以,软件架构上若需做优化,则往往需耗费惊人的人力与时间成本。
敏捷开发, 经由可视化、轻量级的 "场景树", 使得使用者与团队成员间可共同的协作, 共同的识别:
User Story 中的活动
活动后所产生的实体对象
验证实体对象的纬度
识别描述实体对象的价值对象
整合所有 User Stories 的 User Story 地图
所以, 开发人员可根据 “场景树”与 User Story
地图,轻易且高效的找到单元测试点并设计出有效的测试用例与测试数据。而使开发人员能在最短的时间内,将软件架构直接转换为测试代码与产品代码。使开发人员能在最短的时间内,经由单元测试的
“黑盒测试”,发现到软件架构上的缺陷。
另外,SonarQube也提供了一可持续优化产品代码(架构)的平台。
“所以,在敏捷开发中,我们真的找到了一个有效的方法,去构造一高效、健康的产品开发的生态系统;经由此生态系统,使用者与团队成员将可高效的协作,共同的设计软件架构,并在最短的时间内,发现软件架构上的缺陷并持续的优化软件架构。”
欢迎你也来试试。
来体现软件的架构设计。
这种方式的问题是:因缺乏使用者与团队成员间的互动参与,使得对外并未能完整的将使用者需求,映射到软件架构中;
而对内所提供的软件架构设计文档,
对实际开发的工作,
指导意义并不大(因为,厚重的架构设计文档,便如老太婆的裹脚布般;又臭又长)。更严重的问题是,由于架构设计耗费太长的时间,如此再加上开发、测试的时间,团队往往会太晚才会发现软件架构上的重大缺陷。而由于太晚才发现软件架构上的缺陷,所以,软件架构上若需做优化,则往往需耗费惊人的人力与时间成本。
敏捷开发, 经由可视化、轻量级的 "场景树", 使得使用者与团队成员间可共同的协作, 共同的识别:
User Story 中的活动
活动后所产生的实体对象
验证实体对象的纬度
识别描述实体对象的价值对象
整合所有 User Stories 的 User Story 地图
所以, 开发人员可根据 “场景树”与 User Story
地图,轻易且高效的找到单元测试点并设计出有效的测试用例与测试数据。而使开发人员能在最短的时间内,将软件架构直接转换为测试代码与产品代码。使开发人员能在最短的时间内,经由单元测试的
“黑盒测试”,发现到软件架构上的缺陷。
另外,SonarQube也提供了一可持续优化产品代码(架构)的平台。
“所以,在敏捷开发中,我们真的找到了一个有效的方法,去构造一高效、健康的产品开发的生态系统;经由此生态系统,使用者与团队成员将可高效的协作,共同的设计软件架构,并在最短的时间内,发现软件架构上的缺陷并持续的优化软件架构。”
欢迎你也来试试。
相关文章推荐
- 精益敏捷开发下的软件架构设计
- web开发,是个非常敏捷的过程,变化随时都在产生,用户需求千变万化,许多方面偶然性非常高,较之软件开发,希望用一个架构规划以后的所有设计,是不现实的
- 敏捷开发下, 如何将需求分析,架构(软件)设计,开发与测试,一气呵成式的结合且高效的完成 ?
- 敏捷开发中如何持续集成和优化软件性能
- 设计、仿真、工艺、加工、优化、开发交流 · 行业软件、二次开发、优化技术
- 【转载】"变化"、"复用"、"抽象"、"稳定" 影响着软件设计模式,架构,开发方法
- 从《敏捷软件开发原则、模式与实践》看待现当前开发团队现状(持续更新)
- 企业管理软件开发架构之七 Object Control设计与运用
- 敏捷开发智慧敏捷系列之三:做不做架构设计?
- 敏捷开发智慧敏捷系列之三:做不做架构设计?
- 如何设计一个软件的架构,使它可以提供二次开发的功能?
- 演进式架构设计在敏捷开发中的使用
- ERP软件开发架构之二 数据访问层设计
- 敏捷开发智慧敏捷系列之三:做不做架构设计?
- 敏捷开发中的架构设计
- 敏捷软件开发读书笔记2——面向对象的设计原则
- 架构设计--仅是软件开发之第二大影响力?! (原文最终修订于2006-07-01 凌晨03:20:31)
- 敏捷开发不利于架构设计?
- 匠心软件谈APP软件开发中架构优化的重要性
- 敏捷团队高效的完成软件架构设计