1. University of Brescia
Dipartimento di Ingegneria dell'Informazione
Knowledge Engineering and Human-Computer Interaction Research Group
A WIS Project:
4 Advices for the CIO
Federico Cerutti
© 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

2. The context
Company Supplier
Do we need a WIS? Give me a WIS
Management CIO
Wants to
See and
SW
Control
building
Process
Delivered
WIS
Slide 2 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

3. The CIO main feature
Capacity Management
 The Process responsible for ensuring that the
Capacity of IT Services and the IT Infrastructure is
able to deliver agreed Service Level Targets in a
Cost Effective and timely manner. Capacity
Management considers all Resources required to
deliver the IT Service, and plans for short, medium
and long term Business Requirements
 Purpose: ensure that there is adequate capacity in all
areas of IT to match the current and future needs that
the IT department agreed upon with the business
Slide 3 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

4. Input and Output of Capacity
Management
Slide 4 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

5. The forecast model:
The project with a supplier
Project
Software
WEB
Slide 5 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

6. Model the suppliers: the CIO
point of view
Company Supplier
Vision
CIO / Project Manager
Project Costumer
Consultants
Project
Interfaces Functional project Functional project
Leader Leader
Task leader Task leader
Slide 6 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

7. Project Life Cycle Process
Broad generic project phases
 Concept
 Initiation, identification, selection
 Definition
 Feasibility, development, demonstration, design prototype,
quantification
 Execution
 Implementation, realization, production and deployment,
design/construct/commission, installation and test
 Closeout
 Termination and post-completion evaluation
Slide 7 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

8. First advice:
Know which are the interfaces
 Organization relations among project participants
 Interactions among project phases
 Benefits:
 Identification of role and responsibility (conflicts management)
 Definition of the Input and Output of project phases
 Better programming and scheduling
 Efficency
 Two kinds of interfaces:
 Product interfaces
 Project interfaces
Slide 8 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

9. Costumer Interfaces
for each project phase
 Documents related to the product or results
 Specifications, drawings, descriptions, test procedures,
flow charts, cost estimates …
 Physical product or results
 Intermediate or final mockups, scale or full size models,
prototypes, tools …
 Defining the Decision Points
 Control
 Documenting Project Life-Cycle Management
Process
Slide 9 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

10. The forecast model:
The software project
Project
Software
WEB
Slide 10 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

11. We do not want a project: we
want a software project
 “The organizational characteristics, the degree of
familiarity with the technology to be used, and the
competitive demands for initiating the project are
just some of the environmental factors that can vary
from project to project”
 Our product is a software
 Two kinds of life-cycle models:
 Predictive
 Adaptive
Slide 11 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

12. How to choose (from
requirements features)
Wfall Prot RAD IncrB Spiral ASD XP SCRUM
Fixed requirements X
Functional requirements
X X X X X
variable
Several components with
X X X X X
variable requirements
Lot of HCI requirements X X X
High risk requirements X X
Requirements of High Level
X X X
Documentation
Is it so easy?
Slide 12 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

13. The forecast model:
The Web Application Project
Project
Software
WEB
Slide 13 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

14. Multi-domain implies
collaborative multi-skills
UI designers
Analysts
Domain experts
Use Scenario
cases diagrams
Classes
Requirements WIS collaborations
Stakeholders Designers
Model
Deployment State
diagrams diagrams
Components
Management
Implementers
Integrators Architect
Slide 14 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

15. Second advice:
People management
 Web Projects are People Projects
 Real-world cases analysis suggests:
 Having a say in the resource selection process helps to
ensure project success
 The partner project manager can make or break the project
 Visibility into the progress of all team members can help
prevent disaster (interface sharing)
 Clear process for screening the individuals who will
work on the project and introducing them to the business
 Help in controlling the project
Slide 15 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

16. Third advice:
A Web app is more than a SW app
 Web apps does not require software engineering
capabilities only (multi-skills)
 The traditional Project Life-Cycle are not proficient
 They do not address explicitly several issues
 Focus on the software production
 Several approaches provided:
 Batini, Pernici, Santucci (BPS)
 Conallen
 Polillo
Slide 16 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

17. BPS: the process
Requirements
Planning
Gathering/Analysis
Detailed Analysis
Design
Implementation Deployment
Slide 17 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

18. BPS: Quality driven design
 Navigability
 Accessibility
 Usability
 Readability
 Reliability
 Manageability
 Compatibility, interoperability
 Security
 Efficiency
Slide 18 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

19. BPS: Pros/Cons
 Pros:
 Focus on classic software methodology
 Focus on the quality of the WIS
 Cons:
 Focus on classic software methodology (Third advice: a
Web app is more than a SW app)
 It does not specify the multi-skills required in WIS
 It does not consider test and evaluation
 It does not provide any specific interface
Slide 19 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

20. Conallen's Iterative Workflow
Project Management
Requirements Gathering
Analysis
Design
Implementation
Test
Deployment
Evaluation and Change Management
Slide 20 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

21. Conallen (1)
 Project Management
 Business case
 Project and iteration plans
 Iteration evaluation and Quality Assurance
 Requirements Gathering
 Unambiguously express what the proposed system should do
 Risks Management
 Analysis
 Examining the requirements
 Making a conceptual model of the system to be built
 Design
 To make the analysis model of the system realizable in software
Slide 21 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

22. Conallen (2)
 Implementation
 Test
 Unit, Integration, System, Acceptance, Regression tests
 Deployment
 Deployment planning
 Address failover issues, load balancing...
 Integration with third-party and off-the-shelf components
 Careful planning of network resources
 Evaluation / Change Management
 Management of the changes: introduced and monitored in a controlled way
 Each change is a small adjustment
 To assess the quality of any section of the project
Slide 22 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

23. Conallen: Pros/Cons
 Pros:
 Address the risk early
 Use cases drive the process
 Sets of use cases that contain the most risk can be
targeted for early development
 Test plans to evaluate each iteration delivery
 Rigid project life cycle with clear project/product
interfaces mainly with prototypes
 Cons:
 Rigid methodology (hard for the CIO point of view)
Slide 23 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

24. Polillo: Project Phases
Management
Management
Visual design
Management
Requirements
Development
Web design
Contents
Internet
Server
Web
Analysts Architect Designers Domain
UI
designers Experts
Implementers
Slide 24 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

25. Polillo: Project Phases Iteration
Design
Prototyping Test Deployment
Slide 25 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

26. Requirement
Gathering
Slide 26
Requirement
Document
Project Starts
Quality Plan
Web Design
Navigation Prototype
Visual Design
Communication
Prototype
Polillo: the Road Map
Development
Working Prototype
© 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>
Contents
Content Prototype
Deployment
Online System

27. Polillo: Pros/Cons
 Pros:
 It is a roadmap, can easily used as an external (CIO point
of view) model of the process
 It addresses the prototyping problem which can easily
manage the inter-domain communication
 It is quality driven
 It evidences each phase's project/product interfaces
 Cons:
 Too easy?
Slide 27 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

28. Fourth advice: Effective Web
Prototypes Have Clear Benefits
 Prototypes help organizations communicate
 Facilitate internal discussions
 Explain products
 Prototypes are key to user-centered design
 Validate product concepts
 Iterate on designs and decide between alternatives
 Find usability problems
 Done right, prototypes save time and money
 Quickly, sometimes in a matter of minutes
 Cheaply, before you pay the developers
Slide 28 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

29. Prototypes Beware: improper use
creates problems
 Use one type of prototype to serve all purpose
 Expose some aspects of the prototype at the wrong
time
 Don't set accurate expectations
 Spend too long making things perfect
 Project teams don't understand prototype fidelity
 A prototype can have both high and low fidelity
 Prototyping tools don't dictate fidelity
Slide 29 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

30. Summary
 First advice
 Project Management by Interfaces
 Second advice
 WIS Projects are People Projects
 Third advice
 Web App is more than a SW App
 Fourth advice
 Prototypes (if used rightly) have clear benefits
Slide 30 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>

31. References
[1] R. D. Archibald, Project Management
[2] P. Schgör, R. Brambilla, F. Amarilli, Professione Informatica vol I, Pianificazione, uso e
gestione dei sistemi informativi
[3] C. Batini, B. Pernici, G. Santucci, Sistemi Informativi vol VI, Sistemi Informativi basati
sul Web
[4] R. Polillo, Plasmare il Web, Road map per siti di qualità
[5] J. Conhallen, Building Web Applications with UML
[6] T. Sheedy, People Management Is Fundamental To The Success Of Large Systems
Integration Projects (Forrester, 12/06/2008)
[7] K. Bodine, A Web Prototyping Primer (Forrester Best Practice 02/06/2006)
[8] E. Hubbert, Role Overview: Capacity Manager (Forrester, 01/12/2008)
[9] M. Minevich, The CTO Handbook: Chief Technology Officer/Chief Information Officer
Manual
[10] J. Hallows, Information Systems Project Management: How to Deliver Function and
Value in Information Technology Projects
Slide 31 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>