1 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 assurance (QA), and software quality In addition, all these QA activities need to be managed in an engineering process we call the software quality engineering process, with quality goals set early in the product development, and strategies for QA selected, carried out, and monitored to achieve these preset quality goals. As part of this overall process, data collected during the QA activities, as well as from the overall development activities, can be analyzed to provide feedback to the software development process for decision making, project management, and quantifiable quality improvement. This book also provides a comprehensive coverage of these topics. 1.2 BOOK ORGANIZATION AND CHAPTER OVERVIEW Figure 1.1. illustrates the general scope of the topics introduced above: Testing is an important subset of QA activities; and QA is an important subset of quality engineering activities. This diagram also explains our book title: Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement. This book is organized in four major parts and 22 chapters, with the main topics outlined below. Part I: Overview and basics Part I gives a general introduction and overview of the topics covered in the book, and presents the basic concepts and definitions related to quality, QA, ing, quality engineering, etc.. Specific questions answered include: About this book: What it is? How to use it? How is it organized? In addition, what background knowledge is needed to have a thorough understanding of the technical aspects of this book? These questions are answered in Chapter 1. What is software quality? In particular, what are the different views of quality? Is quality a single, atomic concept, or does it consist of many different attributes or characteristics? What is the relationship between quality, correctness, and defect? Can we narrow down the definition of quality to better focus our attention on various QA activities commonly carried out during software life cycles? These questions are answered in Chapter 2. What is QA? The question is answered from a particular perspective in Chapter 3, representing a defect-based interpretation of quality and QA. What are the different QA activities and related techniques? A defect-based classification is presented, also in Chapter 3, for the major QA alternatives and techniques, such as ing, inspection, formal verification, fault tolerance, etc.
2 28 Software Quality Engineering c Jeff Tian, to be published by John Wiley, 2005 Input to S/w Dev. e1 e: error source Software System f1 f: fault Usage Scenarios and Results (input/output) x: failure e2 e3 e5 e4 e6 f2 f3 f4 x1 x2 Error Removal Fault Removal Failure Prevention Failure Containment Legend: a a a b presence of "a" removal of "a" "a" causes "b" defect barrier/remover Figure 3.1. Generic ways to deal with defects between these QA activities and related errors, faults, and failures through some specific examples, as follows: Some of the human conceptual errors, such as error source e6, are directly removed by error source removal activities, such as through better education to correct the specific human conceptual mistakes. Other incorrect actions or errors, such as some of those caused by error source e3 and e5, are blocked. If an error source can be consistently blocked, such as e5, it is equivalent to being removed. On the other hand, if an error source is blocked sometimes, such as e3, additional or alternative defect prevention techniques need to be used, similar to the situation for other error sources such as e1, e2, and e4, where faults are likely to be injected into the software system because of these error sources. Some faults, such as f4, are detected directly, i.e., without involving the observation of failures, through inspection or other static analysis, and removed as a part of or as followup to these activities. Other faults, such as f3, are detected through ing or other execution-based QA alternatives by observing their dynamic behavior. If a failure is observed in these QA activities, the related faults are located by examining the execution record and
3 Software Quality Engineering c Jeff Tian, to be published by John Wiley, Requirement & Specification Quality gates: Inspection, review, etc. Design Focus on defect prevention Coding QA Phase Testing Focus on defect removal Release & Support Other QA activities and focus areas Focus on defect containment Figure 4.1. QA activities in waterfall process Because of the possibilities of defect propagations and the increasing cost over time or successive development phases to fix defects once they are injected into the system, we need to reduce the number of faults in software systems by the combination of defect prevention and application of QA techniques that can help remove software faults early. Some defect detection and removal techniques, such as inspection, can be applied to early phases, such as inspecting requirement documents, product specifications, and different levels of product designs. On the other hand, there are practical obstacles to the early fixing of injected defects. For example, dynamic problems may only become apparent during execution; and inter-dependency only becomes apparent with the implementation of related components or modules. Because of these reasons, other fault detection and removal activities, such as ing, are typically concentrated in the middle to late phases of software development. Finally, failure prevention and containment activities, such as fault tolerance and safety assurance, are typically the focus of operational phases. However, their planning, design, and implementation need to be carried out throughout the software development process. In some sense, they are equivalent to adding some necessary functions or features into the existing product to make them safe or fault tolerant. Figure 4.1. illustrate how the different QA activities fit into the waterfall process. Three key characteristics of this activity distribution are illustrated: The phase with QA as the focus: Testing phase. QA activities, typically inspections and reviews, carried out at the transitions from one phase to the next are shown as barriers or gates to pass. The exception to this is between ing and release, where the reviews are typically accompanied by acceptance ing. Other QA activities scatter over all other development phases: The general distribution scope is shown by the dotted bracket, with a focus on defect prevention in the early phases, a focus on defect removal during coding and ing phases, and a focus on defect containment in operational support.
4 Software Quality Engineering c Jeff Tian, to be published by John Wiley, Customer requirements validate Operational use Product specifications verify/validate System other V&V activities High level design Low level design verify verify Component Integration Coding & unit Figure 4.2. Verification and validation activities associated with the V-Model addition, system also validates the product by focusing on how the overall operations under an environment that resembles that for target customers. In a sense, the users operational environment is captured as part of the product specification or as part of the ing model. At the bottom, coding and unit ing are typically grouped in a single phase, where the code itself specifies the expected behavior and needs to be verified through unit. Sometimes, various other QA activities, such as inspections, reviews, walkthroughs, analyses, formal verification, etc., are also associated with the left arm of the V-model and illustrated by additional dotted lines pointed to the specific phases. Similar to the mapping of QA activities to other process models above, validation and verification activities can be mapped into non-sequential processes such as incremental, iterative, spiral, and extreme programming processes. Typically, there is some level of user involvement in each part or iteration. Therefore, validation plays a more important role in these processes than in waterfall process or V-model. 4.4 RECONCILING THE TWO VIEWS The above descriptions of verification and validation activities included examples of specific QA activities. These specific QA activities were also classified using our scheme according to the generic ways of dealing with defects. Through this connection and the inter-relations represented therein, we can establish the relationship and the mapping between the verification and validation (V&V) view on the one hand and our defect-centered (DC) view and classification on the other hand. In addition, we can use the process information as presented in Figure 4.1., Figure 4.2., and related discussions to help us with this mapping, as discussed below.
5 52 Software Quality Engineering c Jeff Tian, to be published by John Wiley, 2005 Set quality goals Entry Quality Planning Selected QA activities Quality Assurance Activities Feedbcak & adjustments No Quality goals satisfied? Yes Exit Measurements Selected measurements & models Quality Assessment & Improvement Analysis/ modeling results Figure 5.1. Quality engineering process 1. Pre-QA activities: Quality planning. These are the activities that should be carried out before carrying out the regular QA activities. There are two major types of pre-qa activities in quality planning, including: (a) Set specific quality goals. (b) Form an overall QA strategy, which includes two sub-activities: i. Select appropriate QA activities to perform. ii. Choose appropriate quality measurements and models to provide feedback, quality assessment and improvement. A detailed description of these pre-qa activities is presented in Section In-QA activities: Executing planned QA activities and handling discovered defects. In addition to performing selected QA activities, an important part of this normal execution is to deal with the discovered problems. These activities were described in the previous two chapters. 3. Post-QA activities: Quality measurement, assessment and improvement These are the activities that are carried out after normal QA activities have started but not as part of these normal activities. The primary purpose of these activities is to provide quality assessment and feedback so that various management decisions can be made and possible quality improvement initiatives can be carried out. These activities are described in Section 5.3. Notice here that post-qa does not mean after the finish of QA activities. In fact, many of the measurement and analysis activities are carried out parallel to QA activities after they are started. In addition, pre-qa activities may overlap with the normal QA activities as well. Pre-QA quality planning activities play a leading role in this quality engineering process, although the execution of selected QA activities usually consumes the most resources. Quality goals need to be set so that we can manage the QA activities and stop them when the quality goals are met. QA strategies need to be selected, before we can carry out specific QA activities, collect data, perform analysis, and provide feedback.
6 Software Quality Engineering c Jeff Tian, to be published by John Wiley, Quality Planning: Setting quality goals Select quality assurance strategies Making adjustments based on feedback Quality Assurance: QA Phase: Testing Quality gates: at phase transition pairs, e.g., passing design reviews before coding Other QA activities scattered over all phases, e.g. inspecting specs/desing/code/ cases Quality Assessment and Improvement INPUT: measurement from QA and development activities OUTPUT: quality assessment and other analysis results Requirement & Specification Design Coding Testing Release & Support Figure 5.2. Quality engineering in the waterfall process All these activities typically last over the whole development process, with different subactivities carried out in different phases. This is particularly true for the QA activities, with ing in the phase, various reviews or inspections at the transition from one phase to its successor phase, and other QA activities scattered over other phases. Minor modifications are needed to integrate quality engineering activities into other development processes. However, the distribution of these activities and related effort is by no means uniform over the activities or over time, which is examined next Effort profile Among the three major types of activities in the quality engineering process, the execution of specific QA activities is central to dealing with defects and assuring quality for the software products. Therefore, they should and normally do consume the most resources in terms of human effort as well as utilization of computing and other related resources. However, the effort distribution among the three is not constant over time because of the process characteristics described above and the shifting focus over time. Some key factors that affect and characterize the effort profile, or the effort distribution over time, include: Quality planning drives and should precede the other two groups of activities. Therefore, at the beginning part of product development, quality planning should be the dominant part of quality engineering activities. Thereafter, occasional adjustments
7 Software Quality Engineering c Jeff Tian, to be published by John Wiley, Total Effort Product Release Quality Analysis Quality Assurance Quality Planning Development Time Figure 5.3. effort Quality engineering effort profile: The share of different activities as part of the total In addition, the general shape and pattern of the profile such as in Figure 5.3. should preserve regardless of the specific development process used. Waterfall process would see more dominance of quality planning in the beginning, and dominance of ing near product release, and measurement and quality assessment activities peak right before product release. Other development processes, such as incremental, iterative, spiral, and extreme programming processes, would be associated with curves that vary less between the peaks and valleys. QA is spread out more evenly in these processes than in the waterfall process, although it is still expected to peak a little bit before product release. Similarly, measurement and analysis activities are also spread out more evenly to monitor and assess each part or increment, with the cumulative modeling results used in product release decisions. There are also more adjustments and small scale planning activities involved in quality planning, which also makes the corresponding profiles less variable as well. 5.5 CONCLUDING REMARKS To manage the quality assurance (QA) activities and to provide realistic opportunities of quantifiable quality improvement, we need to go beyond QA to perform the following: Quality planning before specific QA activities are carried out, in the so-called pre-qa activities in software quality engineering. We need to set the overall quality goal by managing customer s quality expectations under the project cost and budgetary constraints. We also need to select specific QA alternatives and techniques to implement as well as measurement and models to provide project monitoring and qualitative feedback. Quality quantification and improvement through measurement, analysis, feedback, and followup activities. These activities need to be carried out after the start of specific QA activities, in the so-called post-qa activities in software quality engineering. The analyses would provide us with quantitative assessment of product quality, and
8 Software Quality Engineering c Jeff Tian, to be published by John Wiley, Set reliability/coverage goals Planning & Preparation Entry goal setting information gathering model construction cases procedure Test cases & procedure Measurements Execution No Reliability/ coverage goals Feedbcak & satisfied? adjustments Yes Exit Selected measurements & models Defect handling Analysis & Followup Analysis/ modeling results Figure 6.1. Generic ing process observations. In fact, many forms of informal ing include just this middle group of activities related to execution, with some informal ways to communicate the results and fix the defects, but without much planning and preparation. However, as we will see in the rest of Part II, in all forms of systematic ing, the other two activity groups, particularly planning and preparation activities, play a much more important role in the overall ing process and activities. The execution of a specific case, or a sub-division of the overall execution sequence for some systems that require continuous operation, is often referred to as a run. One of the key component to effective execution is the handling of problems to ensure that failed runs will not block the executions of other cases. This is particularly important for systems that require continuous operation. To many people, defect fixing is not considered to be a part of ing, but rather a part of the development activities. However, re-verification of problem fixes is considered as a part of ing. In this book, we consider all of these activities as a part of ing. Data captured during execution and other related measurements can be used to locate and fix the underlying faults that led to the observed failures. After we have determined if a run is a success or failure, appropriate actions can be initiated for failed runs to locate and fix the underlying faults. In addition, further analyses can be performed to provide valuable feedback to the ing process and to the overall development process in general. These analysis results provide us with assessments of the current status with respect to progress, effort, defect, and product quality, so that decisions, such as when to stop ing, can be made based on facts instead of on people s gut feelings. In addition, some analyses can also help us identify opportunities for long term product quality improvement. Therefore, various other activities, such as measurement, analysis, and followup activities, also need to be supported. Sub-activities in planning and preparation Because of the increasing size and complexity of today s software products, informal ing without much planning and preparation becomes inadequate. Important functions, features, and related software components and implementation details could be easily overlooked in such informal ing. Therefore, there is a strong need for planned, monitored, managed and optimized ing strategies based on systematic considerations for quality, formal models, and related techniques. Test cases can be planned and prepared using such ing
9 204 Software Quality Engineering c Jeff Tian, to be published by John Wiley, 2005 Customer requirements validate Operational use diagnosis beta Product specifications verify/validate System acceptance other V&V activities High level design Low level design verify verify Integration Component regression Coding & unit Figure Testing sub-phases associated with the V-Model Testing sub-phases Figure illustrates the ing sub-phases through the use of V-model, a variation of the commonly used waterfall process with an emphasis on verification and validation activities. It shows an annotated V-model with additional information about the specific ing subphases. All the sub-phases not included in the original V-model are shown in dashed boxes, with their relationship to the other sub-phases also illustrated. Specific information about these sub-phases is described below: When problems are reported by customers during operational use, diagnosis ing can be used to recreate and diagnose the problems. Diagnosis ing can also be used for other sub-phases of ing for the same purpose as well, as illustrated by the downward arrow in Figure Controlled product release and operational use by limited customers lead to beta ing. Beta ing can be considered as an additional ing sub-phase closely linked to operational use. It often directly precedes operational use or is carried out at the very beginning of it, as depicted accordingly in Figure A special ing sub-phases, acceptance ing, is attached to the end of system ing, because it is typically performed right after system ing to determine if the product should be released. Sometimes, the late part of system ing is used as acceptance instead of a dedicated acceptance ing sub-phases. Therefore, we also show possible overlap between the two in Figure As a direct division of the ing phase in the waterfall process, several specific subphases of ing, such as system ing, integration ing, and component ing
Software Engineering Introduction & Background Department of Computer Science Kent State University Complaints Software production is often done by amateurs Software development is done by tinkering or
Software Engineering Prof. N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture - 2 Introduction to Software Engineering Challenges, Process Models etc (Part 2) This
Title: Topic 3 Software process models (Topic03 Slide 1). Topic 3: Lecture Notes (instructions for the lecturer) Author of the topic: Klaus Bothe (Berlin) English version: Katerina Zdravkova, Vangel Ajanovski
Process Models and Metrics PROCESS MODELS AND METRICS These models and metrics capture information about the processes being performed We can model and measure the definition of the process process performers
Fault Slip Through Measurement in Software Development Process Denis Duka, Lovre Hribar Research and Development Center Ericsson Nikola Tesla Split, Croatia email@example.com; firstname.lastname@example.org
Agile Development and Testing Practices highlighted by the case studies as being particularly valuable from a software quality perspective Iteration Advantages: bringing testing into the development life
What is a life cycle model? Framework under which a software product is going to be developed. Defines the phases that the product under development will go through. Identifies activities involved in each
Master Thesis Software Engineering Thesis no: MSE-2007:02 January 2007 Metrics in Software Test Planning and Test Design Processes Wasif Afzal School of Engineering Blekinge Institute of Technology Box
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) ANALYTICAL COMPARISON AND SURVEY ON TRADITIONAL AND AGILE METHODOLOGY Sujit Kumar Dora 1 and Pushkar Dubey 2 1 Programmer, Computer Science & Engineering, Padmashree
Software Development Process A software development process, also known as software development lifecycle, is a structure imposed on the development of a software product. Similar terms include software
Note: This material is for Evaluators reference only. Caters to answers of CSTE Mock Test - Part I paper. 1. A branch is (Ans: d) a. An unconditional transfer of control from any statement to any other
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
System/Software Development Life Cycle Anurag Srivastava Associate Professor ABV-IIITM, Gwalior Why Life Cycle Approach for Software? Life cycle is a sequence of events or patterns that are displayed in
4 Software Development Life Cycle M MAJOR A J O R T TOPICSO P I C S Objectives... 52 Pre-Test Questions... 52 Introduction... 53 Software Development Life Cycle Model... 53 Waterfall Life Cycle Model...
Software Engineering An Introduction Fakhar Lodhi 1 Engineering The science concerned with putting scientific knowledge to practical use. Webster s Dictionary Physics versus Electrical Engineering 2 Software
Failure Mode and Effect Analysis Lecture 4-3 Software Failure Mode and Effects Analysis in Software Software Development, Pries, SAE Technical Paper 982816 Software Development is Different Process variation
CS 451 Software Engineering Winter 2009 Yuanfang Cai Room 104, University Crossings 215.895.0298 email@example.com 1 Testing Process Testing Testing only reveals the presence of defects Does not identify
Life Cycle Models V. Paúl Pauca Department of Computer Science Wake Forest University CSC 331-631 Fall 2013 Software Life Cycle The overall framework in which software is conceived, developed, and maintained.
SYSTEM DEVELOPMENT AND THE WATERFALL MODEL What is a System? (Ch. 18) A system is a set of integrated components interacting with each other to serve a common purpose. A computer-based system is a system
How era Develops Software Executive Summary: In an organized, iterative, carefully documented manner, era has built a dense infrastructure of methodology, standards, and procedures to underpin the development
Software Process Models Xin Feng Questions to Answer in Software Engineering? Questions to answer in software engineering What is the problem to be solved? Definition What are the characteristics of the
T-76.5613 Software Testing and Quality Assurance Lecture 2, 13.9.2006 Basic Testing Concepts and Terminology Juha Itkonen SoberIT Contents Realities and principles of Testing terminology and basic concepts
THE ONLY BOOK CAN SIMPLY LEARN SOFTWARE TESTING! Page 1 Contents ABOUT THE AUTHOR... 3 1. Introduction To Software Testing... 4 2. What is Software Quality Assurance?... 7 3. What Is Software Testing?...
Nova Software Quality Assurance Process White Paper Atlantic International Building 15F No.2 Ke Yuan Yi Road, Shiqiaopu, Chongqing, P.R.C. 400039 Tel: 86-23- 68795169 Fax: 86-23- 68795169 Quality Assurance
Using TechExcel s DevSuite to Achieve FDA Software Validation Compliance For Medical Software Device Development The FDA requires medical software development teams to comply with its standards for software
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.
Central Page 284 of 296 Application of software product quality international standards through software development life cycle Mladen Hosni, Valentina Kirinić Faculty of Organization and Informatics University
Noorul Islam College of Engineering M. Sc. Software Engineering (5 yrs) IX Semester XCS592- Software Project Management 8. What is the principle of prototype model? A prototype is built to quickly demonstrate
PROCESS OF MOVING FROM WATERFALL TO AGILE PROJECT MANAGEMENT MODEL Sanja Vukićević 1, Dražen Drašković 2 1 Faculty of Organizational Sciences, University of Belgrade, firstname.lastname@example.org 2 Faculty
Various Software Development Life Cycle Models Sahil Jindal, Puneet Gulati, Praveen Rohilla Dronacharya College of Engineering, India Abstract:An SDLC model is a conceptual framework describing different
Life-Cycle Model Software Life-Cycle Models Xiaojun Qi It specifies the various phases/workflows of the software process, such as the requirements, analysis (specification), design, implementation, and
CSE 435 Software Engineering Sept 16, 2015 2.1 The Meaning of Process A process: a series of steps involving activities, constraints, and resources that produce an intended output of some kind A process
Processing Models Of SDLC Mrs. Nalkar Sanjivani Baban Asst. Professor, IT/CS Dept, JVM s Mehta College,Sector 19, Airoli, Navi Mumbai-400708 Nalkar_sanjivani@yahoo.co.in Abstract This paper presents an
Subject: Software Development to Question No: 1 Page 1 of 2 Allocation: 33 marks (a) (i) A layout manager is an object that implements the LayoutManager interface and determines the size and position of
Total Quality 1) Quality 1.1 Quality assurance (QA) refers to the engineering activities implemented in a quality system so that requirements for a product or service will be fulfilled. It is the systematic
Quality Management Systems (QMS) for Software Preview: This lecture covers the following topics: Historical perspective of QMS Elements of QMS Procedures in a quality management system Statistical Process
Software Testing Trends in Australia and Beyond Jason Lee Dolby Laboratories Australia Mark Pedersen K.J. Ross & Associates Australia Abstract This presentation looks at trends in software testing within
Development models R. Kuiper and E.J. Luit 1 Introduction We reconsider the classical development models: the Waterfall Model [Bo76], the V-Model [Ro86], the Spiral Model [Bo88], together with the further
INTRODUCTION : Fundamentals of Software Engineering (Compulsory) This course is designed to provide the students with the basic competencies required to identify requirements, document the system design
Estimating Software Reliability In the Absence of Data Joanne Bechta Dugan (email@example.com) Ganesh J. Pai (firstname.lastname@example.org) Department of ECE University of Virginia, Charlottesville, VA NASA OSMA SAS
PART A Questions 1. Mention any two software process models. 2. Define risk management. 3. What is a module? 4. What do you mean by requirement process? 5. Define integration testing. 6. State the main
Information Systems Development Process (Software Development Life Cycle) Phase 1 Feasibility Study Concerned with analyzing the benefits and solutions for the identified problem area Includes development
Software Development Lifecycle Steve Macbeth Group Program Manager Search Technology Center Microsoft Research Asia About Me Currently manage a team of 10 Program Managers at Microsoft Research Asia Over
A Comparison of System Dynamics (SD) and Discrete Event Simulation (DES) Al Sweetser Andersen Consultng 1600 K Street, N.W., Washington, DC 20006-2873 (202) 862-8080 (voice), (202) 785-4689 (fax) email@example.com
11 PROJECT RISK MANAGEMENT Project Risk Management includes the processes concerned with identifying, analyzing, and responding to project risk. It includes maximizing the results of positive events and
Agile Software Development Methodologies and Its Quality Assurance Aslin Jenila.P.S Assistant Professor, Hindustan University, Chennai Abstract: Agility, with regard to software development, can be expressed
JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2006 Vol. 5. No. 8, November-December 2006 Requirements Engineering Tasks Donald Firesmith,
Master Thesis Software Engineering Thesis no: MSE-2010:33 November 2010 Identification and Analysis of Combined Quality Assurance Approaches Vi Tran Ngoc Nha School of Computing Blekinge Institute of Technology
Meeting DO-178B Software Verification Guidelines with Coverity Integrity Center May, 2009 Thomas Schultz Director of Product Strategy, Coverity, Inc. Executive Summary Development organizations that create
Page 1 SECTION 4 TESTING & QUALITY CONTROL TESTING METHODOLOGY & THE TESTING LIFECYCLE The stages of the Testing Life Cycle are: Requirements Analysis, Planning, Test Case Development, Test Environment
Best-Practice Software Engineering: Software Processes to Support Project Success Dietmar Winkler Vienna University of Technology Institute of Software Technology and Interactive Systems Dietmar.Winkler@qse.ifs.tuwien.ac.at
JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2006 Vol. 5, No. 6, July - August 2006 On Assuring Software Quality and Curbing Software
DOCUMENT: Future AAMI/IEC 62304:2006/AMD1, 18-August-2015 Final Draft International Standard for Vote, Amendment 1 to IEC 62304: Medical device software Software life cycle processes. Public Review Draft
Personal Software Process (PSP) Application of CMM principles to individuals Developed by Watts Humphrey of the Software Engineering Institute (SEI) in the early 1990s Extensive supporting materials: books,
Software Development Process Models Balasankar C S1 M.Tech CSE 1 / 24 Software Development Process Models Activities directly related production design, coding, testing Specifies major development & quality
D6 INFORMATION SYSTEMS DEVELOPMENT. SOLUTIONS & MARKING SCHEME. June 2013 The purpose of these questions is to establish that the students understand the basic ideas that underpin the course. The answers
Course: Quality Management, DPT404 Teacher: Conny Johansson Department: IDE, University Of Karlskrona/Ronneby The V-Model Prepared for Conny Johansson Conny.Johansson@ide.hk-r.se IDE, University Of Karlskrona/Ronneby
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
CHAPTER Software Process Models 4 Chapter Objectives Introduce the generic concept of software engineering process models. Discuss the three traditional process models. Waterfall Incremental Spiral Discuss
Module 10 Coding and Testing Lesson 23 Code Review Specific Instructional Objectives At the end of this lesson the student would be able to: Identify the necessity of coding standards. Differentiate between
2009 International Conference on Computer Engineering and Applications IPCSIT vol.2 (2011) (2011) IACSIT Press, Singapore Umbrella: A New Component-Based Software Development Model Anurag Dixit and P.C.
Classical Software Life Cycle Models SWEN 301 Trimester 1, 2015 Lecturer: Dr Hui Ma Engineering and Computer Science Lecture slides make use of material provided on the textbook's companion website Motivation
Chakra - A new era in Software Lifecycle modeling technique R.P.Muthu Assistant Professor, Department of Computer Science Indian Institute of Technology, Bombay. Abstract: Every old thing has to be modified
A Guide To The Project Body of Knowledge (PMBOK) Significant Changes from the 3 rd edition to the 4 th edition Major Changes The adoption of the verb-noun format for process names Amplification as to Enterprise
Process Mapping Guidelines FLOWCHART SYMBOLS The following are the primary symbols: SYMBOL NAME DESCRIPTION Activity/Processing Decision Document Direction of Flow Chart Connections Indicates that an activity
5.1 Project Control Overview Project Control is a formal process in project management. In most respects, there is not a lot of room for creativity in the Control Phase of project management. The PMBOK
International Journal of Research in Information Technology (IJRIT) www.ijrit.com ISSN 2001-5569 A Comparison between Five Models of Software Engineering Surbhi Gupta, Vikrant Dewan CSE, Dronacharya College
Process Methodology for Wegmans Deli Kiosk Version 1.0 Prepared by DELI-cious Developers Rochester Institute of Technology September 15, 2013 1 Table of Contents 1. Process... 3 1.1 Choice... 3 1.2 Description...
Test-Driven Development Educator s Session November 13, 2012 Outline Software Quality Overview of Testing Automated Testing Tools Test-Driven Development Educator's Session 2 SOFTWARE QUALITY Educator's
E90 Engineering Design Notes on the Critical Path Method for project planning and management. CPM models any project by a network of blocks or circles called NODES that are connected by lines called ARROWS.
A methodology for knowledge based project management (Work in progress) Patrick Onions firstname.lastname@example.org 23 January 2007 The characteristics of our late 20th century society demand the development
Unit I Introduction Product Life Cycles Products also have life cycles The Systems Development Life Cycle (SDLC) is a framework for describing the phases involved in developing and maintaining information
Quality Management Lecture 12 Software quality management doc.dr.sc. Marko Jurčević prof.dr.sc. Roman Malarić University of Zagreb Faculty of Electrical Engineering and Computing Department of Fundamentals
From Chaos to Clarity: Embedding Security into the SDLC Felicia Nicastro Security Testing Services Practice SQS USA Session Description This session will focus on the security testing requirements which