Aula 11 23052013 sii-v1

Sistemas de Informação para Indústria
© António Grilo 2013Departamento de Engenharia Mecânica e Industrial
1
Class 11
Planning of Information Systems Projects
Ano 2013
Sistemas de Informação
para a Indústria
António Grilo
Prof. Auxiliar FCT-UNL,

2
Planning Information Systems Projects
Runaway projects and system failure represent nearly 30% - 40% of IT
projects:
• Exceed schedule, budget
• Fail to perform as specified
• Types of system failure
• Fail to capture essential business requirements
• Fail to provide organizational benefits
• Complicated, poorly organized user interface
• Inaccurate or inconsistent data

3
Project Management
Project management activities include planning work, assessing risk,
estimating resources required, organizing the work, assigning tasks,
controlling project execution, reporting progress, analyzing results.
Project management includes five major variables:
• Scope
• Time
• Cost
• Quality
• Risk

4
Planning an Information Systems Project
Project Charter - is a document that is elaborated in order to summarise
the project main goals and scope and obtain a formal approval for the
development of project or phase.
Project Preliminary Plan - is a dynamic document that is progressively
developed as the project matures and information becomes available. This
preliminary plan is included within the business case and takes effect when
the business case is accepted. The preliminary plan provides direction and
control of project activities until a more comprehensive plan can be
developed and approved. The preliminary project plan will evolve to the
Baseline Project Plan
Baseline Project Plan – Is the consolidation of the Project Preliminary Plan
and will be the basis for the Execution phase of projects

5
Structure of a Project Plan (Preliminary or Baseline)
1. The project background and reason for existence
2. The project objectives and success criteria
3. The project scope and high level work breakdown structure
4. Project schedule detailing key activities and major milestones
5. Structure for the management, responsibilities, accountabilities
6. Estimate of costs/Budget
7. Out of scope items, related projects, constraints, and assumptions
8. Impacts, both internal and external
9. Risks and response strategy
10. Procurement strategy
11. Stakeholders Management

6
Work Breakdown Structure (WBS)

7
Schedule and Milestones (Gantt Diagram)

8
Specification of Requirements
Specifications are intended to a diverse audience
- Customers and users for validation, contract, …
- Systems (requirements) analysts
- Developers, programmers to implement the system
- Testers to check that the requirements have been met
- Project Managers to measure and control the project
Different levels of detail and formality is needed for each audience.
There are different templates for requirements specifications (e.g. IEEE
830)
Requirements = services the system is expected to provide +
constraints placed on the system
Requirements engineering = gathering, negotiating, analyzing, and
documenting requirements

9
Requirements
The requirements could be expressed at various levels of abstraction.
The way requirements are defined has a major impact on the
development of the information system.
Extract from the requirements specification example:
R1: The system shall provide illumination of at least 500 candela.
R2: The system shall fit within a cube with maximum width of 15cm.
R3: The illumination can be switched on and off by a human operator.
R4: The system shall respond to operator input within 0.5 seconds.
R5: The system shall have a built-in power supply which should be
capable of maintaining continuous illumination for at least 4 hours.
etc . . . . . . .

10
Classification of Requirements
User requirements
Higher level description of services requested and constraints imposed.
Should be understood by the user, and should not address design and
implementation aspects. They
should focus on the key facilities required.
System requirements:
A more detailed, structured description of services and constraints.
Typically consider the non-functional requirements. They are used by
developers as basis for design, and may be specified using various
models (object-oriented models, data-flow diagrams, formal specs,
etc.). These requirements should indicate WHAT the system is required
to do (not HOW) and under what conditions and constraints

11
Requirements

12
Requirements

Aula 11 23052013 sii-v1

Recommandé

Recommandé

Contenu connexe

Similaire à Aula 11 23052013 sii-v1

Similaire à Aula 11 23052013 sii-v1 (20)

Plus de Aneesh Zutshi

Plus de Aneesh Zutshi (8)

Dernier

Dernier (20)

Aula 11 23052013 sii-v1