1 CSE 2102 CSE 2102 Chapter 8: Management of SWE Prof. Steven A. Demurjian Computer Science &...
-
Upload
eileen-harper -
Category
Documents
-
view
218 -
download
1
Transcript of 1 CSE 2102 CSE 2102 Chapter 8: Management of SWE Prof. Steven A. Demurjian Computer Science &...
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
[email protected]://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.
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
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
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
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
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
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