Today: Software Development Models (cont)

Transcription

1 Today: Software Development Models (cont) CPSC 491 Development Processes (aka Development Lifecycle) Define the steps, and their order, to be carried out The main steps (or phases) generally include: 1. Requirements what to build 2. Architecture & Design structure, partitioning of system 3. Implementation primarily coding 4. Testing unit, system, user 5. Deployment installation, training 6. Maintenance updates, bug fixes, upgrades

2 Development Processes (aka Development Lifecycle) We ll briefly look at: Code-and-fix (Big Bang, Code-like-hell) Waterfall Spiral Incremental (Staged Delivery) Iterative (Evolutionary Prototyping) Iterative (Scrum-like) Code-and-Fix / Big-Bang / Code-Like-Hell Steps 1. Start with a general idea of what to build 2. Code like hell 3. Maybe use some combination of (optional) informal design, debug/test methods 4. Stop when you have a product ready to release

3 Code-and-Fix / Big-Bang / Code-Like-Hell What are disadvantages? assessing progress assessing quality if you find halfway through your design is flawed usually have to start over (rework) identifying and mitigating risks Code-and-Fix / Big-Bang / Code-Like-Hell What are advantages? no overhead just pure coding! classic mistake: upstream mistakes x more expensive to fix downstream can show signs of progress early (unless team goes dark ) requires little expertise (just need to program) good for bug-fix type projects

4 Waterfall Model Notes progress sequentially through steps review held after each step (to advance) if mistakes, backtrack and redo assembly line development Waterfall Model What are advantages? Can find (some) errors early on Tasks easier because of (forced) stable requirements assume they don t change, but if they do have to backtrack Helps to ensure high-quality (but large overhead)

5 Waterfall Model What are disadvantages? no software until late in the project low visibility for actual software (few signs of progress) hard to capture all requirements at start for most projects excessive documentation (can waste time, unless required) Spiral Model Notes break project into smaller mini-projects each mini-project addresses one or more risks risks are interpreted broadly poorly understood requirements, architecture, performance problems missing features

6 Example from Rapid Application Development Just an example: projects may have more or less iterations projects may do different steps in each iteration Spiral Model What are the advantages? as costs increase (later iterations), risks decrease checkpoints/planning each iteration (management control) good for high-risk, not well understood projects ultimate flexibility waterfall is like a cruise, spiral like a road trip

7 Spiral Model What are the disadvantages? complicated (especially for managers) need focused, experienced management complicated because of ultimate flexibility most projects are not so high-risk Staged Delivery (Incremental Development) Notes waterfall-like requirements and design steps show (deliver) software in each stage partition system in subsystems in beginning implement one subsystem at a time each stage (increment) is a traditional waterfall approach

8 Staged Delivery (Incremental Development) What are the advantages? feedback on product (visibility) earlier, instead of at end similarly, tangible signs of progress (after each increment) if important subsystems developed early, can be used Staged Delivery (Incremental Development) What are the disadvantages? requires careful planning (# of stages, details of each) can be hard to build subsystems independently increments must be meaningful to customer (for visibility)

9 Evolutionary Prototyping (Iterative Development) Notes focus on visible aspects in each iteration demonstrate prototype to customer/user after each iteration continue to extend prototype based on user feedback stop when customer/users agree good enough complete remaining work and release Example Scrum-like Iteration After initial requirements and rough design each (weekly) iteration becomes a mini-project each iteration produces a working system get feedback at end of iteration from customers/users after each iteration, use feedback to plan tasks for next iteration

10 Incremental vs Iterative Assume we want to build a word processor with features for: creating text organizing text (e.g., cut and paste) formatting text (e.g., font size, style, margins) etc. Incremental Development: define subsystems (e.g., viewing, editing, managing files, ) order subsystems: managing files, viewing, editing, 1st increment: files; 2nd: viewing,... Iterative Development: come up with a basic design 1st iteration: basic features from each subsystem etc. Iterative Development What are some advantages? visibility (after each iteration) identify and adapt to changes early time and budget constraints (each iteration extends working system) good for customers unsure of (or reluctant to commit to) features

11 Iterative Development What are some disadvantages? can be hard to estimate time/cost at beginning try to gather bulk of requirements first then in iterations, deal with changes can lead to do-stuff-until-we-run-out-of-time-or-money can degrade to code-and-fix or quality issues if not careful Introduction to Sprints Work on your milestones as a series of iterations called sprints in scrum usually 1-2 weeks (for your project, keep to 1 week) Each sprint has a goal (what functionality/stories are you tackling?) something to show customer at end of sprint (visibility) ideally, extensions to working prototype Product Backlog : unfinished milestone stories Sprint Backlog : unfinished sprint stories

12 Exercise Plan your first sprint What is the goal of the sprint? what functionality? What stories go into your sprint backlog? What will you show the customer? What feedback will you get? How will it help? Selecting the Sprint Backlog Users (product owners) choose sprint backlog (w/ developers) largely based on priorities and estimates usually, one sprint at a time choose stories at end of previous sprint based on result of previous sprint, etc. And developers help decide how many stories per sprint based on velocity and story estimates you might need to re-estimate stories as you learn more may need to split, refine, or reprioritize stories

13 Carrying out Sprints 1. Determine tasks break stories into tasks, analyze task dependencies 2. Divide up tasks among developers one task per developer record who is working on what (e.g., initials on stickies) typically many tasks (if not, probably too coarse) 3. Work on tasks select tasks to work on and do them do tasks for higher-priority stories first try to avoid half-finished stories What tasks are in your first sprint? Exercise identify the tasks and any dependencies divide up the tasks and record who is working on what identify which tasks will be done first Note: Weekly task sheets

14 Task Boards (Project Dashboards ) Example... An Alternative Layout

15 Using the Task Board Update the task board daily (at least) move finished tasks or stories to done check out new tasks or stories move next stories to swim lanes (main part of board) update burn down chart (more later) For your team since not working full time may not make sense to update daily but still a good idea to keep track of progress mid-week How it works -- Day 1

16 How it works -- Day 2 How it works -- After a few more days

17 The Task Board Conceptually, task board is how to think about iterations e.g., contrast this with Gantt charts Give big picture of progress Focused on entire project whereas for task boards Give day-to-day detailed view of progress Focused on one sprint (e.g., one week) In general, task boards meant to be flexible/adaptable structure them to what works best for your team okay to add, remove, change layout Examples of Task Boards in the Wild

18 Daily Stand Up Meetings Meetings so short you don t have time to sit down typically 5-15 meetings at most done in the morning, before team starts working Goal is to check in on progress, issues, and plan everyone s input on how development is going update task board and burn down as needed discuss what happened yesterday and plan for today Tracking Progress with Burn Down Charts A burn down chart shows where you are in the iteration plot a new point on the graph each work day y-axis is the estimated effort (e.g., total dev days) x-axis is the number of actual dev days left

19 Burn Down Charts Burn Down Charts

20 Unplanned Tasks Happen Expect new (unexpected) tasks to pop up sometimes even entire stories New tasks/stories usually throw off the schedule they add work left to your burn down chart may be able to catch up (e.g., if small tasks) may require reprioritization (talk with customer) Finishing up the Sprint Need to allow time to check in with customer demo the new features, show design changes, get feedback to improve product discuss goals / stories for next iteration Do an iteration review ( retrospective ) what went well? what could have gone better? what changes for next time (process, tools, )? what was your velocity?