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