CS359 SOFTWARE ENGINEERING

Ch3-Managing Software Project

Prepared by:
Ms. Bela Shah
Assistant Professor,
Department of Computer
Science & Engineering

11/23/2021 1
Introduction

• Many software projects fail

 due to faulty project
management practices
It is important to learn different
aspects of software project
management.

2
 Introduction
• Goal of software project management

• Enable a group of engineers to work efficiently towards

successful completion of a software project

3
Project Management Concepts
 Project, Defined
• A project is an endeavor to accomplish a specific objective through a unique set of interrelated tasks
and the effective utilization of resources.
• It has a well-defined objective stated in terms of scope, schedule, and costs.
• Project s are “born” when a need is identified by the customer – the people or organization willing
to provide funds to have the need satisfied.
• It is the people (project manager and project team), not the procedures and techniques, that are critical
to accomplishing the project objective.
• Procedures and techniques are merely tools to help the people do their jobs.
 Examples of Projects
• Planning a wedding
• Designing and implementing a computer system
• Hosting a holiday party
• Designing and producing a brochure
• Executing an environmental clean-up of a contaminated site
• Holding a high school reunion
• Performing a series of surgeries on an accident victim
Phases of the Project Life
Cycle 1
• The first phase involves the identification of a need, problem, or
opportunity.
• The need and requirements are usually written by the customer into a
document
called a request for proposal (RFP).
Phases of the Project Life
Cycle 2
• The second phase is the development of a
proposed solution to the need or problem.
• This phase results in the submission of a
proposal.
• The customer and the winning contractor negotiate
and sign a contract (agreement).
Phases of the Project Life
Cycle 3
• The third phase is performing the project.
• Different types of resources are utilized

• Results in the accomplishment of the project objective

Phases of the Project Life
Cycle 4
• The final phase is terminating the project.
• Perform close-out activities

• Evaluate performance

• Invite customer feedback

 The Project Management Process
• The project management process means planning the work and then working the plan.
• 7 steps of planning
1. Clearly define the project objective.
2. Divide and subdivide the project scope into major “pieces”
3. Define the specific activities for each piece (work package)
4. Graphically portray the activities that need to be performed fro each work
package in order to accomplish the project objective – in the form of network diagram.
5. Make a time estimate for how long it will take to complete each activity – resources needed.
6. Make a cost estimate for each activity.
7. Calculate a project schedule and budget to determine whether the project can
be completed within the required time, with the allotted founds, and with the available
resources.
Responsibility of project managers
 Project proposal writing
 Project cost estimation
 Scheduling
 Project staffing
 Project monitoring and control
 Software configuration management
 Risk management
Managerial report writing and
presentations etc.

14
• A project manager’s activities are
varied.
• can be broadly classified into:
• project planning
• project monitoring and control activities.

15
 Project Planning
• Once a project is found to be feasible
Project managers undertake project planning

17
 Work Breakdown Structure (WBS)
• The second step is to determine what activities need to be
performed.
• A list of all the activities must be developed.
• The WBS is a hierarchical tree of end items to be
accomplished.
• A work item is one small piece of the project.
• A work package is the lowest-level item.
Project Planning Activities

• Estimation:
• Effort, cost, resource, and project duration
• Project scheduling
• Staff organization
• staffing plans
• Risk handling
• identification, analysis, and abatement procedures
• Miscellaneous plans
• quality assurance plan, configuration management
plan, etc.

20
 Project planning
• Requires utmost care and attention --- commitments to unrealistic
time and resource estimates result in:
• Irritating delays
• Customer dissatisfaction
• Adverse affect on team morale
• poor quality work
• Project failure

21
 SPMP Document

• After planning is complete:

•
Document the plans in a Software
Project Management Plan(SPMP)
document.

22
 Organization of SPMP Document

• Introduction (Objectives,Major Functions,Performance Issues,Management and Technical Constraints)

• Project Estimates (Historical Data,Estimation Techniques,Effort, Cost, and Project Duration Estimates)
• Project Resources Plan (People,Hardware and Software,Special Resources)
• Schedules (Work Breakdown Structure,Task Network, Gantt Chart Representation,PERT Chart Representation)
• Risk Management Plan (Risk Analysis,Risk Identification,Risk Estimation, Abatement Procedures)
• Project Tracking and Control Plan
• Miscellaneous Plans(Process Tailoring,Quality Assurance)

23
 Software Cost Estimation
• Determine size of the product
• From the size estimate,
• determine the effort needed.
• From the effort estimate,
• determine project duration, and cost.

25
Software Cost
Estimation
Effort Cost
Estimation Estimation

Size Staffing
Estimation Estimation

Duration
Estimation Scheduling

26
Software Metrics
Terminologies

 Measure: Quantitative indication of the extent, amount, dimension, or size of some attribute of a product or
process.
 Metrics: The degree to which a system, component, or process possesses a given attribute. Relates several
measures
 (e.g. average number of errors found per person hour)
 Indicators: A combination of metrics that provides insight into the software process, project or product
 Direct Metrics: Immediately measurable attributes (e.g. line of code, execution speed, defects reported)
 Indirect Metrics: Aspects that are not immediately quantifiable (e.g. functionality, quantity, reliability)
 Faults:
 Errors: Faults found by the practitioners during software development
 Defects: Faults found by the customers after release

27
Metric Classification
 Processes
Activities related to production of software
 Products
Explicit results of software development activities.
Deliverables, documentation, by products
 Project
Inputs into the software development activities
hardware, knowledge, people

28
Software Measurement
 Direct Measures (internal attributes)
Cost, effort, LOC, speed, memory
 Indirect Measures (external
attributes)
Functionality, quality, complexity,
efficiency, reliability,
maintainability

29
Size Oriented metrics
 Size-oriented software metrics are derived by normalizing quality and/or
productivity measures by considering the size of the software that has
been produced.
simple size-oriented metrics for each project:
 Errors per KLOC (thousand lines of code)
 Defects per KLOC
 $ per KLOC
 Pages of documentation per KLOC
 Errors per person-month
 KLOC per person-month
 $ per page of documentation

30
Function-Oriented metrics

• Function-oriented software metrics use a measure of the functionality delivered by the

application as a normalization value.
• The most widely used function-oriented metric is the function point (FP).
• Computation of the function point is based on characteristics of the
software’s
information domain and complexity.

31
 Software Cost Estimation
• Three main approaches to estimation:
• Empirical
• Heuristic
• Analytical

32
 Software Cost Estimation Techniques

• Empirical techniques:
• an educated guess based on past experience.
• Heuristic techniques:
• assume that the characteristics to be estimated can be expressed in terms of
some mathematical expression.
• Analytical techniques:
• derive the required results starting from certain simple assumptions.

33
 Empirical Size Estimation
Techniques
• Expert Judgement:
• An euphemism for guess made by an expert.
• Suffers from individual bias.
• Delphi Estimation:
• overcomes some of the problems of expert
judgement.

34
 Expert judgement

• Experts divide a software product into component

units:
• e.g. GUI, database module, data communication
module, billing module, etc.
• Add up the guesses for each of the components.

35
 Delphi Estimation:

• Team of Experts and a coordinator.

• Experts carry out estimation independently:
• mention the rationale behind their estimation.
• coordinator notes down any extraordinary rationale:
• circulates among experts.

36
 Delphi Estimation:

• Experts re-estimate.
• Experts never meet each other to discuss their
viewpoints.

37
Heuristic Estimation Techniques

• Single Variable Model:

• Parameter to be Estimated=C1(Estimated
Characteristic)d1
• Multivariable Model:
• Assumes that the parameter to be
estimated depends on more than
one characteristic.
• Parameter to be Estimated=C1(Estimated
Characteristic)d1+ C2(Estimated
Characteristic)d2+…
• Usually more accurate than single
variable models.
38
 Software Size Metrics

• LOC (Lines of Code):

• Simplest and most widely used metric.
• Comments and blank lines should not be counted.

39
 Disadvantages of Using LOC

• Size can vary with coding style.

• Focuses on coding activity alone.
• Correlates poorly with quality and efficiency of
code.
• Penalizes higher level programming languages,
code reuse, etc.

40
 Disadvantages of Using LOC (cont...)

• Measures lexical/textual complexity only.

• does not address the issues of structural or logical
complexity.
• Difficult to estimate LOC from problem
description.
• So not useful for project planning

41
 Function Point Metric
• Overcomes some of the shortcomings of the LOC metric
• Proposed by Albrecht in early 80's:
• FP=4 #inputs + 5 #Outputs + 4 #inquiries #files + 10 #interfaces
+ 10
• Input:
• A set of related inputs is counted as one input.

42
Function Point Metric
• Output:
• A set of related outputs is counted as one output.
• Inquiries:
• Each user query type is counted.
• Files:
• Files are logically related data and thus can be data
structures or physical files.
• Interface:
• Data transfer to other systems.

43
 Function Point Metric (CONT.)

• Suffers from a major drawback:

• the size of a function is considered to be independent of its
complexity.
• Extend function point metric:
• Feature Point metric:
• considers an extra parameter:
• Algorithm Complexity.

44
 Function Point Metric
(CONT.)

• Proponents claim:
• FP is language independent.
• Size can be easily derived from problem description
• Opponents claim:
• it is subjective --- Different people can come up with
different estimates for the same problem.

45
FUNCTION POINT
FP CALCULATION
HOW TO CALCULATE?
EXAMPLE
50
SOLVE……..
SOLUTION:
 COCOMO Model
• COCOMO (COnstructive COst MOdel) proposed by
Boehm.
• Divides software product developments into 3
categories:
• Organic
• Semidetached
• Embedded

46
Elaboration of Product
classes
• Organic:
• Relatively small groups
• working to develop well-understood applications.
• Semidetached:
• Project team consists of a mixture of experienced and
inexperienced staff.
• Embedded:
• The software is strongly coupled to complex hardware,
or real-time systems.

47
COCOMO Product
classes
• Roughly correspond to:
• application, utility and system programs
respectively.
• Data processing and scientific programs are
considered to be application programs.
• Compilers, linkers, editors, etc., are utility
programs.
• Operating systems and real-time system
programs, etc. are system programs.

48
 COCOMO Model
(CONT.)

• For each of the three product categories:

• From size estimation (in KLOC), Boehm provides equations to predict:
• project duration in months
• effort in programmer-months
• Boehm obtained these equations:
• examined historical data collected from a large number of actual
projects.

49
 COCOMO Model
(CONT.)

• Software cost estimation is done through three

stages:
• Basic COCOMO,
• Intermediate COCOMO,
• Complete COCOMO.

50
Basic COCOMO Model
(CONT.)

• Gives only an approximate estimation:

• Effort = a1 * (KLOC)^a2
• Tdev = b1 * (Effort)^b2
• KLOC is the estimated kilo lines of
source code,
• a1,a2,b1,b2 are constants for different
categories of software products,
• Tdev is the estimated time to develop the
software in months,
• Effort estimation is obtained in
terms of person months (PMs).
51
 Development Effort
Estimation
• Organic :
• Effort = 2.4 (KLOC)^1.05 PM
• Semi-detached:
• Effort = 3.0(KLOC)^1.12 PM
• Embedded:
• Effort = 3.6 (KLOC)^1.20PM

52
 Development Time
Estimation
• Organic:
• Tdev = 2.5 (Effort)^0.38 Months
• Semi-detached:
• Tdev = 2.5 (Effort)^0.35 Months
• Embedded:
• Tdev = 2.5 (Effort)^0.32 Months

53
 Example
• The size of an organic software product has been estimated to
be 32,000 lines of source code.

• Effort = 2.4*(32)^1.05 = 91 PM
• Nominal development time = 2.5*(91)^0.38 = 14 months

54
Cocomo merits and demerits
Project
scheduling
• Project Scheduling
• Software project scheduling is an action that distributes estimated effort across the
planned project duration by allocating the effort to specific software engineering tasks.
• It is important to note, however, that the schedule evolves over time.
• During early stages of project planning, a macroscopic schedule is developed.
• This type of schedule identifies all major process framework activities and the product
functions to which they are applied.

55
Project planning
processEstablish the project constraints
Make initial assessments of the project parameters
Define project milestones and deliverables
w hile proj ect has not been completed or cancelledloop
Draw up project schedule
Initiate activities according to schedule Wait
( for a while )
Review project progress
Revise estimates of project parameters
Update the project schedule
Re-negotiate project constraints and
deliverables
if ( problems arise )the n
Initiate technical review and possible
revision
e nd
if e nd
loop
56
Project plan
structure
• Introduction
• Project organisation
• Risk analysis
• Hardware and software resource requirements
• Work breakdown
• Project schedule
• Monitoring and reporting mechanisms

57
Activity
organization
• Activities in a project should be organised to produce tangible
outputs for management to judge progress
• Milestones are the end-point of a process activity
• Deliverables are project results delivered to customers
• The waterfall process allows for the straightforward definition of
progress milestones

58
Milestones in the
process
ACTIVITIES

Feasibilit Requir Prototype Desig Requir

y study ements developme n ements
analysis nt study specification

Feasibilit Requir Evaluatio Architectura Requir

y ements n l design ements
report definition report specification

MILESTONE
S

59
Project
scheduling
• Split project into activities and activities into tasks and estimate time
and resources required to complete each task
• Organize tasks concurrently to make optimal
use of workforce
• Minimize task dependencies to avoid delays
caused by one task waiting for another to complete
• Dependent on project managers intuition and
experience

60
The project scheduling
process

Identify Identify activity Estimate resources Allocate people Create project

activitie dependencies for activities to activities charts
s

Software Activity charts

requirement and bar
s charts

61
Scheduling
problems
• Estimating the difficulty of problems and hence the cost of
developing a solution is hard
• Productivity is not proportional to the number of people working on a
task
• Adding people to a late project makes it later because of
communication overheads
• The unexpected always happens. Always allow contingency in
planning

62
Bar charts and activity
networks
• Graphical notations used to illustrate the project schedule
• Show project breakdown into tasks. Tasks should not be too small.
They should take about a week or two
• Activity charts show task dependencies and the the critical path
• Bar charts show schedule against calendar time

63
Task durations and
dependencies
Task Duration (days) Dependencies
T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)
64
Activity
network 12/7/1
9
15
days 15 days
M1 T3
8 days T
9
T1 5 2/77//71 12/8/1
25/7/ 19 days 9 9
T6 M4 M6
4/7/1
9 M3
start 20 days 7 days
15
days T7 T11
T2

1/9/7/ 10 days 29/7/1 1/998

10 days
19 9 19
M7 M8
T4 T5 15 days
M2
T10 10
14/7/1
days
9 T12
M5
25 days
T8 Finis
19 /8/19 h

65
Activity
timeline 4/7
7
11/7
Start
18/ 25/ 7 1/8 8/8 15/ 8 22/ 8 29/ 8 5/9
9
12/ 19/ 9

T4
T1
T2
M
1
T7
T3
M5
T8
M
3
M
2
M4
T
T9
6
M7
T T 10
5 M6
T 11
M8
T 12
Fin ish
66
Staff
allocation 4/7 11/7 25/ 1/8 8/8 22/8 29/8 12/9 19/
18/7 15/8 5/9 9
Fre
d T4 T8 T11
T12
Jane T1
T3
T9
Anne
T2 T6 T10

Jim T7

Ma T5
ry
67
Project
Tracking
• Project Tracking
• The project schedule provides a road map for a software project manager.
• It defines the tasks and milestones.
• Several ways to track a project schedule:
• conducting periodic project status meeting
• evaluating the review results in the software process
• determine if formal project milestones have been accomplished
• compare actual start date to planned start date for each task
• informal meeting with practitioners
• Project manager takes the control of the schedule in the aspects of:
• project staffing
• project problems
• project resources
• reviews
• project budget

68
Risk
Management
• Risk Management
• A risk is a potential problem – it might happen and it might not
• Conceptual definition of risk
• Risk concerns future happenings
• Risk involves change in mind, opinion, actions, places, etc.
• Risk involves choice and the uncertainty that choice entails
• Two characteristics of risk
• Uncertainty – the risk may or may not happen, that is, there are no 100% risks (those, instead, are called constraints)
• Loss – the risk becomes a reality and unwanted consequences or losses occur

70
 Categories of risk
• Project risks
• They threaten the project plan
• If they become real, it is likely that the project schedule will slip and that costs will increase
• Technical risks
• They threaten the quality and timeliness of the software to be produced
• If they become real, implementation may become difficult or impossible
• Business risks
• They threaten the feasibility of the software to be built
• If they become real, they threaten the project or the product
• Known risks
• Those risks that can be uncovered after careful evaluation of the project plan, the business and technical environment in which
the
project is being developed, and other reliable information sources (e.g., unrealistic delivery date)
• Predictable risks
• Those risks that are deduced from past project experience (e.g., past turnover)
• Unpredictable risks
• Those risks that can and do occur, but are extremely difficult to identify in advance

71
• Sub-Categories of risk
• Market risk – building an excellent product or system that no one really wants
• Strategic risk – building a product that no longer fits into the overall business strategy for the company
• Sales risk – building a product that the sales force doesn't understand how to sell
• Management risk – losing the support of senior management due to a change in focus or a change in
people
• Budget risk – losing budgetary or personnel commitment

72
Risk
management
• Risk management is concerned with identifying risks and drawing up
plans to minimise their effect on a project.
• A risk is a probability that some adverse circumstance will occur.
• Project risks affect schedule or resources
• Product risks affect the quality or performance of the software being
developed
• Business risks affect the organisation developing or procuring the
software

73
Software
risks
Risk R i s k type Description
Staff turnover P roject Experienced staff will leave t he
projec t before it is finished.
M ana gem e nt change P roject There will be a ch an ge of
organisational managem ent with
different priorities.
Hardware unavailability P roject Hardware which is essential for the
projec t will n ot be delivered on
schedule.
Requirements change Project and There will be a larger number of
product changes to the requirements than
anticipated.
Specification delays Project and Specifications of essential interfaces
product are not available o n schedule
Size underestimate Project and Th e size of the system has been
product underestimated.
CAS E tool under- Product CAS E tools w h i ch support the
perform ance projec t do not perform as anticipated
Technology change B us i nes s Th e underlying technology o n which
the system is built is superseded by
n e w technology.
Product competition B us i nes s A competitive product is marketed
before the system is completed.

74
The risk management
process
• Risk identification
• Identify project, product and business risks
• Risk analysis
• Assess the likelihood and consequences of these risks
• Risk planning
• Draw up plans to avoid or minimise the effects of the risk
• Risk monitoring
• Monitor the risks throughout the project

75
The risk management
process

Risk Risk analysis Risk Risk

identificatio monitorin
planning
n g

List of Risk avoidance Risk

Prioritised and contingency
potential risk list assessmen
risks plans t

76
Risk
identification
• Technology risks
• People risks
• Organisational risks
• Requirements risks
• Estimation risks

77
Risks and risk
types Risk type Possible risks
Technology The database used in the system canno t process as many
transactions per second as expected.
Software components wh ich should be reused contain
defects which limit their functionality.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unava ilable at critical times.
Requi red training for staff is not av ailable.
Organ The organ isation is restructured so that different manag
isational ement are respons ible for the project.
Organ isational financial problems force reduc tions in the
project budge t.
Tools The code generated by CASE tools is
inefficient. CASE tools canno t be integrated.
Requi Changes to requirements which require major design rework are
rements proposed.
Customers fail to unde rstand the impact of requirements
chang es.
Estimation The time required to deve lop the software is unde
restimated. The rate of defect repair is underestimated.
The size of the software is unde restimated.

78
Risk
analysis
• Assess probability and seriousness of each risk
• Probability may be very low, low, moderate, high or very high
• Risk effects might be catastrophic, serious, tolerable or insignificant

79
Risk
analysis
Risk P robabi li t y Effe c ts
Orga ni sa ti ona l financial p r o bl e m s force r e duct ions in the Low Cat astr ophic
project budge t.
It is im possi ble to recruit staff wit h the skills re quir e d for the High Cat astr ophic
project.
K e y staff a re ill at critical t ime s in t he project. Moderate Se r ious
Sof t wa r e c o m p o n e n t s wh i c h shoul d b e re used c onta in defects Moderate Se r ious
wh i c h limit their functionality.
C h a n g e s to r e quir e me nts wh i c h re quire m a j or de sign Moderate Se r ious
r e w or k ar e p r op os e d .
T h e organisa tion is re structured so that different m a n a g e m e n t High Se r ious
ar e r e sponsible for the project.
T h e da ta ba se us e d in the syst e m c a nno t pr oc e ss a s m a n y Moderate Se r ious
transac tions pe r s e c on d as e xpec t ed.
T h e ti m e r equir ed to d e v e l op the soft wa re is under esti ma te d. High Se r ious
C A S E tools ca nnot b e integrated. High Tol e r a bl e
C u st o m e r s fail to unde r st a nd the i mpa c t of re quir eme nt s Moderate Tol e r a bl e
c hange s.
R e qu i r e d training for staff is not available. Moderate Tol e r a bl e
T h e rate of defect repair is under estim at ed. Moderate Tol e r a bl e
T h e size of the soft wa re is unde re st ima te d. High Tol e r a bl e
T h e c o d e ge ne r at ed b y C A S E tools is inefficient. Moderate Insignificant

80
Risk management
strategies
Risk Strategy
Organisational Prepare a briefing document for senior management showing how the
financial problems project is making a very important contribution to the goals of the business.
Recruitment problems Alert customer of potential difficulties and the possibility of delays,
investigate buying-in components.
Staff illness Reorganise team so that there is more overlap of work and people therefore
understand each other’s jobs.
Defective components Replace potentially defective components with bought-in components of
known reliability.
Requirements changes Derive traceability information to assess requirements change impact,
maximise information hiding in the design.
Organisational Prepare a briefing document for senior management showing how the
restructuring project is making a very important contribution to the goals of the business.
Database performance Investigate the possibility of buying a higher-performance database.
Underestimated Investigate buying in components, investigate use of a program generator.
development time

81
Risk
monitoring
• Assess each identified risks regularly to decide whether or not it is
becoming less or more probable

• Also assess whether the effects of the risk have changed

• Each key risk should be discussed at management progress

meetings

82
Risk
factorsRisk type Potential indicators
Technology Late delivery of hardwa re or support software,
many reported technology problems
People Poor staff morale, poor relationships amongst team
member, job availability
Organ organ isational gossip, lack of action by senior
isational manage ment
Tools reluctance by team members to use tools, complaints
abou t CASE tools, de mand s for highe r-powe red
workstations
Requi many requirements chang e reque sts, customer
rements complaints
Estimation failure to meet ag reed schedul e, failure to
clear reported defects

83
Risk Management
Tasks
RISK
IDENTIFICATION
RISK ASSESSMENT RISK ANALYSIS

RISK PRIORITIZATION
RISK
MANAGEMENT RISK MANAGEMENT
PLANNING

RISK CONTROL RISK RESOLUTION

RISK MONITORING

84
Top Risk
Examples
• Shortage of technically trained manpower
• Too many requirement changes
• Unclear requirements
• Not meeting performance requirements
• Unrealistic schedules
• Insufficient business knowledge
• Working on new technology

85
 Risk Mitigation, Monitoring, and Management

• Risk mitigation (proactive planning for risk avoidance)

• Risk monitoring (assessing whether predicted risks occur or not, ensuring risk aversion steps are being properly applied, collect information for future risk
analysis, attempt to determine which risks caused which problems)
• Risk management and contingency planning (actions to be taken in the event that mitigation steps have failed and the risk has become a live problem)
• The goal of the risk mitigation, monitoring and management plan is to identify as many potential risks as possible.
• When all risks have been identified, they will then be evaluated to determine their probability of occurrence,
• Plans will then be made to avoid each risk, to track each risk to determine if it is more or less likely to occur, and to plan for those risks should they occur.
• It is the organization’s responsibility to perform risk mitigation, monitoring, and management in order to produce a quality product.
• The quicker the risks can be identified and avoided, the smaller the chances of having to face that particular risk’s consequence.
• The fewer consequences suffered as a result of good RMMM plan, the better the product, and the smoother the development process.

86
 Team structure

11/23/2021 U & P U. Patel Department of Computer Engineering, CSPIT, 87

 Organization Structure

1 Functional Organization:
• Engineers are organized into functional groups, e.g.
• specification, design, coding, testing, maintenance, etc.
• Engineers from functional groups get assigned to different
projects

88
 Advantages of Functional Organization

• Specialization
• Ease of staffing
• Good documentation is produced
• different phases are carried out by different teams of
engineers.
• Helps identify errors earlier.

89
 2-Project Organization

• Engineers get assigned to a project for the entire

duration of the project
• Same set of engineers carry out all the phases
• Advantages:
• Engineers save time on learning details of every
project.
• Leads to job rotation

90
 Team Structure
• Problems of different complexities and sizes
require different team structures:
• Chief-programmer team
• Democratic team
• Mixed organization

91
Team Organization

Democratic Team
Chief Programmer team

92
Mixed team
organization

93
Democratic Teams

• Suitable for:
• small projects requiring less than five or
six engineers
• research-oriented projects
• A manager provides
administrative leadership:
• at different times different members of
the group provide technical
leadership.
94
 Democratic Teams
• Democratic organization provides
• higher morale and job satisfaction to the engineers
• therefore leads to less employee turnover.
• Suitable for less understood problems,
• a group of engineers can invent better solutions than a single individual.

95
Democratic Teams

• Disadvantage:
• team members may waste a
lot time arguing about trivial
points:
• absence of any authority in the
team.

96
 Chief Programmer
Team
• A senior engineer provides technical
leadership:
• partitions the task among the team
members.
• verifies and integrates the products developed by
the members.

97
Chief Programmer
Team
• Works well when
• the task is well understood
• also within the intellectual grasp of a single
individual,
• importance of early completion
outweighs other factors
• team morale, personal
development, etc.

98
 Chief Programmer
Team
• Chief programmer team is subject to single point
failure:
• too much responsibility and authority is assigned to the
chief programmer.

99
Mixed Control
Team Organization
• Draws upon ideas from both:
• democratic organization and
• chief-programmer team organization.
• Communication is limited
• to a small group that is most likely to benefit from it.
• Suitable for large organizations.

100
Team
Structure
• To assign tasks in detailed schedule, need to have a clear team
structure
• Hierarchic team org is most common
• Project manager has overall responsibility; also does design etc.
• Has programmers and testers for executing detailed tasks
• May have config controller, db manager, etc

101
Team
structure..
• An alternative – democratic teams
• Can work for small teams; leadership rotates
• Another one used for products
• A dev team led by a dev mgr, a test team led by test mgr, and a prog. Mgmt
team
• All three report to a product mgr
• Allows specialization of tasks and separate career ladders for devs, tests,
PMs

102
SCM process and
planning
• Have discussed SCM process earlier
• During planning, the SCM activities are planned along with who will
perform them
• Have discussed planning also earlier
• Includes defining CM items, naming scheme, directory structure, access
restrictions, change control, versioning, release procedure etc

103
 Last Lec
Summary
• Team:
• Functional Organization
• Project Organization

• Team structure:
• Chief-programmer team
• Democratic team
• Mixed organization

• SCM

11/23/2021 U & P U. Patel Department of Computer Engineering, CSPIT, 104

U & P U. Patel Department of Computer Engineering

Quality Planning

105
Quality
Planning
• Delivering high quality is a basic goal
• Quality can be defined in many ways
• Current industry standard - delivered defect density (e.g.
#defects/KLOC)
• Defect - something that causes software to behave in an inconsistent
manner
• Aim of a project - deliver software with low delivered defect density

106
Defect Injection and
Removal
• Software development is labor intensive
• Defects are injected at any stage
• As quality goal is low delivered defect density, these defects have to be
removed
• Done primarily by quality control (QC) activities of reviews and
testing

107
Defect Injection and
Removal
Def ect Injection

Development
Process

Req. R Design R Coding R UT IT/ST AT

Analysis

Def ect Removal

108
Approaches to Quality
Management
• Ad hoc - some testing, some reviews done as and when needed
• Procedural - defined procedures are followed in a project
• Quantitative - defect data analysis done to manage the quality
process

109
Procedural
Approach
• A quality plan defines what QC tasks will be undertaken and when
• Main QC tasks - reviews and testing
• Guidelines and procedures for reviews and testing are provided
• During project execution, adherence to the plan and procedures
ensured

110
Quantitative
Approach
• Goes beyond asking “has the procedure been
executed”
• Analyzes defect data to make judgements about
quality
• Past data is very important
• Key parameters - defect injection and removal
rates, defect removal efficiency (DRE)

111
Quality
Plan
• The quality plan drives the quality activities in the project
• Level of plan depends on models available
• Must define QC tasks that have to be performed in the project
• Can specify defect levels for each QC tasks (if models and data
available)

112