OOADObject Oriented Software Engineering

Fall 2005

16. september

by

Eva Trosborg

Agenda 16. september 2005

• Change log homepage • Requirement checklist • Configuration Management • Group reports• Stakeholder analysis• Question and answers session (plan)• (MS-Framework)• Elaboration Larman chapter 8 – 13• Interviews with F&S owners• Group work• Deliverables 20/9 P-Plan & progress report

Change log of material for course Object Oriented Software Engineering, E2005This is a log over changes and additions to material published through the course homepage. New material is added at the top og the list. (back to course homepage)

Date Time Changes/additions

15.09.2005 19.40 Changed lecture plan document to reflect that 23-9 will be database modelling (because I find it more appropriate at this point in time

13.09.2005 20.40 Added Ref's to config. and test management Added Ref to Søren Laugesen: Software Requirements

11.09.2005 17.40 Added time schedule for interviews requirements

15.30 Added checklist for requirements

From the requirement checklist 1

• General:– Is it written in a clear language, correct use of terminology and terms

(in a language the customer can understand)?– If customer-specific terms are used, are they explained (eventually in

a separate term section)?– Are interview notes used to extract requirements? If so, are

requirements traceable to these notes? – Is each requirement uniquely identified to support traceability?– Can each requirement be tracked to their goal (i.e. marketing goal,

performance goal …)?– Is it stated as complete, concise and written in grammatically correct

English sentences?– Can it be passed on without further explanation to an independent

design team?– Can it be passed on to the testing to be validated?– Are requirements grouped (if necessary)?– Are requirements supplemented with use-case diagrams?

From the requirement checklist-2

• Completeness.– Do you feel sure all requirements are present? (could be checked via a cross-

reference.)– Are there any requirements which make you feel uneasy?– Are any requirements related to performance included?– Are any requirements related to security included?– Are any requirements related to maintainability included?– Are requirements for external interfaces specified?– Are requirements for “out-of-line” situations specified?– If the system is a “web-system”, has special web-requirements been included?– Is there a change log showing when the requirement was changed (after

acceptance)?– Is the scope adequate (i.e. are all requirements necessary and feasible)?– Are the requirements placed in a context, so an understanding of what the

system will do is given to the reader (or is it just a list of requirements)?

From the requirement checklist-3

• Quality.– Does each requirement avoid conflict with

other requirements?– Do the requirements avoid specifying

design? (What not how)– Are the requirements at a fairly consistent

and sufficient level of detail to avoid misunderstandings?

– Is there a priority assigned to each requirement?

The DieHards………………………

Project management Jens LindThomas Petersen

Configuration Management Andreas Møller HolstHerman Svendsen

Quality Management Stephan SpangenbergThomas Krohn

Test planning Claus Skoubølling JørgensenMartin Vyuga

The LuckyOnes…………………….

Project management Qingwei Cai (Simon)Tor Bechman Sørensen

Configuration Management Kim Loc Nguyen (Not on participant list)Fei Yang

Quality Management Stavros AmanatidisSuresh Vanga

Test planning Martynas JuseviciusRokas Firantas

The Outsiders………………………

Project management Jacob AtzenTanja Danner NielsenLouise Ege

Configuration Management Ulrich HaslundChristian Willumsen Morten Nordholdt Andersen

Quality Management Veronika CapskajaNicki Lehmann Møller

Test planning Younes NielsenBent Erik Nielsen

The Favorites……………………..

Project management Lars HolmquistLars Christian Olsen

Configuration Management Mikkel Byrsø DanJens MondrupNiels Kasper Emil Oldby

Quality Management Trine Koch LavlundKim Velling Frederiksen

Test planning Sune Østerberg Andersen Vibeke Sønderhamn

The Tiny Group

Nicolai RitzDeike Driesenberg

Lucky Ones

Project management•Qingwei Cai (Simon)•Tor Bechmann Sørensen•Tanja Danner Nielsen (now working with other group)

Configuration Management•Kim Loc Nguyen •Fei Yang

Lucky Ones

Quality Management•Stavros Amanatidis•Deike Drieseberg (Doing something else with Nicolai)•Suresh Vanga (Still need to be confirmed)

Test planning•Martynas Jusevicius•Rokas Firantas

Group Agreements

Working hours•10-15 efficient hours (!) including classes•Meet every Friday•Extra meetings on Thursdays if needed

General procedure•Assign home work every Friday•Discussion and review of the past weeks work Fridays

(extra meeting day will be arranged during the project period)

Group Ambitions

Learning and Grades•We are aiming for a grade above 10•We want to let all participants try new roles and functions to ensure that,•all participants can learn a maximum of new skills during the course

Social Goals•Maintain a high level of communication within the group•Overcome disagreements and other problems together

Project Throughout

•Project Analysis

•Project Design

•Project Implementation

•Project Test

Project Responsibility

Project Analysis•Kim Loc Nguyen•Qingwei Cai (Simon)

Project Design•Martynas Jusevicius•Rokas Firantas

Project Responsibility

Project Implementation•Kim Loc Nguyen•Stavros Amanatidis

Project Testing•Fei Yang•Tor Bechman Sørensen

The Favorites

• Project Management (Lars O. and Lars H.)– General overview

– Control time schedule

– Distribute assignments and follow up

– Produce status reports

– Handle deadlines and revise plans

• Configuration Management (Mikkel, Jens and Kasper)– Document handling

– Versioning

– Control impact of change using UML diagrams

The Favorites

• Quality Management (Trine and Kim)– Specify requirements / measurable requirements

– Make sure requirements are met

• Test Planning (Vibeke and Sune)– When to test and how

– Types of tests (unit, system, performance, acceptance… )

– Usability

– Plan review activities

The Next Steps

• Analyse market for any existing similar solutions• Specify requirements (interview customer)• Discuss copyright issues (regarding future updates/improvements)• Write Use Cases and identify Actors• Present specification of requirements to customer • Get customer’s approval• Isolate a part of the system as an iteration• Develop iteration• Second customer meeting

Definition of the Dream group and What next. We made some basic rules: * be on time - if delayed or cancelling tell someone in group * upload to /SOSU every evening if work has been done that day * feel free to ask how things are going in other parts of the group * feel free to ask for help * feel free to help other members if you have a suggestion on how to do it better. Furthermore we talked about our goal in contradiction to our ambitions. We all want to learn about system engeniring, we want to make a good report and we want to have a good teamwork. We all have the same amount of time available - approx 10-15 hours pr. week - so thats great. Furthermore we agreed to put in extra time now and then if this is neccassary, just that it would only be temporarely. We also came up with some major questions about the system that we will ask our customer this Friday. We decided that the two members in each management group get together during next week, find material about there roles, and discuss this within the group next Friday.Furthermore we have to make some milestones for the project. Also next week. We have established a internet-board, where we can upload / download all our material and discuss the project. We also have a mailing-list, but this is closed for outsiders. So contact the project managers :-)

Stakeholders and stakeholder Analysis

• Stakeholders are any human or non human organization unit that can affect as well be affected by a human or non-human organization unit’s policies or policies’

(Vidgen and McMaster, 1995)

Who are the stakeholders in SISP

• Owners• Employees• Unions• Shareholders• Government• Customers• Suppliers• Community Groups• Competitors (Fidler & Rogerson,

1996)

Top Management group

• Expertise:

• Power:

• IS experience:• IS awareness:

• Corporate strategy,

external markets• Financial resources,

strategic investment• None• Costs! Some

Strategic IS views. EIS needs

Contribution to SISP• Organizational and strategic analysis• Higher level control• IM strategy formulation

User Management group• Expertise:

• Power:

• Previous IS experience:

• IS awareness:

• Business unit strategy,

implementation• Within business unit, field

experiences, Implementation and control of IS

• None or in systems requirements phase

• Awareness of service, cost awareness (perhaps)

Contribution to SISP• Strategy analysis• Bottom-up needs• IS strategy formulation

Information Management group

• Expertise:

• Power:

• IS experience:• IS awareness:

• IS/IT opportunities. Technical

• Co-operation and technical support

• All ISD phases• Up-to-date

technology awareness

Contribution to SISP• Feasibility of IS requirements• IT architecture• IT strategy formulation

Views of stakeholders interests

• Rational: Logical interests, taking an objective view of the problem

• Organizational: Political and social interests

• Individual: Personal interest concerning status, career progress and job security, for example

Stakeholder Group Ralation to the project

Powerbase To do

The DieHards 11.45 – 12.15 Eva 12.45 – 13.15 Carsten

The Outsiders 11.45 - 12.15 Carsten 12.45 - 13.15 Eva

The LuckyOnes 12.15 - 12.45 Eva 13.15 - 13.45 Carsten

The Favorites 12.15 - 12.45 Carsten 13.15 - 13.45 Eva

The TinyGroup 11.45 - 12.15 Eva 13.15 - 13.45 Carsten

Carsten room 3A12

Eva room 3A14