Slide 1 Teams l Most products are too large to be completed by a single software professional with the given time constraints l You will work within a.

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

©Ian Sommerville 2000 Software Engineering, 7th edition. Chapter 25Slide 1 Managing people l Managing people working as individuals and in groups l People.
1 Teams Xiaojun Qi. 2 Team Organization Suppose that a product can be accomplished by 1 person-year of programming. If this product must be completed.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development.
Software Teams & Tools 1 Software Engineering Teams Most projects are too large for a single s/ware professional Employing teams helps projects to be delivered.
Inspection (c) 2007 Mauro Pezzè & Michal Young Ch 18, slide 1 Photo credit jurvetson on Flickr.com; creative commons attribution license.
SBSE Course 3. EA applications to SE Analysis Design Implementation Testing Reference: Evolutionary Computing in Search-Based Software Engineering Leo.
The Human Side of Project Management
1 Postdelivery Maintenance Xiaojun Qi. 2 Why Postdelivery Maintenance Is Necessary Corrective maintenance: To correct residual faults –Analysis, design,
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 2 Software Processes.
Copyright 2002 Prentice-Hall, Inc. Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer.
CS 501: Software Engineering
Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design Third Edition.
Teams.
Xtreme Programming. Software Life Cycle The activities that take place between the time software program is first conceived and the time it is finally.
Software evolution.
Software Quality Assurance
PROJECT MANAGEMENT CONCEPTS & TEAMS
VENDORS, CONSULTANTS AND USERS
Chapter 9 – Software Evolution and Maintenance
The Project AH Computing. Functional Requirements  What the product must do!  Examples attractive welcome screen all options available as clickable.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Extreme Programming.
Lecture # 22 Software Evolution
Computers & Employment By Andrew Attard and Stephen Calleja.
Chapter 3 – Agile Software Development 1Chapter 3 Agile software development.
CHAPTER 4 TEAMS.
Copyright 2002 Prentice-Hall, Inc. Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design.
Copyright 2002 Prentice-Hall, Inc. Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer.
Software Engineering Teams James Gain
Software Engineering Management Lecture 1 The Software Process.
Extreme/Agile Programming Prabhaker Mateti. ACK These slides are collected from many authors along with a few of mine. Many thanks to all these authors.
MD Digital Government Summit, June 26, Maryland Project Management Oversight & System Development Life Cycle (SDLC) Robert Krauss MD Digital Government.
Slide 4.1 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented and Classical Software Engineering Eighth Edition, WCB/McGraw-Hill,
Copyright 2002 Prentice-Hall, Inc. 1.1 Modern Systems Analysis and Design Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 1 The Systems Development.
Rapid software development 1. Topics covered Agile methods Extreme programming Rapid application development Software prototyping 2.
Extreme Programming (XP). Agile Software Development Paradigm Values individuals and interactions over processes and tools. Values working software over.
SYSTEMS ANALYSIS AND DESIGN LIFE CYCLE
Slide 4.1 © The McGraw-Hill Companies, 2007 Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2007 Stephen R. Schach.
Managing people Managing people working as individuals and in groups People are an organisation’s most important assets 1.
CSC 395 – Software Engineering Lecture 5: Teams -or- How to Motivate and Manage the Unwashed Masses.
1 CS 501 Spring 2004 CS 501: Software Engineering Lecture 2 Software Processes.
Slide 4.1 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach
Slide 4.1 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented Software Engineering WCB/McGraw-Hill, 2008 Stephen R.
Slide 4.1 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented Software Engineering WCB/McGraw-Hill, 2008 Stephen R.
4.1/62 TEAMS 4.2/62 Overview l Introduction, l Democratic team approach, l Classical chief programmer team approach, l Beyond chief programmer and democratic.
Software Engineering At Glance. Why We Need Software Engineering? The aim of software engineering is to solve the software crisis Software is delivered.
CS451 Software Implementation and Integration Yugi Lee STB #555 (816) Note: This lecture was designed.
CS451 Software Maintenance Yugi Lee STB #555 (816) Note: This lecture was designed based on Stephen Schach’s.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2010 Stephen R. Schach
Software Project Development Teams. Team Organization Goal: organize teams so that they are productive teams can be used in every phase, especially implementation.
Object-Oriented and Classical Software Engineering Eighth Edition, WCB/McGraw-Hill Stephen R. Schach 1.
INTRODUCTION: Project management involves the planning, monitoring, and control of the people, process, and events that occur as – software evolves from.
CS223: Software Engineering Lecture 18: The XP. Recap Introduction to Agile Methodology Customer centric approach Issues of Agile methodology Where to.
Slide 4.1 TEAMS. Slide 4.2 Overview l Team organization l Democratic team approach l Classical chief programmer team approach l Beyond chief programmer.
Teamwork and Group Dynamics A few tips on effective teamwork, meetings, and presentations Stuart Faulk From lectures by Michal Young, 1988, Anthony Hornoff.
Chapter 1 The Systems Development Environment
Chapter 1 The Systems Development Environment
Software Project Management
Configuration Management Why do we need it? What does it do?
Lecture 3: Organizing Teams
Chapter 1 The Systems Development Environment
Object-Oriented and Classical Software Engineering Eighth Edition, WCB/McGraw-Hill, 2011 Stephen R. Schach 1.
Chapter 1 The Systems Development Environment
Characteristics of an Effective Team
Applied Software Project Management
Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2007 Stephen R. Schach
Chapter 1 The Systems Development Environment
Presentation transcript:

Slide 1 Teams l Most products are too large to be completed by a single software professional with the given time constraints l You will work within a team of professionals

Slide 2 Teams l From Brooks’ Mythical Man Month, any successful team needs: A goal A division of labor A leader

Slide 3 Programming Teams l A product must be completed within 3 months, but 1 person-year of programming is still needed l Proposed Solution If one programmer can code the product in 1 year, four programmers can do it in 3 months l Reality Four programmers will probably take nearly a year The quality of the product is usually lower

Slide 4 Task Sharing l If one farm hand can pick a strawberry field in 10 days, ten farm hands can pick same strawberry field in 1 day l One woman can produce a baby in 9 months, but nine women cannot possibly produce that baby in 1 month

Slide 5 Task Sharing l Unlike baby production, it is possible to share coding tasks between members of team l Unlike strawberry picking, team members must interact in meaningful and effective way Leads to communication problems

Slide 6 Communications Problems l Example: There are three channels of communication between 3 programmers working on project. The deadline is rapidly approaching but the code is not nearly complete l “Obvious” solution: Add a fourth programmer to the team

Slide 7 Team Organization l Teams are used throughout software production l Especially used during implementation phase

Slide 8 Team Organization l Two extreme approaches to team organization Democratic teams Chief programmer teams

Slide 9 Democratic Team Approach l Problem: programmers can be highly attached to their code l Proposed solution: egoless programming

Slide 10 Democratic Team Approach l Proposed solution: egoless programming Restructure the social environment Restructure programmers’ values Encourage team members to find faults in code A fault must be considered a normal and accepted event The team as whole will develop a group identity Modules will “belong” to the team as whole

Slide 11 Democratic Team Approach l A group of up to 10 egoless programmers l Group working for a common cause with no single leader l Emphasizes team identity and mutual respect

Slide 12 Strengths of Democratic Team Approach l Democratic teams are enormously productive and produce high-quality code l They work best when the problem is difficult l They function well in a research environment

Slide 13 Weaknesses of Democratic Team Approach l Management issues l Egos still involved l Number of communication channels involved

Slide 14 Weaknesses of Democratic Team Approach l A 6-person team has fifteen 2-person communication channels

Slide 15 Chief Programmer Teams l Six programmers, but now only 5 lines of communication

Slide 16 Chief Programmer Teams l Two key aspects Specialization Each member of team carries out only those tasks for which he/she has been trained Hierarchy The chief programmer directs all actions of the other members of the team and is responsible for every line of code

Slide 17 Roles of Classical Chief Programmer Teams

Slide 18 Roles of Classical Chief Programmer Teams l Chief programmer Successful manager and highly skilled programmer Does the architectural design Allocates coding among the team members Writes the critical (or complex) sections of code Handles all the interfacing issues Reviews the work of the other team members Is personally responsible for every line of code

Slide 19 Roles of Classical Chief Programmer Teams l Back-up programmer Must be in every way as competent as the chief programmer Must know as much about the project as the chief programmer Does black-box test case planning and other tasks that are independent of the design process

Slide 20 Roles of Classical Chief Programmer Teams l Programming secretary (librarian) A highly skilled, well paid, central member of the chief programmer team Responsible for maintaining the program production library (documentation of project) Programmers hand their source code to the secretary who is responsible for Conversion to machine-readable form, Compilation, linking, loading, execution, and running test cases

Slide 21 Roles of Classical Chief Programmer Teams l Programmers work on detailed design and coding under the direction of the chief programmer All other aspects are handled by the programming secretary

Slide 22 The New York Times Project l Chief programmer team concept first used in 1971 by IBM to automate the clippings data bank of The New York Times l Chief programmer—F. Terry Baker

Slide 23 The New York Times Project l 83,000 source lines of code (LOC) were written in 22 calendar months, representing 11 person- years l After the first year, only the file maintenance system had been written (12,000 LOC) l Most code was written in the last 6 months l 21 faults were detected in the first 5 weeks of acceptance testing l 25 further faults were detected in the first year of operation

Slide 24 The New York Times Project l Principal programmers averaged one detected fault and 10,000 LOC per person-year l The file maintenance system, delivered 1 week after coding was completed, operated 20 months before a single failure occurred l Almost half the subprograms (usually 200 to 400 lines of PL/I) were correct at first compilation

Slide 25 Why Was the NYT Project Such a Success? l Prestige project for IBM First real trial for PL/I (developed by IBM) IBM, with superb software experts, used its best people l Very strong technical backup l F. Terry Baker Superprogrammer Superb manager and leader His skills, enthusiasm, and personality “carried” the project

Slide 26 Strengths of Chief Programmer Team l Proven success l Numerous successful projects have used variants of Chief Programmer Team

Slide 27 Weaknesses of Chief Programmer Team l Chief programmer must be a highly skilled programmer and a successful manager l Back-up programmer must be as good as the chief programmer l Programming secretary does only paperwork all day

Slide 28 Beyond CP and Democratic Teams l We need ways to organize teams that Make use of the strengths of democratic teams and chief programmer teams, and Can handle teams of 20 (or 120) programmers

Slide 29 Beyond CP and Democratic Teams

Slide 30 Larger Projects

Slide 31 Extreme Programming Teams l Pair programming All code is written by two programmers sharing a computer

Slide 32 Advantages of Pair Programming l Test cases drawn up by one member of team l Knowledge not all lost if one programmer leaves l Inexperienced programmers can learn l Centralized computers promote egoless programming

Slide 33 Team Organization l There is no one solution to the problem of team organization l The “correct” way depends on The product The outlook of the leaders of the organization Previous experience with various team structures