2. Draw and explain state transition diagram for a typical weather information system. (8M)

Size: px
Start display at page:

Download "2. Draw and explain state transition diagram for a typical weather information system. (8M)"

Transcription

1 1. Explain, with a neat diagram, the distinct phases of Rational Unified Process (RUP). 1b. List and explain the different stages involved in the object oriented design process. 2. Draw and explain state transition diagram for a typical weather information system. (8M) 3a. With a neat diagram explain the model of software testing process. 3b. Write short note on Software Reengineering. 4a. What are the advantages of software inspection over testing. 4b. What is equivalence partitioning? Explain with an example how equivalence partition helps in testing. 5. List and explain Lehman s laws related to software evolution. 6a. Define maintenance. What are the different types of software maintenance? 6b. With a neat diagram explain the system evolution process. 7a. Bring out the meaning of verification and validation clearly with an example. Explain the ultimate goal of the verification and validation process. 7b. Explain why software maintenance is more expensive than development. 1.A modern process model derived from the work on the UML and associated process. Normally described from 3 perspectives A dynamic perspective that shows phases over time; A static perspective that shows process activities; A practice perspective that suggests good practice. Inception Establish the business case for the system. Elaboration Develop an understanding of the problem domain and the system architecture. Construction System design, programming and testing.

2 Transition Deploy the system in its operating environment. Phase iteration Inception Elaboration Construction Transition 1b. Highlights key activities without being tied to any proprietary process such as the RUP. 1. Define the context and modes of use of the system; 2. Design the system architecture; 3. Identify the principal system objects; 4. Develop design models; 5. Specify object interfaces. 2. State chart diagrams invented by Harel to describe state machine models. Show how objects respond to different service requests and the state transitions triggered by these requests If object state is Shutdown then it responds to a Startup() message; In the waiting state the object is waiting for further messages; If reportweather () then system moves to summarising state; If calibrate () the system moves to a calibrating state; A collecting state is entered when a clock signal is received.

3 3a. Software testing is a critical element of software quality assurance and represents the ultimate review of specification, design and coding. Testing is necessary because software is likely to have faults in it and it is better to find and remove these faults before the system is put to use. Testing is needed in order to assess what the system actually does and how well it does in it its final environment. Test cases are specifications of the inputs to the test and the expected output from the system and a statement of what is being tested. test data are the inputs devised to test the system Test cases Test data Test results Test repor ts Design test cases Prepar e test data Run pr ogram with test da ta Compar e results to test cases 3b. Software re-engineering is concerned with re-implementing legacy systems to make them more maintainable. Re-engineering may involve re-documenting the system, organising and restructuring the system, translating the system to a modern programming language and modifying and updating the structure and values of the system s data. The functionality of the system is not changed and the architecture remains the same. The input to the process is legacy program and the output is a structured, modularised version of the same program. During program re-engineering, the data for the system may also be re-engineered. Reengineering process activities: 1. Source code translation Convert code to a new language. 2. Reverse engineering Analyse the program to understand it; 3. Program structure improvement Restructure automatically for understandability; 4. Program modularisation Reorganise the program structure; 5. Data reengineering

4 Clean-up and restructure system data. 4a. There are three major advantages of inspection over testing: 1. During testing, errors can mask (hide) other errors. Once one error is discovered, you can never be sure if other output anomalies are due to a new error or are side effects of the original error. Because inspection is a static process, you don t have to be concerned with interactions between errors. Consequently, a single inspection session can discover many errors in a system. 2. Incomplete versions of a system can be inspected without additional costs. If a program is incomplete, then you need to develop specialised test harnesses to test the parts that are available. This obviously adds to the system development costs. 3. As well as searching for program defects, an inspection can also consider broader quality attributes of a program such as compliance with standards, portability and maintainability. You can look for inefficiencies, inappropriate algorithms and poor programming style that could make the system difficult to maintain and update.

5 4b. The input data and output results of a program usually fall into a number of different classes that have common characteristics such as positive numbers, negative numbers and menu selections. Programs normally behave in a comparable way for all members of a class. That is, if you test a program that does some computation and requires two positive numbers, then you would expect the program to behave in the same way for all positive numbers. Because of this equivalent behaviour, these classes are sometimes called equivalence partitions or domains (Bezier, 1990). One systematic approach to test case design is based on identifying all partitions for a system or component. Test cases are designed so that the inputs or outputs lie within these partitions. Partition testing can be used to design test cases for both systems and components. In Figure 23.8, each equivalence partition is shown as an ellipse. Input equivalence partitions are sets of data where all of the set members should be processed in an equivalent way. Output equivalence partitions are program outputs that have common characteristics, so they can be considered as a distinct class. You also identify partitions where the inputs are outside the other partitions that you have chosen. These test whether the program handles invalid input correctly. Valid and invalid inputs also form equivalence partitions. You identify partitions by using the program specification or user documentation and, from experience, where you predict the classes of input value that are likely to detect errors. For example, say a program specification states that the program accepts 4 to 8 inputs that are fivedigit integers greater than 10,000. Figure 23.9 shows the partitions for this situation and possible test input values Invalid inputs Valid inputs Less than 4 Betw een 4 and 1 0 More than 1 0 Number of input v alues System Outputs Less than B e 0 More than Input v alues

6 Once you have identified a set of partitions, you can chose test cases from each of these partitions. A good rule of thumb for test case selection is to choose test cases on the boundaries of the partitions plus cases close to the mid-point of the partition. The rationale for this is that designers and programmers tend to consider typical values of inputs when developing a system. You test these by choosing the mid-point of the partition. Boundary values are often atypical (e.g., zero may behave differently from other nonnegative numbers) so are overlooked by developers. Program failures often occur when processing these atypical values. 5. Law Continuing c ange In re sing comp exit Desc iption A rogram tha is use in a re l-world environment n cessari y must cha ge or b come progr ssiv ly l ss useful in tha environment As an e olving progr m c anges, its struc ure t nds to b come more compl x. Extra resourc s must be de ot d to preserv ng and simplifying the struc ure. L rge program volu ion Program evolut on is a se f-regula ing proc ss. Syst m attribu es su h as si, time betwe n rel ses and th numb r of re ort d errors is approximat ly invari nt for ea system re ase Orga isa iona st bi ity Conserva ion of famili rity Continuing growth De ining quali y Ov r a programõs life ime its rate of deve opment is approximate y consta t and inde ende t of the resour es de ot d to syst m deve opment Ov r th l fetime of a syst m, t e increme ta c ange in eac re ase s a proxima el nst nt. The func iona it offe ed by systems h s t c ntinua ly incr ase to mainta n user sat sfa tion The quali y of systems wil a pe r to be de li ing un ess the are dapt d to chang s in the r opera iona e vironme t. Fe db ck syst m Evo ution proc sses in orpor te mul i-ag nt, mult -loop fe db k syst ms and you have to trea th m as fe db k systems o chie sign fica t produc improvement

7 6a. The process of changing the software after delivery is called software maintenance. Maintenance does not normally involve major changes to the system s architecture. Changes are implemented by modifying existing components and adding new components to the system. Maintenance to repair software faults C h a n g i n g a s y s t e m t o c o r r e c t deficiencies in the way meets its requirements. Maintenance to adapt software to a different operating environment Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial implementation. Maintenance to add to or modify the system s functionality Modifying the system to satisfy new requirements. Software adaptation (18%) Fault repair (17%) Functionality addition or modification (65%) 6b. Evolution processes vary depending on The type of software being maintained; The development processes used; The skills and experience of the people involved. Proposals for change are the driver for system evolution. Change proposals may involve existing requirements that have not been implemented in the released system, requests for new requirements and bug repairs from system stakeholders, new ideas and proposals for software improvement from software development team. Change identification and evolution continue throughout the system lifetime. Processes of change identification and system evolution are cyclical and continue throughout the lifetime of a system. Evolution process includes the fundamental activities of change analysis, release planning, system implementation and releasing a system to customers.

8 Change identification process New system Change proposals Software evolution process Change requests Impact anal ysis Release planning Change implementa tion System release Fault repair Platform adaptation System enhancement The process of change implementation is an iteration of development process where revisions to the system are designed, implemented and tested. A critical difference is that the initial stage of change implementation is program understanding. During this phase the program structure and how the functionality is delivered is understood. 7a. The terms Verification and Validation are frequently used in the software testing world but the meaning of these terms are mostly vague and debatable. Verification and validation is concerned with establishing

9 the existence of defects in a program. Software verification is ensuring that the product has been built according to the requirements and design specifications, while software validation ensures that the product Verification Definition: The process of evaluating work-products (not the actual final product) of a development phase to determine whether they meet the specified requirements for that phase. Validation The process of evaluating software during or at the end of the development process to determine whether it satisfies specified business requirements. Objective: To ensure that the product is being built according to the r e q u i r e m e n t s a n d d e s i g n specifications. In other words, to ensure that work products meet their specified requirements. Question: Are we building the product right? To ensure that the product actually meets the user s needs, and that the specifications were correct in the first p l a c e. I n o t h e r w o r d s, t o demonstrate that the product fulfills its intended use when placed in its intended environment. Are we building the right product? Evaluation Items: Plans, Requirement Specs, Design Specs, Code, Test Cases Activities: Reviews Walkthroughs Inspections The actual product/software. Testing This is static method for verifying design and code. Software verification is human based checking of documents and files software verification is ensuring that the product has been built according to the requirements and design specifications This is dynamic process for checking and testing the real product. Software validation always involves executing the code software validation ensures that the product actually meets the user's needs, and that the specifications were correct in the first place. actually meets the user's needs, and that the specifications were correct in the first place.

10 7b. Maintenance costs are high because it is more expensive to add functionality after a system is in operation than it is to implement the same functionality during development. The key factors that distinguish development and maintenance and lead to high maintenance costs are: Team stability Maintenance costs are reduced if the same staff are involved with them for some time. New team responsible for maintenance do not understand the system. Lot of effort during maintenance is taken for understanding existing system. Contractual responsibility The developers of a system may have no contractual responsibility for maintenance so there is no incentive to design for future change. Lack of team stability increases maintenance costs. Staff skills Maintenance staff are often inexperienced and have limited domain knowledge. The maintenance staff may not have much experience of development and may have to learn the language to maintain the system. Program age and structure As programs age, their structure is degraded and they become harder to understand and change. Some systems have been developed without modern software engineering techniques. They may never have been well structured or optimised for efficiency. System documentation may be lost or inconsistent. Old systems may not be subject to configuration management, so time is wasted finding the right versions of system component to change.

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

Software Processes. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 4 Slide 1 Objectives To introduce software process models To describe three generic process models and when they may be

More information

Lecture 15 Software Testing

Lecture 15 Software Testing Lecture 15 Software Testing Includes slides from the companion website for Sommerville, Software Engineering, 10/e. Pearson Higher Education, 2016. All rights reserved. Used with permission. Topics covered

More information

Software change. Software maintenance

Software change. Software maintenance Software change 1 Software change is inevitable New requirements emerge when the software is used The business environment changes Errors must be repaired New equipment must be accommodated The performance

More information

Part 5. Verification and Validation

Part 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 information

Software Maintenance. Maintenance is Inevitable. Types of Maintenance. Managing the processes of system change

Software Maintenance. Maintenance is Inevitable. Types of Maintenance. Managing the processes of system change Software Maintenance Managing the processes of system change Maintenance is Inevitable The system requirements are likely to change while the system is being developed because the environment is changing.

More information

Topic: Software Verification, Validation and Testing Software Engineering. Faculty of Computing Universiti Teknologi Malaysia

Topic: Software Verification, Validation and Testing Software Engineering. Faculty of Computing Universiti Teknologi Malaysia Topic: Software Verification, Validation and Testing Software Engineering Faculty of Computing Universiti Teknologi Malaysia 2016 Software Engineering 2 Recap on SDLC Phases & Artefacts Domain Analysis

More information

Verification and Validation. Assuring that a software system meets a user s needs. Verification vs Validation. The V & V Process

Verification and Validation. Assuring that a software system meets a user s needs. Verification vs Validation. The V & V Process Verification and Validation Assuring that a software system meets a user s needs Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 19,20 Slide 1

More information

Legacy Systems. Older software systems that remain vital to an organisation. Legacy systems. Legacy system replacement

Legacy Systems. Older software systems that remain vital to an organisation. Legacy systems. Legacy system replacement Legacy Systems Older software systems that remain vital to an organisation Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 1 Legacy

More information

Software re-engineering

Software re-engineering Software re-engineering Reorganising and modifying existing software systems to make them more maintainable Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 1 Objectives To explain

More information

Object-oriented development. Object-oriented Design. Objectives. Characteristics of OOD. Interacting objects. Topics covered

Object-oriented development. Object-oriented Design. Objectives. Characteristics of OOD. Interacting objects. Topics covered Object-oriented development Object-oriented Design Object-oriented analysis, design and programming are related but distinct. OOA is concerned with developing an object model of the application domain.

More information

W.C.Uduwela. Dept. of Mathematics & Computer Science

W.C.Uduwela. Dept. of Mathematics & Computer Science Software Testing W.C.Uduwela Dept. of Mathematics & Computer Science The image cann ot be displayed. Your compu ter may not have enough memory to open the image, or the image may have been cor rup ted.

More information

Verification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1

Verification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1 Verification and Validation 1 Objectives To introduce software verification and validation and to discuss the distinction between them To describe the program inspection process and its role in V & V To

More information

Chapter 8 Software Testing. Chapter 8 Software testing

Chapter 8 Software Testing. Chapter 8 Software testing Chapter 8 Software Testing 1 Topics covered Introduction to testing Stages for testing software system are: Development testing Release testing User testing Test-driven development as interleave approach.

More information

Reducing the costs of rework. Coping with change. Software prototyping. Ways to Cope with change. Benefits of prototyping

Reducing 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 information

Introduction to Software Engineering

Introduction 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 information

Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 22 Slide 1

Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 22 Slide 1 Verification and Validation Slide 1 Objectives To introduce software verification and validation and to discuss the distinction between them To describe the program inspection process and its role in V

More information

Object-oriented Design

Object-oriented Design Object-oriented Design Objectives To explain how a software design may be represented as a set of interacting objects that manage their own state and operations To describe the activities in the objectoriented

More information

Verification and Validation

Verification 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 information

Incremental development A.Y. 2018/2019

Incremental 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 information

Software Engineering

Software Engineering Software Engineering Engr. Abdul-Rahman Mahmood MS, PMP, MCP, QMR(ISO9001:2000) armahmood786@yahoo.com alphasecure@gmail.com alphapeeler.sf.net/pubkeys/pkey.htm http://alphapeeler.sourceforge.net pk.linkedin.com/in/armahmood

More information

CMSC 435: Software Engineering Section 0201

CMSC 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

Documentation & Maintenance

Documentation & Maintenance Documentation & Maintenance Princípy tvorby softvéru, FMFI UK Jana Kostičová, 16.5.2016 Documentation Why documentation? 1. Facilitates communication Within the development team itself Between the development

More information

Chapter 1: Programming Principles

Chapter 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 information

Verification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1

Verification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1 Verification and Validation Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1 Verification vs validation Verification: "Are we building the product right?. The software should

More information

VO Software Engineering

VO 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 information

Software testing. Objectives. Contents

Software testing. Objectives. Contents 8 Software testing Objectives The objective of this chapter is to introduce software testing and software testing processes. When you have read the chapter, you will: understand the stages of testing from

More information

The testing process. Component testing. System testing

The testing process. Component testing. System testing Software testing Objectives To discuss the distinctions between validation testing and defect testing To describe the principles of system and component testing To describe strategies for generating system

More information

Chapter 8 Software Testing. Chapter 8 So-ware tes0ng

Chapter 8 Software Testing. Chapter 8 So-ware tes0ng Chapter 8 Software Testing 1 Topics covered ² Introduction to testing ² Stages for testing software system are: Development testing Release testing User testing ² Test-driven development as interleave

More information

Examination Questions Time allowed: 1 hour 15 minutes

Examination 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 information

ΗΜΥ 317 Τεχνολογία Υπολογισμού

ΗΜΥ 317 Τεχνολογία Υπολογισμού ΗΜΥ 317 Τεχνολογία Υπολογισμού Εαρινό Εξάμηνο 2008 ΙΑΛΕΞΕΙΣ 18-19: Έλεγχος και Πιστοποίηση Λειτουργίας ΧΑΡΗΣ ΘΕΟΧΑΡΙ ΗΣ Λέκτορας ΗΜΜΥ (ttheocharides@ucy.ac.cy) [Προσαρμογή από Ian Sommerville, Software

More information

Software Engineering I. Chapters 8 & 9. SW Testing & Maintenance. Slide 1. 12/17/2017 SW Testing and Maintenance

Software Engineering I. Chapters 8 & 9. SW Testing & Maintenance. Slide 1. 12/17/2017 SW Testing and Maintenance Software Engineering I Chapters 8 & 9 SW Testing & Maintenance 12/17/2017 SW Testing and Maintenance Slide 1 Chapter 8 Software Testing 12/17/2017 SW Testing and Maintenance Slide 2 Program testing Testing

More information

Aerospace Software Engineering

Aerospace Software Engineering 16.35 Aerospace Software Engineering Verification & Validation Prof. Kristina Lundqvist Dept. of Aero/Astro, MIT Would You...... trust a completely-automated nuclear power plant?... trust a completely-automated

More information

Introduction To Software Testing. Brian Nielsen. Center of Embedded Software Systems Aalborg University, Denmark CSS

Introduction To Software Testing. Brian Nielsen. Center of Embedded Software Systems Aalborg University, Denmark CSS Introduction To Software Testing Brian Nielsen bnielsen@cs.aau.dk Center of Embedded Software Systems Aalborg University, Denmark CSS 1010111011010101 1011010101110111 What is testing? Testing Testing:

More information

SOFTWARE ENGINEERING. Software Specification Software Design and Implementation Software Validation. Peter Mileff PhD

SOFTWARE ENGINEERING. Software Specification Software Design and Implementation Software Validation. Peter Mileff PhD Peter Mileff PhD SOFTWARE ENGINEERING Software Specification Software Design and Implementation Software Validation University of Miskolc Department of Information Technology Software Specification...

More information

Basics : the Requirements Engineering Process

Basics : the Requirements Engineering Process SEG3101 (Fall 2010) Basics : the Requirements Engineering Process Gregor v. Bochmann, University of Ottawa Based on Powerpoint slides prepared by Gunter Mussbacher with material from: Sommerville & Kotonya

More information

Chapter 10. Testing and Quality Assurance

Chapter 10. Testing and Quality Assurance Chapter 10 Testing and Quality Assurance Different styles of doing code review Human Reviewer Code Inspection with continuous integration infrastructure Pinger s testing set up Testing Related topics 1.

More information

Software Engineering (CSC 4350/6350) Rao Casturi

Software Engineering (CSC 4350/6350) Rao Casturi Software Engineering (CSC 4350/6350) Rao Casturi Testing Software Engineering -CSC4350/6350 - Rao Casturi 2 Testing What is testing? Process of finding the divergence between the expected behavior of the

More information

Software Engineering Chap.7 - Design and Implementation

Software Engineering Chap.7 - Design and Implementation Software Engineering Chap.7 - Design and Implementation Simão Melo de Sousa RELEASE (UBI), LIACC (Porto), CCTC (Minho) Computer Science Department University of Beira Interior, Portugal Eng.Info./TSI,

More information

Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 11/10/2015

Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 11/10/2015 Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm Rao Casturi 11/10/2015 http://cs.gsu.edu/~ncasturi1 Class announcements Final Exam date - Dec 1 st. Final Presentations Dec 3 rd. And

More information

Overview. State-of-the-Art. Relative cost of error correction. CS 619 Introduction to OO Design and Development. Testing.

Overview. State-of-the-Art. Relative cost of error correction. CS 619 Introduction to OO Design and Development. Testing. Overview CS 619 Introduction to OO Design and Development ing! Preliminaries! All sorts of test techniques! Comparison of test techniques! Software reliability Fall 2012! Main issues: There are a great

More information

CSC 408F/CSC2105F Lecture Notes

CSC 408F/CSC2105F Lecture Notes CSC 408F/CSC2105F Lecture Notes These lecture notes are provided for the personal use of students taking CSC 408H/CSC 2105H in the Fall term 2004/2005 at the University of Toronto. Copying for purposes

More information

Software Engineering Fall 2014

Software Engineering Fall 2014 Software Engineering Fall 2014 (CSC 4350/6350) Mon.- Wed. 5:30 pm 7:15 pm ALC : 107 Rao Casturi 11/10/2014 Final Exam date - Dec 10 th? Class announcements Final Presentations Dec 3 rd. And Dec 8 th. Ability

More information

THE BCS PROFESSIONAL EXAMINATION BCS Level 6 Professional Graduate Diploma in IT September 2017 EXAMINERS REPORT. Software Engineering 2

THE BCS PROFESSIONAL EXAMINATION BCS Level 6 Professional Graduate Diploma in IT September 2017 EXAMINERS REPORT. Software Engineering 2 General Comments THE BCS PROFESSIONAL EXAMINATION BCS Level 6 Professional Graduate Diploma in IT September 2017 EXAMINERS REPORT Software Engineering 2 The pass rate was 40% representing the lowest mark

More information

Objectives. Chapter 19. Verification vs. validation. Topics covered. Static and dynamic verification. The V&V process

Objectives. Chapter 19. Verification vs. validation. Topics covered. Static and dynamic verification. The V&V process Objectives Chapter 19 Verification and Validation Assuring that a software system meets a user s need are to introduce software verification and validation (V&V) and to discuss the distinction between

More information

SOFTWARE ENGINEERING SOFTWARE EVOLUTION. Saulius Ragaišis.

SOFTWARE ENGINEERING SOFTWARE EVOLUTION. Saulius Ragaišis. SOFTWARE ENGINEERING SOFTWARE EVOLUTION Saulius Ragaišis saulius.ragaisis@mif.vu.lt CSC2008 SE Software Evolution Learning Objectives: Identify the principal issues associated with software evolution and

More information

Software Testing. Software Testing

Software Testing. Software Testing Software Testing Software Testing Error: mistake made by the programmer/ developer Fault: a incorrect piece of code/document (i.e., bug) Failure: result of a fault Goal of software testing: Cause failures

More information

Software Life Cycle. Main issues: Discussion of different life cycle models Maintenance or evolution

Software Life Cycle. Main issues: Discussion of different life cycle models Maintenance or evolution Software Life Cycle Main issues: Discussion of different life cycle models Maintenance or evolution Introduction software development projects are large and complex a phased approach to control it is necessary

More information

SOFTWARE ENGINEERING DECEMBER. Q2a. What are the key challenges being faced by software engineering?

SOFTWARE ENGINEERING DECEMBER. Q2a. What are the key challenges being faced by software engineering? Q2a. What are the key challenges being faced by software engineering? Ans 2a. The key challenges facing software engineering are: 1. Coping with legacy systems, coping with increasing diversity and coping

More information

Verification and Validation

Verification and Validation Verification and Validation Assuring that a software system meets a user's needs Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 19 Slide 1 Objectives To introduce software verification

More information

Recap on SDLC Phases & Artefacts. Topic: Software Verification, Validation and Testing Software Engineering

Recap on SDLC Phases & Artefacts. Topic: Software Verification, Validation and Testing Software Engineering Topic: Software Verification, Validation and Testing Software Engineering Faculty of Computing UniversitiTeknologi Malaysia Recap on SDLC Phases & Artefacts Domain Analysis @ Business Process Requirement

More information

Chapter 9. Software Testing

Chapter 9. Software Testing Chapter 9. Software Testing Table of Contents Objectives... 1 Introduction to software testing... 1 The testers... 2 The developers... 2 An independent testing team... 2 The customer... 2 Principles of

More information

Software Testing and Maintenance

Software Testing and Maintenance Software Testing and Maintenance Testing Strategies Black Box Testing, also known as Behavioral Testing, is a software testing method in which the internal structure/ design/ implementation of the item

More information

Software Testing. Software Testing. in the textbook. Chapter 8. Verification and Validation. Verification Techniques

Software Testing. Software Testing. in the textbook. Chapter 8. Verification and Validation. Verification Techniques Software Testing in the textbook Software Testing Chapter 8 Introduction (Verification and Validation) 8.1 Development testing 8.2 Test-driven development 8.3 Release testing 8.4 User testing 1 2 Verification

More information

ASTQB Advance Test Analyst Sample Exam Answer Key and Rationale

ASTQB Advance Test Analyst Sample Exam Answer Key and Rationale ASTQB Advance Test Analyst Sample Exam Answer Key and Rationale Total number points = 120 points Total number points to pass = 78 points Question Answer Explanation / Rationale Learning 1 A A is correct.

More information

Verification and Validation

Verification 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 information

Verification and Validation

Verification 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 information

Higher-order Testing. Stuart Anderson. Stuart Anderson Higher-order Testing c 2011

Higher-order Testing. Stuart Anderson. Stuart Anderson Higher-order Testing c 2011 Higher-order Testing Stuart Anderson Defining Higher Order Tests 1 The V-Model V-Model Stages Meyers version of the V-model has a number of stages that relate to distinct testing phases all of which are

More information

First To Market through Translation of Executable UML

First To Market through Translation of Executable UML 1(40) A swedish friend asked: What is this uml uml that I see everywhere on the web? Humla : Swedish for bumble-bee. 2(40) The old story about the Depending on its weight in relation to the size of its

More information

International Journal of Computer Engineering and Applications, Volume XII, Special Issue, September 18, ISSN SOFTWARE TESTING

International Journal of Computer Engineering and Applications, Volume XII, Special Issue, September 18,   ISSN SOFTWARE TESTING International Journal of Computer Engineering and Applications, Volume XII, Special Issue, September 18, www.ijcea.com ISSN 2321-3469 SOFTWARE TESTING Rajat Galav 1, Shivank Lavania 2, Brijesh Kumar Singh

More information

Chapter 1: Principles of Programming and Software Engineering

Chapter 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 information

2 Software life span models

2 Software life span models 2 Software life span models Stages through which software goes, from conception to death Stages may be very different Software = product stages are similar to the stages in the life span of other products

More information

Lecture 7: Software Processes. Refresher: Software Always Evolves

Lecture 7: Software Processes. Refresher: Software Always Evolves Lecture 7: Software Processes What is a Software Development Process? The Lifecycle of a Software Project Agile vs. Disciplined Some common approaches: RUP, SCRUM, XP, ICONIX, Where UML fits in (next lecture)

More information

Software Testing. Lecturer: Sebastian Coope Ashton Building, Room G.18

Software Testing. Lecturer: Sebastian Coope Ashton Building, Room G.18 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 Software Testing 1 Defect Testing Defect testing involves

More information

Topics in Software Testing

Topics in Software Testing Dependable Software Systems Topics in Software Testing Material drawn from [Beizer, Sommerville] Software Testing Software testing is a critical element of software quality assurance and represents the

More information

International Journal of Computer Engineering and Applications, Volume XII, Special Issue, April- ICITDA 18,

International Journal of Computer Engineering and Applications, Volume XII, Special Issue, April- ICITDA 18, International Journal of Computer Engineering and Applications, Volume XII, Special Issue, April- ICITDA 18, www.ijcea.com ISSN 2321-3469 SOFTWARE TESTING Rajat Galav, Shivank Lavania Student, Department

More information

Change Management Process on Database Level within RUP Framework

Change Management Process on Database Level within RUP Framework Change Management Process on Database Level within RUP Framework ZELJKA CAR*, PETRA SVOBODA**, CORNELIA KRUSLIN** *Department of Telecommunications Faculty of Electrical Engineering Computing, University

More information

Low Level Design Activities. Implementation (Low Level Design) What is a Good Low Level Module? Black Box Aspects. Black box aspects White box aspects

Low Level Design Activities. Implementation (Low Level Design) What is a Good Low Level Module? Black Box Aspects. Black box aspects White box aspects Low Level Design Activities Implementation (Low Level Design) Implement Document Deskcheck Basic Test PVK--HT00 Copyright 1997-1999, jubo@cs.umu.se/epltos@epl.ericsson.se 2 What is a Good Low Level Module?

More information

Chapter 7 Design and Implementation

Chapter 7 Design and Implementation Chapter 7 Design and Implementation Chapter 7 Design and Implementation Slide 1 Topics covered Object-oriented design using the UML Design patterns Implementation issues Reuse Configuration management

More information

Lesson 06. Requirement Engineering Processes

Lesson 06. Requirement Engineering Processes Lesson 06 Requirement Engineering Processes W.C.Uduwela Department of Mathematics and Computer Science Objectives To describe the principal requirements engineering activities and their relationships To

More information

Lecture 9. Verification and Validation. Assuring that a software system meets a user's needs. Tutorial Questions. Verification and Validation

Lecture 9. Verification and Validation. Assuring that a software system meets a user's needs. Tutorial Questions. Verification and Validation ICT 381 SOFTWARE ENGINEERING Lance Fung School of Information Technology Lecture 9 Verification and Validation Ref: Sommerville I., Software Engineering, 6th Edition, Chapter 19 Slide 1 Slide 2 Tutorial

More information

UNIT-I Introduction of Object Oriented Modeling

UNIT-I Introduction of Object Oriented Modeling UNIT-I Introduction of Object Oriented Modeling - Prasad Mahale Object Oriented Modeling and Reference Books: Design 1. Grady Booch, James Rumbaugh, Ivar Jacobson Unified Modeling Language User Guide,

More information

Deliver robust products at reduced cost by linking model-driven software testing to quality management.

Deliver robust products at reduced cost by linking model-driven software testing to quality management. Quality management White paper September 2009 Deliver robust products at reduced cost by linking model-driven software testing to quality management. Page 2 Contents 2 Closing the productivity gap between

More information

Verification and Validation. Verification and validation

Verification and Validation. Verification and validation Verification and Validation Verification and validation Verification and Validation (V&V) is a whole life-cycle process. V&V has two objectives: Discovery of defects, Assessment of whether or not the system

More information

Patterns and Testing

Patterns and Testing and Lecture # 7 Department of Computer Science and Technology University of Bedfordshire Written by David Goodwin, based on the lectures of Marc Conrad and Dayou Li and on the book Applying UML and (3

More information

Introduction to Software Engineering

Introduction 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 information

Managing Change and Complexity

Managing 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 information

SEG3201 Basics of the Requirements Process

SEG3201 Basics of the Requirements Process SEG3201 Basics of the Requirements Process Based on material from: I Bray: An introduction to Requirements Engineering Gerald Kotonya and Ian Sommerville: Requirements Engineering Processes and Techniques,

More information

Building a New Rational Web Site with Rational Suite

Building a New Rational Web Site with Rational Suite Building a New Rational Web Site with Rational Suite by Christina Howe Director of Internet Services Rational Software In April of last year, Rational Software determined that its Web site no longer measured

More information

A new international standard for data validation and processing

A new international standard for data validation and processing A new international standard for data validation and processing Marco Pellegrino (marco.pellegrino@ec.europa.eu) 1 Keywords: Data validation, transformation, open standards, SDMX, GSIM 1. INTRODUCTION

More information

Chapter : Analysis Modeling

Chapter : Analysis Modeling Chapter : Analysis Modeling Requirements Analysis Requirements analysis Specifies software s operational characteristics Indicates software's interface with other system elements Establishes constraints

More information

Software Engineering Lifecycles. Controlling Complexity

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

USTGlobal INNOVATION INFORMATION TECHNOLOGY. Using a Test Design Tool to become a Digital Organization

USTGlobal INNOVATION INFORMATION TECHNOLOGY. Using a Test Design Tool to become a Digital Organization USTGlobal INNOVATION INFORMATION TECHNOLOGY Using a Test Design Tool to become a Digital Organization Overview: Automating test design reduces efforts and increases quality Automated testing resolves most

More information

Quality Assurance in Software Development

Quality Assurance in Software Development Quality Assurance in Software Development Qualitätssicherung in der Softwareentwicklung A.o.Univ.-Prof. Dipl.-Ing. Dr. Bernhard Aichernig Graz University of Technology Austria Summer Term 2017 1 / 47 Agenda

More information

Sample Exam Syllabus

Sample 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 information

Categorizing Migrations

Categorizing Migrations What to Migrate? Categorizing Migrations A version control repository contains two distinct types of data. The first type of data is the actual content of the directories and files themselves which are

More information

Software Process. Software Process

Software 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

Computational Systems COMP1209

Computational Systems COMP1209 Computational Systems COMP1209 Testing Yvonne Howard ymh@ecs.soton.ac.uk A Problem A café wants to build an automated system to provide breakfasts. The robot waiter greets people before taking their order

More information

Requirements Engineering: Specification & Validation. Software Requirements and Design CITS 4401 Lecture 18

Requirements Engineering: Specification & Validation. Software Requirements and Design CITS 4401 Lecture 18 Requirements Engineering: Specification & Validation Software Requirements and Design CITS 4401 Lecture 18 The Problems of Requirements What goal(s) are we trying to satisfy? How do we identify the scope

More information

Ontology Summit 2013: Ontology Evaluation Across the Ontology Lifecyle Track B: Extrinsic Aspects of Ontology Evaluation

Ontology Summit 2013: Ontology Evaluation Across the Ontology Lifecyle Track B: Extrinsic Aspects of Ontology Evaluation Ontology Summit 2013: Ontology Evaluation Across the Ontology Lifecyle Track B: Extrinsic Aspects of Ontology Evaluation Black Box Testing Paradigm in the TCPC #014168-PA Mary Balboni, Doug Toppin, Thanh-Van

More information

Scheduling & Rationality

Scheduling & Rationality Scheduling & Rationality SOE MM10 Scheduling & Tracking Why Are Projects Late? An unrealistic deadline established by outsiders Changing customer requirements not reflected in schedule changes An honest

More information

Sample Question Paper. Software Testing (ETIT 414)

Sample Question Paper. Software Testing (ETIT 414) Sample Question Paper Software Testing (ETIT 414) Q 1 i) What is functional testing? This type of testing ignores the internal parts and focus on the output is as per requirement or not. Black-box type

More information

Software Quality Assurance. David Janzen

Software Quality Assurance. David Janzen Software Quality Assurance David Janzen What is quality? Crosby: Conformance to requirements Issues: who establishes requirements? implicit requirements Juran: Fitness for intended use Issues: Who defines

More information

Examples. Object Orientated Analysis and Design. Benjamin Kenwright

Examples. Object Orientated Analysis and Design. Benjamin Kenwright Examples Object Orientated Analysis and Design Benjamin Kenwright Outline Revision Questions Group Project Review Deliverables Example System Problem Case Studey Group Project Case-Study Example Vision

More information

The Analysis and Proposed Modifications to ISO/IEC Software Engineering Software Quality Requirements and Evaluation Quality Requirements

The Analysis and Proposed Modifications to ISO/IEC Software Engineering Software Quality Requirements and Evaluation Quality Requirements Journal of Software Engineering and Applications, 2016, 9, 112-127 Published Online April 2016 in SciRes. http://www.scirp.org/journal/jsea http://dx.doi.org/10.4236/jsea.2016.94010 The Analysis and Proposed

More information

AC63/AT63/AC114/AT114 SOFTWARE ENGINEERING DEC 2015

AC63/AT63/AC114/AT114 SOFTWARE ENGINEERING DEC 2015 Q.2 a. What is System Engineering? Explain in detail. (12) Systems engineering is the activity of specifying, designing, implementing, validating, deploying and maintaining socio technical systems. Concerned

More information

Presenter: Dong hyun Park

Presenter: Dong hyun Park Presenter: 200412325 Dong hyun Park Design as a life cycle activity bonds the requirements to construction Process of breaking down the system into components, defining interfaces and defining components

More information

Software Evolution. Dr. James A. Bednar. With material from

Software Evolution. Dr. James A. Bednar.  With material from Software Evolution Dr. James A. Bednar jbednar@inf.ed.ac.uk http://homepages.inf.ed.ac.uk/jbednar With material from Massimo Felici, Conrad Hughes, and Perdita Stevens SAPM Spring 2012: Evolution 1 Software

More information

Software Testing. Software Testing. in the textbook. Chapter 8. Verification and Validation. Verification and Validation: Goals

Software Testing. Software Testing. in the textbook. Chapter 8. Verification and Validation. Verification and Validation: Goals Software Testing in the textbook Software Testing Chapter 8 Introduction (Verification and Validation) 8.1 Development testing 8.2 Test-driven development 8.3 Release testing 8.4 User testing 1 2 Verification

More information

Ingegneria del Software II academic year: Course Web-site: [www.di.univaq.it/ingegneria2/]

Ingegneria del Software II academic year: Course Web-site: [www.di.univaq.it/ingegneria2/] Course: Ingegneria del Software II academic year: 2004-2005 Course Web-site: [www.di.univaq.it/ingegneria2/] Verification and Validation Lecturer: Henry Muccini and Vittorio Cortellessa Computer Science

More information

Evaluating the Evolution of a C Application

Evaluating the Evolution of a C Application Evaluating the Evolution of a C Application Elizabeth Burd, Malcolm Munro Liz.Burd@dur.ac.uk The Centre for Software Maintenance University of Durham South Road Durham, DH1 3LE, UK Abstract This paper

More information