Illinois Institute of Technology

1
Illinois Institute of Technology

• CS487
• Software Engineering
• David A. Lash

2
Project Elements

• The planning monitoring control of people,
  process and event as software evolves
• 2-4 developers working together may not need much
  but ... What about 30-40, 300?
• Organized customer communication, right
  development process, estimated effort, quality
  checkpoints, on-going monitoring of tasks
• Output is project plan with set(s) of tasks.
• Manage, People, Product, Process and Project

3
Problem

• What is the appropriate level of rigor?
• What, if any, standards apply?
• Software Scope
• Context.
• How does this item fit into a larger picture
• Information objective.
• What is the customer going to see.
• Function and performance.
• How is the software going to process the
  information.

4
People

• All people who work in the development process
  are not interchangeable.
• Many people find it objectionable to be called a
  resource.
• Any time there are more than 1 person working to
  solve a problem, an organization is recommended

5
Development Team

• What is teamwork?
• Joint action by a group of people, in which
  individual interests are subordinated to group
  unity and efficiency coordinated effort, as of
  an athletic team.
• Team size about 4 people. Requires minimal
  training for the leader.
• Each individual should have a unique primary
  function i.e. leader, librarian, developer,
  tester.
• Periodically switch functions to cross train.

6
Development Team Organization

• Democratic decentralized no traditional leader.
  Works best when the average experience is 15
  years . Consensus decisions
• Controlled decentralized a defined leader with
  secondary leaders. Multiple teams.
• Controlled Centralized Managed by a team
  leader. Good for a cross section of people. Lead
  gets top-level decisions and internal coordination

7
Process

• Selecting the right process?
• Waterfall Traditional

8
Process

• Incremental Solves a number of problems
• Spiral Must be adopted at the enterprise level.

9
How do you evaluate process?

• Are you using the process correctly?
• Are you using the correct process?
• What can you do better?

10
Capability Maturity Model

• Developed and controlled by the Software
  Engineering Institute (SEI)
• What is the CMM?
• Arbitrary
• Not a process
• Develop for the DOD to evaluate software
  contractors.
• Being adopted by a number of regulators.
• Defines activities that should be going on.
• Arranged to make easy to progress through the 5
  levels.

11
CMM - Review

• 1. Chaotic - Productivity and Quality are based
  on individual effort. No control
• 2. Repeatable - Requirements Management, Project
  Planning, Quality Assurance, Configuration
  Management, Subcontractor management
• 3. Defined - Organization Process Focus,
  Organization Process Definition, Training Program
• 4. Managed - Quantitative Process Management,
  Software Quality Management
• 5. Optimizing - Defect Prevention, Technology
  change management, Process change management

12
Project Planning

• What are the tasks necessary for this project?
• How do these tasks relate to each other?
• Planning and scheduling are different
• Planning defines the tasks, personnel and
  equipment necessary to deliver the product.
• To determine personnel requirements you must
  estimate the size of each task.
• Planning is done at the beginning of the project
  when you know the least about the problem

13
Estimating

• How long is the project going to take?
• First, how long is are the tasks going to take?

14
Estimating

• Done early in the process high degree of error
• Can only accurately estimate the next step.
• Must re-plan at the beginning of each phase.
• Establish size metric.
• Estimation requires
• Experience building this specific application
• Knowledge of the Environment
• History of similar projects

15
General Estimation Formula
Where E is one person effort A, B and C are
empirically derived constants EV is an
estimation of some measure of size The values of
A B are calibrated for local environment using
regression analysis and real data.
16
Three-point

• Three-point or expected value
• Where
• Sopt - Optimistic Estimate
• Sm - Most-likely Estimate
• Spess - Pessimistic Estimate
• EV - Estimation Variable

17
Three-point

• For example, assume to build a software module.
  Have some LOC estimates
• optimistic - 4600
• most likely - 6900
• pessimistic - 8600
• (4600 69004 8600)/6 6800
• Can also be useful for time to complete

18
Function Points

• Good method for IT projects. Use Feature Points
  for embedded and systems projects
• An estimation technique that uses the types of
  I/O for a problem to determine the size of the
  project
• Called an early measure of size
• Function Points convert directly to KLOC

19
Function Points

• Method
• Count of Information elements
• Input files
• Output files
• Inquiry transactions
• Logical files
• External interfaces
• Total complexity factors

20
Function Point Counting
21
Function Points Calculation

• Where - FP unadjusted previous
  calculation - Fi sum of complexity
  adjustment values based on
  subjective ratings from 0-5 on 14
  complexity items - 0 - no
  influence - 1 - incidental - 2 -
  moderate - 3 - average - 4 -
  significant - 5 - Essential

22
Complexity Factors
23
Complexity Factors
24
COCOMO Estimation

• COnstructive COst Model - BB89 COCOMO II BB96
• Uses function points, KLOC or object points (A BB
  funct PT like metrics with different elements)
• A hierarchy of estimation models for prototype,
  requirements established and post-architecture
  stages
• Basic - Compute development effort as a function
  of size in KLOC
• Intermediate - Compute development effort as a
  function of size and cost drivers (HW, people)
• Advanced - Intermediate version plus assessment
  of cost driver impact on each step (e.g.,
  analysis design, architecture)

25
COCOMO Project Types

• Organic
• In-house development
• Small teams with extensive application experience
• Characteristics
• Stable development environment
• Minimal need for innovative data processing
• Low premium on early completion

26
COCOMO Project Types

• Semidetached
• One of two types of projects
• 1. An intermediate level of the project
• 2. A mixture of the organic and embedded
• Characteristics
• Team members have an intermediate level of
  experience
• Team has a wide mixture of experienced and
  inexperienced people
• Team members have experience related to some
  aspects of the system under development, but not
  others

27
COCOMO Project Types

• Embedded
• Not limited to our current definition of embedded
  meaning firmware, but also includes large scale
  turn-key system
• A major distinguishing factor is a need to
  operate within tight constraints
• Require a high degree of rigor

28
COCOMO Basic
Where
E Effort in person months D Chronological
months
29
COCOMO Basic
30
COCOMO Intermediate
31
COCOMO Intermediate
Where
E Effort in person months D Chronological
months EAF Effort Adjustment Factor -
based on subjective rating from
very low to extra high on 15 project
attributes
32
Effort Adjustment Cost Factors
33
Effort Adjustment Cost Factors
34
COCOMO example

• Suppose used three-point analysis to estimate
  33,200 LOC.
• Using basic model get
• E 2.4(KLOC)1.05
• -2.4(33.2)1.05
• 96 person months
• Duration would be
• D 2.5E.38
• 2.5(95).38
• 12.3 months
• Number of people NE/D N96/12.3 8

35
Project Estimation Problems

• No Requirements
• No Designs
• What is a KLOC?
• 1000 lines of source code
• Are all definitions of a line of code the same?

36
Project Scheduling and Tracking

• When will the project finish?
• Where is the project now?

37
Project Scheduling

• Project Scheduling
• Adding resources and personnel to establish a
  list of dates that monitor the development
  process
• The last completion is when the project is
  complete
• Adding more personnel will make it later. It
  also can change a projects profile
• It is always better to be early than late

38
Project Scheduling Methods

• PERT/CPM Charts
• Calculate the path with the least amount of slack
• Slack is the amount of time between when a task
  can begin and must begin
• Timeline Charts

39
Project Tracking

• Get status in a timely manner
• Weekly at a low level
• Monthly at a high level
• Time sheet status reports
• Separate time into project and non-project
• Project time bill to specific task not project,
  category or charge code
• To avoid 90 complete for 80 of the project.
  Use Earned Value to determine completed

40
Project Tracking

• Earned Value tells you where you are based on the
  completed tasks of your plan
• Earned Value task / project 100
• Example
• In a 1000 hour project, a 15 hour task is 1.5 of
  the project. When it completes it adds 1.5 to
  the completion
• Projected Earned Value tells you where your plan
  should be