迭代软件开发方法如敏捷的基于度量的质量评估

K. Jinzenji, T. Hoshino, L. Williams, Kenji Takahashi
{"title":"迭代软件开发方法如敏捷的基于度量的质量评估","authors":"K. Jinzenji, T. Hoshino, L. Williams, Kenji Takahashi","doi":"10.1109/ISSREW.2012.40","DOIUrl":null,"url":null,"abstract":"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 software iteratively developed only by defining process structure, without obtaining metrics.","PeriodicalId":220698,"journal":{"name":"ISSRE Workshops","volume":"2012 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2012-11-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"7","resultStr":"{\"title\":\"Metric-Based Quality Evaluations for Iterative Software Development Approaches Like Agile\",\"authors\":\"K. Jinzenji, T. Hoshino, L. Williams, Kenji Takahashi\",\"doi\":\"10.1109/ISSREW.2012.40\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"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 software iteratively developed only by defining process structure, without obtaining metrics.\",\"PeriodicalId\":220698,\"journal\":{\"name\":\"ISSRE Workshops\",\"volume\":\"2012 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2012-11-27\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"7\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"ISSRE Workshops\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1109/ISSREW.2012.40\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"ISSRE Workshops","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/ISSREW.2012.40","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 7

摘要

向市场快速发布软件的需求正在增加。我们注意到像瀑布这样的连续软件开发的局限性,因为它需要花费太多的时间来观察移动的软件并获得反馈。我们正在考虑转换和采用像敏捷一样的迭代开发。然而,在迭代开发中存在两个主要问题。首先,没有定义过程结构,因此我们无法验证软件是否以正确的方式制作。其次,在验收测试中通过匹配用户需求来评估软件质量,因此我们不能从客观的角度使用度量来确定软件质量,而只能从主观的角度来确定。这两个问题是阻碍传统开发向迭代开发转变的障碍。在本报告中,我们定义了软件开发过程,并提出了迭代方法中的质量度量评估方案。首先,我们将迭代开发分为纯迭代和混合迭代两种类型。然后,检测四个重要参数,如冲刺期、发布期、集成类型和开发类型,以定义过程结构。顺序开发的典型度量可以在迭代开发中使用。但是,迭代过程中的度量必须重新评估,因为代码在迭代过程中由于重构、需求演变等原因而不稳定。为此,我们提出了指标重评价方案。我们还提供了示例软件的结果,包括过程结构、重新评估的质量度量、质量控制图和故障收敛。顺便说一下,我们还有一些顾虑。获取度量会给程序员带来额外的工作,因此这是对敏捷性的权衡。我们对故障收敛的假设在我们的示例软件中似乎是合理的,但是,我们必须收集更多的示例来更新我们的假设。在将来,我们必须检查更多的例子,以证明仅通过定义过程结构而不获得度量来迭代开发的软件质量。
本文章由计算机程序翻译,如有差异,请以英文原文为准。
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 software iteratively developed only by defining process structure, without obtaining metrics.
求助全文
通过发布文献求助,成功后即可免费获取论文全文。 去求助
来源期刊
自引率
0.00%
发文量
0
×
引用
GB/T 7714-2015
复制
MLA
复制
APA
复制
导出至
BibTeX EndNote RefMan NoteFirst NoteExpress
×
提示
您的信息不完整,为了账户安全,请先补充。
现在去补充
×
提示
您因"违规操作"
具体请查看互助需知
我知道了
×
提示
确定
请完成安全验证×
copy
已复制链接
快去分享给好友吧!
我知道了
右上角分享
点击右上角分享
0
联系我们:info@booksci.cn Book学术提供免费学术资源搜索服务,方便国内外学者检索中英文文献。致力于提供最便捷和优质的服务体验。 Copyright © 2023 布克学术 All rights reserved.
京ICP备2023020795号-1
ghs 京公网安备 11010802042870号
Book学术文献互助
Book学术文献互助群
群 号:604180095
Book学术官方微信