View
4
Download
0
Category
Preview:
Citation preview
1
Collaborative Software Design & Development
© 2005, Dewayne E Perry
Lecture 4
EE 382V – Spring 2008
Collaborative Software Design & Development
*Teams*
Dewayne E PerryENS 623A
Office Hours: T/Th
10:00-11:00perry @ ece.utexas.edu
www.ece.utexas.edu/~perry/education/382V-s08/
2
Collaborative Software Design & Development Lecture 4
© 2005, Dewayne E Perry EE 382V – Spring 2008
Teamwork According to Dilbert
3
Collaborative Software Design & Development Lecture 4
© 2005, Dewayne E Perry EE 382V – Spring 2008
Study ContextSwindon in the UK, Nuernberg in GermanyEnglish in Swindon, German in NuernbergFirst product in Nuernberg, this second driven managerially from SwindonExisting Team in Nuernberg, new team in SwindonDomain experience in both places
Swindon team hired away from Motorola etcTelecom domainAt the end of project, success and failure
Testing team – considered to be very successfulIntegration team – considered to be a failureWhy?
4
Collaborative Software Design & Development Lecture 4
© 2005, Dewayne E Perry EE 382V – Spring 2008
Forming TeamsSuccess Factors
Do effective planningSelf-managingGet the work done
Factors in forming teamsI
Inception and acceptance of project goalsII
Agreement on solution of technical issues, attaining goalsIII
Resolving conflicts and political issuesIV
attaining goals, execution of requirements –
ie, doing itCritical factors
Need time to build trustFace to face is necessary to build working relationshipsNeed clear agreement on team goalsMatch communication bandwidth to intensive interfaces
5
Collaborative Software Design & Development Lecture 4
© 2005, Dewayne E Perry EE 382V – Spring 2008
Test Team SuccessMirrored team formation theoryContributing factors
Managerial strategiesContext for self managementShared vision among team leadersWork critical issues ahead of time, not when criticalOptimize critical issues by divide and conquer
ProactiveIsolate critical issuesImprove processes, for example
Initially, hand coded testsAutomated regression testingAutomate test generation and testing
6
Collaborative Software Design & Development Lecture 4
© 2005, Dewayne E Perry EE 382V – Spring 2008
Conway’s Law and the Integration TeamConway’s Lay:
The structure of your system mirrors the structure of your organization
Why?Organizational structure governed by management structure not project structureModules are divisions of laborSystems components are assigned as responsibilities to people and they reside in organizationsDifferent stages of the product are often produced by different parts of the organization, eg
Requirements and architecture in one organizationDesign and code in anotherSystem build and integration in yet anotherTesting and quality control in still another
7
Collaborative Software Design & Development Lecture 4
© 2005, Dewayne E Perry EE 382V – Spring 2008
Conway and Geographical DistributionProblem exacerbated in geographically separated organizationProblems in geographically separated development
Informal communication – eg75 minutes per day, informal, short, unplanned interactionsFace to face interactions
Formal communicationsNeed bandwidth appropriate to needs of communication
Inherently unpredictable aspectsNeed spontaneous communication
Unanticipated breakdowns in communication lead to delay, inefficiency and frustration
8
Collaborative Software Design & Development Lecture 4
© 2005, Dewayne E Perry EE 382V – Spring 2008
Why Projects FailGutless estimation
Lack of ability to predict (well)Monitoring progress is difficultProject plans seldom are changed except at the last minuteBrooks Law:
Adding more people to a late project only make it laterTime to acclimatize new people to projectMore communication overhead
9
Collaborative Software Design & Development Lecture 4
© 2005, Dewayne E Perry EE 382V – Spring 2008
IntegrationIntegration team constrained by
The integration planComponent interface specificationsSoftware processesDocumentation
Integration PlanDependence on overall development plan
In this case overly optimisticComponents have to be ready at the right time
Changing requirements, schedulesInadequate substrate for the product/project
Both software and hardwareLack of alignment
10
Collaborative Software Design & Development Lecture 4
© 2005, Dewayne E Perry EE 382V – Spring 2008
IntegrationInterface Specifications
Used ORBIX (based on CORBA) to support interface specificationInterfaces + simulators for others use
Hides problems of real implementationCode based understanding of actual interfaceInterface management based on substrate
Different assumptions etc
11
Collaborative Software Design & Development Lecture 4
© 2005, Dewayne E Perry EE 382V – Spring 2008
IntegrationSoftware Processes
Weaknesses in process uncovered in integrationSite isolation – due to architecture component assignment
Initially a good decision, paid for it laterProcess consolidation at one site
Problem: timely feedbackDifferent environments in different sites
Change Control BoardInitially at one site – knew little about code at other siteLack of knowledge of the legacy system built onAdded architect from the other cite to CCB
12
Collaborative Software Design & Development Lecture 4
© 2005, Dewayne E Perry EE 382V – Spring 2008
IntegrationDocumentation of processes and design decisions
Technologies that were supposed to help did not meet expectationsDue to time pressures, proceeded with coding
Not an unusual state of affairsBUT, code diverged from designThis impacts integration significantly
Shift in role of documentationInitially, focus on designLater, oriented towards change management process
Documentation omissionsIn substrate docs – significant problemsIn project - also
13
Collaborative Software Design & Development Lecture 4
© 2005, Dewayne E Perry EE 382V – Spring 2008
Success BarriersLack of informal unplanned interactionNot knowing who to contact about what
Lack of necessary informationThe cost of initiating contact – high when distributed
Who is availableTime differencesLack of responsiveness
Ability to communicate effectivelyDifferent languages and culturesCommunication mediums – face to face vs phones, eg
Lack of trust/willingness to communicate openly
14
Collaborative Software Design & Development Lecture 4
© 2005, Dewayne E Perry EE 382V – Spring 2008
Towards Successful TeamsArchitecture centric –
Keep interfaces clean and distinctAs modular as possible
Need stable processesFront load travel
face to face to build trustTo create liaisons
Tools toFind organizational informationCheck availabilityEffective cross site meeting, planned and unplanned
15
Collaborative Software Design & Development Lecture 4
© 2005, Dewayne E Perry EE 382V – Spring 2008
A Common Syndrome in Business/Academia
Punish the competentReward the incompetentPromote the uninvolved (cartoon off just a bit here)
Recommended