CS 350, slide set 6 M. Overstreet Old Dominion University Fall 2005.

Slides:



Advertisements
Similar presentations
SEP1 - 1 Introduction to Software Engineering Processes SWENET SEP1 Module Developed with support from the National Science Foundation.
Advertisements

More CMM Part Two : Details.
Software Project Management Lecture # 11. Outline Quality Management ( chapter 26 - Pressman )  Software reviews  Formal Inspections & Technical Reviews.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #7 Software Engineering.
Sponsored by the U.S. Department of Defense © 2002 by Carnegie Mellon University July 2002 Pittsburgh, PA Lecture 6: Team Planning.
Delegation Skills.
W5HH Principle As applied to Software Projects
Performance Appraisal System Update
Gu & Maher University of Sydney, October 2004 DECO2005 Monitoring Team Process.
Stepan Potiyenko ISS Sr.SW Developer.
Personal Software Process
SE 555 Software Requirements & Specification Requirements Validation.
5/29/2007SE TSP Launch1 Team Software Project (TSP) May 29, 2007 Launch/Strategy Team Formation.
Course Technology Chapter 3: Project Integration Management.
8/7/2007SE _8_07_Misc_PostMortem.ppt1 Additional Topics & Team Project Post-Mortem.
Planning. SDLC Planning Analysis Design Implementation.
LOGO TEAM ASSIGNMENT 02 TEAM 7 – K15T02 The Big Goal.
Capstone Design Project (CDP) Civil Engineering Department First Semester 1431/1432 H 10/14/20091 King Saud University, Civil Engineering Department.
Fundamental of Software Project Management
CMM Level 3 KPA’s CS4320 Fall Organizational Process Focus (Goals) Software process development and improvement activities are coordinated across.
INFO 637Lecture #31 Software Engineering Process II Launching & Strategy INFO 637 Glenn Booker.
Team Launch Introduction. Real projects are large and complex, and most software is created by teams Merely throwing people together does not result in.
Copyright Course Technology 1999
1 Chapter 4: Project Integration Management. 2 Learning Objectives Describe an overall framework for project integration management as it relates to the.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 10: Testing and Inspecting to Ensure High Quality Part 4:
CS 350, slide set 7 M. Overstreet Old Dominion University Spring 2005.
INFO 637Lecture #41 Software Engineering Process II Development Plan INFO 637 Glenn Booker.
CS 350, slide set 8 M. Overstreet Old Dominion University Spring 2005.
Introduction to Software Engineering LECTURE 2 By Umm-e-Laila 1Compiled by: Umm-e-Laila.
CS 350, slide set 6 M. Overstreet Old Dominion University Spring 2005.
Preparing for the Launch Mohammed El- Affendi. Launch Major Tasks  The Launch is performed according to script “LAU1”, table 3.1 in the book (page 39),
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
1.  Describe an overall framework for project integration management ◦ RelatIion to the other project management knowledge areas and the project life.
CS 350, slide set 10 M. Overstreet Old Dominion University Spring 2006.
INFO 637Lecture #21 Software Engineering Process II TSP Roles and Overview INFO 637 Glenn Booker.
Team Assignment 15 Team 04 Class K15T2. Agenda 1. Introduction 2. Measurement process 3. GQM 4. Strength Weakness of metrics.
Disciplined Software Engineering Lecture #7 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
Team Work What is a team? Building Effective Teams Managing yourself Team obligations Common Team problems Risk Management Meeting techniques cs3141, Fall.
© 1998 Carnegie Mellon UniversityTutorial The Personal Software Process (PSP) The overview of the PSP that follows has been built from material made.
CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 2 The Software Process Discussion of the Software Process: Process Framework,
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Georgia Institute of Technology CS 4320 Fall 2003.
INFO 637Lecture #101 Software Engineering Process II Review INFO 637 Glenn Booker.
Team Software Process (TSPi) CS4320 Fall TSP Strategy Provide a simple process framework based on the PSP. Use modest, well-defined problems. Develop.
CS 350, slide set 5 M. Overstreet Old Dominion University Spring 2005.
CHAPTER 9 INSPECTIONS AS AN UP-FRONT QUALITY TECHNIQUE
INFO 636 Software Engineering Process I Prof. Glenn Booker Week 9 – Quality Management 1INFO636 Week 9.
INFO 424 Team Project Practicum Week 2 - Launch report, Project tracking, Review report Glenn Booker Notes largely from Prof. Hislop.
T Iteration Demo Group name [PP|I1|I2] Iteration
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 7 1 Design and Code Reviews - Overview What are design and code.
Sponsored by the U.S. Department of Defense © 2002 by Carnegie Mellon University July 2002 PSP-TSPi Faculty Workshop Pittsburgh, PA Lecture.
1 EMS Fundamentals An Introduction to the EMS Process Roadmap AASHTO EMS Workshop.
THE POSTMORTEM Chapter 10 Introduction to Team Software Process.
PRODUCT IMPLEMENTATION Chapter 8 Tawatchai Iempairote September 23, 2041.
INFO 637Lecture #11 Software Engineering Process II PSP Overview & TSP Introduction INFO 637 Glenn Booker.
CS 350, slide set 11 M. Overstreet Old Dominion University Fall 2004.
Focus on design principles and on a process for doing design = To produce a precise, complete, high- quality foundation for product implementation.
CSC 480 Software Engineering PSP Project 1 August 20, 2004.
CS 350, slide set 4 M. Overstreet Old Dominion University Spring 2005.
CS 350, slide set 10 M. Overstreet Old Dominion University Spring 2005.
Software Process Models.
TMP3413 Software Engineering Lab Lab 01: TSPi Tool Support.
Software Project Management Lecture # 12. Outline Quality Management ( chapter 26 - Pressman )  SQA  Who does it?  SQA Activities  Software reviews.
CSC 480 Software Engineering Team Issues. Essence of a Successful Team To be successful, teams must  Plan their projects  Track their progress  Coordinate.
Information Technology Project Management, Seventh Edition.
CSC 480 Software Engineering
General Education Assessment
Team Software Process (TSP)
Presentation transcript:

CS 350, slide set 6 M. Overstreet Old Dominion University Fall 2005

Reading Team Software Process text, Ch. 1, 2, 3

Topics Intro to TSPi What’s coming in the rest of the semester? Some problems and warnings

Quandary Most of the technology you will need to understand to be successful in your jobs doesn’t exist yet. Employers identify problem solving as the key employee skill. In some crucial ways, the main thing to learn is a process for dealing with new problems.

TSPi overview i stands for instruction. Subset of TSP Focus: Based on PSP Scripts, measurements, metrics Teams & roles Different members responsible for different parts of joint project Develop complete product in several complete cycles

TSPi Structure and flow Needs statement Cycle 1 Launch Strategy 1 Plan 1 Requirements 1 Design 1 Implementation 1 Test 1 Postmortem 1 Cycle 2 Launch Strategy 2 Plan2 Requirements 2 Design 2 Implementation 2 Test 2 Postmortem 2 Cycle 3 Launch Strategy 3 Plan 3 Requirements 3 Design 3 Implementation 1 Test 3 Postmortem 3

TSPi Development Script - 1 PurposeGuide team through dev. software project Entry Criteria Instructor to guide and support project Students know PSP Instructor has project description Instructor has described project objectives Exit Criteria Completed project Completed user documentation Completed and current project notebook Documented team evaluations and cycle reports

TSPi Development Script - 2 WkStepActivities 1Review Read TSP ch. 1 and 2. 2LAU1 STRAT1 Assign teams and roles. Read TSP ch. 3, App B and one of ch Produce conceptual design, establish dev. strategy, make size estimates and assess risk. Read TSP ch. 4. 3PLAN1 Produce cycle 1 team and engineer plans Read TSP ch. 5 & App C. 4REQ1 Define and inspect cycle 1 requirements. Produce system test plan and support materials. Read TSP ch. 6 and test sections of ch. 9. 4DES1 Produce and inspect cycle 1 high-level design. Produce integration test plan and support materials. Read TSP ch. 7.

TSPi Development Script - 3 WkStepActiviies 5IMP1 Implement and inspect cycle 1. Produce unit test plan and support materials. Read TSP ch. 8. 6TEST1 Build, integrate, and system test cycle 1. Produce user documentation for cycle 1. Read TSP ch. 9. 7PM1 Conduct a postmortem and write cycle 1 final report. Produce role and team evaluations for cycle 1. Read TSP ch 10, 16, 17, and 18. CYCLE 2 Repeat above for cycle 2 (we won’t have time for this). CYCLE 3 Repeat above for cycle 3 (we won’t have time for this).

Why projects fail Rarely for technical reasons Internal politics Team does not bind Fail to develop rapport with customers People will fight over meaningless issues Pressure is a problem Having a plan of action helps Know real issues that must be resolved rather than worrying about imaginary problems

Common team problems Ineffective leadership Few people are natural leaders, but can get better with practice Beneficial to have effective examples (people) Some people don’t know how to compromise Lack of participation Procrastination/lack of confidence Poor quality Function creep Poor peer evaluation

Team definition For TSPi, a team consists of at least 2 people (TSP designed for 5), who are working toward a common goal, where each member is assigned specific responsibilities and where successful completion of project requires team members to contribute.

Jelled teams Whole greater than sum of parts Great satisfaction for members Necessary conditions Task to be performed clear Team responsible clearly identified Including who is and is not on team Team has control over tasks Can be dangerous to team members Can’t “not do it” attitude Hard on personal relationships (spouses, significant others) See “Soul of a new machine” by Tracy Kidder Identified as one of best 100 books of 20 th century

How to build teams Common goals Assigned roles Most people want to contribute. Each person needs specific task to complete that he/she understands, and Peer pressure has an effect. Need plans Strategy for achieving goals Communication Weekly meetings – if possible part of recitation time

Problems & warnings TSP instruction problem: Students learn TSP by doing a “big” project Students need to know TSP before they start So, we need to finish the TSP book by Tuesday so you can start the semester- long (well, half semester) project And we can’t You are the victims of an experiment! Struggle with better ways of teaching what you need to know OVER THE LONG RUN Changing views on how to do this

Launching a new team Defining goals for team and team members Defining roles How the group is to be organized Establish responsibilities of each role Just makes is easier and quicker to divide up work Still, everybody develops and tests code, everybody manages some aspect of the project Assigning roles

Goal considerations Aggressive but realistic Here, we want to stretch your abilities, but not crush you Avoid timid, safe goals Should strive to achieve, but cannot be punished severely if not achieved They matter (but they don’t)

Identifying team goals Write them down Decide how to measure Explain why you picked them Give copy to other team members and to instructor Have the support manager put a copy in the project notebook

General comments on goals Should relate to how a user will perceive the product: Quality Utility Costs When available In 350, instructor and grader are the customers

Possible goals Attempt 1: Produce a quality product Run a well-managed project Extend project beyond minimal These may seem too vague, but if concrete measurements are added:

Goals and metrics - 1 Team goal 1: Produce quality product Percent of defects found before 1 st compile: 80% Number of defects found in system test: 0 Requirements functions included at project completion: 100%

Goals and metrics - 2 Team goal 2: Run a well-managed project Error in estimated product size: < 20% Error in estimated development hours: < 20% Per cent of data recorded and entered in project notebook: 100% Number of days project completed before deadline: 3

Goals and metrics - 3 Team goal 3: extend project beyond minimal requirements Bonus points possible

TSPi team members - 1 Team leader Resolves issues among members Facilitates meetings Much more, see text. See fig 3.1 e.g. decides how the project notebook will be kept see appendix G for notebook specs and standards Development manager Lead all development work Much more, see text Planning manager Lead team planning and progress tracking Much more, see text

TSPi team members - 2 Quality/Process manager Lead quality planning and tracking Act as inspection moderator Much more, see text Support manager Obtain needed support tools Handle configuration management Much more, see text

Team member goals Examples Be a cooperative and effective team member Average PEER eval. for helpfulness and support > 3 Average PEER eval. for overall contribution > 3 Produce quality products Defect density at compile < 10/KLOC Defect density at test < 5/KLOC Defects found after unit test: 0

Example role goals Planning manager goal: Accurately report team status every week to instructor Support manager goal: No unauthorized changes made to baselined product Quality/Process manager goal: All team inspections are properly moderated and reported

Launch script Purpose To start teams on a development cycle Students have read ch. 1, 2, 3, and reviewed NASA requirements GeneralThe instructor describes TSPi objectives Form teams and assign team roles Explain objective for the software Establish meeting and reporting times Steps 1, 2, and 3 are completed during the first meeting Steps 4 through 8 are completed during the second meeting Exit criteria Each student has completed and submitted INFO form The development teams are formed and roles assigned. The instructor has described the overall product objectives The instructor has reviews and discussed the TSPi and team’s role goals Each team has agreed on goals, weekly meeting times, and the weekly data to report

Student information sheets - 1 Mail to cmo by next Monday, Oct. 31 Rank from 1 (least) to 5 (most) your preferences for serving the the following roles: Team Leader Development Manager Planning Manager Quality/Process Manager Support Manager

Weekly meeting script PurposeTo guide teams in conduction weekly meetings Entry criteria All team members present All team member have provided updated TASK, SCHEUDLE, and WEEK forms to the planning manager The team leader has issued a meeting agenda GeneralIn advance of the meeting, the team leader has: Asked team members for meeting agenda topics Prepared and distributed the meeting agenda The team leader leads the weekly meeting The quality/process manager records the meeting topics Each team member generally reports his/her role work and development work at the same time After the meeting, the team leader distributes the meeting report Puts a report copy in the project notebook Exit criteria The meeting report completed and placed in the project notebook Updated team and programmer TASK, SCHEDULE, WEEK, and CSR forms in the project notebook Updated copy of the ITL (issue tracking log) in the project notebook

Weekly forms See text (table 3.5) for meeting step by step details Agenda review Role reports Engineer reports Close meeting See text (table 3.7) for individual report instructions.