Lecture 1-2

On Building Software

CS 300 Lecture 2-1
Bart Massey

Engineering Constraints

  • Time

  • Resources:

    • Consumable: money, materials
    • Capacity: people, equipment
  • Knowledge: technology, domain

  • Quality and other "-ilities":

    • Utility, safety, security, reliability
    • Performance: time and memory
  • Society: business, ethics

Software Engineering Roles

  • Software is made of people

  • On the whole: customer, user, developer, subcontractor, auditor, reseller

  • Development: project manager, system engineer, architect, designer, programmer, tester, librarian

  • People don’t match roles 1:1

    • Programmer and tester should usually be different
    • Architect should usually be a single person

Intro to Process: Planning and Estimating

  • Identify work activities

  • Prepare a schedule

  • Marshall resources

Intro to Process: Measuring and Controlling

  • Quality

  • Productivity

  • Project Evolution

Intro to Process: The Waterfall Model

  • Execute phases (requirements, design, implement, test) in order until each is done

  • Not realistic:

    • Later phases expose defects in and constraints on earlier phases
    • Requirements change throughout a project
  • More realistic approach:

    • Iterative waterfall: Go through phases repeatedly on larger and larger versions of the project
    • Incremental waterfall: Work backward and forward as needed to get to a complete iteration

Intro to Process: Agile Methods

  • Carry iterative/incremental to natural extreme: tiny increments in "natural" order

  • Characterized by a specific set of practices

    • "User Stories"
    • "Standups"
    • "Sprints"
    • "Pair Programming"
    • "Test-driven Development"
  • Claimed by many to be an improvement

    • Easier to manage than "C&C" methods
    • Better efficiency, happier workers

Intro to Process: Open Source

  • Inspired Agile in many ways

  • Implies a code-centric process

  • Highly informal incremental requirements / design

  • Emphasis on "user testing": tight feedback loop from field to source code

  • Leverages large numbers of small contributions

Intro to Process: Special Methods

  • Spiral model: Iterative discovery for risk management

  • Formal methods (e.g. "Cleanroom"): Derive software rigorously from formal description. Prove software properties formally

Risk Management

  • Risk severity is likelihood times impact

  • High severity risks need to be enumerated and addressed

  • Typically, this is done in a Risk Management Plan

    • Risks that can't be avoided need to be tracked
    • Ameliorations must be executed when needed

Applicability Of All This Stuff?

  • So far, you have mostly been in courses where:

    • Requirements and design are given to you
    • Projects are small
    • Any software you produce is evaluated (weakly) by professionals
    • There is no life cycle beyond delivery
  • Once you get away from all that, there's a bunch of machinery you'll need to be successful

    • Typically 40-60% of project effort is outside the project life cycle altogether
    • You begin so see why it takes so many engineers to produce even a little bit of software
Last modified: Sunday, 4 October 2015, 11:23 PM