1 Quantitative and qualitative methods in process improvement and product quality assessment. Anna Bobkowska Abstract Successful improvement of the development process and product quality assurance should take advantages of complementary use of both quantitative and qualitative methods. In the paper, experience of such integrated activities during students quality lab is presented. 1. Introduction One of the recommendations of the TQM (Total Quality Management) says: Measure your success!  However things defined by business case or external problems such as cancelled projects, late deliveries, exceeded budget, and useless software are just a tip of the iceberg containing issues of the complex project reality. In order to make improvements effectively good understanding of those subtitles is needed. One can argue that quantitative methods are not sufficient for the purpose of successful software quality assurance. Intentional and systematic use of qualitative methods can provide missing part of the solution. 2. Complementary applications of quantitative and qualitative methods Quantitative and qualitative issues are strictly related, but in software engineering qualitative methods are treated rather informally. Comparison of both approaches in aspects of techniques and applications is presented in the figure 1. Quantitative methods Measurement Quantification Computations Applications Statistical results Control and management Comparison of similar products Integration with other indicators Qualitative methods Comments, notes and schemas Discussions and observations, Questionnaires, interviews Analysis, reasoning Applications Problem identification and removal Theory generation and improvement Understanding of project reality Enhancement of the measurement structure Cross-case analysis Focus on details, complexity Non-technical aspects Figure 1. Comparison of quantitative and qualitative methods in aspects of techniques and applications.
2 2.1. Quantitative methods Quantitative methods use numbers. Measures are easy to take when there are countable objects e.g. number of persons, number of elements of given type on the diagram, or there are standard devices or agreements for objective measuring a given feature, e.g. time, cost. In the case when those conditions are not satisfied but a number that represents a state according to the defined goal is needed, it is necessary to quantify that feature. Examples include: ease of use, understandability, and cover all the cases when it is very difficult to find objective metrics. Quantification is concerned with assigning numbers to the states of reality with appropriate rules of representation . During quantification there is a problem of subjectivity and imprecision of the achieved data although they are represented by numbers. Quantitative methods are necessary for comparison of similar products, control and management. Quantitative data easily deliver statistical results and can be processed automatically. Another advantage of their use is ease of integration with systems covering other indicators. It is important to define goals of measurement and prepare an appropriate measurement plan. This can be done with GQM (Goal-Question-Metric)  approach or FCM (Factor-Criteria-Metrics) structure  or Goal-Subgoal-Metrics structure . In application of software quality defect density metric is used. Although defects are countable ideas, it is not fully objective metric since defect classifications are made by humans. Apart from the problem of not discovered defects, importance of the defect can differ in cases when it has occurred a serious defect, a mistake or just a misunderstanding. Another approach is concerned with FCM structure and making computation in order to achieve numbers that represent higher level quality indicators. This is usually more total approach which allows to involve non-technical (e.g. human) aspects of quality. This approach is used and extended in the presented research Qualitative methods Qualitative methods use objects different then numbers e.g. words, pictures. The techniques include interviews, discussions, observations, comments, notes, questionnaires, and schemas. Usually the results are more subjective and more difficult to process, and thus require more work during analysis. But they give richer and more informative results. Quantitative methods can be applied to theory generation and improvement, problem identification and removal, and cross-case analysis . They are necessary in the situations when better reality or system understanding is required, and complexity, not reductions and quick processing are a value. Searching for reasons of things and non-technical aspects are good fields for them. Although they seem to be intuitive their application also requires infrastructure preparation and special methods of results analysis. Qualitative methods can be helpful in optimising a structure of measurements. On the other hand, metrics can provide assessments or problem indication to focus on with qualitative methods. After identification of the reasons of problems and their removal quantitative methods can be used again to track the project.
3 3. Development process improvement There is a relationship between development process parameters and software quality. While attempting to achieve high quality products one should provide also optimal development process. Optimal process being goal of this research is characterised by: An appropriate schedule, in which deadlines are set to avoid late deliveries, and there is unified weekly workload during all the semester. Infrastructure for efficient co-operation between participant with different roles in the project is provided, and there are some facilitators for internal organisation in the group, e.g. task sequencing and work distribution. Product templates for each phase are defined to fit the type of the system and avoid overdocumenting. Before the changes, OMT  method without measurements and reviews was used. There were problems with late deliveries, poor quality products, and student s complaining about workload. But there was no base to verify the workload and find reasons of problems. So, the development process was exchanged to a more controlled process described in brief in section 3.1, and then it was optimised with use of combination of quantitative and qualitative methods in the three following years Making a difference Any set of improvement activities must be based on the development process definition. Software development process, in this case, was tailored for Internet applications and covered the phases of requirements specification, object-oriented analysis, design, implementation and testing. The products of the analysis and design were documented with UML  and structured text. Implementation technology was a design decision. Additionally the method of playing roles by the groups of project participants  was introduced. There were the following roles: Developer - responsible for the project and the delivery of products, Customer responsible for the problem domain, and Quality expert - responsible for quality assurance. It was assumed that groups playing the roles co-operate in partnership. The process included reviews after each phase, and technical meeting of all participants after requirements specification review phase. Measurement plan was established. Collected data contained information about: time of work spent on project activities by the participants, late deliveries and evaluation of products quality delivered by the developer (self-evaluation), the quality expert, and teacher. Apart from that, participants described way of work distribution, internal communication, and main problems concerned with the phase. Those comments as well as observations and discussions were used to find problems and look for solutions. Introduction of the measurements and comments revealed author from relaying on opinions and beliefs, and allowed to rely on facts. Metrics easily verified concepts, for example, real time of work, quality of products, and scale of late deliveries (if those were problems of all groups or just an exception!). On the other hand, descriptions gave an understanding of activities made by students and their problems. A lot of problems were concerned with poor organisation, misunderstanding, and had simple solutions. But there were also serious problems that needed more advanced activities. In the task of searching for suggestions that facilitate organisation or explanations that allow to better understand project issues, metrics and descriptions made complementary work.
4 3.2. Process optimisation Optimisation activity aimed to change process parameters in these places where problems occurred. Collected data enabled tracking results of the new development process. Number of weeks set for the development tasks, average time of work per group and deviation that indicates how the results differ among groups are presented in the table 1. Symbols of * indicate different development tasks made during the same period of time, e.g. in the first iteration there was phase of design that covered system design and component design. Data are taken from four best projects for each iteration. Table 1. Number of weeks for a development task (#weeks), average time of work (ATW) and deviation (d) in the iterations. Development tasks #weeks ATW d #weeks ATW d #weeks ATW d in iter.1 in iter.2 in iter.3 Vision Requirements * specification Review Analysis *3 Review System design 3 * * * User interface 2 *2 2 *4 prototype Review Component design 3 * ** Review Implementation ** Tests Total Time for review was not limited. Quality expert s task was to find as many defects as possible and then make evaluations and quality predictions. Just looking through documentation one could find it was more precise and reader friendly then before the change. Also late deliveries (except from design phase) did not happen in the scale of the students group. However some problems appeared. Results of the revision of the first iteration and improvement activities undertaken to avoid the problems in the next iteration are presented in the table 2. Table 2. Problems collected in the first iteration and improvements in the second iteration Problems Improvement activities Large time of work, especially in the Establish groups of 3 persons instead of 2. implementation phase (it is co-related Support internal organisation of the group by with the measured time of work) delivering suggestions of sequence of task and work distribution. Simplify questionnaires. Late deliveries in the design phase Split design (as one task lasting a long time) into (each group was late 1 or 2 weeks) Medium level of the customer satisfaction at the end of project. two: system design and component design. Introduce prototyping user interface task with review made by the customer.
5 The improvements gave satisfactory results. In the second iteration the customer s satisfaction level was higher, there was no late deliveries of system design, but there were still problems with component design. It was possible to decrease the time of work (see large deviation in the second iteration), but average results are so large because of a very good group that worked a lot, but also delivered excellent products. The list of problems found in the second iteration and improvement activities for the next iteration are presented in table 3. Table 3. Problems collected in the second iteration and improvements in the third iteration Problems Improvement activities Is there possibility to make the Simplify of Requirements Specification document: Vision of process more efficient? Still the system is made during the first week and non-functional large time of work was requirements selected to fit best this type of system are reported. delivered together with the analysis phase. Late deliveries in component design phase Different understanding of the system by the quality expert, the customer and the developer after system design review and user interface prototype review. Introduce two phases of component design together with component prototyping, implementation and writing technical documentation (the second one includes also system integration) instead of the component design phase and implementation phase. Introduce meeting of all participants after system design review and user interface prototype review to make compromise for the design and implementation. After those improvements there were no late deliveries, time of work decreased, and level of customer s satisfaction was good. This optimal process enabled to make observations on human factors, e.g. adequacy of assigning persons with certain competencies and personality to the development tasks. Presented work describes activities taken to achieve the optimal process with no late deliveries, unified time of work during all the semester, good infrastructure supporting development process and optimal product templates. Each iteration allowed to remove more detailed problems. Removal of the most visible problems resulted in appearance of more hidden ones, e.g. different views of an expert and customer would not be possible to find without review of user interface prototype, or without split for system and component design it would be difficult to locate the problem in component design. It is also interesting that problems indicated by measurements usually have their explanations, e.g. late deliveries in component design are caused by poor knowledge of implementation environment and difficulty to imagine how the system works. 4. Product quality assessment Inspections and tests are main techniques of quality assurance with focus on product. Inspections can be applied to the documentation in early phases to avoid defect propagation and thus minimise time and cost of improvements. In the final version of this work, reviews of analysis and requirements specification, system design, and detailed design with component implementation were made by the quality experts, and user interface prototype was verified by the customer. Questionnaire templates with metrics and comments collection as well as
6 reasoning about quality were designed in order to support reviews. Tests were made by both the quality experts and the customers at the end of the project Questionnaires for reviews First activity in product quality assurance, and especially review design, is quality definition. The FCM structure was used for this purpose, and for this type of application desired quality was defined with the following factors: Functionality with criteria of completeness, adequacy and coherency, Satisfaction which was verified by checking ease of use, productivity and general aesthetics, Maintainability which was decomposed to documentation quality, portability and modifiability, Dependability in aspects of security and error-tolerance. It was assumed that quality metrics assigned to criteria and factors were in scale [1..5], where 1meantverylowquality,and5 veryhigh. In order to achieve those quality metrics data collection according to the following elements were used: Diagram metrics - they covered counting of elements on the diagrams, and allowed to compare those numbers with expected values, which could be derived from historical data about similar projects. Those expected values were not given in all projects, and thus intuitive estimation of them had to be made. Diagram metrics were also a basis for local size calculation which was used for defect metrics calculation. There was possibility to comment on those values. This is a potential place for automation, but in the author s opinion these kind of calculations bring very uncertain information. Diagram metrics are objective, but quite a lot of subjectivity is associated with the expected values application. Evaluations with comments - evaluations are numbers that represent subjective feelings about some aspects of the work, e.g. ease of understanding, aesthetics, precision, etc. Sometimes they are more efficient then metrics, e.g. instead of counting all the attributes and compare it with fuzzy expected values, one can evaluate that (always, usually,..., never) attributes are complete and adequate and thus description is detailed enough (or not). They could be given in the scale [1..5] described above or described as comments. Defect collection according to the defect classification - those defects can be then counted and combined with the diagram metrics. Such metrics are good quality indicators. The templates were prepared to integrate quality issues with documentation fragments in order to focus attention of the reviewer on limited fragment of documentation, e.g. one type of diagram with descriptions, with their relevant metrics, evaluation and potential defects. Then those elements were integrated into quality metrics that represented factors and recommendations of improvement were generated. During the lab, intuitive reasoning supported with questionnaires was used, but in this part quantitative calculations with formulas that model quality relationships mathematically can be applied to partially automate the process. To summarise use of qualitative and quantitative methods: comments had application during the project to data collection, reasoning about quality factors and criteria, and generation of recommendations for improvement by the quality experts. Also questionnaire analysis and optimisation over the iterations was possible thanks to those comments. Metrics of diagrams and number of defects were used for calculation of the defect metrics. Quantified values of criteria and factors allowed to compare products and gave an idea about the time needed to make corrections.
8 4.2. Results One of the constraints of this research is that participants are students, and not real customers, developers and quality experts. In order to achieve possibly the most reliable results ten best projects are analysed. In the table 4 metrics of diagrams and defects are presented. Then average value (AV) and deviation (d) are calculated. Since analysis consists of the use case model, class diagram and sequence diagrams with descriptions, the metrics and defects are concerned with them. For the use case diagram, there are the following metrics: number of use cases (# use cases), number of actors (# actors), number of elements including use cases, actors and relationships (# elements), number of elements incoherent with Software Requirements Specification (# incoherent), number of inadequate elements (# inadequate), which includes missing, wrong scope elements, and not needed elements, number of elements difficult to understand (# dif. to understand), which includes ambiguous and surprising elements and statements. Table 4. Metrics of diagrams and defects of the analysis phase for ten projects (P1-P10) Description P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 AV d # use cases # actors # elements # incoherent # inadequate # dif. To understand % inadequate 15% 27% 11% 6% 12% 24% 8% 6% 6% 18% 13% 6% % dif. to understand 10% 23% 8% 13% 18% 11% 3% 10% 8% 0% 10% 5% # classes Size ofthe class diagr # imprecision Precision evaluation 3 3 3, ,5 4 3, # inadequate # dif. to understand % imprecision 10% 33% 50% 9% 21% 8% 2% 17% 16% 6% 17% 11% % inadequate 7% 25% 63% 6% 11% 13% 10% 4% 11% 18% 17% 11% % dif. to understand 7% 17% 25% 0% 11% 4% 2% 4% 0% 12% 8% 6% # sequence diagr Size (# interactions) # incorrect interactions # m_exceptions x x x x x x %incorrect interactions 8% 6% 2% 0% 33% 4% 8% 10% 6% 12% 9% 6% # inco A-SRS # inco CD-UCD # inco CD-SD # inco UCD-SD
9 Defect metrics are calculated by division of the number of inadequate elements by the number of elements (% inadequate), and the number of elements difficult to understand by the number of elements (% dif. to understand). The number of elements stand here for the size of use case diagram. Similar metrics are collected for the class diagram, but in this case precision is also important and it is difficult to be captured by metrics, so apart from discovering imprecise elements (# imprecise) there is precision evaluation in the scale of [1..5]. The size of the class diagram is here defined as a sum of classes and relationships. And for sequence diagrams there are the following metrics: number of sequence diagrams (# sequence diagr.), size counted as a number of interactions, missing exceptions (# m_exceptions) - x is used when there is a lot of exceptions missing. And finally coherency between the diagrams is checked: incoherence between analysis diagrams and requirements specification (#inco A-SRS), incoherence between class diagram and use case diagram (# inco CD-UCD), incoherence between class diagram and sequence diagrams (# inco CD-SD), and incoherence between use case diagram and sequence diagrams (# inco UCD-SD). In the table 5, quality metrics for the same projects being result of the reasoning on the basis of the metrics described above together with evaluations and comments are presented. Table 5. Quality metrics for the criteria in ten projects. Description P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 AV Completeness ,9 Adequacy 3, , ,4 Precision 3, ,5 4, ,7 Functionality ,0 The questionnaires support finding defects and help to integrate information taken from different sources. For more precise reasoning it would be useful to introduce some standard rules. Concrete defects are closely connected with the domain of application and they are used during the project to improve quality, so other considerations then classified defect metrics have no sense in this analysis. Statistics of the diagram metrics can be applied for gathering expected values. Let us assume that average value is an expected value, and deviation sets the range of accepted values. In this case, range of expected values for the number of classes is [8..16], and it is possible to find automatically anomalies in project P3 with too little classes (4), and project P6 with too many (24). 5. Conclusions In the paper, experience of process improvement and product quality assessment in early phases of software development with use of quantitative and qualitative methods is presented. Defined process and collected data plan were the basis for making improvements. They enabled to rely on facts, not opinions during revisions. Quantitative methods were used to verify concepts, and qualitative ones for problem identification and removal, and deeper analysis of project issues. After the change concerned with introduction of the new method with reviews and measurements, the development process was optimised over three iterations. Every iteration allowed to identify and remove more and more detailed problems. In product quality assessment qualitative and quantitative methods were used by the quality experts to data collection, reasoning about quality factors and criteria, and generation of recommendations for improvement. They were also used in questionnaire optimisation.
10 6. References  Bobkowska A., Training on High Quality Software Development with the 3RolesPlaying method, in SCI 98/ISAS 98 conference proceedings, Orlando, USA, July  Briand, L. C., Differding C. M., Rombach D. H., Practical Guidelines for Measurement - Based Process Improvement, Technical Report of the International Software Engineering Network (ISERN-96-05),  Fenton N.E., Software Metrics. A Rigorous Approach, Chapman&Hall,  Grudowski P., Kolman R., Meller A., Preihs J., Zarządzanie jakością (Quality Management), Wydawnictwo Politechniki Gdańskiej, Gdańsk,  Rational Software Corporation, UML Notation Guide,  Rational Software Corporation, Rational Unified Process,  Rumbaugh J., Blaha M., Premerliani W., Eddy F., Lorensen W., Object-oriented modelling and design, Prentice-Hall,  Seaman C. B., Qualitative methods in Empirical Studies of Software Engineering., Transactions on Software Engineering volume 25, 1999, pages
SOFTWARE REQUIREMENTS http://www.tutorialspoint.com/software_engineering/software_requirements.htm Copyright tutorialspoint.com The software requirements are description of features and functionalities
Software Requirements Menouer Boubekeur, Gregory Provan Lectures Introduction to UML Introduction to Requirements Analysis Advanced techniques for Requirement Analysis M. Boubekeur, CSL, University College
Software Engineering Software Requirements Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce the concepts of user and system requirements To describe functional and
Using Use Cases for requirements capture Pete McBreen 1998 McBreen.Consulting firstname.lastname@example.org All rights reserved. You have permission to copy and distribute the document as long as you make no changes
In this Lecture you will Learn: Systems Development Methodologies What a systems development methodology is Why methodologies are used The need for different methodologies The main features of one methodology
Software quality measurement Magne Jørgensen University of Oslo, Department of Informatics, Norway Abstract: This paper analyses our ability to measure software quality. The analysis is based on the representational
Software Engineering Requirements Engineering Process Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To describe the principal requirements engineering activities and d their
A little refresher: What are we modelling? Lecture 9: Requirements Modelling Requirements; Systems; Systems Thinking Role of Modelling in RE Why modelling is important Limitations of modelling Brief overview
Performance Assessment Task Bikes and Trikes Grade 4 The task challenges a student to demonstrate understanding of concepts involved in multiplication. A student must make sense of equal sized groups of
Software Process Improvement Software Business Casper Lassenius Topics covered ² The process process ² Process measurement ² Process analysis ² Process change ² The CMMI process framework 2 Process ² Many
Empirical Software Engineering Introduction & Basic Concepts Dietmar Winkler Vienna University of Technology Institute of Software Technology and Interactive Systems email@example.com
Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software
ISO/IEC 9126 in practice: what do we need to know? P. Botella, X. Burgués, J.P. Carvallo, X. Franch, G. Grau, J. Marco, C. Quer Abstract ISO/IEC 9126 is currently one of the most widespread quality standards.
Higher National Unit specification General information Unit code: HA4C 34 Superclass: CB Publication date: January 2016 Source: Scottish Qualifications Authority Version: 02 Unit purpose The purpose of
Requirements Analysis Concepts & Principles Instructor: Dr. Jerry Gao Requirements Analysis Concepts and Principles - Requirements Analysis - Communication Techniques - Initiating the Process - Facilitated
A UML Introduction Tutorial 1/27/08 9:55 PM A UML Introduction Tutorial In this tutorial you will learn about the fundamentals of object oriented modelling, the Unified Modelling Language and the software
Software Development Methodologies in Industry By: Ahmad Deeb Methodologies Software Development Methodologies in Industry Presentation outline SDM definition Project and analysis approach Research methods
Software Lecture 9 Software Engineering CUGS Spring 2011 Kristian Sandahl Department of Computer and Information Science Linköping University, Sweden A Software Life-cycle Model Which part will we talk
Measurable Software Quality Improvement through Innovative Software Inspection Technologies at Allianz Life Assurance Bernd Freimut, Brigitte Klein, Oliver Laitenberger, Günther Ruhe Abstract The development
ADVANCED DOCUMENT MANAGEMENT SOLUTIONS FOR THE CONSTRUCTION INDUSTRY: THE CONDOR APPROACH Yacine Rezgui, Grahame Cooper, Farhi Marir, Maria Vakola and Alan Tracey Abstract: the paper gives a comprehensive
Unit 11: Software Metrics Objective Ð To describe the current state-of-the-art in the measurement of software products and process. Why Measure? "When you can measure what you are speaking about and express
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike License. Your use of this material constitutes acceptance of that license and the conditions of use of materials on this
Performing Early Feasibility Studies of Software Development Projects Using Business Process Models Ayman A. Issa, Faisal A. Abu Rub ABSTRACT A new approach to perform feasibility studies using business
Study and Evaluation for Quality Improvement of Object Oriented System at Various Layers of Object Oriented Matrices N. A. Nemade 1, D. D. Patil 2, N. V. Ingale 3 Assist. Prof. SSGBCOET Bhusawal 1, H.O.D.
3C05: Unified Software Development Process 1 Unit 5: Unified Software Development Process Objectives: Introduce the main concepts of iterative and incremental development Discuss the main USDP phases 2
Lecture Software Engineering CHAPTER 11 REQUIREMENTS Lecture Software Engineering Topics Determining What the Client Needs Overview of the Requirements Workflow Understanding the Domain The Business Model
Chapter 9, Non-functional Requirements Organizational Requirements Engineering Prof. Dr. Armin B. Cremers Sascha Alda Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 1 Overview of
META DATA QUALITY CONTROL ARCHITECTURE IN DATA WAREHOUSING Ramesh Babu Palepu 1, Dr K V Sambasiva Rao 2 Dept of IT, Amrita Sai Institute of Science & Technology 1 MVR College of Engineering 2 firstname.lastname@example.org
Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and
Risk Analysis and Quantification 1 What is Risk Analysis? 2. Risk Analysis Methods 3. The Monte Carlo Method 4. Risk Model 5. What steps must be taken for the development of a Risk Model? 1.What is Risk
Measuring the Impact of Volunteering Why is measuring the impact of volunteering important? It is increasingly important for organisations or groups to describe the difference that volunteering makes to,
Masters of Science in Software & Information Systems To be developed and delivered in conjunction with Regis University, School for Professional Studies Object Oriented Design Table of Contents January
Fundamentals of Information Systems, Fifth Edition Chapter 8 Systems Development Principles and Learning Objectives Effective systems development requires a team effort of stakeholders, users, managers,
Assuming the Role of Systems Analyst & Analysis Alternatives Nature of Analysis Systems analysis and design is a systematic approach to identifying problems, opportunities, and objectives; analyzing the
Introducing Formal Methods Formal Methods for Software Specification and Analysis: An Overview 1 Software Engineering and Formal Methods Every Software engineering methodology is based on a recommended
Software Development Life Cycle (SDLC) Supriyo Bhattacharjee MOF Capability Maturity Model (CMM) A bench-mark for measuring the maturity of an organization s software process CMM defines 5 levels of process
Evaluation of a Use-Case-Driven Requirements Analysis Tool Employing Web UI Prototype Generation SHINPEI OGATA Course of Functional Control Systems, Graduate School of Engineering Shibaura Institute of
International Journal of Soft Computing and Engineering (IJSCE) A Study on Software Metrics and Phase based Defect Removal Pattern Technique for Project Management Jayanthi.R, M Lilly Florence Abstract:
Questions? Assignment Why is proper project management important? What is goal of domain analysis? What is the difference between functional and non- functional requirements? Why is it important for requirements
Volume 4, Issue 4, April 2014 ISSN: 2277 128X International Journal of Advanced Research in Computer Science and Software Engineering Research Paper Available online at: www.ijarcsse.com A Document Driven
BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 5 Diploma in IT September 2013 EXAMINERS REPORT Systems Analysis and Design Section A General Comments Candidates in general
Software Requirements Descriptions and specifications of a system Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Objectives To introduce the concepts of user and system To describe
Bachelor's Degree in Business Administration and Master's Degree course description Bachelor's Degree in Business Administration Department s Compulsory Requirements Course Description (402102) Principles
Handbook for Degree Project Writers MASTER S PROGRAMMES IN ENGINEERING 2012 THE FACULTY OF ENGINEERING (LTH) LUND UNIVERSITY Contents HANDBOOK FOR DEGREE PROJECT WRITERS Lund University Faculty of Engineering
Object-Oriented Modeling and Design James Rumbaugh Michael Blaha William Premerlani Frederick Eddy William Lorensen General Electric Research and Development Center Schenectady, New York Tschnische Hochschule
Saimaa University of Applied Sciences Faculty of Business Administration, Lappeenranta Degree Programme in International Business Olga Anisimova Quality Management in Purchasing Thesis 2014 Abstract Olga
4 Software Quality Engineering c Jeff Tian, to be published by John Wiley, 2005 Software quality engineering Quality assurance Testing Figure 1.1. engineering Scope and content hierarchy: Testing, quality
Object-Oriented Systems Analysis and Design Noushin Ashrafi Professor of Information System University of Massachusetts-Boston Hessam Ashrafi Software Architect Pearson Education International CONTENTS
PROCESSES SUPPLY CHAIN SKILLED TALENT CUSTOMER RELATIONSHIPS FURTHER EXCELLENCE GENERIC STANDARDS INDUSTRY STANDARDS CUSTOMISED SOLUTIONS TRAINING SERVICES THE ROUTE TO ISO 9001:2015 FOREWORD The purpose
Reaching CMM Levels 2 and 3 with the Rational Unified Process Rational Software White Paper TP174 Table of Contents INTRODUCTION... 1 LEVEL-2, REPEATABLE... 3 Requirements Management... 3 Software Project
Position Classification Standard for Management and Program Clerical and Assistance Series, GS-0344 Table of Contents SERIES DEFINITION... 2 EXCLUSIONS... 2 OCCUPATIONAL INFORMATION... 3 TITLES... 6 EVALUATING
From Object Oriented Conceptual Modeling to Automated Programming in Java Oscar Pastor, Vicente Pelechano, Emilio Insfrán, Jaime Gómez Department of Information Systems and Computation Valencia University
DATA ANALYSIS, INTERPRETATION AND PRESENTATION OVERVIEW Qualitative and quantitative Simple quantitative analysis Simple qualitative analysis Tools to support data analysis Theoretical frameworks: grounded
Process Improvement Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 1 Objectives To explain the principles of software process improvement To explain how software process factors
Software Process for QA Basic approaches & alternatives CIS 610, W98 / M Young 1/7/98 1 This introduction and overview is intended to provide some basic background on software process (sometimes called
Requirements engineering processes Requirements Engineering Processes The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the.
Analysis of the Specifics for a Business Rules Engine Based Projects By Dmitri Ilkaev and Dan Meenan Introduction In recent years business rules engines (BRE) have become a key component in almost every
Foundation of Business Analysis Course BA30: 4 days Instructor Led Prerequisites: No prerequisites - This course is suitable for both beginner and intermediate Business Analysts who would like to increase
A Methodology for the Development of New Telecommunications Services DIONISIS X. ADAMOPOULOS Centre for Communication Systems Research School of Elec. Eng., IT and Mathematics University of Surrey Guildford
Risk Based Software Development Reducing Risk and Increasing the Probability of Project Success IT Software Development Just Isn t Working! IT systems are at the heart of modern business and the development
Algebra 1, Quarter 2, Unit 2.1 Creating, Solving, and Graphing Systems of Linear Equations and Linear Inequalities Overview Number of instructional days: 15 (1 day = 45 60 minutes) Content to be learned
CS 1632 SOFTWARE QUALITY ASSURANCE 2 Marks Sample Questions and Answers 1. Define quality. Quality is the degree of goodness of a product or service or perceived by the customer. Quality concept is the
COST EFFECTIVE APPROACHES FOR PRESCRIBED DAM ASSET MANAGEMENT Haris Pinidiya Sydney Water, NSW, Australia ABSTRACT Dams need to be dewatered in an emergency, typically by operating scour valves. Operating
Requirements Engineering Processes Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 7 Slide 1 Objectives To describe the principal requirements engineering activities and their relationships
Qualitative Methods in Empirical Studies of Software Engineering by Carolyn B. Seaman Overview topics of the paper qualitative methods data collection methods participant observation interviewing coding
1 11 Tips to make the s definition process more effective and results more usable This article discusses what I believe are the key techniques for making s definition process repeatable from project to
60 feedback Manager Development Report name: email: date: Sample Example email@example.com 9 January 200 Introduction 60 feedback enables you to get a clear view of how others perceive the way you work.
Responsibilities, interfaces and outsourcing under Solvency II Author Lars Moormann Contact solvency firstname.lastname@example.org January 2013 2013 Münchener Rückversicherungs Gesellschaft Königinstrasse 107,
A UML 2 Profile for Business Process Modelling * Beate List and Birgit Korherr Women s Postgraduate College for Internet Technologies Institute of Software Technology and Interactive Systems Vienna University
Status Report: Practical Software David N. Card, Software Productivity Consortium Cheryl L. Jones, US Army email@example.com Abstract This article summarizes the basic concepts of Practical Software (PSM),
Software Metrics & Software Metrology Alain Abran Chapter 4 Quantification and Measurement are Not the Same! 1 Agenda This chapter covers: The difference between a number & an analysis model. The Measurement
 Accounting and internal control systems and audit risk assessments (Issued March 1995) Contents Paragraphs Introduction 1 12 Inherent risk 13 15 Accounting system and control environment 16 23 Internal
Assignment # 4 Summing up the Course Usability form an Industrial Prospective (DV1301) Ch. M Nadeem Faisal Muhammad Asim Farrukh Sahar Rana Asif Sattar 790102-P373 811115-P373 800102-P373 840715-P177 firstname.lastname@example.org
Quality Standard Customer Service Complaints Handling Version 1 Date:- 2 nd December 2010 Page 1 Contents INTRODUCTION 4 OVERVIEW OF THE COMPLAINTS STANDARD 5 FRAMEWORK 6 MANDATORY SECTIONS 7 SECTION 1
Software Development: An Introduction Fact: Software is hard. Imagine the difficulty of producing Windows 2000 29 million lines of code 480,000 pages of listing if printed a stack of paper 161 feet high
INTERNATIONAL STANDARD ON ASSURANCE ENGAGEMENTS 3000 ASSURANCE ENGAGEMENTS OTHER THAN AUDITS OR REVIEWS OF HISTORICAL FINANCIAL INFORMATION (Effective for assurance reports dated on or after January 1,
3.0 Methodology 3.1 Introduction In this chapter, five software development life cycle models are compared and discussed briefly. The most suitable system methodology for the proposed system is drawn out.
Performance Assessment Task Swimming Pool Grade 9 The task challenges a student to demonstrate understanding of the concept of quantities. A student must understand the attributes of trapezoids, how to