Tabla De Contenido

21.4.2 CARACTERSTICAS TPICAS................................................................................................ 2

21.4.2.1 Planta De Entrada / Salida...............................................................................................2
21.4.2.2 MODOS DE CONTROL................................................................................................... 3
21.4.2.3 INTERFAZ DE OPERACIN............................................................................................3
21.4.3 CUESTIONES DE DISEO.................................................................................................... 5
21.4.4 EJEMPLO (CHANNEL TUNNEL)............................................................................................6
21.5 GESTIN SOFTWARE.............................................................................................................. 8
21.5.1 SOFTWARE - UN CASO ESPECIAL......................................................................................8
21.5.1.1 SOFTWARE ES COMPLEJA..........................................................................................8
21.5.1.2 SOFTWARE ES DISCONTINUA......................................................................................8
21.5.1.3 SOFTWARE CAMBIA DIFICULTADES ACTUALES.........................................................9
21.5.1.4 SOFTWARE ES INSUSTANCIAL.....................................................................................9
21.5.1.5 REQUISITOS DE SOFTWARE SON A MENUDO POCO CLARA...................................9
21.5.2 SOFTWARE DEL CICLO DE VIDA.......................................................................................10
21.5.2.1 ESPECIFICACIN DE REQUISITOS DE FASE............................................................10
21.5.2.2 SOFTWARE FASE DE DISEO.....................................................................................10
21.5.2.3 SOFTWARE MDULO FASE DE DISEO....................................................................11
21.5.2.4 FASE DE CDIGO......................................................................................................... 11
21.5.2.5 SOFTWARE FASE DE PRUEBAS.................................................................................12
21.5.2.6 SOFTWARE / HARDWARE INTEGRACIN FASE........................................................12
21.5.2.7 SOFTWARE VALIDACIN FASE...................................................................................12
21.5.2.8 FASE DE MANTENIMIENTO DE SOFTWARE..............................................................13
21.5.3 SOFTWARE PRCTICA IMPLEMENTACIN......................................................................13
21.5.3.1 Lifecycle Caractersticas Clave.......................................................................................14
21.5.3.2 Software De Seguridad Y Confiabilidad.........................................................................14
21.5.3.3 Anlisis Y Mtodos Y Herramientas De Diseo..............................................................15
21.5.3.4 Gestin De La Configuracin.......................................................................................... 16
21.5.4 GESTIN DE PROYECTOS DE SOFTWARE......................................................................16
21.5.4.1 Planificacin y Estimacin.............................................................................................. 17
21.5.4.2 Programacin................................................................................................................. 17
21.5.4.3 Esfuerzo Distribucin...................................................................................................... 18
21.5.4.4 Seguimiento del Progreso.............................................................................................. 18
Referencias...................................................................................................................................... 19

21.4.2 CARACTERSTICAS TPICAS

Es conveniente describir los sistemas SCADA, considerando su tpica
caractersticas en relacin con la entrada / salida, modos de control e interfaces
con personal de operacin.
21.4.2.1 Planta De Entrada / Salida
Normalmente, un interfaces del sistema SCADA con planta en un amplio
geogrfica zona a travs de PLC y otros equipos de control RTU / baha locales a
la planta. La nmero y los tipos de los puntos de entrada / salida depende de la
naturaleza de la equipo local conectado. Hay dos modos bsicos de captura de
entrada datos que puede ser utilizado por la instalacin de procesamiento central
de la SCADA.
Estos son:
(i)
captura programada, por lo que las unidades locales son consultados
sobre una base regular y todos los datos de entrada se transfieren; o
(ii) el cambio de la captura del Estado, por lo cual slo los datos de entrada
que han cambiado es transferido.
Los datos de entrada y de salida se llevan a cabo de forma centralizada en una
base de datos en tiempo real. Por celebracin de los datos histricos, as como los
actuales es posible proporcionar instalaciones para el anlisis y la presentacin de
informes de las tendencias. Este servicio suele ser particularmente importante
para los sistemas donde la mayora de los datos son analgicos en lugar de
discreto.
En la base de datos de datos de entrada y salida suelen agruparse en funcional
unidades o elementos. Por ejemplo varios puntos de entrada / salida pueden ser
agrupados
proporcionar la representacin completa de un disyuntor de circuito elctrico.
Con frecuencia tales grupos de puntos de entrada de la planta se transforman
para calcular puntos calculados que tambin se almacenan en la base de datos.
Por
ejemplo,
un
solo
punto calculado podra representar el estado de un nmero de circuito asociado
interruptores.
Un uso tpico de estos puntos calculados es en la gestin de alarmas.
En muchos casos, las alarmas se clasifican al menos en mayor y menor alarmas.
Cada alarma es en s misma probabilidad de ser un punto calculado generalmente
calculado a partir de un valor de entrada y un nivel de disparo. Algunas de las
principales alarmas tambin se pueden calcular a partir de combinaciones de
alarmas menores. Estrategias complejas para predecir condiciones de alarma
tambin puede ser utilizado.

21.4.2.2 MODOS DE CONTROL

Control de la planta asociada con un sistema SCADA puede ser local o remoto. El
control local puede ejercerse de forma automtica, por ejemplo por un local PLC, o
puede ser mediante controles mecnicos o elctricos locales (de forma automtica
o
de
accionamiento
manual).
Control remoto mediante el SCADA puede ser instigado por un operador puede
ser automtico. Los controles automticos pueden ser iniciados por el tiempo
(control programado) o eventos (cambio de control estatal). En ambos casos
controlar a menudo involucra iniciar una secuencia preprogramada de las acciones
que a continuacin se llevan a cabo de forma automtica.
Una ventaja de control distribuido con los sistemas de control situados localmente
en subestaciones y presentacin de informes a un sistema SCADA mayor nivel se
la menor dependencia de los enlaces de comunicacin problemticos en las
modernas estaciones controladas por ordenador, el sistema SCADA enva un
sencillo mando a distancia comando de control. Cualquier secuencia de control
secuencial se ejecuta localmente.
21.4.2.3 INTERFAZ DE OPERACIN
La interfaz de operacin para un sistema SCADA moderna debe ser diseado
para
proporcionar el mximo apoyo al operador en su papel de supervisin y
el control de la planta. A fin de lograr este uso considerable est hecho de
sofisticados grficos en tiempo real para mostrar la entrada de corriente y
retrospectiva
valores de salida y tendencias.
Una interfaz de operador bien diseado puede proporcionar un apoyo
considerable engestin de alarmas. Donde hay un potencial para gran nmero de
alarmas es particularmente importante que queden agrupados, clasifican y se
muestran en un de manera coherente que permite al operador concentrarse en el
ms importante alarmas. A menudo, la facilidad para filtrar las alarmas menores o
consecuentes o de reconocerlos en grupos para su posterior respuesta puede ser
valiosa por s misma.
Hoy en da, las pantallas grficas son generalmente basados en Windows. Hay
una creciente tendencia a la utilizacin de un ratn o una pantalla sensible al tacto
para complementar un teclado durante la mayor intervencin del operador. Las
visualizaciones grficas deben incorporar una jerarqua de las pantallas de los
esquemas de alto nivel de la planta en general a las tablas de asociados puntos
de entrada / salida en los niveles ms bajos. Insercin de banner de informacin
importante acerca de los eventos clave se utiliza a menudo. Con el fin de
3

suministrar toda esta funcionalidad es comn utilizar mltiples pantallas en las

posiciones de operadores individuales.
Una instalacin de seguridad importante que se requiere en muchos sistemas
SCADA es la definicin de los diferentes tipos de usuarios con acceso a diferentes
funciones o instalaciones. La distincin puede ser simplemente entre el supervisor
y operador o entre el terminal supervisor y terminal de operador o puede implicar
varios niveles de acceso. La mayora de los sistemas ofrecen la facilidad de crear
o configurar el Base de datos SCADA. Esto es generalmente necesaria para la
instalacin y puesta en marcha del sistema, pero no debe estar disponible para el
operador ordinario.
Centro de control general o diseo de la sala deben tener en cuenta lo siguiente:

La idoneidad de la estructura para soportar posibles eventos de riesgo

mayor.
La capacidad de la disposicin de diseo y el panel, PVD, etc., para
garantizar
manejo ergonmico efectiva de la planta tanto en condiciones normales y
de
emergencia
situaciones.

En particular, la sala de control y sus operadores deben ser considerados como un

"Todo el sistema", y no de forma aislada entre s. Diseadores de sala de control
y los operadores deben ser capaces de demostrar que el factor humano apropiado
consideraciones se han tenido en cuenta en el diseo. Las recomendaciones
sobre:

diseo;
mantenimiento;
ambiente de la sala trmica;
entorno visual (por ejemplo, los niveles de iluminacin de escritorio para
estar en el orden de 500 lx);
ambiente auditivo (por ejemplo, el ruido de fondo sea, 85 dBA);
interfaces hombre mquina?;
alarmas;
tcnicas de codificacin;
diseo de la pantalla (incluyendo texto, etiquetas, los dispositivos de
visualizacin y grficos);
controles;
y antropometra (alcance, asientos, y la postura, etc.)

junto con cdigos internacionales aplicables de la Prctica se da en el Las

referencias al final de este captulo.

21.4.3 CUESTIONES DE DISEO

El rendimiento del sistema es una de las tres cuestiones principales en cualquier
diseo.
este
ser dictado por el siguiente:
(i) la magnitud de las entradas / salidas de campo;
(ii) el tiempo de captura de datos se requiere, que por lo general es dictada por el
momento
limitaciones del proceso siendo monitoreados y / o el tiempo necesario para
responder a un evento;
(iii) Si todos los regmenes sofisticados se utilizan para la compresin de datos;
(iv) si se requiere un protocolo de comunicaciones determinista de la garanta una
respuesta en un plazo determinado;
(v) el nivel de integridad que se espera de las comunicaciones de datos;
(vi) lo fsico medios para la transmisin de datos es aceptable en lo particular
aplicacin.
Una segunda cuestin es la redundancia; cierta clave de entrada de la planta /
salida y aso-operacin ATED puede ser considerado como de alta integridad. Para
tal entrada / salida, redundancia necesita ser considerado en una o ms reas de
un
SCADA
sistema para minimizar los efectos de fracaso. Redundancia tpico puede incluir:
enlaces dobles para entrada / salida de la planta a dos o ms PLC o RTU;
doble enlaces de comunicacin dilogos de manejo con la supervisin principal
procesadores (MSP); redundancia en los principales procesadores de supervisin
proporcionados por cualquiera empleando un procesador tolerante a fallos de
espera o por tener dos o ms procesadores que proporcionan una funcin de
sombreado. En este caso, un procesador de 'standby' sera sombra todas las
operaciones de un procesador "normal" y de vigilancia mecanismos permitiran
una conmutacin de ocurrir si cualquier comunicacin se detectan errores de falla
o mantenimiento de datos.
El tamao del sistema en trminos del nmero de puntos de entrada / salida es
una
tercera edicin.
Como la carga en trminos del nmero de puntos de entrada / salida de plantas
aumentar la capacidad de procesamiento requerida aumenta. La arquitectura
central
de
un sistema SCADA puede requerir varios procesadores cada uno dedicado a lo
especfico
operaciones. Una particin tpica incluira:
5

Front End Procesadores (FEP). FEP estn dedicados a la manipulacin de

adquisicin de datos RTU de campo y equipo PLC.
Grficos estaciones de trabajo. Cuando un nmero de posiciones de
operador
son
requiere una arquitectura basada en cliente-servidor distribuido, repartir la
carga
entre un procesador de supervisin principal y dos o ms estaciones de
trabajo
grficas
debe ser proporcionada.
Supervisin de procesadores Principal (MSP). Uno o ms proyectos de
tamao mediano ofrecen centralizar control y representacin del / salida
(estado de la planta) Entrada de campo por medio de una base de datos
ms. El procesador central llevar a cabo funciones tales como el registro
de datos, manejo de secuencias de control, mantenimiento de lgicos
(funcionales) estado de los equipos.

21.4.4 EJEMPLO (CHANNEL TUNNEL)

El Sistema de Gestin de Ingeniera Channel Tunnel (EMS) emplea un Sistema
SCADA configurado para administrar equipos remotos a travs de 26,000 directa
entrada / puntos de salida y otros 7.000 puntos calculados. el equipo bajo el
control del ccsme es el equipo fijo situado en las dos terminales en Folkestone, en
el Reino Unido y Coquelles en Francia y en los tres tneles(Running Tunnel-Norte,
Correr Tunnel-Sur, y el tnel de servicio).
El Equipo fijo gestiona:
Distribucin elctrica:
Las conexiones a Nacional Grids (225 kV y 132 kV).
Suministro de Overhead 25 kV Sistema de catenaria.
Distribucin de tnel de 21 kV y 3,3 kV suministros.
Iluminacin Terminal y Tnel.

Sistemas mecnicos:
Sistemas de ventilacin normal y complementaria.
El enfriamiento del tnel.
Bombeo.
Equipos de extincin de incendios.
La figura 21.12 muestra el equipo RTU ubicado en el equipo 178
habitaciones situado entre el servicio y tneles de circulacin. Estos manejan la

adquisicin de datos y control de los puntos 26 000 de entrada / salida a travs de

600 PLCs.
Cuando un / punto de entrada y salida cambia de estado, el nuevo estado se enva
tanto a la Centros de control de Francia y Reino Unido utilizando una conexin de
insercin gota a la RTU.
Los estados de entrada / salida se manejan simultneamente por los principales
procesadores de EMS (MEP), tanto en el Reino Unido y los centros de control
franceses. Los eurodiputados son diciembre VAX procesadores que ejecutan el
software de aplicaciones SCADA idnticos. las mquinas operar en un modo
normal
/
en
espera.
La
mquina
normal
es
el
maestro
y
maneja todos los dilogos de operador desde el Reino Unido y puestos de
operador francs.
El procesador de espera mientras que mantiene la compatibilidad de datos con el
procesador normal tambin se monitorea la salud de los procesadores, redes
normales sitio ya travs de tneles enlaces punto a punto. Si se detectan fallas
entonces una conmutacin se producir y la mquina de reserva se mover a una
normal de estado.
Tres FEPs dedicados se proporcionan en cada terminal. Dos de estos FEPs
manejar comunicaciones con RTU. Los otros cuatro FEPs (dos en cada terminal)
proporcionar dobles enlaces redundantes a un nmero de sistemas externos, tales
como deteccin de incendios y control de acceso.
Integridad de datos se proporciona la siguiente manera:

Cierta entrada / salida de la planta tiene vnculos con dos procesadores

diferentes RTU.
Todo RTUs comunicarse tanto con los centros de control de Francia y Reino
Unido.
en
Adems de entrada / estados de salida recibida en el centro de control
franceses estn encaminado a centro de control del Reino Unido por el
tnel a travs de enlaces. Del mismo modo UK centro de control transmite
estados de entrada / salida para el centro de control francs.
En una operacin de plena disponibilidad cada diputado recibe dos
mensajes idnticos que se filtr en consecuencia.
Redundantes en las redes de sitios.

Servidores operador con funciones especficas (OPS) proporcionan cinco

posiciones de operador en el Reino Unido y cuatro en Francia. En el
funcionamiento normal estos proporcionan para una supervisin varios puestos de
mando y dos o posicin. El centro de control del Reino Unido tambin tiene un
importante centro de control de incidente (MICC) con un dedicado OPS.
Operaciones EMS son posibles de forma simultnea en el Reino Unido y Francia
centros de control. Sin embargo, slo un centro de control puede tener un estado
activo que determina la naturaleza de la posible operacin.
7

21.5 GESTIN SOFTWARE

PLC, sistemas de distribucin de energa y sistemas SCADA todos hacen uso de
software. En muchos casos, los componentes de software se pueden ver como el
principal contribuyentes a la funcionalidad de los sistemas. Este uso del software
tiene muchas ventajas, pero tambin presenta muchos problemas que necesitan
ser abordados cuidadosamente si no estn para amenazar el xito del proyecto.
21.5.1 SOFTWARE - UN CASO ESPECIAL
El uso del software en sistemas de control ofrece la flexibilidad ingeniero aumento
en el diseo y operacin de los sistemas. A menudo, el software permite a un
sistema proporcionar una funcionalidad que no poda darse de otra forma de una
rentable manera. Sin embargo, los proyectos de desarrollo de software son
reconocidos por ser tarde, por encima del presupuesto y que no cumplan con los
requisitos del cliente.
La clave para entender por qu los proyectos de desarrollo de software con
frecuencia poseen estas caractersticas desafortunadas es mirar cmo difiere de
desarrollo de software de otras ramas de la ingeniera.
Los problemas presentados por software son muchos y algo fundamentales en su
naturaleza. La disciplina todava maduracin de la ingeniera de software los
intentos de hacer frente a estos problemas.
21.5.1.1 SOFTWARE ES COMPLEJA
El software es un objeto dinmico muy complejo, incluso con un programa sencillo
que tiene un gran nmero de posibles patrones de comportamiento. Para la mayor
parte no trivial software es imposible probar exhaustivamente su comportamiento
[1] o demostrar que voluntad siempre se comportan como su especificacin
requiere. La dificultad de probar que un sistema de software cumple con su
especificacin se ve agravado por la falta de leyes fundamentales que se pueden
aplicar al software. Las matemticas subyacentes ingeniera de software es
todava en su infancia en comparacin con otras ramas de la ingeniera.
21.5.1.2 SOFTWARE ES DISCONTINUA
La naturaleza discontinua de software significa que pequeos cambios en la
entrada valores pueden dar lugar a grandes cambios inesperados en el software y
el sistema comportamiento. Pequeos cambios en el software en s pueden tener
resultados similares. Como resultado de la prueba significativo es mucho menos
evidente que para los sistemas analgicos.
Ensayo de un sistema de software terminado tiene un lugar en la prestacin de
Se requiere confianza en que desempea sus funciones correctamente, pero ms.
8

Un esfuerzo considerable debe ser gastado en la gestin y la evaluacin de la

proceso de desarrollo de software.
21.5.1.3 SOFTWARE CAMBIA DIFICULTADES ACTUALES
La gama de funciones de un sistema de software puede realizar y la aparente
facilidad con la que el nuevo software se puede agregar software hace muy
atractivo para ingenieros. Sin embargo esto es engaoso; una vez que el software
se construye es difcil cambiar con confianza. Incluso los pequeos cambios
pueden tener dramtico e imprevisto efectos sobre partes a menudo no
relacionados
de
un
sistema.
Adems,
como
ms
se realizan cambios en la arquitectura del software tiende a ser cada vez ms
complejo y fragmentado. Los cambios se hacen cada vez ms difcil de
implementar satisfactoriamente. Este hecho debe tenerse en cuenta al solicitar
modificaciones a los sistemas terminados.
21.5.1.4 SOFTWARE ES INSUSTANCIAL
La naturaleza intangible de software significa que usted no puede ver, tocar o
sentir software. Como resultado, un sistema de software es muy difcil de apreciar
hasta el final de un desarrollo cuando las partes componentes estn integrados.
Lamentablemente por el momento una alta proporcin de los recursos del
proyecto tendr ha gastado lo que cualquier accin correctiva caros por decir lo
menos. Adems las pruebas en esta etapa es slo de uso limitado en la prestacin
de fianza confianza en el software.
21.5.1.5 REQUISITOS DE SOFTWARE SON A MENUDO POCO CLARA
Los sistemas de software suelen realizar un gran nmero de diversas funciones
que pueden interactuar entre s de maneras complejas y sutiles. Es muy difcil
para un cliente para describir estas funciones, precisamente, y esto conduce a
requisitos poco claros y cambiantes. Este problema se agrava por la cultura
brecha que existe con frecuencia entre los clientes y los desarrolladores de
software.
En otras ramas de la ingeniera de la especificador de un producto suele ser con
experiencia en la disciplina de la ingeniera necesaria para construir ese producto.
Este situacin rara vez existe con los sistemas de software. Como resultado los
sistemas de software a menudo se especifican en Ingls narrativa porque las
anotaciones de software ingeniera no estn familiarizados con el cliente. El uso
de Ingls (u otro naturales idiomas) pueden dar lugar a ambigedades e
inconsistencias en la especificacin que luego se introducen en el proceso de
desarrollo y slo descubierto tarde en el proyecto cuando son difciles y costosos
de corregir.
9

21.5.2 SOFTWARE DEL CICLO DE VIDA

En el nivel ms alto de un proyecto de desarrollo de software debe ser gestionada
de la misma manera que cualquier otro proyecto de ingeniera. As, un desarrollo
de software debe seguir un ciclo de vida del proyecto de software similar a la
mostrada en Fig. 21,1 [2].
Tal ciclo de vida ha fases claramente definidas, con cada fase que tiene entradas y
salidas definidas. El proyecto debera haber reconocido revisar los puntos para
ayudar a control. Puntos de revisin normalmente se produciran al menos en Al
final de cada fase. El proceso de desarrollo de software y de todo el sistema debe
tener lugar dentro de un sistema de aseguramiento de la calidad, como la ISO
9000serie. El ciclo de vida se muestra en la Fig. 21.1 y se describe a continuacin
es un ciclo de vida para el desarrollo de software, que se debe integrar en el
proyecto general ciclo vital.
21.5.2.1 ESPECIFICACIN DE REQUISITOS DE FASE
El objetivo de la fase de especificacin de requisitos es producir un claro, completa
inequvoca descripcin, y no contradictoria de lo que un sistema es hacer. La
especificacin de los requisitos debe ser plenamente comprensible para ambos los
clientes y los desarrolladores. Puede haber requisitos de software independientes
especificacin, pero si no, los requisitos de software debe ser claramente
separada e identificable dentro de la especificacin global requisitos.
Los errores en la fase de especificacin de requisitos pueden tener consecuencias
muy graves y por lo tanto los desarrolladores deben hacer un gran esfuerzo para
confirmar su correccin.
Cuando la especificacin de requisitos se ha acordado, una prueba de requisitos
especificacin (a menudo llamado una especificacin de prueba de aceptacin)
debera elaborarse arriba. Este documento debe indicar aquellas pruebas un
sistema debe pasar para que sea aceptable para el cliente. En caso de un sistema
a prueba cualquiera de las pruebas de aceptacin el cliente tiene derecho a que el
problema que se fijar y re-pruebas realizadas. Sin embargo, estas pruebas no
pueden por s solos asegurar que el software es correcta.
21.5.2.2 SOFTWARE FASE DE DISEO
El uso de la especificacin de requisitos que los desarrolladores se iniciar el
diseo de la software. Como con cualquier disciplina de ingeniera esta es un
esencialmente creativa proceso que se puede hacer de muchas maneras
diferentes.
El objetivo de la fase de diseo de software es para descomponer el software en
un conjunto coherente de mdulos autnomos que tendrn cada una su propia
especificacin y que cada uno puede comprobarse por separado. El diseo de
software fase a menudo ver el proceso de desarrollo de software de desaparecer
10

en un tnel en lo que se refiere a la cliente. Algn tiempo despus, un sistema

totalmente funcional emerger desde el otro lado en la fase de validacin del
software. La el trabajo llevado a cabo dentro de este tnel es de vital importancia y
es bien vale la pena la comprensin de los clientes y el seguimiento de lo que
ocurre.
Un enfoque de arriba hacia abajo estructurado debe tomarse a este diseo de alto
nivel del software, produciendo una jerarqua de mdulos en diferentes niveles.
Una variedad de tcnicas, a menudo apoyados por herramientas automatizadas,
se puede utilizar durante el diseo. Tcnicas tpicas incluyen diagramas de flujo de
datos, transicin del estado diagramas, anotaciones orientados a objetos y
diagramas entidad relacin. cualquiera de estas tcnicas deben complementarse
con descripciones en ingls.
21.5.2.3 SOFTWARE MDULO FASE DE DISEO
El objetivo de la fase de diseo del mdulo de software es realizar la detallada
diseo de exactamente cmo cada mdulo llevar a cabo su tarea requerida. la
medios por los que se expresa este diseo detallado variar dependiendo de la
tipo de sistema en desarrollo y las herramientas utilizadas por el proveedor. tpico
enfoques son utilizar diagramas lgicos, diagramas de flujo, pseudocdigo
(programacin lenguaje como declaraciones), la notacin matemtica formal o
decisin mesas. Alternativamente las tcnicas utilizadas durante la fase de diseo
de software pueden seguir utilizndose. A menudo, una combinacin de estos
mtodos, complementado por Ingls lenguaje de descripcin es mejor. Es esencial
que el requerimiento de entradas y salidas, sus valores y significados posibles
estn claramente identificados para cada mdulo.
Durante el diseo detallado de un mdulo del desarrollador debera producir una
especificacin de la prueba que detalla las pruebas que deben llevarse a cabo
para confirmar las funciones correctas de un mdulo de una vez codificadas.

21.5.2.4 FASE DE CDIGO

El objetivo de la fase de cdigo es transformar la especificacin de diseo de
software y las especificaciones de diseo de mdulo de software en un programa
informtico coherente o programas.
Es importante asegurarse de que el cdigo producido es comprensible para las
personas que no sea el autor. Con el fin de lograr este objetivo, las normas del
proyecto debe se crear y se adhiere a las estructuras de cdigo, formato y
comentar. el cdigo de producido tambin deben ser revisados y cambios en el
cdigo aprobado son estrictamente controlada.
11

En principio, el lenguaje de programacin o idiomas que se utilizarn podra ser

seleccionado en esta etapa. En la prctica es probable que las restricciones de
diseo considerados anteriormente ya se han determinado el idioma. tales
consideraciones podra ser dictado por la disponibilidad, experiencia o procesador
utilizado, adems de los mritos de un idioma en particular. Si es posible un alto
nivel, guaje estructurado calibre siempre debe preferirse el uso de ensamblador.
21.5.2.5 SOFTWARE FASE DE PRUEBAS
La fase de pruebas de software debe cubrir el ensayo del software de individuo
mdulos al sistema de software completo. Por consiguiente, la fase implica
mucho ms que las pruebas en contra de la especificacin de las pruebas de
aceptacin. El objetivo de la fase es asegurar que las funciones de software
correctamente, en lo medida en que esto se puede lograr por medio de pruebas.
Con el fin de probar satisfactoriamente el individuo los mdulos que es probable
que sea necesario para gran parte de este anlisis para tener colocar en paralelo
con la fase de codificacin, aunque conceptualmente ocurre despus.
Se deben mantener registros de las pruebas de cada mdulo individual, de cada
grupo de mdulos como avanza la integracin de software y del completo
software integrado. Estos registros deben ser considerados como parte de la
documentacin del software y debe conservarse, ya sea por el proveedor o el
cliente. El cliente debe asegurarse de que el proceso de prueba se controla ya sea
directamente o por un tercero.
21.5.2.6 SOFTWARE / HARDWARE INTEGRACIN FASE
El objetivo de la fase de software / hardware de integracin es combinar la
software y hardware en un todo coherente. El proceso de integracin implica ms
pruebas del software y del sistema, con ms cambios que se realizan para el
software para resolver cualquier problema que pueda surgir. Frecuentemente parte
o la totalidad de esta fase deben tener lugar en las instalaciones del cliente. Es
esencial que las actividades de esta fase particular de software cambios y sus
pruebas son controladas y registradas adecuadamente.
21.5.2.7 SOFTWARE VALIDACIN FASE
La fase de validacin del software se produce cuando el software se ha
completado.El objetivo de la fase es asegurar que el software completado comtelas con la especificacin de requisitos del software. Una variedad de mtodos
puede ser utilizado incluyendo el software y las pruebas del sistema y varios
niveles de revisin de la documentacin del software y del sistema.

12

La relacin entre la validacin de software y pruebas de aceptacin puede variar

en funcin del tipo de proyecto, la funcin del software y la los requisitos del
cliente. En algunos casos se requiere validacin de software como parte de la
prueba de aceptacin antes de la instalacin del software en el sitio. En otros
casos la validacin puede ser necesaria despus de todos los ajustes de puesta
en marcha han sido implementado.
21.5.2.8 FASE DE MANTENIMIENTO DE SOFTWARE
Mantenimiento de software difiere de otras actividades de mantenimiento en que
se necesariamente implica modificaciones en el software. Estas modificaciones
pueden corregir errores en el software, se suman las instalaciones que deberan
haber sido incluidos originalmente o aadir nuevas instalaciones. A menudo, el
mantenimiento del software implica la actualizacin a un nuevo sistema operativo
y el software modificando existente de modo que se que funciona dentro del
entorno.
Debido a que el mantenimiento del software siempre implica nuevos cambios en el
software se requiere un control y una regulacin cuidadosa. Por ejemplo, los
beneficios o no de cada cambio propuesto debe ser cuidadosamente considerados
y analizados antes de autorizar el cambio.

21.5.3 SOFTWARE PRCTICA IMPLEMENTACIN

El proceso de desarrollo de software que se describe en la Seccin 21.5.2
proporciona una marco terico para las actividades que un ingeniero puede
esperar para ver teniendo lugar. El concepto de ciclo de vida del software y su
documentacin asociada son bien comprendidas y aceptadas, pero las
interpretaciones varan. En particular, ttulos de fase y documentos pueden no
coincidir con las presentadas en la Seccin 21.5.2. No obstante, debera ser
posible identificar todas las caractersticas clave en cualquier proceso de
desarrollo de software (ver Seccin 21.5.3.1).
En la prctica hay una gran variedad de herramientas, mtodos y tcnicas que
proveedores puede y debe utilizar durante el ciclo de vida del software. No puede
haber reglas claras acerca de lo que deben utilizarse y la eleccin tambin pueden
afectar a la ciclo de vida y documentacin conjunto asociado con el software. el
importante
punto es que ninguna de las herramientas, mtodos o tcnicas es suficiente por s
solo. Deben ser utilizados como parte de un enfoque basado en una justificable
coherente ciclo de vida y se asocia con documentacin y software completo
tcnicas de gestin de proyectos (vase la seccin 21.5.4).
13

21.5.3.1 Lifecycle Caractersticas Clave

Las caractersticas principales que deben ser evidentes en cualquier ciclo de vida
del software son:

Una clara especificacin del software identifica por separado estas

exigencias
de los requisitos del sistema y por separado del diseo de software;
Un diseo de software que se registra y pasa por dos o ms etapas
de aumentar el detalle antes de la codificacin;
Pruebas de software que se especifica claramente, y que cubre cada etapa
del cdigo que se est desarrollando, integrado e instalado;
Validacin final del cdigo completo en contra de los requisitos;
El control de cambios en el software completo;
Diseo y calidad revisiones formales en los puntos apropiados en el ciclo de
vida.

21.5.3.2 Software De Seguridad Y Confiabilidad

Los aspectos de seguridad de los sistemas que contienen software a menudo no
son apreciados por ingenieros. Software puede proporcionar a menudo el
potencial de mejora de la seguridad a travs de una mayor funcionalidad. Sin
embargo, las caractersticas de software son de tal manera que se necesita un
cuidado especial en el que se va a utilizar como parte de un sistema de que tiene
el potencial de hacer dao o que se requiere de otro modo que ser de alta
integridad.
Est ms all del alcance de esta seccin para proporcionar cualquier orientacin
detallada sobre el tema, pero en el Cuadro 21.5 listas un pocos de el proyecto
emergente y normas finales y las directrices que se aplican. La Institucin de
Ingenieros Elctricos (que ahora se llama El Instituto de Ingeniera y Tecnologa)
produjo una excelente breve profesional sobre el tema de los sistemas
relacionados con la seguridad [3], que ha sido actualizado por la orientacin de los
peligros Foro [9].

14

21.5.3.3 Anlisis Y Mtodos Y Herramientas De Diseo

Varias herramientas estn disponibles para ayudar con la especificacin de
software, diseo, implementacin y prueba. Diferentes mtodos abordan
diferentes aspectos de la ciclo de vida del software y el uso de diferentes
enfoques. Todos ofrecen al menos algunos de la estructura sobre la que basar un
ciclo de vida del software.
Asistido por ordenador herramientas de ingeniera de software (CASE) y los
mtodos de que se basan se utilizan con frecuencia como la base sobre la que un
Se planea proyecto de desarrollo de software. Estas herramientas suelen asistir
con especificacin, diseo e implementacin y proporcionar gran parte del ciclo de
vida necesaria documentacin de esas fases. La provisin de dicha
documentacin por una herramienta automatizada ayuda a asegurar que sea
coherente y sigue una coherente formato.
Lo ms importante es la trazabilidad de requisitos, a la final diseo y cdigo,
tambin est garantizada. En muchos casos, los mtodos y herramientas amplio
uso de diagramas que ayuda a hacer los diseos comprensible. Los mtodos
formales proporcionan un enfoque basado matemticamente para software
especificacin y diseo. El principal atractivo de este tipo de mtodos es que que
permiten una prueba de que la especificacin matemtica es internamente
consistente y que el cdigo completado implementa correctamente la
especificacin. Al momento de escribir estos mtodos no son muy utilizados y las
habilidades necesarias para su uso son escasos. En el futuro el uso de tales
mtodos puede ser espera que aumente, particularmente para aplicaciones de alta
integridad.
Una herramienta de gestin de cdigo propietario, para controlar configuraciones
de construccin deben ser adoptadas por los desarrolladores de sistemas. Estas
herramientas ayudan a proporcionar instalaciones bibliotecarias en un entorno
multi-desarrollo y asegurar que todas las modificaciones de software se registran y
15

se incorporan en el nuevo sistema construye. Las herramientas tambin

proporcionan instalaciones de control de la configuracin de la versin
estampacin archivos individuales y permitiendo versiones actuales e histricos de
un software sistema para recuperarse y reconstruir.
Otros mtodos y herramientas estn disponibles que no son tan fcilmente
categoras autorizadas. El anlisis esttico se puede utilizar para analizar el cdigo
de software y generar mtricas que expresan diversas caractersticas del cdigo
como nmeros. Las combinaciones de estas mtricas pueden usarse para ayudar
a formar un juicio acerca de la calidad del cdigo y su estructura. El anlisis
dinmico se puede utilizar para ejercer el cdigo y recopilar datos sobre su
comportamiento en uso.
21.5.3.4 Gestin De La Configuracin
Gestin de la configuracin de los sistemas de software se debe aplicar durante el
desarrollo y la vida operativa del software con el fin de controlar cualquier cambio
necesario y para mantener el software en un estado conocido.
Para lograr la gestin de configuracin de los componentes de un sistema de
software se reparti para formar los elementos de configuracin. Estos abarcan
todo el diseo y documentacin de prueba, as como los componentes de software
constituyentes.
El concepto de una lnea de base se aplica al software una vez que la
construccin est en una estado conocido, por lo general una vez que la fase de
integracin de software en el desarrollo se alcanza ciclo de vida. A partir de
entonces todos los cambios necesarios, como resultado de anomalas o
modificaciones funcionales, son controlados a travs de un cambio predefinido
proceso de control. Las etapas bsicas del proceso de control de cambio son:

Identificacin de necesidad de cambio;

Identificar la implementacin del cambio, evaluar el impacto y aprobar (o
rechazar)
aplicacin;
La implementacin del cambio de auditora;
Instalar software modificado y actualizar la lnea de base.

21.5.4 GESTIN DE PROYECTOS DE SOFTWARE

Esta seccin conjuntos de reas fuera en la que los problemas y las tcnicas de la
basada en software proyectos difieren de las de los proyectos ms tradicionales
de fabricacin.

16

No obstante, las cuestiones bsicas de la gestin de proyectos siguen siendo

vlidos y para lograr el xito de las siguientes reas deben ser abordados:

Definicin del mbito de trabajo;

Riesgo incurrido;
Los recursos necesarios; y
Tareas y fases que hay que realizar.

21.5.4.1 Planificacin y Estimacin

Al igual que con cualquier proyecto, la planificacin y la estimacin de los intentos
de cuantificar lo que se requiere de recursos. Normalmente esto se mide en
esfuerzo meses hombre, la duracin cronolgica, y la descomposicin de tareas y
otras reas que afectan costo. La complejidad de los requisitos de software y la
dificultad de correctamente definindolos hacen las necesidades de recursos
difciles de estimar. Con los recientes aos una serie de tcnicas de estimacin
han evolucionado que intentan cuantificar los probables costos y duraciones. La
base para las diferentes tcnicas, en todos los casos, se basa en las experiencias
del pasado y el dimensionado en funcin de la totalidad basado en ordenador del
sistema.
Cada tcnica de estimacin tiene una serie de atributos comunes:

Alcance del Proyecto;

Mtricas de software (medidas) que forman la base sobre la cual las
estimaciones
se podrn a;
Estimacin funcional y la descomposicin de tareas permitiendo de
individuo
artculos.

Hay dos categoras bsicas de las tcnicas de estimacin, tamao orientado y

funcin orientada. Un ejemplo de una tcnica orientada tamao es el constructiva
modelo de costos (COCOMO) [4]. Esto calcula el esfuerzo de desarrollo como
funcin del tamao del programa y produce esfuerzo de desarrollo (costo) y
duracin.
En contraste las tcnicas orientadas a la funcin normalmente se refieren a un
punto de la funcin anlisis [5] y considerar el esfuerzo asociado con el nmero de
entradas de usuario y salidas, consultas, archivos e interfaces. Una vez calculados
los puntos de funcin se utilizan para derivar la productividad, calidad y
mediciones de costos.

17

21.5.4.2 Programacin
En un pequeo desarrollo de software, un ingeniero de software puede tambin
analizar el diseo, cdigo, prueba y posteriormente instalar un sistema. Sin
embargo, como proyecto tamao y la complejidad aumenta ms ingenieros deben
involucrarse. En un equipo multi persona proyecto hay una sobrecarga de tiempo
incurrido en la comunicacin entre los miembros del equipo.
Adems, cuando los miembros del equipo se unen proyecto equipos en un intento
de recuperar el tiempo perdido, que necesitan aprender el sistema, muy
probablemente de los que ya estn trabajando en el proyecto. En resumen, como
proyecto tamao y complejidad incremento entonces el esfuerzo de ingeniera
necesario para aumentos de aplicacin de manera exponencial. Si se desliza de
desarrollo de proyectos (o requiere acelerar) aadir nuevo esfuerzo tpicamente al
aumentar la magnitud de cualquier deslizamiento (al menos en el corto plazo).
La cuestin fundamental a considerar es que las relaciones de trabajo de las
personas y las estructuras son esenciales para el xito del proyecto, pero
necesitan una cuidadosa estructuracin y la gestin.
21.5.4.3 Esfuerzo Distribucin
Todas las tcnicas de estimacin de software conducen a estimaciones de la
duracin de los proyectos en esfuerzo (tpicamente meses hombre). stos asumen
una distribucin del esfuerzo a travs del ciclo de vida de desarrollo de 40-20-40
(ver Fig. 21.1). La distribucin 40-20-40 pone el nfasis en las tareas de anlisis y
diseo de front-end y back-end la prueba.
21.5.4.4 Seguimiento del Progreso
El carcter no sustancial de software hace un progreso muy difcil de medir.
Una gran cantidad de recursos a menudo es necesaria para completar un proyecto
que es reportado como casi completa. Las cifras tpicas citadas son el 50% de los
recursos para completar el ltimo 10% del proyecto [6].
Por la separacin y la presentacin de informes sobre las actividades de desarrollo
de software a un bajo medicin realista nivel de progreso se hace ms prctico.
Debido a que cada tarea bsica es pequea y autnoma es relativamente sencillo
para identificar si se ha completado y por lo tanto estimar el progreso que se ha
hecho.

18

Referencias
1. Leveson NG. Software safety: why, what, and how. Computing Surveys
1986;18(June (2)).
2. IEC. Draft software for computers in the application of industrial safety related
systems.
IEC (Secretariat) 122, International Electrotechnical Commission; 1991.
3. IEE. Safety related systems_a professional brief for the engineer. The Institution
Electrical
Engineers, London; January 1992. p. 1.
4. Boehm B. Software engineering economics. Engelwood Cliffs, NJ, USA:
Prentice-Hall; 1981.
5. Albrecht A.J. Measuring application development productivity. In: Proc IBM Appl
Dev Symp. Monterey, CA; October 1979. p. 83_92.
6. Brooks FP. The mythical man-month. Addison-Wesley; 1975.
7. www.hse.gov.uk/comah/stragtech/techmeascontrol.htm. Control Room design,
2010.
8.Kincade
RG, Anderson J. Human factors guide for nuclear power plant control room
development.
EPRI-NP3659. Essex Corporation, San Diego; 1984.
9. Hazards Forum. Safety related systems_guidance for engineers. Issue 2, August
2002.
ISBN: 0-9525-103-0-8. The Hazards Forum, London.

19