UNIT 5 B

Managing software development

Unit 5
TCC 125/05

Software Development
Models

Managing Software
Development

C WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

COURSE TEAM
Course Team Coordinator: Ms. Azrina P. Jamal Mydin
Content Writer: Ms. Siti Sarah bt. Md. Rahim
Instructional Designer: Mr. Khoo Chiew Keen
Academic Member: Mr. Chandarasegaran Natarajan

COURSE COORDINATOR
Ms. Azrina P. Jamal Mydin

EXTERNAL COURSE ASSESSOR

Associate Professor Masrah Azrifah, Universiti Putra Malaysia

PRODUCTION
In-house Editor: Mr. Khoo Chiew Keen
Graphic Designer: Ms. Valerie Ooi

Wawasan Open University is Malaysias first private not-for-profit tertiary institution dedicated to
adult learners. It is funded by the Wawasan Education Foundation, a tax-exempt entity established
by the Malaysian Peoples Movement Party (Gerakan) and supported by the Yeap Chor Ee Charitable
and Endowment Trusts, other charities, corporations, members of the public and occasional grants
from the Government of Malaysia.
The course material development of the university is funded by Yeap Chor Ee Charitable and
Endowment Trusts.

2012 Wawasan Open University

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or
transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or
otherwise, without prior written permission from WOU.

Wawasan Open University

(KPT/JPT/DFT/US/P01)
Wholly owned by Wawasan Open University Sdn. Bhd. (700364-W)

54, Jalan Sultan Ahmad Shah, 10050 Penang.

Tel: (604) 2180333 Fax: (604) 2279214
Email: enquiry@wou.edu.my
Website: www.wou.edu.my

UNIT 5 D
Managing software development

Contents
Unit 5 Managing Software
Development
Unit overview

Unit objectives

5.1 Planning and scheduling

Objectives

Introduction

Introduction to software development planning and

scheduling
Project planning
Project scheduling

Plan-driven development
Project plans
The planning process

6
6
7

Software development scheduling

Schedule representation

8
9

Agile planning

12

Suggested answers to activity

18

5.2 Project management

3
5

19

Objectives

19

Introduction

19

Overview of project management

19

Managing people

22

Teamwork
Selecting group members
Team organisation
Team communications
Team motivation

24
25
26
27
28

E WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

Suggested answers to activity

5.3 Project estimation

31

33

Objectives

33

Introduction

33

Introduction to project estimation

33

Algorithmic cost modelling

34

The COCOMO II model

The application composition model
The early design model
The reuse model

36
37
40
46

Project duration and staffing

49

Suggested answers to activities

52

5.4 Professional and ethical responsibility

55

Objectives

55

Introduction

55

Understanding professional and ethical responsibilities

55

Issues of professional responsibilities

56

Code of ethics

58

Summary of Unit 5

63

Course summary

65

Suggested answers to self-tests

67

References

69

Glossary

71

UNIT 5 1
Managing software development

Unit Overview

eveloping a software needs thorough management. There are possibilities that

a good product comes from good management. Good planning and scheduling
is one of the factors that can produce better management. Teamwork from all of
the software development team members also plays an important role. There must
be a particular arrangement for project estimation using a suitable cost estimation
model. For managing software development, codes of ethics need to be applied to
assist the team members to understand the difference between right and wrong
when making decisions.
Unit 5 is divided into four sections. The first section discusses planning and
scheduling the developments. It utilises a stepwise procedure to allocate good timing
and to avoid risk.
The second section discusses project management. A project is envisioned with
a defined beginning and end, undertaken to meet unique goals and objectives.
Managing people and teamwork are aspects to be considered as well.
The third section focuses on project estimation where you will be introduced to two
types of cost estimation model. These models help reduce the problem of cost and
effort estimation by dividing it into smaller and manageable problems.
The last section concerns the professional and ethical responsibility. Professional
ethics are regulated by standards, which are often referred to as codes of ethics. You
will learn the use of code of ethics in managing software development team.

Unit Objectives
By the end of Unit 5, you should be able to:
1. Describe the concept of planning and scheduling in software development.
2. Describe the various aspects of managing people in software development
team.
3. Discuss project estimation in software development.
4. Explain the professional and ethical responsibility in managing software
development.

2 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

UNIT 5 3
Managing software development

5.1 Planning and Scheduling

Objectives
By the end of this section, you should be able to:
1. Describe the three stages of project planning.
2. Identify the basic principles in project scheduling.
3. Discuss the project plan.
4. List the types of schedule representation and its activities.
5. Describe agile planning approaches.

Introduction
Most system development is organised in terms of project. One of the most important
tasks in software project is planning. In managing the project, the project leader is
responsible for organising the resources to achieve the goals within a given timeline.
The project activities need to be broken down into parts so that it can be managed
easily.
While planning, a project leader also needs to develop a project schedule because
there are several activities that require good scheduling. This section is divided into
four parts:
1. Introduction to software development planning and scheduling.
2. Plan-driven development.
3. Software development scheduling.
4. Agile planning.

Introduction to software development planning and scheduling

Project planning
Planning offers advantage to just about anything you do. Having a plan in developing
software helps you to manage the project in a more structured and predictable way.
You can gain a number of incremental improvements that add up to major progress
by planning every effort a little better.

4 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

While planning is considered important to virtually everything, it will not help you
to solve all your problems. In a software development team, the team leader needs
to break down the work into parts and assign it to team members. The team leader
also needs to predict matters that may arise and allocate alternative settlements to
those matters.
According to Sommerville (2011), there are three phases in developing project
planning: the proposals phase, project start-up phase and throughout the project
phase. Project planning is created at the beginning of the project. The function of
project planning is to interact within project team and also with customers on how
the task will be done. Let us have a look at the activities inside those three phases:
1. The proposal phase
The use of proposal is to educate the customer about the capabilities of the
team in satisfying their needs. Software development team use proposal to
record all the requirements and resources needed to develop the software. It
also helps to work out the price that the team should quote to a customer.

2. Project start-up phase

During this stage, you have to plan who will work on the project, where to
gain the resources, how the resources will be allocated across your company,
how the project will be broken down into parts and many more. In project
start-up stage, you can refine the initial effort estimates that you have
prepared since you have more information than at the proposal stage.

3. Throughout the project phase

When developing the project, you may collect a lot of information related
to the system being implemented by monitoring the project. So, the
development is likely to be modified according to information that you have
gained. You will also learn more about your team members in term of level
of capabilities. With the information that have you gained, you will make
more accurate estimates of how long the work will take.

When developing a proposal, the plan is important because it shows the customer
how you will carry out the work. It may not be a complete plan that contains all
requirements but once you get the contract, the plan will be revised to provide
better assessment. The cost can also be estimated from the plan. Cost estimates
allow project leaders to build cash flow requirement while time estimates help create
a project timeline.

UNIT 5 5
Managing software development

Project scheduling
Scheduling is a helpful tool for orchestrating a sequence of events, whether you are
managing a software development project or coordinating your study time. Most of
the schedules involve a start and an end date, the tasks required, the task duration
and the relationship between the tasks.
According to Sommerville (2010), project scheduling is the process of deciding how
the work in a project will be organised as separate tasks and when and how these
tasks will be executed. Using project scheduling, you estimate the calendar time
needed to complete each task. You also estimate the effort required and who will
work on the tasks that have been broken down into parts.
Project scheduling is needed in both plan-based and agile processes. But the level of
detail may be less in an agile project plan. This initial schedule is used to plan how
people will be allocated to the project and to check the progress of the project against
its contractual commitments. In agile processes, an iterative approach to scheduling
is used to plan each phase. According to Pressman (2006), there are a number of
basic principles that can guide you to have a good software project scheduling:
1. Compartmentalisation
This means that the project will be divided into a several activities and tasks
so that it can be easily handled.

2. Interdependency
Every activity and task that has been compartmentalised must have their
interdependency. Certain task must be made in sequence else it will be in
parallel. Some activities can be done independently while some cannot start
until the other tasks related to it are done.

3. Time allocation
Each task must be assigned the start date and the due date and whether the
task is conducted full time or part time.

4. Effort validation
Each task will be assigned to a certain number of staff. The project leader
needs to make sure how much effort is needed to complete one task. Usually,
more effort is required than there are people to do the work.

6 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

5. Defining responsibilities
Each task that has been scheduled must be assigned to staff that have
knowledge in that area.

6. Defining outcomes
Every task must have its defined outcome which is normally a work product
or a part of work product for software projects.

7. Defining milestones
A project milestone needs to be associated with every task or group of tasks.
A milestone is accomplished when the quality of one or more work products
has been reviewed and approved.

All of these principles apply when developing project scheduling.

Plan-driven development
Plan-driven development is a specific approach to develop a software where the plan
is made in detail. The project plan records the work to be done, who will do it, the
development of schedule and the work products. Plan-driven development can be
equated as the traditional way to manage a large software project. This is different
from agile development where changes and updates need to be made simultaneously
during iteration of development.
According to Sommerville (2010), in implementing plan-driven development, many
early decisions have to be revised. When revising the early decisions, you can detect
the potential problems and dependencies before the project starts. As a result, we
can avoid reworking the project since we can detect the problems earlier.

Project plans
Project plan refers to a formal documentation that is used to manage activities that
will be performed and the description of how the activities will be done. It is also a
document that is expected to be changed from time to time. Project planning is used
to define each major task, estimate the time and resources needed, and monitor the
tasks that have been identified. The plans normally include the following sections
as below:
1. Introduction an overview of your project and the goals that you need to
achieve at the end of the project.

UNIT 5 7
Managing software development

2. Project organisation determine which people will handle which

responsibilities in the software development team.
3. Risk analysis determine the possible risks that may occur and propose a
solution strategy for each of the risks.
4. Hardware and software requirements list down all hardware and software
requirements when developing the project. You may need to include the
price in cost estimation of hardware or software that you need to buy.
5. Work breakdown determine the tasks and break it down into small
manageable parts. Each of the tasks requires a milestone so that you know
down how to assess the time.
6. Project schedule it shows the dependencies between tasks, the estimated
time required to reach each milestone and the allocation of people to tasks.
7. Monitoring and reporting mechanism produce a report that states the
monitoring result for future review.

Once the project plan has been established and agreed by the stakeholders, the plan
becomes the baseline of your project. Software development team can measure the
progress of the project against the baseline throughout the life of the project.

The planning process

Often project planning is ignored in favour of getting on with the work. However,
many people fail to realise the value of a project plan in saving time, money and
avoiding many problems. When going through the project planning process, the
project leader will divided the responsibility of implementing each action item or
step necessary to complete the project. A project plan also keeps all team members
informed of the progress of the current set of action items.

8 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

[Unfinished]
Identify
Constraint
[Start]

Identify
Risks

<<System>>
Project
Planner
Define Project
Schedule

Identify
Milestones
and
Deliverables

Do the Work

Monitor
Progress
against Plan

[Project
finished]
[End]

[No
problems]

[Serious
problems]

[Minor problems and slippages]

Initiate Risk
Mitigation
Actions

Re-plan
Project

Figure 5.1 Project planning process

Figure 5.1 shows a typical workflow for a project planning process (Sommerville

2010). You must identify any limitation that can cause the failure of the project.
The risks and constraints that are being defined must be clearly stated as well as
the project milestones and deliverables. Deliverables are work products that will be
delivered to the customer such as the requirement document for the software. With
the project milestones you can estimate the delivery date. More accurate delivery
dates will be established during the scheduling phase.
After that, an estimated schedule for the project will be drawn. List the tasks that
need to be created and carried out for each deliverable. You need to identify the
amount of effort (hours or days) required to carry out the tasks. Once you have
established the amount of effort for each task, you can work out the accurate delivery
date depending on the effort required for each deliverable. You should review the
progress and note any discrepancies from the schedule.
The problems are always there during a project and these can lead to project delays.
Therefore, you need to initiate the risk mitigation actions. Risks can be tracked
using a simple risk log. You need to review the log regularly so that the risks would
not occur. If it happens, it might lead to significant delay. Therefore, you need to
re-plan the project and it may involve renegotiating the project limitations and
deliverables with the customer.

Software development scheduling

A project is a collection of activities that need to be completed with minimal time
and cost. Therefore, project scheduling is needed in developing projects. Using
project scheduling, you can determine the earliest start and finish of the activities. It
is organised as separate activities and when and how these activities will be executed.

UNIT 5 9
Managing software development

You can also allocate resources over the duration of the project. For example, the
time required specialised hardware, the disk space required on a server and what
the travel budget will be.
Whether you are using plan-driven development or agile development, you still
need to have an initial project scheduling to guide your progress. The details in agile
development will be less than in plan-driven development.

Software Requirement and Design

Identify
Tasks

Identify Tasks
Dependencies

Estimate
Resources
for Tasks

Allocate
team to
Task

Create
Project
Charts

Figure 5.2 Project scheduling process

According to Sommerville (2010), the activities should normally last at least a week
and no longer than 2 months. The maximum amount of time for any activities should
be around 8 to 10 weeks and if it is going to take longer than that, the activities will
be broken down into smaller parts.

Schedule representation
Schedule can be represented in several formats. A simple table can also represent
a project schedule that contains the tasks, effort, expected duration and task
dependencies. But it will be hard to understand. Therefore, there are other compatible
ways to develop a project schedule. Two types of representations that are commonly
used are:
1. Gantt chart
It is a type of bar chart which illustrates who is responsible for which activity,
the elapsed time, the date of beginning and end of the project. It is named
after the inventor, Henry Gantt. It is suitable for small projects.

2. Activity network chart

It represents interdependencies and associations and allows planning to
include these relationships. It is also called PERT (Program Evaluation
Review Technique) chart. It is suitable for large and complex projects.

10 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

There are several tools that can support the development of project schedules such
as Microsoft Project. You just need to input project information into a table and it
will generate the schedule automatically from the information given. The project
activities that you usually need to input are such as:
1. Duration in calendar days or months.
2. An effort estimate which reflects the number of person-days or personmonths to complete the work.
3. A deadline by which the activity should be completed.
4. Defined endpoint. It depicts the tangible result of completing the activity
and it could be in form of document, meeting slide shows or others.
Task

Effort (person-days)

Duration (days)

Dependencies

T1

15

10

T2

15

T3

20

15

T4

10

T5

10

T2, T4 (M3)

T6

10

T1, T2 (M4)

T7

25

20

T1 (M1)

T8

75

25

T4(M2)

T9

10

15

T3, T6 (M5)

T10

20

15

T7, T8 (M6)

T11

10

10

T9 (M7)

T12

20

10

T10, T11 (M8)

T1 (M1)

T = Tasks M = Milestone
Table 5.1 Task, duration and dependencies

Milestones are often represented as the deliverables while the effort to produce the
deliverable is referred to as task. Major project milestones are sometimes represented
as base success of a task. Therefore, it should be documented by a short report
that tells the work progress that has been made. For example, as seen in Table 5.1,
milestone M1 is associated with task T1 and milestone M3 is associated with tasks
T2 and T4.

UNIT 5 11
Managing software development

Table 5.2 Activity bar chart

The team leader of the software development team needs to allocate resources to the
tasks. A resource is any person, item, tool, or service that is needed by the project.
People may be working on more than one task at the same time. There are also times
their resources when not are used at all. They may be on holiday, working on other
projects, involved with some other activities or attending workshops.
Please be reminded that in a software development team, there may be part-time
workers. Therefore, you may not want to assign many tasks to this person. You also
need to be aware when assigning the part-timer to a group task. This is because it
can cause scheduling problems if this person cannot cope with it. If one project is
delayed, this may affect other projects.
This can affect later tasks that are dependent on earlier tasks which have been delayed.
Delays can cause serious problems with staff allocation especially when there are
people who are working on several tasks at the same time.

12 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

Activity 5.1
The table below shows the task durations for software project tasks.
Let us assume that a serious problem occurs during the project and
T9 is affected. Instead of taking 15 days, task T9 needs to take 25
days. Draw new activity bar charts showing how to reorganise the
task.
Task

Duration (days)

Dependencies

T1

10

T2

15

T3

15

T4

10

T5

10

T2, T4

T6

T1, T2

T7

20

T1

T8

25

T4

T9

15

T3, T6

T10

15

T7, T8

T11

10

T9

T12

10

T10

T1

Agile planning
Agile planning is very collaborative in nature where not just the project manager
but the whole team is responsible for planning. When implementing agile planning
in your project, you are using iterative approaches. During this iteration process, all
of the necessary work to turn an idea in to a working product is completed without
dependencies. The end result is that parts of the product are delivered on a regular,
frequent basis.
According to Sommerville (2010), these agile approaches have a two-stage approach
to planning, corresponding to the start-up phase in plan-driven development and
development planning:
1. Release planning it looks ahead by several months and decides on the
features that need to be included in a release of a system.
2. Iteration planning it has a shorter-term outlook and focuses on planning
the next increment of a system. This is typically 2 to 4 weeks of work for
the team.

UNIT 5 13
Managing software development

Let us take extreme programming planning for this discussion. Figure 5.3 shows
the stages in extreme programming planning.

Story
Identification

Initial
Estimation

Release
Planning

Interation
Planning

Task
Planning

Figure 5.3 Extreme programming planning

There are five stages required when applying agile plan:

Story identification
The user story is counted as the specification that reflects the features that should
be included in the system. Software development team and customer need to try to
identify a set of stories that covers all of the functionalities that are to be included
in the system. You may want to create a customer team with a product manager,
testers, real users, and interaction designers to create more fine-grained user stories.
You can use a template for writing user stories:
As a <role>, I want to <goal> to achieve <business value>.

As an administrator, I want to create

a new user so that I can add a new
employee to the system.

As an administrator, I want to
perform user management so that I
can maintain the user database.

As an administrator, I want to view a

user record so that I can ensure the
information it contains is valid.

As an administrator, I want to edit

a user record so that I can correct a
mistake.

As an administrator, I want to delete

a user record so that I can remove an
employee that quits.

Figure 5.4 Example of user stories

14 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

The user stories will be broken down into smaller pieces. User stories represent the
work the team must accomplish to meet the requirements of the product.

Initial estimation
The next stage is initial estimation whereby the software development team reads and
discusses the stories. The user stories will be assigned as product backlog as shown
in Figure 5.5. The product backlog is meant to be dynamic with items being added,
removed, and reprioritised. After that, the stories need to be ranked in order of the
amount of time the team think will to be needed implement the story. In this way,
it can allow the customer to select the pieces of a requirement that are more critical
to be implemented first.

Release backlog

Product
backlog

Release backlog

Release backlog

Iteration
backlog

Iteration
backlog

Iteration
backlog

Figure 5.5 Flow of product backlog, release backlog and iteration backlog

Once the ranking had been completed, the team then allocates the story points to
the stories. The higher the level of stories, the more story points gained. It will be
challenging to estimate story points because the team has no reference points. As
the team does more and more estimates, those estimates will improve in accuracy.
Once the stories have been estimated, the story point is translated into the first
estimate of the total effort required by using the notion of velocity. The details of
the estimation technique will be discussed in upcoming units.

Release planning
Release planning involves selecting and refining the stories. It will reflect the features
to be implemented in a release of a system. It also reflects the order in which the
stories should be implemented. The development team must now work closely with
the product owner to ensure that the work that was identified looks appropriate for
the size and duration of the release. A release date will be chosen and the stories will
be reviewed to see if the effort estimate is consistent with that date. The stories will
be added or removed from the list if it is not consistent. Once the iteration starts,
the customer can no longer change the work that was selected for the iteration.

UNIT 5 15
Managing software development

Iterative planning
At the start of the iteration, the customer can reprioritise the release backlog so that
the development team knows the items it needs to work on next. The customer and
development team should take a half-day on the first day of the iteration for the
iteration planning meeting. During this meeting, the team should select as many
high-priority items as it can contain from the release backlog and add these to the
iteration backlog. According to Sommerville (2010), stories to be implemented for
that iteration are chosen, with the number of stories reflecting the time to deliver an
iteration (usually 2 or 3 weeks) and the teams velocity. The iteration is consider led
complete when the iteration delivery date is reached even if there are some stories
that not implemented yet.

Task planning
There is a more detailed planning stage at the start of each iteration where the
developers break the stories down into development tasks. A development task
should take 4 to 16 hours. There are two important benefits from this approach to
task allocation:
1. The whole software development team gets a review of the tasks to be
completed in iteration. Therefore, they have a better understanding of what
other team members are doing.
2. For the individual developer, the person chooses the tasks to implement.
Therefore, the person has a sense of ownership in these tasks and this
motivates them to complete the tasks.

The advantages of this planning are the software is always released as planned and
there is no schedule slippage. The extreme programming philosophy is to reduce
the work rather than extend the schedule if the work cannot be completed. A major
difficulty in agile planning is that it requires customer involvement and availability.

16 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

Summary
Project planning breaks the project down into structured activities
that will be carried out by the software development team. Project
planning is created at the beginning of the project. The three stages
to complete it are the proposal stage, the project start-up phase and
throughout the project phase.
Project scheduling depicts the process of organising the work and
how the tasks will be executed on time. The time and effort required
to complete each tasks is estimated. Guidance on building the
project schedule has been specified including compartmentalisation,
interdependencies, time allocation, effort validation, defined
responsibilities, defining outcomes and defining the milestones.
Plan-driven development is organised around a complete
development plan that depicts the project tasks, the planned
effort, the activity schedule and who is responsible for each task.
A project plan sets the resources needed for the project, the tasks
involved and a specific schedule for carrying out the work. The
plan should consist of the introduction of the plan, the project
organisation, risk analysis, hardware and software requirements,
the work breakdown structure, project schedule and monitoring
and reporting mechanisms.
Agile planning is a plan that delivers projects without much detail
on how features will be delivered. It is based only on the priority
of user stories and how much functionality the team can deliver
within a given time. Agile planning works well with small and
stable software development teams that can get to discuss the stories
together for the implementation.
Achieving a successful development project planning depends on the
suitability of the project planning that you choose for your project.
Whether using plan-driven development or agile planning, you need
to understand what you really want to get out from the process.

UNIT 5 17
Managing software development

Self-test 5.1
1. Who is responsible for project planning and scheduling?
A. Project leader
B. Programmers
C. Project Design
D. Managers

2. In which planning stage may you refine the initial effort

estimates that you have prepared?
A. The proposal stage
B. Project start-up phase
C. Project scheduling
D. Throughout the project phase

3. The project must be divided into a number of manageable

activities and tasks. Which basic principle of project scheduling
does this statement refer to?
A. Interdependencies
B. Time allocation
C. Effort validation
D. Compartmentalisation

4. Everyone in the team will be assigned to their tasks and

responsibilities. The statement refers to
A. defining milestones
B. defining outcomes
C. defining responsibilities
D. defining tasks

5. A ________________means that it is a work product that is

delivered to the customer.
A. outcomes
B. schedule
C. activities
D. deliverables

18 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

6. Release planning involves selecting and refining the stories.

A. True
B. False

Suggested answers to activity

Feedback
Activity 5.1
Here is an example of the answer that you can use.

UNIT 5 19
Managing software development

5.2 Project Management

Objectives
By the end of this section, you should be able to:
1. List the goals of software projects.
2. Identify the four critical factors in people management.
3. Describe the factors of good team communication.

Introduction
Project management can be depicted as a system of procedures, technologies and
practices that produces the planning, organising, staffing, directing and controlling
necessary to make a successful software engineering project. Project management
will be conducted by the project leader of a software development team.
The project leader must know how to lead their team members. In project
management, there are many activities that need to be divided among the team
members so that they can achieve a good quality of software development. This
unit is divided into three parts:
1. Overview of project management
2. Managing people
3. Teamwork

Overview of project management

Software project management is important because it is always subject to
organisational budget and schedule constraint. A project needs to be managed
carefully. The team leader of software the development team needs to make sure
that the software project meets the customer requirement by overcoming various
challenges and limitations as well as delivering high quality software. A bad
management usually turns the project into a failure but you need to remember that
a good management cannot guarantee that you will have project success. It only
guarantees you a better chance of success. Project management only helps you to
have a strong pole on the project so that it can guide you on the right path. This is
because there is always complexities and uncertainties that cannot be controlled in
an unpredictable world even with risk management.

20 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

There are many related factors that make for successful for project management
and it may vary from one project to another project. For most project management
the important goals are:
1. Deliver the software to the customer in the time given.
2. The cost is within the budget.
3. Customer satisfaction.
4. Maintain the relationship among the software development team members.

These goals are not only for software engineering project, but also for other
engineering projects. The software management in software engineering is
challenging in its own ways. Sommerville (2010) stated that there are differences
between software management in software engineering and other engineering
projects. The differences are:
1. The software is intangible
A development team of an aircraft project can see the product being built. If
the schedule on slips, then the effect the product is visible. You may see the
unfinished structure of the aircraft. This is totally different from developing
software. Software is intangible. It cannot be seen or touched. The software
development team cannot see the progress of the development by simply
looking at the product. It needs to rely on others to produce that data they
can use to review the work.

2. Large software development is often one-shot project

Large software usually has different development from one to another. Rapid
technological changes in computers and communications can make a team
leaders experience fall into disuse. Lessons learnt from previous projects
may not be entirely applicable to new projects.

3. Software processes are variable

Software management is different from one organisation to another. Even
though the design of the software sometimes can be the same such as
building a student registration system for a college, the component inside the
system may vary. It depends on the needs of the customers or organisations.
Although there has been significant progress in process standardisation and
improvement, we still cannot reliably predict when a particular software
process is likely to lead to development problems.

UNIT 5 21
Managing software development

It is undeniable that some software projects may encounter budget issues that cause
the software projects to fall behind schedule. It is hard to determine the exact job
description of the software development team. The job may vary depending on the
organisation and types of software that is being developed. Most project managers
take responsibility in the following activities:
1. Proposal writing
Proposal writing is needed because it carries the item of work to win the
contract. It must have the objectives of the project and how it will be carried
out. It also includes the cost and estimated schedule, with justification for
why the project proposal is better than other proposals from competitors.
Proposal writing is a skill that the project manager acquires and you can
also achieve it through practice and experience.

2. Project planning
The project managers or team leaders are responsible for planning, estimating
and scheduling project development and assigning task to people. The project
manager needs to supervise the work to ensure that it is up to standard. The
project manager also needs to monitor the progress so that it can be finished
on time and within the budget given.

3. Reporting
It is necessary to report the progress of a development to customers of the
company. Therefore, the project manager will communicate with them
on matters ranging from detailed technical information to management
summaries. The project manager also needs to be able to write a good project
report and present the information during progress review.

4. Risk management
The project managers have to access the risks that may affect a project,
monitor it and take action when the problem occurs. You may refer to
section 2.4 for further information regarding risk management. Assessing
risk management properly may give us enough time to cope with the
unexpected risks.

5. People management
To manage a team of people, a project manager needs to decide and choose
suitable team members according to their capabilities. A project manager
needs to make sure the relationship between team members is close so that
everybody can communicate well. The project manager needs to motivate
them and listen to their problem if occur. For further details on people
management, you may refer to section 5.2.

22 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

As a whole, good project management comes from a dedicated software project

leader. Project management is essential if software engineering projects are to be
developed on schedule and within budget.

Managing people
The greatest properties in software organisation are the people who are involved in
the development. It will involve a lot of cost to recruit and retain a good worker. A
company is successful because people in the company have respect for each other
and take responsibility for any tasks that have been assigned using their skills and
experience.
Good software engineers are not necessarily good project leaders. A good project
leader must have soft skills that can motivate and lead a project development team.
A project manager also needs to be aware of the potential problems of people
management. Sommerville (2010) stated that there are four critical factors in people
management:
1. Consistency
All team members need to be treated equally. True teamwork demands that
all employees are held to the same standards.

2. Respect
Project leader needs to build respect among team members by working
in a team towards the goals. Team building activities can also help team
members learn respect for one another. Leading them through a few teambuilding exercises that show respect for each other can help them see past
their differences towards a common goal.

3. Inclusion
A project leader needs to listen to the team members. If one team member
is left out of the loop, he may feel left out, and that will eventually reduce
the teams effectiveness.

4. Honesty
Project leader must be honest about what is going on in the team. If the team
is not performing properly, the project leader needs to tell them as soon as
possible and discuss together to overcome the problem. Any good or bad news
must be shared so that further action can be figured out together as a team.

UNIT 5 23
Managing software development

A good project leader needs to know how to communicate well with the team
members. The team members need to be motivated to avoid the loss of focus and
interest in the work that they are doing. The well-travelled theory by Maslow (1954)
suggests that people are motivated by satisfying their needs. These needs are arranged
in a series of levels. Figure 5.6 shows the human needs hierarchy. There are five
levels in this hierarchy that contains physiological needs, safety needs, social needs,
esteem needs and self-realisation needs.

Self-realisation
Needs

Esteem Needs

Social Needs

Safety Needs

Physiological Needs

Figure 5.6 Human needs hierarchy

The lower levels of this hierarchy represent fundamental needs for food, sleep and
so on and the need to feel secure in an environment. The social needs are concerned
with the need to belong to part of a social grouping. Esteem needs depict the need
to feel respected by others and the last level on the top is concerned with personal
development. People need to satisfy lower level needs like thirst and hunger before
they satisfy more abstract higher level needs.
From the view point of people management related to software engineering, a project
leader needs to make sure that important levels such as social needs, esteem needs
and self-realisation needs are satisfied. Therefore, the way to apply it is to motivate
the team members at the highest level needs.
1. Social needs
Project leader can get the team together to celebrate after each of the project
milestones is achieved. It will be good to give the team members a break
after struggling to complete each task.

24 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

2. Esteem needs
Project leader needs to show the team that they are important and valued.
The effective way to do it is by giving public recognition of achievement
to the team members.

3. Self-realisation needs
Project leaders also need to give team members responsibility for their work
and assign them demanding tasks to satisfy the self-realisation needs. Project
leaders can also provide a training programme where people can develop
their skills.

A person can focus on more than one need. For example, a person may be seeking
promotion because it will lead to a higher salary which is considered a physiological
need. But the promotion can also satisfy esteem and self-actualisation needs.
Applications of the human needs are not static even though the needs are described
as hierarchical.

Teamwork
Most professional software is developed by development teams that range in size
from two to several hundred people. Therefore, it is clear that with a large team, it
is impossible to work together on a single problem. Large teams usually split into
a number of small teams. Each team is responsible for developing a part of the
overall system. Communications problem can be reduced when people work in
smaller groups. The smaller team can get around a table to discuss the project and
the software they are developing.
Successful teams are more than simply a collection of individuals with the right
balance of skills such as the technical skills, experience and personality. Good team
members must have team spirit. Members of a well team remain led remain loyal
to the group. They make an effort to protect the team from outside interference.
Good project leaders should always try to encourage their team members to stick
together. Social events can be organised for group members and their families in
order to establish a sense of belonging to the group by naming the group and creating
identity and territory in activities such as games or sports.
Sometimes the team effectiveness depends on the nature of the development and
the organisation doing the work. It is very difficult for the team members to focus
on software development if the software development team is constantly reorganised
and there is job insecurity. Sommerville (2010) states that there are three generic
factors that affect teamwork:

UNIT 5 25
Managing software development

1. The people in the team

You need a mix of people in a development team as software development
involves different kinds of activities such as programming, testing and
documentation.

2. The team organisation

A team should be organised so that individuals can contribute to the best
of their abilities and tasks can be completed as expected.

3. Technical and managerial communications

It is essential to have good communications between team members and
other stakeholders.

Getting the right team cannot guarantee that the project can be a success. Too many
other things can go wrong including changes in the business and its environment.
But if the project leader does not take note of group composition, organisation and
communications, it is possible that the project will run into difficulties.

Selecting group members

Creating a team with the right balance of technical skills and personalities can
make the team work together effectively. It is the job of the project leader to create
a cohesive team. Technically, people who are motivated by the work are likely to
be the strongest. People who are self-oriented will probably be best at pushing the
work forward to finish the job. People who are interaction-oriented help facilitate
communications within the group.
Choosing a group with perfect personalities is sometimes impossible. If this is the
case, the project leaders have to control the group so that individual goals do not
take priority over team objectives. Control is easier to gain if all team members
participate in every stage of the project.
Let us have an example of a programmer who is given a program design for coding.
The programmer notices that there are possible improvements that can be made to the
coding. If the programmer implements these improvements without understanding
the rationale for the original coding, any changes might have implications for other
parts of the system. If all of the team members were involved in the coding from the
start, they will understand why certain design decisions were made.

26 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

Team organisation
The way that a team is formed affects the decisions made by that team. It also affects
the way information is exchanged and the interaction between the development team
and external project stakeholders. Important organisational questions for project
managers include:
1. Should the project leader be the technical leader of the group?
The technical leader is responsible for the critical technical decisions made
during software development. There may be some project leaders that have
experience to take on this role. But when it involves a large project, it is best
to appoint somebody else that also have experience such as senior engineers
who will take responsible for technical leadership.

2. Who will be involved in making critical technical decisions and how will
these be made?
The project leaders may have a meeting and discuss with team members.
For a larger project, it is best to have a meeting with each team leader rather
than involveing all staff.

3. How will interactions with external stakeholders and senior company

management be handled?
In many cases, the project leader will be responsible for these interactions.
Sometimes, in a large software development team, there are specific teams
that handle these responsibilities with appropriate interaction skills for that
role.

4. How can teams integrate people who are not working in the same place?
A large project usually involves a lot of team members. It is common to
include members from different software development teams and also
individual freelancer who work from home. This has to be taken into account
in team decision making.

5. How can knowledge be shared across the team?

Project leader should avoid too much information sharing as people become
overloaded and excessive information distracts them from their work.
However, important information can be distributed by implementing group
communications.

UNIT 5 27
Managing software development

Software development team may be organised into small teams. Usually, small teams
can handle the project very well since they can make decisions easier than large
teams. However, if a group is composed mostly of inexperienced or incompetent
members, it can be a big problem because it can cause lack of coordination between
team members and possibly eventual project failure.

Team communications
Team members should communicate effectively and efficiently with each other and
with other project stakeholders. Team members must exchange information on
the status of their work, the design decisions that have been made and changes to
previous design decisions. Good communication between team members can help
strengthen the teams relationship. Sommerville (2010) states that the effectiveness
and efficiency of communications is influenced by:
1. Group size
It gets harder for team members to communicate effectively as a team
gets bigger. Communications are often one way when it involves status
differences between team members. Managers and experienced engineers
tend to dominate communications with less experienced staff who may be
reluctant to start a conversation.

2. Group structure
People in teams that are structured informally communicate more effectively
than people in teams that have a hierarchical structure. In hierarchical teams,
communication tends to flow up and down the hierarchy. People who are at
the same level may not talk to each other. This is a problem in a large project
with several development teams. If people working on different subsystems
only communicate through their leaders, then there are high chances of
delays and misunderstandings.

3. Group composition
Marshall and Heslin (1975) state that communication is usually better in
mixed-sex groups than in single-sex groups. It provides the best chemistry
for interaction and achievement of task.

4. The physical work environment

The workplace is a major factor in facilitating or encouraging communications.

28 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

5. The available communication channels

Face to face, email, formal documents and telephone are some of the different
forms of communications. Project leaders need to make sure that the team
make use of a range of technologies to facilitate communications.

Project leaders may try to use communication channels that do not take too much
time since them working in tight deadlines. They may rely on meetings and formal
documents to pass on information to other team members. But this is not usually
effective. There are often good reasons why people cannot attend meetings and miss
the presentation. Documentation also is not too effective since some members will
not read a long document because they do not know if the documents are relevant.
Good communication is achieved when communication is two-way. This means that
the team can discuss issues and information and establish a common understanding
of proposals and problems. This can be done by holding a meeting. It is sometimes
impractical to arrange meetings at short notice.
To prevent these problems, project leaders may use web technologies such as email,
social network such as Facebook or Twitter, instance messaging and others. It allows
team members to exchange information, irrespective of their location. Therefore,
the team members will have leeway and it can be easily arranged to resolve issues
that need discussion.

Team motivation
Project managers need to motivate their team members to make the project a success.
According to Boehm, motivation has been found to be the number one influence
on peoples performance. To motivate the staff is not as easy as it seems. Giving
monetary rewards and bonuses is not the best way. Instead, you may motivate them
by recognition, achievement, the work itself, responsibility, advancement and the
chance to learn a new skill.
If you insist on giving some kind of reward for motivational purposes, you may try
a pizza or free dinner or even a letter of appreciation or award. Some motivational
donts adapted from Rapid Development by Steve McConnell (1996) that a project
leader needs to avoid are:
1. Do not assign unrealistic deadlines This is because few people will work
hard if they realise that a deadline is impossible to meet and can cause tension
in the group.
2. Do not ignore good effort people will work harder if they feel their work
is appreciated.
3. Do not make an important decision without the teams input project
leader needs to discuss and be involved with the team members when making
decisions that can greatly affect the team members.

UNIT 5 29
Managing software development

4. Do not maintain poor working condition project leader must be aware

that a good working environment can uplift the working spirit. This includes
desk space, privacy from interruptions and others.

By avoiding those listed above, we can ensure that motivation for the project is as
high as possible.

Activity 5.2
Briefly define why a project leader who always update all team
members about progress in a project can improve group relationships.

Summary
Software project management that can develop software within
budget and on schedule is considered essential to a software project.
There are some project activities that need to be handled by a project
leader including project planning, reporting, risk management,
people management and proposal writing.
Software management is not similar to other engineering
management. Software is intangible. The software development may
be innovative so we need to have an experienced leader to guide the
management. Software processes are not as mature as traditional
engineering processes.
The effectiveness in a group brings about good results in developing
software. Communication between team members is important to
avoid any misunderstandings. Communication within a group is
influenced by factors such as the status of group members, the size
of the group, the gender composition of the group, personalities
and available communication channels. Motivation is important to
enhance the working spirit of team members.

30 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

Self-test 5.2
1. What is the most important goal for project management?
A. Deliver the software to the customer in the time given
B. The cost is out of budget
C. Deliver the software by denying the customer needs
D. A complicated teamwork

2. A project leader also needs to give some opportunity to all

members of the team to make a contribution. Which critical
factor of people management does this refer to?
A. Honesty
B. Respect
C. Inclusion
D. Consistency

3. The following are categories in the higher level of human

hierarchical needs EXCEPT
A. Self-realisation
B. Esteem
C. Social
D. Safety

4. Team members can develop their skills by going to ___________

that is usually organised the by project leader.
A. gathering
B. holiday
C. training
D. social event

5. Good teamwork will not

A. have team spirit
B. protect other team members from outside interference
C. loyal to the group
D. keep the problem by themselves

UNIT 5 31
Managing software development

6. A project leader does not have to create a team with the right
balance of technical skills and personalities to make the team
work together effectively.
A. True
B. False

7. It is easy for team members to communicate effectively as a

team gets bigger.
A. True
B. False

Suggested answers to activity

Feedback
Activity 5.2
Here is an example of the answer and ideas that you can use.
The reason that the project leaders need to frequently update all
software development team members about progress in a project
is because:
1. The bigger the group, the harder for the information to get
around the group. Therefore, it is the responsibility of the project
leader to inform other team members.
2. There may be disagreement in decision making. Therefore, the
team members may speak out their opinion even though they
are in the lower level management.
3. When project leaders always update the progress, the team
members will be aware of the schedule and can ensure that the
project is completed within the given time.

32 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

UNIT 5 33
Managing software development

5.3 Project Estimation

Objectives
By the end of this section, you should be able to:
1. Describe the options for cost and effort estimation.
2. Discuss size estimation.
3. Identify the sub-model in COCOMO (Constructive Cost Model) II model.
4. Understand the calendar time estimation.

Introduction
Project estimation can reduce the problem of cost and effort estimation by putting
it into a set of smaller and manageable problems. A cost estimation model is needed
to solve the problem. Many components are involved and this makes the process of
estimation harder since it is unpredictable. Algorithmic cost modelling can be used
to make estimation for software development projects.
We are using COCOMO II model to support modern software development
process and update project database. This model can support modern approaches
and embeds sub-models that produce detailed estimates. For further investigation,
this unit is divided into four sections:
1. Introduction to project estimation.
2. Algorithmic cost modelling.
3. The COCOMO II model.
4. Project duration and staffing.

Introduction to project estimation

Nowadays, software cost composes a large percentage of the overall computer based system cost. It is an important element in computer-based systems. When
the system becomes more complex, the cost would be higher as well. Therefore, a
large cost estimation error can make the difference between profit and loss. It can
be a big problem for the developer.

34 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

In most cases, developing a cost and effort estimate for a software project is too
complex to be considered in one part or piece. For this reason, using project
estimation, we can break the problem down into a set of smaller and manageable
problem. After that, we can form a problem solving using project cost estimation
model.
The objective of project cost estimation is to fully quantify the costs of all aspects
of software development throughout the project life cycle. The process to estimate
the cost is unpredictable and difficult to count since it also involves many variables
such as human, technical, environmental and many more. However, software project
estimation can be transformed from scattered information to a series of systematic
steps that provide estimates with acceptable risk.
Pressman (2006) states that there are a number of options to achieve reliable cost
and effort estimates:
1.

Delay estimation until late in the project (it is obvious that we can gain
100% accurate estimation after the project is complete).

2. Doing software project estimation based on similar projects that have already
been completed.
3. Use relatively simple decomposition technique to generate project cost and
effort estimates.

The first option is attractive but not practical. Cost estimation must be provided at
the beginning of project development. However, we should realise that the more we
know about the project, the less likely we are to make a serious error in estimation.
The second option can work well if your project is similar to a completed project.
Unfortunately, past experience has not always been a good indicator of future
results. For option three, it is a practical approach to software project estimation.
The techniques and models will be explained later in this chapter.

Algorithmic cost modelling

Most work carried out in software project estimation focuses on algorithmic cost
modelling. It uses a mathematical formula to predict project costs. The prediction
is based on estimates of the project size, the type of software being developed and
other factors. In this process, costs are analysed and the closest fit formula to actual
experience is found.
Usually, the part of product that will use algorithmic cost model is to estimate the
code size. Algorithmic models for estimating effort in a software development are
mostly based on a simple formula:
Effort = A SizeB M

UNIT 5 35
Managing software development

= constant factor which depends on local organisational practices and the

type of software that is developed.

Size = assessment of the code size of the software or a functionality estimate

expressed in function or application points.
B

= lies between 1 and 1.5

M = multiplier made by combining process, product and development

attributes such as dependability requirements for the software and the
experience of the development team.

The number of lines of source code (SLOC) in the delivered system is the fundamental
size metric that is used in many algorithmic cost models. Size estimation may involve
certain kinds of estimation such as:
1. Estimation by comparison with other projects.
2. Estimation by converting function or application points to code size.
3. Estimation by ranking the sizes of the system components.
4. Using a known reference component to estimate the component size or it
may simply be a question of engineering judgement.

Most models have exponential components (B in the above formula) that are related
to the size and complexity of the system. This reflects the fact that costs do not
usually increase linearly with project size. Extra cost will be required as the size and
complexity of the software increases. This is because of the communication overhead
of larger teams, more difficult system integration and so on. Therefore, the value
B increases with the size and complexity of the system. According to Sommerville
(2010), all algorithmic models have similar process:
1. It is often difficult to estimate Size at an early stage in a project, when only
the specification is available.
2. The estimates of the factors contributing to B and M are subjective. Estimates
vary from one person to another, depending on their background and
experience of the type of software project.

At an early stage, accurate code size estimation is difficult to achieve. This is because
the size of the final program depends on design decisions that may not have been
made when the estimate is required. You may not know how much data management
code will be included in the system.

36 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

The same goes with programming language where some languages use more lines
that others. For example, Java might use more lines of code than if C was used.
However, validation costs are likely to be reduced since the extra code allows more
compile time checking. If it is possible to reuse code from previous projects, then
the size estimation has to be adjusted to take this into account.
Even though the algorithmic cost model is a systematic way to estimate effort, it is
complex and difficult to use. Many considerable scopes and attributes for uncertainty
need to be taken into account. This discourages potential users, therefore the practical
application of algorithmic cost modelling has been limited to a small number of
companies. The other difficulty is the need for calibration. Model users need to
calibrate their model and attribute values using their own historical project data as
this reflects their experience and practice.
When using algorithmic cost estimation model, you must develop a range of estimates
for worst, expected and best levels. You must also apply the costing formula to all
of the levels. When you understand the type of software that is being developed,
the estimation is most likely to be accurate. This is because you have calibrated the
costing model using local data and programming language and hardware choices
have been predefined.

The COCOMO II model

There are several similar models that have been developed to help estimate the effort,
schedule and costs of a software project. One of the models that we will discuss
here is the COCOMO II model. This is an empirical model which is derived by
collecting data from a large number of software developments. The data that have
been collected are analysed to discover the conventional method that is the best fit
to the observation. This method connects the size of the system and product, project
and team factors to the effort to develop the system.
Sommerville (2010) states that Constructive Cost Model or COCOMO is an
algorithmic software cost estimation model developed by Barry W. Boehm. This
model provides more support for modern software development processes and
an updated project database. It can support modern approaches such as rapid
development using dynamic languages, development by component composition
and the spiral model. It also embeds sub-models that produce increasingly detailed
estimates. The sub-models that are part of the COCOMO II model are:
1. Application composition model
2. Early design model
3. Reuse model
4. Post-architecture model

UNIT 5 37
Managing software development

Different parts of the system may be developed using different technologies in large
systems. You may not be able to estimate all parts of the system accurately. Therefore,
you may use the suitable sub-model for each part of the system and integrate the
results to create a composite estimate.

The application composition model

This model was introduced into COCOMO II to support the estimation of effort
required for prototyping projects. It also supports projects where the software is
developed by forming existing components. Application composition model weighs
the estimate using application point. The application point will be divided with
the standard estimate of application point of productivity. According to Boehm et
al. (2000), the estimate is adjusted according to the difficulties of developing each
application point.
The effort required to develop software is created from reusable components,
scripting or database programming. Application point will be used to estimates system
developed using dynamic language based on the number of application points. The
weights that have been counted as application points are such as:
1. The number of separate screens that are displayed.
2. The number of reports that are produced.
3. The number of modules in imperative programming language.
4. The number of lines of programming code.

Some of the application points in the project will be implemented using reusable
components. Therefore, you need to adjust the estimate to make sure the percentage
of reuse expected. The final formula for effort computation for system prototypes is:
PM = [NAP (1 %reuse / 100] / PROD

PM = the effort estimate in person months

NAP = the total number of application points in the delivered system
% reuse = an estimate of the amount of reused code in the development
PROD = the application point productivity
Any additional effort that involves reuse will not be counted inside the estimation
cost.
There are several steps that you need to follow for the estimation of effort in person
months.

38 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

1. Assess application count: Estimate the number of screen, reports and 3GL
(third Generation Language) components that will comprise this application.

2. Classification of complexity level: We have to classify the application instance

into simple, medium and difficult complexity levels depending on values
assigned to its characteristics. The screens are classified on the basis of
number of views and sources and reports are on the basis of number of
sections and sources. The details are given in Table 5.3.
Number of
view contained

Source of data tables

Total < 4
(<2 client
<3 server)

Total < 8
(2 3 client
3 5 server)

Total 8+
(>3 client
>5 server)

<3

Simple

Simple

Medium

3 7

Simple

Medium

Difficult

>8

Medium

Difficult

Difficult

Table 5.3 (a) For screens

Number of
view contained

Source of data tables

Total < 4
(<2 client
<3 server)

Total < 8
(2 3 client
3 5 server)

Total 8+
(>3 client
>5 server)

0 or 1

Simple

Simple

Medium

2 or 3

Simple

Medium

Difficult

4+

Medium

Difficult

Difficult

Table 5.3 (b) For reports

3. Assign complexity weight for each application: The weights are used for
three application types. For example, screen, report and 3GL components
using Table 5.4.
Application Type

Source of data tables

Simple

Medium

Difficult

Screen

Report

3GL Component

10

Table 5.4 Complexity weight

UNIT 5 39
Managing software development

4. Determine application points: Add all the weight application instances to

get one number and this number is known as application point count.

5. Compute new application point (NAP): We have to estimate object reuse.

Depending on the percentage reuse, the new application points are counted.
NAP =

(application point)*(100%reuse)
100

NAPs are the application points that will need to be developed and they
may differ from the application point count because they may be reused.

6. Calculation productivity rate: The productivity rate can be calculated as:

Productivity rate (PROD): NAP/Person Month

Productivity depends on the developers experience and capability. The

capability includes the capabilities of the software tools (ICASE) that support
the project. Table 5.5 shows the levels of application point of productivity
suggested by Boehm et al.
Developers experience and capability;
ICASE maturity and capability
PROD (NAP/person per month)

Very
low

Low

Normal

High

Very
High

13

25

50

Table 5.5 Application point productivity

7. Compute the effort in person per month: When PROD is known, you can
estimate effort person per month as:
PM =

NAP
PROD

40 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

Activity 5.3
Consider a database application project with the following
characteristics:
1. The application has five screens and five views each and seven
data tables for three servers and four clients.
2. The application may generate two reports of three sections each
from seven data tables for two servers and three clients. There
is 20% reuse of application points.

The developers experience and capability in this subject is low. The

maturity of the company in terms of capability is also low. Calculate
the application point count, new application points and effort to
develop such project.

The early design model

It is used during early stages of the system design and after the requirements have
been established. In the early design model, the estimate is based on function points.
This model is used to make rough estimates of a projects cost and duration before
determining its entire architecture. You need to estimate the number of external
inputs and outputs, user interactions, external interfaces and files or database tables
used by the system.
The early design model is useful when comparing the ways of implementing the
user requirement for option exploration. This model assumes that user requirements
have been agreed and preliminary stages of the design process are under way. You
should make a quick and approximate cost estimate by simplifying assumptions
of estimate. At this stage, the estimates produced are based on the formula for
algorithmic models as follows:
Effort = A SizeB M
where,
A

= Boehm proposed that the coefficient A should be 2.94 based on his own large
data set.

Size = The size of the system is shown in KSLOC which means the number of
thousands of lines of source code. You will calculate KSLOC by estimating the
number of function points in the software. After that, use standard tables
that relate software size to function points for different programming
languages to compute a preliminary estimate of the system size in KSLOC.
Below are several steps to find the size.

UNIT 5 41
Managing software development

1. You need to determine the Unadjusted Function Points (UFP) using

predefined weight for each function shown in Table 5.6:
Functional Units

Weighting Factors
Low

Average

High

External Input (EI)

External Output (EO)

External Inquires (EQ)

Internal Logical Files (ILF)

10

15

External Interface Files (EIF)

10

Table 5.6 Functional units with weighting factors

Calculation for UFP is shown in Table 5.7:

Complexity
Description

Total

Low

Medium

High

Inputs

_x3

_x 4

_x 6

Outputs

_x4

_x 5

_x 7

Queries

_x3

_x4

_x 6

Files

_x7

_x 10

_x 15

Program Interfaces

_x5

_x 7

_x 10

Total Unadjusted Function Point (TUFP)

Table 5.7 UFP calculation table

2. After the TUFP has been defined, you need to calculate the adjustment
factor which is determined by considering 14 aspects of processing complexity
as shown in Table 5.8.
Number of factors considered
1

Does the system require reliable backup and recovery?

Is data communication required?

Are there distributed processing functions?

Is performance critical?

Will the system run in an existing heavily utilised operational

environment?

Does the system require online data entry?

Does the online data entry require the input transaction to be built
over multiple screens or operations?

Are the master files updated online?

42 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

Are the inputs, outputs, files or queries complex?

10

Is the internal processing complex?

11

Is the code designed to be reusable?

12

Are conversion and installation included in the design?

13

Is the system designed for multiple installations in different

organisations?

14

Is the application designed to facilitate change and ease of use by

the user?

Table 5.8 14 aspects of processing complexity

You need to rate each factor on a scale of 0 to 5 as shown in Figure 5.7.

No
influence

Incidental

Moderate

Average

Significant

Essential

Figure 5.7 Factor of scale

To calculate the adjustment factor,

Complexity Adjusment Factor (CAF) = 0.65 + [0.01 (total processing
complexity)]

3. Now you can calculate the function point after TUFP and CAF have been
defined. The calculation is
FP = CAF TUFP

4. Once you have obtained the value of FP, you need to convert the number of
function points into the lines of code that will be required to build the system.
The number of codes depends on the programming languages you choose
to use. Table 5.9 represents a very rough conversion guide for some popular
languages. The table is taken from Caper Jones, Software Productivity
Research.

UNIT 5 43
Managing software development

Language

Approximate Number of Lines of Code

(LOC) per Function Point

130

COBOL

110

JAVA

55

C++

50

Visual Basic

30

HTML

15

Packages (e.g., Access, Excel)

10 40

Table 5.9 Converting from function points to lines of code

For example, a system consists of 224 function points. If you were to develop
the system in COBOL, it would typically require
Size = FP LOC per function point
= 224 110
= 24640

It will require 24,640 lines of codes for programmers to write it. As you
can see, the choice of development language has a significant impact on the
time and cost of projects.
B = The exponent B shows the increased effort required as the size of the
project increases. If B < 1, the rate of increase of effort decreases as the size
of the product increases. If B > 1.0, the rate of increase of effort increases as
the size of the product increases. The value B is computed on the basis of
scaling factors that may cause a drop in productivity with an increase in size.

44 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

Scale Factor

Explanation

Precedentedness

Reflects the previous experience of the organisation

with this type of project. Very low means no previous
experience; extra high means that the organisation is
completely familiar with this application domain.

Development
flexibility

Reflects the degree of flexibility in the development

process. Very low means a prescribed process is used;
extra high means that the client sets only general goals.

Architecture/risk
resolution

Reflects the extent of risk analysis carried out. Very low

means little analysis; extra high means a complete and
thorough risk analysis.

Team cohesion

Reflects how well the development team knows

each other and works together. Very low means very
difficult interactions; extra high means an integrated
and effective team with no communication problems.

Process maturity

Reflects the process maturity of the organisation.

The computation of this value depends on the CMM
Maturity Questionnaire but an estimate can be achieved
by subtracting the CMM process maturity level 5.

Table 5.10 Scaling factors

Scaling factors

Very
low

Low

Nominal

High

Very
high

Extra
high

Precedentedness

6.20

4.96

3.72

2.48

1.24

0.00

Development
flexibility

5.07

4.05

3.04

2.03

1.01

0.00

Architecture/
risk resolution

7.07

5.65

4.24

2.83

1.41

0.00

Team cohesion

5.48

4.38

3.29

2.19

1.10

0.00

Process Maturity

7.80

6.24

4.68

3.12

1.56

0.00

Table 5.11 Data to compute value B

Source: Software Engineering by Aggarwal (2005)

The value B can be calculated as

B = (total of scaling factor) /100 + 1.01

According to Boehm, when all the scaling factors of a project are rated as
extra high, the best value of B is obtained and is equal to 0.91. When all the
scaling factors are very low, the worst value of B is obtained and is equal to
1.23. Therefore, the value of B may vary from 0.91 to 1.23.

UNIT 5 45
Managing software development

M = It is based on seven project and process attributes that increase or

decrease the estimates. This table is taken from Software Quality Management,
Dumke and Guericke (University Magdeburg).
Cost
Meaning
Driver

Rating
Extra
Low

Very
Low

Low

Nominal High

0.73

0.81

0.98

1.00

Very
High

Extra
High

1.30

1.74

2.38

RCPX

Product
reliability and
complexity

RUSE

Reuse
required

0.95

1.00

1.07

1.15

1.24

PDIF

Platform
difficulties

0.87

1.00

1.29

1.81

2.61

PERS

Personal
capabilities

2.12

1.62

1.26

1.00

0.83

0.63

0.5

PREX

Personal
experience

1.59

1.33

1.12

1.00

0.87

0.71

0.62

FCIL

Support
facilities

1.43

1.30

1.10

1.00

0.87

0.73

0.62

SCED

Schedule

1.43

1.14

1.00

1.00

1.00

Table 5.12 Cost drivers with rating

Therefore, the way to count M is

M = PERS RCPX RUSE PDIF PREX FCIL SCED

Activity 5.4
A software project of application generator category has to be
developed. Given that the functional units (UFP) for size of the
system are:
1. External Input (EI) = Low (2), Medium (3), High (1)
2. External Output (EO) = Low (4), Medium (4), High (2)
3. External Inquires (EQ) = Low (2), Medium (1), High (1)
4. Internal Logical Files(ILF) = Low (3), Medium (4), High (2)
5. External Interface Files (EIF) = Low (1), Medium (2), High (1)

46 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

The processing complexity requires that the data communication

be moderate, the performance of the system be average, online
data entry be moderate, conversion and installation included in
the design be moderate while the other aspects have no influence
on the system. The software project uses JAVA as its programming
language.
The scale factor (B) has low rating in precedentness, development
flexibility and team cohesion. Other factors are nominal. The scaling
factor (C) is 1.01. The early design cost drivers such as Platform
Difficulties (PDIF) and Personal Capability (PERS) are high and
others are nominal. Calculate the effort in person-months for the
development of the project.

The reuse model

It is used to compute the effort required to combine the reusable components and
then generates the program code. Organisations that have large systems typically use
a significant amount of code that has been reused from previous software projects.
The reuse model is used to estimate the effort required to combine reusable or
generated code. COCOMO II has two types of reused code as follows:
1. Black box codes code that can be reused without understanding the code
or making changes to the code. The development effort for black box code
is taken to be zero.
2. White box codes code that needs to be adapted to combine with new or
reused code. Development effort for reuse is counted since the code has to be
understood and modified before it can be integrated correctly with the
system.

To generate this code, the reuse model includes a formula to estimate the effort
required:
PM= (ASLOC AT / 100) / ATPROD

ASLOC = total number of lines of reused code including the code that is autogenerated
AT = the percentage of reused code that is automatically generated
ATPROD = the productivity of engineers in integrating the code
PM = effort estimate in person-months

UNIT 5 47
Managing software development

Boehm et al. (2000) has measured ATPROD to be about 2,400 source statements
per month. Therefore, if there are a total of 20,000 lines of reused source code in
a system and 30% of this is automatically generated, then the effort required to
integrate the generated code is:
(20,000 30/100) / 2,400 = 2.5 person-months

So, the effort required to integrate the code is 2.5 person-months.

The post-architectural model

This is the most detailed model in the COCOMO II model. It is used for
development effort based on system design specification which is based on number of
lines of source code. It may also proceed in the most cost effective way if the project
life cycle architecture has been developed, validated in line with the system concept
of operation and risk. Post-architectural model involves the actual development and
maintenance of a software product.
The starting point for estimates produced at the post-architecture level is the same
formula used in the early design estimates:
PM = A SizeB M

The difference between early design and post-architectural formulas is the cost
driver for finding the value M. In early design, only 7 cost drivers were identified.
The post-architectural model has 17 cost drivers mapped from the early design cost
drivers. This mapping is essential because many parameters were not known correctly
in the early design phase. Below are the cost drivers of post- architectural model
with the rating taken from Software Quality Management, Dumke and Guericke
(University Magdeburg).

48 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

Cost
Driver

Meaning

RELY

Reliability Required

DATA

Database Size

CPLX

Product Complexity

RUSE

Required
Reusability

DOCU

Documentation

TIME

Ratings
Very
Low

Low

Nominal

High

Very
High

0.75

0.88

1.00

1.15

1.39

0.93

1.00

1.09

1.19

0.88

1.00

1.15

1.0

1.66

0.91

1.00

1.14

1.29

1.49

0.95

1.00

1.06

1.13

Execution Time
Constraint

1.00

1.11

1.31

1.67

STOR

Main Storage
Constraint

1.00

1.06

1.21

1.57

PVOL

Platform Volatility

0.87

1.00

1.15

1.30

ACAP

Analyst Capability

1.50

1.22

1.00

0.83

0.67

PCAP

Programmers
Capability

1.37

1.16

1.00

0.87

0.74

PCON

Personnel
Continuity

1.24

1.10

1.00

0.92

0.84

AEXP

Analyst Experience

1.22

1.10

1.00

0.89

0.81

PEXP

Programmer
Experience

1.25

1.12

1.00

0.88

0.81

LTEX

Language & tool

Experience

1.22

1.10

1.00

0.91

0.84

TOOL

Use of Software
Tools

1.24

1.12

1.00

0.86

0.72

SITE

Site Location &

Communication
Technology
between Sites

1.25

1.10

1.00

0.92

0.84

SCED

Schedule

1.29

1.10

1.00

1.00

1.00

0.75

0.89

Extra
High

0.78

Table 5.13 Cost drivers involved in post-architectural model

At this stage, you would be able to make a more accurate estimate of the project size.
Hence, the calculation of PM is a better and fine-tuned value using very specific
cost drivers.

UNIT 5 49
Managing software development

Project duration and staffing

Project leaders must estimate how long the software will take to develop and when
staff will be needed to work on the project. According to Sommerville (2010),
organisations prefer shorter development duration so that they can bring the product
to market before their competitors.
The COCOMO models have a formula that can estimate the calendar time required
to complete a project:
TDEV = 3 (PM)[0.33 + 0.2*(B 1.01)]

TDEV = the nominal schedule for the project, in calendar months, ignoring any
multiplier that is related to project schedule.
PM = the effort computed by the COCOMO model
B = the complexity-related component
For example, if B = 1.17 and PM = 60, then
TDEV = 3 x (60) 0.36 = 13 months

The schedule required in project planning and the one that has been predicted by the
COCOMO model are not necessarily the same thing. There may be a requirement
that needs to be delivered earlier, therefore this increases the effort required for the
project. This is counted in SCED multiplier in the effort estimation computation.
Let us say that the project estimated TDEV is 13 months such as the above. But
the actual schedule is 11 months. Therefore, the schedule is compressed into
approximately 25%. Using the values for SCED multiplier as derived by Boehms
team, the effort multiplier for such a schedule compression is 1.43. Therefore,
according to the actual schedule, the actual effort required is almost 50% more than
the effort required in acceleration schedule.
Complex relationships arise between the number of people working on the
development, the effort spent and the project delivery schedule. If four people
can complete a project in 13 months which is equivalent to 52 person-months of
effort, then you may add one more person so that you can complete the work in
11 months which is considered as 55 person-months of effort. But the COCOMO
model suggests that you need six people to finish the work in 11 months which is
equivalent to 66 person-months of effort.
You cannot simply estimate the number of people needed in a development team by
dividing it with the total effort. Typically, a small group of people are required at the
start of the project to carry out the initial design. The development team then builds
up to a peak during the development and testing of the system and then declines

50 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

in size as the system is prepared for deployment. Project leaders must avoid adding
too many staff to a project early in its lifetime so that it can maintain the expected
level as in project schedule.

Summary
From this section, you have learnt that project cost estimation is
used to fully quantify the costs of all aspects of software development
throughout the project life cycle. Many considerable scope and
attributes for uncertainty need to be taken into account when
applying project estimation to your project. In this section, there
are a number of options available to achieve reliable cost and effort
estimates.
Two kinds of estimation techniques for project estimation have
been introduced. First is the algorithmic cost model. This model
is based on estimates of the project size, the type of software being
developed and other factors. Second is the COCOMO II costing
model which is a mature algorithmic cost model that takes project,
product, hardware and personnel attributes into account when
formulating a cost estimate.
Using COCOMO II formula, you can calculate the estimation for
project duration and staffing. It estimates how long the software will
take to develop and when staff will be needed to work. For staffing, a
small group of people are required to carry out the early design at the
beginning of development. During development, more staff would
be needed. Using estimation technique, the project leader can know
how to estimate when staff is needed the most. For maintaining the
level in project schedule, the project leader must avoid adding too
many staff to the development unless its really necessary.

UNIT 5 51
Managing software development

Self-test 5.3
1. When is the best time to provide cost estimation?
A.
B.
C.
D.

Beginning of the project

During the project
Late at the end of the project
After design phase

2. This is used to make estimates of software development projects.

This statement refers to
A. algorithmic estimate model
B. algorithmic cost model
C. spiral model
D. Rapid Application Development

3. _________________ is made by combining process, product

and development attributes such as dependability requirements
for the software and the experience of the development team.
A. Architectural
B. Application
C. Assessment
D. Multiplier

4. COCOMO stands for

A. Constant Cost Model
B. Cost Combining Model
C. Constructive Cost Model
D. Conveying Cost Model

5. Below are the sub-models of the COCOMO II model EXCEPT

A. early design
B. application model
C. reuse model
D. post-architectural model

52 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

6. Complex relationships arise between the number of people

working on the development, the effort spent and the project
delivery schedule.
A. True
B. False

7. Project leaders must add more staff to a project early in its

lifetime so that it can maintain the expected level as in project
schedule.
A. True
B. False

Suggested answers to activities

Feedback
Activity 5.3
The project comes under the category of application composition
estimation model.
Number of screens = 5 with 5 views each
Number of reports = 2 with 3 sections each
From Table 5.3, we know that each screen and report will be of
medium complexity.
Using Table 5.4 of complexity weights, we may calculate application
point count = 5 2 + 3 5 = 25
NAP =

25 * (100 20)
= 20
100

Table 5.5 shows that the low value of productivity (PROD) is

seven. Therefore:
PM =

NAP
PROD

PM =

20
= 2.857 PM
7

UNIT 5 53
Managing software development

Activity 5.4
For calculation of size,
1. Define UFP
Description

Total
Number

Complexity

Total

Low

Medium

High

Inputs

2x3

3x4

1x6

24

Outputs

10

4x4

4x 5

2x 7

50

Queries

2x3

1x4

1x 6

16

Files

3x7

4 x 10

2 x 15

91

Program
Interfaces

1x5

2x7

1 x 10

29

Total Unadjusted Function Point (TUFP)

210

2. Define CAF
No

Number of factors considered

Rating

Does the system require reliable backup and

recovery?

Is data communication required?

Are there distributed processing functions?

Is performance critical?

Will the system run in an existing heavily

utilised operational environment?

Does the system require online data entry?

Does the online data entry require the input

transaction to be built over multiple screens
or operations?

Are the master files updated online?

Are the inputs, outputs, files or queries

complex?

10

Is the internal processing complex?

11

Is the code designed to be reusable?

12

Are conversion and installation included in

the design?

13

Is the system designed for multiple installations

in different organisations?

14

Is the application designed to facilitate change

and ease of use by the user?

Total processing complexity

54 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

CAF = 0.65 + [0.01 (total processing complexity)]

F = 0.65 + (0.01 8)
F = 0.73
3. Determine the function point
FP = CAF TUFP
= 0.73 210
= 153
4. Define size of the system. Since the software is using JAVA as
its programming language, the lines of code per function point
will be
Size = FP LOC per function point
= 153 55
= 8415
5. Determine exponent B
Factor

Scale

Precedentedness

4.96

Development Flexibility

2.03

Architecture/Risk Resolution

4.24

Team Cohesion

4.38

Process Maturity

4.68

Total

20.29

B = (total of scaling factor) /100 + 1.01

= (20.29/100) + 1.01
= 1.2
6. Determine M.
M = PERS RCPX RUSE PDIF PREX FCIL SCED
= 1 1 1.29 0.83 1 1 1
= 1.07
7. Determine the effort in person-months.
Effort = A SizeB M
= 2.94 (8415)1.2 1.07
= 161,360.06 person-months

UNIT 5 55
Managing software development

5.4 Professional and Ethical

Responsibility
Objectives
By the end of this section, you should be able to:
1. Identify issues of professional and ethical responsibilities.
2. Describe eight ethics principles.
3. Identify listing of responsibilities.

Introduction
The activities during the design, analysis, specification, maintenance and evaluation
phases of software development have a significant real-world impact. Software
engineers must pledge to make software engineering a beneficial and respected
profession to ensure that those efforts will be used for the general good. Software
engineers also need to apply an ethical approach to their professional practice.
In this section, you will learn how software engineers gain the ability to make
appropriate decisions based on ethical codes and principles. This section has been
divided into three parts:
1. Understanding professional and ethical responsibilities.
2. Issues of professional responsibilities.
3. Code of Ethics.

Understanding professional and ethical responsibilities

Without any doubt we must agree that computers have an important role in our daily
life. Software engineers are the people that contribute directly towards developing
and maintaining all these software systems and it has become essential to our life.
Software engineers have a chance to do good or cause harm or even allow others
to do bad things since their role is so important in developing software systems.
Software engineers must pledge to make software engineering a beneficial and
respected profession so that they will work only for the good cause.
People make different decisions because they think differently. But by knowing
the way they make the decisions and discussing the decisions with others, a better
agreement can be achieved. To make a job more conceivable, we can write out some

56 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

ethical principles. But these principles can be applied differently. Based on these
principles, they can come out with ideas and seek something that is acceptable
among them.
According to Software Engineering Code of Ethics and Professional Practice,
engineers have to abide by the Eight Ethics Principles. The principles include the
discussion about the software engineers action that has to be in the best interest of
the public. They need to work in a manner that is good for client and employer.
They need to build software which meets the highest professional standards possible.
They must maintain integrity and independence in professional determinations.
Project leaders also need to promise and support an ethical manner when creating
and maintaining software.

Issues of professional responsibilities

Software engineering is carried out within a social and legal framework that limits
the freedom of people working in that area just like other engineering disciplines.
Software engineers must accept that their job not only requires technical skills
but also involves wider responsibilities. A professional engineer must behave in an
ethical and morally responsible way. There are areas not tied by laws but more of
professional understanding. This includes:
1. Confidentiality: Whether or not a formal confidentiality agreement has been
signed, you must respect the confidential of your employers and clients.
2. Competence: You should not misrepresent your level of competence. You
should not knowingly accept work that is outside your competence.
3. Intellectual property right: The awareness of local laws governing the use
of intellectual property such as patent and copyright. You should be careful
to ensure that the intellectual property of employers and clients is protected.
4. Computer misuse: You should not use your technical skills to misuse other
peoples computers. Computer misuse ranges from the relatively ordinary
such as playing games using companys computers to extremely serious ones
such as diffusing viruses.

Responsibility and accountability are two important elements that are of concern
to software engineers who are involved in:
1. The development of the projects.
This includes analysing, designing, implementing, testing and support. The
software development team must be responsible for the software development
process. They must ensure that the software is fit for use by others. Fitness
for use is not restricted to functionality but must also give due regard to
security, usability, reliability and privacy concerns.

UNIT 5 57
Managing software development

2. The use of the software.

The software development team must be responsible for ensuring that the
software is used within the underlying principle, limitations, assumptions
and validity of the result.

The software development team should have a list of responsibilities so that it can be
used as a guide to develop software that is safety-critical. This list is also suitable for
those software engineers that require ready-made software for their field of practice.
This list may also be used by those who want to provide the specification for the
software to be developed for them and who would benefit from knowing what to
request from their potential customers. Software development teams involved in
developing software should:
1. Explain the purpose of the software, the methodologies and requirements
as well as the constraint of the software system in the form of a document.
2. Reveal the scope of testing in terms of its functionality and the extent to
which internal testing has provided confirmation of suitability to purpose.
3. Produce a realistic data by making the end users test the reliability, functions,
features and performance of the software for themselves.
4. Supply statements which are considered applicable standards in the software
system.
5. Prepare clear and understandable documentation and procedures for end
users and it must highlight any limitations, risks on the use of the software.
6. Review and directly reveal to the users any constraints of the software and
identify any backup or checking procedures to verify proper operations of
the software.
7. Produce an agreement or timely releases to software users for important bug
fixes or any corrections that may affect the performance of the software.
8. Provide sufficient documentation to allow the client to perform maintenance.
9. Produce a schedule for the users of the software regarding the continuing
educational and training services.
10. Conduct their programming activities according to software industry
standards and guidelines.
11. Ensure there is appropriate action taken by the proper authorities in any
instance where they believe that public safety or the environment is
endangered.

58 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

12. Provide a necessary safeguard against software failure such as increasing the
depth of software engineer fundamentals.

The software development teams and customers are free to negotiate the scope of
work through their contractual agreement. The purpose of this list is to emphasise
that there are many duties that the software development team should be prepared
to undertake.

Code of ethics
In setting ethical standards, professional societies and institutions play an important
role. According to Sommerville (2010), there are organisations such as the ACM
(Association for Computing Machinery), the IEEE (Institute of Electrical and
Electronic Engineers) and the British Computer Society which publish a code of
professional conduct or code of ethics. Members of this organisation undertake to
follow that code when they sign up for membership. These codes of conduct are
generally concerned with fundamental ethical behaviour.
Professional associations, notably the ACM and the IEEE have cooperated to produce
a joint code of ethics and professional practice. This code exists in both a short form
such as in Table 5.14, and a longer form (Gotterbarn 1999) that adds detail and
substance to the shorter version.

UNIT 5 59
Managing software development

Software Engineering Code of Ethics and Professional Practice (Short Version)

PREAMBLE
The short version of the code summarizes aspirations at a high level of the
abstraction; the clauses that are included in the full version give examples and
details of how these aspirations change the way we act as software engineering
professionals. Without the aspirations, the details can become legalistic and tedious;
without the details, the aspirations can become high sounding but empty; together,
the aspirations and the details form a cohesive code.
Software engineers shall commit themselves to making the analysis, specification,
design, development, testing and maintenance of software a beneficial and
respected profession. In accordance with their commitment to the health, safety
and welfare of the public, software engineers shall adhere to the following Eight
Principles:
1. PUBLIC Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER Software engineers shall act in a manner that is in
the best interests of their client and employer consistent with the public
interest.
3. PRODUCT Software engineers shall ensure that their products and related
modifications meet the highest professional standards possible.
4. JUDGMENT Software engineers shall maintain integrity and independence
in their professional judgment.

5. MANAGEMENT Software engineering managers and leaders shall subscribe

to and promote an ethical approach to the management of software
development and maintenance.
6. PROFESSION Software engineers shall advance the integrity and reputation
of the profession consistent with the public interest.
7. COLLEAGUES Software engineers shall be fair to and supportive of their
colleagues.
8. SELF Software engineers shall participate in lifelong learning regarding the
practice of their profession and shall promote an ethical approach to the
practice of the profession.
Table 5.14 The shorter version of ACM/IEEE Code of Ethics (IEEE/ACM 1999)

You will face ethical dilemma when different people have different views and
objectives. For example, how you should react when you disagree, in principle and
with the policies of senior management in the company? This will depend on the
nature of agreements and the individuals. Is it best to argue a case for your position
from within the organisation or to resign in principle? It may be too late to resolve
the problem if a solution is not provided in time. A particularly hard situation for
software engineers arises when the employer acts in an unethical way. You need to
try to resolve the situation to fulfil your social responsibility while respecting the
rights of your employers.

60 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

Another ethical issue is participation in the development of military and nuclear

systems. Some people feel strongly about these issues and do not wish to participate
in any development associated with military systems. Others will work on military
systems but not on weapon systems. Yet others feel that national defence is an
overriding principle and have no ethical objections to working on weapon systems.
The appropriate ethical position here depends entirely on the views of the individuals
who are involved.
In this situation, it is important that both employers and employees should make
their views known to each other in advance. Where an organisation is involved in
military or nuclear work, they should be able to specify that employees must be
willing to accept any work assignment. Equally, if employees are taken on and make
it clear that they do not wish to work on such systems, employers should not put
pressure on them to do so at some later date.

Summary
The software development team needs to commit themselves to
making software beneficial to ensure that those efforts will be for
the general good. They need to be concerned about the safety and
security requirements, human and personal rights and be aware
of and follow the laws and standards. There are areas that are not
tied by laws but by meant for general understanding that includes
confidentiality, competence and intellectual property right and
computer misuse.
The software development team should have a list of responsibilities
so that it can be used as a guide. It may also be used by those who
want to provide the specification for the software to be developed
for them. Code of ethics expresses the majority of opinion about
the profession on ethical issues. It also means educating the general
public about the ethical norms and values of the profession. There
are eight principles which include public, client and employer,
product, judgement, management, profession, colleagues and self.

UNIT 5 61
Managing software development

Self-test 5.4
1. What can we do to achieve better decision?
A. Develop an ethical guideline
B. Defend our opinion
C. Stick to one opinion
D. Take decision from higher level only

2. You should be careful to ensure that the copyright of employers

is protected. Which professional responsibility does this
statement refer to?
A. Confidentiality
B. Intellectual properties right
C. Computer misuse
D. Competence

3. You should not misrepresent your level of qualities. Which

professional responsibility does this statement refer to?
A. Confidentiality
B. Intellectual property right
C. Computer misuse
D. Competence

4. Code of ethics is concerned with

A. fundamental customer behaviour
B. fundamental work behaviour
C. fundamental ethical behaviour
D. fundamental manipulative behaviour

5. The following are included in the Eight Ethics Principles

EXCEPT
A. confidentiality
B. competence
C. retirement
D. management

62 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

6. The purpose of the software development team responsibility

list is to emphasise that there are many duties that the software
development team should be prepared to undertake.
A. True
B. False

UNIT 5 63
Managing software development

Summary of Unit 5
Summary
Software development team will present a project plan that provides
structured activities on how the work will be done. The process of
organising the work can be represented on project scheduling where
it shows how the tasks need to be executed on time. A project plan
sets the resources needed for the project, the tasks involved and a
specific schedule for carrying out the work. Bar chart and activity
diagram are commonly used for schedule representation. Project
scheduling involves the creation of graphical representations for
the different parts of project planning.
The team members in software development should be connected
to each others. Team members must be able to communicate clearly
their feelings, express plans and goals, share ideas and opinions. The
key factor to achieving good results in developing the product is
when the team manages themselves properly.
In project cost estimation, the project leaders need to fully quantify
the costs of all aspects of software development throughout the
project life cycle. Estimation techniques for software may be
experience-based where managers judge the effort required or
algorithmic where the effort required is computed from other
estimated project parameters.
Firm commitment is needed from the software development team
to ensure that those efforts will be for the general good. Software
engineers need to have guidance on their responsibilities so that there
will be positive effect on their profession. Therefore, the eight ethics
principles have been developed by ACM and IEEE which include
public, client and employer, product, judgement, management,
profession, colleagues, and self.
Overall, using a project plan that has the right scheduling is one of
the factors that can make a successful project. With a project plan,
the project leader can produce a cost and effort estimate. Teamwork
is also an important factor in assessing a project. With good
teamwork, it will be easy to make the team comply with the eight
ethics principles which are a guide on responsibilities in their job.

64 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

UNIT 5 65
Managing software development

Course Summary
Summary
This course is meant to help you develop an understanding of
software development models. After completing this course, you
should have a good understanding of what software development
models are as explained in Unit 1. You have also learnt about
software process management i.e., process modelling, design
architecture, quality of software and managing risk in Unit 2.
Besides that, Unit 3 dealt with analysis techniques by looking at
problem analysing and solution synthesis as well as requirement
and specification analysis. It also involves some activities using use
cases and objects.
In Unit 4, you have learnt about System Development Life Cycle
(SDLC), Object-oriented Analysis and Design (OOAD), Agile
Distributed Development Model (ADDM), Component-based
Software Engineering (CBSE) and other models. Unit 5 covered
software development management. It dealt with planning and
scheduling, project management, understanding the software life
cycle and the methodologies, and finally the professional and ethical
responsibility in software development. You should be able to apply
the knowledge that you have learnt throughout this course to be an
effective software engineer.

66 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

UNIT 5 67
Managing software development

Suggested Answers to Self-tests

Feedback
Self-test 5.1
1. A
2. B
3. D
4. C
5. D
6. A

Self-test 5.2
1. A
2. B
3. D
4. C
5. D
6. B
7. B

Self-test 5.3
1. A
2. B
3. D
4. C

68 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

5. B
6. A
7. B

Self-test 5.4
1. A
2. B
3. D
4. C
5. D
6. A

UNIT 5 69
Managing software development

References
Boehm, B et al. (2000) Software Cost Estimation with Cocomo II, Boston: AddisonWesley.
Gotterbarn (1999) Not all codes are created equal: The software engineering code
of ethics, a success story. Journal of Business Ethics 22 (1):81 89
Marshall and Heslin (1975) Sexual composition and the effect of density and group
size on cohesiveness, Journal of Personality and Social Psychology PSP , vol. 31:
5, 952 961.
Maslow, A (1954) Motivation and Personality, NY: Harper.
McConnell, S (1996) Rapid Development, WA: Microsoft Press, Redmond, WA.
Pressman R S (2001) Software Engineering: A Practitioners Approach, 5th edn, USA:
Pearson.
Sommerville, I (2010) Software Engineering, 9th edn, USA: Pearson.

70 WAWASAN OPEN UNIVERSITY

TCC 125/05 Software Development Models

UNIT 5 71
Managing software development

Glossary
Compartmentalisation

A divide and conquer approach to separating

conflicting ideas.

Discrepancies

Difference, inconsistency.

Empirical model

A novel approach to computer-based modelling.

Interdependency

A relationship in which each member is

mutually dependent on the others.

Milestone

Often put at the end of a stage to mark the

completion of a work phase.

one-shot project

Project that is done only one time, with no

subsequent issues intended.

Proposal writing

Document that helps cultivate an initial

p ro f e s s i o n a l re l a t i o n s h i p b e t we e n a n
organisation and the software development
team.

Social events

An event characteristic of persons forming

groups that happens at a given place and time.

Velocity

In extreme programming, it means the number

of effort points implemented by the team per
day.