310414 managing development 1 managing software development 310414 software engineering 310414...

of 32 /32
310414 310414 MANAGING DEVELOPMENT MANAGING DEVELOPMENT 1 MANAGING SOFTWARE DEVELOPMENT MANAGING SOFTWARE DEVELOPMENT 310414 310414 SOFTWARE ENGINEERING SOFTWARE ENGINEERING

Author: brooke-ariel-ford

Post on 17-Jan-2016

214 views

Category:

Documents


0 download

Embed Size (px)

TRANSCRIPT

COMP 211: Introduction to Software EngineeringTHE CHALLENGE
Planning the development is a continuous process:
“plan the work” and “work the plan”.
come up with a plan for software development with
incomplete knowledge (requirements, people, etc.)
limited resources (time, money, skills, etc.)
decide
whether to build or buy – effort to be expended
what resources are required – schedule to follow
what are the risks – what development tools to use
.
.
.
the SDP documents exactly how the project will be managed
it defines the project
define the problem ® agree on what constitutes success
analyze the requirements ® so you can make sizing estimates
prepare a top-level package diagram ® overall view of the system
estimate the time and effort needed to deliver the product
input needed from:
project sizing
The outcome is a go/no-go decision.
310414
executable code – tutorials
user manuals – examples
help files – templates
use-case databases – requirements, analysis, design specs
object design files – source code
Internal deliverables ® of continuing value to the organization
source code libraries – make files
test libraries – problem report database
Services ® additional deliverables for the customer
training – on-site support
DEVELOPMENT ENVIRONMENT
need to choose hardware and software development tools appropriate for the project
development tools ≠ development process
tools are effective only if they make well-understood processes more efficient
in choosing a development support tool evaluate:
support of the lifecycle: UML; management oversight and control;
architectural control; collaboration support;
developer efficiency; library integration;
external cost; internal cost; time loss;
product instability; investment protection
we usually need to estimate:
size – effort – duration
productivity – development cost
use software metrics from past projects
divide and conquer
SOFTWARE METRICS FOR ESTIMATING
We can collect many types of metrics about many aspects of software.
Question: What metrics are useful for estimating and
how can they be used for estimating?
Technical metrics
Quality metrics
Productivity metrics
Size-oriented metrics
Function-oriented metrics
Human-oriented metrics
Productivity metrics
Size-oriented metrics
Function-oriented metrics
SOFTWARE METRICS FOR ESTIMATING
productivity metrics – focus on the output of the software engineering process
quality metrics – indicate how closely the software conforms to implicit and explicit customer requirements (i.e., fitness for use)
technical metrics – focus on the properties of the software rather than the process through which the software was developed
size-oriented metrics – direct measures of software development output and quality
function-oriented metrics –indirect measures of software properties
human-oriented metrics – provide information on the manner in which people develop software and human perceptions about the effectiveness of tools and methods
310414
Productivity = KLOC/effort Quality = errors/KLOC
Cost = $K/KLOC Documentation = pages/KLOC
310414
Productivity = FP/effort Quality = errors/FP
Cost = $/FP Documentation = pages/FP
Number of user inputs x 3 4 6 =
Number of user outputs x 4 5 7 =
Number of user inquiries x 3 4 6 =
Number of files x 7 10 15 =
Number of external interfaces x 5 7 10 =
Count - total
FUNCTION-ORIENTED METRICS
Number of user inputs – counts each user input that provides distinct application-oriented data to the software (distinguished from inquiries)
Number of user outputs – counts each user output that provides application-oriented output to the user (e.g., reports, screens, error messages, etc.; individual data items are not counted)
Number of user inquiries – counts each online input that results in the generation of some immediate response in the form of an online output
Number of files – counts each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate file)
Number of external interfaces – counts each machine-readable interface (e.g., data files on disk) that is used to transmit information to another system
310414
No influence Incidental Moderate Average Significant Essential
F1 Does the system require reliable backup and recovery?
F2 Are data communications required?
F3 Are there distributed processing functions?
F4 Is performance critical?
F5 Will the system run in an existing, heavily utilized operational environment?
F6 Does the system require on-line data entry?
F7 Does the on-line data entry require the input transaction to be built over multiple screens or operations?
F8 Are the master files updated on-line?
F9 Are the inputs,, outputs, files, or inquiries complex?
F10 Is the internal processing complex?
F11 Is the code designed to be reusable?
F12 Are conversion and installation included in the design?
F13 Is the system designed for multiple installations in different organizations?
F14 Is the application designed to facilitate change and ease of use by the user?
310414
may use Delphi technique - average 3 or more estimates
Pert estimation
optimistic – most likely – pessimistic
expected value computed as a weighted average of optimistic (o), most likely (m) and pessimistic (p)
E = (o + 4m + p)/6 StdDev = (p - o)/6
actual size between E-StdDev and E+StdDev 68% of the time
SD is a measure of schedule and budget risk
310414
Parametric models
use parametric formulas empirically derived from a limited sample of projects to predict effort, project duration, etc.
static single-variable models (e.g., COCOMO)
Resource = c1 x (estimated characteristic)C2
static multi-variable models
Resource = c11e1 + c12e2 + ...
estimates resource requirements as a function of time
c - empirically derived constants e - ith software characteristic
310414
D = cb(E)**(db) development time in months
Software project ab bb cb db
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
organic – relatively small, simple software projects, non-rigid requirements
small teams with good application experience
semi-detached – an intermediate project;
must meet a mix of rigid and less rigid requirements
embedded – project must meet set of tight hardware, software and operational constraints
310414
Software project ai bi
Model 3 - Advanced COCOMO
Model 2 plus an assessment of each cost driver’s impact on each step of the software engineering process
310414
size of application database – application of S.E. methods
complexity of the product – required development schedule
Personnel attributes Hardware attributes
virtual machine experience – volatility of virtual machine environment
programming language experience
– each cost driver is rated on a scale from 0-6
– this rating is used to look up an effort multiplier from published tables
– the product of all effort multipliers results in an effort adjustment factor
(EAF) whose values typically range from 0.9 to 1.4
310414
Requirements
under uncertainty, develop resource requirements incrementally
a cost estimation model is doing well if it can estimate software development costs within 20% of actual costs, 70% of the time on its “own turf”
always perform estimation in more than one way and do cross-checks on your results
essential to have experienced developers do estimating
automated tools can help
RISK PLANNING
If you do not actively attack risks, they will actively attack you!
T. Gilb
determine what can go wrong, before it happens
determine its impact
develop cost-effective contingency plans (what to do if it happens)
the ability to do this well is one of the important qualities of a good manager
related to preventive management (i.e., determine the risk and execute preventive action before the problem can take place)
310414
project risks
technical risks
business risks
no market, no need, sales force can’t sell, no management support, ...
It is important to identify all the risks that we can.
Use a risk checklist.
consequences and impact (xi) of the risk
its nature what is likely to happen
its scope what is likely to be affected and to what degree
its timing when and duration
accuracy of projection
Prioritize risks.
for each risk identified attempt to define the referent point
project will be terminated above referent point
Avoid/manage risks which could lead to project termination.
Projected cost overrun
Projected schedule overrun
xi=“increase duration by 15% and overall cost by 12%”
What steps can be taken to mitigate this risk?
“If you know the enemy and you know yourself, you need not fear the result of a hundred battles.”
The Art of War, Sun Tzu
need to perform cost/benefit analysis of countermeasures
Do they cost more than the consequences
of the risk itself?
apply 80:20 rule: 80% of all project risk is accounted for by 20% of identified risks
310414
usually shown in a tree structure
identify all the activities/tasks required to complete the project
estimate resources required for each leaf node and then “roll-up” to get estimate for the entire project
used in both budgets (cost of task) and schedules (time to do task)
WBS should allow each task to be:
easily planned ® has a well-defined start and end
easily assigned ® to individuals/teams
tracked ® can monitor progress and know who is working on it
budgeted ® has an associated cost
of the right granularity ® not too small and not too large
310414
Build1
Build2
Build1
Build2
Build3
Requirements
Analysis
Design
Implementation
Testing
Installation
Packaging
Project
Development
Tracking
Maintenance
Training
Initiation
Inception
Elaboration
Transition
Construction
Build1
task ordering dependencies (sequential, parallel)
time estimates for each task start time, duration (range?)
resource assignment people, hardware, software
milestones important management decision points
deliverables specifications, documents, code, etc.
critical path chain of tasks which determine project duration
prioritize by risk, criticality, resource utilization
usually three levels of schedule needed:
master schedule for communicating with management, customer
macroschedule for day-to-day management of project
microschedule for team management
310414
critical path
dummy task
dummy task
Build System Prototype C 4 B
Database Design D 5 B
Implementation E 9 C, D
Testing and Evaluation F 10 C, D
Deployment G 2 E, F
Post Project Review H 1 G
Node Earliest Completion Time Latest Completion Time Slack
1 0 0 0
2 1 1 0
3 4 4 0
4 8 9 1
5 9 9 0
6 18 19 1
7 19 19 0
8 21 21 0
9 22 22 0
We need to create a (hierarchical) project organization chart that:
identifies project roles and responsibilities
plans the number of staff in each role
establishes product teams as needed
interdisciplinary teams to coordinate certain efforts
Need at least one project member with similar system experience!
The team organization should:
invest each team member with a clear sense of ownership
This implies that:
teams should be formed to “own” the design and implementation of one or more packages
classes should be assigned to individuals for design and implementation
owners (leads, PIC) should be identified for packages and the system
achieving right level of communication is key to success
310414
when the project’s budget is planned to be spent
what is expected to have been accomplished at each level of expenditure
Manpower will likely be the major cost
to each WBS item assign costs based on duration, staffing level, and cost for each type of staff
BUT, don’t forget other costs!
travel – software licenses
Track the spending!
Compare planned and actual money spent against planned and actual completion monthly.
310414
identify which development metrics to collect
provide a plan for how to collect each of them
describe procedures and tools the will be used to collect them
Project management metrics are usually related to size:
number of use cases
progress: how much of the planned development is in place
stability: how much change has there been in project requirements and change estimates
310414
“software projects fall behind schedule one day at a time”
need to have constant, consistent, inoffensive monitoring of project activities
primary purpose is to make sure the project is
meeting the budget and schedule
change is nearly inevitable despite best efforts to minimize it
key is to handle it in a controlled manner SCM
“Adding manpower to a late software project makes it later.”
Frederick P. Brooks The Mythical Man-Month
310414
doing project reviews and evaluating the results of each review
check if milestones are accomplished as planned
compare actual budget with planned budget and actual start dates with planned start dates for activities
informal chats with project staff
if slipping
diagnose and recover as best you can: reorganize, change schedule, etc.
310414
PROJECT TRACKING & CONTROL – FINAL THOUGHTS
need to identify what tasks in the WBS need to be done by when and by who, AHEAD OF TIME
its the only way to know what you are doing and what else can be changed (reordered) to try to stay on track
even if the schedule changes, you should identify why first and incorporate knowledge into measurements for next time
a schedule slip is not good, but understandable, if you know why it happened
BUT, missed deadlines with no schedule or knowledge of why things are happening that way is INCOMPETENCE
310414
“Manage the process, don’t let the process manage you.”
Khoa Nguyen, CEO Videoserver