course summary and old exam - department of computer and ...tddc93/timetable/15summary.pdf ·...

Course Summary and Old exam

Lecture 14

Kristian Sandahl

Department of Computer and Information Science

Linköping University, Sweden

[email protected]

Software Engineering

TDDC88/TDDC93

autumn 2007

2

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3

Theory Lecture Plan

L1 - Course Introduction and Overview

L2 - Project Management

L3 - Requirements

L4 - Acceptance Testing and Quality Factors

L5 – UML

L6 - Design Patterns

L7 - System Design and Architecture

L8 - Testing Theory

L9 - Testing in Practice

L10 - Inspection

L11 - Software Life Cycles and Configuration Management

L12 - Software Quality Management

L13 - Course Summary, Exam examples, QuestionsL13 – Course summary, old exam, questions

3

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3

A Software Life-cycle Model

Which part will we talk about today?

Requirements

System Design(Architecture,

High-level Design)

Module Design(Program Design,

Detailed Design)

Implementationof Units (classes, procedures,

functions)

Unit testing

Module Testing(Integration testing of units)

System Testing(Integration testing of modules)

Acceptance Test(Release testing)

Validate Requirements, Verify Specification

Verify System Design

Verify Module Design

Verify Implementation

Project Management, Software Quality Assurance (SQA), Supporting Tools, Education

Maintenance

4

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3

Requirements

� Elicitation

� Analysis

� Specification

� Modeling

� Formalization

� Validation

� IEEE Std 830

� Natural language specifications

� Use-case

� Actor

� Classes

� Data model

� Non-functional requirements

5

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3

Fundamental – requirements

1a) Describe three different properties that written requirements in

a natural language requirements specification shall have. (3)

1a) Non-ambiguous, numbered, testable, consistent, complete, prioritized

6

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


1b) Non-functional requirements bear on how the system shall perform its

functions. Quality requirements, such as usability, belong to them.

A design constraint is a non-functional requirements that constrain the

solution space for the design, for instance, requiring a special operating

system.

A data dictionary holds information about the variables that the system shall

handle. Typical contents are: data structures, resolution, units, allowed

ranges, error codes.

1b) Explain the terms non-functional requirement, design constraint and data

dictionary. (3)

7

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


1c) Describe 4 use-cases and draw a use-case diagram of a self scanning system in a

shop. A self scanning system allows a user to scan European Article Number (EAN)

codes of all articles, and deduct the sum from the customer’s shopping account.

Special solutions apply to alcohol, tobacco and non-packaged articles, such as,

vegetables. (4)

8

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


1c) Scan an article. The customer selects an article from the shelf and moves the laser reader

close to the price tag. A sound confirms the scan, and the name and price of the article is

displayed in the screen. When the screen is dark the scanner is ready for next item.

Scan vegetables. The customer puts the vegetables in a plastic bag and goes to the scales.

The plastic bag is put on the scales and the correct button is pressed. A EAN-label is printed

that is put on the plastic bag. The customer moves the laser reader close to the price tag. A

sound confirms the scan, and the name and price of the article is displayed in the screen.

When the screen is dark the scanner is ready for next item.

Scanning tobacco. The customer selects a card from the shelf, with the brand of tobacco

printed. The customer moves the laser reader close to the card. A sound confirms the scan,

and the name and price of the article is displayed in the screen. A text indicating the the

customer will be required to show an ID is lit. When the screen is dark the scanner is ready for

next item.

Checking out. The customer leaves the scanner to the clerk who jacks it to a reader. The

customer is asked to provide an PIN-code, and possibly also show an ID. When the sign "Köp

avslutat" is lit, the customer get a receipt and leaves the shop.

9

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3

Design and architecture

� Box-and-line diagram

� Time

� Development

� Run-time

� Deployment

� Coupling - Cohesion

� Scale up - scale out

� Architecture styles

� Pipes and filters

� Layers

� Client-server

� Design patterns

� Strategy

� Observer

� Façade

� UML: sketching, blueprinting,

programming language

� class diagram: attributes,

association. composition,

generalization

� object diagrams

� sequence diagram

� state machine diagrams

� activity diagrams

� deployment diagrams

10

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3

Fundamental - design

2a) Give at least two reasons for why it is important to design and document software

architectures. Motivate your reasons by giving examples in a software project where a

consulting company should deliver a booking system to a bus shuttle company. (3)

- It eases communication between different stakeholders

- It makes it possible to involve experts in early design decisions.

- It opens for large-scale reuse since sub-systems and their interfaces are specified early

This is especially important for a booking system were quality factors such as number

of simultaneous users and response time are so important. These often depends

on decisions taken in the architectural design. Since there are many booking systems

on the market there is a good chance that re-usable components are available.

11

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


2b) Explain the differences and similarities between coupling and cohesion of

modules, by giving examples from a standard software library (e.g. File I/O). In

which case do we prefer high and/or low levels of these properties? (3)

Both coupling and cohesion describe relationship between software parts, for instance, an

operation of a class calls another operation. If we describe relations within a single

class we are talking about cohesion. If we describe relations between different

classes we are talking about coupling.

Normally we want high cohesion, in an i/o package we would like all operations we need

of i/o in a single package, but we would be distracted if there were more operations

not dealing with i/o.

We also like low coupling, if we change somewhere in the system we would not like to

search for ripple effects all over the system. Some central functions such as i/o will

inevitable be highly connected to the rest of the system.

12

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


2c) Draw a UML class diagram of your choice, which models a concrete system. The

diagram should contain at least the following three types of relations between classes:

association, composition, and generalization. State explicitly in the diagram the type

of relation, i.e., print out if it is an association, composition, or generalization. Explain

in detail the differences between these three relations by using your example diagram.

CoffeeCustomer

Porter

CupOfCoffee

CanOfCoffee

buys

buys

0..1

0..1

0..*

0..*

makes

makes

machine

11

1 11

1

1

1

0..*

0..*

Interface CoinHandler Brewer

The coffee machine consists

of three parts, it can’t exist

without them, so I use

composition.

The porter can act as a CoffeCustomer but

have a special task: to brew a can. Gene-

realisation shows inheritance of all properties.

Associations are generic and

needs more explanation to

describe their meaning. They

can be directed and have diff-

erent cardinality.

13

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3

Testing

� Error, Fault. Failure

� Black-box testing

� White-box testing

� Oracle

� Equivalence class testing

� Boundary value testing

� Control graph testing

coverage

� Data-flow testing coverage

� Unit testing

� Regression testing

� Integration testing

� System testing

� Acceptance testing

� Benchmarking

� Pilot testing

� alpha test

� beta test

� Installation testing

� Parallel testing

14

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3

Fundamental - testing

3a) State the main rationale for doing equivalence class testing, compared to

exhaustive testing. (2)

Equivalence class testing reduces the number of test cases.

It saves time and thus makes it possible to have a better test coverage.

It is very rare that exhaustive testing is realistic.

15

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


3b) For each of the following statements, state if it is true or false. If you claim that a

statement is false, give a rationale for why this is the case. (5)

1. System testing’s main purpose is to validate the requirements.

2. When using a bottom-up integration strategy, it is especially important to

create stubs.

3. JUnit is a testing framework for automated unit testing.

4. If a developer makes an error, it can lead to a fault in the software. If this

software is executed, it can result in a failure.

5. Black-box testing is a method where the control-flow of the source code is

statically examined.

1. False. That is the job for acceptance testing. System testing’s main purpose is to

verify the high-level design.

2. False. Stubs are important when using a top-down strategy. When using bottom-up, it

is necessary to have drivers.

5. False. Black-box testing is testing where the system as seen as a black box, i.e. we

have new knowledge of the internals, such as source code. Relation between input and

output is tested.

16

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


3c) Imagine that you are the team leader of a software development team creating a

client-server system for an online poker system. The system is built up of many

modules (e.g. GUI module, encryption module, backup module, transaction module

etc.) which should be integrated together in a reliable manner. Choose if you want to

use a bottom-up, top-down, or a big-bang integration strategy. Explain the chosen

strategy with an example and explain why you think that this approach is preferable

over the other ones. State also if you see any drawbacks with the chosen strategy. (3)

The top down is preferable, because you can start to develop and test

many modules at the same time by using stubs.

In the big bang approach you have to wait until all modules are ready.

Bottom-up is also feasible from a planning point of view, but since there

are many modules, you would like to test out the entire concept including

the interfaces for security-critical modules.

17

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3

Planning and processes

� Project, Process

� Stakeholders

� SMART goals

� Milestone, Tollgate

� Critical path

� COCOMO

� Delphi

� Risk analysis: Probability, Impact

� Risk plan: Avoid, Transfer, Accept

� Risk management

� Models

� Waterfall

� V-model

� Spiral

� Iterative development

� Incremental development

� Time-boxing

� Processes and methodologies

� RUP - Inception, Elaboration, Construction, Transition

� Agile

• Extreme programming (XP)

• Scrum

� Configuration Management

18

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3

Fundamental – planning and processes

4a) Explain the main properties of a project. Discuss the differences between a project

and a process. Give examples of both a typical project and a process. (3)

A project is a temporary organisation with:

- A goal

- An orderer

- A start and a stopping date

- A budget

A process describes how an input generates output in terms of:

- Sequence of activities

- Who is going to get what information when?

- Constraints

- Resource consumption

A process is often generic and is used in projects, together with other processes to accomplish

the goal. A typical project is our student projects that can use a process for inspecting

code.

19

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


4b) Software Configuration Management (SCM) is critical when managing a

successful software project.

• Give at least two reasons why the above statement is true. (2)

• Generally, SCM tools are necessary for efficient SCM. Name at least one open

source or commercial SCM tool. Give a brief overview for how the tool is

working by describing at least one of its principal functions. (2)

An SCM tool makes it possible:

-to track down which version a specific customer has.

-for many developers to work on the same code base.

-to locate bugs if you get trouble reports such as “Worked in the previous version.”

SCM tools, such as CVS, subversion etc, provides commit, update, merge, diff functions.

20

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


4c) Explain the main differences and similarities between the waterfall model and

the spiral model. (3)

Spiral model focus on risks, waterfall model is not doing so explicitly.

Traditional (misinterpreted) waterfall model does not have iteration. Spiral model do

have this, where the risk is assessed in each step.

Both models go through different phases, e.g. requirements, developments, testing

etc.

The main objective of the spiral model is to describe how software is naturally

constructed. The waterfall model is more for hardware.

A beginner can use and/or understand the waterfall model. The spiral model needs

some preparation

The spiral model can be harder to coordinate with hardware development.

Both models work in industry.

21

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3

Quality factors

� Usability engineering

� Relevance

� Efficiency

� Attitude

� Learnability

� Reliability engineering

� Failure intensity

� Safety

� Hazard, Incident, Accident

� Inspection

� Roles

� Process

� Inspection record

� Weaker methods

� Management

� Software metrics

� Software quality factors

� ISO 9000-3

� Total Quality management

� CMMI or CMM levels 2 and 3

22

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3

Fundamental – Quality factors

5a) You have asked a technical novice customer to write down some initial

requirements about the usability of a system the customer would order from you. You

received the following:

1. The system shall fit well in our current routines.

2. The system shall be easy to learn by our users.

3. A user using the system shall process tasks much faster compared to manual

routines.

4. Almost all users shall appreciate working with the system.

5. The visible interface shall not look too different compared to Windows

applications.

Your task is now to write an answer to the customer where you give examples of how

each of the requirements can be expressed more precisely. Skip all polite phrases and

write the examples’ part only. (5)

23

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


1. The system's use cases shall match the use-cased developed for the business process.

2. The average user shall be able to process all tasks after 4 hours training in class and one

week using the system in parallel with manual routines.

3. The average user shall be able to process all tasks at least twice as fast compared to the

average processing time of the task in question.

4. In a questionnarie after two week of usage at least 90% of the users shall rate the

question "To what degree do you appreciate working with the system? (1-5, 5 is best)", with

a 4 or a 5.

5. The GUI shall comply to the standard rules described in "The Windows Interface

Guidelines for Software Design: An Application Design Guide"

24

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


5b) Describe the terms capability maturity level and (key) process area in CMMI. (2)

5b) The capability maturity level is the outcome of an CMMI assessment of an

organisations and describes its proficiency in developing software with good quality in a

repeatable manner.

A process area describes in detail what is required for a certain maturity level in a special

area, for instance requirements development.

25

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


5c) Explain the benefits for a software development organisation following three of

the IS0 9001 principles:

• Continual improvement

• Factual approach to decision making

• Mutually beneficial supplier relationships

5c) Continual improvement means that everyone tries to use experience to adjust the processes

for each iteration of the processes. Thus there are good opportunities for better product quality,

cost control and job satisfaction.

A factual approach to decision making increases the probability of a more correct decision than

decisions on "gut feeling". It certainly makes it possible to control and improve the decision

process. Better decisions will provide better product quality, cost control and job satisfaction.

Mutually beneficial supplier relationships will give your suppliers a better opportunity for

delivering the right solutions with the needed quality. They will also dare investing in process

and product improvement as well as increasing their understanding of your problem. This is

preferred to use fierce competition to select only the lowest price and being prepared to spend

money on re-doing the software acquisition if the supplier is out of business or hesitates in

making new business with you.

26

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3

Advanced – problem 6 - scenario

6) Imagine that you are the development manager for a software development

company, which is creating geographic information system (GIS) products. A GIS

product integrates hardware, software, and data for managing, capturing, analyzing,

and displaying different geographic information, e.g., digital maps. The company is

specialized on maps with sensitive data aimed for the military market. The system is

based on a client-server architecture, where the server stores the map data, and the

clients consist of various wireless handheld devices, which are used for analyzing and

displaying maps. The company has 20 employees, where 11 are working in your

development team.

OK, quite small company. Multitude of mobile devices.

Sensitive information. Central server.

There is a huge consumer market for similar products.

27

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3

Advanced – problem 6

6 a) You are currently using a development approach, which has similarities with the waterfall

model. For project management, you are using a commercial tool. Typically, you use this

tool for generating Gantt charts and calculating critical paths in the plan. Explain all phases

in detail from idea to delivered product and draw the different parts in a Gantt chart. Note

that your system is released in several versions and that the system is divided into several

subsystems during development. Explain how you create the critical path, locate the slack,

and describe what use you have from them. (10)

Phases:

- Concept exploration. Ideas are generated and pruned and a vision of the system is generated.

- Analysis. The vision is detailed, and specified in distinct requirements that are organized in a

requirements specification

- Design. A system fulfilling the requirements is modelled in a high-level architectural model,

and each subsystem is described in a detailed design specification.

- Implementation. The design is implemented in code. Each module is unit-tested.

- Integration test. All modules are gradually integrated to a working system

- System test. The entire system is tested against the architecture and technical quality goals

- Acceptance test. The system is installed and validated by users.

- Deliver and plan next iteration.

28

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


6 a) You are currently using a development approach, which has similarities with the waterfall

model. For project management, you are using a commercial tool. Typically, you use this

tool for generating Gantt charts and calculating critical paths in the plan. Explain all phases

in detail from idea to delivered product and draw the different parts in a Gantt chart. Note

that your system is released in several versions and that the system is divided into several

subsystems during development. Explain how you create the critical path, locate the slack,

and describe what use you have from them. (10)

Critical path –

sequence of activities that add to the,

longest duration, cannot be delayed

Slack, can be used for unplanned activities

29

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


6 b) You are also looking into switching to agile methods. Explain what this is and

how it differs compared to you current approach. Give both pros and cons of

switching. (5)

Agile methods are lightweight methods with:

- Frequent releases, perhaps every week. - Now you release once a year.

- Frequent customer feed-back. – Now you meet the customer only in requirements

and acceptance test

- Flat structure teams – Now you have split responsibilities.

- Minimum of documentation – Now you need documents to forward your development

- Much is governed by values – Now you work with process descriptions

Pros of switching:

- Less paper work

- More customer involvement

Cons of switching:

- More demands on people’s skill and presence

- More work on integration and refactoring

30

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


c) The methodology you have been looking into mostly is the Extreme

programming (XP) approach. Explain in detail the 3 practices in XP that you

find most appealing. (5)

6c) Pair programming, means that all production code is made by two persons sitting

together at the workstation. The programmers take turn in operating the keyboard. This

means that the code solutions are checked as it is produces and that unclear matters are

sorted out already at the coding, compared to a normal peer review.

No overtime, means that we put high demands on personnel at work, both when it comes

to producing solutions and communicating. To stand this demands and develop a

professional it is important to have healthy personnel with opportunities to rest and growing

personal interests and family life.

Frequent customer feed-back means that you ensure you are always on the right track.

This makes you more prepared to take on changes and reduces the overhead for planning.

31

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


d) 40% of the customer contracts have fixed price, i.e., the price and

requirements are signed off in the beginning of a project. The rest of the

contracts are based on payment per hour. Discuss pros and cons of your

choice of software development model, depending on if the customer contracts

have fixed price or if the payment is per hour. (5)

6d) With very rare exceptions, XP is not well suited to fixed requirements and fixed prices. The

very idea behind XP is to embrace changing requirements and adapt as customer explore his

actual needs by evaluating early prototypes of the system. Fixed price might be a little easier,

since you always have some value to deliver to the user you can work until resources are

emptied, but again the best system will be developed as a result of continuous evaluation of

releases. So with XP projects paying per hour is preferable.

The waterfall model, on the other hand, build on the idea of fixing the requirements and

optimizing the design to fulfil the specification. With a good set of historical data, experience

persons can use different methods to assess the price. A normal margin of 15% can then be

added to the price, since estimations tend to have an accuracy of +- 20%.

32

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


e) Select 3 quality factors that seem especially important for the company.

Discuss how the choice of software lifecycle model can affect the quality

factors. (5)

6e) The usability of the hand-held devices is high priority. Almost all literature in the field

advocates some kind of prototyping and frequent evaluations using real end-users. Thus XP is

well-suited to this. If waterfall is used and you are quite sure about the functions you might run the

GUI development as a prototype activity in parallel to other development, but this can threaten the

relevance.

Security, the sensitive information needs protection. Very often this means that you have to

integrate standard components for cryptography and other means to reach the customer

requirements. Requirements from standards and integration of components is probably best

handled by the waterfall model, but you can also imagine a mix of methods where a first base-line

of secure data management is made, and then XP can be used in filling the application with

functions.

Response time, is important since updates must be made while you are moving in the terrain.

There are several algorithms and communication traffic simulation models that can be used in

providing data to a good design once all the requirements are known. This speaks for the waterfall

model, especially if we can do some experiments in the design phase. Again, XP, can still be a

useful model in working with later releases.

33

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3

Advanced – problem 7 - scenario

7) Imagine you are developing an auction system for private persons. The features

include, but are not limited to:

- User account management

- Advertise design system

- Search for different articles to buy

- Auction management system

- Bidding system

- Fairly trusted payment system

Now you are supposed to describe either the entire system or a sub-system by:

Aha, we have some high level features and users. We can decide if we are going for

the broad design or if we do detailed design. Maybe we can mix on different

sub-questions?

34

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


a ) Five functional requirements. (5)

R1: The user shall be able to upload the advertisement

R2: The user shall be able to upload pictures

R3: The user shall be able to preview the advertisement

R4: The user shall be able to search for articles by text search

R5: The user shall be able to search for articles available in a certain town in Sweden

35

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


b ) A UML class diagram with at least five classes, where all classes have

attributes and operations. (5)

+getAdvertisments()

-Name

User

+getURL()

-datePosted

Advertisment

+currentTopBid()

-Category

Article

+getRank()

-dateGiven

Bid

+getBalance()

-number

PayPal account

-publish10..*

-Owns

1

0..*

-describes

1 1..*

-has

1 1..*

-isGiven1*

36

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


c ) A UML sequence diagram with at least 5 transactions and three roles (same as

participants or objects). (5)

:user :Auctionsystem :PayPalAccount

Login

Confirm

Send(:bid)

HighestBid

PaymentOrder(Bid)

Divert

LoginPromt

37

Part I

Heading text 1

Part II

Heading text 2

Kristian Sandahl

[email protected]

Part III

Heading text 3


d ) Five functional test cases with input and expected output. (5)

T1 Input: Bid -10 kr

Output: Error: Bid must be a positive integer

T2 Input: Bid 0 kr

Output: Error: Bid must be a positive integer

T3 Input: Bid 100 kr

Output: Bid received 100 kr, please confirm (y/n)

T4 Input: Bid <maximum> kr

Output: Bid received <maximum> kr, please confirm (y/n)

T5 Input: Bid <maximum>+1 kr

Output: Error: Bid must be less than <maximum>

course summary and old exam - department of computer and ...tddc93/timetable/15summary.pdf ·...

Documents