1dsbw 2011/2012 q1

Process Models for Web Application Development

RUP

Agile methods

Business Models for Electronic Commerce

Unit 3

2dsbw 2011/2012 q1

A web/software development process model has four roles:

Provide guidance about the order of a team's activities.

Specify artifacts that should be developed.

Direct the tasks of individual developers and the team as a whole.

Offer criteria for monitoring and measuring the project's products and activities.

The process model should define the workflows, activities, artifacts, and roles in the development process

A workflow is set of activities—requirements, analysis, design, implementation, testing, and deployment—that ultimately produce tangible and observable results: artifacts

An artifact is any persistent piece of information that is produced during the process: models, source code, documents, etc.

Artifacts often undergo significant change during the process, resulting in series of versions that should be controlled and traceable.

Process Models

3dsbw 2011/2012 q1

Goal: to support the development of a high-quality product within a fixed period of time and at a fixed price.

Key aspects:

The Rational Unified Process (RUP)‏

Use case driven

Architecture-centric

Iterative and incremental

4dsbw 2011/2012 q1

RUP: Overview

Analyze

business and

perceived

problems

Analyze

the

understood

problem

Deploy

system

Maintain

system

Develop

domain

model

Develop

project

plan

IterateDevelop

vision

document

[Pa

ss

ac

ce

pta

nce c

rite

ra]

Manage artifact versions

<<defines>>

5dsbw 2011/2012 q1

RUP: Iterate

Incept ion Elaborat ion Const ruct ion Transit ion Product ion

UP Phases

Workflows

Requirements

Analy sis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support

6dsbw 2011/2012 q1

RUP Models: Dependencies and traceabilities

ProjectManagement

Model

RequirementsEngineering

Model

AnalysisModel

DomainModel

DesignModel

TestModel

ImplementationModel

DeploymentModel

7dsbw 2011/2012 q1

Vision Document (revised)‏

Functional requirements

Non-functional requirements:

Business requirements: standards, legislations, regulations

Architectural requirements: acceptable response times, acceptable Web browser versions, etc.

User experience (UX) document:

Defines the targeted look-and-feel for the application, the emotion that the application is trying to establish with the user

The user experience (UX) team is responsible for both developing and implementing this document .

Artifacts in the Requirements Engineering Model

New!

8dsbw 2011/2012 q1

Use Case Model

Use Case diagrams

Conceptual Model

Domain class diagrams

Textual integrity constraints

System Behavior Model

System’s sequence diagrams

System’s operation contracts

State Model

State diagrams

Artifacts in the Analysis Model

9dsbw 2011/2012 q1

Physical Architecture

Description of architectural tiers, processes, protocols, etc.

Logical Architecture:

Web Presentation Layer:

External Design (UX Model)‏

Internal Design

Class Diagrams using the Web Application Extension for UML

Sequence Diagrams

Domain Layer

Data Access Layer

Database Design

Artifacts in the Design Model

10dsbw 2011/2012 q1

The development team:

Large vs. small teams

Heterogeneous vs homogeneous teams

Skill level

The nature of the application

Human-critical applications: medical devices, spacecraft systems, thermonuclear controls, etc.

Web applications: they are not human-critical. Still, other factors should be considered:

Evolving technologies

Greater emphasis on nonfunctional requirements: security, availability, accessibility, etc.

Priorities:

Fast vs. complete

Fast vs. correct

The Process Model should be tailored considering …

11dsbw 2011/2012 q1

Most process models are too “heavy”

Too many things are done with no direct relation with programming software.

Traditional process models are too rigid

The do not fit well when requirements are incomplete and unstable.

They are not appropriate when frequent releases and short development iterations are required.

Customers should participate more actively

Lesser focus on the process and more on people

Alternative: Agile methods

Another way of building software is possible …

12dsbw 2011/2012 q1

Examples:

Agile Modeling

Agile Unified Process (AUP)

Agile Data Method

DSDM

Essential Unified Process (EssUP)

Extreme Programming (XP)

Feature Driven Development (FDD)

Open Unified Process (OpenUP)

Scrum

Lean software development

All of them are adhered to the Agile Alliance (www.agilealliance.org) and its Manifesto

Agile Methods

13dsbw 2011/2012 q1

We are uncovering better ways of developingsoftware by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working Software over comprehensive documentation

Customer Collaboration over contract negotiation

Responding to Change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Manifesto for Agile Software Development

14dsbw 2011/2012 q1

1) Customer satisfaction through early and continuous delivery of valuable software

2) Welcome changing requirements, even late in development

3) Deliver working software frequently (2 weeks – 2 months)‏

4) Business people and developers must work together daily

5) Build projects around motivated individuals

6) Face-to-face conversation

7) Working software is the primary measure of progress

8) Agile processes promote sustainable development

9) Continuous attention to technical excellence and good design

10) Simplicity

11) Self-organizing teams.

12) Regular adaptation to changing circumstances

The Twelve Principles of Agile Development

15dsbw 2011/2012 q1

The four variables to be controlled

Cost, Time, Quality, and Scope

The five values to be promoted:

Communication, Simplicity, Feedback, Courage and Respect

The five principles that should guide us:

Rapid feedback, Assuming simplicity, Incremental changes, Embracing change, Quality work

The twelve practices:

Planning game, small releases, simple designs, automated testing, continuous integration, refactoring, pair programming, collective ownership, 40-hour week, on-site customer, coding standard, metaphor

eXtreme Programming (XP)‏

16dsbw 2011/2012 q1

The XP Process

PublicationIterationReleasePlanning

[otherwise]

[changed/new requirement]

[all acceptance tests successful]

[next iteration]

[project end]

17dsbw 2011/2012 q1

XP Iteration

18dsbw 2011/2012 q1

Scrum

SCRUM

PROCESS

Sprint: 2 – 4 weeks

19dsbw 2011/2012 q1

Pigs

Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.

Scrum Master: The person responsible for the Scrum process, making sure it is used correctly and maximizes its benefits.

Scrum Team: A cross-functional group of people (5 – 9) responsible for managing itself to develop the product.

Chickens

Stakeholders (customers, vendors): They are only directly involved in the process during the sprint reviews.

Managers: People who will set up the environment for the product development organizations.

Scrum Roles

20dsbw 2011/2012 q1

Product Backlog

A list of product requirements – functional and non-functional -prioritized by organizational value

Each Product Backlog will decompose into several Sprint Backlogs

Sprint Backlog

A prioritized list of tasks to be completed during the sprint.

Tasks should last between 4 and 16 hours of work

Sprint Burnout chart

publicly displayed chart showing remaining work inthe sprint backlog

Updated every day

Scrum Artifacts

21dsbw 2011/2012 q1

Spring Planning Meeting

At the beginning of the sprint cycle, the Team selects items from the product backlog they can commit to completing

Sprint backlog is generated

Daily Scrum

15 minutes, stand up, at the same location and same time

All are welcome, but only pigs speak to answer the three questions:

What have you done since yesterday?

What are you planning to do today?

Is anything in your way?

Helps avoid other unnecessary meetings

Scrum Ceremonies

22dsbw 2011/2012 q1

At the end of a sprint cycle, two meetings are held: The Sprint Review Meeting and The Sprint Retrospective

Sprint Review Meeting (The Demo)

Team presents to management, customers, users and the Product Owner the product increment that has been built during the Sprint

All product backlog items selected for Sprint are included in the demo

Afterward, product backlog might be re-arranged, or decision made to release early (or fail fast)

Sprint Retrospective:

Team, Scrum Master, and (optionally) Product Owner reflect on the past sprint:

What went well?

What can be improved?

Scrum Ceremonies (cont.)

23dsbw 2011/2012 q1

Agile vs. Heavyweight: A comparison

ComprehensiveMinimalUpfront Planning

PredictableUnpredictable/ExploratoryDomain

Process-OrientedPeople-OrientedEmphasis

Command-ControlLeadership-CollaborationCulture

AutocraticDecentralizedManagement Style

Conformation to planBusiness ValueSuccess

Measurement

PredictiveAdaptiveApproach

End of the projectEarly in the projectReturn on Investment

LargeSmall/CreativeTeam Size

LimitedNumerousCycles

HeavyLowDocumentation

Change SustainabilityChange AdaptabilityPerspective to Change

LargeSmallProject Size

Heavyweight MethodsAgile Methods

24dsbw 2011/2012 q1

Agile vs. Heavyweight: When they should be used

ExpensiveInexpensiveRefactoring/Cost of

Change

Knowledgeable, representative,

collaborative

Collaborative, dedicated,

co-located, knowledgeable

Customers

Process-oriented, Adequately

Skillful

Agile, co-located,

collaborative

Developers

Design for current and future

needs

Design for current needsArchitecture

Well understood risks

Minor Impact

Unknown risks

Major Impact New

Technology

Risks

Clear & Defined MilestonesUnclear & Not well Defined

Milestones

Time

Sufficient BudgetUncertain budget

Money tight

Resources (money,

infrastructure)‏

Well Known

Largely Stable

Subject to change

Largely emergent

Unknown, Uncertain

Scope (requirements)‏

High AssuranceRapid ValueObjective

Heavyweight MethodsAgile Methods

25dsbw 2011/2012 q1

From Agile to Heavyweight

26dsbw 2011/2012 q1

Information strategy planning (ISP)‏

strategic goals defined

success factors/business rules identified

business model created

The Business Process Engineering Hierarchy

Business area analysis (BAA)‏

processes/services modeled

interrelationships of processes and data

(Web) Application Engineering

modeling applications/procedures that address (BAA) and constraints of ISP

27dsbw 2011/2012 q1

Business Model

A set of planned activities (sometimes referred to as business processes) designed to result in a profit in a marketplace.

E-commerce Business Model

A business model focused to use the characteristics and opportunities of Internet and the Web in a strategic way

Business Models

28dsbw 2011/2012 q1

Business-to-Consumer (B2C)‏

Business-to-Business (B2B)‏

Consumer-to-Consumer (C2C)‏

Peer-to-Peer (P2P)‏

Mobile commerce (M-commerce)‏

E-commerce Business Model Categories

29dsbw 2011/2012 q1

Portal

Offers an integrated package of services and content such as search, news, e-mail, chat, downloads, etc.

Variants:

Horizontal/General: Yahoo.com, MSN.com

Vertical/Specialized (Vortal): Universia.es

Revenue model: Advertising, subscription fees, transaction fees.

E-tailer (Electronic retailer)‏ Online version of retail store.

Variants:

Virtual merchant: Amazon.com

Click-and-mortar: capraboacasa.com

Online mall: fashionmall.com

Manufacturer-direct: dell.com

Revenue model: Sales of goods, transaction fees.

B2C Models (1/3)‏

30dsbw 2011/2012 q1

Content Provider

Information and entertainment providers such as newspapers, sports sites, etc.

Revenue model: Advertising, subscription fees, affiliate referral fees.

Transaction broker

Processors of online sales transactions, such as stockbrokers and travel agents.

Revenue model: transaction fees

Market creator

Creators of virtual markets that bring buyers and sellers together.

Variant: online auctions (eBay.com)‏

Revenue model: transaction fees

B2C Models (2/3)‏

31dsbw 2011/2012 q1

Service provider:

Companies that make money by selling a service, rather than a product.

Revenue model: sales of services.

Community Provider

Sites where individuals with particular interests, hobbies and common experiences can come together and compare notes.

Revenue model: Advertising, subscription, affiliate referral fees.

B2C Models (3/3)‏

32dsbw 2011/2012 q1

B2B Hub: Brings buyers and sellers together to reduce procurement costs.

E-Distributor: Connecting businesses directly with other businesses, reducing sales cycles and mark-up.

B2B Service Provider

Traditional: Supports companies through online business services.

Application Service Provider (ASP): Rents Internet-based software applications to businesses.

Matchmaker: Helps businesses find what they want and need on the Web

Infomediary

Audience Broker: Gathers information about consumers and uses it to help advertisers find the most appropriate audience

Lead Generator: Gathers customer data, and uses it to direct vendors to customers.

B2B Models

33dsbw 2011/2012 q1

Consumer-to-Consumer (C2C)‏

Electronically-facilitated transactions between consumers through some third party

Existent model: Market Creator (B2C)‏

Peer-to-Peer (P2P)‏

Use of P2P networks for business: besides File Sharing, companies are also interested in Distributing Computing, Content Distribution, e-market place, Distributed Search engines, Groupware and Office Automation via P2P network.

M-commerce

A new distribution channel: mobile devices

Emergent Business Models

34dsbw 2011/2012 q1

CONALLEN, J. Building Web Applications with UML Second Edition. Addison-Wesley 2002.

KAPPEL, Gerti et al: Web Engineering. Wiley, 2006. Chapter 10

KHAN, Ali. A Tale of two Methodologies: Heavyweight versus Agile. Minor Research Project in IS 615-690, University of Melbourne, 2004.

R. G. Pressman, D. Lowe: Web Engineering. A Practitioner’s Approach. McGraw Hill, 2008. Chapters 2-3.

Agile Software Process Models: http://www.rspa.com/spi/process-agile.html

References