Testing
incremental testing: All phases are eventually completed, in order of relevance
Iterative testing: all phases are applied to handle current aspects
Software ProcessesCode and Fix
No design! no specifications!
the easiest approach, good for small programs, but also the most expensive, changes cost more
Open Source Model
many successful products: OS (linux) IDE (eclipse), Web browsers (FireFox) and Servers (Apache)
Three informal stages:
One developer builds initial version, distributes it over the web
people download it (if there is interest)
Developers (report and correct defects, add new functionality, port to new environments)
Waterfall model
Features: documentation-driven, feedback loops
Advantages: up-to-date documentation, Every phase passes QA (that is, testing)
Disadvantages: Documentation-Driven, up-to-date documentation, user not involved in process (is this what I wanted)
Rapid prototyping model
Waterfall + initial prototype
client tests prototype early, helps to identify missed & refine existing requirements
Developers have early insight into design, reduces likelihood of multiple iterations
Spiral Model
Cyclic approach to incrementally developing software while analyzing risk
Uses prototyping
Review commits client & developer to next iteration
Doesn't preclude revisiting a prior iteration on better alternatives
Problem: over-reliance on risk identification & analysis
Agile Methodologies
Family of methodologies aiming at producing software in short iterations and allowing flexibility
Suitable for small/medium-size projects
Characteristics
Short releases & iterations
release software as often as possible (every 2-3 weeks)
Incremental Design: don't attempt design all up front (not enough is known early)
User Involvement
User always available for feedback
Minimal documentation
software IS the documentation
Informal communication, the aim is to reach understanding
Responsiveness to change, requirements & environment will likely change (deal with it!)
Traditional Processes
Lengthy development times, large projects use complex methodologies
Waste, duplication of effort
hard to cope with changing requirements
resistance toward change (change can cost a fuckton)
Pre-disposition to full requirements up front (we want to know what you want, right away)
XP: Extreme Programming
Principles:
Rapid feedback: pair programming, unit test, continuous intergration
Simplicity: try the simplest possible approach
Incremental changes: don't do big changes, do small changes that add up
Embrace change: solve your most pressing problems first (but keep options up)
Quality work: try to create as good a product as possible.
CRC: class responsibility cards
Brainstorming tool, one index card for each class
Class name on top, responsibilities (behavior) on left
Collaborators (other classes with whom it interacts) on right
Indentifying classes and responsibilities
Classes: look for nouns in the problem description
Responsibilities: look for verbs in the problem description
Relationships between classes:
Dependency: "uses-a", it's asymmetric
Aggregation: "has-a", a field in a class
Inheritance: "is-a" a class extends another class
CRC cards are used to create a working design, not as documentation
Scrum flow: Sprints == 1 increment, lasts 2 to 3 weeks
Kanban board is used to organize
Time-Boxing: increments length is fixed (2-3 weeks), client gets a new version every 2-3 weeks
More XP features
Pair Programming: two programmers work at one computer, no code ownership, but conflicting personalities, experience
Refactoring: modify code to adjust design (without breaking tests)
Minimize Extra-functionality: no need to build more than the client needs YAGNI (You aren't gonna need it) DTSTTCPW (do the simplest thing that could possibly work)
TDD
XP has had some success with small-scale software, good when requirements vague
TESTING
Inspections and reviews: meetings where code is analyzed, pair programming
Formal methods: mathematical techniques proving that designs are sound
Static Anaylsis of source code to identify error-prone conditions.
Testing: Levels of testing:
Unit testing: methods/classes in isolation
Functional testing: module (1+ units) of use functionality
Integration testing: adding tested units to existing code
System testing: whole system
Testing types:
Acceptance testing: with client, prior to delivery
Performance testing: performs as desired (speed, load)
Stress testing: degrades gracefully (overload, lack of resources)
UI testing: UI components & their usability
Black-box testing: does not consider implementation, evaluates input/output behavior
Glass box testing: considers implementation, evaluates internal structure
Equivalence classes: groups of input values clustered by their similarity of result
Boundary value analysis: concentrate on boundaries, we make more mistakes there
Path Analysis: aims at having tests executing every statement at least once
Path coverage: degree in which paths are covered by tests
Cyclomatic complexity= edges - nodes + 2
Technical Considerations
Handling problems:
Decomposition: divide & conquer (identify different tasks the system will perform
Modularization: High cohesion (all common functions in one module
Seperating Responsibilities: Low coupling (modules interact between well-defined interfaces)
Incremental iterations: Incremental: All aspects are eventually handled
Iterative: all phases are applied to handle current aspects
PSP0
PSP0 is about knowing oneself and ones habits.
Traditional Software Processes Analysis:
XP: Extreme Programming Principles: Rapid feedback: pair programming, unit test, continuous intergration Simplicity: try the simplest possible approach Incremental changes: don't do big changes, do small changes that add up Embrace change: solve your most pressing problems first (but keep options up) Quality work: try to create as good a product as possible. CRC: class responsibility cards Brainstorming tool, one index card for each class Class name on top, responsibilities (behavior) on left Collaborators (other classes with whom it interacts) on right Indentifying classes and responsibilities Classes: look for nouns in the problem description Responsibilities: look for verbs in the problem description Relationships between classes: Dependency: "uses-a", it's asymmetric Aggregation: "has-a", a field in a class Inheritance: "is-a" a class extends another class CRC cards are used to create a working design, not as documentation Scrum flow: Sprints == 1 increment, lasts 2 to 3 weeks Kanban board is used to organize Time-Boxing: increments length is fixed (2-3 weeks), client gets a new version every 2-3 weeks More XP features Pair Programming: two programmers work at one computer, no code ownership, but conflicting personalities, experience Refactoring: modify code to adjust design (without breaking tests) Minimize Extra-functionality: no need to build more than the client needs YAGNI (You aren't gonna need it) DTSTTCPW (do the simplest thing that could possibly work) TDD XP has had some success with small-scale software, good when requirements vague TESTING Inspections and reviews: meetings where code is analyzed, pair programming Formal methods: mathematical techniques proving that designs are sound Static Anaylsis of source code to identify error-prone conditions. Testing: Levels of testing:
PSP0 PSP0 is about knowing oneself and ones habits.