Investigacion Unidad I Analisis.docx

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

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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.

INGENIERIA DE SOFTWARE

2

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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

INGENIERIA DE SOFTWARE

3

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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

INGENIERIA DE SOFTWARE

4

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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

INGENIERIA DE SOFTWARE

5

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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:

INGENIERIA DE SOFTWARE

6

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

 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.

INGENIERIA DE SOFTWARE

7

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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

INGENIERIA DE SOFTWARE

primera

versión

se

publicó

en

1994.

8

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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. INGENIERIA DE SOFTWARE

9

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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.

INGENIERIA DE SOFTWARE 10

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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.

INGENIERIA DE SOFTWARE 11

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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 INGENIERIA DE SOFTWARE 12

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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

INGENIERIA DE SOFTWARE 13

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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.

INGENIERIA DE SOFTWARE 14

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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.

INGENIERIA DE SOFTWARE 15

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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

INGENIERIA DE SOFTWARE 16

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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).

INGENIERIA DE SOFTWARE 17

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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. 2. 3. 4.

Concepción – Definición de alcance, identificación de riesgos. Elaboración – Resolución de riesgos, establecimiento de arquitectura. Construcción – Generación del producto. Transición – Disponibilidad a la comunidad de usuarios finales.

Las actividades se organizan en nueve diferentes disciplinas que son ejecutadas durante las diferentes fases.

INGENIERIA DE SOFTWARE 18

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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

INGENIERIA DE SOFTWARE 19

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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

INGENIERIA DE SOFTWARE 20

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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.

INGENIERIA DE SOFTWARE 21

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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

INGENIERIA DE SOFTWARE 22

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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.

INGENIERIA DE SOFTWARE 23

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

 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

INGENIERIA DE SOFTWARE 24

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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.

INGENIERIA DE SOFTWARE 25

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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.

INGENIERIA DE SOFTWARE 26

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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.

INGENIERIA DE SOFTWARE 27

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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 factible, debe ser sostenible, rentable económicamente.

* se puede decir que un proyecto factible es un proyecto que se puede realizar, que es posible de realizar.

* Capacidad de un proyecto de lograr un buen desempeño financiero.

* determina si el proyecto que se propone será bueno o malo, y en cuales condiciones se debe desarrollar para que sea exitoso.

INGENIERIA DE SOFTWARE 28

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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 INGENIERIA DE SOFTWARE 29

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

cuanto el sistema empieza a aportar beneficios. Cuanto menor sea el periodo de amortizació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. INGENIERIA DE SOFTWARE 30

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

PRODUCIR ESTIMACIONES DE COSTES-BENEFICIOS

Se realizará 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.

INGENIERIA DE SOFTWARE 31

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

 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. INGENIERIA DE SOFTWARE 32

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

2. DETERMINAR LA VIABILIDAD DEL PROYECTO

Se basará 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 qué 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

Cn

Bn

Bn – Cn

…

n

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.

INGENIERIA DE SOFTWARE 33

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

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 = añ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 determinará la viabilidad del proyecto consultando la siguiente tabla:

INGENIERIA DE SOFTWARE 34

INVESTIGACION UNIDAD I Instituto Tecnológico Superior de Alvarado

BIBLIOGRAFIA

1. https://manuel.cillero.es/doc/metrica-3/tecnicas/analisis-costebeneficio/ 2. https://es.calameo.com/read/0045049142e90c91fe944 3. file:///C:/Users/root/Downloads/docdownloader.com_especificacionde-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

INGENIERIA DE SOFTWARE 35