Presentations, Project Status

Reporting, Test Plans, Project

History
CS3911
Spring 2005
Agenda
Mid-Term Presentations (see webpage)
Presentation Guidelines
What is a status report?
Sample Contents
Process Comments
Final Presentations
Test Plans
Project Histories
Guidelines
Each team has 15 minutes for midterm,
25-30 minutes for final
Principle purpose of midterm is status
and project description
Principle purpose of final is project
demo, results and conclusions
Each team member must present at
least once
Attendance at presentations
mandatory, miss yours 1 letter grade,
miss others -5 pts per miss
Presentations
Present Positive Image
Know your audience
Tell em what you are going to tell em,
tell em, tell em what you told em
Watch mannerisms, posture
Slide construction (Fonts, Art)
Careful with humor
Test your AV gear
Presentations (cont’d)

Normally given by PM with support,

but…
Backup slides
Rehearse – Stay within time limits
Leave room for questions
Be honest
Never read slides
Eye contact
Midterm Presentation
Content

Introduction of team
 Team name, customer, faculty advisor, team
members, their roles
Product to be delivered
 Customer background, product context,
tangible product to be developed, main
design question(s)
 Overview of requirements
Project plan
 Task breakdown, milestones, schedule
 Main risk factors
Status
A Status Report shows:
Overview of project
Planned vs. Actual
Other Metrics
Major Milestones Met or Missed
Issues
“Show Stoppers”
It is NOT a “what I did on my
summer project” save that for the
final presentation!
The Project Manager’s
Cube

Schedule Quality

Feature Set
Resources
 Schedule (Total)
.02 to .03 Development
Planned As of 1/15/2004

Actual
Projected
Total
Project

Current
Quarter

Hours Expended
Schedule (By Major
Activity)
Design

Coding

Unit Test

Integration

As of 1/3/04
Resources (Man-Hours)
Cumulative Effort (Man Hours)

Time
Projected
Actual
Total Project
Quarter
Resources (Expenditures)
Cumulative Expenditures (Dollars)

Planned
Actual

Time
Expenditure by Category
Salary (Base)

Overtime

Equipment

Trav
el
Trainin
g
Supplies

Dollars ($)
 Percent Complete

100
Reports

Security

DB Design
Features

Feature Item
Actual
Planned
Defect Rate
Historical
Actual
Defects/KLOC

Time
Other Metrics
ECP Rates
Outstanding ECP
Productivity Rates
Benchmarking Data (14/KLOC)
Process Improvement Data
Risk Data
Project Risk Summary
Prevention
Mitigation Do not repeat
Elimination entire risk plan.
This is for risks
that actually
Risk: Rapidly Changing Requirements
happened.
Strategy: Mitigation thru Customer Rep
Results: No schedule slip
Major Milestones Met
M1.7 Critical Design Review
6/15/2002
R3.4 Formal Code Review 7/1/2002
Milestones Missed
C1.5 Customer Alpha Code
Delivery 7/5/02

Schedule slipped by 3 weeks, new

delivery milestone 8/1/02
It is not necessarily
Explanations… bad to miss a MS. It’s
just bad to miss and
have no plan to
recover
Issues
Excessive Overtime Rate
Design Element 1.3 Modification
Expansion of Requirements by
25%
These should be
things that are
affecting your project:
$, time, hours
Showstoppers
Issue: Main Development Server
Hardware failure
Action: RAID Controller on order,
expected delivery 7/12/02
Impact: DB Coding stopped for 2
weeks, Work shifted to v2 design
Final Presentation Content

Introduction of team
 Team name, customer, faculty advisor, team
members, their roles
Product to be delivered
 Customer background, product context, tangible
product to be developed, main design question(s)
 Overview of requirements
Product actually delivered
 Differences from plan; reasons; design resolution
Process strengths and weaknesses
Demo
Demo at your Final
Presentation
Your final presentation should include a
demo of your product executing
Script it
 Know exactly what you are going to show;
practice demo
Have canned data available
Don’t let demo be first time you try a
feature
Be sure your demo runs in the
presentation environment
Conclusions
Plan Presentation Sequence
Practice (maybe in front of mirror)
Check content
Relax and be confident
Project Histories/Peer Eval

AKA Post Mortem

An analysis of your project experience
Submit to advisor and instructor
No set length
Your chance to expound on your work
and experiences in the project.
Can show work by phase by member (or
can use peer eval forms for privacy)
Two peer evals – they do affect your
grade!!
Testing
Validation: Are we building the
right thing?
 Conformance to customer
requirements and quality attributes.
Verification: Are we building the
thing right?
 Process conformance, quality
activities.
 Testing Ground Rules

“The development of software systems involves a series of production activities

where opportunities for injection of human fallibilities are enormous…Because of huma
inability to perform and communicate with perfection, software development
is accompanied by a quality assurance activity.”
[Deutsch]

Objectives
 Testing is the process of executing a program with
the intent of inducing failures
 Incorrect output
 Infinite loop
 Program crash
i.e. success = failure
Importance
Ground Rules
Benefits
 Raise confidence that software functions is
working according to specification
 Demonstrate that software fails gracefully
 Demonstrate performance and resource
consumption requirements have been met
Provide measure of software reliability and
quality
Testing cannot show the absence of defects
Exhaustive testing not feasible
Testing Phases
Unit
Component
Integration
System
Acceptance
Usability
Regression
Alpha / Beta
Testing Strategies

Dynamic Analysis
 Black Box - requirements based
(random)
 White Box - code based
 Top down - test caller then callees
 Bottom up - test units then integrate
Static Analysis
 Code Reviews
 Anomaly detection (lint)
 Comparison of Test
Strategies
Test Strategy Method Goal Disadvantages

White box Logic Prove processing Functional flaws, data

sensitive conditions and errors
across modules; difficult to
test
Black box Data Prove results Type 2 errors and logic
problems difficult to find

Bottom up All or nothing Perfect parts; if parts Functional flaws found late
work, whole should cause delays; Errors across
work modules difficult to trace and
find

Top down Incremental Exercise critical code to Scaffolding takes time;

improve reliability Constant change may
introduce new errors