meetings good practices n.
Skip this Video
Download Presentation
Meetings Good Practices

Loading in 2 Seconds...

play fullscreen
1 / 36

Meetings Good Practices - PowerPoint PPT Presentation

  • Uploaded on

Meetings Good Practices. Slides already online Printed material to be distributed now You are responsible for material in those slides and printed material [HINT] Quiz over the material next class!!!. Team Notebooks. One for each team: Graded.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Meetings Good Practices' - grant-williamson

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
meetings good practices
Meetings Good Practices
  • Slides already online
  • Printed material to be distributed now
  • You are responsible for material in those slides and printed material
  • [HINT] Quiz over the material next class!!!
team notebooks
Team Notebooks
  • One for each team: Graded.
  • There is no predefined format for the notebook.
    • Meeting records
    • Email
    • Individual contributions
    • Drafts
    • Task assignments
    • Team processing documentation
  • to protect you: describes your contribution to the team.
unique properties of software
Unique Properties of Software
  • (Teams: What are the properties of software that make it unique from other engineering disciplines?)
unique properties of software1
Unique properties of software
  • malleable:
    • can replace ordinary switch with electronic, more "intelligent“
    • the only replaceable component of a deep space craft
  • artificial:
    • not tied to physical properties like civil or mechanical
  • human-intensive:
    • almost no manufacturing: all engineering
  • complex:
    • each bolt is different
  • use:
    • applied out of scope of development
  • young field
software qualities1
Software Qualities:
  • Two types
    • External:
    • Internal:
  • Two categories
    • Product:
    • Process:
software qualities2
Software Qualities:
  • Two types
    • External: visible to users (e.g., speed)
    • Internal: visible to developers (e.g., verifiability)
  • Two categories
    • Product: difficult to measure
    • Process: I can't show you how good it is, but I can tell you how hard we tried
only external factors matter
Only external factors matter.
  • It doesn’t matter if it’s written in C or Java or Lisp or 6502 machine language, so long as it does what it’s supposed to.
  • The internal properties are just a means to achieve external properties.
external software properties







Ease of use







External Software Properties
  • Ability of software to perform tasks as defined by the specification.
  • Note that this is not possible without a specification:
    • if you don’t know what it’s supposed to do, how can you tell if it’s correct?

  • Ability of software to react appropriately to abnormal conditions.
  • This is a compliment to correctness.
  • They do not overlap.

  • The probability that software will provide failure-free operation in a fixed environment for a fixed interval of time (measured per unit time)
  • Probability of failure is the probability that the software will fail on the next input selected (time-independent measure)
  • These two measures can be easily related if you know the frequency with which inputs are executed per unit of time

  • Ease of adapting software to changes in specification
  • Seems like an internal, but when the customer has to wait 6 months for an update, this becomes external
  • Simplify designs, Decentralize the operations (data hiding, etc)

  • Tends to decrease with each release
  • The lifetime of a system is thus limited
  • The opposite of “brittleness”
  • Fight brittleness by refactoring: i.e., changing the internal design to improve evolvability.,r:1,s:0&tx=84&ty=74

compatibility portability
  • Ease of combining software with other systems
  • Able to run on different hardware
  • Examples
    • Is a plotting package compatible with a word processor?
    • Can our system be ported to the Mac?

  • Software places as few demands on resources as possible
    • Hard: real time systems
    • Soft: is it usable?

  • Say you buy a new computer. You could handle N cases before and the new machine is twice as fast.
  • How many cases can you handle?
  • Say you buy a new computer. You could handle N cases before and the new machine is twice as fast.
  • How many cases can you handle?
  • Depends on the algorithm:
    • linear: 2N
    • N2: 41% more
    • 2N: Just 1 more
ease of use
Ease of use
  • What does this mean?

ease of use1
Ease of use
  • What does this mean?
    • How fast an average user can learn to use it? (installation, operation, monitoring).
    • How much does the system help the user?
  • How do you measure it? 
    • ?     
measuring ease of use
Measuring ease of use
  • Non-trivial issue
  • Ease of use contributed to 3 Mile Island Nuclear Power Station failure
  • Advice: Help the user identify problems and perform tasks      
  • The range of things the system can do.
  • How much is enough?
  • It fights against all the others. creeping featurism.

  • Can it be delivered when needed?

  • Can the system be verified?
    • Is it right?
    • How do you know?

  • Can it protect itself from outsiders?

  • Can we modify it?
    • 60% of cost is here
    • corrective: bugs, 20%
    • adaptive: environment change 20%
    • perfective: improve functionality 50%

  • Is it affordable?
  • Can we buy or develop it?
  • Can we maintain it?
    • Programmer staff?
    • Licenses?
    • Hardware?

  • The ability of software elements to be used in different software systems.
    • Should be faster, more reliable.
    • It isn’t always
    • Seems to be more internal than external
  • Consider the construction of a chemical plant.
    • We start with standard parts and assemble them.
    • Consider hardware: assemble standard parts.
    • Consider software?

  • Integrity vs ease of use
  • Economy vs functionality
  • Efficiency vs portability
  • Timeliness vs extendibility
  • Correctness: never a good tradeoff
  • Tradeoffs change with different applications
    • Information systems, real time systems, distributed systems, embedded systems
process improvement
Process Improvement
  • Challenges:
    • Software development is evolutionary and experimental.
    • Software development is not production.
    • The technologies of the discipline are human based.
    • There is a lack of models that allow us to reason about the process and the product.
    • All software is not the same:
      • process is a variable,
      • goals are variable,
      • content varies.
software engineering institute carnegie mellon capability maturity model


Major quality and

quantity improvements



Software Engineering InstituteCarnegie Mellon Capability Maturity Model
  • Managed
  • Substantial quality
  • improvements
  • Comprehensive process
  • measurements






Achieved foundation

for major and continuing






Achieved a stable process

with a repeatable level of

statistical control

  • Initial
  • Ad hoc
  • Little formalization
  • Tools informally
  • applied to process

cmm maturity level 1 initial

No sound SE management principles in place

Ad hoc practices

May be successful because of competent manager and team

Activities are not preplanned, but response to crisis

Unpredictable process

Cannot predict time and cost of development

To get to next level

Initiate rigorous project management, management oversight, and quality assurance

CMM Maturity Level 1: Initial
cmm maturity level 2 repeatable

Basic SE management practices in place

Planning and management are based on experience with similar products (repeatable)

Track costs and schedules

Identify problems as arise and take immediate corrective action

Key practices: quality assurance, CM, project planning

To get to next level

Establish a process group

Establish a software development process architecture

Introduce software engineering methods and technologies

CMM Maturity Level 2: Repeatable
cmm maturity level 3 defined

Process for development fully documented

Reviews used to achieve software quality

Introduce CASE Tools

To get to next level

Establish a basic set of process management to identify the quality and cost parameters

Establish a process database

Gather and maintain process data

Access relative quality of each product and inform management

CMM Maturity Level 3: Defined
cmm maturity level 4 managed

Organization sets quality and productivity goals for each project

Continually measure

Statistical quality control in place

To get to next level

Support automatic gathering of process data

Use data to analyze and modify the process

CMM Maturity Level 4: Managed
cmm maturity level 5 optimizing

Statistical quality and process control techniques are used and guide the organization

Process has positive feedback loop

To maintain level

Continue improvement and optimization of the process

CMM Maturity Level 5: Optimizing