Methodologies for creating ubiquitous computing prototypes ch6

1
Methodologies for creating ubiquitous computing
prototypes (ch6)

• Johan Sanneblad
• 2004-02-19

2
This is an important issue

• Software design methodologies are important, even
  in ubiquitous computing research
• We have numerous strategies for designing and
  evaluating prototypes and services
• But how do we create the software for these
  prototypes?
• Not uncommon Present the design sketch to
  students and let them create it any way they feel
  suitable. Or use an existing student project and
  evaluate it, do not consider the implementation
  aspects. Prototypes are limited to ten weeks.
• We need to consider the implementation aspects in
  our projects.

3
International Projects

• Ubiquitous Computing
• Tangible Computing
• Experience Prototyping
• Large projects such as Smart-Its need
  methodologies to take design implications and
  create computer software
• How do we adapt to
• Changes in design during the development process?
• Changes in hardware requirements
• Changes in current research topics

4
Introduction

• The standard engineering design process produces
  a fundamental blindness to the domains of action
  in which the customers of software systems live
  and work. (Winograd et al, 1996)

5
Important issue

• Volvo, autumn 1998
• New system purchased from consultant firm Cap
  Gemini - Volvo Sales Information Base VSIB
• The system should interconnect all sales
  databases and aggregate data
• A business process map and user-centered design
  was made
• But no-one figured how to use the above maps and
  designs to create the software!
• Solution use designs as guidelines and use
  know-how to design the system

6
The authors

• Propose a broader interpretation of design
• Based on observing the repetitive actions of
  people in a domain and connecting those
  action-processes to supportive software
  technologies.
• Action-centered design
• Should be the basis of a discipline of software
  architecture

7
New discipline (1996)

• Software architecture
• Action-centered design
• Mix of software engineering (1960s) and
  human-centered design (1980s)
• Software engineering
• Software-lifecycle model (e.g. the waterfall
  model and the spiral model)
• Software engineers have not achieved success in
  the engineering design process

8
The engineering process

• Three assumptions
• The result of the design is a product (artifact,
  machine, or system)
• The product is derived from specifications given
  by the customer
• There is little need for contact between customer
  and designer until delivery

9
Human-centered design

• Three assumptions
• The result of a good design is a satisfied
  customer
• The process of design is a collaboration between
  designers and customers
• The customer and designer are in constant
  communication during the entire process

10
New approaches

• Object-oriented design
• Object-oriented programming
• Might appeal to some intuitive sense about how
  the software will be used, and thereby reduces
  the apparent complexity of the software
• Still no silver bullet (Brooks)

11
Successful software packages

• Pick a domain in which many people are involved
• Study the nature of the actions that people take
  in that domain, especially of repetitive actions
• Define software routines that imitate familiar
  patterns of action
• Deploy prototypes early in selected customer
  domains
• All designers asked did not pay much attention to
  standard software-engineering methodology

12
Pattern Mapping

• The key to transforming software design and
  engineering into a customer-centered discipline
  is the development of a method of mapping from
  human actions to software functions in a way that
  is intelligble to clients, designers, and
  engineers simultaneously.
• There is generally no accepted method of mapping
  that is analogous to the blueprint - no agreement
  on the basic patterns of human action that will
  be composed in a software system.

13
Business-process maps

• The notation of business-process maps appears to
  be well suited as a starting point for maps of
  repetitive coordination processes
• This notation needs to be extended to show how a
  process network is triggered by people acting in
  their coordination processes.

14
Business-process maps

• Three components
• Material processes
• Information processes
• Business processes
• Workflow maps

15
Designingnon-business systems
16
Business-process mapping

• Strong focus on repetitive tasks
• Simplifying current tasks
• Tasks can be quantified
• How do we support the creation of
• Creating new tasks?
• Finding new domains?
• Many research projects takes much time before the
  first prototype is finished
• We need suitable methodologies to implement our
  software projects
• Sonic City, Picture This, Total Recal,

17
Extreme programming
18
Extreme Programming

• Agile Methodology
• Iterative work model
• High-quality software
• Quick adaptations to changing requirements
• 12 practices
• Planning Game, On-site Customer, Pair
  Programming, Collective Code Ownership,
  Continuous Integration, Small Releases, Metaphor,
  Simple Design, Coding Standard, Testing,
  Refactoring, and Forty-hour Week

19
A typical XP project

• Team
• 6-8 developers
• Coach
• Customer on-site
• Project iterations
• 2-3 weeks between which planning meetings are
  held
• Who is in charge for the business process mapping?

20
XP in practice

• Coach
• Can recommend developers to pair to spread
  competence and work efficiently
• Any of the team pairs with as many of the others
  in the team as possible
• Resolves conflicts on code design
• Planning game
• Estimating tasks
• Always estimate, despite previous lack of
  experience

21
XP in practice

• Test first
• By writing test units before the code is written
• Small Releases
• The customer should evaluate and comment every
  release
• Developers constantly sees the software from the
  customers point of view
• On-site customer
• Regular visits to the project group

22
XP in practice

• First iteration
• Begin by creating an executable skeleton of the
  system, forming an initial thin but complete
  system
• Make sure that the necessary infrastructure can
  be built and that subsequent development can
  proceed in small chunks
• Get early feedback on the system architecture
• Also called zero feature iteration
• Requires experienced programmers
• Can be performed by the coach

23
XP in practice

• On-Site Coach
• Knows the practices, can explain them and
  motivate why they are important, and can also
  help the team to actually enforce the practices.
• Is responsible for team building
• Team-in-one-room
• All project members usually share an open
  workspace where program development takes place
• Everyone is always aware of what is happening
• Help is always near at hand
• Simplifies for coach to spot problems
• Promotes team building

24
XP in practice

• Spike Time
• Developers need time to do individual work, e.g.
  to read and learn about various practical issues,
  to think about how to solve a particular task, or
  to do experimental programming with new
  solutions.
• Team allocates spike time at planning meetings,
  forming a pool, from which resources are
  withdrawn.
• Results from spike time should be shared with
  others

25
XP in practice

• Reflection
• At regular intervals, the team reflects on how to
  become more effective, then tunes and adjusts its
  behaviour accordingly
• Stand-up meetings, planning meetings
• Documentation
• The code is the most important (and always
  up-to-date) documentation

26
Discussion

• Given the mentioned methods
• Waterfall model
• Spiral model
• Business-process mapping
• Extreme Programming
• What methodologies to we apply and use in our
  work as researchers in ubiquitous computing?
• Prototypes
• Platforms
• Novel features