Copyright 2015, Robert W. Hasker

Classic Model Gathering Requirements Specification Scenarios Sequences Design Architecture Class, state models Implementation Source Unit tests Verification System tests Acceptance tests Dates to 1970.

Classic Model Gathering Requirements DesignImplementationVerification Late delivery Expensive waits Response to change: Wait until next release Revisit previous phase Basic issue: leave model

Why still in use? Gathering Requirements DesignImplementationVerification Simple Covers key deliverables Well-defined benchmarks

Simple fix: Iteration ReqsDesignImpl.VerificationReqsDesignImpl.VerificationReqsDesignImpl.Verification

Simple fix: Iteration ReqsDesignImpl. Verifica tion ReqsDesignImpl. Verifica tion ReqsDesignImpl. Verifica tion Advantages Customer feedback before final delivery Helps convince customer progress is being made Handles scheduling problems (lack of people, hardware Disadvantage Customer may judge software in terms of what's missing

Unified Process  Observation: no phase ever really complete  Varying levels of effort by time Dutchguilder, Wikipedia

Unified Process Phases  Business Modeling, Requirements  identify preliminary use cases, develop preliminary architecture, outline development  Primary goal: establish goals for project and each iteration (with input from all stakeholders)  Key issue: address business and requirements risks  Analysis & Design:  establish baseline architecture  Rest of project: filling "gaps" within the architecture  Implementation, Test  Make use cases operational for end users  Deployment  End result: available for customers/end users

Evaluation  Very flexible  Rational: detailed definitions for each phase  Robust enough for very large projects

Agile  2001: Manifesto for Agile Software Development  Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan

Alternatives to Scrum  Extreme Programming (XP):  Stories done in strict order defined by customer  Strongly encourages Test-Driven Development, pair programming, minimal design  Feature-Driven Development (FDD):  Up front planning, design  Implementation: check off tasks

Other methods  Component-based development  System = sum of off –the-shelf components  Issues: design compromises, testing dependency  Aspect-oriented development  Aspects: operations to be executed before/after method calls  Clean integration of policy and data  Formal methods  Prove code works!

What should we use?  Formal tool for comparing: Capability Maturity Model

What should we use?  Formal tool for comparing: Capability Maturity Model  Every model:  Talk to customer, plan, structure solution, implement, verify, deploy  VCS, risk analysis, review, project tracking & control  Key observation:  Real savings in the small choices made by the team  How to process issues, verify, validate

Where have we been?  Scrum: why?  CI: why not?  UI Design: reviewing interfaces  Process alternatives

Course Goals  Plan and track team software development activities  Generate software process artifacts that are necessary in software quality assurance  Apply software tools needed in the lifecycle of a team software project  Identify the key objectives and deliverables of the phases defined by an agile development process  Design, implement, and work within a continuous integration environment

Final  Bring computer, one page of notes, front and back  Scrum:  A few q’s on agile principles (why)  Review, retrospective, roles, stories, sprints: MC  Testing: acceptance, system, unit, integration  Coverage: statement, decision, condition, MCDC, path, mutation  User interface: user types, postures, principles: MC  Guidelines for effective reviews  Cognitive walkthrough, heuristic evaluation  Continuous inspection, deployment, feedback  Process: waterfall, iterative, Unified Process, CMMI