Lecture 02: Project Management, Cost Estimation 2015-04-27 Prof. - - PowerPoint PPT Presentation

– 02 – 2015-04-27 – main –

Softwaretechnik / Software-Engineering

Lecture 02: Project Management, Cost Estimation

2015-04-27

• Prof. Dr. Andreas Podelski, Dr. Bernd Westphal

Albert-Ludwigs-Universit¨ at Freiburg, Germany

Contents & Goals

– 02 – 2015-04-27 – Sprelim –

2/44

Last Lecture:

• Introduction: Engineering, Quality, Software, Software Specification

This Lecture:

• Educational Objectives: Capabilities for following tasks/questions.
• what characterises a project, life cycle, . . . ?
• what is a role, a phase, a milestone, . . . ?
• what are common activities and roles in software development projects?
• what are goals and activities of project management? why project managent?
• what is COCOMO, what is function points? what is it good for?

why to use it with care?

• Content:
• the notion of ‘project’
• project management activities
• what to manage: activities, people, cost and deadlines
• cost estimation, project planning

(Software) Project

– 02 – 2015-04-27 – Sproject –

3/44

project – A temporary activity that is characterized by having a start date, specific

• bjectives and constraints, established responsibilities, a budget and schedule, and

a completion date. If the objective of the project is to develop a software system, then it is sometimes called a software development or software engineering project.

• R. H. Thayer (1997)

(Software) Project

– 02 – 2015-04-27 – Sproject –

3/44

project – A temporary activity that is characterized by having a start date, specific

• bjectives and constraints, established responsibilities, a budget and schedule, and

a completion date. If the objective of the project is to develop a software system, then it is sometimes called a software development or software engineering project.

• R. H. Thayer (1997)

(software) project – characteristics:

• The duration of a project is limited.

(Software) Project

– 02 – 2015-04-27 – Sproject –

3/44

project – A temporary activity that is characterized by having a start date, specific

• bjectives and constraints, established responsibilities, a budget and schedule, and

a completion date. If the objective of the project is to develop a software system, then it is sometimes called a software development or software engineering project.

• R. H. Thayer (1997)

(software) project – characteristics:

• The duration of a project is limited.
• Each project has an “originator” (person or institution which initiated the project).

The project owner is the originator or its representative. The project leader reports to the project owner.

(Software) Project

– 02 – 2015-04-27 – Sproject –

3/44

project – A temporary activity that is characterized by having a start date, specific

• bjectives and constraints, established responsibilities, a budget and schedule, and

a completion date. If the objective of the project is to develop a software system, then it is sometimes called a software development or software engineering project.

• R. H. Thayer (1997)

(software) project – characteristics:

• The duration of a project is limited.
• Each project has an “originator” (person or institution which initiated the project).

The project owner is the originator or its representative. The project leader reports to the project owner.

• Each project has a purpose, i.e. pursue a bunch of goals. The most important

goal is usually to create or modify software; this software is thus the result of the project, the product. Other important goals are extension of know-how, preparation of building blocks for later projects, or utilisation of employees. The project is called successful if the goals are reached to a high degree.

(Software) Project

– 02 – 2015-04-27 – Sproject –

3/44

project – A temporary activity that is characterized by having a start date, specific

• bjectives and constraints, established responsibilities, a budget and schedule, and

a completion date. If the objective of the project is to develop a software system, then it is sometimes called a software development or software engineering project.

• R. H. Thayer (1997)

(software) project – characteristics:

• The duration of a project is limited.
• Each project has an “originator” (person or institution which initiated the project).

The project owner is the originator or its representative. The project leader reports to the project owner.

• Each project has a purpose, i.e. pursue a bunch of goals. The most important

goal is usually to create or modify software; this software is thus the result of the project, the product. Other important goals are extension of know-how, preparation of building blocks for later projects, or utilisation of employees. The project is called successful if the goals are reached to a high degree.

• The product has a recipient (or will have one).

This recipient is the customer. Later users belong to the customer.

(Software) Project

– 02 – 2015-04-27 – Sproject –

3/44

project – A temporary activity that is characterized by having a start date, specific

• bjectives and constraints, established responsibilities, a budget and schedule, and

a completion date. If the objective of the project is to develop a software system, then it is sometimes called a software development or software engineering project.

• R. H. Thayer (1997)

(software) project – characteristics:

• The duration of a project is limited.
• Each project has an “originator” (person or institution which initiated the project).

The project owner is the originator or its representative. The project leader reports to the project owner.

• Each project has a purpose, i.e. pursue a bunch of goals. The most important

goal is usually to create or modify software; this software is thus the result of the project, the product. Other important goals are extension of know-how, preparation of building blocks for later projects, or utilisation of employees. The project is called successful if the goals are reached to a high degree.

• The product has a recipient (or will have one).

This recipient is the customer. Later users belong to the customer.

• The project links people, results (intermediate/final products), and resources. The
• rganisation determines their roles and relations and the external interfaces of the

project.

Ludewig & Lichter (2013)

Software Project: The Very Big Picture

– 02 – 2015-04-27 – Sproject –

4/44

Software!

Customer Developer

software contract

→

1 100 1

Developer Customer

software delivery

Software Project: A Closer Look

– 02 – 2015-04-27 – Sproject –

5/44

Software!

need 1 need 2 need 3 . . .

Customer Developer

announcement

(Lastenheft)

Software Project: A Closer Look

– 02 – 2015-04-27 – Sproject –

5/44

Software!

need 1 need 2 need 3 . . .

Customer Developer

announcement

(Lastenheft)

↓

spec 1 spec 2a spec 2b . . .

§

. . . e

Customer Developer

software contract

(incl. Pflichtenheft)

Software Project: A Closer Look

– 02 – 2015-04-27 – Sproject –

5/44

Software!

need 1 need 2 need 3 . . .

Customer Developer

announcement

(Lastenheft)

↓

spec 1 spec 2a spec 2b . . .

§

. . . e

Customer Developer

software contract

(incl. Pflichtenheft)

→

1 100 1

Developer Customer

milestone N

Software Project: A Closer Look

– 02 – 2015-04-27 – Sproject –

5/44

Software!

need 1 need 2 need 3 . . .

Customer Developer

announcement

(Lastenheft)

↓

spec 1 spec 2a spec 2b . . .

§

. . . e

Customer Developer

software contract

(incl. Pflichtenheft)

→

1 100 1

Developer Customer

milestone N

→

1 100 1

Developer Customer

software delivery

Software Project: A Closer Look

– 02 – 2015-04-27 – Sproject –

5/44

Software!

need 1 need 2 need 3 . . .

Customer Developer

announcement

(Lastenheft)

↓

spec 1 spec 2a spec 2b . . .

§

. . . e

Customer Developer

software contract

(incl. Pflichtenheft)

→

1 100 1

Developer Customer

milestone N

→

1 100 1

Developer Customer

software delivery

↓

Repair!

Customer Developer

maintenance

Software Project: A Closer Look

– 02 – 2015-04-27 – Sproject –

5/44

Software!

need 1 need 2 need 3 . . .

Customer Developer

announcement

(Lastenheft)

↓

spec 1 spec 2a spec 2b . . .

§

. . . e

Customer Developer

software contract

(incl. Pflichtenheft)

→

1 100 1

Developer Customer

milestone N

→

1 100 1

Developer Customer

software delivery

↓ ≃

· · ·

“Developer”: legal person, may comprise many people

Repair!

Customer Developer

maintenance

Software Project: A Closer Look

– 02 – 2015-04-27 – Sproject –

5/44

Software!

need 1 need 2 need 3 . . .

Customer Developer

announcement

(Lastenheft)

↓

spec 1 spec 2a spec 2b . . .

§

. . . e

Customer Developer

software contract

(incl. Pflichtenheft)

→

1 100 1

Developer Customer

milestone N

→

1 100 1

Developer Customer

software delivery

↓ ≃

· · ·

“Developer”: legal person, may comprise many people

Repair!

Customer Developer

maintenance

Topics:

• (software) project management
• manage: tasks, deadlines, resources

(“what? when? by whom?”)

• phases of software projects
• cost estimation, software metrics
• software development processes

(and models thereof)

Cycle and Life Cycle

– 02 – 2015-04-27 – Sproject –

6/44

cycle — (1) A period of time during which a set of events is completed. See also: ...

IEEE 610.12 (1990)

Cycle and Life Cycle

– 02 – 2015-04-27 – Sproject –

6/44

cycle — (1) A period of time during which a set of events is completed. See also: ...

IEEE 610.12 (1990)

software life cycle — The period of time that begins when a software product is conceived and ends when the software is no longer available for use.

The software life cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and, sometimes, retirement phase. IEEE 610.12 (1990)

Cycle and Life Cycle

– 02 – 2015-04-27 – Sproject –

6/44

cycle — (1) A period of time during which a set of events is completed. See also: ...

IEEE 610.12 (1990)

software life cycle — The period of time that begins when a software product is conceived and ends when the software is no longer available for use.

The software life cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and, sometimes, retirement phase. Note: These phases may overlap or be performed iteratively. IEEE 610.12 (1990)

Cycle and Life Cycle

– 02 – 2015-04-27 – Sproject –

6/44

cycle — (1) A period of time during which a set of events is completed. See also: ...

IEEE 610.12 (1990)

software life cycle — The period of time that begins when a software product is conceived and ends when the software is no longer available for use.

The software life cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and, sometimes, retirement phase. Note: These phases may overlap or be performed iteratively. IEEE 610.12 (1990)

software development cycle — The period of time that begins with the de- cision to develop a software product and ends when the software is delivered.

This cycle typically includes a requirements phase, design phase, implementation phase, test phase, and sometimes, installation and checkout phase. Notes: (1) the phases listed above may overlap or be performed iteratively, depending upon the software development approach used. (2) This term is sometimes used to mean a longer period of time, either the period that ends when the software is no longer being enhanced by the developer, or the entire software life cycle. IEEE 610.12 (1990)

Cycle and Life Cycle

– 02 – 2015-04-27 – Sproject –

6/44

cycle — (1) A period of time during which a set of events is completed. See also: ...

IEEE 610.12 (1990)

software life cycle — The period of time that begins when a software product is conceived and ends when the software is no longer available for use.

The software life cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and, sometimes, retirement phase. Note: These phases may overlap or be performed iteratively. IEEE 610.12 (1990)

software development cycle — The period of time that begins with the de- cision to develop a software product and ends when the software is delivered.

This cycle typically includes a requirements phase, design phase, implementation phase, test phase, and sometimes, installation and checkout phase. Notes: (1) the phases listed above may overlap or be performed iteratively, depending upon the software development approach used. (2) This term is sometimes used to mean a longer period of time, either the period that ends when the software is no longer being enhanced by the developer, or the entire software life cycle. IEEE 610.12 (1990)

system life cycle — The period of time that begins when a system is con- ceived and ends when it is no longer available for use.

IEEE 610.12 (1990)

Project Management

– 02 – 2015-04-27 – main –

7/44

“Tanker Summit Europe” von world24 in der Wikipedia auf Deutsch. Lizenziert unter CC BY-SA 3.0 ¨ uber Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Tanker Summit Europe.JPG#/media/File:Tanker Summit Europe.JPG

Project Management

– 02 – 2015-04-27 – Smgmt –

8/44

Goals of Project Management

– 02 – 2015-04-27 – Smgmt –

9/44

• Main and general goal: a successful project, i.e. project delivers
• defined results
• in demanded quality
• within scheduled time
• using the assigned resources.

100 100 100

Developer Customer

software delivery

Secondary goals:

• build or strengthen good reputation on market,
• acquire knowledge which is useful for later projects,
• develop re-usable components (to save resources later),
• be attractive to employees.
• . . .

Goals of Project Management

– 02 – 2015-04-27 – Smgmt –

9/44

• Main and general goal: a successful project, i.e. project delivers
• defined results
• in demanded quality
• within scheduled time
• using the assigned resources.

100 100 100

Developer Customer

software delivery

Secondary goals:

• build or strengthen good reputation on market,
• acquire knowledge which is useful for later projects,
• develop re-usable components (to save resources later),
• be attractive to employees.
• . . .

Goals of Project Management

– 02 – 2015-04-27 – Smgmt –

9/44

• Main and general goal: a successful project, i.e. project delivers
• defined results
• in demanded quality
• within scheduled time
• using the assigned resources.

100 100 100

Developer Customer

software delivery

Secondary goals:

• build or strengthen good reputation on market,
• acquire knowledge which is useful for later projects,
• develop re-usable components (to save resources later),
• be attractive to employees.
• . . .

Goals of Project Management

– 02 – 2015-04-27 – Smgmt –

9/44

• Main and general goal: a successful project, i.e. project delivers
• defined results
• in demanded quality
• within scheduled time
• using the assigned resources.

100 100 100

Developer Customer

software delivery

Secondary goals:

• build or strengthen good reputation on market,
• acquire knowledge which is useful for later projects,
• develop re-usable components (to save resources later),
• be attractive to employees.
• . . .

Goals of Project Management

– 02 – 2015-04-27 – Smgmt –

9/44

• Main and general goal: a successful project, i.e. project delivers
• defined results
• in demanded quality
• within scheduled time
• using the assigned resources.

100 100 100

Developer Customer

software delivery

Secondary goals:

• build or strengthen good reputation on market,
• acquire knowledge which is useful for later projects,
• develop re-usable components (to save resources later),
• be attractive to employees.
• . . .

Goals of Project Management

– 02 – 2015-04-27 – Smgmt –

9/44

• Main and general goal: a successful project, i.e. project delivers
• defined results
• in demanded quality
• within scheduled time
• using the assigned resources.

100 100 100

Developer Customer

software delivery

Secondary goals:

• build or strengthen good reputation on market,
• acquire knowledge which is useful for later projects,
• develop re-usable components (to save resources later),
• be attractive to employees.
• . . .

Activities of Project Management

– 02 – 2015-04-27 – Smgmt –

10/44

• Planning – without plans, a project

cannot be managed. Mistakes in planning can be hard to resolve.

• Assessment and Control – work results

and project progress have to be assessed and compared to the plans; it has to be

• bserved whether participants stick to

agreements.

• Recognising and Fighting Difficulties

as Early as Possible – unforeseen difficulties and problems in projects are not exceptional but usual. Therefore, project management needs to constantly “screen the horizon for icebergs”, and, when spotting one, react timely and

• effectively. In other words: systematic

risk management.

• Communication – distribute information

between project participants (project

• wner, customer, developers,

administration).

• Leading and Motivation of Employees

– leading means: going ahead, showing the way, “pulling” the group. Most developers want to achieve good results, yet need orientation and feedback.

• Creation and Preservation of

Beneficial Conditions – provide necessary infrastructure and working conditions for developers (against: demanding customers, imprecisely stated goals, organisational restructuring, economy measures, tight office space,

• ther projects, . . . )

Activities of Project Management

– 02 – 2015-04-27 – Smgmt –

10/44

• Planning – without plans, a project

cannot be managed. Mistakes in planning can be hard to resolve.

• Assessment and Control – work results

and project progress have to be assessed and compared to the plans; it has to be

• bserved whether participants stick to

agreements.

• Recognising and Fighting Difficulties

as Early as Possible – unforeseen difficulties and problems in projects are not exceptional but usual. Therefore, project management needs to constantly “screen the horizon for icebergs”, and, when spotting one, react timely and

• effectively. In other words: systematic

risk management.

• Communication – distribute information

between project participants (project

• wner, customer, developers,

administration).

• Leading and Motivation of Employees

– leading means: going ahead, showing the way, “pulling” the group. Most developers want to achieve good results, yet need orientation and feedback.

• Creation and Preservation of

Beneficial Conditions – provide necessary infrastructure and working conditions for developers (against: demanding customers, imprecisely stated goals, organisational restructuring, economy measures, tight office space,

• ther projects, . . . )

Activities of Project Management

– 02 – 2015-04-27 – Smgmt –

10/44

• Planning – without plans, a project

cannot be managed. Mistakes in planning can be hard to resolve.

• Assessment and Control – work results

and project progress have to be assessed and compared to the plans; it has to be

• bserved whether participants stick to

agreements.

• Recognising and Fighting Difficulties

as Early as Possible – unforeseen difficulties and problems in projects are not exceptional but usual. Therefore, project management needs to constantly “screen the horizon for icebergs”, and, when spotting one, react timely and

• effectively. In other words: systematic

risk management.

• Communication – distribute information

between project participants (project

• wner, customer, developers,

administration).

• Leading and Motivation of Employees

– leading means: going ahead, showing the way, “pulling” the group. Most developers want to achieve good results, yet need orientation and feedback.

• Creation and Preservation of

Beneficial Conditions – provide necessary infrastructure and working conditions for developers (against: demanding customers, imprecisely stated goals, organisational restructuring, economy measures, tight office space,

• ther projects, . . . )

Activities of Project Management

– 02 – 2015-04-27 – Smgmt –

10/44

• Planning – without plans, a project

cannot be managed. Mistakes in planning can be hard to resolve.

• Assessment and Control – work results

and project progress have to be assessed and compared to the plans; it has to be

• bserved whether participants stick to

agreements.

• Recognising and Fighting Difficulties

as Early as Possible – unforeseen difficulties and problems in projects are not exceptional but usual. Therefore, project management needs to constantly “screen the horizon for icebergs”, and, when spotting one, react timely and

• effectively. In other words: systematic

risk management.

• Communication – distribute information

between project participants (project

• wner, customer, developers,

administration).

• Leading and Motivation of Employees

– leading means: going ahead, showing the way, “pulling” the group. Most developers want to achieve good results, yet need orientation and feedback.

• Creation and Preservation of

Beneficial Conditions – provide necessary infrastructure and working conditions for developers (against: demanding customers, imprecisely stated goals, organisational restructuring, economy measures, tight office space,

• ther projects, . . . )

Activities of Project Management

– 02 – 2015-04-27 – Smgmt –

10/44

• Planning – without plans, a project

cannot be managed. Mistakes in planning can be hard to resolve.

• Assessment and Control – work results

and project progress have to be assessed and compared to the plans; it has to be

• bserved whether participants stick to

agreements.

• Recognising and Fighting Difficulties

as Early as Possible – unforeseen difficulties and problems in projects are not exceptional but usual. Therefore, project management needs to constantly “screen the horizon for icebergs”, and, when spotting one, react timely and

• effectively. In other words: systematic

risk management.

• Communication – distribute

information between project participants (project owner, customer, developers, administration).

• Leading and Motivation of Employees

– leading means: going ahead, showing the way, “pulling” the group. Most developers want to achieve good results, yet need orientation and feedback.

• Creation and Preservation of

Beneficial Conditions – provide necessary infrastructure and working conditions for developers (against: demanding customers, imprecisely stated goals, organisational restructuring, economy measures, tight office space,

• ther projects, . . . )

Activities of Project Management

– 02 – 2015-04-27 – Smgmt –

10/44

• Planning – without plans, a project

cannot be managed. Mistakes in planning can be hard to resolve.

• Assessment and Control – work results

and project progress have to be assessed and compared to the plans; it has to be

• bserved whether participants stick to

agreements.

• Recognising and Fighting Difficulties

as Early as Possible – unforeseen difficulties and problems in projects are not exceptional but usual. Therefore, project management needs to constantly “screen the horizon for icebergs”, and, when spotting one, react timely and

• effectively. In other words: systematic

risk management.

• Communication – distribute

information between project participants (project owner, customer, developers, administration).

• Leading and Motivation of Employees

– leading means: going ahead, showing the way, “pulling” the group. Most developers want to achieve good results, yet need orientation and feedback.

• Creation and Preservation of

Beneficial Conditions – provide necessary infrastructure and working conditions for developers (against: demanding customers, imprecisely stated goals, organisational restructuring, economy measures, tight office space,

• ther projects, . . . )

Activities of Project Management

– 02 – 2015-04-27 – Smgmt –

10/44

• Planning – without plans, a project

cannot be managed. Mistakes in planning can be hard to resolve.

• Assessment and Control – work results

and project progress have to be assessed and compared to the plans; it has to be

• bserved whether participants stick to

agreements.

• Recognising and Fighting Difficulties

as Early as Possible – unforeseen difficulties and problems in projects are not exceptional but usual. Therefore, project management needs to constantly “screen the horizon for icebergs”, and, when spotting one, react timely and

• effectively. In other words: systematic

risk management.

• Communication – distribute

information between project participants (project owner, customer, developers, administration).

• Leading and Motivation of Employees

– leading means: going ahead, showing the way, “pulling” the group. Most developers want to achieve good results, yet need orientation and feedback.

• Creation and Preservation of

Beneficial Conditions – provide necessary infrastructure and working conditions for developers (against: demanding customers, imprecisely stated goals, organisational restructuring, economy measures, tight office space,

• ther projects, . . . )

What to (Plan and) Manage?

– 02 – 2015-04-27 – Smgmt –

11/44

Managing software projects involves

• tasks and activities,
• people and roles,
• costs and deadlines.

What to (Plan and) Manage (1/3)? Tasks and Activities

– 02 – 2015-04-27 – Smgmt –

12/44

What to (Plan and) Manage (1/3)? Tasks and Activities

– 02 – 2015-04-27 – Smgmt –

13/44

Work that commonly needs to be done in order to develop or adapt software:

What to (Plan and) Manage (1/3)? Tasks and Activities

– 02 – 2015-04-27 – Smgmt –

13/44

Work that commonly needs to be done in order to develop or adapt software:

• Analysis – Software is developed to solve a

problem/satisfy a need. Goal of analysis: understand the problem, assess whether/in how far software can be used to solve it.

What to (Plan and) Manage (1/3)? Tasks and Activities

– 02 – 2015-04-27 – Smgmt –

13/44

Work that commonly needs to be done in order to develop or adapt software:

• Analysis – Software is developed to solve a

problem/satisfy a need. Goal of analysis: understand the problem, assess whether/in how far software can be used to solve it.

• Specification
• f

Requirements – sort

• ut,

document, assess, extend, correct . . . results of analysis. Resulting documents are basis of most other activities! Formal methods: check consistency, realis- ability.

What to (Plan and) Manage (1/3)? Tasks and Activities

– 02 – 2015-04-27 – Smgmt –

13/44

Work that commonly needs to be done in order to develop or adapt software:

• Analysis – Software is developed to solve a

problem/satisfy a need. Goal of analysis: understand the problem, assess whether/in how far software can be used to solve it.

• Specification
• f

Requirements – sort

• ut,

document, assess, extend, correct . . . results of analysis. Resulting documents are basis of most other activities! Formal methods: check consistency, realis- ability.

• Design, Specification of Modules – Most

software systems are not monolithic but consist modules or components which in- teract to realise the overall functionality. Overall structure is called software archi- tecture (→ later). Design architecture, specify component interfaces as precise as possible to enable concurrent development and seamless integration. Formal methods: verify that design meets requirements.

What to (Plan and) Manage (1/3)? Tasks and Activities

– 02 – 2015-04-27 – Smgmt –

13/44

Work that commonly needs to be done in order to develop or adapt software:

• Analysis – Software is developed to solve a

problem/satisfy a need. Goal of analysis: understand the problem, assess whether/in how far software can be used to solve it.

• Specification
• f

Requirements – sort

• ut,

document, assess, extend, correct . . . results of analysis. Resulting documents are basis of most other activities! Formal methods: check consistency, realis- ability.

• Design, Specification of Modules – Most

software systems are not monolithic but consist modules or components which in- teract to realise the overall functionality. Overall structure is called software archi- tecture (→ later). Design architecture, specify component interfaces as precise as possible to enable concurrent development and seamless integration. Formal methods: verify that design meets requirements.

• Coding and Module Test – The needed modules

are implemented using the chosen programming language(s). When ready, tested as needed, and ready for integration. Formal methods: verify that code implements design.

What to (Plan and) Manage (1/3)? Tasks and Activities

– 02 – 2015-04-27 – Smgmt –

13/44

Work that commonly needs to be done in order to develop or adapt software:

• Analysis – Software is developed to solve a

problem/satisfy a need. Goal of analysis: understand the problem, assess whether/in how far software can be used to solve it.

• Specification
• f

Requirements – sort

• ut,

document, assess, extend, correct . . . results of analysis. Resulting documents are basis of most other activities! Formal methods: check consistency, realis- ability.

• Design, Specification of Modules – Most

software systems are not monolithic but consist modules or components which in- teract to realise the overall functionality. Overall structure is called software archi- tecture (→ later). Design architecture, specify component interfaces as precise as possible to enable concurrent development and seamless integration. Formal methods: verify that design meets requirements.

• Coding and Module Test – The needed modules

are implemented using the chosen programming language(s). When ready, tested as needed, and ready for integration. Formal methods: verify that code implements design.

• Integration, Test, Approval – System is con-

structed from completed components, interplay is tested. Customer checks system and declares approval (or not).

What to (Plan and) Manage (1/3)? Tasks and Activities

– 02 – 2015-04-27 – Smgmt –

13/44

Work that commonly needs to be done in order to develop or adapt software:

• Analysis – Software is developed to solve a

problem/satisfy a need. Goal of analysis: understand the problem, assess whether/in how far software can be used to solve it.

• Specification
• f

Requirements – sort

• ut,

document, assess, extend, correct . . . results of analysis. Resulting documents are basis of most other activities! Formal methods: check consistency, realis- ability.

• Design, Specification of Modules – Most

software systems are not monolithic but consist modules or components which in- teract to realise the overall functionality. Overall structure is called software archi- tecture (→ later). Design architecture, specify component interfaces as precise as possible to enable concurrent development and seamless integration. Formal methods: verify that design meets requirements.

• Coding and Module Test – The needed modules

are implemented using the chosen programming language(s). When ready, tested as needed, and ready for integration. Formal methods: verify that code implements design.

• Integration, Test, Approval – System is con-

structed from completed components, interplay is tested. Customer checks system and declares approval (or not).

• Deployment, Operation, and Maintenance –

System is installed up to customer needs and be- comes operational. Occurring errors are fixed. New requirements (changes, extensions): new project (so-called maintenance project).

What to (Plan and) Manage (1/3)? Tasks and Activities

– 02 – 2015-04-27 – Smgmt –

13/44

Work that commonly needs to be done in order to develop or adapt software:

• Analysis – Software is developed to solve a

problem/satisfy a need. Goal of analysis: understand the problem, assess whether/in how far software can be used to solve it.

• Specification
• f

Requirements – sort

• ut,

document, assess, extend, correct . . . results of analysis. Resulting documents are basis of most other activities! Formal methods: check consistency, realis- ability.

• Design, Specification of Modules – Most

software systems are not monolithic but consist modules or components which in- teract to realise the overall functionality. Overall structure is called software archi- tecture (→ later). Design architecture, specify component interfaces as precise as possible to enable concurrent development and seamless integration. Formal methods: verify that design meets requirements.

• Coding and Module Test – The needed modules

are implemented using the chosen programming language(s). When ready, tested as needed, and ready for integration. Formal methods: verify that code implements design.

• Integration, Test, Approval – System is con-

structed from completed components, interplay is tested. Customer checks system and declares approval (or not).

• Deployment, Operation, and Maintenance –

System is installed up to customer needs and be- comes operational. Occurring errors are fixed. New requirements (changes, extensions): new project (so-called maintenance project).

• Dismissing and Replacement – Most software

systems (sooner or later) become obsolete, and are often replaced by a successor system. Com- mon reasons: existing system no longer main- tainable, not adaptable to new or changed re- quirements.

What to (Plan and) Manage (2/3)? People and (other) Resources

– 02 – 2015-04-27 – Smgmt –

14/44

(Plan and) Manage (2/3) — People and (other) Resources

– 02 – 2015-04-27 – Smgmt –

15/44

Customer Developer

Recall: roles “Customer” and “Developer” are assumed by legal persons, which often repre- sent many people. The same legal person may act as “Customer” and “Developer” in the same project.

(Plan and) Manage (2/3) — People and (other) Resources

– 02 – 2015-04-27 – Smgmt –

15/44

Customer Developer

Recall: roles “Customer” and “Developer” are assumed by legal persons, which often repre- sent many people. The same legal person may act as “Customer” and “Developer” in the same project.

· · · · · ·

Clients Software people Useful and common roles in software projects:

• customer, user
• project manager
• (sytems) analyst
• software architect, designer
• (lead) developer

programmer, tester, . . .

• maintenance engineer
• systems administrator
• invisible clients: legislator,

norm/standard supervisory committee

Excursion: The Concept of Roles

– 02 – 2015-04-27 – Smgmt –

16/44

In a software project, at each point in time:

• there is a set P of people, e.g. P =
• ,

, , ,

• there is a set R of (active) roles, e.g. R =
• mgr , prg , tst , ana
• there is a (many-to-many) relation between elements of P and R

assumes ⊆ P × R each person has a role (↓1 assumes = P), each role a person (↓2 assumes = R).

Excursion: The Concept of Roles

– 02 – 2015-04-27 – Smgmt –

16/44

In a software project, at each point in time:

• there is a set P of people, e.g. P =
• ,

, , ,

• there is a set R of (active) roles, e.g. R =
• mgr , prg , tst , ana
• there is a (many-to-many) relation between elements of P and R

assumes ⊆ P × R each person has a role (↓1 assumes = P), each role a person (↓2 assumes = R).

• Example:

mgr

• ne person, one role

prg, prg, prg

multiple persons, one role

tst ana

• ne person, multiple roles

Excursion: The Concept of Roles

– 02 – 2015-04-27 – Smgmt –

16/44

In a software project, at each point in time:

• there is a set P of people, e.g. P =
• ,

, , ,

• there is a set R of (active) roles, e.g. R =
• mgr , prg , tst , ana
• there is a (many-to-many) relation between elements of P and R

assumes ⊆ P × R each person has a role (↓1 assumes = P), each role a person (↓2 assumes = R).

• Example:

mgr

• ne person, one role

prg, prg, prg

multiple persons, one role

tst ana

• ne person, multiple roles

assumes =

• ( , mgr ), ( , prg ), ( , prg ), ( , prg ), ( , tst ), ( , ana )

Excursion: The Concept of Roles

– 02 – 2015-04-27 – Smgmt –

16/44

In a software project, at each point in time:

• there is a set P of people, e.g. P =
• ,

, , ,

• there is a set R of (active) roles, e.g. R =
• mgr , prg , tst , ana
• there is a (many-to-many) relation between elements of P and R

assumes ⊆ P × R each person has a role (↓1 assumes = P), each role a person (↓2 assumes = R).

• Example:

mgr

• ne person, one role

prg, prg, prg

multiple persons, one role

tst ana

• ne person, multiple roles

assumes =

• ( , mgr ), ( , prg ), ( , prg ), ( , prg ), ( , tst ), ( , ana )
• Possible visualisation:

P R assumes

1..∗ 1..∗

Excursion: The Concept of Roles Cont’d

– 02 – 2015-04-27 – Smgmt –

17/44

mgr

• ne person, one role

prg, prg, prg

multiple persons, one role

tst ana

• ne person, multiple roles

Roles typically come with responsibilities and rights. For example,

• tst : a test engineer
• is responsible for quality control
• has the right to raise issue reports
• mgr : a project manager
• has the right to raise issue reports
• is responsible for closing issue reports
• prg : a programmer
• is responsible for reporting unforeseen problems to the project manager
• is responsible for respecting coding conventions
• is responsible for addressing issue reports

(Plan and) Manage (2/3) — People and (other) Resources

– 02 – 2015-04-27 – Smgmt –

18/44

Some truisms and commonplaces to keep in mind:

• “Software engineering [...] takes place in the heads of humans, who like to get software or

develop it. Humans are central [in Software Engineering]; for us, that’s not an empty phrase (‘Floskel’), but a factual statement.” (Ludewig and Lichter, 2013)

• Being discontent with the team situation, doesn’t make people better developers.

(Other way round, in most cases.)

• Recognising and resolving tensions in your team (or at least trying to) is an activity

towards project success, thus a responsibility of each and every team member. “Everybody is responsible, the project manager is a little bit more responsible.”

• “If somebody stronly insists on a claim which feels obviously wrong to you, he/she may

be true given her/his respective (implicit) terms and assumptions.” (source?) Try to understand and explicate these terms and assumptions.

• “Never attribute to malice that which can be adequately explained by stupidity.”

(Hanlon’s Razor)

What to (Plan and) Manage (3/3)? Deadlines and Costs

– 02 – 2015-04-27 – Smgmt –

19/44

What to (Plan and) Manage (3/3)? — Deadlines and Costs

– 02 – 2015-04-27 – Smgmt –

20/44

Software!

Customer Developer

announcement

(Lastenheft)

→

§

. . . e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Developer Customer

milestone N

→

Developer Customer

software delivery

→

Repair!

Customer Developer

maintenance

A phase is a continuous, i.e. not interrupted range of time in which certain works are carried out and completed. At the end of the phase, there is a milestone. A phase is successfully completed if the criteria defined by the milestone are satis- fied.

Ludewig & Lichter (2013)

What to (Plan and) Manage (3/3)? — Deadlines and Costs

– 02 – 2015-04-27 – Smgmt –

20/44

Software!

Customer Developer

announcement

(Lastenheft)

→

§

. . . e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Developer Customer

milestone N

→

Developer Customer

software delivery

→

Repair!

Customer Developer

maintenance

A phase is a continuous, i.e. not interrupted range of time in which certain works are carried out and completed. At the end of the phase, there is a milestone. A phase is successfully completed if the criteria defined by the milestone are satis- fied.

Ludewig & Lichter (2013)

• Phases (in this sense) do not overlap! There may be different “threads of development”

running in parallel, structured by different milestones.

What to (Plan and) Manage (3/3)? — Deadlines and Costs

– 02 – 2015-04-27 – Smgmt –

20/44

Software!

Customer Developer

announcement

(Lastenheft)

→

§

. . . e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Developer Customer

milestone N

→

Developer Customer

software delivery

→

Repair!

Customer Developer

maintenance

A phase is a continuous, i.e. not interrupted range of time in which certain works are carried out and completed. At the end of the phase, there is a milestone. A phase is successfully completed if the criteria defined by the milestone are satis- fied.

Ludewig & Lichter (2013)

• Phases (in this sense) do not overlap! There may be different “threads of development”

running in parallel, structured by different milestones.

• Splitting a project into phases makes controlling easier; milestones may involve the

customer (accept intermediate results) and trigger payments.

• The granularity of the phase structuring is critical:
• very short phases may not be tolerated by a customer,
• very long phases may mask significant delays longer than necessary.

If necessary: define internal (customer not involved) and external (customer involved) milestones.

Deadlines Cont’d

– 02 – 2015-04-27 – Smgmt –

21/44

• Whether a milestone is reached must be assessable by
• clear,
• objective, and
• unambiguous

criteria.

• The definition of a milestone often comprises:
• a definition of the results which need to be achieved,
• the required quality properties of these results,
• the desired time for reaching the milestone, and
• the instance (person or committee) which decides whether the milestone is reached.
• Milestones can be part of the development contract;

not reaching a defined milestone as planned can lead to legal claims.

Costs

– 02 – 2015-04-27 – Smgmt –

22/44 “Next to ‘Software’, ‘Costs’ is one of the terms occurring most often in this book.”

Ludewig and Lichter (2013)

Costs

– 02 – 2015-04-27 – Smgmt –

22/44 “Next to ‘Software’, ‘Costs’ is one of the terms occurring most often in this book.”

Ludewig and Lichter (2013)

A first approximation:

• cost (‘Kosten’) — all disadvantages of a solution, quantifiable in terms of money or not.
• benefit (‘Nutzen’) (or: negative costs) — all benefits of a solution.

Note: costs and benefits can be very subjective — and are not necessarily quantifiable...

Costs

– 02 – 2015-04-27 – Smgmt –

22/44 “Next to ‘Software’, ‘Costs’ is one of the terms occurring most often in this book.”

Ludewig and Lichter (2013)

A first approximation:

• cost (‘Kosten’) — all disadvantages of a solution, quantifiable in terms of money or not.
• benefit (‘Nutzen’) (or: negative costs) — all benefits of a solution.

Note: costs and benefits can be very subjective — and are not necessarily quantifiable... Super-ordinate goal of many projects:

• Minimize overall costs, i.e. maximise difference between benefits and costs.

(Equivalent: minimize sum of positive and negative costs.)

Costs vs. Benefits: A Closer Look

– 02 – 2015-04-27 – Smgmt –

23/44

The benefit of a software is determined by the advantages achievable using the software; it is influenced by:

• the degree of coincidence between product and requirements,
• additional services, comfort, flexibility etc.

Costs vs. Benefits: A Closer Look

– 02 – 2015-04-27 – Smgmt –

23/44

The benefit of a software is determined by the advantages achievable using the software; it is influenced by:

• the degree of coincidence between product and requirements,
• additional services, comfort, flexibility etc.

Some examples of cost/benefit pairs: Jones (1990)

Costs Benefits

Labor during development Use of existing labor Labor during

• peration

Reduced operational labor New equipment? (purchase, maintenance, depreciation) Replacement of equipment maintenance? (sale, maintenance) New software purchases (Other) use of new software

Costs Benefits

Conversion from

• ld system to new

Improvement of system Increased data gathering Increased control Employee discontent Employee satisfaction Training for employees Increased productivity Lost opportunities Better market stance, basis for further growth

Costs: Economics in a Nutshell

– 02 – 2015-04-27 – Smgmt –

24/44

Distinguish current cost (‘laufende Kosten’), e.g.

• wages
• management, marketing
• rooms
• computers, networks, software as part of infrastructure
• . . .

and project-related cost (‘projektbezogene Kosten’), e.g.

• additional temporary personnel
• contract costs
• expenses
• hardware and software as part of product or system
• . . .

Software Costs in a Narrower Sense

– 02 – 2015-04-27 – Smgmt –

25/44 software costs net production quality costs error prevention costs analyse-and-fix costs error costs error localisation costs error removal costs error caused costs (in operation) decreased benefit maintenance (without quality)

quality assurance during and after development Ludewig and Lichter (2013)

Discovering Errors Late Can Be Expensive

– 02 – 2015-04-27 – Smgmt –

26/44

2 5 10 20 50 100 200 relative cost of an error Analysis Design Coding Test & Integration Acceptance & Operation phase of error detection larger projects smaller projects

Relative error costs over latency according to investigations at IBM, etc. by (Boehm, 1979). Visualisation: Ludewig and Lichter (2013)

Software Project Management Bottom-Line

– 02 – 2015-04-27 – Smgmt –

27/44

“Management, management... Can’t we just sit down and write some software?”

Software Project Management Bottom-Line

– 02 – 2015-04-27 – Smgmt –

27/44

“Management, management... Can’t we just sit down and write some software?”

• Quantity as Quality (Ludewig and Lichter, 2013) — the large is in general not

just a multiple of the small; solutions for small problems don’t scale in general.

Software Project Management Bottom-Line

– 02 – 2015-04-27 – Smgmt –

27/44

“Management, management... Can’t we just sit down and write some software?”

• Quantity as Quality (Ludewig and Lichter, 2013) — the large is in general not

just a multiple of the small; solutions for small problems don’t scale in general. Example: reliability. Consider a software system with N modules, each module being correct with probability p. N modules are correct with probability pN. Example N = 100: p 0.9 0.95 0.99 0.999 p100 0.0000267 0.006 0.37 0.90

Software Project Management Bottom-Line

– 02 – 2015-04-27 – Smgmt –

27/44

“Management, management... Can’t we just sit down and write some software?”

• Quantity as Quality (Ludewig and Lichter, 2013) — the large is in general not

just a multiple of the small; solutions for small problems don’t scale in general. Example: reliability. Consider a software system with N modules, each module being correct with probability p. N modules are correct with probability pN. Example N = 100: p 0.9 0.95 0.99 0.999 p100 0.0000267 0.006 0.37 0.90

• Software Engineering as defensive discipline

Software Project Management Bottom-Line

– 02 – 2015-04-27 – Smgmt –

27/44

“Management, management... Can’t we just sit down and write some software?”

• Quantity as Quality (Ludewig and Lichter, 2013) — the large is in general not

just a multiple of the small; solutions for small problems don’t scale in general. Example: reliability. Consider a software system with N modules, each module being correct with probability p. N modules are correct with probability pN. Example N = 100: p 0.9 0.95 0.99 0.999 p100 0.0000267 0.006 0.37 0.90

• Software Engineering as defensive discipline

Analogy: hygiene in hospital. “Dear patient, we’re working hard to protect you from an infection.” — “Well, doctor, I thought you were working to get me well again.”

Software Project Management Bottom-Line

– 02 – 2015-04-27 – Smgmt –

27/44

“Management, management... Can’t we just sit down and write some software?”

• Quantity as Quality (Ludewig and Lichter, 2013) — the large is in general not

just a multiple of the small; solutions for small problems don’t scale in general. Example: reliability. Consider a software system with N modules, each module being correct with probability p. N modules are correct with probability pN. Example N = 100: p 0.9 0.95 0.99 0.999 p100 0.0000267 0.006 0.37 0.90

• Software Engineering as defensive discipline

Analogy: hygiene in hospital. “Dear patient, we’re working hard to protect you from an infection.” — “Well, doctor, I thought you were working to get me well again.” “Software Engineering is boring and frustrating for people who don’t value the defense of failures as a positive achievement.” (Ludewig and Lichter, 2013)

Project Planning and Cost Estimation

– 02 – 2015-04-27 – main –

28/44

From ‘Lastenheft’ to ‘Pflichtenheft’

– 02 – 2015-04-27 – Splan –

29/44

Software!

Customer Developer

announcement

(Lastenheft)

→

§

. . . e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Developer Customer

milestone N

→

Developer Customer

software delivery

→

Repair!

Customer Developer

maintenance

software life cycle — The period of time that begins when a software product is conceived and ends when the software is no longer available for use.

The software life cycle typically includes a concept phase, [...]. IEEE 610.12 (1990)

From ‘Lastenheft’ to ‘Pflichtenheft’

– 02 – 2015-04-27 – Splan –

29/44

Software!

Customer Developer

announcement

(Lastenheft)

→

§

. . . e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Developer Customer

milestone N

→

Developer Customer

software delivery

→

Repair!

Customer Developer

maintenance

software life cycle — The period of time that begins when a software product is conceived and ends when the software is no longer available for use.

The software life cycle typically includes a concept phase, [...]. IEEE 610.12 (1990)

Lastenheft (Requirements Specification) Vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auf- tragnehmers innerhalb eines Auftrages.

(Entire demands on deliverables and services of a developer within a contracted development, created by the customer.) DIN 69901-5 (2009)

Pflichtenheft (Feature Specification) Vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts.

(Specification of how to realise a given requirements specification, created by the developer.) DIN 69901-5 (2009)

• One way of getting there: a pre-project.

The “Estimation Funnel”

– 02 – 2015-04-27 – Splan –

30/44

4× 2× 1× 0.5× 0.25× effort estimated to real effort (log. scale) Pre-Project Analysis Design Coding & Test t

Uncertainty with estimations (following (Boehm et al., 2000), p. 10). Visualisation: Ludewig and Lichter (2013)

Expert’s Estimation

– 02 – 2015-04-27 – Splan –

31/44

One approach: the Delphi method.

• Step 1:

write down your estimates!

Expert’s Estimation

– 02 – 2015-04-27 – Splan –

31/44

One approach: the Delphi method.

• Step 1:

write down your estimates!

• Step 2:

show your estimates and explain! 9.5 13 11 3 27

Expert’s Estimation

– 02 – 2015-04-27 – Splan –

31/44

One approach: the Delphi method.

• Step 1:

write down your estimates!

• Step 2:

show your estimates and explain! 9.5 13 11 3 27

• Step 3:

estimate again!

• Then take the median, for example.

Algorithmic Estimation: COCOMO

– 02 – 2015-04-27 – Splan –

32/44

• Constructive Cost Model:

Formulae which fit a huge set of archived project data (from the late 70’s).

• Flavours:
• COCOMO 81 (Boehm, 1981): basic, intermediate, detailed
• COCOMO II (Boehm et al., 2000)
• All based on estimated program size S measured in DSI or kDSI (thousands of

Delivered Source Instructions).

• Factors like security requirements or experience of the project team are mapped to

values for parameters of the formulae.

• COCOMO examples:
• textbooks like Ludewig and Lichter (2013) (most probably made up)
• an exceptionally large example:

COCOMO 81 for the Linux kernel (Wheeler, 2006) (and follow-ups)

COCOMO 81

– 02 – 2015-04-27 – Splan –

33/44

Software Project Type Characteristics of the Type a b c d Size Innovation Deadlines/ Constraints Dev. Environment Organic Small (<50 KLOC) Little Not tight Stable 2.4 1.05 2.5 0.38 Semi-detached Medium (<300 KLOC) Medium Medium Medium 3.0 1.12 2.5 0.35 Embedded Large Greater Tight Complex HW/ Interfaces 3.6 1.20 2.5 0.32

Basic COCOMO: E (effort required) = a(S/kDSI )b [person-months] TDEV (time to develop) = cEd [months] Intermediate COCOMO: E (effort required) = Ma(S/kDSI )b [person-months]

. . . where

– 02 – 2015-04-27 – Splan –

34/44

M = RELY · CPLX · TIME · ACAP · PCAP · LEXP · TOOL · SCED

factor very low low normal high very high extra high

RELY required software reliability 0.75 0.88 1 1.15 1.40 CPLX product complexity 0.70 0.85 1 1.15 1.30 1.65 TIME execution time constraint 1 1.11 1.30 1.66 ACAP analyst capability 1.46 1.19 1 0.86 0.71 PCAP programmer capability 1.42 1.17 1 0.86 0.7 LEXP programming language experience 1.14 1.07 1 0.95 TOOL use of software tools 1.24 1.10 1 0.91 0.83 SCED required development schedule 1.23 1.08 1 1.04 1.10

COCOMO II

– 02 – 2015-04-27 – Splan –

35/44

Consists of

• Application Composition Model — configuration dominates programming
• Early Design Model — adaption of Function Point approach (in a minute)
• Post-Architecture Model — like COCOMO 81, needs architecture defined

E = 2.94 ·

• S

kSLOC X · M where X = PREC + FLEX + RESL + TEAM + PMAT. So-called scaling factors:

• Precedentness (PREC) — experience with similar projects
• Development flexibility (FLEX) — development process fixed by customer
• Architecture/risk resolution (RESL) — risk management, architecture size
• Team cohesion (TEAM) — communication effort in team
• Process maturity (PMAT) — see CMM

COCOMO II Cont’d

– 02 – 2015-04-27 – Splan –

36/44

M now depends on:

group factor description

Product factors RELY required software reliability DATA size of database CPLX complexity of system RUSE degree of development of reusable components DOCU amount of required documentation Platform factors TIME execution time constraint STOR memory consumption constraint PVOL stability of development environment Team factors ACAP analyst capability PCAP programmer capability PCON continuity of involved personnel APEX experience with application domain PLEX experience with development environment LTEX experience with programming language(s) and tools Project factors TOOL use of software tools SITE degree of distributedness SCED required development schedule

Algorithmic Estimation: Function Points

– 02 – 2015-04-27 – Splan –

37/44 Complexity Sum Type low medium high input ·3 = ·4 = ·6 =

• utput

·4 = ·5 = ·7 = query ·3 = ·4 = ·6 = user data ·7 = ·10 = ·15 = reference data ·5 = ·7 = ·10 = Unadjusted function points UFP Value adjustment factor VAF Adjusted function points AFP = UFP · VAF VAF = 0.65 + 14

i=1 GSC i

100 ,

0 ≤ GSC i ≤ 5,

Algorithmic Estimation: Function Points

– 02 – 2015-04-27 – Splan –

37/44 Complexity Sum Type low medium high input ·3 = ·4 = ·6 =

• utput

·4 = ·5 = ·7 = query ·3 = ·4 = ·6 = user data ·7 = ·10 = ·15 = reference data ·5 = ·7 = ·10 = Unadjusted function points UFP Value adjustment factor VAF Adjusted function points AFP = UFP · VAF

IBM and VW curve for the conversion from AFPs to PM according to (Noth and Kretzschmar, 1984) and (Kn¨

• ll and Busse, 1991).

VAF = 0.65 + 14

i=1 GSC i

100 ,

0 ≤ GSC i ≤ 5,

COCOMO vs. Function Points

– 02 – 2015-04-27 – Splan –

38/44

(Ludewig and Lichter, 2013) says:

• function point approach used in practice, in particular commercial software

(business software?)

• COCOMO tends to overestimate in this domain; needs to be adjusted by

corresponding factors

In The End. . .

– 02 – 2015-04-27 – Splan –

39/44

. . . it’s experience, experience, experience.

“estimate, document, estimate better” (Ludewig and Lichter, 2013)

In The End. . .

– 02 – 2015-04-27 – Splan –

39/44

. . . it’s experience, experience, experience.

“estimate, document, estimate better” (Ludewig and Lichter, 2013) Suggestion: start to explicate your experience now.

• Take notes on your projects (Softwarepraktikum, Bachelor Projekt, Master

Bacherlor’s Thesis, Team Projekt, Master’s Thesis, . . . )

• timestamps
• size of program created
• number of errors found
• number of pages written
• . . . (more measures/metrics: later)
• Try to identify factors: what hindered productivity, what boosted productivity, . . .
• Which detours and mistakes were avoidable in hindsight? How?

Okay, estimation is done, and now. . . ?

– 02 – 2015-04-27 – Splan –

40/44

The Start Phase

– 02 – 2015-04-27 – Splan –

41/44

Software!

Customer Developer

announcement

(Lastenheft)

→

§

. . . e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Developer Customer

milestone N

→

Developer Customer

software delivery

→

Repair!

Customer Developer

maintenance

• The phase between customer’s decision to have software developed and start of

project is called start phase. Start of project: project plan is installed.

The Start Phase

– 02 – 2015-04-27 – Splan –

41/44

Software!

Customer Developer

announcement

(Lastenheft)

→

§

. . . e

Customer Developer

software contract

(incl. Pflichtenheft)

→

Developer Customer

milestone N

→

Developer Customer

software delivery

→

Repair!

Customer Developer

maintenance

• The phase between customer’s decision to have software developed and start of

project is called start phase. Start of project: project plan is installed.

• Planning activities;
• Clarify extension of deliverables and scope of work.
• Identify risks.
• Create budget and time plans.
• Define and structure tasks.
• Define who reports what to whom, inside team and towards customer.
• Estimate needed personnel (number and qualifications).
• Assign tasks to roles, and roles to personnel.
• Provide necessary support (e.g. infrastructure).

Some Final Wisdom...

– 02 – 2015-04-27 – Splan –

42/44 Most software projects are successful (cf. SUCCESS survey (Buscherm¨

• hle et al., 2006));

if they fail, they tend to fail due to:

• insufficient education (in particular project management)
• unrealistic expectations of higher management
• implicit customer expectations
• behaviour of team members
• own expectations

(Ludewig and Lichter, 2013)

Rules of behaviour for successful project management: (i) Think people first, the business is second. All a business is, is its people. Take care of them. (ii) Establish a clear definition of your project’s development cycle and stick to it. (iii) Emphasize the front-end of the project so that the rear-end won’t be dragging. (iv) Establish baselines early and protect them from uncontrolled change. (v) State clearly the responsibilities of each person on the project. (vi) Define a system of documents clearly and early. (vii) Never give an estimate or an answer you don’t believe in. (viii) Never forget Rule (i). (Metzger, 1981)

References

– 02 – 2015-04-27 – main –

43/44

References

– 02 – 2015-04-27 – main –

44/44 Boehm, B. W. (1979). Guidelines for verifying and validating software requirements and design

• specifications. In EURO IFIP 79, pages 711–719. Elsevier North-Holland.

Boehm, B. W. (1981). Software Engineering Economics. Prentice-Hall. Boehm, B. W., Horowitz, E., Madachy, R., Reifer, D., Clark, B. K., Steece, B., Brown, A. W., Chulani, S., and Abts, C. (2000). Software Cost Estimation with COCOMO II. Prentice-Hall. Buscherm¨

• hle, R., Eekhoff, H., and Josko, B. (2006). success – Erfolgs- und Misserfolgsfaktoren

bei der Durchf¨ uhrung von Hard- und Softwareentwicklungsprojekten in Deutschland. Technical Report VSEK/55/D. DIN (2009). Projektmanagement; Projektmanagementsysteme. DIN 69901-5. IEEE (1990). IEEE Standard Glossary of Software Engineering Terminology. Std 610.12-1990. Jones, G. W. (1990). Software Engineering. John Wiley & Sons. Kn¨

• ll, H.-D. and Busse, J. (1991). Aufwandssch¨

atzung von Software-Projekten in der Praxis: Methoden, Werkzeugeinsatz, Fallbeispiele. Number 8 in Reihe Angewandte Informatik. BI Wissenschaftsverlag. Ludewig, J. and Lichter, H. (2013). Software Engineering. dpunkt.verlag, 3. edition. Metzger, P. W. (1981). Managing a Programming Project. Prentice-Hall, 2 edition. Noth, T. and Kretzschmar, M. (1984). Aufwandssch¨ atzung von DV-Projekten, Darstellung und Praxisvergleich der wichtigsten Verfahren. Springer-Verlag. Thayer, R. H. (1997). Tutorial – Software Engineering Project Management. IEEE Society Press, revised edition.