UNIVERSIDAD TCNICA DE MACHALA

FACULTAD DE INGENIERA CIVIL

CARRERA DE INGENIERA DE SISTEMAS








GUA DE ESTUDIO

INGENIERA DE SOFTWARE


QUINTO SEMESTRE


ING. J OFFRE CARTUCHE CALVA

2014

EL ORO ECUADOR



























































I
I
N
N
T
T
R
R
O
O
D
D
U
U
C
C
C
C
I
I

N
N
A
A
L
L
A
A

I
I
N
N
G
G
E
E
N
N
I
I
E
E
R
R

A
A
D
D
E
E
S
S
O
O
F
F
T
T
W
W
A
A
R
R
E
E
(
(
I
I
S
S
W
W
)
)




1. CONCEPTOS DE INGENIERA DE SOFTWARE

En este tema se realiza una introduccin a la Ingeniera del software. Se revisan conceptos
como: software, ingeniera de software, producto, proceso, actividad, tarea, paradigma,
metodologa, tcnica, herramientas, estndares, entre otros.

Principales conceptos a tener en cuenta en la ingeniera de software


El software se ha convertido en el elemento clave de la evolucin de los sistemas y
productos informticos. El software considerado como el producto se compone de
programas, datos y documentos. Cada uno de estos elementos componen una configuracin
que se crea como parte del proceso de la ingeniera del software.

Qu es la ingeniera de software? Hay diferentes autores que conceptualizan la
ingeniera de software desde sus propias perspectivas, sin embargo todos guardan relacin.
A continuacin se presentan algunos conceptos de diferentes autores:

Por ejemplo la definicin que propuso Fritz Bauer en una conferencia mundial en 1968: La
ingeniera de software es el establecimiento y uso de principios de la ingeniera para obtener
econmicamente un software confiable y que funcione eficiente en mquinas reales

Ingeniera del Software es la aplicacin practica del conocimiento cientfico en el diseo y
construccin de programas de computadora y la documentacin necesaria requerida para
desarrollar, operar (funcionar) y mantenerlos (Bohem, 1976).

Disciplina para producir software de calidad desarrollado sobre las agendas y costes
previstos y satisfaciendo los requisitos (S. Schach 1990, Software Engineering).

M M t to od do o
T T c cn ni ic ca a
Proceso a seguir para resolver una situacin o
problema con un orden y objetivos establecidos.
Proceso {actividades} {tareas}
Estrategia para desarrollar una actividad de un
mtodo
M Me et to od do ol lo og g a a Mtodo + tcnicas + soporte documental
H He er rr ra am mi ie en nt ta a Soporte automatizado, Ejm. CASE, CARE
P Pr ro od du uc ct to o
Resultado de cada etapa o actividad, denominado
tambin entregable


Ingeniera al software es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable
al desarrollo, operacin (funcionamiento) y mantenimiento del software (IEEE, 1993).

La ingeniera de software es una disciplina que integra al proceso, los mtodos y las
herramientas para el desarrollo del software de computadora. Se ha propuesto un gran
nmero de modelos para la ingeniera de software, pero todos definen un conjunto de
actividades del marco de trabajo, una coleccin de tareas conducidas para realizar cada
actividad, productos de trabajo generados como consecuencia de las tareas y un conjunto de
actividades de soporte que acompaan el proceso entero.

Un objetivo de dcadas ha sido el encontrar procesos o metodologas predecibles y
repetibles que mejoren la productividad y la calidad. Los modelos prescriptitos (paradigmas
o ciclos de vida) del proceso de software se han aplicado durante muchos aos en un
esfuerzo encaminado a ordenar y estructurar el desarrollo del software. Cada uno de estos
modelos convencionales sugiere un flujo de proceso o ciclo de vida que de alguna forma es
diferente, pero todos realizan un conjunto de actividades genricas del marco de trabajo:
comunicacin, planeacin, modelado, construccin y despliegue.

2. ACTIVIDADES GENRICAS DE LA INGENIERA DE SOFTWARE

Comunicacin
Esta actividad del marco de trabajo implica una intensa colaboracin y comunicacin con los
clientes; adems abarca la investigacin de requisitos y otras actividades relacionadas.

Planeacin
Esta actividad establece un plan para el trabajo de la ingeniera del software. Describe las
tareas tcnicas que deben realizarse, los riesgos probables, los recursos que sern
requeridos, los productos del trabajo que han de producirse y un programa de trabajo.

Modelado
Esta actividad abarca la creacin de modelos que permiten al desarrollador y al cliente
entender mejor los requisitos del software y el diseo que lograr satisfacerlos.

Construccin
Esta actividad combina la generacin del cdigo y la realizacin de pruebas necesarias para
descubrir errores en el cdigo.

Despliegue
El software (como una entidad completa o un incremento completado de manera parcial) se
entrega al cliente, quin evala el producto recibido y proporciona informacin basada en su
evaluacin.

Segn el estndar ISO 12207, los procesos de la ingeniera de software se organizan en:
proceso primario (Actividades: adquisicin, suministro, desarrollo, operacin y
mantenimiento), proceso de soporte (Actividades: documentacin, gestin de la
configuracin, control de calidad, verificacin, validacin, reuniones, auditora, resolucin de
problemas) y proceso organizacional (Actividades: gestin, infraestructura, mejora y
formacin). Tambin, se identifican como actividades genricas del la ingeniera del software
a las siguientes:




3. MODELOS (PARADIGMAS O CICLOS DE VIDA) DE LA INGENIERA DEL SOFTWARE

La ingeniera de software tiene varios modelos considerados tambin paradigmas o ciclos de
vida de desarrollo en los cuales se puede apoyar para la realizacin de software, de los
cuales podemos destacar algunos por ser los ms utilizados y los ms completos: el modelo
de cascada o ciclo de vida clsico, los modelos incrementales, el DRA (Desarrollo Rpido de
Apicaciones), los procesos evolutivos como la construccin de prototipos y el espiral, el
modelo basado en componentes, los mtodos formales (CMM, CMMI), el orientado a
aspectos, el proceso unificado UML, los mtodos giles.

4. EVOLUCIN DE LA INGENIERA DE SOFTWARE

La ingeniera de software es una disciplina muy joven, a finales de la dcada de los 60
comenzaron a establecer algunos principios bsicos, sin embargo se ha producido una
preocupante crisis del software de la cual an no se logra salir. A continuacin se presenta
una breve evolucin:
(< 1968)
Dominios sencillos
El software era diseado a medida
Carencia de mtodos sistemticos
La programacin del software se consideraba como un arte.
(1968)
Fritz Bauer, utiliza por primera vez el trmino Ingeniera del Software, en la 1era.
Conferencia sobre desarrollo de software patrocinada por el Comit de Ciencia de la
OTAN celebrada en Garmisch, Alemania.
(>1968)
Dominios complejos
Aplicaciones variadas y complejas
Separacin desarrollador cliente
Exigencias de calidad
Desarrollo en grupos
Crisis del software
Se evidencia una preocupacin de las universidades y organismos de estandarizacin
(SEI, IEEE, ISO) por el desarrollo de estndares, metodologas, tcnicas y
herramientas para la ingeniera de software.

5. CRISIS DEL SOFTWARE

El trmino crisis del software se acu en 1968, en la primera conferencia organizada por la
OTAN sobre desarrollo de software.

La crisis del software es el hecho de que el software que se construye no solamente no
satisface los requerimientos ni las necesidades pedidos por el cliente, sino que adems
excede los presupuestos y los horarios de tiempos. La industria del software no ha podido
satisfacer la demanda. La complejidad del software producido y demandado se incrementa
constantemente. El software es solicitado para ejecutar las tareas demandantes de hoy y
est presente en todos los sistemas que van desde los ms sencillos hasta los de misin
crtica. Las aplicaciones de software son complejas porque modelan la complejidad del


mundo real. En estos das, las aplicaciones tpicas son muy grandes y complejas para que
un individuo las entienda y, por ello, lleva gran tiempo implementar software.

A continuacin se citan algunas causas de la crisis del software:
Imprecisin en la planificacin del proyecto y estimacin de los costos.
Baja calidad del software.
Dificultad de mantenimiento de programas con un diseo poco estructurado, etc.
Por otra parte se exige que el software sea eficaz y barato tanto en el desarrollo como en
la compra.
Tambin se requiere una serie de caractersticas como fiabilidad, facilidad de
mantenimiento y de uso, eficiencia, etc



Comparativa de proyectos para el desarrollo de sistemas de software





6. PRINCIPALES ORGANIZACIONES DE ESTANDARIZACIN DE LA INGENIERA DE
SOFTWARE

Desde la identificacin del fenmeno crisis del software, han sido muchas las
organizaciones que han abordado, con mayor o menor rigor, el anlisis de problemas en el
desarrollo de sistemas de software. Sus trabajos se han encaminado a la localizacin de las
causas; y a la exposicin en textos didcticos, normativos o estndares de procesos o
prcticas necesarias para abordar el desarrollo, mantenimiento y operacin con las mayores
garantas de xito.

Han sido muchos los departamentos de universidades, organismos de normalizacin o
investigacin nacionales o internacionales, sociedades de profesionales, departamentos de
Proyecto no terminado, nunca se llega a utilizar
Desbordamiento de agendas o costes. Las funcionalidades no cubren las
expectativas. Problemas funcionales
Proyecto realizado en el tiempo previsto, con los costes previstos, con la
funcionalidad esperada y ofreciendo un funcionamiento correcto.
2000
1998
1995
1994
28% 23% 49%
26% 28% 46%
27% 40% 33%
16% 31% 53%
xito Problemtico Fracaso
2004
29% 19% 53%
Fuente: Standish Group Survey (http://www.standishgroup.com/)


defensa, departamentos de calidad y procesos de empresas los que han ido generando
normas y estndares.

Se considera como entidades de mayor reconocimiento internacional, por sus trabajos y
esfuerzos realizados para la normalizacin, y reconocimiento de la Ingeniera del software a:
ISO, SEI e IEEE- Computer Society.

ISO. Organizacin Internacional para la Estandarizacin, fundada en 1947.

Son miembros 87 pases. En 1987 la Organizacin
Internacional para la Estandarizacin (ISO) y la Comisin
Internacional Electrotcnica (IEC), establecieron un Comit
Internacional (JTC1) para las Tecnologas de la Informacin.
La misin del JTC1 es la estandarizacin en el campo de los
sistemas de tecnologas de la informacin, incluyendo microprocesadores y equipos.

Los estndares o instrucciones tcnicas ms importantes para la Ingeniera del Software:
ISO/IEC 12207
ISO/IEC TR 15504

SEI. Instituto de Ingeniera del software. (SEI http://www.sei.cmu.edu/). Integrado en la
Universidad Carnegie Mellon.

La aportacin ms significativa de este Instituto son
los modelos de madurez de las capacidades: CMM
y CMMI; que en sus casi 15 aos de implantacin
efectiva en entornos de produccin de software han
demostrado su efectividad en las dos finalidades que cubren: como marco de referencia para
mejora de procesos, y como criterio de evaluacin para determinar la madurez, y por tanto
fiabilidad de resultados previsibles de una organizacin de software.

IEEE Computer Society

IEEE Es el Instituto de Ingenieros en Electricidad y Electrnica (Institute of Electrical and
Electronics Engineers).


Su misin es preservar, investigar y promover la informacin de las
tecnologas elctricas y electrnicas.

Surgi en 1963 con la fusin del AIEE (Instituto Americano de
Ingenieros Elctricos) y el Instituto de Ingenieros de Radio (IRE).

La IEEE Computer Society (www.computer.org) es una sociedad integrada en IEEE, formada
en la actualidad por ms de 100.000 miembros en todo el mundo.
Su finalidad es avanzar en la teora, prctica y aplicacin de las tecnologas de la
informacin. Realiza conferencias, publicaciones, cursos de formacin, y desarrolla
estndares.



IEEE ha desarrollado estndares para todas las reas de Ingeniera del Software. Algunos
de ellos, correspondientes a las principales reas especficas de la Ingeniera del Software
son:
IEEE Std. 830 Prcticas recomendadas para las especificaciones de software.
IEEE Std. 1362 Gua para la especificacin del documento de requisitos ConOps
IEEE Std. 1063 Estndar para la documentacin de usuario de software.
IEEE Std. 1012 Estndar para la verificacin y validacin de software.
IEEE Std. 1219 Estndar para el mantenimiento del software



7. PRINCIPALES ESTNDARES Y MODELOS DE LA INGENIERA DE SOFTWARE





Los estndares son tiles porque:
Agrupan lo mejor y ms apropiado de las buenas prcticas y usos del desarrollo de
software.
Engloban los conocimientos.
Proporcionan un marco para implementar procedimientos de aseguramiento de la
calidad.
Proporcionan continuidad y entendimiento entre el trabajo de personas y
organizaciones distintas.





Definirse a s misma: Cules son las reas de conocimiento que la comprenden?
Definir los procesos que intervienen en el desarrollo, mantenimiento y operacin del
software
De las mejores prcticas, extraer modelos de cmo ejecutar esos procesos para evitar los
problemas de la crisis del software
Definir estndares menores para dibujar criterios unificadores en requisitos, pruebas,
gestin de la configuracin, etc.
SWEBOK: Software Engineering Body of knowledge
http://www.swebok.org

ISO/IEC 12207: Procesos del ciclo de vida del software
CMM / CMMI
ISO/IEC TR 15504
IEEE 830 - IEEE 1362 - ISO/IEC 14764
La Ingeniera del Software es una ingeniera muy joven que necesitaba:


TAREA EXTRACLASE I



1. Conteste con una (V) si es verdadero o con una (F) si es falso:
a. ( ) El producto en ingeniera de SW es considerado como el resultado de ejecutar
una actividad o tarea.
b. ( ) El proceso es un conjunto de entregables.
c. ( ) La tcnica es la estrategia que se aplica para ejecutar una actividad de un
mtodo
d. ( ) El software es considerado como el conjunto de programas.

2. Complete:

a. Con sus propias palabras defina el trmino Ingeniera de Software:
....................................................................................................................
....................................................................................................................
b. Mtodo en ingeniera de software...........................................................
....................................................................................................................
....................................................................................................................
c. Tcnicas:
....................................................................................................................
....................................................................................................................
d. CASE:
....................................................................................................................
....................................................................................................................
Principales organizaciones de estandarizacin: ....
....................................................................................................................
....................................................................................................................

Proceso: ....
....................................................................................................................
....................................................................................................................

3. Elabore un cuadro resumen de las caractersticas de los diferentes paradigmas de
desarrollo de software

4. Describa las etapas de un proceso de Ingeniera de SW Genrico


5. Describa brevemente los principales estndares de la ingeniera de software





















































I
I
N
N
G
G
E
E
N
N
I
I
E
E
R
R

A
A
D
D
E
E

R
R
E
E
Q
Q
U
U
I
I
S
S
I
I
T
T
O
O
S
S


INTRODUCCIN











Los requisitos constituyen un insumo determinante en el desarrollo del software; los
usuarios o clientes juegan un papel de proveedores de informacin y los desarrolladores
deben interactuar con ellos para la obtencin de requisitos. La fase de requisitos del
software se puede describir como un proceso ingenieril (por esta razn algunos autores lo
consideran como Ingeniera de Requisitos (IR)) que consta de una serie de actividades
que dan lugar, fundamentalmente, a una especificacin del producto software que se ha
decidido construir. En concreto todas ellas se organizarn por actividades de educcin u
obtencin de informacin, de especificacin, de validacin y de gestin.

En los ltimos aos han surgido grandes cambios en el campo de la Ingeniera de
Requisitos. As, en primer lugar, se ha establecido un reconocimiento general de la
importancia de la Ingeniera de Requisitos y de los riesgos en que se incurren si sta se
realiza de forma incorrecta o insuficiente. Actividades propias de esta rea, como la
especificacin de requisitos o la gestin de requisitos del usuario, son algunas de las
consideradas ms crticas en el desarrollo y la produccin del software.

Pero, en segundo lugar, y como consecuencia de la asuncin de esta problemtica
situacin por parte de los implicados en la industria del software, se ha llegado a introducir
explcitamente la Ingeniera de Requisitos en modelos de Mejora del Proceso Software. O,
por la misma razn, se han desarrollado guas e interpretaciones que permiten el estudio
de la conformidad de procesos y productos de la Ingeniera de Requisitos a estndares
internacionales de Calidad que buscan garantizar la satisfaccin del cliente. Este tema
trata la implicacin entre aspectos de calidad del producto final con las prcticas
relacionadas con la Ingeniera de Requisitos.




















ESQUEMA DEL TEMA II








1. CONCEPTOS DE INGENIERA DE REQUISITOS


Para que un esfuerzo de desarrollo de software tenga xito, es esencial comprender
perfectamente los requisitos del software. Independientemente de lo bien diseado o
codificado que est un programa, si se ha analizado y especificado pobremente,
decepcionar al usuario y desprestigiar al que lo ha desarrollado (Roger S. Pressman.
Ingeniera del Software Mc Graw Hill 1995).

En este tema se tratar el proceso de la Ingeniera de Requisitos y su importancia como
etapa fundamental en el desarrollo de SW. El documento de Especificacin de Requisitos
(ERS en espaol o SRS en ingls) es un producto importante que servir de base para
procesos subsiguientes de ingeniera de software como planificacin, anlisis, diseo,
construccin, pruebas y validacin con los usuarios.

Importancia de los Requisitos
Los requisitos indudablemente son importantes porque constituyen la base para los
dems procesos de desarrollo del software. Diferentes autores mencionan lo complejo de


este proceso, los posibles errores y sus repercusiones en el producto de SW y sus
usuarios.
La parte ms difcil en la construccin de sistemas software es decidir precisamente qu
construir. Ninguna otra parte del trabajo conceptual es tan ardua como establecer los
requerimientos tcnicos detallados, incluyendo todas las interfaces con humanos,
mquinas y otros sistemas software. Ninguna otra parte del trabajo puede perjudicar tanto
el resultado final si se realiza de forma errnea. Ninguna otra parte es tan difcil de
rectificar posteriormente (Frederick P. Brooks J ., 1987. Es autor del libro The mythical
Man-Month, un clsico de la Ingeniera del Software escrito en 1975 y reeditado 20 aos
despus y que an sigue vigente).

Qu porcentaje de proyectos concluyen con xito? Un estudio realizado por Standish
Group analiz el desarrollo de 8000 proyectos de software, realizados por 350 empresas
diferentes y concluy que slo el 16% de los proyectos de software se realizan con xito.

El estudio identific como principales causas de los problemas:
Falta de informacin por parte de los usuarios
Requisitos deficientes (incompletos y cambiantes)
La planificacin de agendas y estimaciones de costes no se realizaron en base a los
requisitos
Deficiencias en la aplicacin de procesos y desconocimiento del ciclo de vida del
proyecto

Los criterios de xito de un proyecto son:
Implicacin de los usuarios
Apoyo de los directivos
Enunciado claro de los requisitos
No desviarse de las fechas previstas.
No desviarse de los costes estimados.
Que el producto final cubra las expectativas y necesidades del cliente.
Que funcione correctamente.

Errores en los requisitos

Segn Boehm (1975), 45% de los errores tienen su origen en los requisitos y en el
diseo preliminar. DeMarco, 1984: 56% de los errores que tienen lugar en un proyecto
SW, se deben a una mala especificacin de requisitos.

Tragedias ocurridas por defectos en el SW
De 6 nuevos proyectos que entran en servicio 2 quedan cancelados.
Los proyectos de sistemas de tamao medio consumen 150% ms de tiempo
Alrededor de 3/4 partes de sistemas grandes no funcionan como se quera o no se
utilizan para nada.
El 55 % de los proyectos cost ms de lo esperado
El 68% incumpli plazos previstos.
El 88% tuvo que redisearse
El 34% se termin y no se utiliz por cambio de tecnologa
Algunos casos reales de fracasos de SW:


Un sensor mal programado por Francia, destruy el supe cohete europeo Ariane 5
(El Pas, 23 de junio de 1996)
2 Billones de dlares perdidos al no poder poner en marcha el aeropuerto de Denver
(USA) por culpa del software de control del sistema de traslado de equipajes (fecha
prevista apertura 1-noviembre-93; abri el 28-febrero-95, retraso de 16 meses).
Computer, Febrero, 1995.

Proyeccin de errores

Los errores que no se logren identificar en la fase de requisitos provocarn errores
mayores en las siguientes fases de desarrollo del software. Los errores en los requisitos
se comportan como una enfermedad contagiosa que siempre repercute en todas las fases
del proyecto.
Estimacin: No es posible estimar con rigor costes y recursos necesarios para
desarrollar algo que no se conoce.
Planificacin: No se puede confiar en la planificacin para el desarrollo de algo que no
se sabe bien como es.
Diseo: Los errores en requisitos, las modificaciones frecuentes, las deficiencias en
restricciones o futuras evoluciones, producen arquitecturas que ms tarde se
confirmarn como errneas y sern modificadas.
Construccin: Las deficiencias en los requisitos obligan a programar en ciclos de
prueba y error que derrochan horas y paciencia de programacin sobre patrones de
re codificacin continua y programacin heroica.
Validacin y verificacin: Terminado el desarrollo del sistema, si las especificaciones
tienen errores de bulto, o peor an, no estn reflejadas en una especificacin de
requisitos, no ser posible validar el producto con el cliente.

Los defectos comunes en los requisitos y sus consecuencias





Beneficios de los buenos requisitos

Acuerdo entre desarrolladores, clientes y usuarios sobre el trabajo que debe
realizarse. Requisitos bien elaborados y validados con el cliente evitan descubrir al
terminar el proyecto que el sistema no era lo que se peda.

Acuerdo entre desarrolladores, clientes y usuarios sobre los criterios que se
emplearn para su validacin. Resulta muy difcil demostrar al cliente que el
producto desarrollado hace lo que el pidi si su peticin no est documentada y
validada por l.

Base objetiva para la estimacin de recursos (coste, personal en nmero y
competencias, equipos y tiempo). Si los requisitos no comprenden necesidades
reales, las estimaciones no dejan de ser meras apuestas. Las estimaciones en el
fondo son clculos de probabilidad que siempre implican un margen de error; por esta
razn disponer de la mayor informacin posible reduce el error.



Concrecin de los atributos de calidad (ergonoma, mantenibilidad, etc.). Ms all
de funcionalidades precisas, los requisitos recogen atributos de calidad necesarios
que en ocasiones son desconocidos por los desarrolladores, produciendo finalmente
sistemas sobredimensionados o con serias deficiencias de rendimiento.

Eficiencia en el consumo de recursos: reduccin de la re-codificacin, reduccin de
omisiones y malentendidos. Tener un conocimiento preciso de lo que hay que hacer
evita la prueba y error, repeticin de partes ya desarrolladas, etc.

Qu son los requisitos?

Los requisitos del sistema son La descripcin de los servicios y restricciones.
IEEE define Requisito como:
Condicin o aptitud necesaria para resolver un problema o alcanzar un objetivo.
Condicin o facilidad que debe proporcionar un sistema o algunos de sus
subsistemas para satisfacer un contrato, norma, especificacin o cualquier otra
condicin impuesta formalmente a travs de un documento.
Una representacin documentada de una condicin o facilidad.
Requisito segn Norma MIL-STD STD-498. Caracterstica del sistema que es una
condicin para su aceptacin.

Requisito segn Goguen. Propiedad que un sistema debera tener para tener xito en el
entorno en el que se usar.

Un requisito define: Qu hace el sistema? Y no Cmo lo hace?


mbitos de los requisitos









Descripcin del sistema. Documento, tambin denominado ConOps y normalizado en
el estndar IEEE Std. 1362-1998.

Definicin de ConOps: Documento dirigido a los usuarios, que describe las caractersticas
de un sistema propuesto, desde el punto de vista del usuario. La Descripcin del Sistema
es el medio de comunicacin que recoge la visin general, cualitativa y cuantitativa de las
caractersticas del sistema; compartido por la parte cliente y desarrolladora.


mbitos
Sistema
Software
Descripcin del sistema
ConOps
Requisitos del software
SRS


Especificacin de requisitos del software (SRS o ERS). Un documento SRS es la
especificacin de las funciones que realiza un determinado producto de software,
programa o conjunto de programas en un determinado entorno.

A travs de los SRS se determina qu funcionalidades deben realizarse, qu datos deben
generarse en cada resultado, en qu lugar y quin los debe producir. La SRS debe
centrarse en los servicios que se realizarn, pero, en general, no debe especificar
elementos de diseo o de proyecto. Deben centrarse nicamente en el punto de vista
externo del sistema, y no en el funcionamiento interno.

El documento de especificacin de requisitos puede elaborarlo el personal representativo
de la parte suministradora (desarrollador), o de la parte cliente; si bien es aconsejable la
intervencin de ambas partes.


QU ES INGENIERA DE REQUISITOS?

La Ingeniera de Requisitos comprende las actividades de desarrollo de software (y
Sistemas de Informacin) relacionadas con la gestin y definicin de necesidades,
restricciones y atributos de calidad para sistemas nuevos o actuales.

La IR trata de los principios, mtodos, tcnicas y herramientas que permiten descubrir,
documentar y mantener los requisitos para sistemas basados en computadora, de forma
sistemtica y repetible.

IEEE define la IR como: Proceso de estudio de necesidades de los usuarios con el objeto
de llegar a una definicin del sistema HW/SW.

Segn el profesor Loucopoulos: La IR consiste en un trabajo sistemtico de desarrollo de
requisitos, a travs de un proceso iterativo y cooperativo de anlisis del problema,
documentando los resultados en una variedad de formatos y probando la exactitud del
conocimiento adquirido.

Proceso de la Ingeniera de Requisitos

1. Obtencin (elicitacin). El primer paso consiste en conocer y comprender las
necesidades y problemas del cliente.

OBTENCIN
Obtener
informacin
ANLISIS ESPECIFICA
CIN
VERIFICACIN
&
VALIDACIN
GESTIN
Clasificarla, localizar
inconsistencias, dar
prioridades, pasar a
requisitos
Escribir los
requisitos
Comprobar que
son formalmente
correctos y lo que
el cliente quiere
Registrar
cambios, estudiar
su impacto,
actualizar
documentacin
Obtener informacin Registro y contrastacin
Controlar las
modificaciones


En la obtencin se identifican todas las fuentes de requisitos implicadas en el sistema y,
en funcin de las caractersticas del entorno y del proyecto se emplean las tcnicas ms
apropiadas para la identificacin de las necesidades que deben satisfacerse.

2. Anlisis. Una vez obtenida la informacin necesaria del entorno, es necesario
sintetizarla, darle prioridades, analizar posibles contradicciones o conflictos, descomponer
el sistema y distribuir las necesidades de cada parte, delimitar los lmites del sistema y
definir su interaccin con el entorno.

3. Especificacin. Cuando ya se conoce el entorno del cliente y sus necesidades, es
necesario plasmarlas en forma de requisitos en los documentos que sirven de base de
entendimiento y acuerdo entre cliente y desarrollador, y que establecern tanto la gua
desarrollo como los criterios de validacin del producto final.
Documentar los requisitos es la condicin ms importante para gestionarlos
correctamente.

4. Verificacin y validacin. Los requisitos deben ser formal y tcnicamente correctos
(verificacin), y satisfacer las necesidades del sistema, sin omitir ninguna ni incluir
funcionalidades innecesarias (validacin).

El significado de estos dos trminos genera confusiones habitualmente. El criterio bsico
que los diferencia es que verificacin se refiere a la calidad formal, en este caso de los
documentos de requisitos (no son ambiguos, no son incompletos, son posibles,
verificables, etc.) y validacin comprende la adecuacin en el entorno de produccin, en el
caso de la documentacin de requisitos, la conformidad por parte del cliente de que
reflejan lo que l quiere.

5. Gestin. Los requisitos cambiarn durante el desarrollo del sistema, y es necesario
poder trazar en cada cambio todas las partes afectadas, as como poder medir el impacto
que cada modificacin implica en la planificacin del proyecto.





2. DESCRIPCIN DE LAS ACTIVIDADES DEL PROCESO DE LA IR


A. OBTENCIN DE REQUISITOS.

Este proceso tambin es considerado como: elicitacin, educcin, formulacin,
identificacin o extraccin.

La especificacin de requisitos se refiere a la captura y descubrimiento de los
requisitos.
Es una actividad ms humana que tcnica.
Se identifica a los interesados (clientes y usuarios) y se establecen las primeras
relaciones entre ellos y el equipo de desarrollo.




A quin (es) se dirigen los requisitos?

El proceso de obtencin de requisitos se dirige a:

Usuarios potenciales o clientes
Productores de software o sistemas

Cada uno de estos dos escenarios lleva a situaciones totalmente diferentes: En el primer
caso, se definen las necesidades (puede servir como base para el pliego de condiciones)
y ser muy general para permitir distintas soluciones. En el segundo caso, las
especificaciones suponen un paso inicial para el desarrollo de software y debern ser
mucho ms especficas.

Fuentes de los requerimientos
Identificar los objetivos del proyecto y eventualmente realizar un estudio de
viabilidad de los mismos.
mbito de aplicacin o dominio de conocimiento del proyecto (permitir resolver
conflictos entre actores)
Identificar a todos los actores del proyecto para poder disear un sistema que
recoja diferentes puntos de vista de manera consensuada y sea fcil de usar por
todos ellos
Identificar el entorno operacional para poder establecer las restricciones del
proyecto y los costes.
Entorno organizativo: identificacin de los condicionantes que la estructura, la
cultura y la poltica interna de la organizacin puedan imponer o sobre-entender.

Tcnicas de obtencin de los requerimientos

Entrevistas con los actores (clientes y/o usuarios): cerradas / abiertas
Encuestas aplicando cuestionarios con preguntas concretas y respuestas
cerradas / abiertas
Escenarios. Los requisitos se sitan en el contexto de uso (casos de uso).
Permiten contextualizar y preguntarse sobre Qu pasara si ... ? Cmo se
hace sto ?
Prototipos: permiten clarificar y precisar requerimientos. tiles cuando la
incertidumbre es total acerca del futuro sistema.
Reuniones de grupo (normales o brainstorming): permiten aportar mayores
puntos de vista que a travs de entrevistas individuales y aflorar puntos de vista
contrapuestos. Es necesario gestionarlas correctamente para evitar conflictos o
puntos de vista dominantes.
Observacin de los sistemas actuales y medida de distintos parmetros de los
mismos a travs de la inmersin operacional. Ilustra acerca de las tareas y ciertos
procesos complejos o sobreentendidos que raramente se explicitan.
Estudio de los documentos y formularios existentes.
Visitas a otras instalaciones, investigacin externa, jornadas profesionales, ferias
Presentaciones comerciales, estudio de productos SW ya existentes.






B. ANLISIS DE REQUISITOS.

Consiste en detectar y resolver conflictos entre requisitos.
Se precisan los lmites del sistema y la interaccin con su entorno.
Se trasladan los requisitos de usuario a requisitos del software (implementables).
Se realizan tres tareas fundamentales: Clasificacin, Modelizacin y
Negociacin.

Clasificacin de Requisitos.

La clasificacin ms tpica de los requisitos es la que se presenta a continuacin:

Sin embargo, algunos autores presentan otras formas de clasificacin de requisitos:
Por prioridades
Por coste de implementacin
Por niveles (alto nivel, bajo nivel)
Segn su volatilidad/estabilidad
Si son requisitos sobre el proceso o sobre el producto

Requisitos Funcionales:
Definen el comportamiento del sistema.
Describen los servicios o funciones del sistema
Describen las tareas que el sistema debe realizar.
Al definir un requisito funcional es importante mantener el equilibrio entre la
excesiva generalidad, insuficiencia de detalle o ambigedad, y el exceso de detalle
con precisiones o descripciones innecesarias o redundantes.

Requisitos No funcionales: Definen aspectos, que sin ser funcionalidades, (tareas que
el sistema debe realizar) resultan deseables desde el punto de vista del usuario.
Generalmente comprenden atributos de calidad:
Tiempos de respuesta.
Caractersticas de usabilidad.
Facilidad de mantenimiento. etc.

Requitos de Interfaz. Definen las interacciones del sistema con su entorno. Interfaces de
Usuarios o con otros sistemas.

Modelizacin de Requisitos:

La meta es entender mejor el problema, ms que iniciar el diseo de la solucin
(idealmente)

El tipo de modelo elegido depende de:
La naturaleza del problema
La experiencia del modelizador
La disponibilidad de herramientas
Por decreto. El cliente impone una notacin

TIPOS DE REQUISITOS
FUNCIONALES
Capacidades
Restricciones
NO FUNCIONALES
DE INTERFAZ
Restricciones


Tradicionalmente se entenda que el anlisis se reduca a modelizar (DFDs, modelos de
objetos, etc), pero el anlisis de requisitos NO es exclusivamente un proceso de
modelizacin. Por otro lado, no existe la mejor forma de modelar requisitos. En
realidad, no hay evidencia emprica que demuestre, en general, la superioridad de unas
notaciones de modelizacin frente a otras.

Negociacin de Requisitos:

Tambin denominada resolucin de conflictos entre:
Requerimientos incompatibles
Actores que demandan requerimientos incompatibles
Recursos disponibles y requerimientos solicitados
Requerimientos funcionales y restricciones

Frecuentemente el analista no tiene capacidad para decidir, por lo que debe favorecer el
consenso, y si hay un contrato de prestacin de servicios, debe dejarse traza del por qu
de la decisin tomada.

Podra incorporarse como parte de la Validacin de requerimientos. La mejor tcnica es
la de las reuniones con los involucrados, previamente preparadas y documentadas
para conocer el impacto de los conflictos y sus posibles soluciones.

Otras tcnicas son: correo electrnico, boletines electrnicos, bases de datos compartidas
tipo Lotus Notes con la documentacin de los requerimientos y sus conflictos. No estn
excesivamente probadas y su utilidad puede ser dudosa si se genera una actitud de
desinters.

C. ESPECIFICACIN DE REQUISITOS.

Para la especificacin de los requisitos o documentacin es necesario utilizar algn
estndar, as encontramos a los siguientes:

IEEE Std. 830-1998
PSS-05 de la Agencia Espacial Europea (ESA)


El estndar IEEE std. 830 1998 contiene la siguiente estructura:

1. Introduccin
2.1. Propsito
2.2. Alcance
2.3. Definiciones
2.4. Referencias
2.5. Visin General
3. Descripcin General
3.1. Perspectiva del producto
3.2. Funciones del producto
3.3. Caractersticas del usuario
3.4. Restricciones
3.5. Suposiciones


4. Requisitos Especficos
5. Apndices
6. ndice

Fuente: (http://es.tldp.org/I+D/donantonio/doc-ers_ieee830-donantonio-servidor/donantonio-servidor-html/index.html )

Los aspectos bsicos que una descripcin de requisitos debe cubrir son:
Funcionalidad. Descripcin de lo que el software debe hacer.
Interfaces externos. Cmo debe interactuar el software con las personas, el
sistema de hardware, o con otros sistemas (software y hardware).
Rendimiento. Indicacin de la velocidad, disponibilidad, tiempos de respuesta,
tiempos de recuperacin, tiempos de determinadas funciones.
Atributos. Consideraciones de portabilidad, correccin, mantenibilidad, seguridad,
etc.
Restricciones de diseo en la implementacin. Indicacin de las restricciones
que puedan afectar por la necesidad de sometimiento a estndares, lenguajes,
polticas de integridad de bases de datos, lmites de recursos disponibles para el
desarrollo, sistema operativo, etc.

Propiedades deseables de los requisitos.

Comprensible por clientes, usuarios y desarrolladores.
Correcto, sin requisitos innecesarios o redundantes.
No ambiguo y con el nivel de precisin necesario.
Completo, que no falten requisitos y que todas las respuestas del sistema a entradas
tanto vlidas como invlidas estn especificadas.
Consistente, sin conflictos ni contradicciones entre los requisitos o con documentos de
nivel superior y con una terminologa nica.
Verificable, que pueda comprobarse que el sistema final cumple los requisitos
mediante un proceso finito y de coste razonable.
Fcilmente modificable, organizada, con los requisitos identificados y con control de
configuracin.
Rastreable, de forma que se conozcan las dependencias de los requisitos hacia detrs
y hacia delante.
Priorizada, indicando la importancia de los requisitos.
Anotada con estabilidad, para conocer posibles fuentes de cambios durante el
desarrollo.
Independiente del diseo y la implementacin, para evitar complejidades innecesarias
y no limitar a los diseadores.


D. VALIDACIN DE REQUISITOS

La validacin de requisitos consiste en descubrir problemas en el documento de requisitos
antes de comprometer recursos en la implementacin del software.

El documento debe revisarse para:
Descubrir omisiones
Conflictos
Ambigedades


TALLER

Realiza las siguientes actividades con el propsito de reforzar conocimientos en IR:

1. Cules son los factores de xito y de fracaso de los proyectos de software?
2. Qu tragedias ha causado el desarrollo de software con defectos?
3. Qu es la Ingeniera de Requisitos (IR)?
4. Cul es la importancia de la Ingeniera de Requisitos?
5. A quienes dirigirnos para recolectar requisitos?
6. Qu son los requisitos?
7. Cul es la clasificacin de los requisitos?
8. Describa las etapas del proceso de la IR
9. Investigue las tcnicas de especificacin de requisitos
10. Cmo se clasifican los requisitos?
11. Describa el estndar IEEE 830 -1998 para documentar requisitos.

Comprobar la calidad del documento y su grado de de adhesin a estndares

Para revisar el documento de los requisitos es aconsejable conformar una comisin de
revisin que incluya desarrolladores y usuarios. Esta comisin debe encargarse de:
Buscar problemas en el documento de los ERS.
Convocar a reuniones y establecer acuerdos.

Algunas tcnicas para identificar problemas habituales:
Listas de comprobacin checklists
Prototipado. Permite descubrir con rapidez si el usuario se encuentra satisfecho o
no con los requisitos
Validacin de Modelos. Cuando los requisitos son expresado en base a modelos
como: Casos de Uso, DFDs u otros.
Validacin de su testeabilidad. El equipo de pruebas debe revisar los requisitos.


E. GESTIN

La gestin de requisitos debe realizarse durante todo el proceso de desarrollo del
software. Es parte de la Gestin de la Configuracin del Software y se realizan algunas
actividades:
Definir procedimientos de cambios: definen los pasos y los anlisis que se
realizarn antes de aceptar los cambios propuestos.
Cambiar los atributos de los requisitos afectados.
Mantener la trazabilidad: hacia atrs, hacia delante y entre requisitos.
Control de versiones del documento de requisitos


























TAREA EXTRACLASE II




1. Complete:

a. Requisito:
....................................................................................................................
....................................................................................................................
b. IEEE 830...........................................................
....................................................................................................................
....................................................................................................................
c. Cul es la parte ms difcil en la construccin de un software?
....................................................................................................................
....................................................................................................................
....................................................................................................................
d. Tcnicas usadas en el proceso de validacin de requisitos:
....................................................................................................................
....................................................................................................................
....................................................................................................................
e. Cmo se comportan los errores en los requisitos en las dems fases del proceso de
ingeniera del software?: .. ....
....................................................................................................................
....................................................................................................................
f. Cul es el mbito de los requistos?:
....................................................................................................................
....................................................................................................................
....................................................................................................................

2. Elabore un cuadro resumen de las tcnicas para recolectar requisitos del
software



3. Qu es la Ingeniera de Requisitos




4. Realice un ensayo sobre los procesos de la Ingeniera de Requisitos