Software Development Methodologies

Similar documents
A Pipelined Approach for Iterative Software Process Model

Implementing a tool to Support KAOS-Beta Process Model Using EPF

Deploying Agile Practices in Organizations: A Case Study

The Role of Architecture in a Scaled Agile Organization - A Case Study in the Insurance Industry

Software Maintenance

ADAPTIVE PLANNING. 1 Powered by POeT Solvers Limited

Including the Microsoft Solution Framework as an agile method into the V-Modell XT

The Seven Habits of Effective Iterative Development

Motivation to e-learn within organizational settings: What is it and how could it be measured?

PROCESS USE CASES: USE CASES IDENTIFICATION

IT4305: Rapid Software Development Part 2: Structured Question Paper

A Context-Driven Use Case Creation Process for Specifying Automotive Driver Assistance Systems

Team Dispersal. Some shaping ideas

Experience and Innovation Factory: Adaptation of an Experience Factory Model for a Research and Development Laboratory

Different Requirements Gathering Techniques and Issues. Javaria Mushtaq

Project Leadership in the Future

Evaluation of Usage Patterns for Web-based Educational Systems using Web Mining

Evaluation of Usage Patterns for Web-based Educational Systems using Web Mining

ESTABLISHING A TRAINING ACADEMY. Betsy Redfern MWH Americas, Inc. 380 Interlocken Crescent, Suite 200 Broomfield, CO

P. Belsis, C. Sgouropoulou, K. Sfikas, G. Pantziou, C. Skourlas, J. Varnas

An Industrial Technologist s Core Knowledge: Web-based Strategy for Defining Our Discipline

Process improvement, The Agile Way! By Ben Linders Published in Methods and Tools, winter

Running Head: STUDENT CENTRIC INTEGRATED TECHNOLOGY

Patterns for Adaptive Web-based Educational Systems

How to Read the Next Generation Science Standards (NGSS)

Trends & Issues Report

Student Handbook 2016 University of Health Sciences, Lahore

Prince2 Foundation and Practitioner Training Exam Preparation

The open source development model has unique characteristics that make it in some

Digital Media Literacy

IBM Software Group. Mastering Requirements Management with Use Cases Module 6: Define the System

Certified Six Sigma - Black Belt VS-1104

Number of students enrolled in the program in Fall, 2011: 20. Faculty member completing template: Molly Dugan (Date: 1/26/2012)

USER ADAPTATION IN E-LEARNING ENVIRONMENTS

Software Development Plan

STANDARDS AND RUBRICS FOR SCHOOL IMPROVEMENT 2005 REVISED EDITION

CREATING SHARABLE LEARNING OBJECTS FROM EXISTING DIGITAL COURSE CONTENT

Brainstorming Tools Literature Review and Introduction to Code Development

Kelso School District and Kelso Education Association Teacher Evaluation Process (TPEP)

Program Assessment and Alignment

Experiences Using Defect Checklists in Software Engineering Education

Lecturing Module

Cooking Matters at the Store Evaluation: Executive Summary

EDITORIAL: ICT SUPPORT FOR KNOWLEDGE MANAGEMENT IN CONSTRUCTION

Being Extreme in the Classroom: Experiences Teaching XP

SECTION I: Strategic Planning Background and Approach

Nearing Completion of Prototype 1: Discovery

Abstract. Janaka Jayalath Director / Information Systems, Tertiary and Vocational Education Commission, Sri Lanka.

OCR LEVEL 3 CAMBRIDGE TECHNICAL

FRESNO COUNTY INTELLIGENT TRANSPORTATION SYSTEMS (ITS) PLAN UPDATE

STANDARD OPERATING PROCEDURES (SOP) FOR THE COAST GUARD'S TRAINING SYSTEM. Volume 7. Advanced Distributed Learning (ADL)

It's Not Just Standing Up: Patterns for Daily Stand-up Meetings

Using Virtual Manipulatives to Support Teaching and Learning Mathematics

Specification of the Verity Learning Companion and Self-Assessment Tool

Delaware Performance Appraisal System Building greater skills and knowledge for educators

The Keele University Skills Portfolio Personal Tutor Guide

From understanding perspectives to informing public policy the potential and challenges for Q findings to inform survey design

A Coding System for Dynamic Topic Analysis: A Computer-Mediated Discourse Analysis Technique

What is PDE? Research Report. Paul Nichols

The Characteristics of Programs of Information

Major Milestones, Team Activities, and Individual Deliverables

A CASE STUDY FOR THE SYSTEMS APPROACH FOR DEVELOPING CURRICULA DON T THROW OUT THE BABY WITH THE BATH WATER. Dr. Anthony A.

IMGD Technical Game Development I: Iterative Development Techniques. by Robert W. Lindeman

Leader s Guide: Dream Big and Plan for Success

The IDN Variant Issues Project: A Study of Issues Related to the Delegation of IDN Variant TLDs. 20 April 2011

Executive Summary. DoDEA Virtual High School

Committee on Academic Policy and Issues (CAPI) Marquette University. Annual Report, Academic Year

Delaware Performance Appraisal System Building greater skills and knowledge for educators

Inquiry Learning Methodologies and the Disposition to Energy Systems Problem Solving

Unit 2. A whole-school approach to numeracy across the curriculum

Abstractions and the Brain

Smarter Lunchrooms- Part 2 Kathryn Hoy, MFN, RD, CDN Manager, Cornell Center for Behavioral Economics in Child Nutrition Programs

Successful Studio-Based Real-World Projects in IT Education

Request for Proposal UNDERGRADUATE ARABIC FLAGSHIP PROGRAM

Myths, Legends, Fairytales and Novels (Writing a Letter)

Blended E-learning in the Architectural Design Studio

Assessment. the international training and education center on hiv. Continued on page 4

With guidance, use images of a relevant/suggested. Research a

PRINCE2 Practitioner Certification Exam Training - Brochure

Vorlesung Mensch-Maschine-Interaktion

Curriculum Scavenger Hunt

Helping Graduate Students Join an Online Learning Community

Developing an Assessment Plan to Learn About Student Learning

e-portfolios in Australian education and training 2008 National Symposium Report

Modeling user preferences and norms in context-aware systems

Assignment 1: Predicting Amazon Review Ratings

DISTANCE LEARNING OF ENGINEERING BASED SUBJECTS: A CASE STUDY. Felicia L.C. Ong (author and presenter) University of Bradford, United Kingdom

10.2. Behavior models

The NH Parent Partner Program

Activities, Exercises, Assignments Copyright 2009 Cem Kaner 1

TEACHING QUALITY: SKILLS. Directive Teaching Quality Standard Applicable to the Provision of Basic Education in Alberta

Specification and Evaluation of Machine Translation Toy Systems - Criteria for laboratory assignments

Qualitative Site Review Protocol for DC Charter Schools

Learn & Grow. Lead & Show

ACADEMIC AFFAIRS GUIDELINES

Executive Summary. Osan High School

Pair Programming: When and Why it Works

Teaching Tornado. From Communication Models to Releases. Stephan Krusche. Department of Computer Science, Technische Universitaet Muenchen

On Human Computer Interaction, HCI. Dr. Saif al Zahir Electrical and Computer Engineering Department UBC

Guidelines for Project I Delivery and Assessment Department of Industrial and Mechanical Engineering Lebanese American University

Transcription:

Software Development Methodologies Lecturer: Raman Ramsin Lecture 9 Agile Methodologies: Crystal 1

Crystal Introduced by Cockburn as a family of methodologies in 1998. New members of the family were defined in 2001 and 2004. Based on the belief that different projects call for different methodologies Flexibility addressed through continuous review and revision of the development process 2

Crystal Methodologies: Project Categories Projects are categorized according to the criticality of the system being produced and the size of the project. Four levels of criticality have been defined, based on what might be lost because of a failure in the produced system: Comfort (C) Discretionary Money (D) Essential Money (E) Life (L) The maximum number of people that might have to get involved in a project is regarded as the measure of the project s size. A category L40 project is a project involving up to 40 people developing a life-critical system. 3

Crystal Methodologies: Complexity Crystal methodologies put heavy emphasis on communication among people involved in the project: Projects with a larger size require heavier (more complex) methodologies, since they involve more people, and hence, need better coordination. Projects with higher criticality call for a more rigorous approach, which might be accommodated by tuning a methodology used for a less critical project. Crystal methodologies are categorized according to the project size that they address. Each member of the Crystal family has been assigned a colour showing its relative complexity: the heavier the methodology, the darker the colour assigned to it. 4

Crystal Methodologies: Family Members Crystal methodologies named in the literature: Clear, Yellow, Orange, Red, Maroon, Blue, and Violet (in ascending order of complexity). Others can be added if a usage context arises. Only those that have been practically used in real projects have been defined: Crystal Orange was introduced in 1998, targeting C40, D40 and E40 projects. Crystal Orange Web was introduced in 2001, and is a variant of Crystal Orange targeting ongoing web development projects. Crystal Clear was introduced in 2004, primarily targeted at C6 and D6 projects. 5

The Crystal Family Project size (number of people involved) 6 [Cockburn 2004]

Crystal Methodologies: Common Traits Adherence to the principles of agile development Iterative-incremental process, with each increment (delivery cycle) lasting no more than four months No support for development of life-critical systems No support for distributed teams The people involved must be collocated (e.g. in the same building). Dependence on effective communication and information flow among team-members for successful enactment 7

Crystal Methodologies: Flexibility Every Crystal methodology: Enforces a development process framework. Requires that a set of certain general process elements be used. Requires that certain work products be produced. But a large body of finer-grained detail is left to the development team to decide; developers are even allowed to use techniques borrowed from other methodologies. The development team(s) selects a base methodology at the start of the project (in the form of a minimal set of working conventions). Reflection Workshops are frequently held to monitor and tune the process. 8

Crystal Clear 1. Primarily targeted at C6 and D6 projects. 2. There is only one development team. 3. Team-members work in close proximity to each other. 4. Usable software is delivered at least once every three months, though delivery is typically expected to be much more frequent. 9

Crystal Clear: Process 1. Chartering: forming the development team, performing a preliminary feasibility analysis, shaping and fine-tuning the development methodology, and developing an initial plan. 2. Cyclic Delivery: the main development engine consisting of two or more Delivery Cycles. Each delivery cycle takes from one week to three months, during which: 1. the team updates and refines the release plan. 2. implements a subset of the requirements through one or more program-test-integrate iterations; the iteration(s) in a delivery cycle are themselves composed of daily and integration cycles. 3. delivers the integrated product to real users. 4. reviews the development methodology adopted and the project plans. 3. Wrap-up: deployment into the user environment, and postdeployment reviews and reflections are performed. 10

Crystal Clear: Process Project Project Chartering Delivery Cyclic Delivery Delivery Wrap-up Delivery recalibrate Iteration Iteration deliver reflect plan Day Day Day reflect & celebrate Iteration daily stand-up Integration Integration Integration Day Episode Episode Episode build & test Integration 11 [Cockburn 2004]

Crystal Clear Process: Chartering 1. Build the core of the team 2. Perform the Exploratory 360 3. Shape and fine-tune the methodology conventions 4. Build the initial project plan 12

Crystal Clear Process: Chartering Activities 1 1. Build the core of the team: 1. An Executive Sponsor: provides monetary and logistical support and essential direction to the team; may also act as domain expert. 2. A Lead Designer: also acts as project manager, coordinator, and technical expert and trainer. 3. An Ambassador User, who acts as the expert on system usage. 4. A number of Systems Analysts, Designer-Programmers, Business Experts, Testers, Text-Writers, Coordinators, and others, as deemed necessary by the team. 2. Perform the Exploratory 360 3. Shape and fine-tune the methodology conventions 4. Build the initial project plan 13

Crystal Clear Process: Chartering Activities 2 1. Build the core of the team 2. Perform the Exploratory 360 : a preliminary feasibility study providing a high-level project-wide review of the key issues governing the development effort: 1. expected business value of the system 2. high-level requirements (usually captured in use cases) 3. domain models 4. technology alternatives 5. overall project plans and constraints 6. necessary resources 7. development methodology 3. Shape and fine-tune the methodology conventions 4. Build the initial project plan 14

Crystal Clear Process: Chartering Activities 3 1. Build the core of the team 2. Perform the Exploratory 360 3. Shape and fine-tune the methodology conventions: A minimal set of rules is agreed upon by the team as the skeleton of the methodology to be used in developing the system. The initial set will be iteratively revised and perfected during cyclic delivery, gradually evolving into a methodology tailored to fit the project in hand. 4. Build the initial project plan 15

Crystal Clear Process: Chartering Activities 4 1. Build the core of the team 2. Perform the Exploratory 360 3. Shape and fine-tune the methodology conventions 4. Build the initial project plan: 1. typically includes a Project Map showing the development tasks and their dependencies, and a Release Plan showing the projected completion dates for delivery cycles and iterations. 2. Tasks are identified, prioritized and estimated using a technique called Blitz Planning, which is a close variant of XP s card-based planning technique. 16

Crystal Clear Process: Cyclic Delivery 1. Each delivery cycle involves the following four activities: 1. Recalibrate the release plan: the requirements and the project plans are reviewed and updated according to the experience gained in the delivery cycles performed so far. 2. Develop in iterations: one or more iterations are performed in every delivery cycle. Each iteration lasts from one week to three months. 3. Deliver to real users: the integrated system is delivered to a small number of users and feedback is used for improving the system and revising the plans and/or the requirements. 4. Reflect on the delivery: through a workshop, the team reflect on the quality of the delivered product, the development methodology and the plans. 17

Crystal Clear Process: Cyclic Delivery - Iteration 1. Iteration planning: a fine-grained plan is produced involving the tasks that should be performed in the iteration. 2. Cyclic program-test-integrate: An iteration consists of cyclic daily activities. A Daily Cycle includes: 1. A stand-up meeting; 2. Several Integration Cycles; during each integration cycle: 1. Designer-programmers perform design-implementation Episodes: they start development tasks, and carry out designing-programming and unit testing. 2. At the end of an integration cycle, the code produced by designerprogrammers during the episodes is integrated into the system, and appropriate integration tests are performed. 3. Iteration completion ritual: a Reflection Workshop is held. 18

Crystal Clear Process: Wrap-up 1. Perform acceptance testing. 2. Prepare the final product and the user environment for final deployment. 3. Carry out system conversion. 4. Perform final reflection aimed at compiling and recording the lessons learned from the project, in order to use them in future projects. 19

Crystal: Strengths and Weaknesses Strengths Iterative-incremental process Continuous integration Iterative development engine governed by planning and reviewing Flexible and configurable process Methodologies used for a low-criticality project can typically be tuned to fit a higher-criticality project, provided that the project size is not increased dramatically. Active user involvement 20

Crystal: Strengths and Weaknesses Strengths (Contd. 1) Early and frequent releases Scalability (though limited) through using different methodologies for different project sizes Continuous validation Specific work-products prescribed, though details and templates are left to the developers to decide [Crystal Clear] Traceability to requirements (though limited) through continuous validation and quality reviews [Crystal Clear] Requirements are allowed to evolve over time [Crystal Clear] Test-based development 21

Crystal: Strengths and Weaknesses Strengths (Contd. 2) [Crystal Clear] Preliminary feasibility analysis conducted as a risk mitigation mechanism [Crystal Clear] Based on system functionality, typically captured in use cases [Crystal Clear] Based on structural modeling of the problem domain [Crystal Clear] Based on a system architecture identified and refined during the process [Crystal Clear] Design activities encouraged, with results documented as Design Notes 22

Crystal: Strengths and Weaknesses Weaknesses Only limited scalability Lack of an unambiguous common process Limited applicability: not suitable for developing highly critical systems Over-dependence on inter-human communication [Crystal Clear] Seamlessness not addressed [Crystal Clear] traceability to requirements suffers because planning and development activities are not necessarily requirements-based (e.g. Blitz Planning is task-based rather than requirements-based). 23

Crystal: Strengths and Weaknesses Weaknesses (Contd.) [Crystal Clear] Design activities are carried out by individual developers in the manner they choose; design is not performed as a team effort with globally available results based on which implementation can be carried out uniformly. [Crystal Clear] Since the detailed nature of many workproducts is left to the individual developers to decide, behavioural and functional modeling can be poor throughout the process. [Crystal Clear] No formalism 24

References Cockburn, A., Surviving Object-Oriented Projects: A Manager's Guide. Addison-Wesley, 1998. Cockburn, A., Agile Software Development: Software through People. Addison-Wesley, 2001. Cockburn, A., Crystal Clear: A Human-Powered Methodology for Small Teams. Addison-Wesley, 2004. 25