Management of Software Engineering

1
Management of Software Engineering

• Dr. Mai Fadel

2
Introduction

• There are many engineers involved in the
  development of a software product gt
• There work must be coordinated and managed
• Define a project and have a manager
• Tasks of a project manger
• Planning
• Acquisition of resources space, computing
  resources, materials, and human resources
  (staffing)
• execution
• Monitoring
• Challenge making decisions on how best to use
  limited resources to achieve a set of independent
  and sometimes conflicting goals
• Plan the work and work the plan

3

• The managers faces many decisions that involve
  complicated trade-offs.
• Develop in-house compared with modifying a
  commercially available module
• Without clear cost model that delineates the
  economic impact of these decisions, there is no
  good way to choose among alternatives.
• There are a number of quantitative approaches to
  software cost estimation, cost modeling, and cost
  analysis have been proposed.
• They are far from being accurate (20-80)
• Useful
• Managers not only manage a single project but the
  overall organizations life cycle
• Evaluate the organization be comparing them with
  other competing organizations
• Assess the capabilities of the organization to
  improve it. Capability Maturity Model (CMM) used
  to assess the software development organization
  maturity and to implement an improvement strategy.

4
Management Functions

• The creation and maintenance of an internal
  environment in an enterprise where individually
  working together in groups, can perform
  efficiently and effectively toward the attainment
  of group goals
• Management interrelated activities
• Planning, organizing, staffing, directing, and
  controlling

5
Project Planning

• First step of software engineering management
  project
• Step 1Document assumptions, goals, and
  constraints of the project.
• The need for a clear statement of the goals
• Step 2 come up with a plan for how best to meet
  the requirements within given constraints
• What process model
• Determine the required resources (raw material is
  the human brainpower gt cost is proportional to
  the number of engineers) software cost
  estimation

6
Project Planning continued

• Forecasting how many engineers is difficult. It
  requires
• Estimating the difficulty of the problem
• Estimating how much of the task each engineer can
  accomplish
• Incomplete and imprecise requirements hinder
  accurate cost estimation
• Best approach is to develop resource requirements
  incrementally, revising current estimates as more
  information becomes available
• How long it will take an engineer to accomplish a
  given task is primarily a function of
• Complexity of the problem, engineers ability,
  the design of the software and the tools that are
  available (e.g. undo, parsing)

7
Planning 1- Software Productivity

• Management requirement measure the productivity
  of the people and processes involved in
  production
• Use it in planning to estimate cost, evaluate
  performance people, tools, processes
• We can be sure about improvements only if we can
  quantitatively measure productivity
• productivity metrics amount of functionality
  produced per unit of time
• Function Points
• Size of code
• Factors affecting productivity

8
Productivity Size of Code

• Source code is the most tangible part of software
  engineering
• Size of code as a productivity metric
• List of questions
• Should we count the comment lines?
• How many times should we count the lines in a
  file that is included several times? etc.
• Delivered Source Instructions (DSI)
• NonCommented Source Statements (NCSS)
• Generic Unit KLOC
• Problems
• A programmer who uses libraries or abstractions
  is penalized
• It is important to know what is counted in order
  to make accurate comparisons

9
Productivity Size of Code

• Consider when comparing the productivity figures
  reported by different organizations is whether
  the reported figures include the effect of
  canceled projects.
• Are the canceled projects counted in the overall
  productivity of the organization? Consistency
  must be maintained.
• When applying the Urban renewal principle the
  code will shrink? Does this engineer suddenly
  reduces the productivity of the entire
  organization?
• Lines of code are tied to procedural languages
  and are inherently incapable of dealing with the
  visual languages (using diagrams and screen
  panels rather than statements)
• Do not deal with declarative systems wherein
  programs are generated automatically

10
Productivity Factors affecting productivity

• These factors affects productivity regardless of
  the metric used
• By identifying the major contributors to
  productivity, organizations can determine
  quantitatively whether they can afford to change
  their practices whether the improvements in
  productivity are worth the costs associated with
  the required changes.
• New programming language, new development
  process, hiring an efficiency expert
• A study that uses LOC metric the Factors are
• Capability of the personal
• Complexity of the product (half as important)
• Required reliability and timing constraints
• (least) schedule constraints and previous
  experience with the language
• These factors are used in the cost estimation
  models

11
Productivity Factors affecting productivity

• Belief that aggressive schedule motivates a
  better, faster job
• Unrealistic aggressive schedules cause engineers
  to compromise on intangible aspects of quality
  and schedule delay
• Engineers are good achieving one tangible goals
  (if it is schedule then they achieve it by
  compromising documentation and structure)
• The fear about leaving engineers to work by
  themselves away from the guidance of headquarters
  turned out to be ill founded.
• Maybe because of the isolation from distractions
  from the many meetings (tradeoffs that manager
  should make)
• Intangible factors personnel turnover, canceled
  projects, reorganizations, and restructuring of
  systems for better quality.

12
Planning 2- People Productivity

• People are the source of producing high-quality
  software efficiently
• Engineering capability
• Common misconception held by managers (staffing,
  planning, and scheduling practices) software
  engineers are interchangeable
• Personalities of the members should be taken
• Because of the heavy interactions between teams
• Centrally controlled projects and decentralized
  control.
• Personal are not interchangeable due to technical
  ability and personality
• Negative management practice staffing a project
  with the best available people, rather than
  attempting to find the best people to
• Training period cost
• Solution schedule the training period as
  required, hire outside consultants

13
Planning 3- Cost Estimation

• It is part of the planning stage of any
  engineering activity
• Primary cost is for people
• Other engineering disciplines there is the cost
  of chips, bricks, and other material
• Two uses for cost estimation in s/w project
  management
• During the planning stage, deciding how many
  engineers are needed for the project and develop
  a schedule accordingly
• Monitoring the projects progress, assessing
  whether the project is progressing according to
  schedule, if not what corrective action
  (ascertain how much work has been accomplished,
  and how much is left to be done)
• Software work accomplishment metric.
• Halsteads metric is applied to an existing piece
  of software and can be used to compare such
  things as
• the complexity of two different programs or
• the relative benefits of two programming
  languages
• In the planning phase, we dont have the program
  gt cannot use any code-based metric to measure
  its inherent complexity
• Structure metrics and predictive methods
  (function points).

14
Predictive models of software cost

• If we can predict how large a software system was
  going to be before developing it, that size could
  be used as a basis for
• determining how much effort would be required,
• how many engineers would be needed, and
• how long it would take to develop the software
• It would be used to predict development and other
  stages of the software life cycle
• The size estimation derives the entire estimation
  process (e.g. size-gteffort)
• Computing an initial estimate of code size would
  be simpler if the organization maintains a
  database of information about past projects.

15
Predictive models of software cost

• The purpose of a software cost model is to
  predict the total development effort required to
  produce a given piece of software in terms of the
  number of engineers and length of time
• General formula used to arrive at the nominal
  development effort is
• PM initial c KLOCk
• To take into account the many variables that can
  affect the productivity of the project, cost
  drivers are used to scale the initial estimate of
  effort.
• e.g. if modern programming languages are used gt
  scale down
• Real-time reliability requirement gt scale up
• Cost drivers
• Product reliability, inherent complexity
• Computer are there execution time or storage
  constraints?
• Personal personal experience in the application
  area or the prog. Lang.?
• Project are sophisticated software tools being
  used?
• There are attributes in each class
• e.g. some models use object code for the size
  estimate, others use source code

16
Predictive models of software cost

• Basic steps for arriving at the cost of a
  proposed software system
• Estimate the softwares eventual size, and use it
  in the models formula to arrive at an initial
  estimate of effort
• Revise the estimate by using the cost driver or
  other scaling factors given by the model
• Apply the models tools to the estimate derived
  in step 2 to determine the total effort, activity
  distribution, etc.

17
COCOMO

• Construction Cost Model is a cost estimate model.
• Its general steps
• The code size estimate is based on KDSI
• Initial development effort based on projects
  development mode organic/semidetached/embedded
• Determining the mode, the corresponding formula
  is used to compute the initial effort estimate
• Table 8.3 and 8.4 can be considered as the
  quantitative summary of a considerable amount of
  experimental data collected by Boehm over the
  years
• e.g. flight control system -gtembedded class,
  payroll application-gt organic

18
COCOMO

• 2- the estimator determines the effort multiplier
  for the particular project based on cost-driver
  attributes.
• COCOMO uses 15 such attributes to scale the
  nominal development effort,
• Attributes listed in Table 8.5
• Multipliers show the impact of the factor how
  much control the manager has over it
• Product factors are in general fixed and not in
  the control of the manager
• The estimate of total effort The multiplier of
  each attribute are multiplied together x nominal
  effort derived

19
COCOMO

• 3- COCOMO allows the derivation of other
  important numbers and analyses.
• Table 8.4 the schedule column shows formulas, for
  deriving the length for the project schedule, on
  the basis of the estimate of the total effort for
  the project
• The model allows sensitivity analysis based on
  changing the parameters.
• e.g. modeling change in development time, impact
  of unstable hardware on project schedule
• Without such models we rely on judgments, which
  are hard to trust justify, cannot know if there
  is improvement
• They can help as validation against
  organizations project database
• Maintained database should store the progress of
  its projects
• These models are difficult to trust, but can
  complement the expert judgment and intuition

20
3- Project Control

• The purpose of controlling a project is to
  monitor the progress of the activities against
  the plans, in order to ensure that the goals are
  being approached and eventually achieved
• Decomposing work to decide which tasks need to be
  done
• Scheduling the order of tasks to be done is
  determined (Gantt charts PERT charts)
• Each work item is assigned with an activity to
  perform the item

21
4- Organization

• The organizing function of management deals with
  devising roles for individuals and assigning
  responsibility for accomplishing project goals
• Motivated by the need for cooperation when the
  goals are not achievable by a single individual
  in a reasonable time
• The aim of an organizational structure is to
  facilitate cooperation towards a common goal
• It helps in coordination between vice presidents
  and organize the interactions among programmers

22
Software development team organizations

• Team organization can be categorized according to
  where decision-making control lies.
• Centralized-control team organization
• several workers report to a supervisor who
  directly controls their tasks and responsible for
  their performance.
• hierarchal organizational structure
• (-) ve Communication through the
  supervisor, success depends on his skill and
  ability

23
Software development team organizations

• 2. Decentralized-control team organization
• decisions are made be consensus, and all
  work is considered group work.
• Team members review each others work and
  are responsible as a group for what every member
  produces
• ringlike management structure shows lack
  of hierarchy
• (-) ve communication overhead in large
  projects, engineers are overwhelmed
• Mixed-control team organization
• combines both modes
• control is vested in the project manager
  and senior programmers
• communication is decentralized among each
  set of individuals, peers, and their immediate
  supervisors

24
(No Transcript)