DOCSLIB.ORG

Framework of Quality Measurement in CASE Tool Based Software Development

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Framework of Quality Measurement in CASE Tool Based Software Development Framework of Quality Measurement in CASE Tool Based Software Development Dissertation zur Erlangung des akademischen Grades Doktoringenieur (Dr.‐Ing.) angenommen durch die Fakultät für Informatik der Otto‐von‐Guericke‐Universität Magdeburg von: M.Sc. in DKE Hashem Yazbek geb. am 17.10.1974 in Homs, Syrien Gutachter: Prof. Dr.‐Ing. habil. Reiner Dumke Prof. Dr.‐Ing. habil. Georg Paul Prof. Dr. Juan José Cuadrado‐Gallego Magdeburg, den 28.09.2010 Contents Acknowledgement iii List of Figures v List of Tables vii List of Abbreviations ix 1 Introduction 1 1.1 Motivation 1 1.2 Research Questions 1 1.3 Thesis Structure 2 2 Software Process Descriptions and Models 3 2.1 Software Process Characteristics 3 2.2 Software Process Modelling 8 2.3 Software Process Improvement and Evaluation Approaches 17 2.3.1 General Maturity Models 18 2.3.2 The CMMI Approach 20 2.3.3 The SPICE Approach 25 2.3.4 The Six Sigma Approach 26 2.3.5 The ITIL Approach 27 2.3.6 Further Software Process Evaluation 29 2.4 Summary 31 3 CASE‐Based Software Development 33 3.1 CASE Tools 33 3.2 CASE‐Based Processes 36 3.3 Summary 40 4 Software Process Measurement and Evaluation 41 4.1 Software Process Indicators and Criteria 42 4.2 Software Process Laws 45 4.3 Software Process Principles and Rules 47 4.4 Software Process Rules of Thumb 58 4.5 Software Process Experiments 59 4.6 Software Process Case Studies 63 4.7 Software Process Metrics and Measures 64 4.8 Process Metrics Repositories 76 i 4.9 Process Measurement Levels 84 4.9.1 Software Process Establishment by Indicators and Criteria 85 4.9.2 Software Process Improvement Modelling by Laws, Process Principles and Rules 86 4.9.3 Empirical Software Process Modelling by Rules of Thumb, Process Experiments and Case Studies 87 4.9.4 Software Process Measurement Model by Process Metrics 88 4.9.5 Software Process Management Models by Process Improvement Approaches 89 4.10 Summary 91 5 Framework of Quality Assurance Using CASE Tools 93 5.1 Framework Principles: CASE Tool Based Software Processes 93 5.1.1 General Principles 93 5.1.2 CASE‐Based Orientation 94 5.1.3 CASE Tool Based Process Evaluation 95 5.2 Framework Kernel: Quality Measurement and Improvement 96 5.2.1 Software Measurement Components 96 5.2.2 Software Measurement Process Evaluation 103 5.2.3 Software Measurement Improvements 106 5.3 Framework Steps: Phases and Contents 107 5.3.1 Analyzing the CASE Tool Based Process Situation 107 5.3.2 Planning the CASE Tool Based Process Improvements 111 5.3.3 Implementing the CASE Tool Based Process Improvements 112 5.4 Summary 113 6 Framework Application and Validation 115 6.1 Chosen CASE Tool Situation 115 6.2 CASE‐Based Test Scenario 116 6.3 Appraisal of CASE Tool Evaluation Results 116 6.3.1 Together Measurement Level 116 6.3.2 Metrication in Visual Studio 118 6.3.3 Measurement in Enterprise Architect 120 6.3.4 Metrics Eclipse Plug‐in 122 6.3.5 Metrics One Measurement Level 123 6.3.6 Metrication in Embarcadero RAD Studio 2010 125 6.4 Evaluation of CASE‐Based Quality Assurance 126 6.5 Summary 129 7 Conclusions and Future Work 131 References 133 ii Acknowledgement I would like to thank my supervisor, Prof. Dr. Reiner Dumke for the help throughout this work. Especially his patience and advice that he provided over the years. A special thanks goes out to Prof. Georg Paul and Prof. Juan J. Cuadrado‐Gallego for their efforts in reviewing and providing their expert opinions on the thesis at hand. Magdeburg, September 2010 Hashem Yazbek iii iv List of Figures Figure 1: Managerial foundations of software engineering 3 Figure 2: Context diagram for software process models 4 Figure 3: Activities supporting by process models 6 Figure 4: The software process improvement cycle by Lepasaar et al. 8 Figure 5: Roles of technology in software applications or products 10 Figure 6: Components of the software product 11 Figure 7: Dimensions of the software engineering 13 Figure 8: Components of the software process 13 Figure 9: Components of the software development resources 15 Figure 10: Components of the software maintenance 16 Figure 11: Components of the software product application 17 Figure 12: Dependencies of software process evaluation methods and standards 18 Figure 13: Overview of chosen process maturity and improvement models 19 Figure 14: The CMMI model components 21 Figure 15: The CMMI project management process areas 22 Figure 16: The SPICE process assessment model 26 Figure 17: Basic characteristics of the Six Sigma approach 27 Figure 18: The relationship between the service standards and ITIL 28 Figure 19: The “What to Build” pattern for product line project management 30 Figure 20: The PSP approach 31 Figure 21: Simplified CASE tool architecture 33 Figure 22: Eclipse tool GUI architecture 34 Figure 23: Four essential types of CASE tool integration 35 Figure 24: CASE tools in the dimensions of the software engineering 35 Figure 25: CASE and software process evaluation methods and standards 37 Figure 26: Overview of chosen process maturity and improvement models 37 Figure 27: A model showing the stages of measurement that organizations typically go through 44 Figure 28: Intentions of chosen software engineering laws 47 Figure 29: User’s cognitive structure of software evaluation by Wong and Jeffery 48 Figure 30: The LIPE activities and product flow among them by Zettel et al. 48 Figure 31: Metrics depends on stakeholder needs 49 Figure 32: The enterprise project management model 54 Figure 33: Schema of a IT Balanced Scorecard 55 Figure 34: Project definition, priorities and incremental development 58 Figure 35: Function Points per hour in different IT domains 59 Figure 36: The history of function point methods development 69 Figure 37: Layers of metrics data bases 77 Figure 38: Distribution by business domain of ISBSG projects that provided defect data in percentage 80 Figure 39: The ISBSG repository using in the Web 81 Figure 40: The concept of Basili’s Experience Factory 82 Figure 41: The measurement data warehouse approach 82 Figure 42: The mediated measurement repository 83 Figure 43: The service bus‐oriented measurement repository 83 Figure 44: A holistic presentation of the software process involvements 84 v Figure 45: The SPE based process network 85 Figure 46: The PIM based process related semantic network 86 Figure 47: An EMP based process related semantic network 87 Figure 48: A SMP based process related semantic network 88 Figure 49: The different process semantic network levels 90 Figure 50: metrics tools integrated into CASE‐Tool 112 Figure 51: Together metrics dialog 117 Figure 52: Visual Studio Code Metrics Results Window 118 Figure 53: Enterprise Architect Use Case Metrics dialog 120 Figure 54: Eclipse metrics view 123 Figure 55: Metrics One Class metrics 124 Figure 56: Kiviat charts in RAD Studio 125 vi List of Tables Table 1: Chosen maturity models 19 Table 2: Characteristics of different sigma levels 26 Table 3: Software Quality Drivers 44 Table 4: Expenditures by activity for a conventional software project 59 Table 5: Percentage of respondents in a European survey of management practices 63 Table 6: Delivered defects per Function Points 63 Table 7: Percentages of process activities in different kinds of projects 64 Table 8: Percentage of Organizations having QA and metrics efforts in place Based on a worldwide survey 64 Table 9: Attributes of the ISBSG Benchmarking Data CD Release 8 80 Table 10: The supported metrics in Metrics Eclipse Plug‐in 122 Table 11: Overview of metrics concept 127 vii viii List of Abbreviations AOP Aspect‐Oriented Programming ANSI American National Standards Institute AOSE Agent‐Oriented Software Engineering API Application Programming Interface ASG Allen Systems Group BPMN Business Process Modeling Notation BPEL Business Process Execution Language CASE Computer‐Aided Software Engineering CAME Computer Assisted software Measurement and Evaluation CBSE Component‐Based Software Engineering CBO Coupling Between Objects CFP Cosmic Function Point CMM Capability Maturity Model CMMI Capability Maturity Model Integration COCOMO Constructive Cost Model COM Component Object Model CORBA Common Object Request Broker Architecture COSMIC the Common Software Measurement International Consortium COTS Commercial, Off‐The‐Shelf CSV Comma‐Separated Values CWM Common Warehouse Metamodel C&K Chidamber and Kemerer DACS Data & Analysis Center for Software ix DAML DARPA Agent Markup Language DBMS Database Management System DBS Database System DCE Distributed Computing Environment DDL Data Definition Language DML Data Manipulating Language DIT Depth of Inheritance Tree DPDS DACS Productivity Center DTD Document Type Definition EAI Enterprise Application Integration EBD Event‐Based Design EF Experience Factory ERP Enterprise Resource Planning ETL Extract Transform Load FOD Feature‐Oriented Design FP Function Point GQM Goal‐Question‐Metric GUI Graphical User Interface HTML Hyper Text Markup Language ICASE Integrated Computer Aided Software Engineering ICT Information and Communication Technology IDL Interactive Data Language IEC International Electrotechnical Commission IEEE Institute of Electrical & Electronics Engineers x IFPUG International Function Point Users Group IPD‐CMM Integrated Product Development CMM IPSE Integrated Project Support Environment ISBSG International Software Benchmarking Standard Group ISO International Standardization Organization IT Information Technology J2EE Java Platform, Enterprise Edition KDSI Kilo Delivered Source Instructions LCOM Lack of Cohesion in Methods LOC Lines
Load more

Recommended publications
  • Measuring the Software Size of Sliced V-Model Projects
    2014 Joint Conference of the International Workshop on Software Measurement and the International Conference on Software Process and Product Measurement Measuring the Software Size of Sliced V-model Projects Andreas Deuter PHOENIX CONTACT Electronics GmbH Gregor Engels Dringenauer Str. 30 University of Paderborn 31812 Bad Pyrmont, Germany Zukunftsmeile 1 Email: [email protected] 33102 Paderborn, Germany Email: [email protected] Abstract—Companies expect higher productivity of their soft- But, the “manufacturing” of software within the standard ware teams when introducing new software development methods. production process is just a very short process when bringing Productivity is commonly understood as the ratio of output the binaries of the software to the device. This process is hardly created and resources consumed. Whereas the measurement of to optimize and does not reflect the “production of software” the resources consumed is rather straightforward, there are at all. The creation of the software is namely done in the several definitions for counting the output of a software de- developing teams by applying typical software engineering velopment. Source code-based metrics create a set of valuable figures direct from the heart of the software - the code. However, methods. However, to keep up with the high demands on depending on the chosen process model software developers and implementing new functionality (e.g. for PLC) the software testers produce also a fair amount of documentation. Up to development process within these companies must improve. now this output remains uncounted leading to an incomplete Therefore, they start to analyze their software processes in view on the development output. This article addresses this open detail and to identify productivity drivers.
    [Show full text]
  • Software Error Analysis Technology
    NIST Special Publication 500-209 Computer Systems Software Error Analysis Technology U.S. DEPARTMENT OF COMMERCE Wendy W. Peng Technology Administration Dolores R. Wallace National Institute of Standards and Technology NAT L INST. OF ST4ND & TECH R I.C. NISI PUBLICATIONS A111D3 TTSTll ^QC ' 100 .U57 //500-209 1993 7he National Institute of Standards and Technology was established in 1988 by Congress to "assist industry in the development of technology . needed to improve product quality, to modernize processes, to reliability . manufacturing ensure product and to facilitate rapid commercialization . , of products based on new scientific discoveries." NIST, originally founded as the National Bureau of Standards in 1901, works to strengthen U.S. industry's competitiveness; advance science and engineering; and improve public health, safety, and the environment. One of the agency's basic functions is to develop, maintain, and retain custody of the national standards of measurement, and provide the means and methods for comparing standards used in science, engineering, manufacturing, commerce, industry, and education with the standards adopted or recognized by the Federal Government. As an agency of the U.S. Commerce Department's Technology Administration, NIST conducts basic and applied research in the physical sciences and engineering and performs related services. The Institute does generic and precompetitive work on new and advanced technologies. NIST's research facilities are located at Gaithersburg, MD 20899, and at Boulder, CO 80303.
    [Show full text]
  • Software Metrics: Successes, Failures and New Directions
    Software Metrics: Successes, Failures and New Directions Norman E Fenton Centre for Software Reliability Agena Ltd City University 11 Main Street Northampton Square Caldecote London EC1V OHB Cambridge CB3 7NU United Kingdom United Kingdom Tel: 44 171 477 8425 Tel 44 1223 263753 / 44 181 530 5981 Fax: 44 171 477 8585 Fax: 01223 263899 [email protected] [email protected] www.csr.city.ac.uk/people/norman.fenton/ www.agena.co.uk Abstract The history of software metrics is almost as old as the history of software engineering. Yet, the extensive research and literature on the subject has had little impact on industrial practice. This is worrying given that the major rationale for using metrics is to improve the software engineering decision making process from a managerial and technical perspective. Industrial metrics activity is invariably based around metrics that have been around for nearly 30 years (notably Lines of Code or similar size counts, and defects counts). While such metrics can be considered as massively successful given their popularity, their limitations are well known, and mis-applications are still common. The major problem is in using such metrics in isolation. We argue that it is possible to provide genuinely improved management decision support systems based on such simplistic metrics, but only by adopting a less isolationist approach. Specifically, we feel it is important to explicitly model: a) cause and effect relationships and b) uncertainty and combination of evidence. Our approach uses Bayesian Belief nets which are increasingly seen as the best means of handling decision-making under uncertainty.
    [Show full text]
  • Software Measurement: a Necessary Scientific Basis Norman Fenton
    IEEE TRANSACTIONS ON SOFTWARE ENGINEERING. VOL. 20, NO. 3, MARCH I994 I99 Software Measurement: A Necessary Scientific Basis Norman Fenton Abstruct- Software measurement, like measurement in any 11. MEASUREMENTFUNDAMENTALS other discipline, must adhere to the science of measurement if it is to gain widespread acceptance and validity. The observation In this section, we provide a summary of the key concepts of some very simple, but fundamental, principles of measurement from the science of measurement which are relevant to soft- can have an extremely beneficial effect on the subject. Measure- ware metrics. First, we define the fundamental notions (which ment theory is used to highlight both weaknesses and strengths of are generally not well understood) and then we summarise the software metrics work, including work on metrics validation. We representational theory of measurement. Finally, we explain identify a problem with the well-known Weyuker properties, but also show that a criticism of these properties by Cherniavsky and how this leads inevitably to a goal-oriented approach. Smith is invalid. We show that the search for general software complexity measures is doomed to failure. However, the theory A. What is Measurement? does help us to define and validate measures of specific complexity attributes. Above all, we are able to view software measurement Measurement is defined as the process by which numbers or in a very wide perspective, rationalising and relating its many symbols are assigned to attributes of entities in the real world diverse activities. in such a way as to describe them according to clearly defined Index Terms-Software measurement, empirical studies, met- rules [ 131, [36].
    [Show full text]
  • Ssfm BPG 1: Validation of Software in Measurement Systems
    NPL Report DEM-ES 014 Software Support for Metrology Best Practice Guide No. 1 Validation of Software in Measurement Systems Brian Wichmann, Graeme Parkin and Robin Barker NOT RESTRICTED January 2007 National Physical Laboratory Hampton Road Teddington Middlesex United Kingdom TW11 0LW Switchboard 020 8977 3222 NPL Helpline 020 8943 6880 Fax 020 8943 6458 www.npl.co.uk Software Support for Metrology Best Practice Guide No. 1 Validation of Software in Measurement Systems Brian Wichmann with Graeme Parkin and Robin Barker Mathematics and Scientific Computing Group January 2007 ABSTRACT The increasing use of software within measurement systems implies that the validation of such software must be considered. This Guide addresses the validation both from the perspective of the user and the supplier. The complete Guide consists of a Management Overview and a Technical Application together with consideration of its use within safety systems. Version 2.2 c Crown copyright 2007 Reproduced with the permission of the Controller of HMSO and Queen’s Printer for Scotland ISSN 1744–0475 National Physical Laboratory, Hampton Road, Teddington, Middlesex, United Kingdom TW11 0LW Extracts from this guide may be reproduced provided the source is acknowledged and the extract is not taken out of context We gratefully acknowledge the financial support of the UK Department of Trade and Industry (National Measurement System Directorate) Approved on behalf of the Managing Director, NPL by Jonathan Williams, Knowledge Leader for the Electrical and Software team Preface The use of software in measurement systems has dramatically increased in the last few years, making many devices easier to use, more reliable and more accurate.
    [Show full text]
  • Objectives and Context of Software Measurement, Analysis, and Control Michael A
    Objectives and Context of Software Measurement, Analysis, and Control Michael A. Cusumano Massachusetts Institute of Technology Sloan School WP#3471-92/BPS October 8, 1992 Objectives and Context of Software Measurement, Analysis and Control Michael A. Cusumano Sloan School of Management Massachusetts Institute of Technology Cambridge, Massachusetts USA 02142 Abstract This paper focuses on the what and why of measurement in software development, and the impact of the context of the development organization or of specific projects on approaches to measurement, analysis, and control. It also presents observations on contextual issues based on studies of the major Japanese software producers. 1 Introduction This paper focuses on the what and why of measurement in software development, and the impact of the context of the development organization or of specific projects on approaches to measurement, analysis, and control. It begins by discussing three basic questions: (1) Why do we measure? (2) What is it we want to know? And (3) how does the context affect the ability to measure? The second section presents observations on contextual issues based on my ongoing study of the Japanese [3]. This paper also relies heavily on extensive interviews conducted at Hitachi, Fujitsu, NEC, and Toshiba during May, August, and September 1992. 2 Basic Questions Why we measure aspects of the software development process and conduct analytical exercises or experiments, as well as what we try to do with this information, depends very much on who is doing or requesting the measuring and analysis. There already exists a broad literature on technical aspects software measurement and the relationship to process management, which will not be reviewed here [1, 2, 5, 6].
    [Show full text]
  • 12 Steps to Useful Software Metrics
    12 Steps to Useful Software Metrics Linda Westfall The Westfall Team [email protected] PMB 101, 3000 Custer Road, Suite 270 Plano, TX 75075 972-867-1172 (voice) 972-943-1484 (fax) Abstract: 12 Steps to Useful Software Metrics introduces the reader to a practical process for establishing and tailoring a software metrics program that focuses on goals and information needs. The process provides a practical, systematic, start-to-finish method of selecting, designing and implementing software metrics. It outlines a cookbook method that the reader can use to simplify the journey from software metrics in concept to delivered information. Bio: Linda Westfall is the President of The Westfall Team, which provides Software Metrics and Software Quality Engineering training and consulting services. Prior to starting her own business, Linda was the Senior Manager of the Quality Metrics and Analysis at DSC Communications where her team designed and implemented a corporate wide metric program. Linda has more than twenty-five years of experience in real-time software engineering, quality and metrics. She has worked as a Software Engineer, Systems Analyst, Software Process Engineer and Manager of Production Software. Very active professionally, Linda Westfall is a past chair of the American Society for Quality (ASQ) Software Division. She has also served as the Software Division’s Program Chair and Certification Chair and on the ASQ National Certification Board. Linda is a past-chair of the Association for Software Engineering Excellence (ASEE) and has chaired several conference program committees. Linda Westfall has an MBA from the University of Texas at Dallas and BS in Mathematics from Carnegie- Mellon University.
    [Show full text]
  • Model of Agile Software Measurement: a Case Study Master of Science Thesis in the Programme Software Engineering and Technology
    Model of Agile Software Measurement: A Case Study Master of Science Thesis in the Programme Software engineering and Technology JOHAN GUSTAFSSON Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering Göteborg, Sweden, June 2011 The Author grants to Chalmers University of Technology and University of Gothenburg the non-exclusive right to publish the Work electronically and in a non-commercial purpose make it accessible on the Internet. The Author warrants that he/she is the author to the Work, and warrants that the Work does not contain text, pictures or other material that violates copyright law. The Author shall, when transferring the rights of the Work to a third party (for example a publisher or a company), acknowledge the third party about this agreement. If the Author has signed a copyright agreement with a third party regarding the Work, the Author warrants hereby that he/she has obtained any necessary permission from this third party to let Chalmers University of Technology and University of Gothenburg store the Work electronically and make it accessible on the Internet. Model of Agile Software Measurement: A Case Study JOHAN GUSTAFSSON © JOHAN GUSTAFSSON, June 2011. Supervisor: ROBERT FELDT Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering SE-412 96 Göteborg Sweden Telephone + 46 (0)31-772 1000 Department of Computer Science and Engineering Göteborg,Sweden 1 Model of Agile Software Measurement: A Case Study Johan Gustafsson Computer Science and Engineering. Chalmers University of Technology Gothenburg, Sweden [email protected] Abstract— This master thesis examines what type of What companies need is a quick, flexible and cost efficient measurement should be conducted in agile software development.
    [Show full text]
  • An Approach for Deriving, Analyzing, and Organizing Requirements Metrics and Related Information in Systems Projects
    An Approach for Deriving, Analyzing, and Organizing Requirements Metrics and Related Information in Systems Projects Ibtehal Noorwali1, Nazim H. Madhavji1 and Remo Ferrari2 1Computer Science Department, The University of Western Ontario, London, Ontario, Canada 2Siemens Mobility, New York, NY, U.S.A. Keywords: Requirements Metrics, Requirements Management, Measurement Approach. Abstract: Large systems projects present unique challenges to the requirements measurement process: large sets of re- quirements across many sub-projects, requirements existing in different categories (e.g., hardware, interface, software, etc.), varying requirements meta-data items (e.g., ID, requirement type, priority, etc.), to name few. Consequently, requirements metrics are often incomplete, metrics and measurement reports are often unor- ganized, and meta-data items that are essential for applying the metrics are often incomplete or missing. To our knowledge, there are no published approaches for measuring requirements in large systems projects. In this paper, we propose a 7-step approach that combines the use of the goal-question-metric paradigm (GQM) and the identification and analysis of four main RE measurement elements: attributes, levels, metrics, and meta-data items—that aids in the derivation, analysis, and organization of requirements metrics. We illustrate the use of our approach by applying it to real-life data from the rail automation systems domain. We show how the approach led to a more comprehensive set of requirements metrics, improved organization
    [Show full text]
  • Metrics, Models, and Measures for Managing Programs & Projects
    Lean & Agile Performance Measurement Metrics, Models, and Measures for Managing Programs & Projects Dr. David F. Rico, PMP, CSEP, FCP, FCT, ACP, CSM, SAFE, DEVOPS Twitter: @dr_david_f_rico Website: http://www.davidfrico.com LinkedIn: http://www.linkedin.com/in/davidfrico Agile Capabilities: http://davidfrico.com/rico-capability-agile.pdf Agile Cost of Quality: http://www.davidfrico.com/agile-vs-trad-coq.pdf DevOps Return on Investment (ROI): http://davidfrico.com/rico-devops-roi.pdf Dave’s NEW Business Agility Video: https://www.youtube.com/watch?v=-wTXqN-OBzA Dave’s NEWER Development Operations Security Video: https://vimeo.com/214895416 DoD Fighter Jets vs. Amazon Web Services: http://davidfrico.com/dod-agile-principles.pdf Author Background Gov’t contractor with 35+ years of IT experience B.S. Comp. Sci., M.S. Soft. Eng., & D.M. Info. Sys. Large gov’t projects in U.S., Far/Mid-East, & Europe Career systems & software engineering methodologist Lean-Agile, Six Sigma, CMMI, ISO 9001, DoD 5000 NASA, USAF, Navy, Army, DISA, & DARPA projects Published seven books & numerous journal articles Intn’l keynote speaker, 196+ talks to 14,400 people Specializes in metrics, models, & cost engineering Cloud Computing, SOA, Web Services, FOSS, etc. Professor at 7 Washington, DC-area universities 2 On Metrics—Peter Drucker 3 Large TRADITIONAL Projects Size vs. Quality Size vs. Change 16.00 40% 12.80 32% 9.60 24% 6.40 16% CHANGE DEFECTS 3.20 8% 0.00 0% 0 2 6 25 100 400 0 2 6 25 100 400 SIZE SIZE Size vs. Productivity Size vs. Success 5.00 60% 4.00 48% 3.00 36% 2.00 24% 1.00 SUCCESS 12% PRODUCTIVITY 0.00 0% 0 2 6 25 100 400 0 2 6 25 100 400 SIZE SIZE Jones, C.
    [Show full text]
  • Measuring Process Flow Using Metrics in Agile Software Development a Systematic Literature Review and a Case Study
    Master of Science in Software Engineering June 2019 Measuring Process Flow using Metrics in Agile Software Development A Systematic Literature Review and a Case Study Krishna Sai Bitla Sairam Sagar Veesamsetty Faculty of Computing, Blekinge Institute of Technology, 371 79 Karlskrona, Sweden This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology in partial fulfilment of the requirements for the degree of Master of Science in Software Engineering. The thesis is equivalent to 20 weeks of full-time studies. The authors declare that they are the sole authors of this thesis and that they have not used any sources other than those listed in the bibliography and identified as references. They further declare that they have not submitted this thesis at any other institution to obtain a degree. Contact Information: Author(s): Krishna Sai Bitla E-mail: [email protected] Sairam Sagar Veesamsetty E-mail: [email protected] University advisor: DR. Krzysztof Wnuk Department of Software Engineering Industry Advisor: Dani Benjamin Plant Manager VCEZ at Volvo Cars Faculty of Computing Internet : www.bth.se Blekinge Institute of Technology Phone : +46 455 38 50 00 SE-371 79 Karlskrona, Sweden Fax : +46 455 38 50 57 ii ACKNOWLEDGEMENTS Our Journey in the thesis has been tremendously intense learning, value added and a remarkable experience. First and foremost, we would first like to thank from our bottom of our hearts to our university supervisor, Dr. Krzysztof Wnuk who has always been a third wheel in the thesis study. Whenever we have faced trouble during thesis time he has made sure that his doors were always open for supervisions, comments on the study, suggestions for unique considerations during the thesis period.
    [Show full text]
  • Contextual Injection of Quality Measures Into Software Engineering Processes
    International Journal on Advances in Software, vol 4 no 1 & 2, year 2011, http://www.iariajournals.org/software/ 76 Contextual Injection of Quality Measures into Software Engineering Processes Gregor Grambow and Roy Oberhauser Manfred Reichert Computer Science Dept. Institute for Databases and Information Systems Aalen University, Germany Ulm University, Germany {gregor.grambow, roy.oberhauser}@htw-aalen.de [email protected] Abstract—Despite improvements in software engineering process (e.g., junior vs. senior engineers, information needs), processes and tools, concrete preventative and analytical activity coordination with the overall team process, the software quality assurance activities are still typically contextual and project influences on the processes (e.g., manually triggered and determined, resulting in missed or schedule, resource availability), and software quality untimely quality opportunities and increased project overhead. assurance (SQA) dependencies (e.g., quality plan, reactive Quality goals, when defined, lack holistic environmental quality measures, metric dependencies). support for automated performance measurement and Historically software development projects have also governance that is tightly integrated in the low-level faced difficulties in meeting budget, schedule, functionality, operational software engineering processes. This results in and quality targets [6][7][8]. A more recent study in 2002 by higher quality risks and cost risks. Based on adaptive process the National Institute of Standards and Technology (NIST) management, an approach is presented that injects situationally-determined quality measure proposals into the found that most delivered software products are still stricken concrete workflows of software engineers, using contextual by bugs and defects [9]. While some of these difficulties semantic knowledge and multi-agent quality goal tracking and might be ascribed to a misaligned planning environment in decision-making.
    [Show full text]