PROJECT INFO, PRESENTATION INFO, AND IMPACT ANALYSIS

PROJECT INFO, PRESENTATION INFO,

AND IMPACT ANALYSIS

November 13, 2012

Tuesday, November 13, 12

PAPER AND PRESENTATIONS

After class, sign up for a presentation date

Presentations:

4 classes, 18 people = 15 minutes per presentation (4 or 5/day)

Your presentation should be 11 minutes long

4-5 minutes for questions/switchover

You will receive warnings at 2 minutes, 1 minute, and 30 seconds remaining

Please send me all slides at least 5 hours before your presentation!


OVERALL PRESENTATION TIPS

Before starting, think about main points - will not have time to go over everything!!!!

Oral Communication is different from written communication

K.I.S.S. (Keep it simple, stupid.)

Focus on getting one to two key points across

Think about your audience

Some are experts in sub-area, some are experts in general area, and others know

Should be accessible to all on some level

Think about your goals

Leave your audience with clear picture of the gist of your contribution

Make them want to read your work


How to Give a Bad TalkBased on Dave Patterson’s Ten Commandments

(Powerpoint by Rolf Riedi)

How to give a Bad Talk (by David Patterson)http://pages.cs.wisc.edu/~markhill/conference-talk.html#badtalk


http://pages.cs.wisc.edu/~markhill/conference-talk.html#badtalk




1) Thou shalt not waste spaceTransparencies and hard-discs are expensive.

If you can save five slides in each talks per year, you save 7.00/year in transparencies!

This is equivalent to 350 kB precious memory!2. Thou shalt not be neat

3. Thou shalt not covet brevity

Do you want to continue the stereotype that engineers can't write? Always use complete sentences, never just key words. If possible, use whole paragraphs and read every word.

4. Thou shalt cover thy naked slides

You need the suspense! Overlays are too flashy.

5. Thou shalt not write large

Be humble -- use a small font. Important people sit in front. Who cares about the riff-raff?

6. Thou shalt not use color

Flagrant use of color indicates uncareful research. It's also unfair to emphasize some words over others.

7. Thou shalt not illustrate

Confucius says ``A picture = 10K words,'' but Dijkstra says ``Pictures are for weak minds.'' Who are you going to believe? Wisdom from the ages or the person who first counted goto's?

8. Thou shalt not make eye contact

You should avert eyes to show respect. Blocking screen can also add mystery.

9. Thou shalt not skip slides in a long talk

You prepared the slides; people came for your whole talk; so just talk faster. Skip your summary and conclusions if necessary.

10. Thou shalt not practice


1) Thou shalt not waste space

• Transparencies and hard-discs are expensive.

• If you can save five slides in each talks per year, you save $7.00/year in transparencies!

• This is equivalent to 350 kB precious memory!


2) Thou shalt not be neat

•  Why vaste research time on prepare slides? •  Ignore spell�g, grammer and legibility.

Who cares what 30 people think?


2) Thou shalt not be neat

•  Why waste research time on preparing slides? •  Ignore spelling, grammar and legibility.

Who cares what 30 people think?


3) Thou shalt not covet brevity

•  Do you want to continue the stereotype that statisticans can't write? Always use complete sentences, never just key words. If possible, use whole paragraphs and read every word.


3) Thou shalt not covet brevity

•  Use key words. •  Don�t read your slide.


•  You need the suspense!


4) Thou shalt animate to the limit



•  You need the suspense! •  You need the suspense!



Overlays are too flashy Animations can irritate.




Overlays are too flashy Animations can irritate.



5) Thou shalt not write large •  Be humble -- use a small font… • …especially for the relevant part. •  Important people sit in the front.


6) Thou shalt not use color

• Flagrant use of color indicates

uncareful research. •  It's also unfair to emphasize

some words over others.


7) Thou shalt not illustrate

• Confucius says – ̀ `A picture is a 1000 words,''

•  but Dijkstra says – ̀ `Pictures are for weak minds.'�

• Who are you going to believe? –  Wisdom from the ages or –  the person who first counted goto's?


8) Thou shalt not make eye contact

• You should avert eyes to show respect.

• Blocking screen can also add mystery.


9) Thou shalt not skip slides in a long talk

• You prepared the slides and suffered, make them suffer too.

• People came for your whole talk; don�t cheat them out of anything.

• So just talk faster • Skip your summary and

conclusions if necessary.


10) Thou shalt not practice•  Why waste research time practicing a talk?

–  It could take several hours out of your two years of research. –  How can you appear spontaneous if you practice?

•  If you do practice, argue with any suggestions you get and make sure your talk is longer than the time you have to present it.

•  Commandment X is most important. Even if you break the other nine,

•  this one can save you.


PRESENTATIONS (RESEARCH PROPOSAL)

For a 11 minute talk, ~7 slides

Suggested outline (proposal)

1) Title slide

2-3) Intro and motivation/background

4-5) Implementation

6) Evaluation idea

7) Discussion and conclusion


PRESENTATIONS (PROPOSAL-ISH)


Suggested outline (proposal-ish)

1) Title slide

2-3) Intro and motivation

4-5) Other techniques

6) Discussion of your idea

7) Conclusion


PRESENTATIONS (LIT REVIEW)


Suggested outline (lit review)

1) Title slide

2-3) Intro and motivation

4-5) Techniques you examined (pick the big ones)

6) What you’ve learned

7) Conclusion


SRS PROJECTSystem: Existing music lending library

Goal of this release: Add automated way to borrow music

Materials: 2 collections in zip format

Interviews (written, audio)

Pictures

Data

ALL information in your SRS should link back to the elicited data

Write an SRS using IEEE Std 830-1998 format


SRS PROJECT DATES

Week 1: Begin looking over and sorting through the materials.

Week 2: Fill out the requirements specification document following the template

Week 3: Put requirements into the Requirements Management System.

More info to come about the Management System

Friday, November 30th: Submission of SRS documents

Thursday, December 6th: Submission of group evaluations of SRS projects


IMPACT ANALYSIS

Provides accurate understanding of the change

Helps team make good business decisions

Examines the proposed change:

What will be created?

What will be modified?

What will be discarded?

What effort’s associated with each?


IMPACT ANALYSIS PROCEDURE

Understand possible implications of making the change

Identify all files, models, and documents to be changed

Identify tasks to implement change

Estimate effort needed to complete tasks


QUESTIONS TO UNDERSTAND IMPACT

Do any existing requirements in the baseline conflict with the proposed change?

Do any other pending requirements changes conflict with the proposed change?

What are the business or technical consequences of not making the change?

What are possible adverse side effects or other risks of making the proposed change?

Will the proposed change adversely affect performance requirements or other quality attributes?

Is the proposed change feasible within known technical constraints and currents staff skills?


QUESTIONS TO UNDERSTAND IMPACT

Will the proposed change place unacceptable demands on any computer resources required for the development, test, or operating environments?

Must any tools be acquired to implement and test the change?

How will the proposed change affect the sequence, dependencies, effort, or duration of any tasks currently in the project plan?

Will prototyping or other user input be required to verify the proposed change?

How much effort that has already been invested in the project will be lost if this change is accepted?

Will the proposed change cause an increase in product unit cost, such as by increasing third-party product licensing fees?

Will the change affect any marketing, manufacturing, training, or customer support plans?


USING TRACEABILITY:CHECKLIST OF IMPACT

Identify any user interface changes, additions, or deletions required.

Identify any changes, additions, or deletions required in reports, databases, or files.

Identify the design components that must be created, modified, or deleted.

Identify the source code files that must be created, modified, or deleted.

Identify any changes required in build files or procedures.

Identify existing unit, integration, system, and acceptance test cases to be modified or deleted.

Estimate new unit, integration, system, and acceptance test cases now required.

Identify any help screens, training materials, or other user documentation that must be created or modified.

Identify applications, libraries, or hardware components affected by the change.

Identify any third-party software that must be purchased or licensed.

Identify any impact the change will have on the project's software project management plan, quality assurance plan, configuration management plan, or other plans.


EVALUATING IMPACT OF CHANGE

Work through checklist of questions

Work through checklist for potential impact (Use traceability information)

Estimate labor hours needed to update, create, modify, and develop each component

Total effort estimates

Identify sequence tasks must occur in (parallelize with existing?)

Is change along the critical program path?

Estimate impact on schedule and cost

Evaluate change’s priority

Report analysis results to CCB


REPORTING RESULTS

* Modify template for your project’s needsTuesday, November 13, 12

NEXT CLASS

Improving the requirements process

Fundamentals of software process improvement

Process improvement cycle


Documents

PROJECT INFO, PRESENTATION INFO, AND IMPACT ANALYSIS