1

CSE

2102

CSE

2102

Chapter 8: Management of SWEChapter 8: Management of SWE

Prof. Steven A. DemurjianComputer Science & Engineering Department

The University of Connecticut371 Fairfield Road, Box U-2155

Storrs, CT 06269-2155

steve@engr.uconn.eduhttp://www.engr.uconn.edu/~steve

(860) 486 – 4818(860) 486 – 3719 (office)

2

CSE

2102

CSE

2102

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

CSE

2102

CSE

2102

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

CSE

2102

CSE

2102

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

CSE

2102

CSE

2102

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

CSE

2102

CSE

2102

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

CSE

2102

CSE

2102

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

CSE

2102

CSE

2102

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

CSE

2102

CSE

2102

Software Cost EstimationSoftware Cost Estimation

10

CSE

2102

CSE

2102

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

11

CSE

2102

CSE

2102

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 – github,SCCS, RCS, etc. Application Platforms

DBMS, OSs, Web Servers, Application Servers, ... Hardware Platforms: Servers, PCs, Disks, etc.

Prototype vs. Test vs. Production

12

CSE

2102

CSE

2102

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

13

CSE

2102

CSE

2102

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 15-20 Classes as Estimate – 200 Classes in Final Prototype

14

CSE

2102

CSE

2102

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?

Item Weight Number of inputs 4 Number of outputs 5 Number of inquiries 4 Number of files 10 Number of interfaces 7

15

CSE

2102

CSE

2102

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:

Item WeightNumber of inputs Number of outputs Number of inquiries Number of files Number of interfaces

4 5 4 10 7

* 5* 8* 10* 7* 10

20 + 40 + 40 + 70 + 70 = 240

16

CSE

2102

CSE

2102

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 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?

17

CSE

2102

CSE

2102

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…

18

CSE

2102

CSE

2102

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

19

CSE

2102

CSE

2102

Code Estimation 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)

20

CSE

2102

CSE

2102

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

21

CSE

2102

CSE

2102

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 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

22

CSE

2102

CSE

2102

COCOMOCOCOMO

Mode

Feature Organic Semidetached Embedded

Organizational understanding of

product objectives

Thorough Considerable General

Experience in working with related

software systems

Extensive Considerable Moderate

Need for software conformance with

pre - es tablished requirements

Basic Considerable Full

Need for software conformance with

external interface specifications

Basic Considerable Full

Concurrent development of

associated new hardware and

operational procedures

Some Moderate Extensive

Need for inn ovative data processing

architectures, algorithms

Minimal Some Considerable

Premium on early completionProduct size range

Low<50 KDSI

Medium<300 KDSI

HighAll sizes

23

CSE

2102

CSE

2102

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

Development Mode Nominal effort Schedule Organic (PM)NOM=3.2(KDSI)1.05 TDEV=2.5(PMDEV))0.38 Semidetached (PM)NOM=3.0(KDSI)1.12 TDEV=2.5(PMDEV))0.35 Embedded (PM)NOM=2.8(KDSI)1.20 TDEV=2.5(PMDEV))0.32

24

CSE

2102

CSE

2102

COCOMO Scaling FactorsCOCOMO Scaling Factors

25

CSE

2102

CSE

2102

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

26

CSE

2102

CSE

2102

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

27

CSE

2102

CSE

2102

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?

28

CSE

2102

CSE

2102

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

29

CSE

2102

CSE

2102

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

30

CSE

2102

CSE

2102

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

31

CSE

2102

CSE

2102

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

32

CSE

2102

CSE

2102

RISK 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)

Typical SWE Risks (Boehm 1989)Typical SWE Risks (Boehm 1989)

33

CSE

2102

CSE

2102

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

Typical SWE Risks (Boehm 1989)Typical SWE Risks (Boehm 1989)

34

CSE

2102

CSE

2102

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 …

35

CSE

2102

CSE

2102

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?

36

CSE

2102

CSE

2102

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?

37

CSE

2102

CSE

2102

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?

38

CSE

2102

CSE

2102

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?

39

CSE

2102

CSE

2102

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 (WBS: Activity Tree of

Goals Root is major (Project) Goal Children are Subgoals to Achieve Parent Goal

40

CSE

2102

CSE

2102

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 Code generator

41

CSE

2102

CSE

2102

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)

1/1 4/1 7/1 10/1 1/1 4/1

start

finish

build scanner

build parser

build code generator

write manual

integration and testing

design

42

CSE

2102

CSE

2102

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

vacation

vacation

vacation

vacation

training

training

training

training

training

training

1/1 4/1 7/1 10/1

43

CSE

2102

CSE

2102

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 …

44

CSE

2102

CSE

2102

CT Insurance Overall Plan 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

45

CSE

2102

CSE

2102

Focused Plan for Consumer AffairsFocused Plan for Consumer Affairs

46

CSE

2102

CSE

2102

22ndnd Portion of Plan Portion of Plan

47

CSE

2102

CSE

2102

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 Determine Interdependencies Between Activities

48

CSE

2102

CSE

2102

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 Code generator

49

CSE

2102

CSE

2102

start design build parser

write manual

build code generator

build scanner

integration and testing

finish

Jan 1 Jan 3

March 7

March 7

March 7

March 7

Nov 14

Mar 17+

PERT Chart for Compiler ProjectPERT Chart for Compiler Project

50

CSE

2102

CSE

2102

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

51

CSE

2102

CSE

2102

Scheduling – What are the Pieces?Scheduling – What are the Pieces?

Divisions

Licensing Con. Aff. Mar. Con.

Classify Assign Inquiry Processing

Shared Tabs

52

CSE

2102

CSE

2102

Project Prototyping Plan

Tracks Who Does What When for Which Component

53

CSE

2102

CSE

2102

Project Management: Personnel Organization 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

54

CSE

2102

CSE

2102

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!

55

CSE

2102

CSE

2102

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?

56

CSE

2102

CSE

2102

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?

57

CSE

2102

CSE

2102

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

58

CSE

2102

CSE

2102

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

59

CSE

2102

CSE

2102

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

60

CSE

2102

CSE

2102

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)

61

CSE

2102

CSE

2102

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

Programmers Specialists

Chief programmer

Librarian BackupProgrammers

62

CSE

2102

CSE

2102

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

63

CSE

2102

CSE

2102

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

(a)(b)management structure communication pattern

64

CSE

2102

CSE

2102

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)

65

CSE

2102

CSE

2102

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

66

CSE

2102

CSE

2102

Mixed Control Team StructureMixed Control Team Structure

Senior engineers

Project manager

Junior engineers

(a) (b)

management structure communication pattern

67

CSE

2102

CSE

2102

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

68

CSE

2102

CSE

2102

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

Process is Tool Supported Requirements Engineering, Design, Coding,

Version & Configuration Management, Testing How is Software Built Today? What is Outsourcing?

69

CSE

2102

CSE

2102

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) 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

70

CSE

2102

CSE

2102

CT Insurance Detailed Team PlanningCT Insurance Detailed Team Planning

71

CSE

2102

CSE

2102

CT Insurance Detailed Team PlanningCT Insurance Detailed Team Planning

72

CSE

2102

CSE

2102

CT Insurance Detailed Team PlanningCT Insurance Detailed Team Planning

73

CSE

2102

CSE

2102

CT Insurance Detailed Team PlanningCT Insurance Detailed Team Planning

74

CSE

2102

CSE

2102

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

75

CSE

2102

CSE

2102

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

76

CSE

2102

CSE

2102

Decision TreeDecision Tree

System X

Build

Reuse

Buy

Contract

$380,000

$450,000

$350,000

$500,000

$210,000

$400,000

$275,000

$313,000

$490,000

Simple (.3)

Difficult (.7)

Minor (.4)

Major(.6)

Simple (.2)

Difficult (.8)

Minor (.7)

Major(.3)

with changes(.4)

without changes(.6)

77

CSE

2102

CSE

2102

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

Other DOIT Project: Reverse Engineer Design for Undocumented Code

78

CSE

2102

CSE

2102

Software Quality Assurance Recall Software Engineering Qualities

Correctness Correctness andand Reliability Reliability Robustness Robustness andand Performance Performance User Friendliness User Friendliness andand Verifiability Verifiability Maintenance Maintenance andand Reusability Reusability Repairability Repairability andand Evolvability Evolvability Portability, Understandability, Portability, Understandability, andand Interoperability Interoperability Productivity, Timeliness, Productivity, Timeliness, andand Visibility Visibility

Project Managers Select Qualities to be Assessed SQA Programs are Emerging, Particularly with

Respect to Critical Qualities (Software, Correctness, Robustness, Performance)

79

CSE

2102

CSE

2102

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

80

CSE

2102

CSE

2102

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: http://hissa.nist.gov/publications/nistir4909/

81

CSE

2102

CSE

2102

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

82

CSE

2102

CSE

2102

NIST Standard for SQANIST Standard for SQA

83

CSE

2102

CSE

2102

NIST Standard for SQANIST Standard for SQA

84

CSE

2102

CSE

2102

NIST Standard for SQANIST Standard for SQA

85

CSE

2102

CSE

2102

NIST Standard for SQANIST Standard for SQA

86

CSE

2102

CSE

2102

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?

87

CSE

2102

CSE

2102

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

88

CSE

2102

CSE

2102

Level 5: Optimizing

Level 4: Managed

Level 3: Defined

Level 2: Repeatable

Level 1: Initial

CMM Maturity LevelsCMM Maturity Levels

89

CSE

2102

CSE

2102

CMM Key Process AreasCMM Key Process Areas

CMM Level Key process areas Initial None Repeatable Requirements management

Software project planning Software project tracking and oversight Software subcontract management Software quality assurance Software configuration management

Defined Organization process focus Organization process definition Training program Integrated software management Software product engineering Intergroup coordination Peer reviews

Managed Software quality management Quantitative process management

90

CSE

2102

CSE

2102

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