1. Chapter 8: Management of SWE
Prof. Steven A. Demurjian
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-2155
Storrs, CT
(860) 486 – 4818
(860) 486 – 3719 (office)

2. Motivating SW Management
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?

3. Overview of Chapter 8
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

4. Motivation and Approach
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

5. Challenge of Project Management
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)

6. Management Functions
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

7. Project Planning
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.

8. Software Estimation
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.

9. Estimation: Software Scope
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
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 – 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
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
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 Classes as Estimate – 200 Classes in Final Prototype

13. Function Points
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
What Problem do you see?

14. Function Points 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:
= 240
Item
Weight
* 5
Number of inputs 4 5 10 7
* 8
Number of outputs
* 10
Number of inquiries
* 7
Number of files
* 10
Number of interfaces

15. What’s the Next Step…
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 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
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?
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 PM = c.KLOCk
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
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
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
Each has an Associated Formula for Nominal Development Effort Based on Estimated Code Size

21. COCOMO Mode Feature Organic Semidetached Embedded
Organizational understanding of
product objectives
Thorough
Considerable
General
Experience in working with related
software systems
Extensive
Moderate
Need for software conformance with
pre - es
tablished requirements
Basic
Full
external interface specifications
Concurrent development of
associated new hardware and
operational procedures
Some
Need for inn
ovative data processing
architectures, algorithms
Minimal
Premium on early completion
Product size range
Low
<50 KDSI
Medium
<300 KDSI
High
All sizes

22. Nominal Effort/Schedule Equations
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

23. COCOMO Scaling Factors
Ratings
Cost Drivers
Very low
Low
Nominal
High
Very
Extra
Product attributes
Required software
reliability
.75
.88
1.00
1.15
1.40
Data base size
.94
1.08
1.16
Product complexity
.70
.85
1.30
1.65
Comput
er attributes
Execution time constraints
1.11
1.66
Main storage constraints
1.06
1.21
1.56
Virtual machine volatility*
.87
Computer turnaround time
1.07
Personnel attributes
Anal
yst capability
1.46
1.19
.86
.71
Applications experience
1.29
1.13
.91
.82
Programmer capability
1.42
1.17
Virtual machine
experience*
1.10
.90
Programming language
experience
1.14
.95
Project
attributes
Use of modern
programming practices
1.24
Use of software tools
.83
Required development
schedule
1.23
1.04

24. COCOMO II
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 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
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
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
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
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
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)
RISK MANAGEMENT TECHNIQUE
1. Personnel shortfalls -
Staffing with top talent; job matching; team
building; key
personnel agreements; cross
training; 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)
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
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
Benchmarking; inspections; reference checking;
compatibility analysis

33. Project Mgmt.: Implementation Strategies
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
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
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 Big-Bang 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
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 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
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: Activity Tree of Goals
Root is major (Project) Goal
Children are Subgoals to Achieve Parent Goal

39. Consider Compiler Project
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
Code
Integrate
and test
Write
manual
Scanner
Parser
generator

40. Project Management: Scheduling
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
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.
Darius
Marta
Leo
Ryan
Silvia
Laura
vacation
training
1/1
4/1
7/1
10/1

42. CT Insurance Project Plan
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. Scheduling: PERT Charts
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 (use WBS)
Determine Interdependencies Between Activities

44. Recall WBS of Compiler Project
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
Code
Integrate
and test
Write
manual
Scanner
Parser
generator

45. PERT Chart for Compiler Project

46. Scheduling: PERT Chart
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

47. Scheduling – What are the Pieces?
Divisions
Licensing
Con. Aff.
Mar. Con.
Shared Tabs
Classify
Assign
Inquiry
Processing

48. Project Prototyping Plan
Tracks Who Does What When for Which Component

49. Project Management: Personnel Organization
An Organization Structure is Used to Structure 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

50. Personnel Organization
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!

51. Personnel Organization
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?

52. Personnel Organization
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?

53. Personnel Organization
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

54. Personnel Organization
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

55. Role of Manager in Teams
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

56. Centralized Control 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)

57. CP Team Structure
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

58. Centralized Control 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

59. Decentralized Control
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
management structure
communication pattern

60. Decentralized Control
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)

61. Mixed Control
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

62. Mixed Control Team Structure
management structure
communication pattern

63. Mixed Control 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

64. Project Management Today
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
Use Of Tools - Process is Tool Supported
Requirements Engineering, Design, Coding, Version Management, Configuration Management, and Testing

65. CT Insurance Department Project
Insurance Department (Hartford)
Project Manager
Full-Time Consultant
2 Support Developers (Web, Testing, etc.)
UConn (Storrs)
3 Software Engineers (1 in Waterbury - Remote)
hour/week Grad Students
S. Demurjian and D.G. Shin (UConn Managers)
We Utilized Mixed Control – How?

66. Project Mgmt.: Software Acquisition
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

67. Project Mgmt.: Software Acquisition
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

68. Decision Tree Simple (.3) $380,000 Build $450,000 Difficult (.7)
Minor (.4)
$275,000
$313,000
Simple (.2)
Reuse
Major(.6)
$490,000
System X
Difficult (.8)
Minor (.7)
$210,000
Buy
$400,000
Major(.3)
$350,000
with changes(.4)
Contract
$500,000
without changes(.6)

69. Software Re-Engineering
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

70. Software Quality Assurance
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)

71. Software Quality Assurance
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

72. SQA Audit 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:

73. SQA Techniques 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

74. NIST Standard for SQA

75. NIST Standard for SQA

76. NIST Standard for SQA

77. NIST Standard for SQA

78. SQA 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?

79. Capability Maturity Model
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

80. CMM Maturity Levels

81. CMM Key Process Areas

82. Chapter 8 Summary
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