首页> 外文会议>23rd IEEE International Symposium on Software Reliability Engineering Workshops. >Metric-Based Quality Evaluations for Iterative Software Development Approaches Like Agile
【24h】

Metric-Based Quality Evaluations for Iterative Software Development Approaches Like Agile

机译:敏捷等迭代软件开发方法的基于度量的质量评估

获取原文
获取原文并翻译 | 示例

摘要

The needs for rapid software release to the market are increasing. We notice the limitation for sequential software development like Waterfall, because it takes too much time to see the moving software and get feedback. We are thinking to transform and adopt iterative development like Agile. However, there are two major issues on iterative development. First, the process structure is not be defined, so that we can't verify if the software was made in the right way. Secondary, the software quality is evaluated in the acceptance testing by matching the user requirements, so that we can't confirm software quality from the objective viewpoint using metrics but only from the subjective one. These two issues are obstacles to transform to iterative development from traditional one. In this presentaion, we defined software development process and propose quality metrics evaluation scheme in iterative methodology. First, we categorize the iterative development into two types, pure-iterative and hybrid. Then, important four parameters, such as the sprint term, the release term, integration type and development type are detected to define the process structure. Typical metrics for sequential development can be used in iterative development. But, the metrics in the iteration process must be re-evaluated, because the code is not stable during the iteration process due to refactoring, requirement evolution and so on. So we proposed the metrics re-evaluation scheme. We also provide the example software's result that includes process structure, re-evaluated quality metrics, quality control chart and fault convergence. By the way, we still have a couple of concerns. Obtaining metrics causes the extra work for programmers, so it is trade-off of agility. Our assumption for fault convergence is seems to be justified in our example software, but, we have to collect more example and brush up our assumption. In the future, we have to examine more examples to justify the quality of sof- ware iteratively developed only by defining process structure, without obtaining metrics.
机译:快速向市场发布软件的需求正在增长。我们注意到像Waterfall之类的顺序软件开发的局限性,因为要花费太多时间才能看到正在运行的软件并获得反馈。我们正在考虑转变并采用像敏捷这样的迭代开发。但是,在迭代开发中存在两个主要问题。首先,没有定义流程结构,因此我们无法验证软件的制作方式是否正确。其次,通过匹配用户需求在验收测试中评估软件质量,因此我们不能从客观的角度使用度量标准来确认软件质量,而只能从主观的角度来确认。这两个问题是从传统的过渡到迭代发展的障碍。在本文中,我们定义了软件开发过程,并提出了以迭代方法论提出的质量指标评估方案。首先,我们将迭代开发分为两种类型:纯迭代和混合。然后,检测重要的四个参数,如冲刺期,发布期,集成类型和开发类型,以定义过程结构。顺序开发的典型指标可以用于迭代开发。但是,必须重新评估迭代过程中的指标,因为由于重构,需求演变等原因,代码在迭代过程中不稳定。因此,我们提出了指标重新评估方案。我们还提供示例软件的结果,包括过程结构,重新评估的质量指标,质量控制图和故障收敛。顺便说一句,我们还有两个问题。获取指标会给程序员带来额外的工作,因此这是灵活性的折衷。在我们的示例软件中,我们对于故障收敛的假设似乎是合理的,但是,我们必须收集更多的示例并完善我们的假设。将来,我们必须检查更多示例,以证明仅通过定义流程结构而不获得指标即可迭代开发的软件质量。

著录项

相似文献

  • 外文文献
  • 中文文献
  • 专利
获取原文

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号