1. Training of master Trainers Workshop e-Services Design and Delivery
10 – 15 November 2012
e-Services Design and Delivery
Module VII
Emilio Bugli Innocenti

2. e-Services Design & Delivery
Contents of MODULE VII – “e-Services Design & Delivery”
Data Modeling: Entity Relationship Diagrams
System Modeling: Unified Modeling Language
Example/Case Study: The KIWI Project
10 slide design tips for producing powerful and effective presentations
13Comments
more +
By Guest Contributor
September 19, 2006, 7:00am PDT
This article is also available as a PDF download.
By Garr Reynolds
#1: Keep it simple
PowerPoint uses slides with a horizontal, or Landscape,orientation. The software was designed as a convenient way to display graphicalinformation that would support the speaker and supplement the presentation. Theslides themselves were never meant to be the star of the show. (The star, ofcourse, is your audience.) People came to hear you and be moved or informed (orboth) by you and your message. Don't let your message and your ability to tella story get derailed by slides that are unnecessarily complicated, busy, orfull of what Edward Tufte calls "chartjunk." Nothing in your slide should be superfluous, ever.
Your slides should have plenty of white space, or negativespace. Do not feel compelled to fill empty areas on your slide with your logoor other unnecessary graphics or text boxes that do not contribute to betterunderstanding. The less clutter you have on your slide, the more powerful yourvisual message will become.
#2 Limit bullet points and text
Your presentationis for the benefit of the audience. But boring an audience with bullet pointafter bullet point is of little benefit to them. Which brings us to the issueof text. The best slides may have no text at all. This may sound insane giventhe dependency of text slides today, but the best PowerPoint slides will bevirtually meaningless without the narration (that is you). Remember, the slidesare meant to support the narration of the speaker, not make the speakersuperfluous.
Many people oftensay something like this: "Sorry I missed your presentation. I hear it wasgreat. Can you just send me your PowerPoint slides?" But if they are goodslides, they will be of little use without you. Instead of a copy of yourPowerPoint slides, it is far better to prepare a written document thathighlights your content from the presentation and expands on that content.Audiences are much better served receiving a detailed, written handout as atakeaway from the presentation, rather than a mere copy of your PowerPointslides. If you have a detailed handout or publication for the audience to bepassed out after your talk, you need not feel compelled to fill yourPowerPoint slides with a great deal of text.
We'll talk moreabout this in the delivery section below, but as long as we are talking abouttext, please remember to never, ever turn your back on the audience and readtext from the slide word for word.
This slide is not unusual, but it is not a visual aid, it is more like an eye chart. 
Try to avoid text-heavy (and sleep inducing) slides like this one. 
Aim for something like this simple slide above. 
And this is even better.#3: Limit transitions and builds (animation)
Use object builds and slide transitions judiciously. Objectbuilds (also called animations), such as bullet points, should not be animatedon every slide. Some animation is a good thing, but stick to the most subtleand professional (similar to what you might see on the evening TV news broadcast).A simple Wipe Left-to-Right (from the Animations menu) is good fora bullet point, but a Move or Fly, for example, is too tedious and slow (andyet, is used in many presentations today). Listeners will get bored quickly ifthey are asked to endure slide after slide of animation. For transitionsbetween slides, use no more than two or three types of transition effects anddo not place transition effects between all slides.
#4: Use high quality graphics
Use high qualitygraphics, including photographs. You can take your own high quality photographswith your digital camera, purchase professional stock photography, or use theplethora of high quality images available online. (But be cautious of copyrightissues.) Never simply stretch a small, low-resolution photo to make it fit yourlayout--doing so will degrade the resolution even further.
Avoid usingPowerPoint Clip Art or other cartoonish line art.Again, if it is included in the software, your audience has seen it a milliontimes before. It may have been interesting in 1993, but today the inclusion ofsuch clip art often undermines the professionalism of the presenter. There areexceptions, of course, and not all PowerPoint art is dreadful, but use itcarefully and judiciously.
I often use imagesof people in my slides, as photography of people tends to help the audienceconnect with the slide on a more emotional level. If the photographic image issecondary in importance, then I decrease the opacity and add a Gaussian Blur ormotion filter in Photoshop. If the photographic image is the primary area Iwant the audience to notice (such as a picture of a product), then the imagecan be more pronounced and little (or no) text is needed.
Try to avoid cheesy clip art like this. 
This edited stock photograph is more effective and professional. 
In this title slide, the image is primary. 
In this slide from the same presentation, the image is secondary and pushedto the back by editing it first in Photoshop.#5: Have a visual theme but avoid using PowerPoint templates
You clearly need a consistent visual theme throughout yourpresentation, but most templates included in PowerPoint have been seen by youraudience countless times (and besides, the templates are not all that great tobegin with). Your audience expects a unique presentation with new (at least tothem) content; otherwise, why would they be attending your talk? No audiencewill be excited about a cookie-cutter presentation, and we must therefore shyaway from any supporting visuals, such as the ubiquitous PowerPoint DesignTemplate, that suggests your presentation is formulaic or prepackaged.
You can make your own background templates, which will bemore tailored to your needs. You can then save the PowerPoint file as a DesignTemplate (.pot) and the new template will appear among your standard Microsofttemplates for your future use. You can also purchase professional templates online.
#6: Use appropriate charts
Always be asking yourself, "How much detail do Ineed?" Presenters are usually guilty of including too much data in theironscreen charts. There are several ways to display your data in graphic form;here are a few things to keep in mind:
Pie charts. Usedto show percentages. Limit the slices to 4-6 and contrast the most importantslice either with color or by exploding the slice.
 Vertical bar charts.Used to show changes in quantity over time. Best if you limit the bars to 4-8.
 Horizontal bar charts.Used to compare quantities. For example, comparing sales figures among the fourregions of the company.
 Line charts. Usedto demonstrate trends. For example, here is a simple line chart showing thatour sales have gone up every year. The trend is good. The arrow comes in laterto underscore the point: Our future looks good!
 In general, tables are well suited for side-by-sidecomparisons of quantitative data.
 However, tables can lack impact on a visceral level. If youwant to show how your contributions are significantly higher than two otherparties, for example, it would be best to show that in the form of a bar chart(below). But if you're trying to downplaythe fact that your contributions are lower than others, a table will displaythat information in a less dramatic or emotional way.
 #7: Use color well
Color evokes feelings. Color is emotional. The right colorcan help persuade and motivate. Studies show that color usage can increaseinterest and improve learning comprehension and retention.
Youdo not need to be an expert in color theory, but it's good for businessprofessionals to know at least a bit on the subject. Colors can be divided intotwo general categories: cool (such as blue and green) and warm (such as orangeand red). Cool colors work best for backgrounds, as they appear to recede awayfrom us into the background. Warm colors generally work best for objects in theforeground (such as text) because they appear to be coming at us. It is nosurprise, then, that the most ubiquitous PowerPoint slide color scheme includesa blue background with yellow text. You do not need to feel compelled to usethis color scheme, although you may choose to use a variation of those colors.
If you will be presenting in a dark room(such as a large hall), a dark background (dark blue, gray, etc.) with white orlight text will work fine. But if you plan to keep most of the lights on (whichis highly advisable), a white background with black or dark text works muchbetter. In rooms with a good deal of ambient light, a screen image with a darkbackground and light text tends to washout, but dark text on a light backgroundwill maintain its visual intensity a bit better.
Learn more:
PresentationPro.com has some great Flash tutorials, including oneon color.
Dummies.com has a good short article on how to usethe Color Schemes in PowerPoint.

3. e- Service Design & Delivery: the Technical Perspective
DATA SET DESIGN: ENTITY-RELATIONSHIP DIAGRAM
Data modeling – a technique for organizing and documenting a system’s data. Sometimes called database modeling.
Entity relationship diagram (ERD) – a data model utilizing several notations to depict data in terms of the entities and relationships described by that data

4. e- Service Design & Delivery: the Technical Perspective
Data Modelling Concept: Entity
Entity – a class of persons, places, objects, events, or concepts about which we need to capture and store data.
Named by a singular noun
Places: sales region, building, room, branch office, campus.
Objects: book, machine, part, product, raw material, software license, software package, tool, vehicle model, vehicle.
Events: application, award, cancellation, class, flight, invoice, order, registration, renewal, requisition, reservation, sale, trip.
Persons: agency, contractor, customer, department, division, employee, instructor, student, supplier.
Concepts: account, block of time, bond, course, fund, qualification, stock.

5. e- Service Design & Delivery: the Technical Perspective
Data Modelling Concept: Attribute
Attribute – a descriptive property or characteristic of an entity. Synonyms include element, property, and field.
Just as a physical student can have attributes, such as hair color, height, etc., data entity has data attributes
Compound attribute – an attribute that consists of other attributes. Synonyms in different data modeling languages are numerous: concatenated attribute, composite attribute, and data structure.

6. e- Service Design & Delivery: the Technical Perspective
Data Modelling Concept: Identification
Key – an attribute, or a group of attributes, that assumes a unique value for each entity instance. It is sometimes called an identifier.
Concatenated key - group of attributes that uniquely identifies an instance. Synonyms: composite key, compound key.
Candidate key – one of a number of keys that may serve as the primary key. Synonym: candidate identifier.
Primary key – a candidate key used to uniquely identify a single entity instance.
Alternate key – a candidate key not selected to become the primary key. Synonym: secondary key.

7. e- Service Design & Delivery: the Technical Perspective
Data Modelling Concept: Relationship
Relationship – a natural business association that exists between one or more entities.
The relationship may represent an event that links the entities or merely a logical affinity that exists between the entities.

8. e- Service Design & Delivery: the Technical Perspective
Data Modelling Concept: Cardinality
Cardinality – the minimum and maximum number of occurrences of one entity that may be related to a single occurrence of the other entity.
Because all relationships are bidirectional, cardinality must be defined in both directions for every relationship.

9. e- Service Design & Delivery: the Technical Perspective
Data Modelling Concept: Degree
Degree – the number of entities that participate in the relationship.
A relationship between two entities is called a binary relationship.
A relationship between three entities is called a 3-ary or ternary relationship.
A relationship between different instances of the same entity is called a recursive relationship.

10. e- Service Design & Delivery: the Technical Perspective
Logical System Models
Logical models remove biases that are the result of the way the system is currently implemented, or the way that any one person thinks the system might be implemented.
Logical models reduce the risk of missing business requirements because we are too preoccupied with technical results.
Logical models allow us to communicate with end-users in nontechnical or less technical languages.

11. e- Service Design & Delivery: the Technical Perspective
Difference between DFDs and Flowcharts
Processes on DFDs can operate in parallel (at-the-same-time)
Processes on flowcharts execute one at a time
DFDs show the flow of data through a system
Flowcharts show the flow of control (sequence and transfer of control)
Processes on a DFD can have dramatically different timing (daily, weekly, on demand)
Processes on flowcharts are part of a single program with consistent timing

12. e- Service Design & Delivery: the Technical Perspective
System Design: UML - Unified Modeling Language
It is a modeling language, not a process
In 1996, work on the UML was begun by Rational
UML is a robust notation that can express information gathered throughout a project’s lifecycle.
Adopting standard use of UML can improve communication between clients and developers.
UML can be used as an effective data modeling tool as well as an object modeling tool.

13. UML UML Diagrams Class Diagrams Use Case Diagrams
Collaboration Diagrams
Sequence Diagrams
Package Diagrams
Component Diagrams
Deployment Diagrams
Activity Diagrams
State Diagrams

14. UML Class Diagrams Are the most fundamental UML Diagram.
Describe the classes in the system, and the static relationships between classes.
Class diagrams are used during Analysis, Design and Development

15. UML Class Diagrams 1 1..* 1 0..1 1 Customer Customer Rental Invoice
Rental Item
1..* 1
0..1 1
Checkout Screen
Checkout Screen
Video Game
DVD Movie
VHS Movie
Video Game

16. UML Class Diagrams 1..* 1 0..1 DVD Movie VHS Movie Video Game
Rental Item
{abstract}
Rental Invoice
1..* 1
Customer
Checkout Screen
0..1
Simple
Association
Class
Abstract
Aggregation
Generalization
Composition
(Dependency)
Multiplicity

17. -- can optionally be described here.
UML
Parts of a Class
MyClassName
+SomePublicAttribute : SomeType
-SomePrivateAttribute : SomeType
#SomeProtectedAttribute : SomeType
+ClassMethodOne()
+ClassMethodTwo()
Responsibilities
-- can optionally be described here.
Classes can have four parts
Name
Attributes
Operations
Responsibilities
Classes can show visibility and types.
All parts but the Name are optional.

18. UML Object Diagrams An Object is an instance of a class.
Object names are underlined.
Object diagrams are similar to class diagrams. Many of the same notations are used.
Object diagrams capture instances of classes, and allow the dynamic relationships to be shown.
ThisOne : MyClassName
+SomePublicAttribute : SomeType
-SomePrivateAttribute : SomeType
#SomeProtectedAttribute : SomeType
+ClassMethodOne()
+ClassMethodTwo()

19. Class and Object Diagram
UML
Class and Object Diagram
Class Name
Association Name
Customer
Rental Item
+id:integer
Rents
+name:string
Class Diagram
Attributes
Object Name
Joe: Customer
Casablanca: Movie
+id:1667
+id:22340
+name:Joe Smith
+released:1942
Object Diagram

20. UML
Use Cases
Describe interactions between users and computer systems (both called actors) .
Capture user-visible functions.
Achieve discrete measurable goals.
Are typically used during Analysis and Design.

21. UML Use Cases Telephone Customer In-Store Clerk Identify Movie
Open Account
Return Movie
Review
Account Status
Actor
Use Case

22. UML
Use Case Report
The Use Case Report provides documentation for the Use Case.
A Use Case is not complete without the report.
The elements of the Use Case Report are shown on the right.
Brief description
Precondition
Flow of events
Main flow
Subflows
Alternate flows
Postcondition
Special Requirements
Enclosures
Diagrams
Pictures of the UI

23. UML Collaboration Diagrams
Collaboration diagrams describe interactions and links
Focus on exchange of messages between objects
Appears during Analysis phase
Enhanced during Design phase

24. UML Collaboration Diagrams – Rent a movie Object Message :Rented Items
:Check-out Manager
:Customer
:Inventory
1: enter_customer()
3: enter_movies()
5: add(customer, movies)
7: print invoice()
2: IsValidCust(CustId)
4:GetMovieByBarcode()
:Clerk
Object
Message
:Rented Items
8: generateRentalTotal()

25. UML Sequence Diagrams Can be “morphed” from Collaboration Diagrams.
Describe interactions between objects arranged in time sequence
Focus on objects and classes involved in the scenario and the sequence of messages exchanged
Associated with use cases
Used heavily during Analysis phase and are enhanced and refined during Design phase

26. UML Sequence Diagrams – Rent a Movie Object Activation Message
1: find customer()
2: search (string)
4: search (string)
6: add(Cust, item)
3: enter movie()
5: rent (movie)
7: printInvoice()
8: generateRentalTotal()
Object
Lifeline
Activation
Message
:CheckoutMgr
:Inventory
Cust:Customer
:RentedItems
:Employee

27. UML
Package Diagrams
Class
Package

28. UML
Component Diagram
Component
Interface
Dependency
Note

29. UML
Deployment Diagram
Node
Communication
Association

30. UML Activity Diagram Identify Caller Obtain Name & Address Create
Start State
Identify
Caller
Action State
Decision
Obtain Name
& Address
Open
Account?
Current
Customer?
[no]
[no]
[yes]
End State
[yes]
Create
Account

31. UML Customer Manager Walking Clerk Swimlanes and Fork/Join Points
Identify
Movie
Fork Point
Swimlanes and
Fork/Join Points
Place
Order
Place
Order
Fill
Order
Pay
Collect
Money
Pickup
Movie
Deliver
Movie
Join Point

32. UML
Guard
State Diagram
Event
Transition
Action
Activity
State

33. UML
UML Diagrams Usage

34. UML CASE STUDY – The KIWI Project - Use Cases for Milan Prefecture
Main Actors

35. UML CASE STUDY – The KIWI Project - Use Cases for Milan Prefecture
External Actors

36. UML CASE STUDY – The KIWI Project - Use Cases for Milan Prefecture
Workflow on the fly

37. UML
CASE STUDY – The KIWI Project – Activity Diagram
Back End Process

38. UML CASE STUDY – The KIWI Project – Sequence Diagram
Workflow on the fly