eva trosborgslide no.: 1introduktion to object oriented software engineering introduktion to object...

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

Introduktion to Object Oriented Software Engineering

Fall 2005

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

by

Eva Trosborg


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 – 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


Carsten Buhl Frederiksen – Our Instructor

• Working experience

• Teori– Cand Scient i Datalogi


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.


Goal for this module (2/2)

5. Implement (a part of) the detailed design6. 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


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.


Literature

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

– …


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.


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?


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?


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]


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


Report

The exercises take place in form of a project. During the first two weeks we assign project teams of about 8 students eachEach 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 ManagementConfiguration ManagementDocument handling andTest planningOf 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.


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.


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


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


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?


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


Wish-list for group assignmentBelow 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.

RoleYour priority (1-4, 1=highest)

Arguments

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.


And then the real thing


What is a System?

• Elements:– Program

– HW

– People

– Database

– Documentation

– Procedures

– Education

– …


What is Development?


Much more than programing


What is so very special about System development


Methodology Definition 1


Methodology suggests …


Methodology Definition 2


Methodology Components 1


Methodology Components 2


Reasons to adopt a methodology

• A better end product – Acceptability– Availability– Cohesiveness– Compatibility– Documentation– Ease of learning– Economy– Effectiveness– Efficiency– Fast development rate– Flexibility– Functionality

• A better development process• A standardised process

– Implementability– Low coupling– Maintainability– Portability– Reliability– Robustness– Security– Simplicity– Testability– Timeliness– Visibility


Issues in Systems Development


Designing methodologies


Tools and toolsets

• Tools– Project management :

• MS Project

– Groupware: • GroupSystems Ventura

– Web site development: • Dreamweaver

– Drawing:• Microsoft Visio

– Database management system: • Access

• Toolsets– Information Engineering

Facility

– Select

– Oracle


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?


System Development Components

System Development

Performance Management

Realization Regulation

AnalysisDesign EvaluationPlanning

Presentreality

Visions

Present reality

Visions

Reflection

Action

Process Oriented

Product Oriented


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


Balancing Resources

Strategy• Choices

Budget Timescales Human Resources

Outsource Partnership In House

ConsultantsFunction Application Integrators


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

Waterfall model


The ‘b’ model

Analysis

Operation

Inception

Design

Acceptance

Production

Evaluation Analysis

Design

Production

Inception

Figure 6.2 The ‘b’ modelSource: Derived from N D Birrell & M A Ould, A Practical Handbook for Software Development, Cambridge University Press, 1985


RUP - Rational Unified Model

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


The ‘V’ model

Requirementsdefinition

Requirementsspecification

High-leveldesign

Technicalspecification

Low-level design

Modulespecifications

Moduleproduction

Developedmodules

Module testing

tested modules

Integration andtest

Integratedsystem

System testing

Tested system

Customeracceptance

Acceptedsystem

Customerrequirements

Module testplan

Develop/agreeacceptance

criteria

Producemodule test

plan

Integration testplan

Produceintegration test

plan

System testplan

Generatesystem test

plan

Acceptancecriteria

Activity Product

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


The incremental approach

Feasibility studyHigh-level

design

Requirementsdefinition &

developmentplanning

Feedback/validation/verification

Detaileddesign

Systemintegration

Operation

Code & unittest

Installation &system test

Increment 1

Detaileddesign

Systemintegration

Operation

Code & unittest


Increment 2

Detaileddesign

Systemintegration

Operation

Code & unittest


Increment 3

Figure 6.4 The incremental model


Requirement specfication

Archtectural design

Running system

Preanalysis

Development

Maintenance

For each itteration: detailed design, programming test and delivery to customer

Partly incremental modelThis model is often used in RAD (Rapid

Application Development)


The spiral model – evolutionary development

Plan next phases

Determine objectives, alternatives, constraints

Evaluate alternatives, identify and resolve risks

Develop, verify next-level product

Figure 6.5 Boehm’s spiral modelSource: Based on Computer, May 1988, © 1988, IEEE


Spiralmodel – simpel form

(Analyse & design)


Spiralmodel [Boehm, IEEE 1998]

ReviewCommitment

Partition

Determineobjectives, alternatives,constraints

Progressthrough steps

Cumulativecost

Plan next phase

Develop, verifynext-level product

Evaluate alternatives,identify, resolve risks

RiskAnalysis

Concept ofOperation

Requirement planlife-cycle plan

Prototype 1Prototype 2 Prototype 3OperationalPrototype

RiskAnalysis

RiskAnalysis

RiskAnalysis

Simulations, models, benchmarks

SoftwareRequirements

SoftwareProductDesign

DetailedDesign

Development Plan

Integration and TestPlan

ImplementationAcceptanceTest

IntegrationTest

UnitTest

CodeRequirementValidation

Design validationand verification


Traditional approach to analysis

Analysis notesetc

Analyserequirements

Specifyrequirements

Draftrequirementsspecification

Reviserequirementsspecification

Agreedrequirementsspecification

Producehigh-levelsystemdesign

High-leveldesign

specification

Supply termsof reference

andinformation

Review draftrequirementsspecification

To programspecification, codingetc

TORs, information

Specification

Reviewcomments

Limited user involvement; driven by developers

Users

Developers

Figure 6.6 The traditional approach


Structured systems development

Agreedphysical

description

Analysecurrentphysicalsystem

Derive logicaldescription

Agreed logicaldescription

Producelogical design

Agreed logicaldesign

Producephysicaldesign

Draft physicaldesign

Provide dataand review

analysisresults

Assist/agreein preparing

logical design

To programspecification,coding etc

TORs,information

Greater user involvement at all stages; driven by users

Users

Developers

Assist/agreein producinglogical view

Reviewphysicaldesign

Revisephysicaldesign

Agreedphysicaldesign

QuestionsQuestions

Information

Questions,suggestions

Information,decisions

Suggesteddesign

Reviewresponses


DSDM• Dynamic Systems Development Methodhttp://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


Aigile methods why?


Rightsizing methodology

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

There is a limit


Rightsizing methodology

Leight methods

Heavy methods needed

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


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

Eva Trosborg

eva trosborgslide no.: 1introduktion to object oriented software engineering introduktion to object...

Documents

smaller software system

software development

eva trosborgslide

eva trosborg slide

system development project

datalogi slide

introdutionary module

smaller project