Modelo de desarrollo de requisitos en SCADA (página 2)

Entre las aplicaciones de estos sistemas se encuentran las siguientes:

• "Monitorizar procesos químicos, físicos o de transporte en sistemas de suministro de agua, para controlar la generación y distribución de energía eléctrica, de gas o en oleoductos y otros procesos de distribución.

• Gestión de la producción (facilita la programación de la fabricación).

• Mantenimiento (proporciona magnitudes de interés tales para evaluar y determinar modos de fallo, MTBF, índices de Fiabilidad, entre otros).

• Control de Calidad (proporciona de manera automatizada los datos necesarios para calcular índices de estabilidad de la producción, tolerancias, etc.

• Administración (actualmente pueden enlazarse estos datos del SCADA con un servidor ERP (Enterprise Resource Planning o sistema de planificación de recursos empresariales), e integrarse como un módulo más)." (Robotica-Domotica-cibernetica-ofimatica-sistemas-SCADA)

Actualmente los SCADAs son empleados en una gran variedad de aplicaciones de diversas industrias: pesadas, ligeras o de bienes; en Cuba, se trabaja en Holguín en el desarrollo de SCADAs para la línea del Níquel(Ni) en el control de exportación con el Sistema de supervisión y control EROS; en la UCI se desarrollan sistemas para Empresas productoras de Petróleo (PDVSA) en la República Bolivariana de Venezuela, para la Empresa de Telecomunicaciones de Cuba (ETECSA) con el objetivo de supervisar los equipos del departamento de Energía y Climatización, para el Instituto de Meteorología que desea supervisar los parámetros de sus equipos para realizar cálculos predictivos acerca del comportamiento del tiempo, para el Centro de Inmunología Molecular (CIM) relacionado con la industria farmacéutica para controlar la temperatura de los equipos que se usan para producir biofármacos destinados al tratamiento del cáncer, para la Oficina del historiador con el objetivo de lograr edificios inteligentes capaces de supervisar los consumos de grandes corporaciones como hoteles, centros comerciales, entre otros.

Ver en la Figura , el dominio de las LPS SCADA.

Fig. 1. Dominios de Aplicación de la línea de productos de SCADA.

Los principales aspectos que influyen en la complejidad del DR de las LPS SCADAs y por ende a que el equipo de desarrollo no tenga una idea clara de lo que se necesite construir, se centran básicamente en las funcionalidades de esta LPS, aunque prevalecen las siguientes :

• Tratamiento de alarmas (información visual, sonora, texto).

• Tratamiento histórico de la información (mediante su incorporación en bases de datos), procesamiento en tiempo real, manejo masivo de datos (miles de variables) y persistencia de los mismos.

• Infraestructura de comunicación en tiempo real entre diferentes aplicaciones y dispositivos de control: PLC's (Controladores lógicos programables), PACs (Controlador de automatización programable), RTU o DRIVER's (Variadores de velocidad de motores), incluyendo las normas para diagramación de procesos e instrumentación.

• Desarrollo de manejadores (drivers) para la comunicación con los dispositivos de control, requiere que el equipo necesite cierta especialización y conocimiento sobre los actuadores que van a programar.

• Las operaciones y cálculos que debe realizar el sistema en tiempo real con los datos adquiridos.

• Amplio campo de acción donde se pueden implementar estos sistemas.

• Relaciones estrechas de trabajo entre automáticos, ingenieros de software y el especialista del dominio donde se vaya a instalar el sistema :este último posee una cantidad significativa de conocimiento especializado en forma de conocimiento tácito que los ingenieros de software deben obtener y modelar.

• Sistemas distribuidos geográficamente.

El DR en la LPS es un proceso complejo atendiendo a la criticidad de los sistemas SCADA y a los requisitos no funcionales que determinan el comportamiento del mismo.

En las entrevistas realizadas a los analistas de los proyectos que desarrollan la LPS SCADA, que son los encargados de lograr una visión de conjunto y componer una especificación de requisitos completa, correcta y consistente, se evidenció en el 72% de los casos la existencia de una serie de problemas en algunos casos comunes durante la etapa de DR, entre los cuales se identificaron los siguientes:

• Los analistas no tienen una idea clara de lo que se desea construir debido a la complejidad de estos sistemas, esto trae consigo que no se haga una captura correcta y completa de los requisitos.

• Como no existe una memoria de requisitos de LPS SCADA se basan para la obtención de los mismos en el estudio de documentación relacionada con el tema, y en algunas características de otros sistemas SCADA existentes como el Oasis y el GALBA (Guardián del Alba),.

• Una vez especificados los requisitos (con problemas), los analistas se intercambian estos documentos, reutilizando la información de los mismos, lo que conlleva a la repetición de errores.

• Debido a esto las especificaciones de requisitos no incluyen todas las funcionalidades que debe tener el sistema, excluyendo así algunas características importantes.

• No tienen experiencias y habilidades en la IR de sistemas industriales por lo que se aplican en los mejores casos pocas técnicas de IR, debido a esto, las informaciones dadas por los usuarios o recopiladas por los mismos analistas no llegan a ser suficientes.

• Los requisitos no son analizados y validados, no se tiene conocimiento sobre las técnicas usadas para desarrollar estas actividades, debido a esto no se profundiza en el dominio del problema, en otros casos algunos requisitos no se corresponden realmente a las necesidades de clientes y usuarios, y presentan contradicciones por provenir de distintos proveedores, en algunos casos inapropiados.

• No existe una estrecha relación de trabajo entre automáticos, analistas y el especialista del dominio (en algunos casos este último no existe), esto trae consigo que no se entienda bien el dominio del problema y que se use un lenguaje técnico que conlleve al no consenso de las partes involucradas.

• Inestabilidad en los requisitos solicitados por el cliente.

• Demoras en informaciones pedidas al cliente.

• En el CEDIN se desarrollan los requisitos para cada producto individualmente y no enfocado a la reutilización de los mismos a pesar de sus semejanzas, este proceso no se realiza de manera centralizada atendiendo a cada dominio del SCADA que se desarrolla, por lo que el nivel de reutilización es muy escaso.

Todas estas anomalías han contribuido en algunos proyectos a que aumente el número de errores existentes en la etapa de requisitos, a que la misma se extienda un poco más de lo planificado y en otros casos a que se tenga que retroceder a la etapa inicial por la aparición de nuevos requisitos, lo que ha conllevado a un alto nivel de reproceso de actividades que deben realizarse para corregir dichas fallas, todo esto junto a otros factores ha ocasionado retrasos en el cronograma, aumento en el costo de los proyectos, y por ende demoras en la entrega a tiempo de los productos a los clientes.

El presente trabajo se enfocará al estudio del DR en la LPS SCADA, a diferencia del DR de un producto único, pues no existe un proceso que sea válido de aplicar según las especificidades de estos productos y el nivel de experiencia y habilidad de las personas involucradas en la ingeniería de requisitos.

A partir de esta situación se define el Problema científico:

Los métodos que actualmente se utilizan para el DR en la LPS SCADA no proporcionan al analista el entendimiento total del sistema y contribuyen a que no se entregue el producto al cliente dentro del tiempo estimado .

De acuerdo al dominio para el que se desarrolla cada producto de software, se hace necesario definir y desarrollar el carácter común y la variabilidad de los requisitos de la LPS.

De ahí que el objeto de estudio de la presente investigación se centre en la disciplina de IR.

Para responder al problema científico se definió como Objetivo General:

Desarrollar un modelo para el DR en la LPS SCADA que proporcione al analista un mayor entendimiento del sistema y contribuya a que se entregue el producto al cliente dentro del tiempo estimado. Por tanto como campo de acción se define el DR en proyectos SCADAs.

La Hipótesis de la investigación se plantea de la siguiente manera:

Si se desarrolla un modelo para el DR orientado a proyectos SCADAs, se logrará un mayor entendimiento del sistema por parte de los analistas y contribuirá a que el producto se entregue al cliente dentro del tiempo estimado.

A partir de un análisis del objetivo general se derivaron los siguientes Objetivos Específicos:

• Elaborar el marco teórico de la investigación.

• Analizar actualmente como se realiza el DR en los proyectos SCADAs.

• Desarrollar un modelo para el DR en proyectos SCADAs.

• Validar el modelo propuesto en un proyecto SCADA.

Para lograr los objetivos trazados se acometieron las siguientes Tareas:

• Análisis de los conceptos fundamentales relacionados con la Ingeniería de Requisitos para fundamentar teóricamente la investigación.

• Análisis del estado de arte sobre los modelo de desarrollo de software basado en Líneas de Productos para fundamentar la utilización de este modelo en proyectos SCADAs del CEDIN.

• Análisis del estado de arte de los modelos de ingeniería de requisitos basado en Líneas de Productos para fundamentar la utilización de este modelo en proyectos SCADAs del CEDIN.

• Realizar un diagnóstico de la situación actual en el DR en los proyectos SCADAs del CEDIN.

• Definición de la obtención de requisitos en proyectos SCADAs, incluyendo las tareas a realizar y las técnicas y herramientas a emplear.

• Definición del análisis y especificación de requisitos en proyectos SCADAs, incluyendo las tareas a realizar y las técnicas y herramientas a emplear.

• Definición de la validación de requisitos en proyectos SCADAs, incluyendo las tareas a realizar y las técnicas y herramientas a emplear.

• Selección de un proyecto SCADA del CEDIN para validar el Modelo propuesto.

Los Métodos de Trabajo Científico utilizados son los siguientes:

Métodos teóricos

El método histórico-lógico y el dialéctico para el estudio crítico de los antecedentes utilizando estos como punto de referencia y comparación de los resultados alcanzados

El método analítico-sintético al descomponer el problema de investigación en elementos por separado y profundizar en el estudio de cada uno de ellos, para luego sintetizarlos en la solución la propuesta.

El método de idealización-modelación para explicar por qué el modelo seleccionado es el que más se ajusta a las características de los proyectos SCADAs

Métodos empíricos:

El método de la entrevista para obtener los principales problemas que existen en proyectos SCADAs a la hora de desarrollar los requisitos.

Variables de la investigación

Para la operacionalización de las variables se usó la descomposición atendiendo a los elementos que la conforman.

Población: Proyectos SCADAs del Centro de Informática Industrial.

Muestra: Analistas de los Proyectos SCADAs del Centro de Informática Industrial.

La Novedad Científica de la tesis se expresa en sus aportes fundamentales que son los siguientes: Brindar un modelo de referencia para el DR en proyectos SCADAs.

CAPÍTULO I

IR : conceptos y características

• Requisitos

A través de los años se ha podido constatar que los requisitos son la pieza fundamental en un proyecto de desarrollo de software, ya que marcan el punto de partida para actividades como la planeación, básicamente en lo que se refiere a las estimaciones de tiempos y costos, así como la definición de recursos necesarios y la elaboración de cronogramas que será uno de los principales mecanismos con los que se contará durante la etapa de desarrollo.

Se presenta a continuación definiciones existentes de lo que es un requisito:

"Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.

Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal". (2006)

"Son una especificación de lo que debe ser implementado, son descripciones de cómo el sistema debe comportarse". (Requirements Engineering: A Good Practice Guide., 1997)

Analizando los conceptos anteriores, se define un requisito como una descripción de una condición o capacidad que debe cumplir un sistema, ya sea derivada de una necesidad de usuario identificada, o bien estipulada en un contrato, estándar, especificación u otro documento formalmente impuesto al inicio del proceso.

• IR

La comprensión de los requisitos de un sistema está entre las tareas más difíciles que enfrenta un analista, desde mediados de los años setenta estos han cobrado especial importancia debido al alto costo que implica corregir los errores relacionados con los mismos ,a causa de esto actualmente los requisitos son considerados claves en el desarrollo de un software.

El término Ingeniería de Requisitos ha surgido para englobar los procesos de desarrollo y gestión de requisitos en el ciclo de vida del software, el primero enfocado a las actividades de obtención, análisis, especificación y validación de los requisitos que permitirá alcanzar los objetivos del negocio y el segundo centrado en la administración de los mismos, que tiene como propósito central la gestión de los cambios y la trazabilidad, de esta forma la IR proporciona el mecanismo apropiado para:

• "Entender lo que el cliente quiere.

• Analizar las necesidades.

• Evaluar la factibilidad.

• Negociar una solución razonable.

• Especificar la solución sin ambigüedades.

• Validar la especificación.

• Administrar los requisitos conforme éstos se transforman en un sistema operacional." (Ludeña, Aurelio Capa y Santiago)

• Importancia de la IR

Según la autora Lizka Yohany Herrera en su documento de la IR, los principales beneficios que se obtienen de la IR son:

• "Permite gestionar las necesidades del proyecto en forma estructurada: cada actividad de la IR consiste de una serie de pasos organizados y bien definidos.

• Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.

• Disminuye los costos y retrasos del proyecto: es sabido que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la IR, ya que es una de las etapas de mayor importancia en el ciclo de desarrollo de software y de las primeras en llevarse a cabo.

• Mejora la calidad del software: la calidad en el software tiene que ver con cumplir un conjunto de requisitos(funcionalidad, facilidades de uso, confiabilidad, desempeño, entre otros).

• Mejora la comunicación entre equipos: la especificación de requisitos representa una forma de concenso entre clientes y desarrolladores, si este concenso no ocurre, el proyecto no será exitoso.

• Evita rechazo de usuarios finales: Obliga al cliente a considerar sus requisitos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto." (Ingenieria de requisitos, Ingenieria de software, 2003)

Por otro parte en estudios realizados en el 2004 por El Standish 2004 CHAOS Report, que encuestó a 9.236 proyectos, queda demostrado que sólo el 29% de los mismos finalizan con éxito. Entendiendo por proyectos exitosos, aquellos que terminan en el tiempo estimado, presupuesto establecido y funcionalidad requerida. En la siguiente figura se evidencia el alto número de proyectos que fallan al tratar de alcanzar sus objetivos y queda demostrado como la etapa de requisitos influye en un alto porciento de estos fracasos.

Figura 1. Factores de fracaso en los proyectos

A partir del estudio de las principales causas de fallas en los procesos se encuentra que el 52% se atribuyen a deficiencias en el proceso de ingeniería de requisitos como son: una mala administración de los requisitos, trabajar con los proveedores inapropiados, poca participación de los usuarios, requisitos incompletos, incorrectos, que faltan e inclusión de requisitos no esenciales. Todo lo anterior genera un alto nivel de reproceso de actividades que deben realizarse para corregir dichas fallas. Una valoración de los costos por reproceso muestra que estos pueden llegar a representar el 30% del total del costo del proyecto.

Figura 2 Costos por reprocesos

Estos costos pueden llegar a aumentar dependiendo de la etapa del proyecto en la cual sean identificados, como se evidencia en la figura Costo de la corrección de fallos originados en requisitos. La detección temprana de estas fallas ayuda a disminuir considerablemente el impacto en todos los aspectos del proyecto, incluido el costo de corrección. En contraposición, la detección tardía de una de estas fallas puede llegar a aumentar los costos de corrección hasta 1000 veces que sí se hubiese hecho al inicio del proyecto. (Ltda, 2004)

• IR: Actividades dentro del proceso de DR

Hay cinco etapas en un proceso típico de Ingeniería de Requisitos utilizadas para el desarrollo de un producto único, cuatro de estas actividades forman parte del proceso de DR, las mismas son: obtención, análisis, especificación y validación de los requisitos. En general la delimitación entre una actividad y la otra no es tan clara, ya que están sumamente interrelacionadas, existiendo entre una y otra un alto grado de iteración y retroalimentación.

Obtención

Actividad involucrada en el descubrimiento de los requisitos del sistema. Aquí, los analistas deben trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar, etc. Los principales objetivos que se deben alcanzar son los siguientes:

Conocer el dominio del problema, de forma que los analistas puedan entenderse con los clientes y usuarios y sean capaces de trasmitir dicho conocimiento al resto del equipo.

Descubrir necesidades reales entre clientes y usuarios, haciendo énfasis en aquellas que la mayor parte de las veces se asumen y toman por implícitas.

Consensuar los requisitos entre los propios clientes y usuarios hasta obtener una visión común de los mismos.

Análisis

Sobre la base de la obtención realizada previamente, comienza esta fase la cual tiene como propósito descubrir problemas con los requisitos del sistema identificados hasta el momento, para ello se basa en los siguientes objetivos:

"Detectar conflicto en los requisitos que suelen provenir de distintas fuentes y presentar contradicciones o ambigüedades debido a su naturaleza informal.

Profundizar en el conocimiento del dominio del problema puede facilitar el proceso de construir un producto útil para clientes y usuarios." (Un entorno metodológico de IR para sistemas de información, 2000)

En esta fase el analista proporciona un sistema de retroalimentación que refina el entendimiento que obtuvo el analista en la etapa de obtención.

Especificación

En esta fase se documentan los requisitos acordados con el cliente, en un nivel apropiado de detalle. En la práctica, esta etapa se va realizando conjuntamente con el análisis, se puede decir que la especificación es el "pasar en limpio" el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML (Lenguaje de Modelado Unificado), que es un estándar para el modelado orientado a objetos, por lo que los casos de uso y la obtención de requisitos basada en casos de uso se utiliza cada vez más para la obtención de requisitos.

Validación

Por último, la validación garantiza que los requisitos una vez analizados y resueltos los posibles conflictos, correspondan realmente a las necesidades de clientes y usuarios, de forma que se evite a pesar de que el producto final sea técnicamente correcto, no sea satisfactorio. La validación puede llevar al analista a reescribir algunas especificaciones de requisitos, en otros casos a obtener nuevos, producto de la aparición de necesidades que hasta entonces estaban ocultas, para volver a evaluar el análisis inicial, o para corregir y perfeccionar el conjunto de requisitos documentados.

Para el desarrollo de la línea de productos de estas actividades son las mejores que se realizan en las primeras etapas de DA & E. Los principales objetivos de DA & E son la identificación de productos potenciales miembros y sus necesidades, para analizar estos requisitos y para diseñar y aplicar un marco de dominio reutilizables. Lo anterior cinco etapas del proceso de ingeniería de requerimientos se pueden utilizar para identificar, analizar, especificar, verificar y gestionar los requisitos de la línea de productos y línea de productos de otros aspectos relacionados. Varias herramientas y técnicas se han desarrollado para cada una de las etapas de ingeniería de requerimientos. La aplicabilidad de diversas técnicas como el desarrollo de líneas de productos han sido evaluados en las siguientes secciones.

En nuestro trabajo futuro que va a proponer una metodología de ingeniería de requerimientos para las líneas de productos. Este método utiliza un enfoque de programación orientada a aspectos para la identificación de requisitos comunes y variables y mapas de productos para la determinación del alcance y las características de la familia. Utiliza XML como una especificación de plantilla para especificar los requisitos y mantener la relación de dependencia entre las necesidades.

Normas y modelos para la Ingeniería de Requisitos

Modelo de desarrollo para la Ingeniería de requisitos

En esta sección se comentan brevemente algunos de los modelos más usados para la ingeniería de requisitos.

Modelo de Pohl

Es un modelo iterativo en el que se definen las cuatro actividades que pueden verse en la siguiente figura, en la que aunque el orden de realización de las actividades puede ser cualquiera, se asume una secuencia en la que los requisitos son obtenidos, a continuación son negociados entre los participantes, se integran con el resto de la documentación y finalmente se validan y verifican para asegurar que se corresponden con las necesidades reales de los clientes y usuarios y que no presentan conflictos con los demás requisitos.

Fig. Modelo de procesos de IR

Las características principales de las cuatro actividades de este modelo son las siguientes:

"Elicitación de requisitos:

Tiene como objetivo hacer explícito el conocimiento oculto sobre las necesidades de clientes y usuarios y el sistema a desarrollar de forma que todos los participantes en el problema sean capaces de enenderlo. En este modelo se asume que durante la realización de las actividades de elicitación es necesario identificar a las fuentes de información, conocer lo mejor posible el dominio del problema, reutilizar especificaciones de requisitos similares y utilizar técnicas: entrevistas, casos de uso, etc.

Negociación de requisitos:

Tiene como objetivo alcanzar acuerdos entre todos los participantes sobre los requisitos elicitados en la actividad anterior, avanzando en la dimensión de acuerdo del proceso. Para ello se proponen cuatro factores:

• Evitar los conflictos emocionales entre los participantes, de forma que quede claro qué es lo que se negocia y que dicha negociación no se vea afectada por motivos personales.

• Hacer explícitos para cada conflicto las alternativas, las argumentaciones y las razones subyacentes que los provocan, de forma que la negociación pueda basarse en las raíces del conflicto.

• Asegurarse de que se toman las decisiones correctas, de forma que la mayoría de los participantes estén de acuerdo en los resultados de la negociación .

Especificación/Documentación de requisitos:

en esta actividad se deben documentar los requisitos elicitados y negociados, se propone que no se utilice una sola notación sino tantas como sea necesario para que todos los participantes los entiendan.

Validación/ Verificación de requisitos:

Comprobar que los requisitos documentados corresponden con las necesidades de los clientes y usuarios(validación), y comprobar que la especificación cumple los criterios de calidad oportunos(verificación), haciendo avanzar el proceso en las tres dimensiones descritas." (The Three dimensions of requirements engineering: A framework and its application., 1997)

Modelo Espiral

Representado gráficamente en la figura, está basado en el modelo espiral de Bohem para l ingeniería de requisitos y en el modelo de Potts, en él se asume una naturaleza iterativa del proceso y la dificultad de establecer un punto de terminación del mismo, dado que los requisitos nunca llegarán a ser perfectos. A parte de las tres actividades que se describen a continuación, el modelo asume que existe na cuarta, la gestión de requisitos, que se realiza durante todo el proceso y que se encarga de gestionar la obtención incremental de los requisitos y los inevitables cambios a los que están sujetos.

Fig. Modelo Espiral de procesos de IR

Elicitación de requisitos

Distintas fuentes de información como clientes, usuarios, expertos, etc. son consultadas para entender el dominio y establecer los requisitos del sistema a desarrollar. Los requisitos elicitados puede que no sean completos y pueden estar expresados de forma vaga o no estructurada.

Análisis y validación de requisitos

Los requisitos elicitados se integran y analizan, lo que suele provocar la identificación de requisitos que faltan, inconsistencias y conflictos entre los mismos. Aunque a esta actividad en el nombre tiene en cuenta la validación, no se hace referencia en la misma a ningún tipo de actividad relacionada.

Negociación de requisitos:

Los conflictos identificados durante el análisis deben resolverse llegando a acuerdos entre los participantes en el proceso, para lo que suele ser necesario elicitar nueva información.

El modelo Swebok

El proyecto Swebok(Software Engineering Body of Knowledge) es un proyecto para producir un cuerpo de conocimiento sobre ingeniería de software que siente las bases como una profesión. Dentro de las diez áreas de conocimiento que han establecido, la novena corresponde a la ingeniería de requisitos, dentro de la misma se propone el modelo de procesos que sigue a continuación.

Fig. Modelo de procesos para la IR de Swebok

Elicitación de requisitos

Se considera como la primera que es necesario realizar para lograr entender los problemas que hay que resolver. Para realizarla con cierta garantía es necesario tener en cuenta los siguientes puntos:

Los objetivos: pueden considerarse como los requisitos de alto nivel que deberá cumplir el sistema a desarrollar.

Conocimiento del dominio: es fundamental conocer el dominio del problema para facilitar la comunicación y poder inferir el conocimiento tácito que los participantes no suelen hacer explícito.

Participantes: Es preciso identificar a todos los participantes que tengan algún tipo de interés en el desarrollo y tener en cuenta los puntos de vista de los distintos grupos.

Entorno operacional: el sistema a desarrollar deberá funcionar en un entorno que es necesario conocer para poder identificar las necesidades de interoperabilidad con otros sistemas ya existentes.

Entorno organizacional: es necesario conocerlo para evitar que surjan problemas con los procesos de negocio.

Para la realización de esta actividad se sugieren técnicas conocidas como las entrevistas, la observación, entre otras.

Análisis y negociación de requisitos:

Se pretende detectar y resolver los conflictos entre los requisitos, determinar los límites del sistema y cómo interactuará con su entorno y transformar los requisitos de usuario en requisitos de software. En esta actividad se propone que se clasifiquen los requisitos, se realicen modelos conceptuales y se negocien los conflictos detectados.

Documentación de requisitos:

Los documentos de requisitos son el medio habitual para el registro y la comunicación de los requisitos.

Validación de requisitos: se debe comprobar los documentos de requisitos para detectar omisiones, conflictos y ambigüedades no detectadas en el análisis y también se debe comprobar que los requisitos siguen las normas de calidad establecidas, se decir, se combinan validación y verificación en una sola actividad.

Conclusiones

Con este trabajo se prevee un perfeccionamiento en el Modelo de Desarrollo de requisitos en Líneas de productos SCADA, con el mismo se obtendrán mejoras en cuanto a defectos en lo requisitos y en todo el proceso de administración de estos.

Autor:

Ing. Belkis Grissel González Rodriguez

Tutor:

MSc. Karina Pérez Teruel

2010