Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
Course Summary and Old exam
Lecture 14
Kristian Sandahl
Department of Computer and Information Science
Linköping University, Sweden
Software Engineering
TDDC88/TDDC93
autumn 2007
2
Part I
Heading text 1
Part II
Heading text 2
Kristian Sandahl
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
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
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
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
Part III
Heading text 3
Fundamental – requirements
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
Part III
Heading text 3
Fundamental – requirements
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
Part III
Heading text 3
Fundamental – requirements
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
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
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
Part III
Heading text 3
Fundamental - design
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
Part III
Heading text 3
Fundamental - design
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
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
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
Part III
Heading text 3
Fundamental - testing
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
Part III
Heading text 3
Fundamental - testing
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
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
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
Part III
Heading text 3
Fundamental – planning and processes
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
Part III
Heading text 3
Fundamental – planning and processes
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
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
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
Part III
Heading text 3
Fundamental – Quality factors
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
Part III
Heading text 3
Fundamental – Quality factors
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
Part III
Heading text 3
Fundamental – Quality factors
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
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
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
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)
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
Part III
Heading text 3
Advanced – problem 6
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
Part III
Heading text 3
Advanced – problem 6
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
Part III
Heading text 3
Advanced – problem 6
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
Part III
Heading text 3
Advanced – problem 6
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
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
Part III
Heading text 3
Advanced – problem 7
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
Part III
Heading text 3
Advanced – problem 7
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
Part III
Heading text 3
Advanced – problem 7
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
Part III
Heading text 3
Advanced – problem 7
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>