e Learning Design Methodologies 1 Software Life

e. Learning Design Methodologies 1

Software Life Cycle Models 1950 s Code & Fix 1960 s Design-Code-Test-Maintain 1970 s Waterfall Model 1980 s Spiral Model 1990 s Rapid Application Development 2000 s Agile Methods 2

Development Methodologies (1/2) n n n Agile software development Agile Unified Process (AUP) Open Unified Process Best practice Cathedral and the Bazaar, Open source Constructionist design methodology (CDM) n n n Cowboy coding Design by Use (DBU) Design-driven development (D 3) Don't repeat yourself (DRY) or Once and Only Once (O 3) Dynamic Systems Development Method (DSDM) Extreme Programming (XP) 3

Development Methodologies (2/2) n n n n Iterative and incremental development KISS principle (Keep It Simple, Stupid) MIT approach Quick-and-dirty Rational Unified Process (RUP) Scrum (management) Spiral model Software Scouting n n n Test-driven development (TDD) Unified Process Waterfall model Worse is better (New Jersey style) Extreme Programming (XP) You Ain't Gonna Need It (YAGNI) 4

Code-and-Fix n n n “Code-like-Hell” Specification (maybe), Code (yes), Release (maybe) Advantages ¡ ¡ n Disadvantages ¡ ¡ n No overhead Requires little expertise No process, quality control, etc. Highly risky Suitable for prototypes or throwaways 5

“Waterfall” Model 6

Activities by % of Total Effort NASA’s “Manager’s Handbook for Software Development” 7

Potential Deliverables by Phase 8

Concept Exploration n n The “Why” phase Not a “mandatory formal” phase ¡ n Collecting project ideas ¡ n Then the “funneling” process Project Justification ¡ ¡ ¡ n Sometimes called the “pre-project” phase ROI Cost-benefit analysis Project Portfolio Matrix Initial planning and estimates 9

Concept Exploration n Possibly includes Procurement Management: n n Gathering the initial team ¡ n Including PM if not already on-board Identify the project sponsor ¡ n RFP Process Vendor selection Contract management Primary contact for approval and decision making Potential Phase Outputs: ¡ Concept Document, Product Description, Proposal, SOW, Project Charter 10

Concept Exploration n Characteristics & Issues ¡ ¡ Lack of full commitment and leadership Some frustrations: n n n ¡ ¡ Management only getting rough estimates from development Development not getting enough specifics from customer Finding a balanced team Budget sign-off may be your 1 st major task Achieved via: n n n Good concept document or equivalent Demonstration of clear need (justification) Initial estimates 11

Requirements n n n The “What” phase Inputs: SOW, Proposal Outputs: ¡ Requirements Document (RD) n n ¡ ¡ ¡ a. k. a. Requirements Specification Document (RSD) Software Requirements Specification (SRS) 1 st Project Baseline Software Project Management Plan (SPMP) Requirements Approval & Sign-Off n Your most difficult task in this phase 12

Requirements n n Perhaps most important & difficult phase Shortchanging it is a ‘classic mistake’ Can begin with a Project Kickoff Meeting Can end with a Software Requirements Review (SRR) ¡ For Sponsor and/or customer(s) approval 13

Why are Requirements so Important? 14

Requirements n Characteristics & Issues ¡ ¡ Conflict of interest: developer vs. customer Potential tug-of-war: n n ¡ ¡ n Disagreement on Features & Estimates Especially in fixed-price contracts Frequent requirements changes Achieving sign-off Project planning occurs in parallel 15

Requirements n Requirements are capabilities and condition to which the system – more broadly, the project – must conform 16

2 Types of Requirements ¡ Functional (behavioral) ¡ ¡ Features and capabilities Non-functional (a. k. a. “technical”) (everything else) ¡ ¡ ¡ ¡ Usability n Human factors, help, documentation Reliability n Failure rates, recoverability, availability Performance n Response times, throughput, resource usage Supportability n Maintainability, internationalization Operations: systems management, installation Interface: integration with other systems Other: legal, packaging, hardware 17

Requirements n Other ways of categorizing ¡ Go-Ahead vs. Catch-up n ¡ Backward-looking vs. Forward-looking n n n Backward: address issues with previous version Forward: Anticipating future needs of customers Must be prioritized n n Relative to competition Must-have Should-have Could-have (Nice-to-have: NTH) Must be approved 18

Analysis & Design n The “How” Phases Inputs: Requirements Document Outputs: ¡ ¡ ¡ Functional Specification Detailed Design Document User Interface Specification Data Model Prototype (can also be done with requirements) Updated Plan (improved estimates; new baseline) 19

Analysis & Design n a. k. a. Top-level design & detailed design Continues process from RD Ends with Critical Design Review (CDR) ¡ ¡ Formal sign-off Can also include earlier Preliminary Design Review (PDR) for high level design 20

Development n n n The “Do It” phase Coding & Unit testing Often overlaps Design & Integration phases ¡ ¡ To shorten the overall schedule PM needs to coordinate this 21

Development n Other concurrent activities ¡ ¡ ¡ Design completion Integration begins Unit testing of individual components Test bed setup (environment and tools) Project plans updated Scope and Risk Management conducted 22

Development n Characteristics ¡ ¡ ¡ n Pressure increases Staffing at highest levels Often a “heads-down” operation Issues ¡ ¡ Last-minute changes Team coordination (esp. in large projects) Communication overhead Management of sub-contractors 23

Integration & Test n n Evolves from Dev. Phase Often done as 2 parallel phases ¡ n n n Partial integration & initial test Starts with integration of modules An initial, incomplete version constructed Progressively add more components 24

Integration & Test n n n Integration primarily a programmer task Test primarily a QA team task Integration: ¡ ¡ ¡ Top-down: Core functionality first, empty shells for incomplete routines (stubs) Bottom up: gradually bind low-level modules Prefer top-down generally 25

Integration & Test n Tests ¡ ¡ ¡ n Integration testing Black & White-box testing Load & Stress testing Alpha & Beta testing Acceptance testing Other activities ¡ Final budgeting; risk mgmt. ; training; installation preparation; team reduced 26

Integration & Test n Characteristics & Issues ¡ ¡ ¡ ¡ Increased pressure Overtime Customer conflicts over features Frustration over last-minute failures Budget overruns Motivation problems (such as burnout) Difficulty in customer acceptance n Esp. true for fixed-price contracts 27

Deployment & Maintenance n Installation depends on system type ¡ n n Migration strategy How to get customers up on the system ¡ n Web-based, CD-ROM, in-house, etc. Parallel operation Deployment typically in your project plan, maintenance not 28

Deployment & Maintenance n Maintenance ¡ ¡ ¡ n n n Fix defects Add new features Improve performance Configuration control is very important here Documents need to be maintained also Sometimes a single team maintains multiple products 29

Deployment & Maintenance n Characteristics & Issues ¡ ¡ ¡ Lack of enthusiasm Pressure for quick fixes Insufficient budget Too many patches Personnel turnover Regression testing is critical n Preferably through automated tools 30

Lifecycle Planning n n a. k. a. Lifecycle Management or SDLC Greatly influences your chance of success Not choosing a lifecycle is a bad option Three primary lifecycle model components ¡ ¡ ¡ Phases and their order Intermediate products of each phase Reviews used in each phase 31

Lifecycle Planning n n n Different projects require different approaches You do not need to know all models by name You should know how that if given a certain scenario what sort of SDLC would be appropriate There are more than covered here A lifecycle is not a design, modeling or diagramming technique ¡ The same technique (UML, DFD, etc) can be used with multiple lifecycles 32

Pure Waterfall n n The “granddaddy” of models Linear sequence of phases ¡ n n “Pure” model: no phases overlap Document driven All planning done up-front 33

Waterfall Risk n n Why does the waterfall model “invite risk”? Integration and testing occur at the end ¡ Often anyone’s 1 st chance to “see” the program 34

Pure Waterfall n Works well for projects with ¡ ¡ Stable product definition Well-understood technologies Quality constraints stronger than cost & schedule Technically weak staff n n Provides structure Good for overseas projects 35

Pure Waterfall n Disadvantages ¡ Not flexible n ¡ ¡ ¡ Rigid march from start->finish Difficult to fully define requirements up front Can produce excessive documentation Few visible signs of progress until the end 36

SSADM n n Only covers part of the system development process, i. e. analysis and design. It emphasises the importance of the correct determination of systems requirements. 37

SSADM Stages n Feasibility Study ¡ n Requirements Analysis ¡ ¡ n Stage 0 – Feasibility Stage 1 – Investigation of current requirements Stage 2 – Business Systems Options Requirements Specification ¡ Stage 3 – Definition of Requirements 38

SSADM Stages n Logical System Specification ¡ ¡ n Stage 4 – Technical System Options Stage 5 – Logical Design Physical Design ¡ Stage 6 – Physical Design 39

Spiral 40

Spiral n n n Emphasizes risk analysis & mgmt. in each phase A Series of Mini-projects Each addresses a set of “risks” ¡ n n Start small, explore risks, prototype, plan, repeat Early iterations are “cheapest” Number of spirals is variable ¡ Last set of steps are waterfall-like 41

Spiral n Advantages ¡ ¡ ¡ n Can be combined with other models As costs increase, risks decrease Risk orientation provides early warning Disadvantages ¡ ¡ More complex Requires more management 42

Evolutionary Prototyping n Design most prominent parts first ¡ n Good for situations with: ¡ ¡ ¡ n n Usually via a visual prototype Rapidly changing requirements Non-committal customer Vague problem domain Provides steady, visible progress Disadvantages ¡ ¡ ¡ Time estimation is difficult Project completion date may be unknown An excuse to do “code-and-fix” 43

Staged Delivery n n n Waterfall steps through architectural design Then detailed design, code, test, deliver in stages Advantages n n n Disadvantages n n n Customers get product much sooner Tangible signs of progress sooner Problems discovered earlier Increases flexibility Reduces: status reporting overhead & estimation error Requires more planning (for you the PM) More releases increase effort (and possible feature creep) How’s this differ from Evolutionary Prototyping? 44

V Process Model 45

V Process Model 46

V Process Model n Designed for testability ¡ n n Variation of waterfall Strengths ¡ n Encourages V&V at all phases Weaknesses ¡ ¡ n Emphasizes Verification & Validation Does not handle iterations Changes can be more difficult to handle Good choice for systems that require high reliability such as patient control systems 47

RAD n n Rapid Application Development Popular in the 80’s ¡ ¡ ¡ 1. Joint Requirements Planning (JRP) 2. Joint Application Design (JAD) 3. Construction n n ¡ n Heavy use of tools: code generators Time-boxed; many prototypes 4. Cutover Good for systems with extensive user input available 48

XP: e. Xtreme Programming n n n n Not a Microsoft product Part of movement called “Agile Development” A “Lightweight” methodology A bit counter-culture Currently in vogue Motto: “Embrace Change” Highly Incremental / Iterative 49

e. Xtreme Programming 50

e. Xtreme Programming n n n n Suitable for small groups Attempts to minimize unnecessary work Uses an “on-site” customer Small releases Pair programming Refactoring Stories as requirements You want good developers if you use this 51

Other “Agile” Methodologies n n n Agile here means “lite”, reduced docs, highly iterative Agile Software Development SCRUM ¡ n Features 30 -day “Sprint” cycles Feature Driven Development (FDD) ¡ XP with more emphasis on docs and process 52

Other “Agile” Methodologies n n Adaptive Software Development (ASD) Dynamic System Development Method (DSDM) ¡ n Popular in Europe Homegrown: developers often hide their “agile adventures” from management 53

Other “Agile” Methodologies n Pros ¡ ¡ ¡ n Similar to XP, can reduce process overhead Responsive to user feedback Amenable to change Cons ¡ ¡ ¡ Requires close monitoring by PM May not “scale” to large projects Often requires better quality developers 54

Rational Unified Process n n n n RUP From Rational Corporation “Generic” version is the Unified Process Commercial Extensive tool support (expensive) Object-oriented Incremental Newer 55

Rational Unified Process 56

Rational Unified Process n n n n n Develop Iteratively Manage Requirements Uses UML (Unified Modeling Language) Produces “artifacts” Use component-based architecture Visually model software Complex process A “framework” Suitable for large scale systems 57

Choosing Your Lifecycle n n n Varies by project Opt for “iterative” or “incremental” How well are requirements understood? What are the risks? Is there a fixed deadline? How experienced is the team or customer? 58

IEEE 1074 n A standard for developing software processes ¡ ¡ ¡ Lifecycle model selection Project management process Predevelopment processes Development processes Post-development processes Integral process 59

Unified Modelling Language 60

Use cases diagram UML 2 Use cases diagrams describes the behavior of the target system from an external point of view. Use cases describe "the meat" of the actual requirements. n Use cases. A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse. n Actors. An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures. n Associations between actors and use cases are indicated by solid lines. An association exists whenever an actor is involved 61 with an interaction described by a use case.

Use cases diagram 62

Use cases diagram 63

Use cases diagram 64

Class diagram UML class diagrams show the classes of the system, their inter-relationships, and the operations and attributes of the classes n n n Explore domain concepts in the form of a domain model Analyze requirements in the form of a conceptual/analysis model Depict the detailed design of object-oriented or object-based software 65

Class diagram 66

Class diagram 67

68