etreme rogramming (XP) eXtreme Programming (XP)

2 A Typical XP Project All programmers in a room together Work in a series of fixed iteration cycles –Typically 1-3 weeks each –Usually same iteration size for every iteration –Time-boxed

3 At The Beginning Meet the customer for planning –Requirement analysis Break each feature (user story) down into individual tasks for developers to estimate and sign up Setup infrastructure

4 For Each Iteration Determine the tasks for the iteration Team sign up for and implement the tasks Pair programming and test-first all codes Customer provides acceptance tests At the end, team deliver a working system Coded to standard Functionally tested All refactored Fully integrated Free of defects

Dilbert on XP

6 XP Claims XP team is much more productive –Delivers well-designed and well-tested code faster, on time and on budget XP is highly disciplined –Won't write any functionality that doesn't fulfill a specific, explicit customer need (YAGNI) –Write all production code in pairs and test-first –Deliver a fully functional system at the end of each 1-3 week iteration

Systems Analysis Determine what information and information processing are needed.

8 Good Characteristics for Requirement Determination Impertinence: question everything Impartiality: find the best solution Attention to details: every fact must fit with other facts Reframing: look at the organization in new ways

9 Requirement Determination Techniques Interview and listen –Individual or group Questionnaires Observe users Analyze procedures and documents Identify use cases Joint Application Design (JAD) Prototyping

System Analyst 10

How Great Product Are Designed… 11

12 Good Requirements Focus on “what”, not “how” Include both functional and nonfunctional requirements Are correct, consistent, complete, realistic, necessary, verifiable, traceable Categorizing requirements 1.Critical (must be met) 2.Highly desirable (but not necessary) 3.Good to have

13 Structuring Requirements Traditional analysis –Process modeling Data Flow Diagram (DFD) –Logic modeling Structured English, decision table, decision tree –Data modeling Entity Relationship (ER) Diagram Object-oriented analysis –UML diagrams

14 Data Flow Diagram (DFD) Graphically represent the functions (processes) which capture, manipulate, store, and distribute data between a system and its environment –Concentrate on data movement Context Diagram Level-0 Diagram

15 Logic Modeling Represent the internal structure and functionality of the processes on DFD Structured English Decision table Decision tree

16 Object-Oriented Analysis and Design (OOAD) Represent relationships as well as data and data processing using objects UML- Class Diagram

17 Agile Analysis Users write a set of stories that describe things the system should do for them –The set of stories becomes, in effect, a working requirement specification Stories contain about sentences each, without technical jargons

18 User Stories

A User Story 19

Story/Kanban Boards 20

A Good Story Is … (by Bill Wake, 2003) Independent Negotiable Valuable to users Estimatable Small Testable 21

22 Where Do We Start? 1.Meeting client to determine requirements (user stories) 2.Analysis and estimation 3.Set up the infrastructure 4.Determine your workload 5.Reevaluating and prioritizing user stories 6.Choosing and estimating tasks 7.Manage expectation