DOC PREVIEW
ODU CS 350 - Lecture Notes

This preview shows page 1-2-3-4 out of 12 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1CS 350, slide set 7M. OverstreetOld Dominion UniversitySpring 2005Reading Team Software Process text, Ch. 1, 2, 3Topics Intro to TSPi What’s coming in the rest of the semester? Some problems and warnings2Quandary Most of the technology you will need to understand to be successful in your jobs doesn’t exist yet. Employers identify problem solvingas 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 cyclesTSPi Structure and flowNeeds statementCycle 1 LaunchPostmortem 1Test 1Implementation 1Design 1Requirements 1Plan 1Strategy 1Cycle 2 LaunchPostmortem 2Test 2Implementation 2Design 2Requirements 2Plan2Strategy 2Cycle 3 LaunchPostmortem 3Test 3Implementation 1Design 3Requirements 3Plan 3Strategy 33TSPi Development Script - 1 Completed project Completed user documentation Completed and current project notebook Documented team evaluations and cycle reportsExit Criteria Instructor to guide and support project Students know PSP Instructor has project description Instructor has described project objectivesEntry CriteriaGuide team through dev. software projectPurposeTSPi Development Script - 2 Read TSP ch. 1 and 2.Review1 Produce and inspect cycle 1 high-level design. Produce integration test plan and support materials. Read TSP ch. 7.DES14 Define and inspect cycle 1 requirements. Produce system test plan and support materials. Read TSP ch. 6 and test sections of ch. 9.REQ14 Produce cycle 1 team and engineer plans Read TSP ch. 5 & App C.PLAN13 Assign teams and roles. Read TSP ch. 3, App B and one of ch. 11-15. Produce conceptual design, establish dev. strategy, make size estimates and assess risk. Read TSP ch. 4.LAU1STRAT12ActivitiesStepWkTSPi Development Script - 3 Repeat above for cycle 3 (we won’t have time for this).CYCLE 3 Repeat above for cycle 2 (we won’t have time for this).CYCLE 2 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.PM17 Build, integrate, and system test cycle 1. Produce user documentation for cycle 1. Read TSP ch. 9.TEST16 Implement and inspect cycle 1. Produce unit test plan and support materials. Read TSP ch. 8.IMP15ActiviiesStepWk4Why 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 problemsCommon 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 evaluationTeam 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.5Jelled 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 20thcenturyHow 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 timeProblems & 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 this6Launching 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 rolesGoal 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 notebook7General 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 customersPossible 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 1stcompile: 80% Number of defects found in system test: 0 Requirements functions included at project completion: 100%8Goals 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: 3Goals and metrics - 3 Team goal 3: extend project beyond minimal


View Full Document

ODU CS 350 - Lecture Notes

Download Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?