Investigacion Unidad I Analisis

INSTITUTO TECNOLOGICO SUPERIOR
DE ALVARADO
INGENIERÍA EN SISTEMAS COMPUTACIONALES
MATERIA:
INGENIERIA DE SOFTWARE
SEMESTRE-GRUPO:
DECIMO SEMESTRE
PRODUCTO ACADÉMICO:
INVESTIGACION UNIDAD I ANALISIS
PRESENTA:
RAMON PRIETO CANO
DOCENTE:
GUADALUPE RAMÍREZ GARCÍA
H. Y G. ALVARADO, VER. ENE-JUN 2019

INVESTIGACION UNIDAD I
Instituto Tecnológico Superior de Alvarado
INDICE
INTRODUCCION ........................................................................................................................ 1
1.1 REVISION DE ESPECIFICACION DE REQUISITOS ................................................... 2
1.1.1 Norma IEEE830 ........................................................................................................... 3
1.1.2Trazabilidad de requisitos ......................................................................................... 4
1.2 Descripción de procesos actuales................................................................................ 5
1.3 Diagramas UML ................................................................................................................ 19
1.4 Estudio de Factibilidad .................................................................................................. 27
1.5 Análisis Costo-Beneficio ............................................................................................... 29
BIBLIOGRAFIA .................................................................................................................... 35
INTRODUCCION
La especificación de requisitos de software (ERS) es una descripción

completa del comportamiento del sistema que se va a desarrollar. Incluye un
conjunto de casos de uso que describe todas las interacciones que tendrán los
usuarios con el software. Los casos de uso también son conocidos
como requisitos funcionales. Además de los casos de uso, la ERS también
contiene requisitos no funcionales (complementarios). Los requisitos no
funcionales son requisitos que imponen restricciones en el diseño o la
implementación, como, por ejemplo, restricciones en el diseño o estándares de
calidad.
Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje

utilizado para su redacción debe ser informal, de forma que sea fácilmente
comprensible para todas las partes involucradas en el desarrollo.
INGENIERIA DE SOFTWARE 1
1.1 REVISION DE ESPECIFICACION DE REQUISITOS
Los requerimientos especifican qué es lo que el sistema debe hacer (sus

funciones) y sus propiedades esenciales y deseables. La captura de los
requerimientos tiene como objetivo principal la comprensión de lo que los clientes
y los usuarios esperan que haga el sistema. Un requerimiento expresa el
propósito del sistema sin considerar como se va a implantar. En otras palabras,
los requerimientos identifican el qué del sistema, mientras que el diseño
establece el cómo del sistema. La captura y el análisis de los requerimientos del
sistema es una de las fases más importantes para que el proyecto tenga éxito.
Como regla de modo empírico, el costo de reparar un error se incrementa en un
factor de diez de una fase de desarrollo a la siguiente, por lo tanto, la preparación
de una especificación adecuada de requerimientos reduce los costos y el riesgo
general asociado con el desarrollo [Norris & Rigby, 1994].
Análisis de requerimientos: Es el conjunto de técnicas y procedimientos

que nos permiten conocer los elementos necesarios para definir un proyecto de
software. Es una tarea de ingeniería del software que permite especificar las
características operacionales del software, indicar la interfaz del software con
otros elementos del sistema y establecer las restricciones que debe cumplir el
software.
Por lo mismo, es importante proporcionarle al alumno las bases para que

él se introduzca con profundidad en el mundo de los compiladores. Esta materia
abre horizontes impresionantes ya que se conoce a fondo las etapas por las que
atraviesa la creación de un lenguaje de computación. Desde la etapa léxica hasta
la etapa de generación de código, el estudiante debe profundizar en
conocimientos que colindan con la parte electrónica de la computadora, el
lenguaje ensamblador, el lenguaje máquina.
La especificación de requerimientos suministra al técnico y al cliente, los
medios para valorar el cumplimiento de resultados, procedimientos y datos, una
vez que se haya construido. La tarea de análisis de los requerimientos es un
proceso de descubrimiento y refinamiento, el cliente y el desarrollador tienen un
papel activo en la ingeniería de requerimientos de software. El cliente intenta
plantear un sistema que en muchas ocasiones es confuso para él, sin embargo,
es necesario que describa los datos, que especifique las funciones y el
comportamiento del sistema que desea. El objetivo es que el desarrollador actúe
como un negociador, un interrogador, un consultor, o sea, como persona que
consulta y propone para resolver las necesidades del cliente.
El análisis de requerimientos proporciona una vía para que los clientes y

lo desarrolladores lleguen a un acuerdo sobre lo que debe hacer el sistema. La
especificación, producto de este análisis proporciona las pautas a seguir a los
diseñadores del sistema. “La carencia de buenos requisitos ha sido la causa del
fracaso de proyectos con presupuestos de millones de dólares, ha impedido el
desarrollo productivo, y ha sido el mayor contribuyente de los costes elevados
del mantenimiento del software” (Dr. Raymond Yeh in the forward to System and
Software Requirements Engineering, IEEE Computer Society Press Tutorial,
Editors, M. Dorfman, and R.H Thayer, 1990)
1.1.1 Norma IEEE830
Recomendación para la Especificación de Requerimientos de Software de

la IEEE. Existe una organización muy importante a nivel internacional llamada
IEEE (Institute of Electrical and Electronics Engineers, en español le llaman
comúnmente la I triple E). Esta organización, produce estándares que se aplican
en muchas industrias del mundo. La IEEE, edita revistas de divulgación científica
con un prestigio muy alto, y también organiza congresos muy importantes en el
ámbito internacional. Por lo general, los libros de texto que hablan acerca de los
requerimientos de software, incluyendo estas notas, se basan en un estándar
emitido por la IEEE qué se aprobó en 1998, llamado: IEEE Std 830-1998. Std es
la forma de abreviar “Standard” en inglés y el número de la especificación es
830, fue aprobada en 1998 y es una revisión de un estándar previo aceptado en
1993, Por las siglas en inglés, SRS que significan: Software Requirements
Specifications, se acostumbra llamar SRS al documento de especificación. En el
IEEE Std 830-1998 se habla sobre las características que deben tener los
requerimientos (correctos, consistentes, completos, realistas, rastreables y
verificables), los tipos de requerimientos (funcionales y no funcionales), así como
lo que se debe tomar en cuenta al elaborarlos (ambiente físico, interfaces,
usuarios y factores humanos, funcionalidad, documentación, datos, recursos,
seguridad y aseguramiento de la calidad). En resumen, este estándar
recomienda lo que hemos visto hasta ahora a lo largo del curso. Lo más
importante del IEEE Std 830-1998 es que define la estructura que debe tener
una especificación de requerimientos, esta estructura se explica en la siguiente
sección. La IEEE Std 830-1998 es parte de los estándares que es necesario
cubrir cuando se pretende cumplir con las normas de calidad, por lo tanto, esta
estructura se respeta en la mayoría de las especificaciones de requerimientos
en cualquier parte del mundo cuando se elaboran sistemas de software a nivel
industrial.
En otras palabras, este documento realiza en primer lugar una serie de

recomendaciones para la consecución de una buena especificación de
requisitos, además de describir las partes de que debe constar.
1.1.2Trazabilidad de requisitos
La trazabilidad de requisitos es una herramienta fundamental para la

gestión de requisitos. Es elemental para el control y como apoyo para la toma de
decisiones en el proyecto. Como no es un entregable o componente del
producto, se debe cuidar que su creación y uso sea lo más eficiente posible. Se
define trazabilidad, o en algunos textos rastreabilidad, como la asociación del
requisito con otros requisitos y las diferentes instancias con que se relaciona
durante la evolución de las diferentes fases del ciclo de desarrollo del producto
o servicio. Esa asociación se controla en ambos sentidos, de los requisitos a los
resultados y viceversa. La intención principal es poder determinar si todos los
requisitos base han sido considerados y si las instancias que han sido generadas
pueden asociarse con un requisito válido.
1.2 Descripción de procesos actuales
En un mundo de cambios constantes y competencia global, las

organizaciones de desarrollo de software son presionadas a alcanzar mayor
eficiencia con menores costos. Para poder lograr este objetivo, es necesario
adoptar una forma de trabajo que permita entender, controlar, comunicar,
mejorar, predecir y certificar el trabajo realizado. Actualmente existe una gran
diversidad de opciones relacionadas con procesos de desarrollo.
Constantemente se escuchan diferentes acrónimos como CMM, CMMI, RUP,
ISO, PSP, TSP, etc., que causan confusión, principalmente debido a la mala
interpretación de los mismos.
Revisemos entonces los principales procesos de desarrollo y modelos

más utilizados al momento, así como los estándares relacionados.
¿Por qué contar con un proceso de software?
Hasta hace poco tiempo, la producción de software era realizada con un

enfoque artístico, a diferencia de un enfoque industrial. Ante la constante
presencia de proyectos fallidos, y con el objetivo de mejorar la calidad de los
productos, en los últimos años las organizaciones introdujeron los métodos de
ingeniería de software (Ver Fundamentos – Desarrollar software es mucho más
que programar, pág. 42).
A partir de estos, se formalizó el enfoque de ingeniería de producto para

desarrollar software. Factores como la globalización han obligado a las
organizaciones a contar con marcos de trabajo que las ayuden hacer las cosas
de la manera más eficiente. Fue entonces que se incorporó la ingeniería de
procesos al desarrollo de software.
Proceso
Antes de definir lo que es un proceso de desarrollo de software,

entendamos lo que es un proceso. Una definición sencilla de proceso es “serie
de acciones que conducen a un final”. Esta definición parece coincidir con las
ideas generales de la gente sobre procesos, pero deja muchas preguntas
abiertas. ¿El proceso es la forma en que la organización opera —desde
mercadotecnia hasta recursos humanos— o es la forma en que un desarrollador
diseña, produce código, o prueba el software? ¿El proceso se refiere a
administración, ingeniería, o ambas? ¿El proceso implica demasiada
documentación y nos abstiene de desarrollar el producto objetivo?
La respuesta a éstas puede variar dependiendo de la perspectiva. Sin

embargo, siempre que para alcanzar algún fin deseado necesitemos ejecutar
una serie de acciones, y estas acciones tengan cierto orden, dependencias, roles
responsables, resultados, tiempos de ejecución y herramientas de apoyo,
estaremos hablando de procesos, que pueden ser predefinidos y
personalizados.
Proceso de software
La meta de la ingeniería de software es construir productos de software,

o mejorar los existentes; en ingeniería de procesos, la meta es desarrollar o
mejorar procesos. Un proceso de desarrollo de software es un conjunto de
personas, estructuras de organización, reglas, políticas, actividades y sus
procedimientos, componentes de software, metodologías, y herramientas
utilizadas o creadas específicamente para definir, desarrollar, ofrecer un servicio,
innovar y extender un producto de software. Un proceso de software efectivo
habilita a la organización a incrementar su productividad al desarrollar software:
 Permite estandarizar esfuerzos, promover reusó, repetición y
consistencia entre proyectos.
 Provee la oportunidad de introducir mejores prácticas de la
industria.
 Permite entender que las herramientas deben ser utilizadas para
soportar un proceso.
 Establece la base para una mayor consistencia y mejoras futuras.
Un proceso de software mejora los esfuerzos de mantenimiento y soporte:
 Define cómo manejar los cambios y liberaciones a sistemas de

software existentes.
 Define cómo lograr la transición del software a la operación, y cómo
ejecutar los esfuerzos de operación y soporte.
Necesitamos un proceso de software cuya funcionalidad esté probada en

la práctica, y personalizado para que cumpla con nuestras necesidades
específicas.
Diversidad en Modelos
Actualmente existe una gran variedad de modelos para procesos de

software. Podemos entenderlos más fácilmente si los clasificamos en dos tipos:
genéricos y específicos.
Revisemos estos modelos para entender mejor su objetivo y estructura.

Primero conoceremos modelos genéricos como CMM e ISO, y posteriormente
estudiaremos modelos específicos para software.
CMM (Capability Maturity Model) - Modelo de Madurez de Capacidades
Marco que describe elementos clave de procesos efectivos de software.

Creado por el Software Engineering Institute (SEI) en conjunto con Carnegie
Mellon University. La primera versión se publicó en 1994.
CMM describe un camino evolutivo en 5 niveles de mejora de procesos para
lograr su madurez. Cubre prácticas de planeación, ingeniería y administración
del desarrollo y mantenimiento de software.
ISO 9001-2000
ISO (International Standards Organization) en 1987 crea la norma ISO

9000, conjunto de estándares que establecen los requerimientos para la gestión
de los sistemas de calidad. ISO 9000:2000 está formado por:
 ISO 9000 Fundamentos y Vocabulario.

 ISO 9001 Requisitos.
 ISO 9004 Recomendaciones.
La parte de Requisitos - ISO 9001:2000, está estructurado en 8 secciones:
 Alcance.
 Normas para la Consulta.
 Términos y Definiciones.
 Sistema de Gestión de la Calidad.
 Responsabilidad de la Dirección.
 Gestión de los Recursos.
 Realización del Producto.
 Medida, Análisis y Mejora.
Aunque ISO 9001:2000 no otorga un estándar específico para sistemas

de desarrollo de software, es decir, no abarca todos los procesos relacionados
con el desarrollo de software, muchas organizaciones de software han optado
por gestionar su sistema de calidad en base a este estándar, y obtener una
certificación reconocida de manera internacional.
CMMI (Capability Maturity Model Integration) - Modelo de Madurez de

Capacidades Integrado
El proyecto de CMMI fue concebido como una iniciativa para reunir los
diferentes CMMs en un conjunto de modelos integrados, más consistentes entre
ellos. Los modelos fuente que sirvieron como bases incluyen: CMM Software,
CMM Ingeniería de Sistemas, y CMM Desarrollo Integrado de Producto.
CMMI proporciona una guía para desarrollar procesos, que además ayuda
a evaluar la madurez de la organización o capacidad de un área de procesos.
CMMI incluye los procesos de ingeniería de software e ingeniería de sistemas.
El modelo está representado de forma continua y escalonada. Contiene 22 áreas
de procesos. Cada área de proceso está formada por: Objetivos específicos,
Prácticas específicas, Objetivos genéricos, y Prácticas genéricas.
10
CMMI Modelo Continuo
Está formado por 5 niveles de capacidad del proceso:
0. Incompleto
1. Desempeñado
2. Administrado
3. Definido
4. Administrado cuantitativamente
5. Optimizado
Y por cuatro categorías de áreas de procesos: Administración de

Procesos, Administración de Proyectos, Ingeniería, Soporte. Estas categorías
agrupan a las diferentes áreas de proceso, dividiéndolos en procesos básicos y
avanzados.
CMMI Modelo Escalonado
El modelo escalonado, al igual que CMM, describe un camino evolutivo

en 5 niveles de madurez de procesos, además integra nuevas áreas de proceso.
La selección entre el modelo escalonado y el continuo depende del

objetivo de la organización, además de tener que considerar la situación (si ya
se tiene CMM, cultura en procesos, etc.). Por ejemplo, si el objetivo es llevar a la
organización a cierto nivel de capacidad, deberá seleccionarse la forma
escalonada; en cambio si el objetivo es mejorar cierto proceso, será mejor seguir
la forma continua.
11
Algunos Beneficios de CMMI vs. CMM
Algunos de los beneficios que han experimentado las organizaciones que

pasan de CMM a CMMI son los siguientes:
 Mejor alineación a objetivos de negocio.

 Mejor visibilidad hacia las actividades de ingeniería, con el objetivo
de asegurar que el producto o servicio cumple las expectativas del
cliente.
 Aprovechamiento de mejores prácticas adicionales (e.j., medición,
riesgo, administración, y manejo de proveedores).
 Acoplamiento más estrecho con estándares de ISO.
ISO/IEC 15504
Estándar internacional que ofrece un marco para la evaluación de

procesos. Fue iniciado en 1991 como el proyecto SPICE (Software Process
Improvement and Capability dEtermination). La versión de Reporte Técnico fue
aceptada y publicada en 1998, enfocada únicamente en procesos de software.
En el transcurso de su desarrollo ha evolucionado, de ser un modelo de

referencia de buenas prácticas de software, para convertirse en un marco de
trabajo para evaluación de múltiples modelos (de software o no). Su dirección
actual es poder aplicarse a múltiples disciplinas y permitir a las diferentes
comunidades definir sus propios procesos específicos, modelos de referencia o
buenas prácticas. ISO 15504 está en vías de convertirse en estándar
internacional, y se espera que esté completo para 2006.
Esta versión está compuesta de cinco documentos, a diferencia del

reporte técnico que consta de nueve partes (Ver gráfica 1 - Estructura de
documentos). La parte 2 de este estándar es de especial interés, ya que es la
que define como se realiza una evaluación. Establece requisitos tanto para
12
modelos de procesos de referencia como para los métodos de evaluación sin
establecer alguno en particular.
Niveles de Capacidad (Ver gráfica 2):
1. Incompleto. - Falta de cumplimiento del proceso.
2. Realizado. - Genera los productos de trabajo esperados
3. Administrado. - Proceso y productos administrados y

controlados.
4. Establecido. - Proceso definido para la organización y utilizado

adecuadamente.
5. Predecible. - El proceso opera dentro de los límites estadísticos

establecidos.
6. Optimizado. - El proceso mejora continuamente.
Las organizaciones de software no tienen que seleccionar entre 15504 y

su modelo actual. El rol de 15504 es proveer un marco de trabajo en el que los
modelos y métodos de evaluación puedan existir de una manera armónica. No
está diseñado para ser utilizado solo. La selección radica en decidir si el
ajustarse a 15504 es importante para el negocio (¿El negocio compite en el
13
mercado global?, ¿Provee software a algún cliente que requiera 15504?,
¿Existen varios modelos de evaluación en la organización?). De ser así, deberán
elegir modelos que se ajusten a 15504.
Compatibilidad entre Modelos
ISO/IEC 15504
 Evaluación de procesos de software.

 En vías de ser estándar.
 Dirección amplia.
 Niveles de capacidad.
 Evaluación de capacidades por proceso individual.
 Guía para realizar la evaluación.
 Toma como referencia ISO 9001 y CMMI.
14
CMMI
 Modelo de madurez de procesos de software.

 Modelo – estándar de facto.
 Dirección detallada.
 Pasos progresivos (niveles) - Escalonada.
 Categorías de procesos - Continua.
 Guía para institucionalización e implementación.
 Modelo de evaluación será conforme al modelo de evaluación de
15504.
ISO 9001-2000
 Sistema de Gestión de la Calidad.

 Estándar internacional.
 Dirección amplia.
 Un conjunto de requerimientos a ser cubierto.
 No hay lineamientos para su implementación.
 Usado como referencia en actividades de gestión de calidad por
CMMI y 15504.
Con eso concluimos nuestra revisión de modelos genéricos. A

continuación, veamos los modelos específicos para software.
PSP – Personal Software ProcessSM
Personal Software Process (PSP) es un proceso diseñado para ayudar a

los ingenieros de software a controlar, manejar y mejorar su trabajo. PSP está
basado en una motivación: La calidad de software depende del trabajo de cada
uno de los ingenieros de software. Debido a que los costos de personal
constituyen 70% del costo del desarrollo de software, las capacidades y hábitos
de trabajo de los ingenieros determinan en gran manera los resultados del
desarrollo de software.
15
Basado en prácticas encontradas en CMM, el PSP puede ser usado por
ingenieros para estructurar y disciplinar el desarrollo de software. El ingeniero de
software podrá planear mejor el trabajo, conocer con precisión el desempeño,

medir la calidad de productos, y mejorar las técnicas.
PSP puede ser aplicado en:
 Desarrollo de programas.
 Definición de requerimientos.
 Documentación.
 Pruebas de sistemas.
 Mantenimiento de sistemas.
TSP - Team Software Process
Team Software Process (TSP) es un marco para el desarrollo de software

que pone igual énfasis en el proceso, producto y trabajo en equipo. Al igual que
PSP, TSP fue propuesto por Watts Humphrey.
TSP se basa en PSP, y se fundamenta en que el software, en su mayoría,

es desarrollado por equipos, por lo que los ingenieros de software deben primero
16
saber controlar su trabajo, y después saber trabajar en equipo. TSP le enseña a
los ingenieros a construir equipos auto dirigidos y desempeñarse como un
miembro efectivo del equipo. También muestra a los administradores como
guiar y soportar estos equipos.
Estrategia de TSP
 • Proveer un proceso sencillo basado en PSP.

 • Desarrollar productos en varios ciclos. Ciclo de TSP:
Lanzamiento, Estrategia, Plan, Requerimientos, Diseño,
Implementación, Pruebas, Postmortem.
 • Establecer medidas estándares para calidad y desempeño.
 • Proveer definiciones de roles, y evaluaciones de rol y de equipo.
 • Requiere disciplina de proceso.
 • Provee guía para manejo de problemas de trabajo en equipo.
RUP
El Rational Unified Process (RUP) es un proceso de software desarrollado

y comercializado por Rational Software (ahora parte de IBM).
17
RUP está diseñado alrededor de seis mejores prácticas para el desarrollo
de software:
 • Desarrollar de manera iterativa.

 • Administrar los requerimientos.
 • Utilizar arquitecturas basadas en componentes.
 • Modelar el software visualmente.
 • Verificar la calidad de manera continua.
 • Controlar los cambios.
En sí, RUP es una guía que define roles, actividades, flujos de trabajo y
lineamientos para ejecutar proyectos de software de acuerdo a estas mejores
prácticas. RUP organiza los proyectos de software en dos dimensiones: la del
tiempo y la de las actividades. En base al tiempo, los proyectos se dividen en
cuatro fases secuenciales:
1. Concepción – Definición de alcance, identificación de riesgos.

2. Elaboración – Resolución de riesgos, establecimiento de arquitectura.
3. Construcción – Generación del producto.
4. Transición – Disponibilidad a la comunidad de usuarios finales.
Las actividades se organizan en nueve diferentes disciplinas que son

ejecutadas durante las diferentes fases.
18
En realidad, RUP es un framework (marco de trabajo) que pretende ser
personalizado o configurado para organizaciones y proyectos específicos. RUP
no se puede aplicar de la misma forma en todos los proyectos de una
organización. Es por esto que pretender seguir RUP a través de ir cumpliendo
con la lista de artefactos que define, es una estrategia poco efectiva. Lo que las
organizaciones deben hacer es entender la razón de ser de RUP – las prácticas
citadas anteriormente – y en base a esto aplicar lo que decidan que es
conveniente para cada área o proyecto específico.
RUP es una instancia particular del Proceso Unificado, definido por Ivar
Jacobson, Grady Booch y James Rumbaugh en el libro “The Unified Software
Development Process” de 1998. Adicionalmente existen otras instancias de este
proceso, tales como el Proceso Unificado Mejorado (Enhanced Unified Process),
el cual agrega soporte multiproyectos y fases y disciplinas para el mantenimiento
y retiro de sistemas de software.
1.3 Diagramas UML
El Lenguaje Unificado de Modelado (UML) fue creado para forjar un

lenguaje de modelado visual común y semántica y sintácticamente rico para la
arquitectura, el diseño y la implementación de sistemas de software complejos,
tanto en estructura como en comportamiento. UML tiene aplicaciones más allá
del desarrollo de software, p. ej., en el flujo de procesos en la fabricación.
Es comparable a los planos usados en otros campos y consiste en diferentes
tipos de diagramas. En general, los diagramas UML describen los límites, la
estructura y el comportamiento del sistema y los objetos que contiene. UML no
es un lenguaje de programación, pero existen herramientas que se pueden usar
para generar código en diversos lenguajes usando los diagramas UML. UML
guarda una relación directa con el análisis y el diseño orientados a objetos. UML
y su función en el modelado y diseño orientados a objetos.
Hay muchos paradigmas o modelos para la resolución de problemas en

la informática, que es el estudio de algoritmos y datos. Hay cuatro categorías de
19
modelos para la resolución de problemas: lenguajes imperativos, funcionales,
declarativos y orientados a objetos (OOP). En los lenguajes orientados a objetos,
los algoritmos se expresan definiendo 'objetos' y haciendo que los objetos
interactúen entre sí. Esos objetos son cosas que deben ser manipuladas y
existen en el mundo real. Pueden ser edificios, artefactos sobre un escritorio o
seres humanos.
Los lenguajes orientados a objetos dominan el mundo de la programación

porque modelan los objetos del mundo real. UML es una combinación de varias
notaciones orientadas a objetos: diseño orientado a objetos, técnica de
modelado de objetos e ingeniería de software orientada a objetos. UML usa las
fortalezas de estos tres enfoques para presentar una metodología más uniforme
que sea más sencilla de usar. UML representa buenas prácticas para la
construcción y documentación de diferentes aspectos del modelado de sistemas
de software y de negocios.
La historia y los orígenes de UML
"The Three Amigos" (los tres amigos) de la ingeniería de software, como

se los conocía, habían desarrollado otras metodologías. Se asociaron para
brindar claridad a los programadores creando nuevos estándares. La
colaboración entre Grady, Booch y Rumbaugh fortaleció los tres métodos y
mejoró el producto final. Los esfuerzos de estos pensadores derivaron en la
publicación de los documentos UML 0.9 y 0.91 en 1996. Pronto se hizo evidente
que varias organizaciones, incluidas Microsoft, Oracle e IBM, consideraron que
UML era esencial para su propio desarrollo de negocios. Ellos, junto con muchas
otras personas y compañías, establecieron los recursos necesarios para
desarrollar un lenguaje de modelado hecho y derecho. "Los tres amigos"
publicaron la Guía del usuario para el Lenguaje Unificado de Modelado en 1999,
y una actualización que incluye información sobre UML 2.0 en la segunda edición
de 2005.
OMG: Tiene un significado diferente
20
Según su sitio web, el Object Management Group® (OMG®) es un
consorcio internacional sin fines de lucro y de membresía abierta para
estándares tecnológicos, fundado en 1989. Los estándares de OMG son
promovidos por proveedores, usuarios finales, instituciones académicas y
agencias gubernamentales. Los grupos de trabajo de OMG desarrollan
estándares de integración empresarial para una amplia gama de tecnologías y
una gama incluso más amplia de industrias. Los estándares de modelado de
OMG, incluidos UML y Model Driven Architecture® (MDA®), permiten un eficaz
diseño visual, ejecución y mantenimiento de software y otros procesos. OMG
supervisa la definición y el mantenimiento de las especificaciones de UML. Esta
supervisión ofrece a los ingenieros y programadores la capacidad de usar un
lenguaje para muchos propósitos durante todas las etapas del ciclo de vida del
software en sistemas de cualquier tamaño.
La finalidad de UML según OMG
El OMG define los propósitos de UML de la siguiente manera:
 Brindar a arquitectos de sistemas, ingenieros y desarrolladores de

software las herramientas para el análisis, el diseño y la
implementación de sistemas basados en software, así como para
el modelado de procesos de negocios y similares.
 Hacer progresar el estado de la industria permitiendo la

interoperabilidad de herramientas de modelado visual de objetos.
No obstante, para habilitar un intercambio significativo de
información de modelos entre herramientas, se requiere de un
acuerdo con respecto a la semántica y notación.
21
UML cumple con los siguientes requerimientos:
 Establecer una definición formal de un metamodelo común basado

en el estándar MOF (Meta-Object Facility) que especifique la
sintaxis abstracta del UML. La sintaxis abstracta define el conjunto
de conceptos de modelado UML, sus atributos y sus relaciones, así
como las reglas de combinación de estos conceptos para construir
modelos UML parciales o completos.
 Brindar una explicación detallada de la semántica de cada

concepto de modelado UML. La semántica define, de
manera independiente a la tecnología, cómo los conceptos UML se
habrán de desarrollar por las computadoras.
 Especificar los elementos de notación de lectura humana para

representar los conceptos individuales de modelado UML, así
como las reglas para combinarlos en una variedad de diferentes
tipos de diagramas que corresponden a diferentes aspectos de los
sistemas modelados.
 Definir formas que permitan hacer que las herramientas UML

cumplan con esta especificación. Esto se apoya (en una
especificación independiente) con una especificación basada en
XML de formatos de intercambio de modelos correspondientes
(XMI) que deben ser concretados por herramientas compatibles.
UML y el modelado de datos
El UML es popular entre programadores, pero no suele ser usado por

desarrolladores de bases de datos. Una razón es sencillamente que los
creadores de UML no se enfocaron en las bases de datos. A pesar de ello, el
22
UML es efectivo para el modelado de alto nivel de datos conceptuales y se puede
usar en diferentes tipos de diagramas UML. Puedes encontrar información sobre
la multidimensional dado de un modelo de clases orientado a objetos en una
base de datos relacional en este artículo sobre Modelado de bases de datos en
UML.
Actualizaciones en UML 2.0
El UML se perfecciona continuamente. UML 2.0 extiende las

especificaciones de UML para cubrir más aspectos de desarrollo, incluido Agile.
La meta era reestructurar y perfeccionar UML de forma que la facilidad de uso,
la implementación y la adaptación se simplificaran. Estas son algunas de las
actualizaciones de los diagramas UML:
 Mayor integración entre modelos estructurales y de

comportamiento.
 Capacidad de definir jerarquía y desglosar un sistema de software
en componentes y subcomponentes.
 UML 2.0 eleva el número de diagramas de 9 a 13.
Conceptos de modelado especificados por UML
El desarrollo de sistemas se centra en tres modelos generales de sistemas

diferentes:
 Funcionales: Se trata de diagramas de casos de uso que

describen la funcionalidad del sistema desde el punto de vista del
usuario.
 De objetos: Se trata de diagramas de clases que describen la

estructura del sistema en términos de objetos, atributos,
asociaciones y operaciones.
23
 Dinámicos: Los diagramas de interacción, los diagramas de

máquina de estados y los diagramas de actividades se usan para
describir el comportamiento interno del sistema.
Estos modelos de sistemas se visualizan a través de dos tipos diferentes

de diagramas: estructurales y de comportamiento.
Conceptos orientados a objetos en UML
Los objetos en UML son entidades del mundo real que existen a nuestro
alrededor. En el desarrollo de software, los objetos se pueden usar para
describir, o modelar, el sistema que se está creando en términos que sean
pertinentes para el dominio. Los objetos también permiten la descomposición de
sistemas complejos en componentes comprensibles que permiten que se
construya una pieza a la vez.
Estos son algunos conceptos fundamentales de un mundo orientado a

objetos:
 Objetos Representan una entidad y el componente básico.

 Clase Plano de un objeto.
 Abstracción Comportamiento de una entidad del mundo real.
 Encapsulación Mecanismo para enlazar los datos y ocultarlos del
mundo exterior.
 Herencia Mecanismo para crear nuevas clases a partir de una
existente.
 Polimorfismo Define el mecanismo para salidas en diferentes
formas.
Tipos de diagramas UML. usa elementos y los asocia de diferentes formas

para formar diagramas que representan aspectos estáticos o estructurales de un
24
sistema, y diagramas de comportamiento, que captan los aspectos dinámicos de
un sistema.
Diagramas UML estructurales
Diagrama de clases El diagrama UML más comúnmente usado, y la base

principal de toda solución orientada a objetos. Las clases dentro de un sistema,
atributos y operaciones, y la relación entre cada clase. Las clases se agrupan
para crear diagramas de clases al crear diagramas de sistemas grandes.
Diagrama de componentes Muestra la relación estructural de los

elementos del sistema de software, muy frecuentemente empleados al trabajar
con sistemas complejos con componentes múltiples. Los componentes se
comunican por medio de interfaces.
Diagrama de estructura compuesta Los diagramas de estructura

compuesta se usan para mostrar la estructura interna de una clase. Diagrama
de implementación Ilustra el hardware del sistema y su software. Útil cuando se
implementa una solución de software en múltiples máquinas con configuraciones
únicas.
Diagrama de objetos Muestra la relación entre objetos por medio de

ejemplos del mundo real e ilustra cómo se verá un sistema en un momento dado.
Dado que los datos están disponibles dentro de los objetos, estos pueden usarse
para clarificar relaciones entre objetos.
Diagrama de paquetes Hay dos tipos especiales de dependencias que

se definen entre paquetes: la importación de paquetes y la fusión de paquetes.
Los paquetes pueden representar los diferentes niveles de un sistema para
revelar la arquitectura. Se pueden marcar las dependencias de paquetes para
mostrar el mecanismo de comunicación entre niveles.
25
Diagramas UML de comportamiento
Diagramas de actividades Flujos de trabajo de negocios u operativos

representados gráficamente para mostrar la actividad de alguna parte o
componente del sistema. Los diagramas de actividades se usan como una
alternativa a los diagramas de máquina de estados.
Diagrama de comunicación Similar a los diagramas de secuencia, pero

el enfoque está en los mensajes que se pasan entre objetos. La misma
información se puede representar usando un diagrama de secuencia y objetos
diferentes.
Diagrama de panorama de interacciones Hay siete tipos de diagramas

de interacciones. Este diagrama muestra la secuencia en la cual actúan.
Diagrama de secuencia Muestra cómo los objetos interactúan entre sí y el orden
de la ocurrencia. Representan interacciones para un escenario concreto.
Diagrama de máquina de estados Similar a los diagramas de

actividades, describen el comportamiento de objetos que se comportan de
diversas formas en su estado actual.
Diagrama de temporización Al igual que en los diagramas de secuencia,

se representa el comportamiento de los objetos en un período de tiempo dado.
Si hay un solo objeto, el diagrama es simple. Si hay más de un objeto, las
interacciones de los objetos se muestran durante ese período de tiempo
particular.
Diagrama de caso de uso Representa una funcionalidad particular de un

sistema. Se crea para ilustrar cómo se relacionan las funcionalidades con sus
controladores (actores) internos/externos.
26
1.4 Estudio de Factibilidad
DEFINICION DE FACTIBILIDAD
Según la real academia factibilidad es: La cualidad de factible, factible:

que se puede hacer.
Factibilidad se refiere a la disponibilidad de los recursos necesarios para

llevar a cabo los objetivos o metas señalados. Generalmente la factibilidad se
determina sobre un proyecto.
ESTUDIO DE FACTIBILIDAD
Es el análisis para determinar: Si el proyecto que se propone será bueno

o malo, y en cuales condiciones se de.be desarrollar para que sea exitoso.
El estudio incluye los objetivos, alcances y restricciones sobre el sistema,

además de un modelo lógico de alto nivel del sistema actual (si existe). A partir
de esto, se crean soluciones alternativas para el nuevo sistema, analizando para
cada una de estas, diferentes tipos de factibilidades.
Los tipos de factibilidades básicamente son:
 Factibilidad técnica: si existe o está al alcance la tecnología

necesaria para el sistema.
 Factibilidad económica: relación beneficio costo.
 Factibilidad operacional u organizacional: si el sistema puede
funcionar en la organización.
Para cada solución factible, se presenta una planificación preliminar de su

implementación.
27
Estos resultados se entregan a la gerencia, quienes son los que aprueban
la realización del sistema el estudio de factibilidad, es una tarea que suele estar
organizada y realizada por los analistas de sistemas. El estudio consume
aproximadamente entre un 5% y un 10% del costo estimado total del proyecto, y
el periodo de elaboración del mismo varía dependiendo del tamaño y tipo de
sistema a desarrollar.
DIFERENCIA ENTRE VIABILIDAD Y FACTIBILIDAD
VIABILIDAD FACTIBILIDAD
* Que además de ser un proyecto * se puede decir que un proyecto

factible, debe ser sostenible, rentable factible es un proyecto que se puede
económicamente. realizar, que es posible de realizar.
* Capacidad de un proyecto de * determina si el proyecto que se

lograr un buen desempeño financiero. propone será bueno o malo, y en
cuales condiciones se debe desarrollar
para que sea exitoso.
28
1.5 Análisis Costo-Beneficio
La técnica de análisis coste/beneficio tiene como objetivo fundamental

proporcionar una medida de los costes en que se incurre en la realización de un
proyecto y comparar dichos costes previstos con los beneficios esperados de la
realización de dicho proyecto. Esta medida o estimación servirá́ para:
 Valorar la necesidad y oportunidad de acometer la realización del

proyecto.
 Seleccionar la alternativa más beneficiosa para la realización del
proyecto.
 Estimar adecuadamente los recursos económicos necesarios en el
plazo de realización del proyecto.
Es de destacar la necesidad cada vez mayor de guiarse por criterios

económicos y no sólo técnicos para la planificación de trabajos y proyectos. Por
ello se hace una primera introducción sobre las técnicas y métodos de evaluación
de conceptos económicos, con el fin de proporcionar a los profesionales criterios
que les ayuden en la planificación de proyectos y evaluación de alternativas.
Conceptos
Punto de amortización (Break-Even Point)
Es el momento en el tiempo en que el conjunto de beneficios obtenidos

por la explotación del nuevo sistema iguala al conjunto de costes de todo tipo
que ha ocasionado. A partir del punto de amortización (Break-Oven Point), el
sistema entra en fase de aportar beneficios netos a la organización.
Periodo de amortización (PayBack)
Es el periodo de tiempo que transcurre desde que los costes son máximos
hasta que se alcanza el punto de amortización (Break-Even Point), es decir, en
29
cuanto el sistema empieza a aportar beneficios. Cuanto menor sea el periodo de
amortización (Payback) de un Sistema, más atractivo será́ para la organización
acometer su implantación.
Retorno de la Inversión – ROI (Return of Investment)
Es el rendimiento de la inversión expresada en términos de porcentaje.

Se calcula mediante la fórmula siguiente:
ROI = 100 x (Beneficio Neto Anual – Coste Desarrollo Anualizado) /

Inversión Promedio
Siendo:
Beneficio Neto Anual: Es la ganancia que aporta el sistema como

consecuencia de su uso, es decir los beneficios obtenidos más los gastos no
incurridos. Deben restársele los gastos operacionales anuales y los de
mantenimiento del sistema.
Coste Desarrollo Anualizado: Total del gasto inicial de desarrollo del

sistema, dividido por los años que se supone que va a ser operativo.
Inversión Promedio: Total de la inversión realizada (costes de desarrollo,

hardware, software, etc.) dividido por el total de conceptos en los que se invierte.
Descripción
Para la realización del análisis coste/beneficio se seguirán los siguientes

pasos:
1. Producir estimaciones de costes/beneficios.
2. Determinar la viabilidad del proyecto y su aceptación.
30
PRODUCIR ESTIMACIONES DE COSTES-BENEFICIOS
Se realizará una lista de todo lo que es necesario para implementar el

sistema y una lista de los beneficios esperados del nuevo sistema.
En general, los costes suelen ser medibles y estimables en unidades

económicas, no así́ los beneficios, los cuales pueden ser tangibles o no
tangibles. En un análisis de costes y beneficios se deben considerar aquellos
aspectos tangibles, es decir, medibles en valores como dinero, tiempo, etc., y no
tangibles, es decir, no ponderables de una forma objetiva.
Entre los beneficios no tangibles pueden estar:
 El aumento de cuentas debido a un mejor servicio a los clientes.
 La mejora en la toma de decisiones debido a una mejora en el

soporte informático.
La valoración de los beneficios no tangibles se debe estimar de una forma

subjetiva y será́ realizada por las áreas correspondientes. A menudo es
conveniente desglosar los costes estimados a lo largo del proyecto, para ofrecer
una información más detallada de la distribución de los recursos de cara a la
dirección. En la estimación de costes se considerarán, entre otros, los siguientes
aspectos:
Adquisición de hardware y software: El que sea preciso para el

desarrollo, implantación y normal funcionamiento del sistema. Se debe
considerar la saturación de máquinas o sistemas actuales como consecuencia
de la entrada en vigor del nuevo sistema.
 Gastos de mantenimiento de hardware y software anteriores.
31
 Gastos de comunicaciones: Líneas, teléfono, correo, etc.
 Gastos de instalación: Cableado, acondicionamiento de sala,
recursos humanos y materiales, gastos de viaje, etc.
 Coste de desarrollo del sistema.
 Gastos del mantenimiento del sistema: Coste anual.
 Gastos de consultoría: En caso de requerirse algún consultor
externo en cualquier etapa del proyecto.
 Gastos de formación: De todo tipo (Desarrolladores, Operadores,
Implantadores, Usuario Final, etc.).
 Gastos de material: Papel, tóner, etc.
 Costes derivados de la curva de aprendizaje: De todo el
personal involucrado: Desarrolladores, Técnicos de Sistemas,
Operadores, y desde luego, Usuarios.
 Costes financieros, de publicidad, etc.
En la estimación de beneficios se pueden considerar cuestiones como las

siguientes:
 Incremento de la productividad: Ahorro o mejor utilización de

recursos humanos.
 Ahorro de gastos de mantenimiento del sistema actual.
 Ahorros de adquisición y mantenimiento de hardware y
software, o reutilización de plataformas sustituidas.
 Incremento de ventas o resultados, disminución de costes:
Producidos por una mejora de la gestión (rotación de stock, “just in
time”, analítica de clientes, etc.).
 Ahorro de material de todo tipo: Sustituido por datos electrónicos
que proporciona el sistema, como, por ejemplo: papel, correo, etc.
 Beneficios financieros.
 Otros beneficios tangibles: Ahorro de recursos externos,
consultoría, formación, etc.
 Beneficios intangibles: Incremento de la calidad del producto o
servicio, mejora de la imagen de la compañía, mejora en la atención
al cliente, mejora en la explotación, etc.
32
2. DETERMINAR LA VIABILIDAD DEL PROYECTO
Se basará en uno de los métodos siguientes:
Retorno de la Inversión:
Este método consiste en calcular el coste y el beneficio anual, conociendo

el coste total al inicio del proyecto “C0”, para determinar en qué año se recupera
el coste total inicialmente estimado.
AÑO COSTE BENEFICIO BENEFICIO NETO
0 C0 0
1 C1 B1 B1 – C1
2 C2 B2 B2 – C2
n Cn Bn Bn – Cn
El año de recuperación de la inversión se produce cuando ∑ Beneficio

Neto = C0.
Valor Actual:
Este método permite tener en cuenta que un gasto invertido durante un

cierto tiempo produce un beneficio.
33
El método consiste en determinar el dinero que es viable invertir
inicialmente para que se recupere la inversión en un periodo de tiempo definido
previamente.
El resultado depende del tipo de interés (r) utilizado en la evaluación.
Se debe calcular, en primer lugar, el beneficio neto que se obtendrá́ cada

año. Dicho beneficio no es real, ya que se debe estimar el valor real de dicha
cantidad en el año n.
Para ello se aplica la fórmula:
Valor Actual = Beneficio neto / (1 + r/100)n siendo n = año 1,..,i
Se debe estudiar en cuántos años se recupera la inversión realizada

inicialmente, o bien, si en un periodo de años fijado previamente se retorna la
inversión y, por tanto, es viable el proyecto.
Si la inversión es el C0, se determinará la viabilidad del proyecto

consultando la siguiente tabla:
34
BIBLIOGRAFIA
1. https://manuel.cillero.es/doc/metrica-3/tecnicas/analisis-coste-
beneficio/
2. https://es.calameo.com/read/0045049142e90c91fe944
3. file:///C:/Users/root/Downloads/docdownloader.com_especificacion-
de-requerimientos-norma-ieee-830.pdf
4. http://www.cua.uam.mx/pdfs/conoce/libroselec/Notas_Analisis_Requ
erimiento.pdf
5. http://www.cua.uam.mx/pdfs/conoce/libroselec/Notas_Analisis_Requ
erimiento.pdf
35

Investigacion Unidad I Analisis

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Investigacion Unidad I Analisis

Cargado por

Copyright:

Formatos disponibles

INSTITUTO TECNOLOGICO SUPERIOR

INGENIERÍA EN SISTEMAS COMPUTACIONALES

INVESTIGACION UNIDAD I ANALISIS

RAMON PRIETO CANO

GUADALUPE RAMÍREZ GARCÍA

H. Y G. ALVARADO, VER. ENE-JUN 2019

1.1 REVISION DE ESPECIFICACION DE REQUISITOS ................................................... 2

1.1.1 Norma IEEE830 ........................................................................................................... 3

1.1.2Trazabilidad de requisitos ......................................................................................... 4

1.2 Descripción de procesos actuales................................................................................ 5

1.3 Diagramas UML ................................................................................................................ 19

1.4 Estudio de Factibilidad .................................................................................................. 27

1.5 Análisis Costo-Beneficio ............................................................................................... 29

La especificación de requisitos de software (ERS) es una descripción

Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje

Los requerimientos especifican qué es lo que el sistema debe hacer (sus

Análisis de requerimientos: Es el conjunto de técnicas y procedimientos

Por lo mismo, es importante proporcionarle al alumno las bases para que

El análisis de requerimientos proporciona una vía para que los clientes y

1.1.1 Norma IEEE830

Recomendación para la Especificación de Requerimientos de Software de

En otras palabras, este documento realiza en primer lugar una serie de

La trazabilidad de requisitos es una herramienta fundamental para la

1.2 Descripción de procesos actuales

En un mundo de cambios constantes y competencia global, las

Revisemos entonces los principales procesos de desarrollo y modelos

¿Por qué contar con un proceso de software?

Hasta hace poco tiempo, la producción de software era realizada con un

A partir de estos, se formalizó el enfoque de ingeniería de producto para

Antes de definir lo que es un proceso de desarrollo de software,

La respuesta a éstas puede variar dependiendo de la perspectiva. Sin

La meta de la ingeniería de software es construir productos de software,

Un proceso de software mejora los esfuerzos de mantenimiento y soporte:

 Define cómo manejar los cambios y liberaciones a sistemas de

Necesitamos un proceso de software cuya funcionalidad esté probada en

Actualmente existe una gran variedad de modelos para procesos de

Revisemos estos modelos para entender mejor su objetivo y estructura.

CMM (Capability Maturity Model) - Modelo de Madurez de Capacidades

Marco que describe elementos clave de procesos efectivos de software.

ISO (International Standards Organization) en 1987 crea la norma ISO

 ISO 9000 Fundamentos y Vocabulario.

Aunque ISO 9001:2000 no otorga un estándar específico para sistemas

CMMI (Capability Maturity Model Integration) - Modelo de Madurez de

Está formado por 5 niveles de capacidad del proceso:

Y por cuatro categorías de áreas de procesos: Administración de

CMMI Modelo Escalonado

El modelo escalonado, al igual que CMM, describe un camino evolutivo

La selección entre el modelo escalonado y el continuo depende del

Algunos de los beneficios que han experimentado las organizaciones que

 Mejor alineación a objetivos de negocio.

Estándar internacional que ofrece un marco para la evaluación de

En el transcurso de su desarrollo ha evolucionado, de ser un modelo de

Esta versión está compuesta de cinco documentos, a diferencia del

Niveles de Capacidad (Ver gráfica 2):

1. Incompleto. - Falta de cumplimiento del proceso.

2. Realizado. - Genera los productos de trabajo esperados

3. Administrado. - Proceso y productos administrados y

4. Establecido. - Proceso definido para la organización y utilizado

5. Predecible. - El proceso opera dentro de los límites estadísticos

6. Optimizado. - El proceso mejora continuamente.

Las organizaciones de software no tienen que seleccionar entre 15504 y

Compatibilidad entre Modelos

 Evaluación de procesos de software.