Quantitative and qualitative methods in process improvement and product quality assessment.

Save this PDF as:

Size: px
Start display at page:

Download "Quantitative and qualitative methods in process improvement and product quality assessment."

Transcription

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! [4] 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 [3]. 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) [2] approach or FCM (Factor-Criteria-Metrics) structure [3] or Goal-Subgoal-Metrics structure [6]. 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 [8]. 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 [7] 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 [5] and structured text. Implementation technology was a design decision. Additionally the method of playing roles by the groups of project participants [1] 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.

7

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 [1] Bobkowska A., Training on High Quality Software Development with the 3RolesPlaying method, in SCI 98/ISAS 98 conference proceedings, Orlando, USA, July [2] 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), [3] Fenton N.E., Software Metrics. A Rigorous Approach, Chapman&Hall, [4] Grudowski P., Kolman R., Meller A., Preihs J., Zarządzanie jakością (Quality Management), Wydawnictwo Politechniki Gdańskiej, Gdańsk, [5] Rational Software Corporation, UML Notation Guide, [6] Rational Software Corporation, Rational Unified Process, [7] Rumbaugh J., Blaha M., Premerliani W., Eddy F., Lorensen W., Object-oriented modelling and design, Prentice-Hall, [8] Seaman C. B., Qualitative methods in Empirical Studies of Software Engineering., Transactions on Software Engineering volume 25, 1999, pages

The Software Process. The Unified Process (Cont.) The Unified Process (Cont.)

The Software Process. The Unified Process (Cont.) The Unified Process (Cont.) The Software Process Xiaojun Qi 1 The Unified Process Until recently, three of the most successful object-oriented methodologies were Booch smethod Jacobson s Objectory Rumbaugh s OMT (Object Modeling

More information

Total Quality Management (TQM) Quality, Success and Failure. Total Quality Management (TQM) vs. Process Reengineering (BPR)

Total Quality Management (TQM) Quality, Success and Failure. Total Quality Management (TQM) vs. Process Reengineering (BPR) Total Quality Management (TQM) Quality, Success and Failure Total Quality Management (TQM) is a concept that makes quality control a responsibility to be shared by all people in an organization. M7011

More information

SOFTWARE REQUIREMENTS

SOFTWARE REQUIREMENTS SOFTWARE REQUIREMENTS http://www.tutorialspoint.com/software_engineering/software_requirements.htm Copyright tutorialspoint.com The software requirements are description of features and functionalities

More information

Menouer Boubekeur, Gregory Provan

Menouer Boubekeur, Gregory Provan Software Requirements Menouer Boubekeur, Gregory Provan Lectures Introduction to UML Introduction to Requirements Analysis Advanced techniques for Requirement Analysis M. Boubekeur, CSL, University College

More information

Software Requirements

Software Requirements 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

More information

Using Use Cases for requirements capture. Pete McBreen. 1998 McBreen.Consulting

Using Use Cases for requirements capture. Pete McBreen. 1998 McBreen.Consulting Using Use Cases for requirements capture Pete McBreen 1998 McBreen.Consulting petemcbreen@acm.org All rights reserved. You have permission to copy and distribute the document as long as you make no changes

More information

In this Lecture you will Learn: Systems Development Methodologies. Why Methodology? Why Methodology?

In this Lecture you will Learn: Systems Development Methodologies. Why Methodology? Why Methodology? 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

More information

Software quality measurement Magne Jørgensen University of Oslo, Department of Informatics, Norway

Software quality measurement Magne Jørgensen University of Oslo, Department of Informatics, Norway 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

More information

What is a requirement? Software Requirements. Descriptions and specifications of a system

What is a requirement? Software Requirements. Descriptions and specifications of a system What is a requirement? Software Requirements Descriptions and specifications of a system May range from a high-level abstract statement of a service or a statement of a system constraint to a detailed

More information

Requirements Engineering Process

Requirements Engineering Process 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

More information

Lecture 9: Requirements Modelling

Lecture 9: Requirements Modelling 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

More information

Performance Assessment Task Bikes and Trikes Grade 4. Common Core State Standards Math - Content Standards

Performance Assessment Task Bikes and Trikes Grade 4. Common Core State Standards Math - Content Standards 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

More information

Software Process Improvement Software Business. Casper Lassenius

Software Process Improvement Software Business. Casper Lassenius 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

More information

Empirical Software Engineering Introduction & Basic Concepts

Empirical Software Engineering Introduction & Basic Concepts Empirical Software Engineering Introduction & Basic Concepts Dietmar Winkler Vienna University of Technology Institute of Software Technology and Interactive Systems dietmar.winkler@qse.ifs.tuwien.ac.at

More information

To introduce software process models To describe three generic process models and when they may be used

To introduce software process models To describe three generic process models and when they may be used 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

More information

Detecting Defects in Object-Oriented Designs: Using Reading Techniques to Increase Software Quality

Detecting Defects in Object-Oriented Designs: Using Reading Techniques to Increase Software Quality Detecting Defects in Object-Oriented Designs: Using Reading Techniques to Increase Software Quality Current Research Team: Prof. Victor R. Basili Forrest Shull, Ph.D. Guilherme H. Travassos, D.Sc. (1)

More information

ISO/IEC 9126 in practice: what do we need to know?

ISO/IEC 9126 in practice: what do we need to know? 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.

More information

Higher National Unit specification. General information. Software Development: Analysis and Design (SCQF level 7) Unit code: HA4C 34.

Higher National Unit specification. General information. Software Development: Analysis and Design (SCQF level 7) Unit code: HA4C 34. 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

More information

Requirements Analysis Concepts & Principles. Instructor: Dr. Jerry Gao

Requirements Analysis Concepts & Principles. Instructor: Dr. Jerry Gao Requirements Analysis Concepts & Principles Instructor: Dr. Jerry Gao Requirements Analysis Concepts and Principles - Requirements Analysis - Communication Techniques - Initiating the Process - Facilitated

More information

A UML Introduction Tutorial

A UML Introduction Tutorial 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

More information

SOFTWARE ARCHITECTURE QUALITY EVALUATION

SOFTWARE ARCHITECTURE QUALITY EVALUATION SOFTWARE ARCHITECTURE QUALITY EVALUATION APPROACHES IN AN INDUSTRIAL CONTEXT Frans Mårtensson Blekinge Institute of Technology Licentiate Dissertation Series No. 2006:03 School of Engineering Software

More information

An Introduction to. Metrics. used during. Software Development

An Introduction to. Metrics. used during. Software Development An Introduction to Metrics used during Software Development Life Cycle www.softwaretestinggenius.com Page 1 of 10 Define the Metric Objectives You can t control what you can t measure. This is a quote

More information

Software Development Methodologies in Industry. By: Ahmad Deeb

Software Development Methodologies in Industry. By: Ahmad Deeb Software Development Methodologies in Industry By: Ahmad Deeb Methodologies Software Development Methodologies in Industry Presentation outline SDM definition Project and analysis approach Research methods

More information

Software Quality Management

Software Quality Management 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

More information

Measurable Software Quality Improvement through Innovative Software Inspection Technologies at Allianz Life Assurance

Measurable Software Quality Improvement through Innovative Software Inspection Technologies at Allianz Life Assurance 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

More information

ADVANCED DOCUMENT MANAGEMENT SOLUTIONS FOR THE CONSTRUCTION INDUSTRY: THE CONDOR APPROACH

ADVANCED DOCUMENT MANAGEMENT SOLUTIONS FOR THE CONSTRUCTION INDUSTRY: THE CONDOR APPROACH 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

More information

STANDARD. Risk Assessment. Supply Chain Risk Management: A Compilation of Best Practices

STANDARD. Risk Assessment. Supply Chain Risk Management: A Compilation of Best Practices A S I S I N T E R N A T I O N A L Supply Chain Risk Management: Risk Assessment A Compilation of Best Practices ANSI/ASIS/RIMS SCRM.1-2014 RA.1-2015 STANDARD The worldwide leader in security standards

More information

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering Software Processes Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce software process models To describe three generic process models and when

More information

Unit 11: Software Metrics

Unit 11: Software Metrics 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

More information

Section C. Requirements Elicitation

Section C. Requirements Elicitation 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

More information

Performing Early Feasibility Studies of Software Development Projects Using Business Process Models

Performing Early Feasibility Studies of Software Development Projects Using Business Process Models 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

More information

II. TYPES OF LEVEL A.

II. TYPES OF LEVEL A. 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.

More information

3C05: Unified Software Development Process

3C05: Unified Software Development Process 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

More information

CHAPTER 11 REQUIREMENTS

CHAPTER 11 REQUIREMENTS 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

More information

Organizational Requirements Engineering

Organizational Requirements Engineering 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

More information

META DATA QUALITY CONTROL ARCHITECTURE IN DATA WAREHOUSING

META DATA QUALITY CONTROL ARCHITECTURE IN DATA WAREHOUSING 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 asistithod@gmail.com

More information

Requirements engineering

Requirements engineering Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and

More information

Risk Analysis and Quantification

Risk Analysis and Quantification 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

More information

Measuring the Impact of Volunteering

Measuring the Impact of Volunteering 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,

More information

Masters of Science in Software & Information Systems

Masters of Science in Software & Information Systems 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

More information

Fundamentals of Information Systems, Fifth Edition. Chapter 8 Systems Development

Fundamentals of Information Systems, Fifth Edition. Chapter 8 Systems Development 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,

More information

Assuming the Role of Systems Analyst & Analysis Alternatives

Assuming the Role of Systems Analyst & Analysis Alternatives 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

More information

Object Oriented Design

Object Oriented Design Object Oriented Design Kenneth M. Anderson Lecture 20 CSCI 5828: Foundations of Software Engineering OO Design 1 Object-Oriented Design Traditional procedural systems separate data and procedures, and

More information

Administrative Data Quality Assurance Toolkit

Administrative Data Quality Assurance Toolkit Administrative Data Quality Assurance Toolkit Version 1 January 2015 1 Administrative Data Quality Assurance Toolkit This toolkit is intended to help statistical assessors review the areas of practice

More information

Introducing Formal Methods. Software Engineering and Formal Methods

Introducing Formal Methods. Software Engineering and Formal Methods 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

More information

Software Development Life Cycle (SDLC)

Software Development Life Cycle (SDLC) 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

More information

Evaluation of a Use-Case-Driven Requirements Analysis Tool Employing Web UI Prototype Generation

Evaluation of a Use-Case-Driven Requirements Analysis Tool Employing Web UI Prototype Generation 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

More information

A Study on Software Metrics and Phase based Defect Removal Pattern Technique for Project Management

A Study on Software Metrics and Phase based Defect Removal Pattern Technique for Project Management 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:

More information

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements 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

More information

Keywords document, agile documentation, documentation, Techno functional expert, Team Collaboration, document selection;

Keywords document, agile documentation, documentation, Techno functional expert, Team Collaboration, document selection; 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

More information

Use-Case Analysis. ! What is it? ! From where did it come? ! Now part of UML

Use-Case Analysis. ! What is it? ! From where did it come? ! Now part of UML Use-Case Analysis Use-Case Analysis! What is it?! An informal, user-friendly, technique useful for functional requirements analysis and specification! From where did it come?! Ivar Jacobson, a Swedish

More information

BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 5 Diploma in IT. September 2013 EXAMINERS REPORT

BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 5 Diploma in IT. September 2013 EXAMINERS REPORT 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

More information

Software Requirements. Descriptions and specifications of a system. Ian Sommerville 2000 Software Engineering, 6th edition.

Software Requirements. Descriptions and specifications of a system. Ian Sommerville 2000 Software Engineering, 6th edition. 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

More information

Bachelor's Degree in Business Administration and Master's Degree course description

Bachelor's Degree in Business Administration and Master's Degree course description 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

More information

Handbook for Degree Project Writers MASTER S PROGRAMMES IN ENGINEERING 2012 THE FACULTY OF ENGINEERING (LTH) LUND UNIVERSITY

Handbook for Degree Project Writers MASTER S PROGRAMMES IN ENGINEERING 2012 THE FACULTY OF ENGINEERING (LTH) LUND UNIVERSITY 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

More information

Object-Oriented Modeling and Design

Object-Oriented Modeling and Design 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

More information

PROCESS IMPROVEMENT CAPABILITY MATURITY MODEL

PROCESS IMPROVEMENT CAPABILITY MATURITY MODEL PROCESS IMPROVEMENT CAPABILITY MATURITY MODEL Immature versus Mature Software Organisations In an immature software organisation, software processes are generally improvised by practitioners and their

More information

Quality Management in Purchasing

Quality Management in Purchasing 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

More information

Software quality engineering. Quality assurance. Testing

Software quality engineering. Quality assurance. Testing 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

More information

Object-Oriented Systems Analysis and Design

Object-Oriented Systems Analysis and Design Object-Oriented Systems Analysis and Design Noushin Ashrafi Professor of Information System University of Massachusetts-Boston Hessam Ashrafi Software Architect Pearson Education International CONTENTS

More information

The Role of Requirement Engineering in Software Development Life Cycle 1

The Role of Requirement Engineering in Software Development Life Cycle 1 The Role of Engineering in Software Development Life Cycle 1 Abhijit Chakraborty, 2 Mrinal Kanti Baowaly, 3 Ashraful Arefin, 4 Ali Newaz Bahar 1, 2 Department of Computer Science and Telecommunication

More information

GENERIC STANDARDS CUSTOMER RELATIONSHIPS FURTHER EXCELLENCE CUSTOMISED SOLUTIONS INDUSTRY STANDARDS TRAINING SERVICES THE ROUTE TO

GENERIC STANDARDS CUSTOMER RELATIONSHIPS FURTHER EXCELLENCE CUSTOMISED SOLUTIONS INDUSTRY STANDARDS TRAINING SERVICES THE ROUTE TO 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

More information

Reaching CMM Levels 2 and 3 with the Rational Unified Process

Reaching CMM Levels 2 and 3 with the Rational Unified Process 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

More information

Measurement Information Model

Measurement Information Model mcgarry02.qxd 9/7/01 1:27 PM Page 13 2 Information Model This chapter describes one of the fundamental measurement concepts of Practical Software, the Information Model. The Information Model provides

More information

10.1 Determining What the Client Needs. Determining What the Client Needs (contd) Determining What the Client Needs (contd)

10.1 Determining What the Client Needs. Determining What the Client Needs (contd) Determining What the Client Needs (contd) Slide 10..1 CHAPTER 10 Slide 10..2 Object-Oriented and Classical Software Engineering REQUIREMENTS Seventh Edition, WCB/McGraw-Hill, 2007 Stephen R. Schach srs@vuse.vanderbilt.edu Overview Slide 10..3

More information

Position Classification Standard for Management and Program Clerical and Assistance Series, GS-0344

Position Classification Standard for Management and Program Clerical and Assistance Series, GS-0344 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

More information

Systematization of Requirements Definition for Software Development Processes with a Business Modeling Architecture

Systematization of Requirements Definition for Software Development Processes with a Business Modeling Architecture Systematization of Requirements Definition for Software Development Processes with a Business Modeling Architecture Delmir de Azevedo Junior 1 and Renato de Campos 2 1 Petrobras University, Republican

More information

From Object Oriented Conceptual Modeling to Automated Programming in Java

From Object Oriented Conceptual Modeling to Automated Programming in Java 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

More information

Software Metrics: Roadmap

Software Metrics: Roadmap Software Metrics: Roadmap By Norman E. Fenton and Martin Neil Presentation by Karim Dhambri Authors (1/2) Norman Fenton is Professor of Computing at Queen Mary (University of London) and is also Chief

More information

DATA ANALYSIS, INTERPRETATION AND PRESENTATION

DATA ANALYSIS, INTERPRETATION AND PRESENTATION DATA ANALYSIS, INTERPRETATION AND PRESENTATION OVERVIEW Qualitative and quantitative Simple quantitative analysis Simple qualitative analysis Tools to support data analysis Theoretical frameworks: grounded

More information

Process Improvement. Objectives

Process Improvement. Objectives 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

More information

Software Process for QA

Software Process for QA 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

More information

Requirements Engineering Processes. Feasibility studies. Elicitation and analysis. Problems of requirements analysis

Requirements Engineering Processes. Feasibility studies. Elicitation and analysis. Problems of requirements analysis 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.

More information

Analysis of the Specifics for a Business Rules Engine Based Projects

Analysis of the Specifics for a Business Rules Engine Based Projects 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

More information

Course Outline. Foundation of Business Analysis Course BA30: 4 days Instructor Led

Course Outline. Foundation of Business Analysis Course BA30: 4 days Instructor Led 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

More information

A Methodology for the Development of New Telecommunications Services

A Methodology for the Development of New Telecommunications Services 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

More information

Risk Based Software Development Reducing Risk and Increasing the Probability of Project Success

Risk Based Software Development Reducing Risk and Increasing the Probability of Project Success 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

More information

Creating, Solving, and Graphing Systems of Linear Equations and Linear Inequalities

Creating, Solving, and Graphing Systems of Linear Equations and Linear Inequalities 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

More information

CS 1632 SOFTWARE QUALITY ASSURANCE. 2 Marks. Sample Questions and Answers

CS 1632 SOFTWARE QUALITY ASSURANCE. 2 Marks. Sample Questions and Answers 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

More information

COST EFFECTIVE APPROACHES FOR PRESCRIBED DAM ASSET MANAGEMENT

COST EFFECTIVE APPROACHES FOR PRESCRIBED DAM ASSET MANAGEMENT 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

More information

Do not open this paper until instructed by the invigilator. Please note: This question paper must not be removed from the examination room.

Do not open this paper until instructed by the invigilator. Please note: This question paper must not be removed from the examination room. APM Introductory Certificate in Project Management Exam paper Candidate Reference Number Date of Exam Location of the Exam General Notes Time allowed 1 hour Answer all 60 multiple choice questions Use

More information

Requirements Engineering Processes. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 7 Slide 1

Requirements Engineering Processes. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 7 Slide 1 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

More information

Module 2. Software Life Cycle Model. Version 2 CSE IIT, Kharagpur

Module 2. Software Life Cycle Model. Version 2 CSE IIT, Kharagpur Module 2 Software Life Cycle Model Lesson 3 Basics of Software Life Cycle and Waterfall Model Specific Instructional Objectives At the end of this lesson the student will be able to: Explain what is a

More information

Qualitative Methods in Empirical Studies of Software Engineering. by Carolyn B. Seaman

Qualitative Methods in Empirical Studies of Software Engineering. by Carolyn B. Seaman 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

More information

11 Tips to make the requirements definition process more effective and results more usable

11 Tips to make the requirements definition process more effective and results more usable 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

More information

360 feedback. Manager. Development Report. Sample Example. name: email: date: sample@example.com

360 feedback. Manager. Development Report. Sample Example. name: email: date: sample@example.com 60 feedback Manager Development Report name: email: date: Sample Example sample@example.com 9 January 200 Introduction 60 feedback enables you to get a clear view of how others perceive the way you work.

More information

Tom wants to find two real numbers, a and b, that have a sum of 10 and have a product of 10. He makes this table.

Tom wants to find two real numbers, a and b, that have a sum of 10 and have a product of 10. He makes this table. Sum and Product This problem gives you the chance to: use arithmetic and algebra to represent and analyze a mathematical situation solve a quadratic equation by trial and improvement Tom wants to find

More information

Key functions in the system of governance Responsibilities, interfaces and outsourcing under Solvency II

Key functions in the system of governance Responsibilities, interfaces and outsourcing under Solvency II Responsibilities, interfaces and outsourcing under Solvency II Author Lars Moormann Contact solvency solutions@munichre.com January 2013 2013 Münchener Rückversicherungs Gesellschaft Königinstrasse 107,

More information

Measurement and Metrics Fundamentals. SE 350 Software Process & Product Quality

Measurement and Metrics Fundamentals. SE 350 Software Process & Product Quality Measurement and Metrics Fundamentals Lecture Objectives Provide some basic concepts of metrics Quality attribute metrics and measurements Reliability, validity, error Correlation and causation Discuss

More information

A UML 2 Profile for Business Process Modelling *

A UML 2 Profile for Business Process Modelling * 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

More information

Status Report: Practical Software Measurement

Status Report: Practical Software Measurement Status Report: Practical Software David N. Card, Software Productivity Consortium Cheryl L. Jones, US Army card@software.org Abstract This article summarizes the basic concepts of Practical Software (PSM),

More information

Software Metrics & Software Metrology. Alain Abran. Chapter 4 Quantification and Measurement are Not the Same!

Software Metrics & Software Metrology. Alain Abran. Chapter 4 Quantification and Measurement are Not the Same! 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

More information

[300] Accounting and internal control systems and audit risk assessments

[300] Accounting and internal control systems and audit risk assessments [300] 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

More information

Assignment # 4 Summing up the Course

Assignment # 4 Summing up the Course 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 mnmi07@student.bth.se

More information

Quality Standard Customer Service Complaints Handling

Quality Standard Customer Service Complaints Handling 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

More information

Software Development: An Introduction

Software Development: An Introduction 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

More information

Elicitation and Modeling Non-Functional Requirements A POS Case Study

Elicitation and Modeling Non-Functional Requirements A POS Case Study Elicitation and Modeling Non-Functional Requirements A POS Case Study Md. Mijanur Rahman and Shamim Ripon, Member IACSIT Abstract Proper management of requirements is crucial to successful development

More information

INTERNATIONAL STANDARD ON ASSURANCE ENGAGEMENTS 3000 ASSURANCE ENGAGEMENTS OTHER THAN AUDITS OR REVIEWS OF HISTORICAL FINANCIAL INFORMATION CONTENTS

INTERNATIONAL STANDARD ON ASSURANCE ENGAGEMENTS 3000 ASSURANCE ENGAGEMENTS OTHER THAN AUDITS OR REVIEWS OF HISTORICAL FINANCIAL INFORMATION CONTENTS 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,

More information

The most suitable system methodology for the proposed system is drawn out.

The most suitable system methodology for the proposed system is drawn out. 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.

More information

N Q.3 Choose a level of accuracy appropriate to limitations on measurement when reporting quantities.

N Q.3 Choose a level of accuracy appropriate to limitations on measurement when reporting quantities. 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

More information