Quiz Examination in Software Engineering Theory



Similar documents
Requirements engineering

Karunya University Dept. of Information Technology

TDDC88 Lab 2 Unified Modeling Language (UML)

Requirements engineering and quality attributes

Project Management. Lecture 3. Software Engineering CUGS. Spring 2012 (slides made by David Broman) Kristian Sandahl

Masters of Science in Software & Information Systems

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

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

IT3205: Fundamentals of Software Engineering (Compulsory)

TECH. Requirements. Why are requirements important? The Requirements Process REQUIREMENTS ELICITATION AND ANALYSIS. Requirements vs.

SOFTWARE ENGINEERING INTERVIEW QUESTIONS

Contents. Introduction and System Engineering 1. Introduction 2. Software Process and Methodology 16. System Engineering 53

Non-Functional Requirements

IT3203 Fundamentals of Software Engineering (Compulsory) BIT 2 nd YEAR SEMESTER 3

Decomposition into Parts. Software Engineering, Lecture 4. Data and Function Cohesion. Allocation of Functions and Data. Component Interfaces

Chapter 4: Tools of Modern Systems Analysis

Software testing. Objectives

The Role of the Software Architect

UML Diagram Types. Use Cases do the Following. Use Case Diagram

Requirements / Use Case Specification

Software Requirements Metrics

Software Engineering. How does software fail? Terminology CS / COE 1530

How To Develop Software

COURSE CODE : 4072 COURSE CATEGORY : A PERIODS / WEEK : 4 PERIODS / SEMESTER : 72 CREDITS : 4

SOFTWARE QUALITY MODELS: A COMPARATIVE STUDY

SOFTWARE REQUIREMENTS

Software Testing. Definition: Testing is a process of executing a program with data, with the sole intention of finding errors in the program.

Quality Management. Lecture 12 Software quality management

Modernized and Maintainable Code. Frank Weil, Ph.D. UniqueSoft, LLC

CPS122 Lecture: State and Activity Diagrams in UML

Basic academic skills (1) (2) (4) Specialized knowledge and literacy (3) Ability to continually improve own strengths Problem setting (4) Hypothesis

The Role of Information Technology Studies in Software Product Quality Improvement

Characteristics of Computational Intelligence (Quantitative Approach)

Software Requirements Specification

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

Requirements Engineering for Web Applications

Object-Oriented Systems Analysis and Design

Software Engineering Question Bank

CREDENTIALS & CERTIFICATIONS 2015

Using Power to Improve C Programming Education

IEEE Computer Society Certified Software Development Associate Beta Exam Application

ICS 121 Lecture Notes Spring Quarter 96

(BA122) Software Engineer s Workshop (SEW)

How To Understand The Organizational Model Of A Multiagent System

COSC 3351 Software Design. Recap for the first quiz. Edgar Gabriel. Spring For the 1 st Quiz

Information Systems Analysis and Design CSC340. XXIV. Other Phases

Use Cases. Massimo Felici. Massimo Felici Use Cases c

Social Network Website to Monitor Behavior Change Design Document

Software Specification and Architecture 2IW80

Software Metrics. Lord Kelvin, a physicist. George Miller, a psychologist

Software cost estimation

Aerospace Software Engineering

A Software Engineering Model for Mobile App Development

Development of AUTOSAR Software Components within Model-Based Design

Introduction to Algorithms March 10, 2004 Massachusetts Institute of Technology Professors Erik Demaine and Shafi Goldwasser Quiz 1.

Structure of Presentation. Stages in Teaching Formal Methods. Motivation (1) Motivation (2) The Scope of Formal Methods (1)

BCS Certificate in Systems Modelling Techniques Syllabus

The Software Development Process

How To Understand Software Engineering

3. Mathematical Induction

CHAPTER 2. Logic. 1. Logic Definitions. Notation: Variables are used to represent propositions. The most common variables used are p, q, and r.

CPS122 - OBJECT-ORIENTED SOFTWARE DEVELOPMENT. Team Project

Assuming the Role of Systems Analyst & Analysis Alternatives

Swirl. Multiplayer Gaming Simplified. CS4512 Systems Analysis and Design. Assignment Marque Browne Manuel Honegger

Software Engineering. What is SE, Anyway? Based on Software Engineering, 7 th Edition by Ian Sommerville

Chapter 4 Software Lifecycle and Performance Analysis

Applying 4+1 View Architecture with UML 2. White Paper

Software Development: An Introduction

Software Quality Management

Requirements Engineering Process

Modeling Guidelines Manual

Outline. Definitions. Course schedule

R214 SPECIFIC REQUIREMENTS: INFORMATION TECHNOLOGY TESTING LABORATORY ACCREDITATION PROGRAM

Chapter 7: Software Engineering

Case studies: Outline. Requirement Engineering. Case Study: Automated Banking System. UML and Case Studies ITNP090 - Object Oriented Software Design

Vancouver Chapter Study Group. BABOK Chapter 1 Introduction. Jorge Vega

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

Organizational Requirements Engineering

User experience storyboards: Building better UIs with RUP, UML, and use cases

Software Requirements Specification. Task Management System. for. Prepared by. Version 1.0. Group Name: Pink and Purple. Date:

4. Multiagent Sys stems Design. Part 2: The PROMETHEUS methodology.

A Framework for Software Architecture Visualization and Evaluation

Lecture 8 About Quality and Quality Management Systems

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 5 Diploma in IT SYSTEMS ANALYSIS & DESIGN EXAMINERS REPORT

IF2261 Software Engineering. Introduction. What is software? What is software? What is software? Failure Curve. Software Applications Type

Lecture 9: Requirements Modelling

An Introduction to Software Engineering

An Introduction to Software Engineering. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1

Application of UML in Real-Time Embedded Systems

Certified Software Quality Engineer (CSQE) Body of Knowledge

The V-model. Validation and Verification. Inspections [24.3] Testing overview [8, 15.2] - system testing. How much V&V is enough?

Transcription:

LINKÖPINGS UNIVERSITET IDA Kristian Sandahl, David Broman Quiz Examination in Software Engineering Theory Date: 2008-09-19 Time: 16.20-17.00 This quiz examination is optional. If the student passes the quiz examination, he/she will earn 10 extra credits on the written examination on 2008-10-22. Note: The 10 extra credits will ONLY be valid on the written examination in October 2008. They will not be valid on any re-take exam or exams in coming years. This quiz is applicable for students taking / retaking courses: TDDB61, TDDB62, TDDC01, TDDC06, TDDC88, TDDC93. Allowed aids: One volume of dictionary to or from English or an English wordbook. Pass condition: To pass the quiz examination, the student must earn at least 50% of the total amount of possible credits. Result: The correct solution will be published on the course website latest on 2008-09-24. The individual results will be returned latest on the lecture on 2008-09-26. Instructions to students, please read carefully This is a multiple choice exam, where each assignment consists of a number of statements. If you think that a statement is true, the checkbox should be marked. If you believe the statement is false, leave the box empty. Note that more than one statement can be true on each assignment. For each statement that is checked and is in fact true, one credit is earned. For each statement that is checked and is in fact false, one credit is lost. It is not possible to get less than 0 credits on each assignment. Example1: A student has selected alternative A, C and D. The correct answer is only A. Hence, the student gets 0 credits out of 1 for the assignment. Example2: A student has selected alternative B. The correct answers are B and C. Hence, the student gets 1 credit out of 2 for the assignment. Good Luck! Kristian Your name (print) Signature Personal number TDDC88-TDDC93 (A) Page 1(8)

Problems Assignment 1. Project Management (A) It is not necessary to have a one-to-one relationship between mile-stones and toll-gates. Mile-stones can be set in a project plan without the direct connection to a toll-gate, and it is possible that several mile-stones have to be fulfilled before a single toll-gate passage is due. Mile-stones can be used for all internal goals of a project. (B) A mile-stone should have the properties of a SMART-goal That is in the definition of a mile-stone. (C) A toll-gate is a project-team internal decision False. The very idea with a toll-gate is that external stakeholders, such as, the customer should influence the decision of the continuation of the project. (D) The risk magnitude indicator of a risk is calculated by adding the probability and impact of that risk. False. You multiply the probability and the impact. (E) COCOMO and the Delphi methods are two parametric effort estimation methods False. Delphi is an expert judgmental method which has no connection to parametric estimation methods. Assignment 2. Architecture and Design (A) The pipe-and-filter architecture requires a UNIX-style operating system False. Pipe-and-filter is a general architecture. UNIX has operations that allow the realization of a pipe-and-filter system, even in small scale. TDDC88-TDDC93 (A) Page 2(8)

(B) You can combine the pipe-and-filter architecture and the layered architecture by implementing one or several layers according to the pipe-andfilter architecture. Most architectural styles can be applied on various levels. The combination above is not uncommon. (C) The Façade design pattern can be used when implementing a layered architecture. The idea with a single entry point to several components is central both in Façade and layered architecture. The major difference is that Façade does not exclude direct calls behind the Façade. (D) One consequence of having low cohesion is that you don t have to check many modules if you just did a change in one of the modules. False. The statement is true for coupling, which can be independent of cohesion. Even if you have low cohesion you can still have both high and low coupling. Assignment 3. UML part I Clean the machine <<include>> Open machine Service Collect coins <<include>> <<extend>> Add change (A) The use-case Open machine is a base use-case. False. The base use-cases are Clean the machine and Collect coins. Open machine is an inclusion use-case. (B) <<extend>> denotes that this is a stereotype with extended meaning for the association. That is the definition. TDDC88-TDDC93 (A) Page 3(8)

(C) The diagram shows that Clean the machine and Collect coins have to be done in parallel as soon as the flow of action is finished for Open machine. False. An actor can be associated with many use-cases without imposing any parallelism. The inclusion of Open the machine has nothing to do with parallelism, its only a convenient way of factoring out common behaviour. Assignment 4. UML - part Ii (A) Several instances of Attribute can be associated to the same instance of Type. (B) The number of the instances of Attribute and Operation must be the same for the instance of a single Class. False. The star indicates an arbitrary number of instances for each association. (C) Type is an abstract class that cannot be instantiated. False. The UML notation would require that the class name was in italic font for an abstract class.. (D) An instance of Attribute can be associated to an instance of Primitive_Type. Primitive_Type inherits the association from Type. TDDC88-TDDC93 (A) Page 4(8)

Assignment 5. Testing A B C D E F G H I J K L M (A) In data-flow testing it is acceptable if you find a variable that is first killed and later used. False. The KU is the most serious data flow fault. (B) Control-flow testing statement coverage requires more test cases than condition coverage since there are often more statements than conditions. False. Condition testing is a stronger coverage metric. They are equal for a program that has no conditions. (C) The order of a bottom-up integration testing of components in the hierarchy diagram above can look like: LM, LMK, LMKF, GHIJ, LMKFBCDE, GHIJD, LMKFBCGHIJDEA False. A correct one can look like: LMK, LMKF, LMKFB, GHIJD, LMKFBCGHIJDEA (D) When implementing a bottom-up integration approach, you need to implement drivers. (For a top-down approach, stubs would have been needed instead.) (E) An oracle is a human being or a system that determines if a test is successful by examining the input and the generated output from a test object. TDDC88-TDDC93 (A) Page 5(8)

Assignment 6. Requirements part I (A) The requirement The user must be able to change his or her personal password is a functional requirement. (B) The requirement After 14 days of some usage, an average user must be able to run the system for at least 4 hours without using any help information, look up in the user manual or asking a colleague is a functional requirement. False. This is a typical non-functional requirement, even though it is a bit underspecified. (C) The requirement The system shall lower the curtains if disturbing reflections occur in the room. can be regarded as a good, functional requirement meeting most of the desired properties of a requirement. False. It is definitely not a good requirement, it is impossible to test unless specified much better. (D) It is a good idea to make an initial stakeholder analysis before formulating the use-cases, because many of the stakeholders will be represented as actors. (E) It is important to follow the IEEE std 830 for Software Requirements Specification as close as possible. This will make your project compatible with the rest of the world even though you will have to write not applicable for many headlines. False. You should always adapt standards to your own company and customer. A requirements specification shall be as readable as possible, since there are many readers with different background. The standard itself gives suggestion of how to adapt the headlines for different types of software. Assignment 7. Requirements part II (A) Specifying requirements with mathematical, formal notation, such as Z, practically means that you have access to some tool support, since even fairly small systems soon become incomprehensible for humans. Only trivial systems are tractable, for instance, since the satisfiability proof grows exponentially. TDDC88-TDDC93 (A) Page 6(8)

(B) Parallel test in acceptance testing means that you investigate if performance can be increased by parallelizing the most critical algorithms. False. In parallel test you are running the new system and an older system in parallel to measure, for instance, increase in efficiency. (C) Requirements elicitation can be performed with demonstrations of different prototypes of a forthcoming system for customers and their endusers. This is a very good method, but you have to be aware that human bias might make the users commit too early to a certain approach to a solution. (D) Classifying requirements along different classification is a waste of time since all requirements are so likely to be changed anyway. False. By, for instance, classifying requirements according to stability you can identify requirements that are not likely to be changed, and give them extra attention as regards testability, clarity etc... (E) When you validate requirements you make sure, for instance, by simulation, that you have specified the true needs of customers and users. Assignment 8. Quality (A) By using the acronym REAL when detailing usability we mean that usability can be sub-divided into Reliability, Egoless Programming, Availability and Low cost. False. We mean Relevance, Efficiency, Attitude and Learnability. The words in the question can, of course, indirectly influence usability, but they are neither direct nor covering most of usability aspects. (B) Failure intensity is measured by grading failures according to a severity ranking scale. False. Failure intensity is measured as the number of failures per execution hour. (C) A safety requirements checklist can contain issues such as: Start-up routines of the system, Exception handling, Data ageing and how certain commands can be reversed. Plus many more. TDDC88-TDDC93 (A) Page 7(8)

(D) Prototyping methods, such as agile programming can never reach any quality systems, since they issue releases so frequently that none of them can be made with afterthought. False. For instance, usability benefit a lot from prototyping approaches with demonstration of systems to the end-users. (E) High testability means that it is easy to localize a fault to a single component. That s one reason of why low coupling leads to testable systems. TDDC88-TDDC93 (A) Page 8(8)