2. Draw and explain state transition diagram for a typical weather information system. (8M)
|
|
- May Black
- 6 years ago
- Views:
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 Objectives To introduce software process models To describe three generic process models and when they may be
More informationLecture 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 informationSoftware 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 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 informationSoftware 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 informationTopic: 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 informationVerification 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 informationLegacy 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 informationSoftware 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 informationObject-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 informationW.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 informationVerification 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 informationChapter 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 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 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 informationIan 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 informationObject-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 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 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 informationSoftware 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 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 informationDocumentation & 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 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 informationVerification 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 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 informationSoftware 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 informationThe 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 informationChapter 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 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 informationΗΜΥ 317 Τεχνολογία Υπολογισμού
ΗΜΥ 317 Τεχνολογία Υπολογισμού Εαρινό Εξάμηνο 2008 ΙΑΛΕΞΕΙΣ 18-19: Έλεγχος και Πιστοποίηση Λειτουργίας ΧΑΡΗΣ ΘΕΟΧΑΡΙ ΗΣ Λέκτορας ΗΜΜΥ (ttheocharides@ucy.ac.cy) [Προσαρμογή από Ian Sommerville, Software
More informationSoftware 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 informationAerospace 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 informationIntroduction 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 informationSOFTWARE 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 informationBasics : 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 informationChapter 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 informationSoftware 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 informationSoftware 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 informationSoftware 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 informationOverview. 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 informationCSC 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 informationSoftware 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 informationTHE 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 informationObjectives. 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 informationSOFTWARE 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 informationSoftware 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 informationSoftware 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 informationSOFTWARE 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 informationVerification 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 informationRecap 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 informationChapter 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 informationSoftware 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 informationSoftware 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 informationASTQB 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 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 informationHigher-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 informationFirst 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 informationInternational 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 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 information2 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 informationLecture 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 informationSoftware 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 informationTopics 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 informationInternational 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 informationChange 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 informationLow 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 informationChapter 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 informationLesson 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 informationLecture 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 informationUNIT-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 informationDeliver 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 informationVerification 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 informationPatterns 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 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 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 informationSEG3201 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 informationBuilding 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 informationA 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 informationChapter : 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 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 informationUSTGlobal 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 informationQuality 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 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 informationCategorizing 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 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 informationComputational 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 informationRequirements 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 informationOntology 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 informationScheduling & 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 informationSample 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 informationSoftware 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 informationExamples. 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 informationThe 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 informationAC63/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 informationPresenter: 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 informationSoftware 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 informationSoftware 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 informationIngegneria 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 informationEvaluating 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