Post on 25-May-2015
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