se 652 software quality management summer 2007 lee vallone

SE 652Software Quality Management

Summer 2007

Lee Vallone

5/22/2007 SE 652 - Software Quality Management 2

Ring Software, Ltd.

You were previously a project manager at Ring Software who has just been promoted to lead the EZ Procurement Release 2 project, a B to B system that enables customers to automate their procurement processes and achieve price reductions through the included supplier bidding system. Release 1 was a dismal “success”. Though the project finally got out the door, it was a year late, under-featured and “buggy”. The customers are very unhappy with the release and sales are suffering, putting the company’s future at risk. Team morale is awful. They worked nights and weekends for the last 2+ years and are worn out. Recently, developers have started resigning to find their fortunes elsewhere, rather than face a repeat performance on R2. There are extensive standard processes, but most are not followed with the excuse that there isn’t enough time. Your predecessor was terminated on the grounds of mismanaging the release. Your job is to deliver R2 with quality, on time and on budget or suffer the fate of your predecessor.


Intro to SE 652

“The major problems of our work are not so much technological as sociological in nature.”

In most development organizations managers spend most of their time solving technical problems, instead of addressing the political & interpersonal issues that are the real culprits for the high failure rate of software projects. Similarly, we teach students the virtues of use-cases and spiral development models, frequently ignoring the true keystones of student success in the project world: teamwork, collaboration and the processes that tie everything together.

Course objectives:1. To help students develop a broad understanding of the requirements and considerations

in planning, managing and implementing a software project, with special emphasis on teams, processes & metrics.

2. To help students understand (and experience) the role and importance of sociological issues and how to address them in a way that substantially increases the probability of project and personal success. It is based on the premise that software engineering is so much more than the technical disciplines.


SE 652 Course Perspective

About: putting it all together

Perspective of: a project leader responsible and accountable for delivering a productManaging constraints (quality, budget & staff, schedule, functionality)

Direct and indirect coaching responsibility for a cross-discipline team

Focus on:• Leadership and membership in high performance, gelled teams• Quality control including processes, audits, assessments, etc.

• Estimation

• Measurement

• Strategic & tactical considerations

At conclusion: course participants will understand what it takes to plan, manage & execute a software project.


SE 652 Introductions

IntroductionProfessor: Lee ValloneEmail: [email protected]: 732-949-4651 (office)Mobile: 908-313-2053 (cell)Office Hours: on request

Course Web Link: http://www.monmouth.edu/~lvalloneLecture slides will be posted prior to start of class

Course EtiquetteLecture attendance is mandatoryBe on time! (including returns from breaks)Cell phones off or silentCritical that assignments are done on time & with quality!Quality contributions to classroom discussions requested & expectedPrivate discussions during class are inappropriate

mailto:[email protected]

http://www.monmouth.edu/~lvallone

http://www.monmouth.edu/~lvallone


SE 652 Class Structure

Classroom tries to mimic the workplaceSignificant workloadSpeak upNot a democracy, but …Strife & Conflict happensExpected behavior

Learning ModesHands on / team projectText & LecturesPresentationsClass Participation


SE 652 Work Activities

Organized by teams of 3-4 for entire sessionTeam project

Some time allotted in classReviews, planning, testing

Expected to meet at least once/week outside of classIndividual deliverables to teamClassroom presentationsTeam leader responsible for team performanceAppraisals

Preparation for other topicsReading materials (texts) & lectures


Lecture & Texts

Lecture Details:~Three Hours of Lecture, Discussion & Presentations

w/ 15 minute break (90 minute rule)Typically, 1/3 selected topic, 1/3 team project &

1/3 team presentations or meetingTexts:

Peopleware (DeMarco & Lister)Introduction to the Team Software Process (Humphrey)Practical Software Measurement (McGarry, et.al.)

Recommended Readings:PSP: A Self Improvement Process for Software Engineers (Humphrey)The Mythical Man Month (Brooks)Death March (Yourdon)Dancing with Bears (DeMarco, Lister)The Dilbert Principle (Adams)


Course Topics

Personal Software ProcessTeam Software ProcessProcess Standards & Audits: ISO 9000, TL9000Process Assessments: SEI’s CMMIMeasuring Software QualityDeath March ProjectsConfiguration ManagementTeam & Development Issues

Risk ManagementCommitmentTrust…


Grading

Texts do not fully cover the course material!

Team vs. Individual25% - Classroom Participation & Exercises

• Every student expected to attend class & contribute

• Quality contributions are appreciated

45% - Team ProjectsAchieving schedule @ high quality is critical

• Completed Project

• Quality Records (e.g. project notebook, forms)

• Class Presentations

• Peer Feedback

30% - Final ExamWill not be based on regurgitation from texts or lectures


Team Project Process

We will loosely follow Watts Humphrey’s PSP & TSP processes– Heavyweight (we can discuss lightweight processes)

– Assumes Personal Software Process Familiarity

– Requires extensive quality records for both individuals & teams

– Key records:• Personal time log

• Team project notebook

Measurement activities will follow the PSM strategy– Create & manage to a measurement plan


TSP Objectives

• Expose students to problems of developing software intensive products

• Guide teams through a Team Development Process

• Demonstrate benefits of using a defined & measured process


TSP Lessons

• Data Gathering, initially viewed as a burden until second nature

• Without a disciplined process, development & testing of even small programs can take a long time

• With a disciplined process, teams will finish projects on time, products will work & fly through the test phase


Team Project

Lines of Code Counter

Teams of 4-5

Team Selection

Two iterations

Functionality (TSPi Appendix A)Team decides iteration contents

SVT Function

Roles (see next slide)


Change Counter Project

Functional Need Statement (TSP Appendix A)– Team reviews each need & targets iteration

– Prepare Response(e.g. Technical Prospectus, Project Plan)

– Negotiate with customer

– Develop Detailed Requirements based on agreement (SRS)• Include traceability back to original functional need statement


Change Counter Project

Functionse.g. Compare; Identify Added/Deleted/Changed; Language, Print

Counting Specificationse.g. Define LOC, Define Add/Delete/Changed

Header Labelinge.g. Date of change, programmer, reason, LOC information

Formattinge.g. Line labels

User Documentatione.g. Usage, detailed description, integrated vs. separate


Development Process Phases

Launch / StrategyDevelopment Strategy, Functional Need Response, Project Plan, Risk Assessment, Size

& Time Estimates

PlanDevelopment Plan, Quality Plan, Configuration Management Plan, Measurement Plan

RequirementsSoftware Requirements Specification (SRS), System Test Plan

DesignHigh Level Design & Software Design Specification (SDS)

ImplementationDetailed Designs, Unit Test Plans, Code, Integration Test Plan

TestTest & Rework

Post-MortemTeam Performance, Peer Reviews, Project Appraisal


TSP Project Documentation

Quality RecordsDevelopment Strategy / Conceptual Design / Project Plan

Software Requirements Specification (SRS)

High Level Design (HLD)*

Software Design Specification (SDS)

Code

Build & Integration Plan

System Test Plans

User Documentation

Process / Guidance DocumentsQuality Plan / Measurement Plan

Process Improvement Process

Development Standards

Change Control & Configuration Management Process


TSP Project Documentation (continued)

Planning / Metrics / Tracking RecordsIssue & Risk Log (ITL)

Size & Time Estimates

Task & Schedule Plan (TASK / SCHEDULE)

Various Summary & Performance Forms (e.g. SUMDI, SUMDR, SUMP, SUMQ)

MiscellaneousChange Control Board

Inspections

Configuration Management System

Tools & Development Environment

Team meeting minutes


Sample Project Notebook

Index

Team member descriptions

Team meeting minutes

Risk & Issue Management

Project Cycle Reports

Schedule Tracking

Project Documents (SRS, SDS, Detailed Design)

Process Documents (CM plan, Design & Coding standards, Naming conventions)

Inspection Quality Records

Code

Change Request Tracking

Test Documents (ITP, STP, Test Results)


Team Roles

• Team Leader

• Development Manager

• Planning Manager

• Quality / Process Manager

• Support Manager


Common Responsibilities

Project development

Data collection (LOGT, LOGD)

Responsible team member– Time Commitment

– Quality Commitment

– Teamwork Commitment


Team Leader

• Overall accountability for team performance

• Build & maintain an effective team

• Motivate team members

• Quickly & effectively identify & resolve issues

• Keep instructor informed

• Team meeting facilitator & timekeeper

• Lead development of cycle report

• Maintain project notebook


Development Manager

• Accountable for development of a quality product from requirements to implementation

• Lead development strategy (STRAT)

• Preliminary size & time estimates

• Lead SRS development

• Lead HLD & SDS development

• Lead implementation and unit test

• Lead build & integration planning & execution

• Lead User Documentation

Note: Recommend System Test Plan be developed by Quality Manager (deviation from text recommendation)


Planning Manager

• Accountable for planning, tracking & reporting team status• Produce initial plan (SUMS, TASK)• Develop schedule• Balance team plan• Track progress against plan

– SUMP & SUMQ Forms– Earned Value & time chart– Weekly status reports– Analysis of actual performance vs. plan

• Weekly data collection– Time spent, task completion data, defects found, size data, LOGD, LOGT, SUMS,

TASK & SCHED forms– Generate composite – TASK, SCHED, SUMP, SUMQ forms– Weekly team Earned Value & Gantt charts

• Generate Weekly status report including analysis of plan vs. actual


Quality / Process Manager

• Accountable for developing and ensuring conformance to processes• Accountable for assessing overall quality of deliverables & approving• Accountable for team data entry• Lead development of team processes

– e.g. change management, issue tracking

• Establish & maintain team development standards– Coding, design, documentation (user & internal)– Naming, error handling, interfaces, messages, screens, reports– Line of Code counting, Reuse

• Review & Approve all submissions for baselining– Based on: process data available, underlying quality development process & data

indicating product is of suitable quality

• Inspection moderator (INS)– Review logistics, verify preparation, keep meeting running smoothly, determine final

review status, data collection

• Meeting Recorder


Support Manager

• Accountable for tools, methods & configuration management

• Determine needs & obtain / setup needed tools & facilities

• Manage configuration management system– Saving, tracking, submission/retrieval, change handling

• Maintain system glossary

• Maintain issue & risk tracking system

• Reuse advocate

se 652 software quality management summer 2007 lee vallone

Documents

software engineering

quality contributions

gelled teams quality

project world

probability of project

inappropriate slide

lee vallone slide

class reviews