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çãopara a Indústria

António GriloProf. 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. Theyshould 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

Technology

Transcript of Aula 11 23052013 sii-v1