Chapter 23 Rapid Development Methodologies Rapid development methodologies

  • Slides: 25
Download presentation
Chapter 23 Rapid Development Methodologies

Chapter 23 Rapid Development Methodologies

Rapid development methodologies n n Objective: to speed up the development process in order

Rapid development methodologies n n Objective: to speed up the development process in order to cope with rapidly changing business needs Business environment: n n n increasingly competitive customer-focused international and therefore continuously changing Methodologies: 1. James Martin Rapid Application Development -JMRAD 2. Dynamic System Development Method – DSDM 3. Extreme Programming – XP 4. Web IS Development Methodology - WISDM 2

Rapid development methodologies n n to meet the goal to develop IS quickly general

Rapid development methodologies n n to meet the goal to develop IS quickly general characteristics n incremental development & prototyping n timeboxing (suggestions vary from 90 days to 6 months) n IS is divided up into a number of components that are developed in a prioritized order (according to functions) n time & resources are fixed, functionalities vary (opposite to traditional development) n 80/20 rule n 80% of the functionalities can be delivered with 20% of resources n Mo. SCo. W rules n requirements are prioritized: M=must haves; S=the should haves; C=the could haves; W=the won’t have n Joint Application Development workshops for user participation n sponsor and champion committed n tools to speed up the development process 3

RAD and IE 4

RAD and IE 4

James Martin’s RAD (JMRAD) n Key characteristics n n n prototyping/evolutionary approach identifying and

James Martin’s RAD (JMRAD) n Key characteristics n n n prototyping/evolutionary approach identifying and involving the users at early stages of development obtaining commitment from the business users requires a toolset with a sophisticated repository Four phases n n Requirements Planning (joint requirements planning) User Design (joint applications development) Construction (user design to detailed design and concrete programming; prototyping) Cutover (comparison between old and new system) 5

Phases of the RAD approach 6

Phases of the RAD approach 6

Dynamic Systems Development Method (DSDM) n n “an approach to building and maintaining computer-based

Dynamic Systems Development Method (DSDM) n n “an approach to building and maintaining computer-based systems, which combines effective use of tools and techniques, prototyping and tight project delivery timetables” to fix RAD’s image of “quick and dirty” to proper method (1994), yet it is more like a framework than a method 7

Dynamic Systems Development Method (DSDM) • Seen as more of a framework than a

Dynamic Systems Development Method (DSDM) • Seen as more of a framework than a methodology it leaves much of the detail of how things should be done to the user. • DSDM defines nine principles that are critical to project success in the rapid development domain. • Underlying development concepts appear to be closely linked to familiar hard systems concepts of feasibility, concept of operations, functional modelling, design and implementation. 8

Dynamic Systems Development Method (DSDM) 1. 2. 3. 4. 5. 6. 7. 8. 9.

Dynamic Systems Development Method (DSDM) 1. 2. 3. 4. 5. 6. 7. 8. 9. Active user involvement is imperative. Teams must be empowered to make decisions. The four key variables of empowerment are: authority, resources, information and accountability. Frequent delivery of products is essential. Fitness for business purpose is the essential criterion for acceptance of deliverables. Iterative and incremental development is necessary to converge on an accurate business solution. All changes during development are reversible, i. e. you do not proceed further down a particular path if problems are encountered, you backtrack to the last safe or agreed point, and then start down a new path. Requirements are baselined at a high level, i. e. the high-level business requirements, once agreed, are frozen. This is essentially the scope of the project. Testing is integrated throughout the life cycle, i. e. ‘test as you go’ rather than testing just at the end where it frequently gets squeezed. A collaborative and co-operative approach between all stakeholders is essential. 9

DSDM three pizzas and a cheese diagram 10

DSDM three pizzas and a cheese diagram 10

DSDM development lifecycle – five phases 1. 2. 3. 4. 5. Feasibility study Business

DSDM development lifecycle – five phases 1. 2. 3. 4. 5. Feasibility study Business study Functional model iteration System design and build iteration Implementation 11

DSDM and users n the role of people in the process is emphasized n

DSDM and users n the role of people in the process is emphasized n n project manager; all skills but focus on speed user side: ambassador user (understanding and representing the needs of a user community); visionary user (having a vision of how the IS would benefit the organization) IT side: no special roles at least one representative from both sides should be present all the time 12

Timeboxes for DSDM project example 13

Timeboxes for DSDM project example 13

Extreme Programming (XP) n n n Particularly suitable for small and medium-sized applications (works

Extreme Programming (XP) n n n Particularly suitable for small and medium-sized applications (works best when the whole project requires 3 -10 programmers) It is a series of principles for developing software rapidly XP is a lightweight methodology: n n few rules and practices minor attention to documentation It stresses customer satisfaction: it is designed to deliver the software the customer needs when it is needed It empowers developers to respond to changing customer requirements, even late in the life cycle 14

Extreme Programming (XP) n n n User stories Architectural spike Paired programming 15

Extreme Programming (XP) n n n User stories Architectural spike Paired programming 15

Extreme Programming (XP) 1. 2. 3. 4. Planning Designing Developing Productionalising (testing) 16

Extreme Programming (XP) 1. 2. 3. 4. Planning Designing Developing Productionalising (testing) 16

XP: planning § Write user stories § Produce a release plan (plan for frequent

XP: planning § Write user stories § Produce a release plan (plan for frequent small releases) § Measure the project velocity § Divide the project into iterations and start each one with iteration planning § Have a stand-up meeting every day to communicate problems and solutions and promote team focus 17

XP: designing § Keep design simple; always do the simplest thing that could work

XP: designing § Keep design simple; always do the simplest thing that could work and never add functionality before it is scheduled § Choose a suitable system of names for your objects that everyone can relate to § Use Class, Responsibilities, and Collaboration (CRC) cards to design the system as a team. § Create architectural spikes: simple programs to explore the potential solution, i. e. programs that address only the problem under examination and ignore all other concerns § Turn a blind eye towards future requirements and extra flexibility. Concentrate on what is scheduled for today only § Re-factor obsolete designs that are hard to understand, maintain, 18 or have unused functionality

XP: coding § The Customer continues to be available through in coding and testing

XP: coding § The Customer continues to be available through in coding and testing (ask for experts not trainees) § Code must be written to agreed standards § Code the unit test first (before the actual code) § Paired programming: 2 people working at the same workstation § Sequential code integration: only one pair of programmers integrates code at a time § Integrate code often in a common repository § Collective code ownership is encouraged § Avoid optimizing code § Avoid working overtime or adding programmers 19

XP: testing § All code must have unit tests § All code must pass

XP: testing § All code must have unit tests § All code must pass all unit tests before it can be released § When a bug is found more tests are created § Acceptance tests (created from user stories in each iteration) are run and the score is published 20

Web IS Development Methodology (WISDM) n WISDM is a framework and methodology for the

Web IS Development Methodology (WISDM) n WISDM is a framework and methodology for the development of web-based information systems. The framework recognizes that a methodology in practice emerges from the triad of situation, human agents, and methods. 21

Web IS Development Methodology (WISDM) Reference: http: //www. wisdm. net/wisdm/index. htm 22

Web IS Development Methodology (WISDM) Reference: http: //www. wisdm. net/wisdm/index. htm 22

Indicative methods for WISDM include: Organizational Analysis: Soft Systems Methodology (SSM), e-business strategy Information

Indicative methods for WISDM include: Organizational Analysis: Soft Systems Methodology (SSM), e-business strategy Information Analysis: Unified Modeling Language (UML) Work Design: ETHICS, Participative Design, Web Quality (Web. Qual) Technical Design: UML plus physical design as indicated by the target implementation environment 23

Web. Qual question 24

Web. Qual question 24

Thank You for Your Attention 25

Thank You for Your Attention 25