CS383 - Software Engineering

Software and Project Management

Semester: 461

Lecture: 6
Outline

● Project management

○ Manager duties

● Project planning

○ Software pricing, project scheduling, agile planning, estimation techniques

● People management

● Risk management

2
Software Project Management

● Coordinating and managing tasks and software engineers involved in a project

● Successful criteria for project management are

○ Deliver the software within agreed time

○ Keep overall costs of software and its development within budget

○ Deliver software that meets requirements specification

○ Maintain motivated, happy and well-functioning development team

3
Software management: managers’ duties

○ Planning:

■ Estimating costs and scheduling project development

■ Assign people to tasks

■ Monitor development progress and it is within agreed time and budget

■ Ensure work is carried out within standards

○ Reporting:

■ Report on the progress and write coherent document of critical information

○ Risk management:

■ Identify risk and assess them and then take actions when problems emerge

4
Software management: managers (cont.d)

○ People management:

■ Choose people to form teams

■ Identify ways of helping teams to lead to effective performance

○ Proposal writing (to win a contract to carry out an item of work):

■ Describe objectives and how they are carried out

■ Provide cost and schedule estimates with justifications

5
Project planning

● Project plan includes

○ Setting intermediate goals and milestones
○ Define tasks (breaking down problems into subproblems)
○ Scheduling tasks and estimate time and resources
■ Avoid delays by minimizing task dependencies

● The project management and plan must be documented in SPM

● There are tools support that facilitate project planning

○ Jira by atlassian, Smartsheet, Microsoft Project, Microsoft Planner,
Wrike, Nutcache 6
Project planning: ABHS example

● Consider developing software for Automated

Baggage Handling Systems
● Define milestones
○ Requirements specifications
○ System architecture and design (including
any subcomponents design)
○ Prototype 1: Baggage check-in
○ Prototype 2: Baggage routing
○ Prototype 3: Staff scheduling
○ Integrated System
● These milestones can have initial delivery
fixed dates

7
Project planning (cont.d)

● The plan, therefore, normally includes:

○ Introduction: description about the objectives and constraints (time,
budget)
○ Project organization: describe the arrangement of development
team and their roles
○ Risk analysis: identify risks and reduction strategies to manage them
○ Resource requirements: specifies the hardware and support
software required for development
○ Work breakdown: divide the work into activities and milestones
○ Project schedule: shows the dependencies between activities, the
estimate time of each milestone/deliverable, and people allocation
for each activity.
8
Project planning (cont.d)

● Typical project scheduling process

● Where possible, tasks should be self-contained (why?)

9
Project planning (cont.d)

● Example of a project schedule chart: T means task, and M means milestone

● You can also include people involved for each task. Eg. T3 (Mohammad,
Khalid, ...)

10
Project planning: estimation techniques

● There are two types of techniques can be used for effort estimation

1. Experience-based techniques: use manager’s experience of past

projects and application domains to predict the effort required.

● There are drawbacks of Experience-based techniques type:

○ Software project may not have much in common with previous
project
○ If strong experience unavailable, then, calculating effort
become hard and not accurate as possible.

11
Project planning: estimation techniques

2. Algorithmic cost modeling: formulaic approach to compute effort based on

estimates of project attributes: size, process characteristic, and the staff involved
(experience and skills).

● Algorithmic models for estimating effort in a software project are mostly

based on a simple formula:

Effort = A x SizeB x M, where:

● A: constant factor depends on organizational practices and type of software

● Size: either assessment of code size, functionality estimation, or application
points
● B: size and complexity of the system (lies between 1 and 1.5)
● M: multiplier of combining process, product and development attributes
(e.g., dependability requirements and experience of the development team)
12
Project planning: estimation techniques

● Nevertheless, initial estimation of any project are not 100% accurate

(why?)
○ Because no empirical data is available to make the estimation
○ The actual estimation was found vary by 0.25 to 4.00 of initial
estimates.
■ Eg. if initial estimation is x, then the actual estimation range
from 0.25x to 4x.
● Project estimation becomes more and more accurate as the project
progress.

13
Project planning: software pricing

● Software pricing is proposing to the customer the costs of completing the

project
○ Estimate of effort is requirement to complete each activity
○ Then, calculate the cost based on that and finally the price to the
customer
● There are parameters that should be use when calculating the costs
○ Effort costs
■ The costs of paying software engineers and managers
○ Hardware and software costs including maintenance
○ Travel and training cost

● Software pricing can be influenced by type of organization

○ economic, political, business, education, etc 14

Project planning: software pricing (cont.d)

● Thera are also other factors affecting software pricing:

○ Market opportunity
■ Quote a low price just to move into a new segment of the software
market, gain experience and to be known. Profit can be gained later.
○ Contractual terms:
■ Customer is willing to allow developing company to retain ownership
of the software code, that can be used later for similar kind of
applications.
○ Requirements volatility:
■ Requirements are likely to be changed, and therefore, you may propose
lower price at the start. Charge later when requirements change.
○ Financial health:
■ Developers may propose low price because financial difficulty.
15
● Cash flow is better than profit in financially bad times
People management

● Project manager should consider four factors in people management

○ Consistence: members should feel that their contributions are valued

fairly.

○ Respect: manager should respect everyone regardless of their diverse

skill-set

○ Inclusion: members should feel that others are listen to them and

appreciate their contribution whatsoever

○ Honesty: manager should always be honest

16
People management (cont.d)

● The successful manager ensures that the group

○ Works effectively

○ Has the resources needed

○ Is well-motivated

○ Has no misunderstanding

○ Group meets its goal

17
People management: teamwork

● Software is developed by project teams.

● Large software projects should not be tackled by a single large team (why?)

○ Risk of spent time in communication than development

○ Managing a single large team is hard: loose tracking of tasks and their completion

● Small programming teams (less than 10 members) have a number of benefits:

○ Less communication problems

○ Easy to form cohesive team
○ Quality standard can be developed
○ Members work together closely
○ Team members get to know each others
○ Refactoring and continual improvement can be easy encouraged

18
Team communication

● Team members who need a regular communication

○ Status meetings: know about the project’s

status and progress

○ At least on weekly basis

● All means of communication are recommended

○ On-site meetings are usually very effective

○ Alternative: email, virtual meetings,

telephones, formal documents ,etc.

19
Project management: meetings

● Group leader must organize successful meetings:

○ Meetings clear purpose and objective
○ Stick to the clear purpose: ensure no stray from objectives
○ Provide meeting agenda: list of issues to discuss
○ Time frame: meeting should starts and ends in defined times
○ Provide minutes: any decision made in the meeting should be
documented

● There are two types of meeting

○ Status meetings
○ Action meetings

20
Project management: status meetings

● Bring participants up-to-date on other peoples portions of the

project
○ A short status of report and circulate it

● Agenda should include written reports from people on the work

they are responsible for.
○ New business should be kept to a minimum. your individual
status report

● Status meetings are typically short: ten to fifteen minutes

○ So make sure everybody has read reports before meeting!

21
Project management: action meetings
1. Brainstorming session

○ Craft variety of possible solutions to a particular problem

○ Idea of one person often inspires ideas in other people
○ A group can produce more creative ideas than a single person
○ Don’t throw an idea away too soon
■ They may have good properties you want to exploit or stimulate other
ideas
○ People have to be encouraged to put their ideas forward:
■ Never dismiss or criticize a suggestion (until a separate evaluation phase
later)
■ Before starting a new idea of your own
● restate what the previous speaker said to their satisfaction.
● find at least one good thing to say about the previous idea.
○ At the end of a brainstorming session, the ideas must be evaluated 22
Project management: action meetings

2. Decision-making meetings

○ These meetings are fairly rare

○ Decision usually falls under one person’s area of authority and
there is no need to agree on something
○ Sometimes a decision is not clear-cut and the decision maker
wants suggestions or advice from those affected by the decision
○ A common type of decision-making meeting involves choosing
between several alternatives
○ Participants need to be familiar with the alternatives before the
meeting

23
Project Control

● Monitor the process and activities against the

plan
○ Take corrections when there is deviation
from plan
○ Realistic plan is important so that
corrections are minimum
○ Adding people into a behind schedule
project will delay it further (why?)

● It is usual that the project plan evolves as the project progress (why?)
○ Expect that time allocations are going to adjusted
■ Very important to keep accurate records of your time spent on tasks.
24
Risk management

● It involves anticipating risks that may affect the project schedule or the quality of
project
● There are three categories of risks (they can overlap):

○ Project related: affect schedule or resources.

■ Eg. essential hardware for the project will not be delivered on time

○ Product related: affect the quality or performance of the product

■ Eg. the size of the system has been underestimated (affect project and

product)

○ Business related: affect the organization developing the software

■ Eg. a competitive product is marketed before the current system is completed

25
Risk management (cont.d)

● Risk management process

26
Risk management: example 1

● Risk identification: organizational financial problems force reductions

in the project budget.

● Risk analysis:
■ Probability: very low, low, moderate, high, very high
■ Impact: catastrophic, serious, tolerable, insignificant

● Risk planning:
○ Prepare a briefing document for senior management showing how
the project is making a very important contribution to the goals of
the business and presenting reasons why cuts to the project budget
would not be cost-effective.

27
Risk management: example 2

● Risk identification: key staff is ill and unavailable at critical times in the
project

● Risk analysis:
■ Probability: very low, low, moderate, high, very high
■ Impact: catastrophic, serious, tolerable, insignificant

● Risk planning:
○ Reorganize team so that there is more overlap of work and people
therefore understand each other’s jobs.

28
Risk management: example 3

● Risk identification: it is hard to recruit staff with the required skill-set for
the project.

● Risk analysis:
■ Probability: very low, low, moderate, high, very high
■ Impact: catastrophic, serious, tolerable, insignificant

● Risk planning:
○ Alert customer to potential difficulties and the possibility of delays;
investigate buying-in components.

29