resumen referente a la ingenieria de sistemas

1. Ingeniería de Requisitos
La ingeniería de requisitos es una condición o necesidad de un usuario
para resolver un problema o alcanzar un objetivo.
Comprende todas las tareas relacionadas con la determinación de las
necesidades o de las condiciones a satisfacer para un software nuevo o
modificado, tomando en cuenta los diversos requisitos de los inversores, que
pueden entrar en conflicto entre ellos.
El propósito de la ingeniería de requisitos es hacer que los mismos
alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los
buenos requisitos deben ser medibles, comprobables, sin ambigüedades o
contradicciones.
Los requerimientos puedes dividirse en requerimientos funcionales y
requerimientos no funcionales.
Los requerimientos funcionales definen las funciones que el sistema será
capaz de realizar. Describen las transformaciones que el sistema realiza sobre las
entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con características que
de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento
(en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.
Definición de Requisitos
El objetivo de la fase de definición de requisitos (también se le suele denominar
de «especificación» de requisitos) es obtener una clara comprensión del problema
a resolver, extraer las necesidades del usuario y derivar de ellas las funciones que
debe realizar el sistema.

2. Características de los Requerimientos
Las características de un requerimiento son sus propiedades principales.
Un conjunto de requerimientos en estado de madurez, deben presentar una serie
de características tanto individualmente como en grupo. A continuación se
presentan las más importantes.
Necesario: Un requerimiento es necesario si su omisión provoca una
deficiencia en el sistema a construir, y además su capacidad, características físicas
o factor de calidad no pueden ser reemplazados por otras capacidades del
producto o del proceso.
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su
redacción debe ser simple y clara para aquellos que vayan a consultarlo en un
futuro.
Completo: Un requerimiento está completo si no necesita ampliar detalles
en su redacción, es decir, si se proporciona la información suficiente para su
comprensión.
Consistente: Un requerimiento es consistente si no es contradictorio con
otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretación. El lenguaje usado en su definición, no debe causar confusiones al
lector.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado
de manera que permita hacer uso de los siguientes métodos de verificación:
inspección, análisis, demostración o pruebas.

3. Actividades de la Ingeniería de Requerimientos
En el proceso de IR son esenciales diversas actividades. En este
documento serán presentadas secuencialmente, sin embargo, en un proceso de
ingeniería de requerimientos efectivo, estas actividades son aplicadas de manera
continua y en orden variado.
Dependiendo del tamaño del proyecto y del modelo de proceso de
software utilizado para el ciclo de desarrollo, las actividades de la IR varían tanto
en número como en nombres. La tabla #1 muestra algunos ejemplos de las
actividades identificadas para cada proceso.
A pesar de las diferentes interpretaciones que cada desarrollador tenga
sobre el conjunto de actividades mostradas en la tabla anterior, podemos
identificar y extraer cinco actividades principales que son:
Análisis del Problema
Evaluación y Negociación
Especificación
Validación
Evolución

4. Tabla 1. Actividades de la IR para diferentes modelos de procesos de Ingeniería de Software
MODELO Oliver and Steiner EIA / IS-632 IEEE Std 1220- CMM nivel RUP
1996 1994 Repetitivo (2)
Actividades Evaluar la Análisis de Análisis de Identificación de Análisis del
información requerimientos Requerimientos requerimientos Problema
disponible
Definir métricas Análisis funcional Estudio de los Identificación de Comprender las
efectivas requerimientos restricciones del necesidades de
sistema a desarrollar los involucrados
Crear un modelo del Síntesis Validación de Análisis de los Definir el sistema
comportamiento del requerimientos requerimientos
sistema
Crear un modelo de Análisis y control Análisis funcional Representación de Analizar el
los objetos del sistema los requerimientos alcance del
proyecto
Ejecutar el análisis Evaluación y Comunicación de Modificar la
estudio de funciones los requerimientos definición del

5. sistema
Crear un plan Verificación de Validación de Administrar los
secuencial de funciones requerimientos cambios de
construcción y requerimientos
pruebas
Síntesis
Estudio y
evaluación del
diseño
Verificación física
Control

6. A continuación se explicará cada una de ellas, presentándolas en el orden
en que deben ser aplicadas para un nuevo proyecto.
Análisis del Problema
El objetivo de esta actividad es entender las verdaderas necesidades del
negocio.
Antes de describir qué pasos deben cumplirse en esta actividad, debemos
tener una definición clara del término "Problema".
"Un problema puede ser definido como la diferencia entre las cosas como
se perciben y las cosas como se desean”. Aquí vemos nuevamente la importancia
que tiene una buena comunicación entre desarrolladores y clientes; de esta
comunicación con el cliente depende que entendamos sus necesidades.
A través de la definición de problema, podemos ver entonces que la
actividad de "Análisis del Problema" tiene por objetivo que se comprendan los
problemas del negocio, se evalúen las necesidades iniciales de todos los
involucrados en el proyecto y que se proponga una solución de alto nivel para
resolverlo.
Durante el análisis del problema, se realizan una serie de pasos para
garantizar un acuerdo entre los involucrados, basados en los problemas reales del
negocio.
Estos pasos son los siguientes:
Comprender el problema que se está resolviendo: Es importante
determinar quién tiene el problema realmente, considerar dicho problema desde
una variedad de perspectivas y explorar muchas soluciones desde diferentes
puntos de vista. Veamos la siguiente necesidad: "El cliente se queja mucho por la
enorme fila que debe formar para realizar una transacción bancaria".

7. Perspectiva del cliente = Pérdida de tiempo
Perspectiva del banco = Posibles pérdidas de clientes
Posibles soluciones pueden ser, determinar por qué demoran los cajeros,
colocar una nueva caja (implica contratación de nuevos cajeros), abrir una nueva
sucursal (involucra personal nuevo y estudio de mercado), realizar transacciones
por otros medios (teléfono, internet, mediante cajeros automáticos, autobancos).
Como puede verse, múltiples soluciones aplican para el mismo problema,
sin embargo, sólo una de ellas será la más factible. Las soluciones iniciales, deben
ser definidas tomando en cuenta tanto la perspectiva técnica como la del negocio.
Evaluación y negociación de los requerimientos
La diversa gama de fuentes de las cuales provienen los requerimientos,
hacen necesaria una evaluación de los mismos antes de definir si son adecuados
para el cliente. El término "adecuado" significa que ha sido percibido a un nivel
aceptable de riesgo tomando en cuenta las factibilidades técnicas y económicas, a
la vez que se buscan resultados completos, correctos y sin ambigüedades.
En esta etapa se pretende limitar las expectativas del cliente
apropiadamente, tomando como referencia los niveles de abstracción y
descomposición de cada problema presentado.
Especificación de Requisitos de Software (SRS)
La especificación de requisitos de software es la actividad en la cual se
genera el documento, con el mismo nombre, que contiene una descripción
completa de las necesidades y funcionalidades del sistema que será desarrollado;
describe el alcance del sistema y la forma en cómo hará sus funciones, definiendo
los requerimientos funcionales y los no funcionales.

8. En la SRS se definen todos los requerimientos de hardware y software,
diagramas, modelos de sistemas y cualquier otra información que sirva de soporte
y guía para fases posteriores.
Es importante destacar que la especificación de requisitos es el resultado
final de las actividades de análisis y evaluación de requerimientos; este
documento resultante será utilizado como fuente básica de comunicación entre los
clientes, usuarios finales, analistas de sistema, personal de pruebas, y todo aquel
involucrado en la implementación del sistema.
Los clientes y usuarios utilizan la SRS para comparar si lo que se está
proponiendo, coincide con las necesidades de la empresa. Los analistas y
programadores la utilizan para determinar el producto que debe desarrollarse. El
personal de pruebas elaborará las pruebas funcionales y de sistemas en base a este
documento. Para el administrador del proyecto sirve como referencia y control de
la evolución del sistema.
La SRS posee las mismas características de los requerimientos: completa,
consistente, verificable, no ambigua, factible, modificable, rastreable, precisa,
entre otras. Para que cada característica de la SRS sea considerada, cada uno de
los requerimientos debe cumplirlas; por ejemplo, para que una SRS se considere
verificable, cada requerimiento definido en ella debe ser verificable; para que una
SRS se considere modificable, cada requerimiento debe ser modificable y así
sucesivamente. Las características de la SRS son verificadas en la actividad de
Validación.
Validación de Requisitos
La validación es la actividad de la IR que permite demostrar que los
requerimientos definidos en el sistema son los que realmente quiere el cliente;
además revisa que no se haya omitido ninguno, que no sean ambiguos,
inconsistentes o redundantes.

9. En este punto es necesario recordar que la SRS debe estar libre de errores,
por lo tanto, la validación garantiza que todos los requerimientos presentes en el
documento de especificación sigan los estándares de calidad.
No debe confundirse la actividad de evaluación de requerimientos con la
validación de requerimientos. La evaluación verifica las propiedades de cada
requerimiento, mientras que la validación revisa el cumplimiento de las
características de la especificación de requisitos.
Durante la actividad de validación pueden hacerse preguntas en base a
cada una de las características que se desean revisar. A continuación se presentan
varios ejemplos:
¿Están incluidas todas las funciones requeridas por el cliente? (completa)
¿Existen conflictos en los requerimientos? (consistencia)
¿Tiene alguno de los requerimientos más de una interpretación? (no
ambigua)
¿Está cada requerimiento claramente representado? (entendible)
¿Pueden los requerimientos ser implementados con la tecnología y el
presupuesto disponible? (factible)
¿Está la SRS escrita en un lenguaje apropiado? (clara)
¿Existe facilidad para hacer cambios en los requerimientos? (modificable)
¿Está claramente definido el origen de cada requisito? (rastreable)
¿Pueden los requerimientos ser sometidos a medidas cuantitativas?
(verificable)
La validación de requerimientos es importante pues de ella depende que no
existan elevados costos de mantenimiento para el software desarrollado.

10. Evolución de los requerimientos
Los requerimientos son una manera de comprender mejor el desarrollo de
las necesidades de los usuarios y cómo los objetivos de la organización pueden
cambiar, por lo tanto,
Es esencial planear posibles cambios a los requerimientos cuando el
sistema sea desarrollado y utilizado. La actividad de evolución es un proceso
externoque ocurre a lo largo del ciclo de vida del proyecto.
Los requerimientos cambian por diferentes razones. Las más frecuentes
son:
Porque al analizar el problema, no se hacen las preguntas correctas a las
personas correctas.
Porque cambió el problema que se estaba resolviendo.
Porque los usuarios cambiaron su forma de pensar o sus percepciones.
Porque cambió el ambiente de negocios.
Porque cambió el mercado en el cual se desenvuelve el negocio.
Cambios a los requisitos involucra modificar el tiempo en el que se va a
implementar una característica en particular, modificación que a la vez puede
tener impacto en otros requerimientos. Por esto, la administración de cambios
involucra actividades como establecer políticas, guardar históricos de cada
requerimiento, identificar dependencias entre ellos y mantener un control de
versiones.
Tener versiones de los requerimientos es tan importante como tener
versiones del código, ya que evita tener requerimientos emparchados en un
proyecto.
Entre algunos de los beneficios que proporciona el control de versiones
están:

11. Prevenir cambios no autorizados.
Guardar revisiones de los documentos de requerimientos.
Recuperar versiones previas de los documentos.
Administrar una estrategia de "releases".
Prevenir la modificación simultánea a los requisitos.
En vista que las peticiones de cambios provienen de muchas fuentes, las
mismas deben ser enrutadas en un solo proceso. Esto se hace con la finalidad de
evitar problemas y conseguir estabilidad en los requerimientos.
Herramientas CASE
Las herramientas CASE (Computer Aided Software Engineering,
Ingeniería de Software Asistida por Computadora) son diversas aplicaciones
informáticas destinadas a aumentar la productividad en el desarrollo de software
reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas
herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo
del software en tareas como el proceso de realizar un diseño del proyecto, cálculo
de costos, implementación de parte del código automáticamente con el diseño
dado, compilación automática, documentación o detección de errores entre otras.
Objetivos
1. Mejorar la productividad en el desarrollo y mantenimiento del software.
2. Aumentar la calidad del software.
3. Reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas
informáticos.
4. Mejorar la planificación de un proyecto
5. Aumentar la biblioteca de conocimiento informático de una empresa
ayudando a la búsqueda de soluciones para los requisitos.
6. Automatizar el desarrollo del software, la documentación, la generación de
código, las pruebas de errores y la gestión del proyecto.

12. 7. Ayuda a la reutilización del software, portabilidad y estandarización de la
documentación
8. Gestión global en todas las fases de desarrollo de software con una misma
herramienta.
9. Facilitar el uso de las distintas metodologías propias de la ingeniería del
software.
Clasificación
Aunque no es fácil y no existe una forma única de clasificarlas, las
herramientas CASE se pueden clasificar teniendo en cuenta los siguientes
parámetros:
1. Las plataformas que soportan.
2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.
3. La arquitectura de las aplicaciones que producen.
4. Su funcionalidad.
La siguiente clasificación es la más habitual basada en las fases del ciclo
de desarrollo que cubren:
Upper CASE (U-CASE), herramientas que ayudan en las fases de
planificación, análisis de requisitos y estrategia del desarrollo, usando,
entre otros diagramas UML.
Middle CASE (M-CASE), herramientas para automatizar tareas en el
análisis y diseño de la aplicación.
Lower CASE (L-CASE), herramientas que semi-automatizan la
generación de código, crean programas de detección de errores, soportan
la depuración de programas y pruebas. Además automatizan la
documentación completa de la aplicación. Aquí pueden incluirse las
herramientas de Desarrollo rápido de aplicaciones.

13. Existen otros nombres que se le dan a este tipo de herramientas, y que no
es una clasificación excluyente entre sí, ni con la anterior:
Integrated CASE (I-CASE), herramientas que engloban todo el proceso de
desarrollo software, desde análisis hasta implementación.
MetaCASE, herramientas que permiten la definición de nuestra propia
técnica de modelado, los elementos permitidos del metamodelo generado
se guardan en un repositorio y pueden ser usados por otros analistas, es
decir, es como si definiéramos nuestro propio UML, con nuestros
elementos, restricciones y relaciones posibles.
CAST (Computer-Aided Software Testing), herramientas de soporte a la
prueba de software.
IPSE (Integrated Programming Support Environment), herramientas que
soportan todo el ciclo de vida, incluyen componentes para la gestión de
proyectos y gestión de la configuración activa.
Por funcionalidad podríamos diferenciar algunas como:
Herramientas de generación semiautomática de código.
Editores UML.
Herramientas de Refactorización de código.
Herramientas de mantenimiento como los sistemas de control de
versiones·

14. INSTITUTO UNIVERSITARIO POLITECNICO
“SANTIAGO MARIÑO”
EXTENSION BARINAS
SISTEMAS II
INTEGRANTE:
PROF. YESENIA DELGADO KRISMAR DURAN C.I 20.099.921
SECCION: S6 CARLOS PAREDES C.I 19.350.099
ALDO GALLARDO C.I 19.881.947
BARINAS, NOVIEMBRE 2012