Gradational conception in Cleanroom Software Development
|
|
- Coleen Dean
- 6 years ago
- Views:
Transcription
1 Gradational conception in Cleanroom Software Development Anshu Sharma 1 and Shilpa Sharma 2 1 DAV Institute of Engineering and Technology, Kabir Nagar, Jalandhar, India 2 Lovely Professional University, Department of Computer Science and Engineering, Jalandhar, India Abstract: The aim of this paper is to lay down the idea and practical application of gradational conception in cleanroom software engineering process. Gradational development is based on the mathematical principle of referential transparency. Cleanroom software engineering process makes use of gradients or increments to develop the software product in sequence or series of additive subsets of user functions. The gradients are aggregated in the top down manner into the final product in the conception and the certification pipeline. The various factors that must be considered for the development of gradients understand of the requirements, complexity, reliability, requirement for sub system, clarity of user functions, dependencies between functions and reusability. Keywords: Gradient conception, cleanroom software engineering, software life cycle, referential transparency. 1. INTRODUCTION The main purpose of using cleanroom software engineering is to transform from individual craftsmanship to peered review engineering, sequential development to gradational development, individual unit testing to team correctness verification, unmeasured reliability to measured reliability. The central fundamental of cleanroom software process is the software development based on formal methods and control implementation under statistical quality measurement. The cleanroom software engineering process deals with various methods of software specification, design or verification/validation testing and finally to get quality certification. It starts up with small unit and end up with fully integrated product by using top-down methodology. The cleanroom strategy contains four parts i.e Part1 consists of incremental planning, requirement gathering, and box structure specification. Part2 consists of formal design and correctness verification. Part3 consists of code generation, inspection, verification and statistical testing and part4 contains statistical use testing and certification. Figure 1 Cleanroom Software Engineering Process [5] There are basically three teams to perform the various activities and they are: 1. Specification Team: It deals with the hardware/ software requirement definitions, design and implementation of the software gradients. 2. Certification Team: it deals with the quality assurance by using various methods. 3. Development Team: This team is responsible for developing and verifying the software. The code inspection is performed for the correctness.[1] 2. EASE OF USE 1. Proper Control on Each Process: This technique gives the proper control over gradation development of software through the properties of referential transparencies. It also deals with the state date and responses based on stimuli Volume 1, Issue 2 July-August 2012 Page 150
2 histories. By verifying the result with the previous result one can improve or control on each and every process. It combines many of formal methods and software quality methods to get better decision and help in developing the error free products. Figure 2 Control Process It also enables cleanroom team to perform various activities simultaneously. The product will undergo well proved increments and get the feedback. Many specifications and models help keep a product longer periods of time. 2. Zero failure in the field: this is the main objective of this paper. It gives less than five failures per KLOC. New teams should experience a productivity increase in their first project and continue the increase. Correctness questions are asked and answered then formal mathematical verification is done. 3. Implemented gradually with higher quality: The significant advantage of cleanroom software engineering is that it can be developed gradually. While the activities involved in cleanroom software engineering is very strict so it attain a higher quality. It deals with the deeper understanding of the requirements, design and code by all verifiers involved. 4. Deals with formal design: It works on the specifications that are iteratively refined to become the architectural designs and component level designs. Cleanroom software engineering uses the box structure specification to define the products. Figure 3 Formal Design Once the requirements are fixed then functional and behavior of each gradation must be defined. At the end of each process the teams should have design resembling structure programming of their language of choice [2]. 3. PROPOSED WORK The overall objective of the gradational development is to grow a system with each new gradient as an elaboration of the functions implemented in previous gradients. The new function in gradient should be plug-in to the previous gradient at predefined point in its structure and should satisfy the sub specifications associated with the processing requirements at those points. This process of function allocation is the practical implementation of referential transparency to gradational conception planning. Thus, logical allocation of functions to gradients based on relationship among functions and intrinsic functional dependencies will predominate in the definition of gradient content. In a database system, for example, functions to add data would typically precede functions to delete data. In a statistical system, functions to collect and enter data would ordinarily precede functions to analyze data and report results. 3.1 Cleanroom Software Engineering Cleanroom defines formal methods of requirement and design with statistical usage testing to produce software with nearly none or zero defects. Software engineering emphasizes following a process model that separates requirements, design, coding, testing and the other steps. The cleanroom process embeds software development and testing within a statistical quality control framework. Mathematically based software development processes are employed to create software that is correct by design and statistical usage testing processes are employed to provide inferences about software reliability. This systematic process of accessing and controlling software quality during development permits the certification of software fitness for use at delivery. Cleanroom management is based on development and certification of pipeline of user function gradients that execute in a system environment and accumulate top down into the final product. Cleanroom teams interact with the variety of peer organizations depending on organizational and project context. System engineering and system test organizations may be involved in embedded software projects, standards, procurement and quality assurance. Organizations may be involved in large projects, configuration management, documentation and organizational software engineering process. The customer is part of cleanroom team as well. The term customer may mean external institutional sponsor, internal organizational sponsor, end user or any other party that is appropriate for defining requirement and evaluating the evolving system. 3.2 Key ideas in Gradational Conception The purpose of Gradient Planning Process is to: Allocate customer requirements defined in function Volume 1, Issue 2 July-August 2012 Page 151
3 specification to a series of software gradients that satisfies software architecture. Define schedule and resource allocation for gradient development and certification. Obtain agreement with the customer on the gradient plan. Increments are designed and implemented as usage hierarchies through box structure decomposition. This process preserves referential transparency between successive decomposition to maintain intellectual control. Increments designs can be expressed in object, functions or any other form. Each increment is based on a prior specification. Increment specifications are expressed in stimulus history based black box and state based state box forms. Increment designs and implementations are expressed in procedure based clear box forms that can introduce new black boxes for further decomposition. Reused or reengineered components are incorporated as planned. Team reviews during the increment design process focus on issues such as clarity, maintainability, reuse and conformance to style. In the companion correctness verification process, the team focuses exclusively on correctness. Specifications, designs and implementation evolve during the increment design process and intended functions are embedded in clear box procedure decomposition to permit effective correctness verification. The team performs correctness verification as the last intellectual pass through the work. The development team does not execute the increment implementation. First execution is performed by the certification team in the statistical testing and certification process after the development team has completed verification in the correctness verification process. Cleanroom minimizes the risk of integration faults through development based on the mathematical principle of referential transparency. Referential transparency in box structure hierarchies requires that the black box specifications embedded in clear boxes at each level of decomposition into state and clear boxes. With referential transparency, intellectual control is maintained and independent work at lower levels can proceed without concern for functional interactions at higher level. 4. EQUATIONS The black box gives the transition rules that specify the product behavior as response to particular stimuli by using the concept of OO inheritance concept. SH (Stimulus History) R (response) It specifies the system properties and functions by mapping all possible stimulus histories to all possible response. State box encapsulates the information (state Data) and operations similar to an object, the stimuli (inputs) and response (output) are represented, the information must be fetched between transitions. The state is the encapsulation of the stimulus history. SH * SD R * SD Stimulus history * State Data Response * State Data Clear box contains the algorithm design of state box similar to the structure programming. It gives both data flow and control flow. It also allows updating the state data and response [3]. 5. THEORETICAL FOUNDATION OF GRADATIONAL CONCEPTION Cleanroom software development is based upon the mathematical principle of referential transparency. Referential transparency in box structure hierarchies requires that the black box specifications embedded in clear boxes at each level of decomposition precisely define the required functional behavior of their subsequent decompositions into state and clear boxes. With referential transparency, intellectual control is maintained and independent work at lower levels can proceed without concern for functional interactions at higher levels. Referential transparency is the special property of arithmetic mathematics that computes large and complex expressions at one goes and gives the correct answer. It deals with the concept that operands value matters a lot in the equation its operands can be changed with other but same in value within a specific range. Table 1: Referential transparency in various systems Once referential transparency has been established for a particular system or for a particular programming language, cleanroom incremental development and verification techniques are guaranteed to work for any application that is developed in that language. In applying cleanroom to object oriented development, the functional description of objects and their methods must be enhanced to establish referential transparency [4]. Referential transparency can be applied in a formal way to full scale system development projects. 6. PROCESS MODEL The gradational conception or we can say incremental development is the life cycle process model. It is the standardized format of planning, organizing and running the new development products. Cleanroom software Volume 1, Issue 2 July-August 2012 Page 152
4 development products usually deal with the fixed financial budget, time constraints and other product constraints. Figure 4 Project Constraints There are hundreds of life cycle models like waterfall model, spiral model, iterative model and many more. By changing the life cycle model, we can improve or tradeoff product quality, product visibility, development time, risk reduction etc. use best strategies to remove risk factors. The spiral is visualized as a process passing through some number of iterations, with the four quadrants that represents the following activities: A. Formulate plans to identify software targets selected to implement the program, clarify the project development restrictions. B. Risk analysis that is an analytical assessment of selected programs to consider how to identify and eliminate risk. C. The implementation of the project for the development and verification. Risk driven spiral model emphasizing the conditions of options and constraints in order to support software reuse, software quality can help as a special goal of integration into the product development. 6.3 Incremental Life Cycle Model It is also known as loop approach. In 1988 Boehm developed the iterative model which includes risk analysis and risk management. It takes the core part and adds the functionality after every successful iteration. The incremental model is an intuitive approach to the waterfall model. Multiple development cycles take place making a life cycle as multi waterfall cycle cycles are divided up into smaller, more easily managed iterations. Each iteration passes through the requirements, design, implementation and testing phases. The working version of the software is produced during the first iteration, so one can have working software early on during the software life cycle. Subsequent iterations build on the initial software produced during the first iterations. Figure 5 Software Development Life Cycle The various models that can be used for the gradational conception in cleanroom software development are as follows: 6.1 Waterfall Model It is easy to understand and work well matured products and weak team but it does not match real world. It is the theoretical model to understand the product properly. In a strict waterfall model, after each phase is finished, it proceeds to the next one. Reviews may occur before moving to the next phase which allows for the possibility of changes. Reviews may also be employed to ensure that the phase is indeed complete. The phase completion criteria are often referred to as a gate that the project must pass through to move to the next phase. Waterfall discourages revisiting and revising any prior phase once it s complete. 6.2 Spiral Life Cycle Model Since end user requirements are hard to obtain, it is natural to develop software in an experimental way and 7. CONCLUSION Cleanroom software engineering is an engineering and managerial process for the development of high quality software with certified reliability. The main aim is to prevent the software errors as they occur. Testing should not be the only place where the errors must be caught, but the design phase as well. One of the main components of the cleanroom software engineering is gradational development. In gradational conception process of cleanroom software engineering, each gradient is developed separately and tested in a simulated production environment. This way the test result will speak about the quality of sub system. If the gradient adheres to the pre defined quality standards, then the next gradient development process is started. If not then development is stopped and the process is fixed. The results of the gradients can use in the improvement of the quality of the next gradient. Gradient prototyping and spiral life cycle model are useful to manage the risks. Each gradient is a complete iteration in the life cycle. This makes the process more Volume 1, Issue 2 July-August 2012 Page 153
5 successful. The mathematical principle of referential transparency proved to be very useful in defining gradients that can be implemented as a sub system. References [1] Stacy J. Powell, Carmen J. Trammell, Richard C. Linger, Jessy H. Poore, Cleanroom software engineering: technology and process. [2] Carmen J. Trammell, Richard C. Linger, Cleanroom software engineering version 1 November [3] Carmen J. Trammell, Mark G. Pleszkoch, Richard C. Linger, Allan R. Hevner The Incremental Development Process in Software Engineering in Decision Support System 17 (1996) [4] Richard C. Linger, Carmen J. Trammel technical Report on cleanroom software engineering reference model November 1996 [5] Chaelynne M. Wolak, Taking the art out of Software Development an In-Depth Review of Cleanroom Software Engineering AUTHOR Anshu Sharma received the B.E degree in Computer Science and Engineering from Lovely Institute of technology in And currently perusing M.S. degrees in Computer Science and Engineering from DAV Institute of Engineering and Technology, Jalandhar. Shilpa Sharma received the B.E degree in Computer Science and Engineering from Lovely Institute of technology in And currently perusing M.S. degrees in Computer Science and Engineering from DAV Institute of Engineering and Technology, Jalandhar. Volume 1, Issue 2 July-August 2012 Page 154
Framework for Improvement in Cleanroom Software Engineering Thesis Submitted in the partial fulfillment of requirements for the award of the degree
Framework for Improvement in Cleanroom Software Engineering Thesis Submitted in the partial fulfillment of requirements for the award of the degree of Master of Engineering in Software Engineering By:
More informationKey Features. Defect Rates. Traditional Unit testing: 25 faults / KLOC System testing: 25 / KLOC Inspections: / KLOC
Cleanroom attempt to mathematically-based, scientific engineering process of software development Cleanroom software engineering yields software that is correct by mathematically sound design, and software
More informationCleanroom Software Engineering Reference
Carnegie Mellon University Research Showcase @ CMU Software Engineering Institute 11-1996 Cleanroom Software Engineering Reference Richard C. Linger Carnegie Mellon University, rlinger@sei.cmu.edu Carmen
More informationCleanroom Software Engineering
Cleanroom Software Engineering Abstract There are circumstances where quality is paramount, and any kind of error cannot be tolerated. When these circumstances arise, special measures need to be taken
More informationCS SOFTWARE ENGINEERING QUESTION BANK SIXTEEN MARKS
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS 6403 - SOFTWARE ENGINEERING QUESTION BANK SIXTEEN MARKS 1. Explain iterative waterfall and spiral model for software life cycle and various activities
More informationCleanroom Software Engineering
Cleanroom Software Engineering Software Testing and Verification Lecture 25 Prepared by Stephen M. Thebaut, Ph.D. University of Florida Required Reading and Additional Reference Required Reading: Linger,
More informationSystems Analysis & Design
Systems Analysis & Design Dr. Ahmed Lawgali Ahmed.lawgali@uob.edu.ly Slide 1 Systems Analysis & Design Course Textbook: Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition
More informationSoftware Verification and Validation (VIMMD052) Introduction. Istvan Majzik Budapest University of Technology and Economics
Software Verification and Validation (VIMMD052) Introduction Istvan Majzik majzik@mit.bme.hu Budapest University of Technology and Economics Dept. of Measurement and Information s Budapest University of
More informationCleanroom Software Engineering
Cleanroom Software Engineering Software Testing and Verification Lecture 25 Prepared by Stephen M. Thebaut, Ph.D. University of Florida Required Reading and Additional Reference Required Reading: Linger,
More informationIncremental development A.Y. 2018/2019
Incremental development A.Y. 2018/2019 Incremental development Interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with
More informationSystem Development Life Cycle Methods/Approaches/Models
Week 11 System Development Life Cycle Methods/Approaches/Models Approaches to System Development System Development Life Cycle Methods/Approaches/Models Waterfall Model Prototype Model Spiral Model Extreme
More informationIntroduction. Chapter 1. What Is Visual Modeling? The Triangle for Success. The Role of Notation. History of the UML. The Role of Process
Quatrani_Ch.01.fm Page 1 Friday, October 27, 2000 9:02 AM Chapter 1 Introduction What Is Visual Modeling? The Triangle for Success The Role of Notation History of the UML The Role of Process What Is Iterative
More informationIntroduction to Software Engineering
Introduction to Software Engineering Gérald Monard Ecole GDR CORREL - April 16, 2013 www.monard.info Bibliography Software Engineering, 9th ed. (I. Sommerville, 2010, Pearson) Conduite de projets informatiques,
More informationSoftware Development Chapter 1
Software Development Chapter 1 1. Introduction Software Applications are increasingly used to tackle problems that concern everyday life : Automatic Bank tellers Airline reservation systems Air traffic
More informationCMSC 435: Software Engineering Section 0201
CMSC 435: Software Engineering Section 0201 Atif M. Memon (atif@cs.umd.edu) 4115 A.V.Williams building Phone: 301-405-3071 Office hours Tu.Th. (11:00am-1:00pm) Don t wait, don t hesitate, do communicate!!
More information*ANSWERS * **********************************
CS/183/17/SS07 UNIVERSITY OF SURREY BSc Programmes in Computing Level 1 Examination CS183: Systems Analysis and Design Time allowed: 2 hours Spring Semester 2007 Answer ALL questions in Section A and TWO
More informationReducing the costs of rework. Coping with change. Software prototyping. Ways to Cope with change. Benefits of prototyping
Coping with change Change is inevitable in all large software projects. Business changes lead to new and changed system requirements New technologies open up new possibilities for improving implementations
More informationFeasibility of Testing to Code. Feasibility of Testing to Code. Feasibility of Testing to Code. Feasibility of Testing to Code (contd)
Feasibility of Testing to Code (contd) Feasibility of Testing to Code (contd) An incorrect code fragment for determining if three integers are equal, together with two test cases Flowchart has over 10
More informationLecture Chapter 2 Software Development
Lecture Chapter 2 Software Development Large Software Projects Software Design o Team of programmers o Cost effective development Organization Communication Problem Solving Analysis of the problem Multiple
More informationHistory of object-oriented approaches
Prof. Dr. Nizamettin AYDIN naydin@yildiz.edu.tr http://www.yildiz.edu.tr/~naydin Object-Oriented Oriented Systems Analysis and Design with the UML Objectives: Understand the basic characteristics of object-oriented
More informationdefined. defined. defined. defined. defined. defined. defined. defined. defined.
Table of Contents Week 1 Software Development... 2 Software Eng Life-Cycle Development Phases... 2 Methodologies... 2 Week 2 - XP, Scrum, Agile... 3 Extreme Programming (XP)... 3 Values of XP Programming...
More informationCS 424 Software Quality Assurance & Testing LECTURE 3 BASIC CONCEPTS OF SOFTWARE TESTING - I
LECTURE 3 BASIC CONCEPTS OF SOFTWARE TESTING - I WHAT IS SOFTWARE TESTING? Testing can find faults in the software but cannot prove that the software is error-free. OBJECTIVES OF SOFTWARE TESTING To test
More informationSoftware Engineering Lifecycles. Controlling Complexity
Software Engineering Lifecycles Class url:http://laser.cs.umass.edu/courses/cs320.spring11/ Controlling Complexity Separation of Concerns Planning Ahead Do a little work now to make later work easier The
More informationThe requirements engineering process
3 rd Stage Lecture time: 8:30-12:30 AM Instructor: Ali Kadhum AL-Quraby Lecture No. : 5 Subject: Software Engineering Class room no.: Department of computer science Process activities The four basic process
More informationInternal Audit Follow-Up Report. Multiple Use Agreements TxDOT Office of Internal Audit
Internal Audit Follow-Up Report Multiple Use Agreements TxDOT Office of Internal Audit Objective Assess the status of corrective actions for high risk Management Action Plans (MAPs) previously communicated
More informationWhat is Software Architecture
What is Software Architecture Is this diagram an architecture? (ATM Software) Control Card Interface Cash Dispenser Keyboard Interface What are ambiguities in the previous diagram? Nature of the elements
More informationTHE APPLICATION OF SEQUENCE ENUMERATION TO THE AXIOMATIC DESIGN PROCESS
Proceedings of ICAD2013 ICAD-2013-28 THE APPLICATION OF SEQUENCE ENUMERATION TO THE AXIOMATIC DESIGN PROCESS Brandon Woolley brandon.woolley@ttu.edu Zhen Li zhen.li@ttu.edu Derrick Tate d.tate@ttu.edu
More informationThis tutorial also elaborates on other related methodologies like Agile, RAD and Prototyping.
i About the Tutorial SDLC stands for Software Development Life Cycle. SDLC is a process that consists of a series of planned activities to develop or alter the Software Products. This tutorial will give
More informationDilbert Scott Adams. CSc 233 Spring 2012
Dilbert Scott Adams CSc 233 Spring 2012 Dilbert Scott Adams CSc 233 Spring 2012 2 Dilbert Scott Adams CSc 233 Spring 2012 3 prerequisites CSc 233 Spring 2012 I thought we had agreed long ago that the Department
More informationArchitectural Blueprint
IMPORTANT NOTICE TO STUDENTS These slides are NOT to be used as a replacement for student notes. These slides are sometimes vague and incomplete on purpose to spark a class discussion Architectural Blueprint
More informationSE420 - Software Quality Assurance
SE420 - Software Quality Assurance http://dilbert.com/strips/comic/2006-01-29/ Lecture 3 Unit Testing, Part-2 January 21, 2019 Sam Siewert Reminders Assignment #2 Posted Thursday [Unit Re-Use] Explore
More informationCh 1: The Architecture Business Cycle
Ch 1: The Architecture Business Cycle For decades, software designers have been taught to build systems based exclusively on the technical requirements. Software architecture encompasses the structures
More informationAdopting Cleanroom software engineering with a phased approach
Adopting Cleanroom software engineering with a phased approach by P. A. Hausler R. C. Linger C. J. Trammel1 Cleanroom software engineering is a theorybased, team-oriented engineering process for developing
More informationB.H. Far
SENG 521 Software Reliability & Software Quality Chapter 15: Advances Topics Department t of Electrical l & Computer Engineering, i University it of Calgary B.H. Far (far@ucalgary.ca) http://www.enel.ucalgary.ca/people/far/lectures/seng521
More informationSchedule(3/3) March 18th 13:00 Unified Process and Usecase-Driven Approach. (problem definition, use case model)
Schedule(3/3) March 18th 13:00 Unified Process and Usecase-Driven Approach 14:30 Case Study of Elevator Control System (problem definition, use case model) March 19th 13:00 Case Study of Elevator Control
More informationChapter 1: Principles of Programming and Software Engineering
Chapter 1: Principles of Programming and Software Engineering Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano Software Engineering and Object-Oriented Design Coding without
More informationmywbut.com Software Life Cycle Model
Software Life Cycle Model 1 Basics of Software Life Cycle and Waterfall Model 2 Specific Instructional Objectives At the end of this lesson the student will be able to: Explain what is a life cycle model.
More informationTopic 01. Software Engineering, Web Engineering, agile methodologies.
Topic 01 Software Engineering, Web Engineering, agile methodologies. 1 What is Software Engineering? 2 1 Classic Software Engineering The IEEE definition: Software Engineering is the application of a disciplined,
More information1: Software Development and.net. An approach to building software
1: Software Development and.net An approach to building software Overview Programming in software development Life-Cycles for software development Object-orientation and modelling Requirements analysis
More informationChapter 1: Programming Principles
Chapter 1: Programming Principles Object Oriented Analysis and Design Abstraction and information hiding Object oriented programming principles Unified Modeling Language Software life-cycle models Key
More informationCourse Wrap-Up. Software Testing and Verification. Stephen M. Thebaut, Ph.D. Prepared by. University of Florida
Course Wrap-Up Software Testing and Verification Prepared by Stephen M. Thebaut, Ph.D. University of Florida A few loose ends Final Exam + solution notes will be posted (under Practice Exams ) ASAP probably
More informationRequirements and Design Overview
Requirements and Design Overview Robert B. France Colorado State University Robert B. France O-1 Why do we model? Enhance understanding and communication Provide structure for problem solving Furnish abstractions
More informationASSIGNMENT- I Topic: Functional Modeling, System Design, Object Design. Submitted by, Roll Numbers:-49-70
ASSIGNMENT- I Topic: Functional Modeling, System Design, Object Design Submitted by, Roll Numbers:-49-70 Functional Models The functional model specifies the results of a computation without specifying
More informationCertified Tester Foundation Level(CTFL)
Certified Tester Foundation Level(CTFL) ISTQB : International Software Testing Qualifications Board Heading: The International Software Testing Qualifications Board (ISTQB) is an internationally recognized
More informationSample Exam Syllabus
ISTQB Foundation Level 2011 Syllabus Version 2.9 Release Date: December 16th, 2017. Version.2.9 Page 1 of 46 Dec 16th, 2017 Copyright 2017 (hereinafter called ISTQB ). All rights reserved. The authors
More informationStatistical Testing of Software Based on a Usage Model
SOFTWARE PRACTICE AND EXPERIENCE, VOL. 25(1), 97 108 (JANUARY 1995) Statistical Testing of Software Based on a Usage Model gwendolyn h. walton, j. h. poore and carmen j. trammell Department of Computer
More informationOBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis
UNIT I INTRODUCTION OBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis Design Implementation Testing Maintenance
More informationIntroduction to Software Engineering
Chapter 1 Introduction to Software Engineering Content 1. Introduction 2. Components 3. Layered Technologies 4. Generic View of Software Engineering 4. Generic View of Software Engineering 5. Study of
More informationSRI VENKATESWARA COLLEGE OF ENGINERRING AND TECHNOLOGY THIRUPACHUR,THIRUVALLUR UNIT I OOAD PART A
SRI VENKATESWARA COLLEGE OF ENGINERRING AND TECHNOLOGY THIRUPACHUR,THIRUVALLUR UNIT I OOAD PART A 1. What is an object? An object is a combination of data and logic; the representation of some realworld
More informationTechnical Report CMU/SEI-96-TR-023 ESC-TR
Technical Report CMU/SEI-96-TR-023 ESC-TR-96-023 Cleanroom Software Engineering Implementation of the Capability Maturity Model (CMM sm ) for Software Richard C. Linger Mark C. aulk Carmen J. Trammell
More informationLecture Notes UML UNIT-II. Subject: OOAD Semester: 8TH Course No: CSE-802
UNIT-II Lecture Notes On UML IMPORTANCE OF MODELING, BRIEF OVERVIEW OF OBJECT MODELING TECHNOLOGY (OMT) BY RAMBAUGH, BOOCH METHODOLOGY, USE CASE DRIVE APPROACH (OOSE) BY JACKOBSON. KHALID AMIN AKHOON 1
More informationPart 5. Verification and Validation
Software Engineering Part 5. Verification and Validation - Verification and Validation - Software Testing Ver. 1.7 This lecture note is based on materials from Ian Sommerville 2006. Anyone can use this
More informationPK0-003 Q&As. Project+ (2009) Pass CompTIA PK0-003 Exam with 100% Guarantee. Free Download Real Questions & Answers PDF and VCE file from:
PK0-003 Q&As Project+ (2009) Pass CompTIA PK0-003 Exam with 100% Guarantee Free Download Real Questions & Answers PDF and VCE file from: 100% Passing Guarantee 100% Money Back Assurance Following Questions
More informationThe Design Space of Software Development Methodologies
The Design Space of Software Development Methodologies Kadie Clancy, CS2310 Term Project I. INTRODUCTION The success of a software development project depends on the underlying framework used to plan and
More informationApplying Human-Centered Design Process to SystemDirector Enterprise Development Methodology
Applying Human-Centered Design Process to SystemDirector Enterprise Development HIRAMATSU Takeshi, FUKUZUMI Shin ichi Abstract Human-centered design process is specified in ISO13407 international standard,
More informationUser Documentation Development Life Cycle (UDDLC)
WWW.ALMAHACONSULTING.CA User Documentation Development Life Cycle (UDDLC) STANDARD OPERATING PROCEDURE BUSINESS PROCESS DOCUMENT DOCUMENT STATUS: VERSION 0.1 Department BUSINESS TRANSFORMATION Process
More informationCertified Software Quality Engineer Preparation On Demand, Web-Based Course Offered by The Westfall Team
Certified Software Quality Engineer (CSQE) Preparation course is an on demand, web-based course design to be a comprehensive, in-depth review of the topics in the ASQ s Certified Software Quality Engineer
More informationSoftware Process. Software Process
Software Process What is SW process? Definition, Development, Support phases Process models: Waterfall Prototyping Spiral, Incremental & iterative (best practices) UP process model What is it? How does
More information(Objective-CS605 Software Engeenring-II)
Which one of the following is NOT a useful indicator of software quality? Correctness Code size (Page 67) Maintainability Integrity Usability Which one of the following does not belong to a strategy for
More information18-642: Software Development Processes
18-642: Software Development Processes 9/6/2017 Coding Is Essentially 0% of Creating Software http://e.ubmelectronics.com/2013embeddedstudy/index.html 2 Old-School Waterfall Development Cycle Bugs SPECIFY
More informationTesting! Prof. Leon Osterweil! CS 520/620! Spring 2013!
Testing Prof. Leon Osterweil CS 520/620 Spring 2013 Relations and Analysis A software product consists of A collection of (types of) artifacts Related to each other by myriad Relations The relations are
More informationVerification and Validation
Steven Zeil February 13, 2013 Contents 1 The Process 3 1 2 Non-Testing V&V 7 2.1 Code Review....... 8 2.2 Mathematically-based verification......................... 19 2.3 Static analysis tools... 23 2.4
More informationVerification and Validation
Steven Zeil February 13, 2013 Contents 1 The Process 2 2 Non-Testing V&V 3 2.1 Code Review........... 4 2.2 Mathematically-based verification.................................. 8 2.3 Static analysis tools.......
More informationComputer Programming AAS Spring 2019 Outcomes
Computer Programming AAS Spring 2019 Outcomes 1. Demonstrate professionalism including presentation skills, utilizing research for problem solving, working independently and in teams, being accountable
More informationPRODUCT SAFETY PROFESSIONAL CERTIFICATION PROGRAM DETAILS. Overview
Overview PRODUCT SAFETY PROFESSIONAL CERTIFICATION PROGRAM DETAILS The Product Safety Professional Certification Program at the Richard A. Chaifetz School of Business focuses on the theoretical as well
More informationINSTITUTE OF AERONAUTICAL ENGINEERING (Autonomous) Dundigal, Hyderabad
INSTITUTE OF AERONAUTICAL ENGINEERING (Autonomous) Dundigal, Hyderabad - 500 043 INFORMATION TECHNOLOGY COURSE DESCRIPTION FORM Course Title Course Code Regulation Course Structure Course Coordinator SOFTWARE
More informationSoftware Engineering with Objects and Components Open Issues and Course Summary
Software Engineering with Objects and Components Open Issues and Course Summary Massimo Felici Software Engineering with Objects and Components Software development process Lifecycle models and main stages
More informationVerification and Validation
Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: http://www.csc.liv.ac.uk/~coopes/comp201 Verification and Validation 1 Verification and Validation
More informationArchitectural Blueprint The 4+1 View Model of Software Architecture. Philippe Kruchten
Architectural Blueprint The 4+1 View Model of Software Architecture Philippe Kruchten Model What is a model? simplified abstract representation information exchange standardization principals (involved)
More informationObject-Oriented and Classical Software Engineering DESIGN 11/12/2017. CET/CSC490 Software Engineering Design CHAPTER 14. Stephen R. Schach.
Slide 14.1 CHAPTER 14 Slide 14.2 Object-Oriented and Classical Software Engineering DESIGN Eighth Edition, WCB/McGraw-Hill, 2011 Stephen R. Schach Overview Slide 14.3 Overview (contd) Slide 14.4 and abstraction
More informationSOFTWARE ENGINEERING. Curriculum in Software Engineering. Program Educational Objectives
Software Engineering 1 SOFTWARE ENGINEERING For the undergraduate curriculum in Software Engineering (http:// www.se.iastate.edu) leading to the degree Bachelor of Science. This curriculum is accredited
More informationIntroduction to Software Engineering p. 1 The Scope of Software Engineering p. 3 Historical Aspects p. 4 Economic Aspects p. 7 Maintenance Aspects p.
Preface p. xv Introduction to Software Engineering p. 1 The Scope of Software Engineering p. 3 Historical Aspects p. 4 Economic Aspects p. 7 Maintenance Aspects p. 8 Specification and Design Aspects p.
More informationThe Open Group Professional Certification Program. Accreditation Requirements
The Open Group Professional Certification Program Accreditation Requirements Version 1.0 October 2018 Copyright 2018, The Open Group All rights reserved. This publication may be reproduced, stored in a
More informationExamination Questions Time allowed: 1 hour 15 minutes
Swedish Software Testing Board (SSTB) International Software Testing Qualifications Board (ISTQB) Foundation Certificate in Software Testing Practice Exam Examination Questions 2011-10-10 Time allowed:
More informationManaging Change and Complexity
Managing Change and Complexity The reality of software development Overview Some more Philosophy Reality, representations and descriptions Some more history Managing complexity Managing change Some more
More informationFormal Methods and their role in Software and System Development. Riccardo Sisto, Politecnico di Torino
Formal Methods and their role in Software and System Development Riccardo Sisto, Politecnico di Torino What are Formal Methods? Rigorous (mathematical) methods for modelling and analysing (computer-based)
More informationBIIAB ICT Systems and Principles for IT Practitioners and Professionals Qualifications Handbook
Qualification Handbook BIIAB ICT Systems and Principles for IT Practitioners and Professionals Qualifications Handbook BIIAB Level 2 Award In ICT Systems and Principles for Practitioners (QCF) 601/6468/2
More informationExecutable Requirements: Opportunities and Impediments
Executable Requirements: Oppotunities and Impediments Executable Requirements: Opportunities and Impediments G. A. Shaw and A. H. Anderson * Abstract: In a top-down, language-based design methodology,
More informationLearning objectives. Documenting Analysis and Test. Why Produce Quality Documentation? Major categories of documents
Learning objectives Documenting Analysis and Test Understand the purposes and importance of documentation Identify some key quality documents and their relations Understand the structure and content of
More informationSoftware Design. Levels in Design Process. Design Methodologies. Levels..
Design Software Design Design activity begins with a set of requirements Design done before the system is implemented Design is the intermediate language between requirements and code Moving from problem
More informationCertified Tester. Expert Level. Modules Overview
Certified Tester Expert Level Modules Overview Version 1.2, 23 rd August 2013 Copyright Notice This document may be copied in its entirety, or extracts made, if the source is acknowledged. Version 1.2
More informationObject-Oriented and Classical Software Engineering
Slide 6.1 Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2007 Stephen R. Schach srs@vuse.vanderbilt.edu CHAPTER 6 Slide 6.2 TESTING 1 Overview Slide 6.3 Quality issues
More informationObject-Oriented and Classical Software Engineering
Slide 6.1 Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2007 Stephen R. Schach srs@vuse.vanderbilt.edu CHAPTER 6 Slide 6.2 TESTING Overview Slide 6.3 Quality issues
More informationCleanroom Software Engineering
Course "Softwareprozesse" Cleanroom Software Engineering Lutz Prechelt Freie Universität Berlin, Institut für Informatik Principles Empirical results Typical practices Stepwise refinement box structures,
More informationQuality Assurance and IT Risk Management
Quality Assurance and IT Risk Deutsche Bank s QA and Testing Transformation Journey Michael Venditti Head of Enterprise Testing Services, Deutsche Bank IT RISK - REGULATORY GOVERNANCE Major shifts in the
More informationThe Cleanroom Method
Course "Softwareprozesse" The Cleanroom Method Lutz Prechelt Freie Universität Berlin, Institut für Informatik http://www.inf.fu-berlin.de/inst/ag-se/ Principles Empirical results Typical practices Stepwise
More informationAgile Tester Foundation E-learning Course Outline
Foundation E-learning Course Outline General Description This course provides testers and test managers with an understanding of the fundamentals of testing on agile projects. Attendees will learn how
More informationFACETs. Technical Report 05/19/2010
F3 FACETs Technical Report 05/19/2010 PROJECT OVERVIEW... 4 BASIC REQUIREMENTS... 4 CONSTRAINTS... 5 DEVELOPMENT PROCESS... 5 PLANNED/ACTUAL SCHEDULE... 6 SYSTEM DESIGN... 6 PRODUCT AND PROCESS METRICS...
More informationITSS Model Curriculum. - To get level 3 -
ITSS Model Curriculum - To get level 3 - (Corresponding with ITSS V3) IT Skill Standards Center IT Human Resources Development Headquarters Information-Technology Promotion Agency (IPA), JAPAN Company
More informationSRM ARTS AND SCIENCE COLLEGE SRM NAGAR, KATTANKULATHUR
SRM ARTS AND SCIENCE COLLEGE SRM NAGAR, KATTANKULATHUR 603203 DEPARTMENT OF COMPUTER SCIENCE & APPLICATIONS QUESTION BANK (2017-2018) Course / Branch : M.Sc-CST Semester / Year : Even / II Subject Name
More informationSOFTWARE ARCHITECTURE & DESIGN INTRODUCTION
SOFTWARE ARCHITECTURE & DESIGN INTRODUCTION http://www.tutorialspoint.com/software_architecture_design/introduction.htm Copyright tutorialspoint.com The architecture of a system describes its major components,
More informationISO Compliant Automatic Requirements-Based Testing for TargetLink
ISO 26262 Compliant Automatic Requirements-Based Testing for TargetLink Dr. Udo Brockmeyer CEO BTC Embedded Systems AG An der Schmiede 4, 26135 Oldenburg, Germany udo.brockmeyer@btc-es.de Adrian Valea
More informationObject Oriented Programming
Binnur Kurt kurt@ce.itu.edu.tr Istanbul Technical University Computer Engineering Department 1 Version 0.1.2 About the Lecturer BSc İTÜ, Computer Engineering Department, 1995 MSc İTÜ, Computer Engineering
More informationExisting Model Metrics and Relations to Model Quality
Existing Model Metrics and Relations to Model Quality Parastoo Mohagheghi, Vegard Dehlen WoSQ 09 ICT 1 Background In SINTEF ICT, we do research on Model-Driven Engineering and develop methods and tools:
More informationQuestion 1: What is a code walk-through, and how is it performed?
Question 1: What is a code walk-through, and how is it performed? Response: Code walk-throughs have traditionally been viewed as informal evaluations of code, but more attention is being given to this
More informationObject-Oriented Systems. Development: Using the Unified Modeling Language
Object-Oriented Systems Development: Using the Unified Modeling Language Chapter 3: Object-Oriented Systems Development Life Cycle Goals The software development process Building high-quality software
More informationCertifiedAT - Version: 1. ISTQB Certified Agile Tester Foundation Level Extension
CertifiedAT - Version: 1 ISTQB Certified Agile Tester Foundation Level Extension ISTQB Certified Agile Tester Foundation Level Extension CertifiedAT - Version: 1 3 days Course Description: We are facing
More informationStandard Glossary of Terms used in Software Testing. Version 3.2. Foundation Extension - Usability Terms
Standard Glossary of Terms used in Software Testing Version 3.2 Foundation Extension - Usability Terms International Software Testing Qualifications Board Copyright Notice This document may be copied in
More informationVO Software Engineering
Administrative Issues Univ.Prof. Dr. Peter Auer Chair for Information Technology Email: auer@unileoben.ac.at Lecture Thursday 10:15 11:45 Project Lab Montag 16:00 19:00 Literature Helmut Balzert, Lehrbuch
More informationSE 2730 Final Review
SE 2730 Final Review 1. Introduction 1) What is software: programs, associated documentations and data 2) Three types of software products: generic, custom, semi-custom Why is semi-custom product more
More information