WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Requirement study for the business integration of the new SCADA/EMS system on the AES SONEL network in Cameroon

( Télécharger le fichier original )
par Mbelli Njah Fongha
Polytechnic,Yaounde - Masters Engineering in Electrical Engineering(Diplome d'ingenieur de conception avec option Genie Electrique) 2009
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

2.4.2: Requirement analysis and specifications development

Requirement analyst and engineers use several different techniques in analyzing requirements as well as establishing their specifications such holding interviews, holding workshops, prototyping, use cases e.t.c. In requirement analysis and specification development, they use techniques that include [10];

1) Stakeholder identification: modern technique which involve identifying the different stakeholders to use the system which encompass direct system users (operators, organization employing requirement engineer) to include senior management, back office systems or organizations and other organizations that can integrate horizontally with organization employing requirement engineer/analyst. The possible stakeholders of this PMS system in our context were identified to be IPPs, ITCs, AESS-T, large retailers, large and small customers, ARSEL and the TSO/present network operations department.

2) Stakeholder interviews: common method use in requirement analysis. These interviews help to reveal requirements not previously being envisaged as being within the scope of the project or even contradictory requirements. Most commonly, each stakeholder has idea of his expectation or would have visualized his requirements.

3) Contract-style: a traditional way of documenting requirements using the implementation plan proposed by the EPC contractor, Siemens in our context

4) Measurable goals: involves using a set of critical measurable goals during the requirement analysis during which the level at which each goal has been attained is continuously being verified.

5) Prototyping

6) Use cases: entails using case studies or examples of similar systems during the requirement analysis. The National grid and the NYISO (New York Independent System Operator) were used as case studies in system operation in our context.

2.5: Process engineering

2.5.1: Change management

Change Management is the process of requesting, determining attainability, planning, implementing and evaluation of changes to a system [11]. The two main goals of change management include: supporting the processing of changes and enabling traceability of changes, which should be possible through proper execution of the process. It is an important process because it can deliver vast benefits by improving the system and thereby satisfying customer needs. Change management can also cause enormous problems because it can ruin system or mix up change administration. In the information technology domain, more funds and work are put into system maintenance, which involves change management, than to the initial creation of a system [12].

The change management process includes a set of activities and deliverables. The six main activities involved in the change management process are

i) Identify potential change [13]: a potential change can be identified when a new functionality is required or a problem is encountered leading to a change request.

ii) Analyze change request [13]: involves determining the technical feasibility of the change as well as its costs and benefits.

iii) Evaluate change

iv) Plan change: entails analyzing change impact and creating a change plan.

v) Implement change: entails executing change, propagating change, testing change, updating documentation and releasing change.

vi) Review and close change: entails verifying and closing change.

The deliverables of the change management process are requirements include

Ø Requirement

Ø Problem report: document describing facts and information related to the problem

Ø Change request

Ø Change log entry: entry consisting of change request, change technical feasibility, change costs and benefits, change impact analysis, change planning, test report and change verification.

Ø Change technical feasibility: document indicating whether or not reliable hardware, software and technical resources are capable of meeting the needs of proposed system

Ø Change cost and benefits: effort required to implement and advantages.

Ø Change impact analysis: assessment of the extent of change

Ø Change planning

Ø Added and changed items

Ø Test report

Ø Documentation: explains, gives instruction for use or otherwise functions as a major guide to the system materials or system. Can be material or training.

Ø System release

Ø Change verification: a determination of whether or not the result of change implementation fulfills the requirements established.

The meta-modeling technique is used to describe the change management process. The figure below is a process-data diagram displaying an algorithm for the change management process with all its activities and deliverables

Figure 15: Process data diagram for the change management process [13]

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"L'ignorant affirme, le savant doute, le sage réfléchit"   Aristote