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
