CPSC280-1/11/2016

[Varrenhunter]

Traditional Software Processes Analysis:

1. Requirements
2. Analysis
3. Design
4. Implementation
5. Testing incremental testing: All phases are eventually completed, in order of relevance Iterative testing: all phases are applied to handle current aspects Software Processes Code 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:
6. One developer builds initial version, distributes it over the web
7. people download it (if there is interest)
8. 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:

1. Unit testing: methods/classes in isolation
2. Functional testing: module (1+ units) of use functionality
3. Integration testing: adding tested units to existing code
4. 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.