Introduktion to

Object Oriented Software Engineering

Fall 2005
by
Eva Trosborg
Agenda
• Teacher: Eva Trosborg
• The goal of this module
• What is System Development? ..
• System Development models
• System Development methods

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 1

 After this lesson you should :

• Have an overview of the module Object

Oriented Software Engineering, the project
and the exam
• Be able to explain the typical phases in a
System development project.
• Be able to argument for different system
development models, advantages and
disadvantages

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 2

 Eva Trosborg – Who is she?
• Working experience
– IBM (Danmark og France)
– PS-Data A/S - PS-Engineering - PS-Informatic
– Nordania Leasing / Danske Bank
– PBS
– Dansk Arbejdsgiver Forening
– Niels Brock, Datamatikeruddannelsen – Shanghai Finance University -
ITU
• Teori
– Cand Scient i Datalogi
– HD i Organisation
– Lederuddannelser IBM og DA ++
– MBA - CBS
• Privat

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 3

 Carsten Buhl Frederiksen –
Our Instructor
• Working experience

• Teori
– Cand Scient i Datalogi

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 4

 Goal for this module (1/2)
When the module ends you should be able to:
1. Explain the typical activities in a Software development
process and discuss the advantages and disadvantahges of
different software development models.
2. Analyse a given situation and write a simple requirement
specification for a smaller software system using object
oriented techniques such as use case diagrams.
3. Develop and document an overall architectural design of a
smaller software system with the help of object oriented
techniques such as interaction diagrams, class diagrams
and package diagrams.
4. Develop and document a detailed design with the help of
object oriented techniques.

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 5

 Goal for this module (2/2)
5. Implement (a part of) the detailed design
6. Design a test strategy and test the software in respect
to the requirements and the design specification
(corresponding to high-level testing typically called
integration testing and acceptance testing)
7. Explain configuration management and organize
version management in a smaller project
8. Discuss quality management as well as plan and
implement quality reviews in a smaller project.
9. Reflect on the usefulness of methods, techniques and
diagrames for specific development context

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 6

 The way the module is run

• Many different topics – a ballance between getting an overview

but also producing a result and reflections on the process.
• The module are based on dialog, practical experiments,
groupwork and report writting. A module where you have to
attend.
• It is an introdutionary module, where the ability to analyses,
design, implement and reflect is evaluated higher than the
ability to repeat and understand every detail in what is written
in the books .
• Based on the students work with development and report for
the selected case.

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 7

 Literature
– Craig Larman (2004). Applying UML and
Patterns : An Introduction to Object-Oriented
Analysis and Design and Iterative Development
(3rd Edition). Prentice-Hall.
–…

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 8

 Process of the exam
• The examination takes place January 5th. – 7th. 2006.
• The exam is individual and without preparation
• The 30 minutes for each student. The examination is based on the
project report and takes the process related task each student has
been responsible for into account. The project report provide a base
for the examiners to start the questioning. Though the quality of the
report is not determining the grading, it of course gives an indication.
den studerende fremlægger projekt rapport,
• 5 – 10 min questions to the project (if the student allows, it can be an
integrated part of the presentation)
• 5 – 10 min At the exam you are drawing a question concerning the
curriculum. Try to connect the project, the goals of the module and a
practical problem for the student or a role / situation to be handled.
The important is to be able to reflect, analysis not just describe and repeat.
• The grading is according to the 13-grade scale. The grade expresses
the evaluation of the report, the reflection on the process-oriented
task by the student and the oral examination. The project itself is not
graded.
• 5 – 10 minutes for grading and entrance of the next student.
• Examples of exam questions will be available later on the module
homepage.

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 9

 Example could be:

Exam question #3 to Object Oriented System Engeneering Januar 2006

Design principles and architecture

You have been asked to explain 2 principles in design: Low Coupling and
High Cohesion?
Give some examples where Low Coupling and High Cohesion can be
beneficial?

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 10

 Another question could be like:

Exam question #6 to Object Oriented System Engeneering Januar 2006

Quality Management

Try to imagine you are employed in one of the largest banks IT-department in
Denmark. Every year the bank are running 40 – 50 projects which last around
12 month, there are typically 25 users and developers involved. At the top of
this the bank run 5 – 7 strategically important projects (50 – 200) involved
lasting in average 18 months.
Your boss has been on a course and was told that Danish companies should
make more quality reviews. He is a little confused – what is it ? and have asked
you to explain.

What is a quality-review?
How would you suggest the bank could organize quality reviews?

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 11

 Practice
• Lectures, guest teachers and student
presentation
– Fridays 9.00 – 11.45, room 3A14
• Supervision
– Fridays 13.00 – 16.00, 3A14, 3A58,
3A60, 4A44, 4A46, 4A62, 4A64
• Module homepage under construction
• E-mail [email protected]
Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 12
 Project will be run in parallel with
the lessons
• An important part of the module take in
consideration a specific organization which the
students follow and writes their project for.
• In the very beginning of the module the
students are placed in a group.
• Groups are not final before every student are
part of one.
• Discuss and agree upon aspiration level
• Discuss and agree upon working method and
degree of delegation

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 13

  Report
The exercises take place in form of a project. During the first two weeks we assign project teams of about
8 students each
Each student is expected to spend around 100 hours on the project. This includes writing the project
report. We provide a project setting and a “fictive” customer. The project task will be presented during the
first lecture.
The project teams develop an adequate program or prototype.
Each project team has to organize its own work! This means you have to Agree on the distribution of
work, the project model, Specify the scope of the different process related tasks, Specify form and exact
context of the different documents, Agree on level of ambitions regarding the process related tasks,
…
Each student has to contribute to a process related task in relation to his or her:
Project Management
Configuration Management
Document handling and
Test planning
Of course you also have to do the job: That means every project has to take care of analysis, design,
implementation and test. Report max 60 pages.

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 14

 The Project Report contains
• PID – Project Initiation Document
• The process part should contain:
– A joint motivation for the overall organisation and division between different process related tasks,
– The project plan
– A reflection on the project management task by the students responsible for it,
– The quality management plan,
– A reflection on the quality management by the students responsible
– Configuration management
– A reflection on the configuration management by the students responsible
– The test plan
– A reflection on the test plan by the students responsible
– The individual or small group reflections should motivate the specific interpretation of the respective role
and an evaluation of what worked out, what did not work, and why, and how to do things better next time.
• The product part should contain:
– A requirements specification,
– Rationale for the requirements specification,
– The analysis document,
– A rationale for the analysis document,
– The design
– A reatinale for the design document
– The implementation
– A motivation for the implementation technology and a discussion how the implementation relates to
design, and requirements document.

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 15

Julia Grishina [email protected] Kandidat, INT
Tanja Danner Nielsen [email protected] Kandidat, SWU
Mikkel Byrsø Dan [email protected] Kandidat, SWU
Nicki Lehmann Møller [email protected] Kandidat, SWU
Trine Koch Lavlund [email protected] Kandidat, SWU
Jie Yang [email protected] Kandidat, INT
Claus Skoubølling Jørgensen - Kandidat, SWU
Herman Svensen [email protected] Kandidat, SWU
Thabet Al Assadi [email protected] Kandidat, INT
Thomas Krohn [email protected] Diplom
Tomas Bo Krag [email protected] Kandidat, INT
Lars Holmquist [email protected] Kandidat, SWU
Martin Vyuga [email protected] Kandidat, INT
Hanne Sofie Jensen [email protected] Kandidat, SWU
Louise Ege [email protected] Kandidat, INT
Rokas Firantas [email protected] Kandidat, INT
Bent Erik Nielsen [email protected] Enkeltfagsstuderende
Martynas Jusevicius - Kandidat, INT
Jun Li [email protected] Kandidat, INT
Suresh Vanga [email protected] Kandidat, MMT
Jens Lind [email protected] Kandidat, SWU

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 16

Jacob Mouni Grande [email protected] Kandidat, SWU
Vibeke Søderhamn Bülow [email protected] Kandidat, SWU
Morten Nordholt Andersen [email protected] Kandidat, SWU
Christian Willumsen [email protected] Kandidat, SWU
Brian James Cowan [email protected] Kandidat, MTG-T
Deike Drieseberg [email protected] Kandidat, INT
Sadia Rehman [email protected] Kandidat, EBUSS
Lars Christian Olsen [email protected] Kandidat, INT
Andreas Møller Holst [email protected] Kandidat, SWU
Sune Østerberg Andersen [email protected] Kandidat, SWU
Qingwei Cai [email protected] Kandidat, INT
Fei Yang [email protected] Kandidat, INT
Jacob Atzen [email protected] Kandidat, SWU
Stavros Amanatidis [email protected] Kandidat, INT
Ulrich Haslund [email protected] Kandidat, SWU
Veronika Capskaja [email protected] Kandidat, INT
Kim Loc Nguyen [email protected] Master, INT
Nils Kasper Emil Oldby [email protected] Kandidat, SWU
Jens Mondrup [email protected] Enkeltfagsstuderende
Kim Velling Frederiksen [email protected] Kandidat, SWU

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 17

 Who are you ?

• Who are you? Practical experience and previous

education
• Why the IT University?
• Why this module?
• Previous experience in System Development and
other IT related topics?
• Important knowledge before forming groups?

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 18

 The friendly summer cottage rental company
(Friends & Summer (F&S))

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 19

 Wish-list for group assignment
Below please give your priority of the role you want to take on in the project work.
Choosing a role does not mean, that you only have to work with that part of the project work. You have to participate in all work in
the project group, as you agree on in the group when distributing the work.
The role you get makes you (and normally your partner, since two persons in each group will bee assigned to each role) the primary
responsible for the success of that particularly aspect of the project. This also means that you will bee the “driving force” behind that
aspect, and that you will make the final decision, should you be unable to reach agreement in the group.
I cannot guarantee that everyone will be given their 1. priority, but each role is considered equally important. If you already during
work or other have tried one role, then choose another to try it out.

Your priority (1-4, Arguments

Role 1=highest)
Project manager

Configuration manager
+
Document handling
Quality assurance

Test planning

Send this document (with the priority-column filled in !!) to [email protected] before the 6. sept. 2005.
Any question (at any time), can also be send to me, and I will try to answer as soon as possible.

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 20

 And then the real thing

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 21

 What is a System?
• Elements:
– Program
– HW
– People
– Database
– Documentation
– Procedures
– Education
– …

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 22

 What is Development?

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 23

 Much more than programing

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 24

 What is so very special about
System development

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 25

 Methodology Definition 1

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 26

 Methodology suggests …

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 27

 Methodology Definition 2

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 28

 Methodology Components 1

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 29

 Methodology Components 2

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 30

 Reasons to adopt a methodology
• A better end product – Implementability
– Acceptability – Low coupling
– Availability
– Cohesiveness
– Maintainability
– Compatibility – Portability
– Documentation – Reliability
– Ease of learning
– Economy
– Robustness
– Effectiveness – Security
– Efficiency – Simplicity
– Fast development rate
– Flexibility – Testability
– Functionality – Timeliness
– Visibility
• A better development process
• A standardised process

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 31

 Issues in Systems Development

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 32

 Designing methodologies

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 33

 Tools and toolsets

• Tools • Toolsets
– Project management : – Information Engineering
• MS Project Facility
– Groupware: – Select
• GroupSystems Ventura – Oracle
– Web site development:
• Dreamweaver
– Drawing:
• Microsoft Visio
– Database management system:
• Access

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 34

 Yet more questions
• Will methodologies solve the problems of IS
development?
• Do methodologies have to change and develop?
• Do methodologies mean more bureacracy and
slower development?
• Should all organisations adopt a methodology?
• Where do methodologies go from here?

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 35

 System Development
Components Vision Presen Vision Presen
s t s t
reality reality

System Development
Reflection Performance Management
Design Analysis Planning Evaluation

Action Realization Regulation

Product Process
Oriented Oriented

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 36

 What is a Project?
• ‘A temporary endeavour undertaken to accomplish a
unique purpose’
• Better understood by its attributes
– Time frame
– Purpose
– Ownership
– Resources
– Roles
– Risks / Assumptions
– Interdependent tasks
– Organisational change
– Operating in an environment larger than itself

Taken from Marchewka, J. T. Information Technology Management, Wiley 2003

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 37

 Balancing Resources

• Choices Strategy

Budget Timescales Human Resources

Outsource Partnership In House

Function Application Integrators Consultants

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 38

 Waterfall model

Kilde: Steve McConnell (1996). Rapid development. Microsoft Press. Side 139.

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 39

 The ‘b’ model
Inception

Analysis

Design

Production

Acceptance Production

Operation Design

Evaluation Analysis

Inception

Figure 6.2 The ‘b’ model

Source: Derived from N D Birrell & M A Ould, A Practical Handbook for Software Development, Cambridge University
Press, 1985
Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 40
 RUP - Rational Unified Model

Kilde: http://www.rational.com/products/rup/whitepapers.jsp

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 41

 The ‘V’ model
Customer Accepted
Activity Product
requirements system

Requirements Customer
definition acceptance

Develop/agree
Requirements Acceptance
acceptance Tested system
specification criteria
criteria

Generate
High-level System test
system test System testing
design plan
plan

Produce
Technical Integration test Integrated
integration test
specification plan system
plan

Integration and
Low-level design
test

Produce
Module Module test
module test tested modules
specifications plan
plan

Module Developed
Module testing
production modules

Source: Adopted and reproduced with the permission of the National Computing Centre Limited from the STARTS Guide,
1987, which was supported by the Department of Trade and Industry
Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 42
 The incremental approach
Detailed
design Code & unit
Requirements test System
definition & High-level
Feasibility study integration Installation &
development design
planning system test
Operation

Increment 1

Detailed
design Code & unit
Feedback/ test System
validation/ integration Installation &
system test
verification Operation

Increment 2

Detailed
design Code & unit
test System
integration Installation &
system test
Operation

Increment 3

Figure 6.4 The incremental model

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 43
 Partly incremental model
This model is often
Preanalysis used in RAD (Rapid
Requirement specfication Application
Archtectural design
Development)
For each itteration:
detailed design,
programming
test and delivery
to customer

Development
Running system
Maintenance

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 44

 The spiral model – evolutionary
Determine development Evaluate
objectives, alternatives,
alternatives, identify and
constraints resolve risks

Develop,
verify next-
Plan next level
phases product
Figure 6.5 Boehm’s spiral model
Source: Based on Computer, MayIntroduktion
Eva Trosborg 1988, © 1988,to
IEEE
Object Oriented Software Engineering Slide no.: 45
 Spiralmodel – simpel form

(Analyse & design)

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 46

 Spiralmodel [Boehm, IEEE 1998]
Cumulative Progress
cost through steps Evaluate alternatives,
Determine
identify, resolve risks
objectives,
alternatives,
constraints Risk
Risk Analysis
Risk Analysis
Analysis
Risk
Commitment Analysis Operational
Review Prototype 1Prototype 2 Prototype 3 Prototype
Partition Simulations, models, benchmarks
Requirement plan Concept of
life-cycle plan Operation Detailed
Software Design
Development Plan Requirement Requirements
Software Code
Validation
Product
Plan next phase Design Unit
Integration and Test Design validation Test
Plan and verification
Integration
Acceptance Test
Implementation Test Develop, verify
next-level product

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 47

 Traditional approach to analysis
Supply terms Review draft
of reference requirements
and specification
information
Review
comments
TORs, information
Users

Specification
Developers

Draft Agreed Produce High-level

Analysis notes Revise
Analyse Specify requirements requirements high-level design
etc requirements
requirements requirements specification specification system specification To program
specification
design specification, coding
etc

Limited user involvement; driven by developers

Figure 6.6 The traditional approach

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 48
 Structured systems development
Provide data
Assist/agree Assist/agree Review
and review
in producing in preparing physical
analysis
logical view logical design design
results

TORs, Information, Review

Information
information decisions responses Users

Questions Questions
Questions,
suggestions
Suggested
design Developers

Analyse Agreed Agreed

Agreed logical Agreed logical Produce Draft physical Revise
current physical Derive logical Produce physical
description design physical design physical
physical description description logical design design
design design To program
system
specification,
coding etc

Greater user involvement at all stages; driven by users

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 49

 DSDM
• Dynamic Systems Development Method
http://www.dsdm.org/en/about/principles.asp
9 key principles
– Users must be actively involved
– Teams must be empowered to make decisions
– Products are delivered frequently rather than perfected
– Each product should be fit for its business purpose
– Iterative and incremental development is an integral part of the
approach
– All changes are viewed as being reversible
– The high level scope of the system should be agreed at a level
which does not make it difficult to change it later in development
– Testing is an integral part of the lifecycle
– All stakeholders must co-operate and collaborate

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 50

 Aigile methods why?

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 51

 Rightsizing methodology

There is a limit

Kilde: Alistair Cockburn (2001). Agile software Development. Addison-Wesley

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 52

 Rightsizing methodology
Heavy
methods
needed

Leight methods Kilde: Alistair Cockburn (2001). Agile software Development. Addison-Wesley

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 53

 I’m looking forward to see you
again the 9th September

Eva Trosborg

Eva Trosborg Introduktion to Object Oriented Software Engineering Slide no.: 54