DISEÑO DE SOFTWARE E INTRODUCCIÓN A LOS PATRONES DE DISEÑO

CUCAITA PINZON CIELO ANDREA

GUERRERO MARTINEZ YESSICA ALEJANDRA
RODRIGUEZ MEDINA CHRISTIAN
INGENIERÍA DE SOFTWARE I 501
JULIAN SALINAS

UNIVERSIDAD DE CUNDINAMARCA
INGENIERÍA DE SISTEMAS
FUSAGASUGA CUNDINAMARCA
ABRIL 24 DE 2017
INTRODUCCIÓN
En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos o
Ingeniería de requerimientos que 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 las partes
interesadas, que pueden entrar en conflicto entre ellos.

La etapa de Análisis de Requerimientos, es la primera etapa en el desarrollo de un

SI. Comienza después de que el Cliente ha detectado una ausencia, falla o falta de
oportunidad de la información o simplemente, luego que la organización ha
determinado un cambio en sus políticas, reglas o tecnologías a aplicar.

En esta etapa, deberemos responder a una pregunta fundamental: ¿Qué es lo que

quiere el Cliente? y para ello, deberemos diagnosticar la Situación Actual, recopilar
los requerimientos del Cliente, tanto en relación al Sistema, como generales
respecto del área Informática, es decir la Situación Ideal, para así poder definir
Alternativas de Solución, según las cuales podremos avanzar desde lo que hoy se
posee, hacia el punto que se pretende llegar.

Como parte de nuestro trabajo, deberemos señalar cuál de las alternativas, es a

nuestro juicio la más conveniente (y justificarlo) en la Propuesta. Hecho lo anterior,
el Cliente evaluará nuestro trabajo, y si decide contratarnos, deberemos establecer
un Contrato que nos asegure a ambas partes (cliente y desarrollador) una claridad
respecto de qué, cómo, cuándo y bajo qué condiciones trabajaremos en conjunto.

MARCO TEÓRICO
La ingeniería de requisitos del software es un proceso de descubrimiento,
refinamiento, modelado y especificación. Se refinan en detalle los requisitos del
sistema y el papel asignado al software.
Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de
requisitos – un conjunto de actividades que son denominadas análisis – El cliente
intenta replantear un sistema confuso, a nivel de descripción de datos, funciones y
comportamiento, en detalles concretos. El desarrollador actúa como interrogador,
como consultor, como persona que resuelve problemas y como negociador.
El análisis y la especificación de requisitos pueden parecer una tarea relativamente
sencilla, pero las apariencias engañan. El contenido de comunicación es muy
denso. Abundan las ocasiones para malas interpretaciones o falta de información.
Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero de
software puede entenderse muy bien repitiendo la famosa frase de un cliente
anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de
que se dé cuenta de que lo que escuchó no es lo que yo quise decir”.
El análisis de requisitos es una tarea de ingeniería del software que cubre el hueco
entre la definición del software a nivel sistema y el diseño de software. El análisis de
requerimientos permite al ingeniero de sistemas especificar las características
operacionales del software (función, datos y rendimientos), indica la interfaz del
software con otros elementos del sistema y establece las restricciones que debe
cumplir el software.

IMPLICACIONES

La Ingeniería de Requisitos implica todas las actividades del ciclo de vida dedicadas
a:
 La educción (a veces llamada "elicitación", debido a una mala traducción de
"elicitation") de los requisitos de usuario.
 El análisis y negociación de requisitos para derivar requisitos adicionales.
 La documentación de los requisitos como especificación.
 La validación de los requisitos documentados contra las necesidades de
usuario.
 Así como los procesos que apoyan estas actividades.

Fases de implementación
Desde un punto de vista conceptual, las actividades son de cinco clases.
 Obtener requisitos: a través de entrevistas o comunicación con clientes o
futuros usuarios, para saber cuáles son sus expectativas.
 Analizar requisitos: detectar y corregir las carencias o falencias
comunicativas, transformando los requisitos obtenidos de entrevistas y
requisitos, en condiciones apropiadas para ser tratados en el diseño.
  Documentar requisitos: igual que todas las etapas, los requisitos deben
estar debidamente documentados.
 Verificar los requisitos: consiste en comprobar la implementación de los
requisitos.

Técnicas principales
La ingeniería de requisitos puede ser un proceso largo y arduo para el que se
requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las
relaciones entre la gente, así que es importante identificar a todos los actores
involucrados, considerar sus necesidades y asegurar que entienden las
implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas
para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas
tales como las entrevistas, o talleres con grupos para crear listas de requisitos.
Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando
sea necesario, el analista emplea una combinación de estos métodos para
establecer los requisitos exactos de las personas implicadas, para producir un
sistema que resuelva las necesidades del negocio.
 Validar los requisitos: comprobar que los requisitos implementados sean
funcionales para lo que inicialmente se construyó el producto.

 Entrevistas
Las entrevistas son un método común. Por lo general no se entrevista a toda la
gente que se relaciona con el sistema, sino a una selección de personas que
represente a todos los sectores críticos de la organización, con el énfasis puesto en
los sectores más afectados o que harán un uso más frecuente del nuevo sistema.

 Talleres
Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las
personas implicadas individuales y que a menudo no se descubren en las
entrevistas o quedan completamente definidas durante la misma. Estas
implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado,
talleres facilitados por un analista del negocio, en donde las personas implicadas
participan en discusiones para descubrir requisitos, analizan sus detalles y las
implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la
documentación de la discusión, liberando al analista del negocio para centrarse en
el proceso de la definición de los requisitos y para dirigir la discusión.

 Forma de contrato
En lugar de una entrevista, se pueden llenar formularios o contratos indicando los
requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.

 Objetivos medibles
Los requisitos formulados por los usuarios se toman como objetivos generales, a
largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista
del sistema hasta determinar los objetivos críticos del funcionamiento interno que
luego darán forma a los comportamientos apreciables por el usuario.

 Prototipos y Casos de uso

Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el
producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y
rectificar algunos aspectos antes de llegar al producto terminado.

Un caso de uso es una técnica para documentar posibles requisitos, graficando la

relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema
aparece como una caja negra, y sólo se representa su interacción con entidades
externas, permite omitir dichos aspectos y determinar los que realmente
corresponden a las entidades externas. El objetivo de esta práctica es mejorar la
comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana
de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes
finales. Esta técnica se enfrenta a los siguientes peligros potenciales.
 A los directivos, una vez que ven un prototipo, les cuesta comprender que
queda mucho trabajo por hacer para completar el diseño final.
 Los diseñadores tienden a reutilizar el código de los prototipos por temor a
“perder el tiempo” al comenzar otra vez.
 Los prototipos ayudan principalmente a las decisiones del diseño y de la
interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son
los requisitos.
 Los diseñadores y los usuarios finales pueden centrarse demasiado en el
diseño de la interfaz de usuario y demasiado poco en producir un sistema
que sirva el proceso del negocio.
Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades
sintetizadas. Los diagramas, en los casos donde se espera que el software final
tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos
y a menudo elimina todo el color del diseño del software (es decir utilizar una gama
de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la
aplicación.

Especificación de requisitos del software

Una especificación de requisitos del software es una descripción completa del
comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que
describen todas las interacciones que se prevén que los usuarios tendrán con el
software. También contiene requisitos no funcionales (o suplementarios). Los
requisitos no funcionales son los requisitos que imponen restricciones al diseño o
funcionamiento del sistema (tal como requisitos de funcionamiento, estándares de
calidad, o requisitos del diseño).
Las estrategias recomendadas para la especificación de los requisitos del software
están descritas por IEEE 830-1998. Este estándar describe las estructuras posibles,
contenido deseable, y calidades de una especificación de requisitos del software.
Los requisitos se dividen en tres:
 Funcionales: son los que el usuario necesita que efectúe el software.
Normalmente se identifican como los requisitos que responden a la pregunta
¿qué hace? e.g. El sistema debe emitir un comprobante al asentar la entrega
de mercadería.
 No funcionales: son los "recursos" para que trabaje el sistema de información
(redes, tecnología). Ej: el soporte de almacenamiento a usar debe ser
MySQL. Normalmente se identifican como los requisitos que responden a la
pregunta ¿cómo lo hace? e.g. rápido, fácil etc.
 Empresariales u Organizacionales: son el marco contextual en el cual se
implantará el sistema para conseguir un objetivo macro. Ej: abaratar costos
de expedición.

Identificación de las personas involucradas

Debido a que los cambios que introduce un sistema nuevo tienden a afectar a más
de un tipo de usuario, los analistas de requisitos han de tomar en consideración a
todos los implicados para que se obtengan y depuren sus requisitos de la forma más
fidedigna posible. Entre las personas implicadas hay que considerar:
 Organizaciones que integran la organización del analista que está diseñando
el sistema
 Organizaciones o sistemas de respaldo
 Dirección
 Usuarios.

Problemas

Relacionados con las personas involucradas

Las vías que pueden dificultar la determinación de los requisitos son:
 Los usuarios no tienen claro lo que desean
 Los usuarios no se involucran en la elaboración de requisitos escritos
 Los usuarios insisten en nuevos requisitos después de que el coste y la
programación se hayan fijado.
 La comunicación con los usuarios es lenta
 Los usuarios no participan en revisiones o son incapaces de hacerlo.
 Los usuarios no comprenden los problemas técnicos
 Los usuarios no entienden el proceso del desarrollo
Esto puede conducir a la situación donde las exigencias del consumidor cambian,
incluso cuando el desarrollo del producto ya está en marcha.

Relacionados con los analistas

La correcta redacción de las Especificaciones de requisitos del Software es
imprescindible para el correcto desarrollo del proyecto. Por ello, en su redacción hay
que evitar:
 Uso de terminología ambigua en la redacción de los documentos de
requisitos
 Sobre Especificación de los requisitos
 Escritura poco legible, voz pasiva, abuso de negaciones
 Uso de verbos en condicional, expresiones subjetivas
 Ausencia de términos y verbos del dominio de la aplicación

Relacionados con los desarrolladores

Los problemas posibles causados por los desarrolladores durante análisis de
requisitos son:
 El personal técnico y los usuarios finales pueden tener diversos vocabularios
y pueden llegar a creer incorrectamente que están de acuerdo, no dándose
cuenta del desacuerdo hasta que se provee el producto final.
 Los desarrolladores pueden intentar encajar el sistema en un modelo
existente, en vez de desarrollar un sistema adaptado a las necesidades del
cliente.
 El análisis de requisitos se puede realizar a menudo por los ingenieros o
programadores, en vez de personal con las habilidades de relación con la
gente y el conocimiento apropiados para entender las necesidades de un
cliente correctamente.

tomado de:
https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos