EEEGEF 492'01 Software Processes and Work Products Dveloppement et produits de logiciel - PowerPoint PPT Presentation

1 / 45
About This Presentation
Title:

EEEGEF 492'01 Software Processes and Work Products Dveloppement et produits de logiciel

Description:

Titre du cours en fran ais: GEF492 D veloppement et produits de logiciel. Calendar descriptions (en anglais et en fran ais) and premise. Course resources ... – PowerPoint PPT presentation

Number of Views:42
Avg rating:3.0/5.0
Slides: 46
Provided by: jeff156
Category:

less

Transcript and Presenter's Notes

Title: EEEGEF 492'01 Software Processes and Work Products Dveloppement et produits de logiciel


1
EEE/GEF 492.01Software Processes and Work
ProductsDéveloppement et produits de logiciel
Royal Military College of Canada Electrical and
Computer Engineering
  • Professor Colin Wortley
  • wortley_at_rmc.ca
  • 613-541-6000 ext. 6493

Dr. Terry Shepard shepard_at_rmc.ca 613-541-6000
ext. 6031
2
Todays Agenda
  • Introductions
  • Titre du cours en français GEF492 Développement
    et produits de logiciel
  • Calendar descriptions (en anglais et en français)
    and premise
  • Course resources
  • Student evaluation
  • Course overview
  • Why study software processes and work products?
  • Definitions of software engineering
  • Software quality
  • Work products and software documentation

3
IntroductionsWho are you?Who am I?
4
calendar description
  • Introduction to scale-related complexities
    inherent in software projects. Study of software
    development processes, and of work products
    associated with those processes. Specific topics
    include Requirements Analysis, Software Metrics,
    Software Quality, Estimating Software Complexity,
    Estimating Software Projects, Testing
    Inspection, and Software Project Management.
    Lectures may be supplemented with critical
    reading and discussion of published articles on
    software. The course is supported by a laboratory
    in which the students undertake a software
    development project.

5
description de lannuaire
  • Introduction à la complexité déchelle inhérente
    aux projets de logiciel. Étude du processus de
    développement du logiciel et des produits de ce
    processus. Les sujets couverts incluent  étude
    des besoins, métriques, qualité, estimation de la
    complexité, estimation des projets, tests et
    inspections, et gestion de projet. Les cours
    magistraux sont complémentés par des lectures
    dirigées et la discussion de communications
    récentes. Un projet de développement de logiciel
    réalisé pendant les périodes de travaux pratiques
    met en pratique la matière vue en classe.

6
Course Premise
  • The basic premise of the course is that a better
    understanding of software processes and work
    products, both at the personal and at the
    organizational level, will make you a more
    effective contributor to improving the quality of
    software at a reasonable cost
  • And if you never do that, at least you will have
    more sympathy for those who do

7
Course Resources Web Site
  • http//tarpit.rmc.ca/
  • .and follow the links

8
Course Resources books and article
  • Books
  • Hans van Vliet. Software Engineering Principles
    and Practice. 2nd edition. John Wiley Sons,
    2000. ISBN 0-471-97508-7.
  • MMM Frederick P. Brooks. The Mythical
    Man-Month Essays on Software Engineering. 20th
    Anniversary Edition. Addison Wesley, 1995.
    ISBN 0-201-83595-9.
  • BT Barry Boehm, Richard Turner. Balancing
    Agility and Discipline. Addison Wesley, 2004.
    ISBN 0-321-18612-5
  • Article
  • Fowler Martin Fowler, The New Methodology,
    martinfowler.com/articles

9
Course Resources Secondary Textbooks
  • Al Kelley and Ira Pohl, A Book on C Programming
    in C (2nd Edition), 1989
  • Daniel Hoffman and Paul Strooper, Software
    Design, Automated Testing and Maintenance, A
    Practical Approach, International Thomson
    Computer Press (ITCP), 1995.
  • Fred P. Brooks Jr., Le Mythe du Mois-homme
    essais sur le génie logiciel, 2e Edn, 20e
    anniversaire, ITCP, 1996
  • Ron Jeffries, Ann Anderson, Chet Hendrickson,
    Extreme Programming Installed, Addison-Wesley
    Professional, 2000
  • Eric S. Raymond, The Cathedral and the Bazaar
    http//www.catb.org/esr/writings/cathedral-bazaar
    / - disponible en français
  • __________________________________________________
    _________
  • We have so many sources because the topic is not
    stable yet no single satisfactory text
  • weakness of the Pressman style too many topics,
    no depth. van Vliet is better, but does not cover
    everything we think is important.
  • XP book is still a good book Boehm and Turner
    brings a newer perspective.

10
Student Evaluation
  • Reading Assignments
  • 6 critiques 10
  • 10 assigned readings 10
  • Labs 20
  • Open book midterm exam 10
  • Open book final exam 50

11
Course Overview
  • 36 class periods
  • Critiques and assigned readings
  • Labs

12
36 class periods
subject to change
  • 1 Introduction
  • 4 Work Products
  • 6 Process Models (including CMM)
  • 2 Requirements
  • 1 Software Project Resource Planning
  • 2 Estimation
  • 1 People and Team Management
  • 1 Metrics
  • 1 Risk
  • 1.5 Midterm and Review of Midterm
  • 0.5 Configuration Management
  • 1 Quality
  • 3 Inspection
  • 8 Testing
  • 2 Guest Lectures
  • 1 Course Review

13
Reading Assignments Papers
  • Each student will write a critique of each of 6
    papers
  • weak critique summary of paper
  • strong critique analytical and thorough
    discussion of one or more significant points in
    the paper
  • clearly state the point or points being
    discussed, and for each point
  • explain why it is a good point, and outline the
    justification, or
  • discuss why the point made is weak or misguided,
    and provide justification
  • Papers and critiques will be discussed in class
  • Equal weight for each paper 10/6

14
6 Papers/Excerpts 1st Three
  • Barbara Kitchenham and Sheri Lawrence Pfleeger
    Software Quality the Elusive Target, IEEE
    Software, Jan.1996, pp.12-20
  • Paolo Donzelli, Marvin Zelkowitz, Victor Basili,
    Dan Allard, Kenneth N. Meyer, Evaluating COTS
    Component Dependability in Context, IEEE
    Software, July/August 2005 (Vol. 22, No. 4) pp.
    46-53
  • David Lorge Parnas and Paul C Clements A rational
    design process how and why to fake it, IEEE
    Transactions on Software Engineering, SE-12(2),
    pp251-257, Feb 1986.

15
6 Papers/Excerpts Last Three
  • James Whittaker, What is Software Testing? And
    Why is it so Hard?, IEEE Software, Jan./Feb.2000,
    pp.70-79
  • Edward F. Weller, Lessons from Three Years of
    Inspection Data, IEEE Software, Sept. 1993, pp.
    38-45
  • Echec du vol Ariane 501, Rapport de la Commission
    d'enquête Ariane 501, Président de la Commission
    Professeur J.-L. LIONS, ESA-CNES, Paris,
    juillet 1996
  • also available in English
  • augmented by several articles commenting on the
    failure

16
Paper critiques schedule
17
Reading Assignments MMM/BT/Fowler
  • You will be asked to answer questions the day the
    reading of a portion from The Mythical Man-Month
    (MMM) or Boehm Turner (BT) or Fowler is due.
  • Questions may be verbal or written.
  • Lack of response, indicating that you have not
    read the assigned portion, will result in a mark
    of zero.
  • Any response indicating that you have read the
    assigned portion will result in a mark of one.
  • Eleven reading portions will be converted to ten
    marks maximum.

18
Readings from Mythical Man Month (MMM), Boehm and
Turner (BT) and Fowler
Read by 13 Sept 20 Sept 27 Sept 4 Oct 11 Oct 18
Oct 25 Oct 1 Nov 8 Nov 15 Nov 22 Nov
  • week 2 MMM Prefaces and Chapters 1-3
  • week 3 MMM Chapters 4-6
  • week 4 MMM Chapters 7-9
  • week 5 MMM Chapters 10-12
  • week 6 MMM Chapters 13-14
  • week 7 MMM Chapter 15
  • week 8 MMM Chapter 19 first half pp 253-273
  • week 9 MMM Chapter 19 second half Epilogue
    pp 273-292
  • week 10 BT Chapter 1
  • week 11 BT Appendix E
  • week 12 Fowler

19
Labs
  • Lab periods 1 to 4
  • add delete operation to symbol table module
  • Lab periods 5 to 11 or 12
  • design, and partially implement and test, a
    reusable component based on the symbol table
    module

working with a representative set of software
work products, adding functionality to existing
software, design decisions, modification of test
plans and test implementations
20
Why Study Software Processes and Work Products?
21
Blue screen of death
22
Software Failures
Therac-25
Ariane 5
http//ei.cs.vt.edu/cs3604/lib/Therac_25/Therac_1
.html
http//www.ima.umn.edu/arnold/disasters/ariane5re
p.html
23
What purpose is served by studying software
processes and work products?other than getting
your degree!
24
Software Product Development
  • development time is typically 3 months to 2 years
    or more
  • teams range from 2 to 1000 people or more
  • problems manifest as
  • inability of project to deliver
  • loss of customer confidence
  • loss of market share or future contracts
  • high cost of long term maintenance/evolution
  • business failure
  • loss of money, property, or life
  • these are primarily quality issues

25
Practice vs Theory
26
Typical course assignment
  • Project generally well-defined with single
    focus/problem domain
  • often small enough to be completed by 1-2 people
    in 1-2 weeks (part time)
  • quality requirements?
  • projects are too small to have quality failures
    created by long causal chains
  • Course assignments are thus of limited value in
    understanding larger problems
  • studying accumulated knowledge from many past
    software developments can help

27
US Average Project Schedule
Software Productivity Research http//www.spr.com
28
US Average Cancellation Rate
Software Productivity Research http//www.spr.com
29
Software development is...
  • a) engineering
  • b) craft
  • c) art

30
Software engineering is a relatively new
discipline
In 1952, John Tukey, the world-renowned
statistician, coined the term software. The term
software engineering was used in the title of a
NATO conference held in Germany in 1968. The
IEEE Computer Society first published its
Transactions on Software Engineering in 1972
sic the correct date is 1975. The committee
within the IEEE Computer Society for developing
software engineering standards was founded in
1976. SWEBOK, IEEE Computer
Society, Trial Version 1.00 - May 2001
31
What is software engineering?
multi-person multi-version programming David
Lorge Parnas (1978)
32
What is software engineering?Ref. Van Vliet
Section 1.1
  • NATO 1968 is the establishment and use of sound
    engineering principles in order to obtain
    economically software that is reliable and works
    efficiently on real machines.
  • IEEE 1990 is the application of a systematic,
    disciplined, quantifiable approach to the
    development, operation, and maintenance of
    software that is, the application of engineering
    to software

33
A difference
  • Computer Science
  • artifact/algorithm oriented
  • explores the limits of computing
  • Software Engineering
  • people/process/product oriented
  • explores the limits of computing practice

34
Essential characteristics of software engineering
Ref. Van Vliet Section 1.1
  • concerns the construction of large programs
  • the central theme is mastering complexity
  • software evolves
  • efficiency with which software is developed is of
    crucial importance
  • regular cooperation between people is an integral
    part of programming-in-the-large
  • software has to support its users effectively
  • members of one culture may develop software
    artifacts on behalf of members of another culture

35
What does quality mean for software?
36
-ilities
Usability, Flexibility, Adaptability,
Cost Reliability Timeliness Correctness Functional
ity Maintainability
Testability, Readability, Portability, Integrity,
Device independence, Self containedness,
Reusability, Interoperability, Efficiency,
Clarity, Device efficiency, Security, Robustness,
Completeness, Consistency, Accountability,
Accessibility, Safety, Understandability,
Validity, Human Engineered, Self descriptive,
Fault tolerant, Accuracy, Structuredness,
Conciseness, Legibility, Augmentability,
Modifiability, Resilience, Generality,
Minimality, Modularity, Expandability,
Trustworthiness,...
often these conflict ?
all have a cost ?
37
Does correctness mean right?français correct,
juste, exact ??? What does it mean to say
that software is right ?
38
The subtlety of an ility
  • right means...
  • does what the user wants
  • does what the user asked for
  • can be fixed to do what the user really needs
  • on time
  • on budget
  • first to market
  • ...

39
Work products and software documentation
40
Generic Work Products
  • requirements
  • architecture/design
  • detailed design
  • code
  • test plans
  • test cases
  • Quality of the final product depends on each of
    the above, whether each one is documented or not

41
Are work products always expressed as
documentation?
42
Bad Documentation Practices
  • Case 1
  • necessary evil
  • added as an after-thought
  • little consistency
  • Case 2
  • contract obligation
  • huge, unreadable, document
  • obscure format

hard to read incomplete inaccurate expensive to
maintain
43
Good documentation identifies
  • audience
  • who are the readers?
  • what must the reader know?
  • purpose
  • what should the reader learn?
  • desired qualities
  • useful as a reference
  • complete
  • maintainable

44
Triple purpose documents
focus of design effort record design decisions
Design
what must be coded correctness baseline
Implementation
support change request structure for changes
Maintenance
45
Do triple purpose documents work?
Write a Comment
User Comments (0)
About PowerShow.com