1 / 14

Roles in a Project Team

Roles in a Project Team. By Sebastian Wagner And Michal Pieniazek. Team models to be covered:. RUP MSF Extreme programming. RUP (Rational Unified Process). What is RUP? RUP is more a framework (or a platform) than a standard methodology.

logan-hansen
Download Presentation

Roles in a Project Team

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Roles in a Project Team By Sebastian Wagner And Michal Pieniazek

  2. Team models to be covered: • RUP • MSF • Extreme programming

  3. RUP (Rational Unified Process) • What is RUP? • RUP is more a framework (or a platform) than a standard methodology. • RUP is a so-called proprietary software methodology and it was developed by Rational Software Corporation and first released in 1998. It is based on best practices used in the industry. Several industry-leading companies have helped in developing RUP and several leading companies such as Microsoft and Sun uses it in their software development. • RUP is a large methodology, which covers everything from project management to implementation and installation. • RUP is a software engineering process supported by a powerful set of tools such as UML and the object technology

  4. The RUP team model • Worker • A worker defines the behavior and responsibilities of an individual, or a group of individuals workingtogether as a team. You could regard a worker as a "hat" an individual can wear in the project. Oneindividual may wear many different hats. This is an important distinction because it is natural to think of aworker as the individual or team itself, but in the Unified Process the worker is more the role defining howthe individuals should carry out the work..

  5. Team structure • Enterprise/business/mission modeling team. Developsenterprise business/context models in order to set system contextand derive system requirements. • System analysis team. Builds the analysis model, including theUML subsystem and localities. This team also develops andmaintains the derived requirements to the analysis, and it maybuild the analysis-level process and data models.

  6. Team structure • Design and implementation teams. Responsible for the detaileddesign and implementation of components within a given viewpoint. Subsystem teams. Develop detailed class design and associated software modules for one or more subsystems. Locality teams. Develop detailed hardware specifications,design, and hardware components for one or more localities. Other teams. Might include data modeling andcomputer/human interaction.

  7. Team Structure • Build and integration team. Receives components developed by the development and implementation teams and builds system iterations. • System test team. Plans, executes, and reports on system tests. • Operation and maintenance team. Performs field delivery, tracksproblems, prioritizes change requests, and delivers updates andpatches. • Project management team. Performs ongoing iteration planning,context management, and stakeholder communications.

  8. Relationship between teams

  9. XP (Xtreme Programming) What is XP? • Extreme Programming (XP) is a discipline of software development based on values of simplicity, communication, feedback, andcourage. • It works by bringing the whole team together inthe presence of simple practices, with enough feedback to enable the team to see where theyare and to tune the practices to their unique situation.

  10. XP team structure Customer • Writes User Stories and specifies Functional Tests • Sets priorities, explains stories • May or may not be an end-user • Has authority to decide questions about the stories Programmer • Estimates stories • Defines Tasks from stories, and estimates • Implements Stories and Unit Tests

  11. XP team structure continued Coach • Watches everything, sends obscure signals, makes sure the project stayson course • Helps with anything • Applies “Rolled Up Newspaper” as required Tracker • Monitors Programmers’ progress, takes action if things seemto be going off track. • Actions include setting up a meeting with Customer, askingCoach or another Programmer to help

  12. XP team structure continued Tester • Implements and runs Functional Tests (not Unit Tests!) • Graphs results, and makes sure people know when testresults decline. Doomsayer • Ensures that everybody knows the risks involved • Ensures that bad news isn't hidden, glossedover, or blownout of proportion

  13. XP team structure continued… again… Manager • Schedules meetings (e.g. Iteration Plan, Release Plan), makessure the meeting process is followed, records results ofmeeting for future reporting, and passes to the Tracker • Possibly responsible to the Gold Owner. • Goes to meetings, brings back useful information • Pays for pizza Gold Owner • The person funding the project, which may or may not be thesame as the Customer

  14. WWW: rup_bestpractices.pdf IBM.com EnablingSoftwareQualityWithXP-Paper.pdf IntroToXpTomKubit.pdf http://www.xprogramming.com Bibliography

More Related