560 likes | 670 Views
Software Engineering Process II. TSP Roles and Overview INFO 637 Glenn Booker. TSP Roles. The PSP had you doing pretty much everything yourself – a veritable jack (or jill) of all trades The TSP breaks roles down so that each leadership function can be more specialized
E N D
Software Engineering Process II TSP Roles and Overview INFO 637 Glenn Booker Lecture #2
TSP Roles • The PSP had you doing pretty much everything yourself – a veritable jack (or jill) of all trades • The TSP breaks roles down so that each leadership function can be more specialized • While each role represents about one person for class, in reality some roles may need more than one person to fulfill them Lecture #2
TSP Roles • The leadership roles are: • Team Leader • Development Manager • Planning Manager • Quality and Process Manager • Support Manager Lecture #2
TSP Roles • When choosing roles within your project, consider • What roles have you done before? • What roles interest you? • What roles do you think you can do? • Consider the possibility of stretching your skills – try a role which is unlike any you’ve done before! Lecture #2
Development Engineer • In addition to one of the previous roles, everyone is also a Development Engineer • This is a really important point! • Hence you will be producing your own products (code, documents, etc.) and fulfilling one of the leadership roles on slide #3 Lecture #2
Development Engineer Activities • This means that during your project, you need to: • Record your time in the time recording log (LOGT) • Enter the week number when each task is completed • Update TASK and SCHEDULE templates • Record all defects for your products in your defect recording log (LOGD) Lecture #2
Development Engineer Activities • Enter the size of each product or component • Submit updated copies of completed TASK, SCHEDULE, and WEEK forms to the planning manager and the instructor at the start of each week • When you complete a system or component task, update the SUMP and SUMQ forms and give copies to the quality/process manager and the instructor Lecture #2
Development Engineer Activities • Report all changes in configuration-controlled components to the support manager • Report issues to be tracked to the support manager for the issue tracking log (ITL) • Above all, examine your data and use it to help you produce quality work! Lecture #2
Team Leader Goals • The team leader is the equivalent of the project manager for the team • Goals of the team leader include: • Be a cooperative and effective team member • Build and maintain an effective team • Motivate all team members to work aggressively on the project Lecture #2
Team Leader Goals • Resolve all the issues team members bring to you • Keep the instructor fully informed about the team’s progress • Perform effectively as the team’s meeting facilitator Lecture #2
Team Leader Skills Needed • You enjoy acting as the leader • You are able to identify key issues and make objective decisions • You can take unpopular positions and can push people to do difficult tasks • You respect the people you are leading Lecture #2
Team Leader Activities • Motivate the team to perform their tasks • Run the weekly team meeting • Report weekly status • Help the team to allocate tasks • Act as a facilitator and timekeeper for team meetings • Maintain the project notebook Lecture #2
Team Leader Activities • Lead the team in producing the development cycle report • Act as a development engineer Lecture #2
Development Manager Goals • The development manager is the leader for creating the product itself – sort of the software architect • Their goals are: • Be a cooperative and effective team member • Produce a superior product • Fully utilize the team members’ skills and abilities Lecture #2
Development Manager Skills • You like to build things • You want to be (or are!) a software engineer and want to lead design and development for a product • You are a competent designer • You are familiar with design methods • You are will to listen to and use others’ ideas Lecture #2
Development Manager Activities • Lead producing the development strategy • Lead producing the preliminary size and time estimates for the products • Lead development of the software requirements specification • Lead producing the high level design • Lead producing the software design specifications Lecture #2
Development Manager Activities • Lead implementing the product • Lead developing the test plans • Lead developing the test materials and running the tests • Lead producing the product user’s documentation Lecture #2
Development Manager Activities • Participate in producing the development cycle report • Act as a development engineer Lecture #2
Planning Manager Goals • The planning manager is responsible for managing the plan for your project • Their goals are: • Be a cooperative and effective team member • Produce a complete plan for the team, and for each team member • Accurately report team status every week Lecture #2
Planning Manager Skills • You have a logical and orderly mind • You tend to plan your work when you can • You like process data, and feel better if you know if you’re on schedule • You think planning is important, and can help your teammates track and measure their work Lecture #2
Planning Manager Activities • Lead producing the task plan for each development cycle • Lead producing the schedule for each development cycle • Lead producing the balanced team development plan • Track the team’s progress against the plan Lecture #2
Planning Manager Activities • Participate in producing the development cycle report • Act as a development engineer Lecture #2
Process and Quality Manager Goals • This role is to ensure the TSP process is being followed, and to verify the quality of your team’s products • Their goals are: • Be a cooperative and effective team member • Ensure team members correctly report and use TSP process data Lecture #2
Process and Quality Manager Goals • Ensure team follows the TSP quality plan and produces a quality product • Ensure team inspections are properly moderated and reported • Ensure team meetings are accurately reported, and reports are put in the team notebook Lecture #2
Process and Quality Manager Skills • You are concerned about software quality • You are interested in process and product measurements • You are aware of inspection and review methods • You can give constructive reviews Lecture #2
Process and Quality Manager Activities • Lead producing and tracking the quality plan • Alert team leader and instructor if there are quality problems • Lead defining and documenting team processes and conducting process improvement Lecture #2
Process and Quality Manager Activities • Establish and maintain the team’s development standards • Review and approve all products before their submission to the Configuration Control Board (CCB) • Act as the team’s inspection moderator • Act as a recorder in all team meetings Lecture #2
Process and Quality Manager Activities • Participate in producing the development cycle report • Act as a development engineer Lecture #2
Support Manager Goals • The support manager is focused mostly on configuration management and risk management • Their goals are: • Be a cooperative and effective team member • Ensure the team has tools and methods needed to support their work Lecture #2
Support Manager Goals • Ensure only authorized changes are made to baselined products • Ensure team’s risks and issues are recorded in the issue-tracking system, and reported each week • Ensure team meets its reuse goals during the development cycle Lecture #2
Support Manager Skills • Lead determining support needs and obtaining needed tools and facilities • Chair the CCB and manage the change control system • Manage the configuration management system • Maintain the system glossary Lecture #2
Support Manager Skills • Maintain team’s issue- and risk-tracking system • Act as team’s reuse advocate • Participate in producing the development cycle report • Act as a development engineer Lecture #2
Common Features • Notice that every role has the common goal of: • Be a cooperative and effective team member • All roles have the activity, as mentioned previously, of: • Act as a development engineer Lecture #2
Common Features • And most roles also have the activity • Participate in producing the development cycle report • So the challenge of teamwork is to balance shared tasks with role-specific ones, and still produce a viable product along the way! Lecture #2
Team Size Considerations • As noted on page xiv of the Preface: • If your team has four people, the support manager activities get divided among everyone • If your team has five people, each person gets one leading role • If your team has six people, the quality and process manager role is split in two; quality manager and process manager Lecture #2
TSP Overview Lecture #2
Iterative Approach • The TSP is based on an iterative approach, where cycles are used to develop major parts of the product incrementally • We’ll follow the first cycle only, and then see how things would follow for subsequent cycles Lecture #2
TSP Overview • The Team Software Process has eight steps or phases • Launch • Development Strategy • Development Plan • Define Requirements • Design • Implementation Lecture #2
TSP Overview • Integration and System Testing • Postmortem • We’ll skim the first seven of these this week, before working through one cycle • At the end of the course, we’ll do the postmortem and address miscellaneous teamwork issues Lecture #2
Launching a Team Project • The use of a formal launch step helps ensure roles are clearly assigned, and allows conscious team building to take place • Script for this step includes: • Understand your product’s objectives • Develop team and individual goals • Conduct an initial team meeting to establish roles and initial due dates Lecture #2
Development Strategy • This is the earliest planning stage in the TSP, where a conceptual plan, development strategy, and estimates are developed • Risk assessment is also done, and the configuration management plan is drafted • These tasks are needed to obtain commitment to the project before further investigation is done Lecture #2
Development Strategy • Script includes: • Define the strategy criteria; what product, process, and quality criteria can be defined, in spite of minimal product knowledge? • Produce the conceptual design; outline what the product will be like • Select development strategy; when will different kinds of functions be created? Lecture #2
Development Strategy • Produce preliminary size and time estimates • Identify and evaluate risks • Produce configuration management (CM) plan Lecture #2
Development Plan • This is a project management plan, to help make sure the right steps are done in the right order • We need to define, in detail, what will be done and who’ll do it • Need to balance workload so people are well utilized Lecture #2
Development Plan • Tasks include: • Start with size estimates • Produce task plan • Produce schedule plan • Produce the quality plan • Produce engineer plans for each person • Balance the workload for the sake of fairness and efficiency Lecture #2
Define Requirements • This is definition of the software requirements specification (SRS) • Defines what the product will be able to do, and how well it will be able to do it (speed, reliability, etc.) • Key objective is to ensure that your product will meet the customer’s needs Lecture #2
Define Requirements • Clear requirements also form the basis for the change control system, which manages changes in the requirements • Steps include: • Clarifying the product needs • Define and document requirements • Develop system test plan, to prove requirements were met Lecture #2
Define Requirements • Do formal verification of requirements and test plan • Verify requirements with customer Lecture #2
Design • The TSP is not limited to any particular design methodology (object oriented, information engineering, etc.) • Hence each team needs to choose the design method for their project • Design elaborates on the conceptual design • This step is only high level design Lecture #2
Design • Design is usually based on breaking a system down into components • Then the requirements for each component are determined • Keep breaking down components until they are small enough to be easily understood, and created by one person Lecture #2