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}
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.