CPSC 491 Lecture Notes Fall 2013

Transcription

1 CPSC 491 Lecture Notes Fall Overview Topics Process models (cont.) Key Ideas Basic definition and advantages/disadvantages of major lifecycle models Homework HW 3 (out) Ch 1, Ch 2: Software Development Process Models Q: What are the typical tasks in software development process models? Requirements what to build Architecture and Design structure, partitioning of system Implementation primarily coding Testing unit, system, user Deployment installation, training Maintenance updates, bug fixes We ll briefly talk about Code-and-fix (Big Bang, Code-like-hell) Waterfall Spiral Incremental (Staged Delivery) Iterative (Evolutionary Prototyping) Iterative (Textbook) Our focus 1

2 2.1 Code-and-fix / Big-Bang / Code-like-hell Q: What is the code-and-fix model? Code and Fix System specification (maybe) Release (maybe) Steps: 1. Start with a general idea of what to build 2. Code like hell 3. Maybe use some combination of: (a) informal design, code, debug, and test methods (b) not required though 4. Step when you have a product ready to release One extreme on the lifecycle scale 2

3 2.2 The Waterfall Model Requirements Analysis Architectural Design The waterfall model is document driven Detailed Design steps or phases Code & Unit/Int Tes<ng product System Tes<ng Notes: project progresses sequentially through each step review held after each step to see if ready to advance the grandaddy of lifecycle models plays a role similar to bubblesort today Can work when: product definition is stable well understood technical approaches used e.g., point or maintenance release or porting a product to a new platform understood but non-trivial projects quality much more important than cost and schedule Q: why are midstream changes expensive? 3

4 Q: What are some of the advantages? can find some errors in the early, low cost stages development easier because of (forced) stable requirements after requirements phase, requirements assumed not to change if they do, you have to backtrack from later stages and repeat supports specialized workers separate roles for requirement engineers, designers, coders, testers each can be a separate expert (like an assembly line) history suggests this doesn t work that well though for SE Q: What are some disadvantages? no software until end of the lifecycle (in system testing) Q: Why is this bad? This is when users could see it and it might not be what they were expecting! hard to fully specify requirements at start of a project software systems are usually too complex / too intangible requires excessive amount of documentation some projects require this though (e.g., safety critical projects) few signs of progress towards an actual product until the end 4

5 2.3 The Spiral Model D($)(& '"(")*+,"&-./"012"%3& 4#("),$12"%3&$,5& 67,%()$+,(%& 85",19:&$,5&!"%7#2"&!+%;%& 67**+(&(7&4>>)7$0C& 97)&A"B(&8(")$17,& <2$#=$("& 4#("),$12"%& '"2"#7>&8(")$17,& '"#+2")$.#"%3&?")+9:& Notes: Breaks project into smaller mini-projects Each mini-project addresses one or more risks Risks are interpreted broadly poorly understood requirements poorly understood architecture performance problems important missing features 5!"#"$%"&

6 A detailed example of one implementation of the model Not to be taken too literally projects may have more or less iterations projects may do different things in each iteration Note: Waterfall is like a cruise Spiral is like a road trip 6

7 Q: What are the advantages? high-risk, not well understood projects ultimate flexibility the model of all models number of iterations, tasks in each iteration as costs increase, risks decrease early iterations are often the cheapest emphasis on risks management control as in waterfall checkpoints and planning after each iteration Q: What are the disadvantages? ultimate flexibility it is complicated need dedicated, focused, informed management have to define what to do before each iteration have to know when you are done Hopefully projects are not so high-risk... we want projects that are fairly well understood 7

8 2.4 Staged Delivery (Incremental Development) Requirements Analysis Architectural Design Deliver product in increments Stage 1: Detailed design, code, debug, test, and deliver Waterfall steps Stage 2: Detailed design, code, debug, test, and deliver Stage n: Detailed design, code, debug, test, and deliver Notes: traditional requirements and architecture design phases show (deliver) software to customer in successively refined stages partition system into subsystems in the beginning add/refine subsystem and deliver result performed one subsystem at a time each increment (stage) is a traditional waterfall approach known what needs to be built before each increment (stage) starts Q: What are the advantages? feedback on product earlier (instead of at end) if important subsystems developed early, users can use right away tangible signs of progress (after each increment) Q: What are the disadvantages? requires careful planning (which stages, details of stage) can be hard to build subsystems independently increments should be meaningful to customer (which can be hard) 8

9 2.5 Evolutionary Prototyping (Iterative Development) Design and Implement Ini/al Prototype Refine Prototype Un/l Acceptable to User Complete and Release Prototype Release requirements, architecture, design, & testing still happens in here Notes: begin by developing most visible aspects of the system demonstrate this part to the user continue to develop prototype based on user feedback when customer agrees prototype is good enough... complete remaining work and release as final product An iteration from the textbook s approach: One iteration Start Requirements Analysis After each iteration, you (ideally) have quality software Design Code After initial requirements and initial design... each iteration becomes a mini-project each iteration produces a working system after each iteration, get user feedback 9 Test

10 2.6 Incremental vs. Iterative Development Assume we want to build a word processor with feature sets: create text organize text (e.g., cut and paste) format text (e.g., font size and style, margins) and so on Using Incremental development design the system first each feature set becomes a separate subsystem 1st increment: develop create text subsystem 2nd increment: develop organize text subsystem continue until each subsystem implemented Using Iterative development create a basic design 1st iteration: implement basic features of multiple feature sets 2nd iteration: enhance quality, extend, and/or modify continue until project is completed Iterative Development works well when... requirements change frequently or are somewhat vague customer reluctant to commit to requirements (unsure of details) application area or technology not well understood time and budget are critical The advantages similar to incremental and spiral 10

11 flexibility (handles change) but has a well-defined process for each iteration so not as open-ended as in spiral model but less flexible high visibility and early customer feedback with short iterations, software for customers to use early Q: What are the disadvantages? Can be hard to estimate time/cost at beginning can gather bulk of requirements first (as in textbook) 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 development true of most models... have to commit to following the process 11

12 3 Requirements The plan Start with user stories Then more on requirements in general Requirement Statement (or just requirement) a single feature or characteristic of the system the feature/characteristic is needed by the customer (to make the system useful) 12

13 4 User Stories A user story is a specific type of requirement statement... Describe one thing the software must do for the customer Written using language the customer understands Written by the customer (not literally...) driven solely by a customer need... even if a developer writes it Short and sweet! usually 1 sentence should fit on one side of a 3x5 card Users stories contain... A meaningful title to uniquely identify the story (short & descriptive) A short description a customer-oriented description of the needed feature good to use a template An acceptance test(s) what needs to happen in the system to claim the story is completed more on this later 13

14 Orion s Orbits Example (book) We need a web site showing our current deals, and we want our users to be able to book suttles and special packages... Show Current Deals! The web site will show current! deals to customers.! Book a Shuttle! A user will be able to book a shuttle from the website.! Book a Special Package! A user will be able to book a special package with extras from the website.! Use AJAX for the UI! The user interface will use AJAX to provide a modern Web-UI experience.! Q: Is the last one meaningful to the customer? User stories should not... use technical terms unfamiliar to the customer mention specific (implementation) technologies unless absolutely required by the customer (more later) be unnecessarily detailed (unless needed by customer) Q: What was wrong with this one? a design decision, not a user story 14

15 Use AJAX for the UI! The user interface will use AJAX to provide a modern Web-UI experience.! User Story Template... It really helps to have your user stories worded consistently One way to achieve this is to use a template for the description: As a (role) I can (feature) so that (reason). For example: As a student I can purchase a parking pass so that I can drive to school. Good practice to include roles and reasons (benefits) not needed if redundant or obvious (from context) 15