Download Chapter 8 - University of Connecticut

Chapter 8: Management of SWE
CSE
CSE
2102
2102
Prof. Steven A. Demurjian
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-2155
Storrs, CT 06269-2155
[email protected]
http://www.engr.uconn.edu/~steve
(860) 486 – 4818
(860) 486 – 3719 (office)
1
Motivating SW Management
CSE
2102







Why is Management Needed?
What are The Main Tasks Of Managers?
What is Special in the Case Of Software?
How Can Productivity be Measured?
Which Tools May be Used for Planning and
Monitoring?
How Can Teams be Organized?
How Can Organizations' Capabilities be Defined and
Measured?
2
Overview of Chapter 8
CSE
2102


Motivate and Review the Entire SW Management
Process – Introduce Ideas and Concepts
Detailed Examination of Project Management w.r.t.
 Estimation
 Risk Analysis
 Implementation Strategies
 Project Control
 Work Breakdown
 Project Scheduling




Organization of Personnel - Approaches to Teams
Software Acquisition
Software Re-engineering (CT Insurance Project)
Software Quality Assurance
3
Motivation and Approach
CSE
2102



Traditional Engineering Practice is to Define a Project
Around the Product being Developed
Project Manager Oversees the Project and:
 Documents Goals
 Develops a Schedule and Budget
 Acquires Resources
 Oversees Project Execution
 Monitors Progress
Staffing: Human Resource Acquisition
 Recruiting (within the Company) and Hiring
 Database Specialist May work on 2 – 3 Projects
 20% - 50% – 30%


Training, Rewarding, and Retaining
Directing Project Members
4
Challenge of Project Management
CSE
2102



Utilize Limited Resources to Achieve Independent and
Sometimes Conflicting Goals
 “Plan the Work and Work the Plan”
Management Decisions Involve:
 Tradeoffs that Impact (Impacted by) Technical
Aspects of Software Engineering
Software Engineering as:
 Team Activity of Many Software Engineers
 Management Coordinates Actions/Responsibilities
"The creation and maintenance of an internal environment
in an enterprise where individuals, working together in
groups, can perform efficiently and effectively toward the
attainment of group goals" (Koontz et al, 1980)
5
Management Functions
CSE
2102





Planning: Flow of Information, People and Products
 What are Required Resources?
 How/When to Acquire Them to Achieve Goals?
Organizing: Clear Lines of Authority/Responsibility
Staffing: Hiring Personnel for Positions
 What Will Each person Do?
 Recruitment, Compensation, Promotion, etc.
Directing: Overseeing the Process
 Guiding Subordinates to Understand (Accept)
Organizational (Project) Structure and Goals
Controlling: Measuring and Correcting Activities to
Ensure Goals are Achieved
 Measure Performance Against Plans
 Keep People Interacting and Project on Track
6
Project Planning
CSE
2102



Project Manager Creates a Plan to Achieve Goals
which Guide Software Engineers in their Tasks
Software Cost Estimation: Predictive Means to
Estimate the Complexity of software Prior to D & D
 Predict Size of the Software
 Use as Input to Estimate Person Years/Timeline
Software Cost Estimation: Multi-Phased Task
 Prediction of Project Complexity
 Delineation of Project Functions
 Guesstimate of Hours/Function
 Organization into Plan with Timeline (Deadlines)
 Consideration of SWE Capabilities in Process
 Impact of Available Software, Tools, etc.
7
Software Estimation
CSE
2102




Software Estimation Involves the “Guesstimate” of
Resources, Cost, and Schedule for Project
 Relies on Experience and Historical Data
 Part of Feasibility Study/Requirements Spec
 Needs to be Constantly Revisited and Reassesed
Accuracy of Estimation Influenced by
 Project Complexity
 Project Size and Interdependency Among
Components
 Degree of Project Structure (or Lack Thereof)
Embodies a Degree of “Risk” or Uncertainty
Focuses on:
 People, Hardware, Software, Space, Time, etc.
8
Software Cost Estimation
CSE
CSE
2102
2102
9
Estimation: Software Scope
CSE
2102


What is the Software Scope:
 Function, Performance, Constraints, Interfaces,
Reliability, Databases, etc.
 Estimating Functional and Performance
Requirements
A Statement of Software Scope Bounded by:
 Quantitative Data Stated Explicitly
 # Simultaneous Users, Max # Users, Response Time,…

Constraints Noted
 Product Cost that Limits Memory Size

Additional Factors
 Algorithms to Utilize, Offsite System Interactions, …

If System Specification Available – these are there…
 Recall Specification Discussion in Chapter 5
10
Estimation: Resources
CSE
2102









CASE Tools: ER, UML, DFD, PNs, etc.
Business System Planning Tools
 Recall Business Process Modeling in UML, Visio
Project Management Tools
 Gantt and PERT, MS Project
Support Tools: MS Office, Visio, Corel Draw, etc.
Analysis and Design Tools
 CASE Tools + Simulators, Queueing Models, etc.
Programming Tools: IDEs + PLs (e.g. Eclipse, VS)
Integration/Testing Tools – github,SCCS, RCS, etc.
Application Platforms
 DBMS, OSs, Web Servers, Application Servers, ...
Hardware Platforms: Servers, PCs, Disks, etc.
 Prototype vs. Test vs. Production
11
Estimation: Other Approaches
CSE
2102




Prototyping and Simulation Tools
 Visio and Rapid Prototyping of GUIs with PLs
Maintenance Tools
 Code Restructuring and Analysis
 Refactoring (What is this?)
Framework Tools
 Database Management, Configuration and Version
Management, Suite of D & D Tools (UML +_PL)
Reusing Software
 Acquire Existing Software that Meets Spec
 CT Insurance – Tiff Converter for Redacting

Modify Existing or Purchased Software
 Estimate Code of Modification vs. From Scratch
 Includes Cost of Purchased Product
12
Estimation: Productivity Metrics
CSE
2102

Typically Quantified in Different Ways
 Classic Approach is Lines of Code Produced/Day
 Estimation of LoC per Task (Function, Class, etc.)
 Cumulative Assessment of LoC for Project
 Often Divided by Major Task (GUI, DB, Server, Client)
 Mapping from LoC to Hours/Task
 Usage of Project Planning Technique (MS Project)



Classic Software Coding Methods Estimate Amount
of Functionality (LoC) Produced Per Unit Time
Two Approaches:
 Function Point
 Code-Based
Can “Miss by a Mile” - PB Project had 15-20 Classes
as Estimate – 200 Classes in Final Prototype
13
Function Points
CSE
2102



Goal: Arrive at a Single Number that Characterizes the
System and Correlates with SWE Productivity
Obtained by:
 Defining and Measuring the Amount of Value (or
Functionality) Produced Per Unit Time
 Determine Complexity of Applications as its
Function Point
Weighted Sum of 5 Characteristic Factors
Item
Number of inputs
Number of outputs
Number of inquiries
Number of files
Number of interfaces

Weight
4
5
4
10
7
What Problem do you see?
14
Function Points
CSE
2102


What does Each Represent?
 Input/Outputs – Provided by User
 Inquiries – Number of Interactive Queries Made by
Users that Require Specific Action by System
 Files – Groups of Related Information
 Interfaces –Interactions with External Systems
Use these Raw Values with Weights to Obtain Total
of: 20 + 40 + 40 + 70 + 70 = 240
Item
Weight
*5
Number of inputs
4
*8
Number of outputs
5
* 10
Number of inquiries
4
Number of files
10 * 7
* 10
Number of interfaces
7
15
What’s the Next Step…
CSE
2102



Total: 240 is Considered in Context of Target
Programming Language
 For each PL – LoC per Function Point
 Sample Values Include: 320 (assembly), 128 (C),
91 (Pascal), 71 (Ada83), and 53 (C++, Java)
If 240 + Java  250*53 = 12,720 LoC
What’s Problem Here?
 Number Doesn’t Always work for All Cases?
 What if Inputs More “Complex” than 4? Or
Inquiries have a Higher or Lower Weight?
 What are Some of the Other Issues Not
Considered?
16
Measuring Code
CSE
2102



Size of Code Produced per Unit of Time as
Productivity Measure
What is Measured?
 DSI – delivered source instructions
 NCSS – noncommented source statements
 KLOC – Thousands of Lines of Code
What is the Potential Issues?
 What about Comments, Documentation?
 Impact of Code Reuse, Code Efficiency?
 How Does One Measure “Automatically Generated
Code” – Getters, Setters, Method Signatures…
17
What are Other Factors that Impact?
CSE
2102







Professionals' Capabilities
Product Complexity
Schedule Constraints
Previous Experience with a Language
Complex Software Requirements (Reliability, Timing,
and/or Performance)
Larger Variation in Productivity of SWE
 Personalities and Interactions Play a Role
 Makeup of Team can have Positive or Severely
Negative Impact!
Estimation Utilized for:
 Estimating Team Size/Effort for Project
 Assessing (Re-assessing) Project Progress
18
Code Estimation
CSE
2102

LoC Good metric for Total Life Cycle Costs
 Most Cost Estimation Methods Utilize Size of
Project to Derive Total Effort Required
PM = c.KLOCk
Legend
• PM: person month
• KLOC: K lines of code
• c, k depend on the model
• k>1 (non-linear growth)
19
Factors Effecting Estimation
CSE
2102





Product: Reliability Requirements or Inherent
Complexity
Computer: Execution Time and/or Storage Constraints
Personnel
 New vs. Experienced?
 Impact of Approach (e.g., Multi-Tier Web) or
Programming Language
Project: Usage of Sophisticated Software Tools
Cost Estimation Procedure
 Estimate Size and Use Formula to Obtain Initial
Estimate
 Revise Estimate Using Above Factors
 Keep Reapplying Metric as Software is Developed
to Re-Estimate Cost More Accurately
20
Estimation: Metrics
CSE
2102




COCOMO: COnstructive COst MOdel proposed by B.
Boehm
Evolved from COCOMO to COCOMO II
Size Estimate based on Thousands of Delivered
Source Instructions, KDSI
Categorizes Software as:
 Organic – e.g., Standard Payroll Application
 Semidetached – e.g., TPS, DBMS, OS
 Embedded – e.g., Flight Control Software
 User Interface Driven – e.g., Web/Mobile App
 Each has an Associated Formula for Nominal
Development Effort Based on Estimated Code Size
 Each has Differing Order of Complexity that Impacts
Estimation
21
COCOMO
CSE
CSE
2102
2102
Mode
Feature
Organic
Semidetached
Embedded
Organizational understanding of
Thorough
Considerable
General
Extensive
Considerable
Moderate
Basic
Considerable
Full
Basic
Considerable
Full
Some
Moderate
Extensive
Minimal
Some
Considerable
Low
<50 KDSI
Medium
<300 KDSI
High
product objectives
Experience in working with related
software systems
Need for software conformance with
pre -es tablished requirements
Need for software conformance with
external interface specifications
Concurrent development of
associated new hardware and
operational procedures
Need for inn
ovative data processing
architectures, algorithms
Premium on early completion
Product size range
All sizes
22
Nominal Effort/Schedule Equations
CSE
2102


COCOMO
 Geared Towards Traditional Development Life
Cycle Models
 Focused on Custom Software Built from Precisely
Stated Specifications
 Relies on Lines of Code
Consider the Equations Below:
 Produce KDSI (Amount of LoC)
 Derive Person Months
Development Mode
Organic
Semidetached
Embedded
Nominal effort
(PM)NOM=3.2(KDSI)1.05
(PM)NOM=3.0(KDSI)1.12
(PM)NOM=2.8(KDSI)1.20
Schedule
TDEV=2.5(PMDEV))0.38
TDEV=2.5(PMDEV))0.35
TDEV=2.5(PMDEV))0.32
23
COCOMO Scaling Factors
CSE
CSE
2102
2102
24
COCOMO II
CSE
2102




COCOMO is Based on “Old” Model of Software
w.r.t. its Makeup and Content
COCOMO II Tries to Transcend its Focus on LoC and
the Three Application Types to Today’s Applications
COCOMO II is Collection of 3 Models
Application Composition Model
 Suitable for Software Built Around Graphical User
Interface (GUI) and Modern GUI-builder Tools
 Uses Object Points as a Size Metric
 Extension of Function Points
 Count of the Screens, Reports, and Modules, Weighted
by aa Three-level Factor (Simple, Medium, Difficult)

For CT Insurance Dept – Based Future Estimates
for Divisions on Experiences with Developed Code
25
COCOMO II
CSE
2102


Early Design Model
 Used Once Requirements are Known and
Alternative Software Architectures have been
Explored
 Cost Prediction Based on Function Points aand
Coarse-grained Cost Drivers
 Leverage Personnel Capability And Experience
Post-Architecture Model
 Redo Estimates Based on Actual Coding Process
 Cost prediction based on
 Size (source instructions or function points, with
modifiers to account for reuse)
 7 Multiplicative Cost Drivers
 5 Factors that Determine the Non-linear Growth of
Person-month costs in terms of size
26
Project Management: Risk Analysis
CSE
2102

Risk Analysis Deals with the Ability to
 Understand Potential Problem Areas
 Monitor Project Closely
 Act When Problem Found
 Four Dimensions:
 Identification and Projection
 Assessment and Management and Monitoring

Risk Deals with Three Factors:
 Future: What Risks Might Endanger Software
Project?
 Change: How will Change Affect Project?
 Choice: How will Choices of Methods, Tools, and
People Affect Project?
27
Risk Analysis: Identification
CSE
2102



Project Risks
 Budget, Schedule, Personnel, Resource, Customer,
Requirements Problems
Technical Risks
 Design, Implementation, Interfacing, Verification,
Maintenance Problems
Business Risks
 Building a Product No One Wants
 Building a Product that Doesn’t Fit Company’s
Product Strategy
 Building a Product Sales Staff Doesn’t Know how
to Sell
 Losing Management Support – Change in Focus
 Losing Budget or Personnel
28
Risk Analysis: Projection
CSE
2102


Attempt to Determine:
 Likelihood that Risk is Real
 Consequences of Problems with Risk
Four Activities in Risk Projection
 Establish a Scale that Reflects Likelihood of Risk
 Quantitative, Probabilistic, or Statistical
Delineate Consequences of Risk
 Estimate Impact of Risk on Project
 Note Overall Accuracy of Risk Projection
Risks Weighted by Perceived Impact
 Nature: Likely Problems if Risk Occurs
 Scope: What will be Affected if Risk Occurs
 Timing: When and How Long will be Impact


29
Risk Analysis: Assessment
CSE
2102




Examine Accuracy of Risk Projection Estimates
Establish a Risk Referent Level
 Level for Cost Overrun will Terminate Project
 Risk Referent Level per Aspect of Project
Risk Triplicate: [r, l, x]
 Risk, Likelihood, Impact of Risk
Four Steps for Risk Assessment
 Define Risk Referent Levels for Project Aspects
 Develop Relationship between r, l, and x for All
Referent Levels
 Predict Set of Reference Points for Termination
 Attempt to Predict the Combination of Risks that
will Affect Referent Levels
30
Risk Analysis: Management/Monitoring
CSE
2102






Risk Aversion is the Actions Taken to Avoid Risk
Triplet [r, l, x] used as Risk Management Basis
 High Risk  Proactive Management/Aversion
Risk Management Incurs Additional Cost
Balance Management Costs with Additional Benefits
80/20 Rule:
 80% of Project Failures Attributed to 20% of
Identified Risks
Risk Management and Monitoring Plan has Three
Objectives:
 Assess if Predicted Risk Does Occur
 Ensure Risk Aversion Steps are Properly Applied
 Collection Information for Future Risk Analysis
31
Typical SWE Risks (Boehm 1989)
CSE
CSE
2102
2102
RISK
RISK MANAGEMENT TECHNIQUE
1. Personnel shortfalls
- Staffing with top talent; job matching; team
building; key - personnel agreements; crosstraining; pre - scheduling key people
2. Unrealistic schedules
and budgets
- Detailed multisource cost & schedu le
estimation; design to cost; incremental
development; software reuse; requirements
scrubbing
3. Developing the wrong
software functions
-
Organization analysis; mission analysis; ops concept formulation; user surveys; prototyping;
early users’ manuals
4. Developing the wrong
user interface
-
Prototyping; scenarios; task analysis; user
characterization (functionality, style, workload)
32
Typical SWE Risks (Boehm 1989)
CSE
CSE
2102
2102
5. Gold plating
-
Requirements scrubbing; prototyping; cost –
benefit analysis; design to cost
6. Continuing stream of
re quirements
- High change threshold; information hiding;
incremental development (defer changes to later
increments)
7. Shortfalls in externally
furnished components
-
8. Shortfalls in externally
performed tasks
- Reference checking; pre - award audits; award - fee
contracts; competitive design or prototyping;
team building
9. Real - time performance
shortfalls
- Simulation; benchmarking; modeling;
prototyping; instrumentation; tuning
10. S training computer
science capabilities
- Technical analysis; cost – benefit analysis;
prototyping; reference checking
Benchmarking; inspections; reference checking;
compatibility analysis
33
Project Mgmt.: Implementation Strategies
CSE
2102




Implementation Strategy Identifies How the Final
System will be Developed
Four Approaches
 Use a Previous Strategy for Past Projects
 Use a Combination of Previous Strategies
 Use a New Strategy
 Use a Combination of New and Previous Strategies
Several Factors Impact on Strategy Selection
 Expertise of Team Members
 Time and/or Cost Constraints
 Application Domain/User Expertise
Many Accepted Strategies in Use …
34
Build it Twice Full Prototype
CSE
2102








System is Implemented Twice
First Version is a Potential “Throw Away” fully
Functional Prototype – Provide Insight for V2!
Second Version Starts After V1 Completed/Evaluated
Recommended for Inexperience Team – Why?
Version 1 Allows Implementers to Gain experience
and Comprehend System Scope and Breadth
 Domain Users Provide Valuable Input on V1
 Input Dictates Changes in V2
 Result: Improved V2 Implementation
Disadvantage: Increased Time and Cost
What about Today? What Situations May this be
Relevant? What Process Model is Most Apropos?
Is there a Useful Variant of BITFP?
35
Level-by-Level Top Down
CSE
2102



System Decomposed into Smaller Modules
 At Each Level, Modules are Developed/Integrated
 Next Decomposition Starts when Current Level
has been Completed
 Integrates Modules as Developed – Reduces BigBang Integration Phase
 Requires Stubs? Drives? Which One?
Disadvantages
 Modules May be Decomposed Differently
 Multiple Solutions for Same Module – Some of
Which may be Less “Optimal” than Others
 Locks Team into Decomposition Decision
Works Best for Experienced Teams… Why?
36
Incremental Development
CSE
2102








Refinement of Build it Twice Full Prototype
Develop System in Functional Increments
 Increment is System with Defined Functionality
 Successive Increments Increase Functionality
Large Systems are More Easily Developed, Tested,
Deployed
 Gets Increment into User’s Hands Quickly
 Allows for Feedback to Project Team
Useful for Inexperienced & Experience Implementers
Where do we See Such Approach Today?
What Type of Applications Can Use this?
What Types of Tools are Available to Promote this?
Is it only Relevant for Large Scale?
37
Advancemanship
CSE
2102


Refinement of Level-by-Level Top Down
Two Components:
 Develop Anticipating Documentation
 Prior to System Development
 Utilize Tools (Visio) for Screen Mock Ups
 Write Detailed Usage Documentation (see web page)

Develop Software Scaffolding
 Develop Some Supporting Software Prior to
Developing the Entire Application
 Focus on “Key” Features
 Utilize Stubs and Drivers to Demonstrate to Users

Advantages? Disadvantages?
38
Project Control: Work Breakdown Structure
CSE
2102



Goal of Project Control:
 Monitor Progress of Activities Against Plan
 Early Detection of Deviation from Plans
Project Control Techniques Breakdown Project Goals
into Intermediate Goals
 Repeat with Intermediate Goals
 Plan each Intermediate Goal w.r.t. Resource
Requirements, Assignment, Schedule
Work Breakdown Schedule (WBS: Activity Tree of
Goals
 Root is major (Project) Goal
 Children are Subgoals to Achieve Parent Goal
39
Consider Compiler Project
CSE
2102




Breakdown of Project into Parts Allows us to Attempt
to Identify Resources for All Leaf Nodes
Leaves are Unit of Work Assignment
WBS May be used as Input to Overall Scheduling
Process
Any Decomposition of Problem Assists in Estimation
Compiler
project
Design
Scanner
Code
Parser
Integrate
and test
Write
manual
Code
generator
40
Project Management: Scheduling
CSE
2102


Gantt Charts Can be Utilized for Scheduling,
Budgeting, and Resource Planning
Bar Chart Represents an Activity
 Horizontal Axis – Time (Days, Months, etc.)
 Vertical Axis – Different Tasks/Goals (Subgoals)
41
Gantt Charges for People Planning
CSE
2102



Track Software team and When they are Available
Manage the Utilization of Software Engineers
What is Major Problem?
 Don’t Show Interdependencies Among Tasks
 Relationships of Goals, Subgoals, etc.
1/1
4/1
7/1
Darius
training
Marta
training
Leo
training
Ryan
training
vacation
Silvia
training
vacation
Laura
training
10/1
vacation
vacation
vacation
42
CT Insurance Project Plan
CSE
2102




Employed MS Project for Detailed Estimations of
Effort Applied to a Schedule
Estimations Occurred After Significant Amount of
Development Accomplished
 Experience to Base Estimates
 More Precise Guesstimates
Web Page Contains
 MS Project Plan (24 pages)
 Excel Spreadsheet on Hours/Timeline
Where are we Today?
 Not Used Since Created (December 2003)
 Interesting to do a Post-Mortem on Planning …
43
CT Insurance Overall Plan
CSE
2102

Nearly 3Year Period (9/2002 to 5/2005)
24 pages 8.5 by 11 inches
4 rows and 6 pages per row
Entire Plan
 5ft wide by 3 ft high
Below is ½ of the first main portion of plan

http://www.engr.uconn.edu/~steve/Cse2102/cidprojplan.pdf




44
Focused Plan for Consumer Affairs
CSE
CSE
2102
2102
45
2nd Portion of Plan
CSE
CSE
2102
2102
46
Scheduling: PERT Charts
CSE
2102

PERT: Program Evaluation and Review Technique
 Network of Boxes (or circles) and Arrows
 Boxes represent activities
 Arrows represent dependencies among activities
 Activity at the head of an arrow cannot start until the
activity at the tail of the arrow is finished
Boxes may be Notated with Start and End Dates
 Boxes may be Designed as Milestones
To Construct a PERT Chart:
 List all Activities Required for Project Completion
with Estimated Time Lengths
 Determine Interdependencies Between Activities


47
Recall WBS of Compiler Project
CSE
2102


For PERT – Focus on
 Defining Which Activities can be Performed at
Which Times
 Understanding Dependencies Among Activities
Note: Implementation Strategy May Influence PERT
Compiler
project
Design
Scanner
Code
Parser
Integrate
and test
Write
manual
Code
generator
48
PERT Chart for Compiler Project
CSE
CSE
2102
2102
March 7
build
scanner
Jan 1
start
Jan 3
design
March 7
build
parser
March 7
build code
generator
Nov 14
integration
and testing
finish
Mar 17+
March 7
write
manual
49
Scheduling: PERT Chart
CSE
2102

Advantages
 Forces Manager to Plan
 Highlights
Interrelationships
Among Tasks
 Identifies Critical Path
in the Project (See
Bold)
 Exposes Possible
Parallelism in Tasks
 Assists in Allocating
Resources
 Allows Scheduling and
Simulation of Schedules
 Enables Manager to
Monitor/Control Project

Disadvantages
 Manager Controls
Granularity of Tasks
 If Manger Imprecise,
PERT is as Well
 Inaccuracies can Make
PERT Ineffectual
 Charts for Large
Projects may be Huge
 Definitely Need
Automated Support
 Some Gantt Tools can
Generate PERT
50
Scheduling – What are the Pieces?
CSE
CSE
2102
2102
Divisions
Licensing
Con. Aff.
Mar. Con.
Shared Tabs
Classify
Assign
Inquiry
Processing
51
Project Prototyping Plan
CSE
2102

Tracks Who Does What When for Which Component
52
Project Management: Personnel Organization
CSE
2102




An Organization Structure is Used to Define the
Communication Patterns Among Members of a Team
Traditional Team Organization is Hierarchical with a
Manager Supervising a Group or Groups of Groups
Other Organizations have Been Tried in Software
Engineering with Some Success
Many Different Organizational Structures Based on
 Who is in Charge of Whom
 Who Interacts with Whom
 Who Does What Task(s)
 Organization Structure vs. Task Responsibilities
 Control: Centralized vs. Decentralized vs. Mixed
53
Personnel Organization
CSE
2102



Organizations are Needed When Goals (Project) not
Achievable by Single Person in Timeframe
 Almost All Projects Today are Team Oriented
 Aim: Facilitate Cooperation Towards Common
Goal
Organization Questions:
 What is Best Role for Each Individual?
 How Should Responsibilities be Divided?
 Is there Training Required?
 Who Trains Whom (or External Training)?
All Organizations Succeed or Fail Based on:
 Communication!
54
Personnel Organization
CSE
2102

Organizations can Organize Themselves as:
 n Individuals Assigned to m Tasks (m ≥ n)
 Little Combined Work
 Coordination Responsibility of Manger
 Manager May Oversee Sever Projects

n Individuals Assigned to m Tasks (m < n)
 Create Informal Teams with Ad Hoc Leader (Possible)
 Coordination Responsibility of Overall Manager

n Individuals Organized into m Teams
 Each Team Assigned one or More Tasks with their
Own Organizational Structure
 Coordination by Team and Overall Manager


Note: Individuals May be on Multiple Teams
Advantages? Disadvantages?
55
Personnel Organization
CSE
2102




Evidence (Mythical Man Month and Other Studies)
Strongly Argues for Formal Team Organizations
Goal of Team is Project as a Joint Effort
 Foster Egoless Programming
 Thorough Project Review Approach
 Increased Learning
 Improved Software Quality
Team effort can Actual Reduce Communication and
Misunderstanding
How do SW Qualities and Principles Perhaps Argue
that Formal Teams are Best Approach to D & D?
56
Personnel Organization
CSE
2102


Many Factors Influence Team Organization
Length of Project
 Long Project Requires Long-Term Job Satisfaction
 Compose Team of Junior and Senior Engineers
 Junior – Less Challenging Tasks
 Senior – More Challenging Tasks – Mentor Juniors
Long-Term Projects: Turnover a Problem – Why?
Project Domain and Required Communication
 Well Defined Projects  Less Communication
 Poor Specifications  More Communication
 Strictly Hierarchical Orgs  Minimize Comm.
 Democratic Orgs  Encourage Communication


57
Personnel Organization
CSE
2102

Size of Teams
 Small Teams









More Cohesive Design
Less Overhead (Communication/Management)
More Unity (if they get Along) and Higher Morale
More Productivity per Team Member
Some Tasks Too Complex for Small Teams
Match Size and Organization to Project
Optimal Team Size – Between 3 and 8 (CSE293)
Once Exceed 8 – Hierarchically Organize Teams
Large Teams
 Partitioning of Project by “Larger” Chunks
 Within Teams – Chunks Also Partitioned
58
Role of Manager in Teams
CSE
2102

Manager Must Balance Needs of:
 Keeping Project on Schedule
 Meet Budgetary Constraints
 Produce a Quality Project
 Reduce Project’s Overall Lifecycle Costs
 Satisfy and Motivate Team Members
 Allows Team Members to Express Individuality
 Conform to Team Standards
59
Centralized Control
CSE
2102



Chief Programmer Teams Most Common Form
Chief Programmer (CP) Responsible for Design and
Critical Portions of Code
 Reports to Manager responsible for Administration
 Determines Needs for Programmers, Consultants
 Determines Tasks, Initiates/Controls Decisions
Librarian
 Software Engineer Maintains Software Repository





Software
Program Libraries
Documentation
Decisions
Coordinates all Documentation Effort (May Also
Write Code as Well)
60
CP Team Structure
CSE
2102


Backup Programmer – Understudy of CP who
Participates in Design/Code and can Take Over
Other Programmers
 Aid in Design and Coding
 Number Depend on Size of Project
Chief programmer
Librarian
Programmers
Specialists
Backup
Programmers
61
Centralized Control
CSE
2102


Advantages
 Communication Minimized
 Faster Development
 More Coherent Design (one Person)
 Works Well if Project Understood (Good Spec)
Disadvantages
 Chief Programmer is Bottleneck
 Success (Failure) Heavily Dependent on CP
62
Decentralized Control
CSE
2102




Each team Member has Equal Responsibility and
Decision Making Authority
Decisions are Made by Consensus
All Work is Group Work – Credit/Blame by All
Group Leadership Rotates Based on Skill and Task
(a)
management
structure
communication
pattern
(b)
63
Decentralized Control
CSE
2102


Advantages
 Improved Software Quality (Multiple Cooks all
Looking Over each Other’s Shoulders)
 Higher Morale and Job Satisfaction
 Less Turnover – Suited for Long-Term Projects
 Appropriate for Less Understood/More Complex
Software Whose Requirements Evolve
Disadvantages
 Increased Communication May Increase
Development Timeframe
 Not Suited for Large Teams
 Too Much Communication
 Hard to Reach Agreement (Consensus)
64
Mixed Control
CSE
2102



Combines Prior Two Approaches to Emphasize their
Advantages and Minimize their Disadvantages
Consists of Three Groups of People
 Project Manager
 Senior Software Engineers
 Junior Software Engineers
Senior Engineer Leads a Group of Juniors and Reports
to a Project Manager
 Control Vested in the Project Manager and Senior
Programmers
 Communication Decentralized Among Each Set of
Individuals, Peers, and Their Immediate
Supervisors
65
Mixed Control Team Structure
CSE
CSE
2102
2102
Project manager
Senior engineers
Junior engineers
(a)
management structure
(b)
communication pattern
66
Mixed Control
CSE
2102





Project Managers and Senior SWE Control Process
Communication Decentralized for Peers/Supervisors
Work can be Assigned by:
 Each Group Works on Different Software Module
 Each Group Works on Different Function (Coding,
Testing, Integration Testing, etc.)
Advantages:
 Groups Work in Parallel with Limited Comm.
 Hierarchy Masters Complexity of Development
Disadvantages:
 Doesn’t Work Well if Product Not Easily Divided
 Some Groups May be Idle at Some Times
 May be Working on Other Projects and Teams
67
Project Management Today
CSE
2102





Geographically Distributed Environment
 Typical Project: 100 Developers Working in Three
To Four Sites
 Synchronous Work Not Possible (Time Zones)
Product Family Architecture
 Architecture for Entire Family, and Components
Developed to be Used in All Family Members
Concurrent Engineering
 Components Developed Concurrently at Different
Sites, Retrieved from the Various Sites and
Combined in a Central Location
Process is Tool Supported
 Requirements Engineering, Design, Coding,
Version & Configuration Management, Testing
How is Software Built Today? What is Outsourcing?
68
CT Insurance Department Project
CSE
2102



Insurance Department (Hartford)
 Project Manager
 Full-Time Consultant
 2 Support Developers (Web, Testing, etc.)
UConn (Storrs)
 3 Software Engineers (1 in Waterbury - Remote)
 4 - 20 hour/week Grad Students
 S. Demurjian and D.G. Shin (UConn Managers)
We Utilized Mixed Control – How?
 Four Teams (1a, 1b, 1c, 1d)
 Gentronics Consultant
 Teams Spanned Both Locations
69
CT Insurance Detailed Team Planning
CSE
CSE
2102
2102
70
CT Insurance Detailed Team Planning
CSE
CSE
2102
2102
71
CT Insurance Detailed Team Planning
CSE
CSE
2102
2102
72
CT Insurance Detailed Team Planning
CSE
CSE
2102
2102
73
Project Mgmt.: Software Acquisition
CSE
2102


Buy vs. Build - Acquisition Options
 Purchase COTS (GOTS) and Use as is
 Purchase COTS and Modify
 Custom Built Software from Outside Vendor
Guidelines for Software Purchase
 Develop Specification of Functional/Performance
 Estimate Cost for Inhouse Build vs. Purchase
 Select Several Candidate Packages
 Develop Comparison Matrix/Conduct Benchmarks
 Evaluate Software Based on Product Quality,
Vendor Support, Product Direction, Reputation, …
 Contact Other Users of Software for Opinions
74
Project Mgmt.: Software Acquisition
CSE
2102


Base Build-Buy Decision on:
 Will Acquisition and Customization Cost be Less
than Inhouse Total?
 Will Delivery Date of the Product be Sooner (or
Match Timeline) as Compared to Inhouse?
 Will Cost of Yearly Outside Support
(Maintenance) be Less than Internal Support
Most Approaches Suggest Construction of a Decision
Tree to Assist in the Process
75
Decision Tree
CSE
CSE
2102
2102
Simple (.3)
Build
Difficult (.7)
Minor (.4)
$380,000
$450,000
$275,000
Simple (.2)
Reuse
$313,000
Major(.6)
System X
Difficult (.8)
Minor (.7)
$490,000
$210,000
Buy
Major(.3)
with changes(.4)
$400,000
$350,000
Contract
without changes(.6)
$500,000
76
Software Re-Engineering
CSE
2102





Existing Software Applications (C, Cobol, Fortran)
Difficult to Maintain and Improve
Patches Ineffectual or Fail
Maintenance is becoming Prohibitively Expensive
Re-engineering an Expensive Activity that May Save
Money at a Later Point in Time
Steps for Re-Engineering
 Select Programs Heavily used for next 5-10 years
 Estimate Maintenance Costs for
 Error Correction, New Features, Hardware, etc…
Prioritorize Programs by Importance
CT Insurance Dept Project – Re-Engineering to
Replace Wang Computer and COBOL Apps
Other DOIT Project: Reverse Engineer Design for
Undocumented Code



77
Software Quality Assurance
CSE
2102



Recall Software Engineering Qualities
 Correctness and Reliability
 Robustness and Performance
 User Friendliness and Verifiability
 Maintenance and Reusability
 Repairability and Evolvability
 Portability, Understandability, and Interoperability
 Productivity, Timeliness, and Visibility
Project Managers Select Qualities to be Assessed
SQA Programs are Emerging, Particularly with
Respect to Critical Qualities (Software, Correctness,
Robustness, Performance)
78
Software Quality Assurance
CSE
2102




SQA Programs Range from …
 Low Level – Responsibility of Software Engineers
 High Level – Dedicated SQA Group
SEI’s CMM is out to Address SQA (+ Spiral Model)
What Supports an SQA Audit?
 Policies
 Organization
 Functional Interfaces
Collectively, Intent is to Assess Both the
 Product – Does it have Required Features
 Process – Have Strict Guidelines been Followed
 e.g., Embedded Software, Secure Software
79
SQA Audit
CSE
2102



Policies
 What are the Current Policies?
 Is there a Management-Supported Policy?
 Are Policies Applied to Development and
Maintenance?
 Are they Enforced?
Organization: Where is SQA Located?
Function Interfaces
 How Does SQA Related to Other Functions?
 Verifying Database Content or Authorization Process
How does SQA Interact with Individuals
Responsible for Configuration Management and
Testing?
See: http://hissa.nist.gov/publications/nistir4909/


80
SQA Techniques
CSE
2102



Programmer/Software Developer Level
 Enforces Seven Software Principles
 Limited Testing of Select Qualities
 Which Ones are Apropos?
Team Level
 Design Reviews
 Structured Walkthroughs
 Code Reviews
SQA has Emerged as Prominent Player in
Guaranteeing Assurance of
 Software
 Database
 Information
 Security
81
NIST Standard for SQA
CSE
CSE
2102
2102
82
NIST Standard for SQA
CSE
CSE
2102
2102
83
NIST Standard for SQA
CSE
CSE
2102
2102
84
NIST Standard for SQA
CSE
CSE
2102
2102
85
SQA
CSE
2102


Advantages
 Fewer Software Defects
 Less Testing and
Maintenance Time
 Higher Product
Reliability
 Higher Customer
Satisfaction
 Lower Maintenance
Costs
 Lower Overall Total
Lifecycle Costs
What are Some Key
Success (Products) w.r.t.
SQA?

Disadvantages
 Difficult to Institute in
Small Organizations Inadequate Resources
 Resistance from Project
team Members
 Major Cultural Change
 Requires Money Up
Front

Why Should we do SQA
Despite these
Disadvantages?
86
Capability Maturity Model
CSE
2102



CMM Developed by the CMU’s SEI for SQA to help
Organizations which …
 Develop Software Improve Software Processes
 Acquire Software Assess the Quality of their
Contractors
Immature Organization
 Processes are Improvised During the Course of a
Project to Resolve Unanticipated Crises
 Products Often Delivered Late and their Quality is
Questionable
Mature Organization
 Organization-wide Standard Approach to Software
Processes, Known and Accepted By All Engineers
 Focus on Continuous Improvement Both in
Performance and Product Quality
87
CMM Maturity Levels
CSE
CSE
2102
2102
Level 5:
Optimizing
Level 4:
Managed
Level 3:
Defined
Level 2:
Repeatable
Level 1:
Initial
88
CMM Key Process Areas
CSE
CSE
2102
2102
CMM Level
Initial
Repeatable
Defined
Managed
Key process areas
None
Requirements management
Software project planning
Software project tracking and oversight
Software subcontract management
Software quality assurance
Software configuration management
Organization process focus
Organization process definition
Training program
Integrated software management
Software product engineering
Intergroup coordination
Peer reviews
Software quality management
Quantitative process management
89
Chapter 8 Summary
CSE
2102


Objective of Chapter 8 is to Focus on the Process of
Software Development w.r.t.
 Estimation (Code, People, Resources, Costs, etc.)
 Scheduling and Control
 Personnel Organizations and Team Structures
 Risk Analysis and Monitoring
 Implementation Strategies
 Software Acquisition
 Software Re-engineering (CT Insurance Project)
 Software Quality Assurance
Overhead Involved in Planning and Management is
Significant – Even for “Small” Projects
90