Sofware Team Organizations
•Download as PPT, PDF•
13 likes•6,360 views
Sofware Team Organizations
![Overview ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Sofware Team Organizations
Similar to Sofware Team Organizations (20)
More from Deniz Kılınç
Recently uploaded
Recently uploaded (20)
Sofware Team Organizations
- 1. Software Team Organizations Volkan ABUR Deniz KILINÇ
- 45. Preliminary Investigation Phase Tasks Ref: Whitten et al, " System Analysis & Design, 5th ed., McGraw
- 46. Problem Analysis Phase Context Ref: Ibid
- 47. Requirements Analysis Phase Tasks Ref: Ibid
- 49. MSF (Microsoft Solutions Framework) Team Model
- 50. Problems, problems, problems... “ This thing is unpredictable – we keep discovering new problems” “ It’s just too difficult to use” “ We couldn’t get the information we needed to do our work” “ We were unaware of how the work of other team members affected our work” “ The project was late and over budget” “ What was built really isn’t what we needed” “ It doesn’t meet our expectations – we’re not happy” “ We didn’t understand clearly what we were supposed to do” “ We can’t get it to operate well in our environment”
- 51. 2W, 1H (What, Who, How) Establish good communications Goals to Success Deliver within project constraints Build to specifications Release with issues identified and addressed Deploy smoothly and prepare well for ongoing operations Enhance user effectiveness “ The project was late and over budget ” “ What was built really isn’t what we needed ” “ This thing is unpredictable – we keep discovering new problems ” “ We can’t get it to operate well in our environment ” “ It’s just too difficult to use ” Problems Satisfy customers Owner “ It doesn’t meet our expectations – we’re not happy ” ? ? ? ? ? ? “ Needed information is not shared timely to all who need it ” ?
- 52. MSF Team Model Clear Communication Delivering the solution within project constraints Satisfied customers Enhanced user effectiveness Smooth deployment and ongoing operations Approval for release only after all quality issues are identified and addressed Building to specification Development Test Release Management User Experience Product Management Program Management
- 58. Team Model – Role Clusters Communication Development Test Release Management User Experience Product Management Program Management
- 59. Functional areas Responsibilities Tasks Program management Project management Drive overall solution design Manage functional specification Maintain traceability map Liaise with other project teams on interoperability issues Solution architecture Example Role cluster (role)
- 60. Functional Areas of Role Clusters Business value Marketing Customer advocacy Product planning Project management Solution architecture Process assurance Administrative services Test planning Test engineering Test reporting Infrastructure Support Operations Logistics Commercial release management Accessibility Internationalization User advocacy Training/support material Usability research and testing User interface design Technology consulting Implementation architecture and design Application development Infrastructure development Development Test Release Management User Experience Product Management Program Management
- 61. Extended Team Operations and Support Groups Technology Focus Business Focus Users Project Sponsor Customer Technology Architects and Steering Committees Help Desk Project Team Development Test Release Management Program Management User Experience Product Management
- 63. Lead and Feature Teams Desktop Feature Team Program Management User Experience Development Test File and Print Feature Team Program Management User Experience Development Test Messaging Feature Team Program Management User Experience Development Test Lead Team
- 65. Small Team Example Release Management User Experience Product Management Test Program Management Development
Editor's Notes
- Adding an extra programmer to a late project means everyone needs to get this person up to date and communicate with them This makes the project even later. This is known as Brook’s Law
- Teaching Notes This is called a task diagram for a phase. It is only a guideline. Each project will adapt these tasks to the project at hard. Tasks may be added, split, or deleted according to the methodology and route used. The dashed line is a control flow (as contrasted to a solid data flow). In this case, it represents a decision that determines whether the next task is necessary.
- No additional notes
- Teaching Notes Some of the tasks are completed in parallel.