Subido por Joshua Castro

03303 Capitulo 1 Requisitos

Anuncio
INGENIERIA DE REQUERIMIENTOS
AVANZADA (requisitos)
ALINEADO CON LAS MEJORES PRÁCTICAS
Capítulo # 1
INGENIERIA DE REQUERIMIENTOS AVANZADA
1.
INTRODUCCION ________________________________________________________________ 3
OBJETIVO GENERAL ________________________________________________________________ 5
OBJETIVOS ESPECÍFICOS. _________________________________________________________ 6
2. INGENIERÍA DE REQUISITOS ___________________________________________________ 7
3. CICLO DE VIDA DE LA ADMINISTRACIÓN DE UN PROYECTO _________________ 8
4. DEFINICIÓN DEL PROYECTO ____________________________________________________ 8
5. PLANEAMIENTO INICIAL – DESARROLLO DE REQUISITOS ___________________ 9
6. ESPECIFICACIONES ____________________________________________________________ 12
7. REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES. _____________________ 14
7.1 REQUERIMIENTOS FUNCIONALES __________________________________________________________ 14
7.2 REQUERIMIENTOS NO FUNCIONALES ________________________________________________________ 14
8. METODOLOGÍAS DE REQUERIMIENTOS _______________________________________ 15
8.1 METODOLOGÍA ESTRUCTURADA ___________________________________________________________ 15
8.2 METODOLOGÍA ORIENTADA A OBJETOS ______________________________________________________ 16
9. ESPECIFICACIÓN DE REQUERIMIENTOS ISO/IEEE 830 ______________________ 18
10. OBJETIVOS DE LA ERS. _______________________________________________________ 18
11. CARACTERÍSTICAS DE UN ERS _______________________________________________ 19
11.1 COMPROBACIÓN DE VALIDEZ ____________________________________________________________ 20
11.2 CONSISTENCIA ______________________________________________________________________ 20
11.4. COMPROBACIÓN DE TOTALIDAD _______________________________________________________ 20
11.5 COMPLETITUD ______________________________________________________________________ 21
11.6 VERIFICABILIDAD ____________________________________________________________________ 21
11.7 CLASIFICACIÓN _____________________________________________________________________ 21
11.8 MODIFICABILIDAD ___________________________________________________________________ 21
11.9 EXPLORABILIDAD (TRACEABILITY) _________________________________________________________ 22
11.10 UTILIZABLE DURANTE LAS TAREAS DE MANTENIMIENTO Y USO _____________________________________ 22
12. ESQUEMA DE LA ERS DEFINIDA EN EL IEEE 830-1998 _____________________ 23
I. INTRODUCCIÓN _______________________________________________________________________ 24
II. DESCRIPCIÓN DE LA INFORMACIÓN __________________________________________________________ 24
III DESCRIPCIÓN FUNCIONAL ________________________________________________________________ 24
IV DESCRIPCIÓN DEL COMPORTAMIENTO ________________________________________________________ 25
V SECCIÓN DE CRITERIOS DE VALIDACIÓN ________________________________________________________ 25
VI BIBLIOGRAFÍA. _______________________________________________________________________ 25
13.
NATURALEZA DE LA INGENIERÍA DE REQUERIMIENTOS __________________ 26
13.1. MATEMÁTICAS ____________________________________________________________________ 26
13.2. CREACIÓN ________________________________________________________________________ 26
13.3. GESTIÓN DE PROYECTO _______________________________________________________________ 26
14.
1
PARTICIPANTES Y PAPELES _________________________________________________ 27
INGENIERIA DE REQUERIMIENTOS AVANZADA
14.1. CLIENTE _________________________________________________________________________ 27
14.2. DESARROLLADORES __________________________________________________________________ 27
14.3. GESTORES ________________________________________________________________________ 27
14.4. USUARIOS FINALES __________________________________________________________________ 28
14.5. CÓDIGO ÉTICO DE UN INGENIERO DE SOFTWARE _______________________________________________ 28
15. CONCLUSIONES _______________________________________________________________ 31
16. BIBLIOGRAFÍA _______________________________________________________________________ 32
2
INGENIERIA DE REQUERIMIENTOS AVANZADA
1. INTRODUCCION
Dentro del campo de la Ingeniería del software se adscriben un sinnúmero de
disciplinas, técnicas y metodologías que referencian a todas las actividades
relacionadas con la fabricación del software y su gestión, entre las principales
se pueden citar ingeniería de requerimientos avanzada, ingeniería de calidad
(comúnmente control de calidad), la ingeniería de métodos, ingeniería de
usabilidad, arquitectura de bases de datos, todas íntimamente relacionadas
que se traslapan durante el ciclo de vida de un proyecto de software de tal
forma que el software se comporte confiable y eficazmente, para que sea
accesible en su desarrollo, control, mantenimiento y seguimiento y que cumpla
con todos los componentes y necesidades
que los usuarios o clientes han
definido.
Este documento aborda la ingeniería de requerimientos avanzada desde sus
inicios, su evolución y modernización paralelamente auspiciada y soportada por
las Normas Internacionales ISO (ISO.ORG)
las cuales dan un soporte de
autenticidad a través de la mejora de procesos, entre ellas se citan:
ISO/IEC 9001:2000: Adopta un enfoque basado en procesos para el desarrolla,
implementación y mejora la eficacia a través de un sistema de gestión de la
calidad. (9001:2000, 2000) (Ginebra).
ISO/IEC 9001:2008: Modificación de la ISO/IEC 9001:2000 (ISO.ORG)
ISO/IEC 9000-3:2004: Se plantea una guía metodología a la aplicación de ISO
9001 para el desarrollo, la aplicación y mantenimiento de software.
ISO/IEC 12207:1995: Comprende los procesos del ciclo de vida del desarrollo
del software.
3
INGENIERIA DE REQUERIMIENTOS AVANZADA
ISO/IEC 12207:2008: Desarrolla un marco común para los procesos de ciclo de
vida de software, empleando terminologías claramente definidas. Contiene los
procesos, actividades y tareas que se aplican durante la adquisición de un
producto de software o servicios y el desarrollo, operación, mantenimiento.
ISO/IEC 9126:2001: Establece las características para evaluar la calidad del
producto software y establece los lineamientos de la calidad.
ISO/IEC 15939:2007: Desarrolla un proceso de medición través de un modelo
que contiene las actividades, es adaptable y flexible a los requerimientos de los
usuarios.
ISO/IEC 15504:2004: Desarrolla y proporciona un marco guía para la
evaluación y mejorar la capacidad y madurez de los procesos. Se aliena y
aplica junto ISO/OEC 12207.
ISO/IEC 14598:1999: Establece pautas que soportan al proceso de evaluación
del software.
ISO/IEC 25000:2005: Implementa una guía para el uso de las nuevas series
de estándares internacionales.
El proceso de análisis de requerimientos es la etapa de la ingeniería del
software que desarrolla y conecta la asignación del software a en al ámbito del
sistema y el diseño y su mantenimiento. (Galeon.com).
Los requisitos para un sistema son descripciones de lo que el sistema debe
hacer: el servicio que ofrece y las restricciones en su operación. Tales
requerimientos reflejan las necesidades de los clientes por un sistema que
atienda cierto propósito. Al proceso de descubrir, analizar, documentar y
verificar
estos
requerimientos.
4
servicios
y
restricciones
se
le
llama
ingeniería
de
INGENIERIA DE REQUERIMIENTOS AVANZADA
El cuadro N° 1 muestra el esquema general de los procesos de la ingeniería de
requerimientos avanzada (IRA).
Objetivo General
Desarrollar un guía metodológica bajo las normas generalmente aceptadas que
permitan formular procesos cualitativos y cuantitativos sostenibles para el
desarrollo y calidad del software, y que mediante la orientación correcta de
estos procedimientos tal forma que el software se comporte confiable y
eficazmente, para que sea accesible en su desarrollo, control, mantenimiento y
seguimiento para que cumpla con todos los componentes y necesidades que
los usuarios o clientes han definido.
5
INGENIERIA DE REQUERIMIENTOS AVANZADA
Objetivos Específicos.
 Definir una mejora continua y sostenible en el diseño de aplicaciones de
manera tal que se ajusten a los requerimientos de las organizaciones.
 Especificar a una mayor calidad durante el desarrollar aplicaciones yanto
simples como complejas.
 Definir los costos, el tiempo y el esfuerzo en el desarrollo de proyectos
del software.
 Alinear las normas específicas mundialmente reconocidas como ISO,
ITIL, CMMI.
 Organizar un equipo de trabajo multidisciplinaria bajo los estándares
internacionales, en el desarrollo, mantenimiento y seguimiento en
aplicaciones de software.
 Identificar mediante pruebas eficientes las posibles mejoras para una
mejor
adaptabilidad
y
aplicaciones de software.
6
continuidad
en
el
funcionamiento
de
las
INGENIERIA DE REQUERIMIENTOS AVANZADA
2. Ingeniería de Requisitos
Durante el curso de un proyecto, coexisten dos ciclos de vida que son
interdependientes. El ciclo de vida del proyecto, por un lado, podría describir
las fases, entregables y actividades que deben ser completadas para producir
un producto, servicio o resultado y cada área de aplicación tiene su ciclo de
vida específico. Por otro lado, el ciclo de vida de desarrollo del proyecto o ciclo
de vida de desarrollo del software que define las etapas que unen su inicio y su
final.
Para lograr visualizar la logística a utilizar en cada forma de la ingeniería del
software y ubicar la etapa de la ingeniería del requerimientos avanzada
primero se debe conocer las diferentes normas y metodologías desarrolladas
para el ciclo de vida de desarrollo del software, que comprenden 5 elementos,
o partes, (llamadas en algunos casos ciclos, etapas, fases), en cada una de
estos ciclos se utiliza un tipo variante de ingeniería del software.
7
INGENIERIA DE REQUERIMIENTOS AVANZADA
3. Ciclo de Vida de la Administración de un Proyecto
Uno de los retos más importantes para el Director del Proyecto consiste en
alinear el ciclo de vida específico del proyecto con el ciclo de vida de su
administración ya que estos dos ciclos se traslaparán.
Tanto las actividades
necesarias para crear el producto del proyecto como las requeridas para su
adecuada administración pueden ser asociadas a través de los entregables o
salidas de la administración del proyecto.
4. Definición del Proyecto
En el caso de negocio se plasma la esencia del proyecto, la necesidad de la que
este surge, el problema que debe resolverse, la oportunidad que debe ser
aprovechada por la organización.
En otras palabras, define algunos de los
elementos principales del proyecto y proporciona la información necesaria para
apoyar la decisión de iniciarlo y de llevarlo a cabo a través de todas las etapas
de su ciclo de vida.
El planeamiento inicial del proyecto abarca la definición del alcance inicial, el
desarrollo de un cronograma de alto nivel, la identificación de estándares de
calidad, la preparación de un presupuesto preliminar, la identificación inicial de
riesgos y el desarrollo, a nivel preliminar, de un plan de comunicaciones.
Ello supone también la ingeniería de requerimientos donde el punto inicial son
los llamados levantamiento de requisitos, los cuales se abarcan en este
documento como objetivo principal.
8
INGENIERIA DE REQUERIMIENTOS AVANZADA
5. Planeamiento Inicial – Desarrollo de Requisitos
El análisis de requisitos es un proceso iterativo que se presenta como una
espiral de actividades que incluye un estudio de factibilidad, adquisición y
análisis de requerimientos, especificación de requerimientos (descubrimiento),
validación de requerimientos (refinamiento), administración de requerimientos
(modelización). Comienza con un refinamiento detallado del ambiente del
programa que ha sido inicialmente establecido durante a ingeniería del sistema
y refinado durante la planificación del proyecto de software.
Dentro del ciclo de vida de un proyecto de software los requisitos son las
partes principales del producto o la aplicación que se debe construir por lo que
se deben identificar, desarrollar objetivamente y documentarlos.
El análisis de requisitos es una condición o capacidad que ser alcanzada o
procesada por un sistema o componente de un sistema, especificación u otros
documentos formalmente impuesta. (Society)
Dentro del detalle se debe comprender las condiciones que debe cumplir o al
menos tener una aplicación o sistema en o parte de sus componentes para
llegar a satisfacer las necesidades de una aplicación de software.
El principal objetivo de los requerimientos es la participación de los
analistas, y la participación del rol y responsabilidad de los actores iniciales o
usuarios futuros duelos de la aplicación, debido principalmente al conocimiento
de los procesos de la organización que se van a automatizar. La técnica de
análisis más comúnmente usada para cubrir el vacío de comunicación entre el
cliente y el técnico y conseguir que comience el proceso de comunicación, es
dirigir una entrevista o revisión preliminar. La primera reunión entre las partes
(el ingeniero de software y el cliente) es una proeza. A pesar de todo se
sugiere que el analista inicie con unas preguntas independientes del contexto,
el primer conjunto de preguntas se centran en el cliente:
9
INGENIERIA DE REQUERIMIENTOS AVANZADA
Ejemplo:
¿Quién es el cliente dueño del proyecto?
¿Quién va a utilizar la solución?
¿Cómo se espera el retorno de la inversión de la solución?
Las siguientes preguntas permiten al analistas conocer mejor el problema y
al c cliente expresar su s ideas sobre la solución.
¿Cómo caracteriza una buena calidad que fuera generada por una solución
satisfactoria?
¿Qué problemas resolverá esta solución?
¿Existe alguna forma de verificar y o describirme el ambiente donde se va a
utilizar la solución?
¿Dentro del ambiente donde se desarrollara la solución existen limitaciones
que afecten la forma en que va a trabajar la solución?
La entrevista cierra con una serie de preguntas para logra cuantificar la
efectividad de la reunión de la reunión, algunas de ellas son:
¿Es Usted la persona adecuada para responder a estas preguntas? ¿Son
oficiales sus respuestas?
¿Las preguntas y cuestionamiento han sido relevantes mis preguntas para
resolver su problema?
¿Considera que se deben incorporar más personal para proporcionar
información adicional?
El documento de requerimientos (llamado algunas veces especificación de
requerimientos del software o SRS) es un comunicado oficial de lo que se
deben
implementar
los
desarrolladores
del
sistema.
Incluye
tanto
los
requerimientos del usuario para un sistema, como una especificación detallada
de los requerimientos del sistema. En ocasiones, los requerimientos del
sistema y del usuario se integran en una sola descripción, En otros casos, los
requerimientos del usuario se definen en una introducción a la especificación
de los requerimientos del sistema.
10
INGENIERIA DE REQUERIMIENTOS AVANZADA
Clientes y desarrolladores de software, constantemente tienen inconsistencias
en su forma de pensar, como “nosotros y ellos”. No solamente deben trabajar
en equipo para identificar y refinar los requisitos, también cada grupo de
trabajo define su propio modelo o pensamiento y deben buscar el método de
comunicación más apropiado.
Con estos problemas presentes se ha desarrollado un enfoque orientado al
equipo para la recopilación de requisitos que se aplica durante las primeras
etapas de análisis y requisitos llamado Técnica para Facilitar la Especificación
de la Aplicación (TFEA), comprende a creación mixta de un equipo de clientes y
personas encargadas de desarrollo que trabajan juntos para el desarrollo e
identificar el problema. (trackli.googlecode.com)
Se han propuesto muchos enfoques diferentes para el método TFEA. Cada uno
utiliza un guion ligeramente diferente, peeos tipos aplican alguna variación de
las siguientes directrices básicas:
Se lleva a cabo una reunión en un lugar neutral, a la que llegan tanto técnicos
como clientes.
Se establecen reglas para la preparación y participación.
Se sugiere una agenda que sea lo suficientemente formal para que cubra todos
los puntos importantes, pero lo suficientemente informal para estimular el flujo
libre de ideas.
Se
acuerda
la
elección
de
un
facilitador
para
controlar
la
reunión.
(trackli.googlecode.com)
Se utiliza una fórmula para la comunicación efectiva
El objetivo es identificar el problema, proponer elementos de una solución,
avaluar los diferentes enfoques y especifica car un conjunto preliminar de
requisitos de la solución en un ambiente adecuada para alcanzar el objetivo.
(trackli.googlecode.com)
11
INGENIERIA DE REQUERIMIENTOS AVANZADA
6. Especificaciones
Los ingenieros del software se han visto forzados a
trabajar con
especificaciones incompletas, inconsistentes o mal establecidas, los requisitos
del
software
se
pueden
analizar
de
varias
formas
diferente
y
las
especificaciones puede ser vista como un proceso de representación de forma
que conduzca finalmente a una correcta implementación del software. Balzar y
Goldman sugieren y propones ocho principios para establecer y desarrollar las
buenas especificaciones, entre ellas están: (Chelob)
Principio # 1: Hacer una distinción entre funcionalidad e implementación.
Una especificación es una descripción de cómo se desea realizar, no de
cómo se va a realizar (implementar)
Principio # 2: Se requiere utilizar un lenguaje para la especificación de
sistema que este orientado al proceso. (Chelob) (Galeon.com)
Se debe especificar el sistema completo de las partes que interactúan, en
vez de solo un componente.
Principio # 3: únicamente y especificación debe comprender y determinar
todo el sistema como un todo del cual un determinado software es parte del
componente.
Un sistema está compuesto de muchos componentes que entrelazan e
interactúan entre sí. Únicamente dentro del modelo del sistema como un todo
y de la interacción entre sus componentes las partes deben definir el
comportamiento de un componente específico y único. (Galeon.com)
Principio # 4: similarmente una especificación debe comprender todo el
ambiente en el que el sistema debe trabajar en la producción. (Galeon.com)
Similarmente, La especificación del entorno permite especificar la interfaz
del sistema de la misma forma que los propios sistemas, en vez de introducir
un formalismo.
12
INGENIERIA DE REQUERIMIENTOS AVANZADA
Principio # 5 Para cada especificación de un sistema debe existir un
modelo cognitivo. (Galeon.com)
La especificación de un sistema debe ser un modelo cognitivo en vez de un
modelo de diseño o de implementación. (Galeon.com) El sistema como tal
debe describir un sistema la percepción de los usuarios finales. (Chelob)
Principio # 6. Cada especificación única del sistema debe ser operativa.
La especificación debe ser completa y lo bastante formal para que puede
usarse
para
determinar
especificación, con
casos
si
una
de
implementación
prueba elegidos
propuesta
satisface
arbitrariamente.
la
(Chelob)
(Galeon.com)
Principio # 7: La especificación del sistema deben ser tolerantes a la
incompletita y ampliable. (Chelob), (Galeon.com)
Ninguna especificación estará prácticamente completa. El medio ambiente
en que se desarrolla es demasiado complejo y confuso. Una especificación en
la mayoría de los casos es un modelo – abstracción- de alguna situación real.
(Chelob)
Principio # 8: Una especificación prácticamente debe estar localizada y
acoplada. (Chelob)
La especificación no es un objeto estático previamente compuesto, sino un
objeto dinámico que sufre considerable modificaciones. (Chelob)
13
INGENIERIA DE REQUERIMIENTOS AVANZADA
7. Requerimientos Funcionales y no funcionales.
Normalmente existen dos tipos de requerimientos siendo funcionales y no
funcionales
7.1 Requerimientos Funcionales
Los requerimientos funcionales son aquellos que se utilizan para lo que
debe hacer el sistema. Tales requerimientos dependen del tipo de software que
se está desarrollando, de los usuario esperados del software y del enfoque
general que adopte la organización cuando se describen los requerimientos,
Los
requerimientos
funcionales
se
describen
en
forma
abstracta,
los
requerimientos funcionales más específicos del sistema detallan las funciones
del sistema, sus entradas y salidas
7.2 Requerimientos No Funcionales
Los requerimientos no funcionales, son requerimientos que no se relacionan
directamente con los servicios específicos que el sistema entrega a sus
usuarios, pueden relacionarse emergentes del sistema, como fiabilidad, tiempo
de resuelta u uso de almacenamiento, capacidad de los dispositivos.
Los requerimientos no funcionales afectan más la arquitectura global de un
sistema que los componentes individuales, como unos requerimientos de
seguridad, surgen a través de las necesidades de los usuarios debido a las
restricciones presupuestarias, políticas de la organización, necesidad de
interoperabilidad con otro software.
14
INGENIERIA DE REQUERIMIENTOS AVANZADA
8. Metodologías de Requerimientos
Teniendo el documento de especificación de requerimientos, el analista
desarrollara el modelado de la nueva aplicación. (Piattini Velthuis, 1996).
También se pueden utilizar variados tipos de metodologías entre las que más
comúnmente existen: la metodología estructurada y la metodología orientada
a objetos
8.1 Metodología Estructurada
Es considera como la primera aproximación para el desarrollo del problema. En
esta metodología predominan los procesos, por lo tanto su objetivo principal es
especificar y descomponer la funcionalidad de las aplicaciones.
De acuerdo a los movimiento la información se procesa y reprocesa durante la
vida del software, esta es modificada por una serie de procesos la cual la y
transforma en nueva información. Los diagramas de flujos de datos (DFD) que
se desarrollan son una norma técnica para modelado gráfico que esquematiza
un flujo de información de datos y las transformaciones que se aplican a los
datos al moverse desde el inicio hasta el final de un proceso. (Galeon.com)
(trackli.googlecode.com)
La metodología estructurada se centra menos en la creación de símbolos
gráficos adicionales y más en la representación y especificaciones de los
aspectos del software orientado al control. Por tanto se basa en el modelo de
flujo como primer elemento de presentación gráfica de un sistema basado en
computadora. Usando como base diagramas de flujo de datos y de control, el
analista separa las funciones que transforman el flujo.
Después, crea un modelo de comportamiento usando un diagrama de
transición de estados y un modelo de contenido de datos con un diccionario de
requisitos. Las especificaciones de los procesos y del control proporcionan una
elaboración adicional de los detalles
15
INGENIERIA DE REQUERIMIENTOS AVANZADA
8.2 Metodología Orientada a Objetos
Los métodos orientados a objetos para el análisis de requisitos del software,
permiten al analista obtener el modelo de un problema representando clases,
objetos, atributos y operaciones como componentes principales de modelación.
Los puntos de vista orientados a los objetos combinan la clasificación de
objetos, la herencia de atributos y los mensajes de comunicación dentro del
contexto de la notación de modelación.
Los objetos modernizan casis cualquier aspecto identificable del ámbito del
problema:
entidades
externas,
casos,
sucesos,
papeles,
unidades
organizativas, lugares y estructuras pueden ser representadas por objetos. Un
aspecto importante, se debe a que los objetos encapsulan datos y procesos.
Las operaciones de procesamiento son parte del objeto son iniciadas pasando
un mensaje al objeto. Una definición de una clase forma la base para la
reusabilidad en los niveles de modelación, diseño e implementación.
La metodología orientada a objetos proporciona una notación y un conjunto
heurístico para construir un modelo AOO- Análisis orientado a objetos.
Dentro de las metodologías más predominantes la orientación a objetos es las
más recientes y utilizadas en la actualidad, debido a la crecientes ventajas,
éntrelas cueles se destaca:
La metodología se basa en componentes, o sea es más fácil de reutilizar el
código para terceras soluciones. Su mantenimiento y seguimiento es más fácil
debido
16
a
que
los
cambios
están
más
focalizados
y
localizados
INGENIERIA DE REQUERIMIENTOS AVANZADA
Dentro de las características de los lenguajes orientados a objetos se
detallan:
Objetos y clases: Un objeto está compuesta por una estructura de datos y de
una colección de métodos, los que en sus primeras versiones eran llamados
procedimientos o funciones, los cuales manipulan los datos o la información.
Los datos estructurados dentro de un objeto son llamados atributos, estos
objetos solo puede ser manejados por medio de su interfaz, lo que al final es
una colección de funciones que se implementan y son visibles al exterior.
Tanto
los
objetos
como
las
clases
contienen
muchas
características
Herencia: Es un mecanismo básico por el que las clases hijas heredan el
código de las clases padre. (Alvarez, 2014)
Polimorfismo:
El
polimorfismo
es
la
posibilidad
de
definir
clases
diferentes
que
tienen métodos o atributos llamados de forma idéntica, que se comportan de
manera distinta. Este concepto se puede aplicar tanto a funciones como a tipos
de datos. De aquí se deriva los conceptos defunciones polimórficas y tipos
polimórficos.
Funciones Poliformas: son aquellas funciones que pueden evaluarse o ser
aplicadas a diferentes tipos de datos de forma indistinta.
Tipos Poli fórmicos: Los tipos polimórficos, por su parte, son aquellos tipos de
datos que contienen al menos un elemento cuyo tipo no está especificado.
(EduRed)
17
INGENIERIA DE REQUERIMIENTOS AVANZADA
9. Especificación de Requerimientos ISO/IEEE 830
Las Especificaciones de Requerimientos de Software (ERS), es un plan o
documento que describe en forma completa y con un nivel de detalle todas las
iteraciones y elementos que se requiere para el desarrollo de un proyecto de
software y sus aplicativos. El ERS condiciona todos aquellos elementos que se
necesitan para construir una solución de software que cumplan con las normas
o metodologías aceptadas en el ámbito internacional.
10. Objetivos de la ERS.
Dentro de los objetivos de un ERS están desarrolladas las especificaciones de
requisitos para el desarrollo de una aplicación de software, entre ellos:
Guiar a los a los clientes/Usuarios para que logren describir de una

manera clara y objetiva lo que se desea desarrollar para obtener un
producto final mediante una aplicación de software, la participación debe
ser en forma activa y consecuente en el desarrollo y levantamiento de la
especificación de requisitos, ya que el cliente tiene visión global más
amplia y detallada de los procesos que se realizan en las labores diarias.
(Monferre Agut) (docslide.us/documents/9001.html)

Hacer comprender y conceptualizar a los desarrolladores y analistas lo
que se requiere concretamente debido a que en muchas ocasiones el
cliente/usuario no sabe exactamente o no entiende lo que se requiere.
(Monferre Agut)
La ERS permite definir todos los requisitos que
cumplan con la visión del producto a desarrollar y a los desarrolladores
tener una línea base para desarrollar el documento de requerimientos.
18
INGENIERIA DE REQUERIMIENTOS AVANZADA

Particularmente
del
condicionarse
la
línea
base
para
definir y
desarrollar de estándares y nomenclaturas de todo tipo para un ERS lo
que puede ser utilizado para cada proyecto del ciclo de vida de
sistemas.
Con el documento de especificación de requisitos el ingeniero del software
puede hacer referencia a la verificación y validación, así como
identificar las
mejoras y correcciones o actualizaciones en los procesos analizados.
La ERS es un documento que detalla ciertos elementos, de una forma
objetiva y de una determinada manera, el cuál debe cumplir con el
estándar
IEEE 830.
Una ERS forma parte de los entregables del ciclo de vida del proyecto en su
etapa
inicial que
debe
definir
correctamente
todos
los
requerimientos
necesarios para una mayor flexibilidad a los desarrolladores y analistas para la
implementación de la solución del software.
11. Características de un ERS
Dentro de características de un documento de especificación de requisitos
software se indican las siguientes:
19

Validez

Consistencia

Ambigüedad

Totalidad

Completitud

Realismo

Verificabilidad

Clasificación

Modificabilidad

Explorabilidad (traceability)

Utilizable durante las tareas de mantenimiento y uso
INGENIERIA DE REQUERIMIENTOS AVANZADA
11.1 Comprobación de validez
Se deben considerar y analizar para identificar las funciones adicionales o
diferentes que se requieran. Los sistemas tiene diversas participantes con
diversas
necesidades,
y
cualquier
conjunto
de
requerimientos
es
inevitablemente un compromiso a través de la comunidad de participantes.
11.2 Consistencia
Los requerimientos en el documento no deben estar en conflicto. Esto es, no
debe haber restricciones contradictorias o descripciones diferentes de la
misma función del sistema. Algunos casos son:

Los requisitos que detallan el mismo objeto real bajo diferente terminología.

Debe haber una característica específica para cada objeto real.

Si se llega a un conflicto lógico entre dos requisitos determinadas. las dos
acciones serían perfectamente válidas.

11.3. Ambigüedad
No deben darse en una palabra o una frase los múltiples significados, de lo
contrario se pueden incluir un glosario de significados.
11.4. Comprobación de Totalidad
El documento de requerimientos debe incluir requerimientos que definan
todas las funciones y restricciones pretendidas por el usuario del sistema.
20
INGENIERIA DE REQUERIMIENTOS AVANZADA
11.5 Completitud
Una ERS tiene completitud si:

Una descripción de la función o entidad a especificar.

Una descripción de sus entradas y sus procedencias.

Una descripción de sus salidas ya a donde se dirigen.

Información sobre los datos requeridos para el cálculo u otras entidades
en el sistema que se utilizan.

Una descripción de la acción que se va a tomar.

Se utiliza un determinado estándar. Por las razones suficientes si no se
utiliza el estándar determinado o un aparte de él, se debe realizar la
observación o nota qué no se ha utilizado dicho apartado.

Normas APA: el documento d debe cumplir con la norma APA en lo que
respecta a etiquetadas figuras, tablas, diagramas, términos y unidades
de medida empleados.
11.6 Verificabilidad
Significa que el requisito debe escribirse siempre de manera que sean
verificable.
11.7 Clasificación
No necesariamente todos los requisitos son igual o tienen la misma
importancia. Estos se pueden clasificar
por diversos criterios:
Importancia: Los requisitos opcionales, requisitos o condicionales.
Estabilidad: Diferentes formas de cambios que hacen un llamado a una
requisito, por lo que deben establecer prioridades, de modo que de un
requisito por su prioridad no emplee excesivos recursos.
11.8 Modificabilidad
Una ERS es modificable si cualquier cambio puede realizarse de manera
fácil, completa y consistente. Siendo así, lo más recomendado es tener una
organización coherente en la que aparezca el índice o una tabla de
contenidos fácilmente accesible. (docslide.us/documents/9001.html)
21
INGENIERIA DE REQUERIMIENTOS AVANZADA
A su vez también es recomendable evitar la redundancia, para que no
aparezca un mismo requisito en varios lugares del ERS, de tal forma, que para
modificar un error, será más cómodo si no tenemos que buscar el mismo
requisito en varios lugares. (docslide.us/documents/9001.html)
11.9 Explorabilidad (traceability)
Una ERS es explorable si el origen de cada requerimiento es claro tanto
hacia atrás (origen que puede ser un documento, una persona etc.) como
hacia delante (componentes del sistema que realizan dicho requisito).
(docslide.us/documents/9001.html) (docslide.us/documents/9001.html)
Cuando un requisito de la ERS está integrado o desglosado debe detectar
las referencias hacia atrás y adelante en el ciclo de vida. (Monferre Agut)
Las referencias hacia delante de la ERS son especialmente importantes para
el mantenimiento del software. Si el código y los documentos deben ser
modificados es primordial poder comparar el conjunto de requisitos que se ven
afectados.
11.10 Utilizable durante las tareas de mantenimiento y uso
Se debe considerar los procesos de mantenimiento incluyendo personal que
nunca ha intervenido directamente en el desarrollo y logre realizar con
capacidad su mantenimiento. (docslide.us/documents/9001.html)Así, dicha
ERS
actúa
a
modo
de
plano
de
la
aplicación,
permitiendo
incluso
modificaciones que no requieran un cambio en el diseño. (Monferre Agut)
(docslide.us/documents/9001.html)
En
muchas
circunstancias,
el
actores
del
desarrollo
suponen
algunos
conocimientos que el personal nuevo que se encargue del mantenimiento no
tiene por qué tener. (830) , por lo que ante esta cuestionamiento e
imprescindible que la documentación este correcta y que las funciones estén
detalladas
tanto
monitoreadas.
22
en
su
origen
para
que
puedan
ser
modificadas,
y
INGENIERIA DE REQUERIMIENTOS AVANZADA
12. Esquema de la ERS definida en el IEEE 830-1998
La especificación de requisitos del software es el producto final refinado del
desarrolló del análisis. La función y el comportamiento asignados al software
como parte de la ingeniería de sistemas
se refina, estableciendo una
descripción completa de la información, una descripción funcional detallada,
una indicación de los requisitos
de rendimiento y de las restricciones de
diseño, unos criterios de validación apropiados.
A continuación se retrata un perfil del formato propuesto por el IEEE 8301998.
I.
Introducción
a. Referencia del Sistemas
b. Descripción General
c. Restricciones el proyecto del Software
II.
Descripción de la Información
a. Representación del flujo d la información.
1. Flujo de Datos
2. Flujo de Control
b. Representación del contenido de la información
c. Descripción de la interfaz del sistema
III.
Descripción Funcional
a. Partición funcional
b. Descripción funcional
1. Narrativa de procesamiento
2. Restricciones/limitaciones
3. Requisitos de rendimiento
4. Restricciones de diseño
5. Diagramas de soporte
c. Descripción del control
1. Especificación del Control
2. Restricciones del diseño
23
INGENIERIA DE REQUERIMIENTOS AVANZADA
IV.
Descripción del comportamiento
a. Estados del Sistema
Sucesos y acciones
V.
Criterios de Validación
a. Límites de rendimiento
b. Clases de Pruebas
c. Respuesta esperada del software
d. Consideraciones especiales
VI.
Bibliográfica
VII.
Apéndice
Descripción de los apartados.
I. Introducción
La introducción describe los fines y los objetivos del software, describiéndoles
en el contexto de un sistema basado en computadora. Realmente la
introducción puede no ser nada más que el ámbito del documento de
planificación.
II. Descripción de la Información
La descripción de la información proporciona una descripción detallada del
problema que del software debe resolver. Estarán documentados el flujo y la
estructura de la información. Se describe el hardware, el software y las
interfaces humanas, para los elementos externos del sistema las funciones
internas del software.
III Descripción Funcional
La sección de descripción funcional proporciona una descripción de cada
función requerida para resolver el problema. Para cada función se da una
explicación del procedimiento, se establecen y justifican las restricciones de
diseño, se establecen las características del comportamiento y se incluyen uno
o más diagramas para representar gráficamente la estructura global del
software y la interrelación entre funciones y otros elementos del sistema.
24
INGENIERIA DE REQUERIMIENTOS AVANZADA
IV Descripción del comportamiento
La sección de descripción del comportamiento examina el funcionamiento
del software como una secuencia de los sucesos
externos y de las
características de control generadas internamente.
V Sección de Criterios de Validación
La sección de criterios de validación es probablemente la sección más
importante e, irónicamente, más descuidada de la especificación de requisitos
del software, ¿Cómo reconocer una implementación fructífera? ¿Qué clase de
pruebas se deben dirigir para validar la función, el rendimiento y las
restricciones?
.Descuidamos
esta
sección
porque
para
complementarla
necesitamos un profundo entendimiento de los requisitos del software. Sin
embargo, la especificación de los criterios de validación actúa como una
revisación implícita de los requisitos.
VI Bibliografía.
La especificación de requisitos del software incluye una bibliografía y un
apéndice. La
bibliografía
contiene
referencias
a todos
los
documentos
relacionados con el software, Aquí s e incluye cualquier otro documento de
ingeniería dl software, así como las referencias técnicas, los libros adquiridos y
los estándares.
El apéndice contiene información que complementa la especificación. En el
apéndice se presentan las tablas de datos, la descripción detallada de los
algoritmos, los diagramas, los gráficos y otro material.
25
INGENIERIA DE REQUERIMIENTOS AVANZADA
13.
Naturaleza de la Ingeniería de Requerimientos
La ingeniería de software es una disciplina que está orientada a aplicar
conceptos y métodos de ingeniería al desarrollo de software de calidad.
13.1.
Matemáticas
Los programas tienen muchas propiedades matemáticas. Por ejemplo la
corrección y la complejidad de muchos algoritmos son conceptos matemáticos
que pueden ser rigurosamente probados. El uso de matemáticas en la IS es
llamado métodos formales.
13.2. Creación
Los programas son construidos en una secuencia de pasos. El hecho de definir
propiamente y llevar a cabo estos pasos, como en una línea de ensamblaje, es
necesario para mejorar la productividad de los desarrolladores y la calidad final
de los programas. Este punto de vista inspira los diferentes procesos y
metodologías que se encuentran en la IS.
13.3. Gestión de Proyecto
El desarrollo de software de gran porte requiere una adecuada gestión del
proyecto. Hay presupuestos, establecimiento de tiempos de entrega, un equipo
de
profesionales
que
liderar.
Recursos
(espacio
de
oficina,
insumos,
equipamiento) por adquirir. Para su administración se debe tener una clara
visión y capacitación en gestión de proyectos.
26
INGENIERIA DE REQUERIMIENTOS AVANZADA
14.
Participantes y papeles
Para el desarrollo de un sistema de software es necesaria la colaboración de
muchas personas con diversas competencias, capacidades e intereses. Al
conjunto de personas involucradas en el proyecto se les conoce como
participantes.
Al conjunto de funciones y responsabilidades que hay dentro del proyecto o
sistema se le conoce como roles o papeles. Los roles están asociados a las
tareas que son asignadas a los participantes, en consecuencia, una persona
puede desempeñar uno o múltiples roles, así también un mismo rol puede ser
representado por un equipo.35
14.1.
Cliente
Es frecuente el uso de los términos "usuarios", "usuarios finales" y "clientes"
como sinónimos, lo cual puede provocar confusión; estrictamente, el cliente
(persona, empresa u organización) es quién especifica los requisitos del
sistema,36 en tanto que el usuario es quien utiliza u opera finalmente el
producto software, pudiendo ser o no el cliente.
14.2. Desarrolladores
Esta clase de participantes están relacionados con todas las facetas del proceso
de desarrollo del software. Su trabajo incluye la investigación, diseño,
implementación, pruebas y depuración del software. 37
14.3. Gestores
En el contexto de ingeniería de software, el gestor de desarrollo de software es
un participante, que reporta al director ejecutivo de la empresa que presta el
servicio de desarrollo. Es responsable del manejo y coordinación de los
recursos y procesos para la correcta entrega de productos de software,
mientras participa en la definición de la estrategia para el equipo de
desarrolladores, dando iniciativas que promuevan la visión de la empresa. 38
27
INGENIERIA DE REQUERIMIENTOS AVANZADA
14.4. Usuarios finales
El usuario final es quien interactúa con el producto de software una vez es
entregado.39 Generalmente son los usuarios los que conocen el problema, ya
que día a día operan los sistemas.
14.5. Código ético de un ingeniero de software
Un ingeniero de software debe tener un código donde aseguran, en la medida
posible, que los esfuerzos realizados se utilizarán para realizar el bien y deben
comprometerse para que la ingeniería de software sea una profesión benéfica
y respetada. Para el cumplimiento de esta norma, se toman en cuenta ocho
principios relacionados con la conducta y las decisiones tomadas por el
ingeniero;
donde
estos
principios
identifican
las
relaciones
éticamente
responsables de los individuos, grupos y organizaciones donde participen. Los
principios a los que deben sujetarse son sobre la sociedad, cliente y
empresario, producto, juicio, administración, profesión, colegas y por último el
personal.

Sociedad: Los ingenieros de software deben actuar de manera congruente
con el interés social, aceptando la responsabilidad total de su trabajo,
moderando los intereses con el bienestar social, aprobando el software
solamente si se tiene una creencia bien fundamentada, cooperando en los
esfuerzos para solucionar asuntos importantes de interés social, ser justo y
veraz en todas las afirmaciones relativas al software o documentos
asociados.

Cliente y empresario: Se debe actuar de manera tal que se llegue a
conciliar
los
mejores
intereses
de
los
clientes
y
empresarios,
congruentemente con el interés social. Estos deberán prestar servicios en
sus áreas de competencia, siendo honestos y francos sobre las limitaciones,
no utilizar un software que se obtenga ilegalmente o sin ética, usar la
propiedad de los clientes o empresarios de manera autorizada, mantener
secreto cualquier documento de información confidencial.
28
INGENIERIA DE REQUERIMIENTOS AVANZADA

Producto: Hay que asegurarse que los productos y sus modificaciones
cumplan con los estándares profesionales más altos posibles, procurando la
alta calidad, costos aceptables y una agenda razonable asegurando que los
costos y beneficios sean claros y aceptados por el empresario y el cliente.
Asegurar que las metas y objetivos de cualquier proyecto sean adecuados y
alcanzables.

Juicio: Se debe mantener una integridad e independencia en el juicio
profesional, moderando todo juicio técnico por la necesidad de apoyar y
mantener los valores humanos, mantener la objetividad profesional con
respecto a cualquier software o documento relacionado, no involucrarse en
prácticas financieras fraudulentas.

Administración: Se deberá asegurar una buena administración para
cualquier proyecto en el cual se trabaje, utilizando procedimientos efectivos
para promover la calidad y reducir riesgos, asegurándose también que se
conozcan las políticas y procedimientos del empresario para proteger
contraseñas, archivos e información confidencial.

Profesión: Se debe incrementar la integridad y reputación de la profesión
en conjunto con el interés social, ayudando al desarrollo de un ambiente
organizacional favorable para actuar, promoviendo el conocimiento público
de la ingeniería de software, extendiendo el conocimiento de la ingeniería
de software por medio de participaciones en organizaciones, reuniones y
publicaciones profesionales.

Colegas: Cada ingeniero deberá apoyar y ser justos con los colegas,
motivando a sus colegas sujetándose al código, ayudando también a su
desarrollo profesional, reconocer los trabajos de otros y abstenerse a
atribuirse de méritos indebidos, revisar los trabajos de manera objetiva,
sincera y propiamente documentada.
29
INGENIERIA DE REQUERIMIENTOS AVANZADA

Personal: Los ingenieros de software participaran toda su vida en el
aprendizaje con la práctica y promoverán un enfoque ético de la profesión,
mejorando su conocimiento de los avances en el análisis, especificación,
diseño, desarrollo, mantenimiento, pruebas del software y documentos
relacionados en conjunto con administración del proceso de desarrollo. 40
30
INGENIERIA DE REQUERIMIENTOS AVANZADA
15. Conclusiones
El análisis delos requisitos es e<l primer paso técnico del procesos de
ingeniería de requerimientos. Es en este punto donde se refina la declaración
general del ámbito del software en una especificación concreta que se
convierte en la base de todas las actividades de ingeniero de requerimientos
que siguen.
En análisis debe centrarse en los ámbitos d información, funcional, y de
comportamiento del problema. Para comprender mejor lo que se requiere, se
crean modelos, se parte del problema y desarrollan representaciones que
muestran la esencia de los requisitos y, posteriormente, los detalles de
implementación.
En muchos casos no es posible especificar completamente el problema en una
etapa tan temprana. La construcción de prototipos constituye un método
alternativo, que da como resultado un modelo ejecutable de software a partir
del
cual
se
pueda
refinar
los
requerimientos.
Para
poder
construir
adecuadamente el prototipo, se necesitan técnicas y herramientas especiales
31
INGENIERIA DE REQUERIMIENTOS AVANZADA
16. Bibliografía
830,
4.
/.
(s.f.).
49587242
/
ERS
Según
IEEE
830.
Obtenido
de
http://es.scribd.com/doc/49587242/ERS-Segun-IEEE-830
9001:2000, I. (15 de 12 de 2000). Quality management systems -Requirements.
Obtenido
de
http://www.iso.org/iso/catalogue_detail?csnumber=21823
Aguirre, C. (s.f.). NATURALEZA DE LA INGENIERÍA DE SOFTWARE. Obtenido
de http://caro9a.blogspot.com/
Alvarez, M. A. (10 de 04 de 2014). Herencia en Programación Orientada a
Objetos. Obtenido de http://www.desarrolloweb.com/articulos/herenciaen-programacion-orientada-objetos.html
Chelob.
(s.f.).
Proceso
de
desarrollo
de
software.
http://www.monografias.com/trabajos5/desof/desof.shtml.
docslide.us/documents/9001.html. (s.f.). Especificación de Requisitos Software
según. Obtenido de http://docslide.us/documents/9001.html
EduRed.
(s.f.).
Polimorfismo
(Informática).
http://www.ecured.cu/Polimorfismo_ (Inform%C3%A1tica).
F.J. Zarazaga , S., J. Nogueras , I., & M.A. , L. (s.f.). Necesidad de una
metodología: La estructurada y la Orientada a Objetos. Obtenido de
Ingeniería
del
Software
I:
https://sites.google.com/site/cursofpeanalistafuncional/necesidad-deuna-metodologia
F.J. Zarazaga Soria, J. N. (s.f.).
Necesidad de
una metodología: La
estructurada y la Orientada a Objetos. Obtenido de Ingeniería del
Software
I:
https://sites.google.com/site/cursofpeanalistafuncional/necesidad-deuna-metodologia
Flores, A. (s.f.). Esquema del ERS definida en el IEEE 830-1998. Obtenido de
http://dsv666.blogspot.com/
Galeon.com, H. (s.f.). REQUERIMIENTOS DEL SOFTWARE. Obtenido de
http://requerimientos.galeon.com/
32
INGENIERIA DE REQUERIMIENTOS AVANZADA
Ginebra, S. C. (s.f.). Número de referenciaISO 9001:2008(traducción oficial)©
ISO 2008NORMA INTERNACIONAL Traducción oficial Official translación
Traducción officielle. Obtenido de http://docslide.us/education/iso-90015584a66e071ba.html
http://es.slideshare.net/AldoMamani/norma-830,
http://es.slideshare.net/romulohuancaluque1/9001-2,
http://dsv666.blogspot.com/, http://es.scribd.com/doc/49587242/ERSSegun-IEEE-8,
&
http://docslide.us/documents/9001.html.
(s.f.).
Especificación de Requerimientos de Software según el estándar IEEE830. Obtenido de http://es.slideshare.net/AldoMamani/norma-830
I, D. d. (s.f.). E78. INGENIERÍA DEL SOFTWARE 5º CURSO DE INGENIERÍA
INFORMÁTICA 2000-2001. Obtenido de especificación de Requisitos
Software
según
el
estándar
de
IEEE
830:
http://docslide.us/documents/9001.html
InSlideShare. (s.f.). Especificación de Requisitos Software Según el Estándar
IEEE830.
Obtenido
de
http://es.slideshare.net/romulohuancaluque1/9001-29858820
International Organización for Standardization, I. (s.f.). We develop and
publish
International
Standards.
Obtenido
de
http://www.iso.org/iso/home.html
ISO.ORG.
(s.f.).
ISO
9000
-
Quality
management.
Obtenido
de
http://www.iso.org/iso/home/standards/managementstandards/iso_9000.htm
Miguel Angel, A. (s.f.). Polimorfismo en Programación Orientada a Objetos.
Obtenido
de
http://www.desarrolloweb.com/articulos/polimorfismo-
programacion-orientada-objetos-concepto.html
Monferre Agut, R. (s.f.). romulohuncaluque/9001-29858820 Especificación de
Requisitos según el Estándar IEEE 830. Obtenido de E78 Ingeniería del
Software: http://es.slideshare.net/romulohuancaluque1/9001-29858820
Monferrer Agut, R. (2001). Especificación de REquisitos Sotfwar. Obtenido de
http://es.slideshare.net/romulohuancaluque1/9001-29858820
33
INGENIERIA DE REQUERIMIENTOS AVANZADA
Piattini Velthuis, M. G. (01 de 09 de 1996). Análisis y Diseño detallado de
aplicaciones
Informáticas
de
Gestión.
Obtenido
de
http://www.agapea.com/libros/Analisis-y-Diseno-detallado-deaplicaciones-Informaticas-de-Gestion--9788478972333-i.htm
Pressman, R. S. (2005). Ingeniería del Software, Un Enfoque Práctico. México:
Mc Graw Hill.
scribd.com/doc/289109144/.
(s.f.).
scribd
/
wiki.
Obtenido
de
http://es.scribd.com/doc/289109144/Wiki
Society, I. C. (s.f.). 610.12-1990 - IEEE Standard Glossary of Software
Engineering
Terminology.
Obtenido
de
https://standards.ieee.org/findstds/standard/610.12-1990.html
Sommerville, I. (2005). Ingeniería del Software. Madrid, España: Pearson
Educación, S.A.
trackli.googlecode.com.
(s.f.).
EVOLUCION
DE
LA
.
Obtenido
de
http://trackli.googlecode.com/svn/trunk/Documentacion/Otra%20inform
acion/CMC/ingenieriasoftwaretematica.doc
34
Descargar
Fichas aleatorios
Prueba

4 Tarjetas Arthas Quinzel

tarjeta del programa pfizer norvasc

0 Tarjetas joseyepezsumino

tarjeta del programa pfizer norvasc

0 Tarjetas joseyepezsumino

tarjeta del programa pfizer norvasc

0 Tarjetas joseyepezsumino

free fire garena

1 Tarjetas Rene Jonathan Ramos Reyes

Crear fichas