Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cerutti--Web Information Systems (postgrad seminar @ University of Brescia)

904 views

Published on

  • Be the first to comment

  • Be the first to like this

Cerutti--Web Information Systems (postgrad seminar @ University of Brescia)

  1. 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. 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. 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. 4. Input and Output of Capacity Management Slide 4 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>
  5. 5. The forecast model: The project with a supplier Project Software WEB Slide 5 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>
  6. 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. 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. 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. 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. 10. The forecast model: The software project Project Software WEB Slide 10 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>
  11. 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. 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. 13. The forecast model: The Web Application Project Project Software WEB Slide 13 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>
  14. 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. 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. 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. 17. BPS: the process Requirements Planning Gathering/Analysis Detailed Analysis Design Implementation Deployment Slide 17 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>
  18. 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. 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. 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. 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. 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. 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. 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. 25. Polillo: Project Phases Iteration Design Prototyping Test Deployment Slide 25 © 2010 Federico Cerutti <federico.cerutti@ing.unibs.it>
  26. 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. 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. 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. 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. 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. 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>

×