Portafolio de evidencia asd by Daniel Alejandro Coubillier Amado

La misi贸n de UNIDEP es formar profesionales de 茅xito que cuenten con las actitudes, habilidades y conocimientos que demanda el sector productivo de la regi贸n.

•

La Universidad del Desarrollo Profesional es una institución de educación superior de calidad, que ofrece programas presenciales y semipresenciales de bachillerato, profesional asociado, licenciatura, posgrado, diplomados y cursos en México y en el extranjero. Se distingue por facilitar a sus egresados la incorporación al mercado de trabajo, apoyada en una estrecha vinculación con el sector productivo y en planes de estudio pertinentes y dinámicos. Es reconocida por su modelo educativo profesionalizante, por la flexibilidad de su oferta académica impartida en ciclos continuos y por horarios y cuotas accesibles, acordes a la disponibilidad de tiempo y recursos económicos del alumno. Cuenta con profesores de amplia experiencia profesional y educativa. Sus instalaciones dentro de la ciudad permiten el fácil acceso. Cuenta con un modelo de administración sistematizado, participativo, operado por personal que es recompensado por su desempeño efectivo que le permite maximizar las aportaciones de sus socios y mantener finanzas sanas.

INDICE 1.- ARCHIVO EN WORD INTRODUCCIÓN A INGENIERIA DE SOFTWARE 2.- REPORTE DE LECTURA PREGUNTAS FRECUENTES DE INGENIERÍA DEL SOFTWARE 3.- PRESENTACIÓN DEL EQUIPO #1 PREGUNTAS FRECUENTES DE INGENIERIA DEL SOFTWARE 4.- REPORTE DE LECTURA EQUIPO # 2 INGENIERÍA DEL SOFTWARE ASISTIDA POR COMPUTADORA 5.- PRESENTACIÓN DEL EQUIPO #2 INGENIERÍA DEL SOFTWARE ASISTIDA POR COMPUTADORA 6.- INVESTIGACIÓN DE CLASE MODELO RUP 7.- INVESTIGACIÓN DE CLASE DE LAS 4 FASE DEL MODELO RUP 8.- INVESTIGACIÓN DE CLASE MÉTRICA-CALIDAD 9.- INVESTIGACIÓN DE CLASE FASE DE GESTIÓN DE PLANEACIÓN (PLANIFICACIÓN-CLAENDARIZACIÓN-GETIÓN DE RIESGOS) 10.- REPORTE DE LECTURA TEMA EQUIPO #3: DISEÑO DE INTERFASE DE USUARIOS 11.- REPORTE DE LECTURA TEMA EQUIPO #4: ATRIBUTOS DE LOS SISTEMAS Y APLICACIONES BASADAS EN WEB. 12.- INVESTIGACIONES ESPECIALES: – – – – –

FRAMEWORKS UML (MODELO DE LENGUAJE UNIFICADO) MICROSOFT PROJECT, INTELIGENCIA ARTIFICIAL, LENGUAJE COBOL SOFTWARE REQUISITE PRO SECOND LIFE

INGENIERÍA DE SOFTWARE Introducción Un sistema informático está compuesto por hardware y software. En cuanto al hardware, su producción se realiza sistemáticamente y la base de conocimiento para el desarrollo de dicha actividad está claramente definida. La fiabilidad del hardware es, en principio, equiparable a la de cualquier otra máquina construida por el hombre. Sin embargo, respecto del software, su construcción y resultados han sido históricamente cuestionados debido a los problemas asociados, entre ellos podemos destacar los siguientes [1]: •Los sistemas no responden a las expectativas de los usuarios. •Los programas “fallan” con cierta frecuencia. •Los costes del software son difíciles de prever y normalmente superan las estimaciones. •La modificación del software es una tarea difícil y costosa. •El software se suele presentar fuera del plazo establecido y con menos prestaciones de las consideradas inicialmente. •Normalmente, es difícil cambiar de entorno hardware usando el mismo software. •El aprovechamiento óptimo de los recursos (personas, tiempo, dinero, herramientas, etc.) no suele cumplirse. Según el Centro Experimental de Ingeniería de Software (CEIS)[1], el estudio de mercado The Chaos Report realizado por Standish Group Internactional[2] en 1996, concluyó que sólo un 16% de los proyectos de software son exitosos (terminan dentro de plazos y costos y cumplen los requerimientos acordados). Otro 53% sobrepasa costos y plazos y cumple parcialmente los requerimientos. El resto ni siquiera llega al término. Algunas deficiencias comunes en el desarrollo de software son: •Escasa o tardía validación con el cliente. •Inadecuada gestión de los requisitos. •No existe medición del proceso ni registro de datos históricos. •Estimaciones imprevistas de plazos y costos. •Excesiva e irracional presión en los plazos. •Escaso o deficiente control en el progreso del proceso de desarrollo. •No se hace gestión de riesgos formalmente. •No se realiza un proceso formal de pruebas. •No se realizan revisiones técnicas formales e inspecciones de código. El primer reconocimiento público de la existencia de problemas en la producción de software tuvo lugar en la conferencia organizada en 1968 por la Comisión de Ciencias de la OTAN en Garmisch (Alemania), dicha situación problemática se denominó crisis del software. En esta conferencia, así como en la siguiente realizada en Roma en 1969, se estipuló el interés hacia los aspectos técnicos y administrativos en el desarrollo y mantenimiento de productos software. Se pretendía acordar las bases para una ingeniería de construcción de software. Según Fritz Bauer [2] lo que se necesitaba era “establecer y usar principios de ingeniería orientados a obtener software de manera económica, que sea fiable y funcione eficientemente sobre máquinas reales”. Esta definición marcaba posibles cuestiones tales como: ¿Cuáles son los principios robustos de la ingeniería aplicables al desarrollo de software de computadora? ¿Cómo construimos el software económicamente para que sea fiable? ¿Qué se necesita para crear programas de computadora que funcionen eficientemente no en una máquina sino en diferentes máquinas reales?. Sin embargo, dicho planteamiento además debía incluir otros aspectos, tales como: mejora de la calidad del software, satisfacción del cliente, mediciones y métricas, etc. 5 [1] [2]

http://www.ceis.cl/Gestacion/Gestacion.htm (5.3.2003) http://standishgroup.com/ (5.3.2003)

El “IEEE Standard Glossary of Software Engineering Terminology” (Stad. 610.12-1990) ha desarrollado una definición más completa para ingeniería del software [1]: “(1) La aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento del software; es decir, la aplicación de ingeniería al software. (2) El estudio de enfoques en (1)”. Pressman [1] caracteriza la Ingeniería de Software como “una tecnología multicapa”, ilustrada en la Figura 1. No se puede mostrar la imagen en este momento.

Figura 1: Capas de la Ingeniería de Software. Dichas capas se describen a continuación: •Cualquier disciplina de ingeniería (incluida la ingeniería del software) debe descansar sobre un esfuerzo de organización de calidad. La gestión total de la calidad y las filosofías similares fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de enfoques cada vez más robustos para la ingeniería del software. •El fundamento de la ingeniería de software es la capa proceso. El proceso define un marco de trabajo para un conjunto de áreas clave, las cuales forman la base del control de gestión de proyectos de software y establecen el contexto en el cual: se aplican los métodos técnicos, se producen resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente. •Los métodos de la ingeniería de software indican cómo construir técnicamente el software. Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. Estos métodos dependen de un conjunto de principios básicos que gobiernan cada área de la tecnología e incluyen actividades de modelado y otras técnicas descriptivas. •Las herramientas de la ingeniería del software proporcionan un soporte automático o semi-automático para el proceso y los métodos, a estas herramientas se les llama herramientas CASE (Computer-Aided Software Engineering). Dado lo anterior, el objetivo de la ingeniería de software es lograr productos de software de calidad (tanto en su forma final como durante su elaboración), mediante un proceso apoyado por métodos y herramientas. A continuación nos enfocaremos en el proceso necesario para elaborar un producto de software. El proceso de desarrollo del software Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Dicho proceso, en términos globales se muestra en la Figura 2 [3]. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas [4]. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuación se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construcción. Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una inmensa combinación de factores que impiden una verificación exhaustiva de las todas posibles situaciones de ejecución que se puedan presentar (entradas, valores de variables, datos almacenados, software del sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.). Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares. Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, los cambios en los requisitos son inevitables, no sólo después de entregado en producto sino también durante el proceso de desarrollo.6 Además, de las dos anteriores, siempre puede señalarse la inmadurez de la ingeniería del software como

disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniería. Sin embargo, esto no es más que un inútil consuelo. Figura 2: proceso de desarrollo de software.

Requisitosnuevos omodificados

ProcesodeDesarrollo deSoftware

Sistemanuevo omodificado

El proceso de desarrollo de software no es único. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difícil automatizar todo un proceso de desarrollo de software. A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos [4]: •Especificación de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software. •Diseño e Implementación: Se diseña y construye el software de acuerdo a la especificación. •Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente. •Evolución: El software debe evolucionar, para adaptarse a las necesidades del cliente. Además de estas actividades fundamentales, Pressman [1] menciona un conjunto de “actividades protectoras”, que se aplican a lo largo de todo el proceso del software. Ellas se señalan a continuación: •Seguimiento y control de proyecto de software. •Revisiones técnicas formales. •Garantía de calidad del software. •Gestión de configuración del software. •Preparación y producción de documentos. •Gestión de reutilización. •Mediciones. •Gestión de riesgos. Pressman [1] caracteriza un proceso de desarrollo de software como se muestra en la Figura 3. Los elementos involucrados se describen a continuación: •Un marco común del proceso, definiendo un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamaño o complejidad. •Un conjunto de tareas, cada uno es una colección de tareas de ingeniería del software, hitos de proyectos, entregas y productos de trabajo del software, y puntos de garantía de calidad, que permiten que las actividades del marco de trabajo se adapten a las características del proyecto de software y los requisitos del equipo del proyecto. •Las actividades de protección, tales como garantía de calidad del software, gestión de configuración del software y medición, abarcan el modelo del proceso. Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso. 7

No se puede mostrar la imagen en este momento.

Figura 3: Elementos del proceso del software Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo de software es establecer las relaciones entre elementos que permitan responder Quién debe hacer Qué, Cuándo y Cómo debe hacerlo. No se puede mostrar la imagen en este momento.

Figura 4: Relación entre elementos del proceso del software En la Figura 4 se muestran los elementos de un proceso de desarrollo de software y sus relaciones. Así las interrogantes se responden de la siguiente forma: •Quién: Las Personas participantes en el proyecto de desarrollo desempeñando uno o más Roles específicos. •Qué: Un Artefacto es producido por un Rol en una de sus Actividades. Los Artefactos se especifican utilizando Notaciones específicas. Las Herramientas apoyan la elaboración de Artefactos soportando ciertas Notaciones. •Cómo y Cuándo: Las Actividades son una serie de pasos que lleva a cabo un Rol durante el proceso de desarrollo. El avance del proyecto está controlado mediante hitos que establecen un determinado estado de terminación de ciertos Artefactos. Un artefacto es una pieza de información que (1) es producida, modificada o usada por el proceso, (2) define un área de responsabilidad para un rol y (3) está sujeta a control de versiones. Un artefacto puede ser un modelo, un elemento de modelo o un documento. 8

La composición y sincronía de las actividades está basada en un conjunto de Principios y Prácticas. Las Prácticas y Principios enfatizan ciertas actividades y/o la forma como deben realizarse, por ejemplo: desarrollar iterativamente, gestionar requisitos, desarrollo basado en componentes, modelar visualmente, verificar continuamente la calidad, gestionar los cambios, etc. Modelos de proceso software Sommerville [4] define modelo de proceso de software como “Una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real.” Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software. Modelos que se van a discutir a continuación: •Codificar y corregir •Modelo en cascada •Desarrollo evolutivo •Desarrollo formal de sistemas •Desarrollo basado en reutilización •Desarrollo incremental •Desarrollo en espiral Codificar y corregir (Code-and-Fix) Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos: •Escribir código. •Corregir problemas en el código. Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño, validación, y mantenimiento. Este modelo tiene tres problemas principales [7]: •Después de un número de correcciones, el código puede tener una muy mala estructura, hace que los arreglos sean muy costosos. •Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara. •El código es difícil de reparar por su pobre preparación para probar y modificar. Modelo en cascada El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de ingeniería [8]. Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso. El modelo en cascada consta de las siguientes fases: •Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definición en detalle. •Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema. •Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad. •Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente. 9

•Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos. La interacción entre fases puede observarse en la Figura 5. Cada fase tiene como resultado documentos que deben ser aprobados por el usuario. Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la corrección de los problemas encontrados en fases previas.

No se puede mostrar la imagen en este momento.

Figura 5: Modelo de desarrollo en cascada. En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción entre las distintas fases de desarrollo. Algunos problemas que se observan en el modelo de cascada son: •Las iteraciones son costosas e implican rehacer trabajo debido a la producción y aprobación de documentos. •Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases. •Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean ignorados o corregidos de una forma poco elegante. •Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto. •Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder a cambios en los requisitos. Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como parte de proyectos grandes. Desarrollo evolutivo La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. En la Figura 6 se observa cómo las actividades concurrentes: especificación, desarrollo y validación, se realizan durante el desarrollo de las versiones hasta llegar al producto final. Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración. 10

No se puede mostrar la imagen en este momento.

Figura 6: Modelo de desarrollo evolutivo. Existen dos tipos de desarrollo evolutivo: •Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario. •Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos. Entre los puntos favorables de este modelo están: •La especificación puede desarrollarse de forma creciente. •Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software. •Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente. Desde una perspectiva de ingeniería y administración se identifican los siguientes problemas: •Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema. •Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento. •Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar. Este modelo es efectivo en proyectos pequeños (menos de 100.000 líneas de código) o medianos (hasta 500.000 líneas de código) con poco tiempo para su desarrollo y sin generar documentación para cada versión. Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede hacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento más estructurado. Los subsistemas con requisitos bien definidos y estables se pueden programar utilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio.

Desarrollo formal de sistemas Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable. Desarrollo Desiciones

Formal

Especificación Informal Especificación Especificación de alto nivel (prototipo)

Tranformación Interactiva

Especificación de bajo nivel

Transformación Automática

Código Fuente

Optimización Validación de Especificación

Mantenimiento

Figura 7: Paradigma de programación automática. La Figura 7 (obtenida desde [20]) ilustra un paradigma ideal de programación automática. Se distinguen dos fases globales: especificación (incluyendo validación) y transformación. Las características principales de este paradigma son: la especificación es formal y ejecutable constituye el primer prototipo del sistema), la especificación es validada mediante prototipación. Posteriormente, a través de transformaciones formales la especificación se convierte en la implementación del sistema, en el último paso de transformación se obtiene una implementación en un lenguaje de programación determinado. , el mantenimiento se realiza sobre la especificación (no sobre el código fuente), la documentación es generada automáticamente y el mantenimiento es realizado por repetición del proceso (no mediante parches sobre la implementación). Observaciones sobre el desarrollo formal de sistemas: •Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las pruebas que verifican la correspondencia con la especificación no son necesarias. •Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes. •Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo. Desarrollo basado en reutilización Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización. Este modelo consta de 4 fases ilustradas en la Figura 9. A continuación se describe cada fase: •Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos. •Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes más adecuados (fase 1). •Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco. •Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad 12 separada.

Las ventajas de este modelo son: •Disminuye el costo y esfuerzo de desarrollo. •Reduce el tiempo de entrega. •Disminuye los riesgos durante el desarrollo.

Figura 9: Modelo de desarrollo iterativo incremental. No se puede mostrar la imagen en este momento.

Figura 8: Desarrollo basado en reutilización de componentes Desventajas de este modelo: •Los “compromisos” en los requisitos son inevitables, por lo cual puede que el software no cumpla las expectativas del cliente. •Las actualizaciones de los componentes adquiridos no están en manos de los desarrolladores del sistema. Procesos iterativos A continuación se expondrán dos enfoques híbridos, especialmente diseñados para el soporte de las iteraciones: •Desarrollo Incremental. •Desarrollo en Espiral. Desarrollo incremental Mills [9] sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema (ver Figura 10). Es una combinación del Modelo de Cascada y Modelo Evolutivo. Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema. Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo. 13

Entre las ventajas del modelo incremental se encuentran: •Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento. •Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema. •Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento. •Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos módulos y se disminuye el riesgo de fallos. Algunas de las desventajas identificadas para este modelo son: •Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas). •Cada incremento debe aumentar la funcionalidad. •Es difícil establecer las correspondencias de los requisitos contra los incrementos. •Es difícil detectar las unidades o servicios genéricos para todo el sistema. •Desarrollo en espiral El modelo de desarrollo en espiral (ver Figura 11) es actualmente uno de los más conocidos y fue propuesto por Boehm [7]. El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra. Cada ciclo de desarrollo se divide en cuatro fases: •Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos. •Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos. •Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase. •Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto. Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta es una actividad importante en la administración del proyecto. El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalúan los riesgos con actividades como análisis detallado, simulación, prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase. 14

Figura 10: Modelo de desarrollo en Espiral ¿Cuál es el modelo de proceso más adecuado? Cada proyecto de software requiere de una forma de particular de abordar el problema. Las propuestas comerciales y académicas actuales promueven procesos iterativos, donde en cada iteración puede utilizarse uno u otro modelo de proceso, considerando un conjunto de criterios (Por ejemplo: grado de definición de requisitos, tamaño del proyecto, riesgos identificados, entre otros). En la Tabla 1 se expone un cuadro comparativo de acuerdo con algunos criterios básicos para la selección de un modelo de proceso [10], la medida utilizada indica el nivel de efectividad del modelo de proceso de acuerdo al criterio (Por ejemplo: El modelo Cascada responde con un nivel de efectividad Bajo cuando los Requisitos y arquitectura no están predefinidos ):

Modelo de proceso

Funciona con requisitos y arquitectura no predefinidos

Produce software altamente fiable

Gesti贸n de riesgos

Permite correcciones sobre la marcha

Bajo

Alto

Medio

Bajo

Alto

Bajo

Medio o Alto

Medio

Medio o Alto

Alto

Medio

Alto

Bajo

Alto

Bajo a Medio

Bajo

Medio

Bajo a Alto

Bajo a Medio

Alto

Bajo

Alto

Medio

Bajo

Alto

Medio

Visi贸n del progreso por el Cliente y el Jefe del proyecto

Codificar y corregir

Cascada

Evolutivo exploratorio

Evolutivo prototipado

Desarrollo formal de sistemas

Desarrollo orientado a reutilizaci贸n

Incremental

Espiral

Metodologías para desarrollo de software Un proceso de software detallado y completo suele denominarse “Metodología”. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, etc.). Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño. La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, información disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de análisis y diseño, podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales (o peyorativamente denominada Metodologías Pesadas, o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso. A continuación se revisan brevemente cada una de estas categorías de metodologías. Metodologías estructuradas Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para el Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente apropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4ta generación. Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE [1] (Francia), MÉTRICA[2] (España), SSADM[3] (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito académico: Gane & Sarson[4], Ward & Mellor[5], Yourdon & DeMarco[6] e Information Engineering[7]. Metodologías orientadas a objetos Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java[8] o C# de Microsoft. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto. En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a un objetivo más modesto, para [1]

http://perso.club-internet.fr/brouardf/SGBDRmerise.htm (7.5.2002) http://www.map.es/csi/metrica3/ (7.5.2003) [3] http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html (7.5.2003) [4] http://portal.newman.wa.edu.au/technology/12infsys/html/dfdnotes.doc (29.8.2003) [5] http://www.yourdon.com/books/coolbooks/notes/wardmellor.html (29.8.2003) [6] http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Yourdon%2FDemarco (29.8.2003) [7] http://gantthead.com/Gantthead/process/processMain/1,1289,2-12009-2,00.html (29.8.2003) [8] http://java.sun.com/ (7.5.2003) [2]

dar lugar al Unified Modeling Language (UML), la notación OO más popular en la actualidad. Algunos métodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh). Algunas metodologías orientadas a objetos que utilizan la notación UML son: Rational Unified Process (RUP), OPEN, MÉTRICA (que también soporta la notación estructurada). Metodologías tradicionales (no ágiles) Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o clásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construcción del sistema. Todas las propuestas metodológicas antes indicadas pueden considerarse como metodologías tradicionales. Aunque en el caso particular de RUP, por el especial énfasis que presenta en cuanto a su adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse), realizando una configuración adecuada, podría considerarse Ágil. Metodologías ágiles Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último momento) [11]. Entre las metodologías ágiles identificadas en [11]: Extreme Programming [6]. Scrum ([12], [13]). Familia de Metodologías Crystal [14]. Feature Driven Development [15]. Proceso Unificado Rational, una configuración ágil ([16]). Dynamic Systems Development Method [17]. Adaptive Software Development [18]. Open Source Software Development [19].

http://www.uml.org/ (7.5.2003) http://www.rational.com/products/rup/index.jsp (7.5.2003) http://www.open.org.au/ (17.9.2003) 18

Referencias

[1] Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill 1997. [2] Naur P., Randell B., Software Engineering: A Report on a Conference Sponsored by the NATO Scienc, 1969. [3] Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software, Addison Wesley 2000. [4] Sommerville, I., Ingeniería de Software, Pearson Educación, 2002. [5] Letelier, P., Proyecto Docente e Investigador, DSIC, 2003. [6] Beck, K., Una explicación de la Programación Extrema. Aceptar el cambio, Pearson Educación, 2000. [7] Boehm, B. W., A Spiral Model of Software Develpment and Enhancement, IEEE Computer ,1988. [8] Royce, W., Managing the developmento of large software systems: concepts and technique, IEEE Westcon, 1970. [9] Mills, H., O´Neill, D., The Management of Software Engineering, IBM Systems, 1980. [10] Laboratorio Ing. Soft., Ingeniería de software 2, Departamento de Informática, 2002. [11] Abrahamsson, P., Salo, O., Ronkainen, J., Agile Software Development Methods. Review and Analysis, VTT, 2002. [12] Schwaber, K., Scrum Development Process. Workshop on Business Object Design and Implementation, OOPSLA´95, 1995. [13] Schwaber, K., Beedle, M., Agile Software Development With Scrum, Prentice Hall, 2002. [14] Cockburn, A., Agile Software Development, Addison Wesley, 2002. [15] Palmer, S. R., Felsing, J. M., A Practical Guide to Feature Driven Development, Prentice Hall, 2002. [16] Kruchten, P., A Rational Development Process, Crosstalk, 1996. [17] Stapleton, J., Dynamic Systems Development Method - The Method in Practice, Addison Wesley, 1997. [18] Highsmith, J., Adaptive Software Development: A Collaborative Approach, Dorset House, 2000. [19] O´Reilly, T., Lessons from Open Source Software Development, ACM, 1999.

REPORTE DE LECTURA PREGUNTAS FRECUENTES DE INGENIERÍA DEL SOFTWARE El software no son sólo programas, sino todos los documentos asociados y la configuración de datos que se necesitan para hacer que estos programas operen de manera correcta. Existen dos tipos de productos que son productos genéricos y productos personalizados, los productos genéricos Son sistemas aislados producidos por una organización de desarrollo y que se venden al mercado abierto a cualquier cliente que le sea posible comprarlos. Y los productos personalizados son sistemas requeridos por un cliente en particular, un contratista de software desarrolla el software especialmente para ese cliente. La ingeniería de software es una disciplina de la ingeniería que comprende todos los aspectos de la producción de software desde las etapas iníciales de la especificación del sistema, hasta el mantenimiento de éste después de que se utiliza. Los ingenieros hacen que las cosas funcionen. Aplican teorías. Métodos y herramientas donde sean convenientes, pero las utilizan de Forma selectiva y siempre tratando de descubrir soluciones a los problemas. La ingeniería del software no sólo comprende los procesos técnicos del desarrollo de software sino también con actividades tales como la gestión de proyectos de software y el desarrollo de herramientas, métodos y teorías de apoyo a la producción de software. Esencialmente, la ciencia de la computación se refiere a las teorías y métodos subyacentes a las computadoras y los sistemas de software. La ingeniería de sistemas se refiere a todos los aspectos del desarrollo y de la evolución de sistemas complejos donde el software desempeña un papel principal. Los ingenieros de sistemas están involucrados en la especificación del sistema, en la definición de su arquitectura y en la integración de las diferentes partes para crear el sistema final. Un proceso del software es un conjunto de actividades y resultados asociados que producen un producto de software, existen cuatro 20 actividades fundamentales de procesos:

1. Especificación del software donde los clientes e ingenieros definen el software a producir y las restricciones sobre su operación. 2. Desarrollo del software donde el software se diseña y programa. 3. Validación del software donde el software se válida para asegurar que es lo que el cliente requiere. 4. Evolución del software donde el software se modifica para adaptarlo a los cambios requeridos por el cliente y el mercado. Un modelo de procesos del software es una descripción simplificada ya que estos modelos pueden incluir actividades que son parte de los procesos y productos de software y el papel de las personas involucra das en la ingeniería del software. Un método de ingeniería del software es un enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la producción de software de alta calidad de una forma costeable. CASE (Ingeniería del Software Asistida por Computadora) comprende un amplio abanico de diferentes tipos de programas que se utilizan para ayudar a las actividades del proceso del software, como el análisis de requerimientos. El modelado de sistemas, la depuración y las pruebas. En el siglo XXI, la ingeniería del software afronta tres retos fundamentales: 1.- El reto de la hetero8eneidad. Cada vez más. se requiere que los sistemas operen como sistemas distribuidos en redes que incluyen diferentes tipos de computadoras y con diferentes clases de sistemas de soporte. 2.- El reto de la entre8a. Muchas técnicas tradicionales de ingeniería del software consumen tiempo. El tiempo que éstas consumen es para producir un software de calidad. 3.- El reto de la confianza. Puesto que el software tiene relación con todos los aspectos de nuestra vida. Es esencial que podamos confiar en él. Esto es especialmente importante en sistemas remotos de software a los que se accede a tal ves de páginas web o de interfaces de servicios web.

PREGUNTAS MAS FRECUENTES DE INGENIERIA DEL SOFTWARE.

EQUIPO 1. JESUS ISIDRO GONZALEZ E. VICTOR HUGO IBARRA ORTIZ. CD. OBREGON, SON. A 16 DE MAYO DE 2013. 22

¿Qué es un Software? El software no son sólo programas, sino todos los documentos asociados y la configuración de datos que se necesitan para hacer que estos programas operen de manera correcta. Por lo general, un sistema de software consiste en diversos programas independientes, archivos de configuración que se utilizan para ejecutar estos programas, un sistema de documentación que describe la estructura del sistema, la documentación para el usuario que explica cómo utilizar el sistema y sitios web que permitan a los usuarios descargar la información de productos recientes. 23

Tipos de productos de software. Existen dos productos: 1. Productos genéricos. Son sistemas aislados producidos por una organización de desarrollo y que se venden al mercado abierto a cualquier cliente que le sea posible comprarlos. Ejemplos de este tipo de producto son el software para Pc´s tales como bases de datos, procesadores de texto, paquetes de dibujo y herramientas de gestión de proyectos. 2. Productos personalizados (o hechos a medida). Son sistemas requeridos por un cliente en particular. Un contratista de software desarrolla el software especialmente para ese cliente. Ejemplos de este tipo de software son los sistemas de control para instrumentos electrónicos, sistemas desarrollados para llevar a cabo procesos de negocios específicos y sistemas de control del tráfico aéreo. 24

¿Qué es la ingeniería del software? Es una disciplina de la ingeniería que comprende todos los aspectos de la producción de software desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste después de que se utiliza.

Disciplina de la ingeniería Los ingenieros hacen que las cosas funcionen. Aplican teorías. Métodos y herramientas donde sean convenientes, pero las utilizan de Forma selectiva y siempre tratando de descubrir soluciones a los problemas, aun cuando no existan teorías y métodos aplicables para resolverlos. Los ingenieros también saben que deben trabajar con restricciones financieras y organizacionales. por lo que buscan soluciones tomando en cuenta estas restricciones. 26

Todos los aspectos de producción de software

La ingeniería del software no sólo comprende los procesos técnicos del desarrollo de software sino también con actividades tales como la gestión de proyectos de software y el desarrollo de herramientas, métodos y teorías de apoyo a la producción de software. 27

¿Cuál es la diferencia entre ingeniería del software y ciencia de la computación?

Esencialmente, la ciencia de la computación se refiere a las teorías y métodos subyacentes alas computadoras y los sistemas de software, mientras que la ingeniería del software se refiere a los problemas prácticos de producir software. Los ingenieros de software requieren ciertos conocimientos de ciencia de la computación, de la misma forma que los ingenieros eléctricos requieren conocimientos de física.

¿Cuál es la diferencia entre ingeniería del software e ingeniería de sistemas? La ingeniería de sistemas se refiere a todos los aspectos del desarrollo y de la evolución de sistemas complejos donde el software desempeña un papel principal. Por lo tanto, la ingeniería de sistemas comprende el desarrollo de hardware, políticas y procesos de diseño y distribución de sistemas, así como la ingeniería del software. Los ingenieros de sistemas están involucrados en la especificación del sistema, en la definición de su arquitectura y en la integración de las diferentes partes para crear el sistema final. Están menos relacionados con la ingeniería de los componentes del sistema (hardware, software, etc.). 29

ÂżQuĂŠ es un proceso del software? Un proceso del software es un conjunto de actividades y resultados asociados que producen un producto de software. Estas actividades son llevadas a cabo por los ingenieros de software. Existen cuatro actividades fundamentales de procesos (incluidas mĂĄs adelante en este libro) que son comunes para todos los procesos del software.

Actividades 1. Especificación del software donde los clientes e ingenieros definen el software a producir y las restricciones sobre su operación. 2. Desarrollo del software donde el software se diseña y programa. 3. Validación del software donde el software se valida para asegurar que es lo que el cliente requiere. 4. Evolución del software donde el software se modifica para adaptarlo a los cambios requeridos por el cliente y el mercado.

¿Qué es un modelo de procesos del software? Un modelo de procesos del software es una descripción simplificada de un proceso del software que presenta una visión de ese proceso. Estos modelos pueden incluir actividades que son parte de los procesos y productos de software y el papel de las personas involucra das en la ingeniería del software.

¿Cuáles son los costos de la ingeniería del software? No existe una respuesta sencilla a esta pregunta ya que la distribución de costos a través de las diferentes actividades en el proceso del software depende del proceso utilizado y del tipo de software que se vaya a desarrollar. Por ejemplo, el software de tiempo real normalmente requiere una validación y pruebas más extensas que los sistemas basados en web. Sin embargo, cada uno de los diferentes enfoques genéricos al desarrollo del software tiene un perfil de distribución de costos diferente a través de las actividades del proceso del software. Si se considera que el costo total del desarrollo de un sistema de software complejo es de 100 unidades de costo, la Figura 1.2 muestra cómo se gastan éstas en las diferentes actividades del proceso. 33

¿Qué son los métodos de la ingeniería del software? Un método de ingeniería del software es un enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la producción de software de alta calidad de una forma costeable. Métodos como Análisis Estructurado (DeMarco, 1978) y JSD (Jackson, 1983) fueron los primeros desarrollados en los años 70. Estos métodos intentaron identificar los componentes funcionales básicos de un sistema, de tal forma que los métodos orientados a funciones aún se utilizan ampliamente. En los años 80 y 90. estos métodos orienta dos a funciones fueron complementados por métodos orientados a objetos. como los propuestos por Booch (1994) y Rumbaugh (Rumbaugh el al., 1991). Estos diferentes enfoques se han integrado en un solo enfoque unificado basado en el Lenguaje de Modelado Unificado (UML) (Booch el al., 1999; Rumbaugh el al., I999a; Rumbaugh el al., 1999b).

¿Qué es CASE? CASE (Ingeniería del Software Asistida por Computadora) comprende un amplio abanico de diferentes tipos de programas que se utilizan para ayudar a las actividades del proceso del software, como el análisis de requerimientos. el modelado de sistemas, la depuración y las pruebas. En la actualidad, todos los métodos vienen con tecnología CASE asociada, como los editores para las notaciones utilizadas en el método, módulos de análisis que verifican el modelo del sistema según las reglas del método y generadores de informes que ayudan a crear la documentación del sistema. Las herramientas CASE también incluyen un generador de código que automáticamente genera código fuente a partir del modelo del sistema y de algunas guías de procesos para los ingenieros de software.

¿Cuáles son los atributos de un buen software? Así como los servicios que proveen, los productos de software tienen un cierto número de atributos asociados que reflejan la calidad de ese software. Estos atribulas no están directamente asociados con lo que el software hace. Más bien, reflejan su comportamiento durante su ejecución y en la estructura y organización del programa fuente y en la documentación asociada. Ejemplos de estos atribulas (algunas veces llamados atribulas no funcionales) son el tiempo de respuesta del software a una pregunta del usuario y la comprensión del programa fuente. 37

Esto se generaliza en el conjunto de atributos que se muestra en la Figura 1.5, el cual tiene las caracterĂsticas esenciales de un sistema de software bien diseĂąado.

¿Cuáles son los retos fundamentales que afronta la ingeniería del software?

En el siglo XXI, la ingeniería del software afronta tres retos fundamentales: 1. El reto de la hetero8eneidad. Cada vez más. se requiere que los sistemas operen como sistemas distribuidos en redes que incluyen diferentes tipos de computadoras y con diferentes clases de sistemas de soporte. A menudo es necesario integrar software nuevo con sistemas heredados más viejos escritos en diferentes lenguajes de programación. El reto de la heterogeneidad es desarrollar técnicas para construir software confiable que sea lo suficientemente flexible para adecuarse a esta heterogeneidad. 39

2. El reto de la entre8a. Muchas técnicas tradicionales de ingeniería del software consumen tiempo. El tiempo que éstas consumen es para producir un software de calidad. Sin embargo. los negocios de hoy en día deben tener una gran capacidad de respuesta y cambiar con mucha rapidez. Su software de soporte también debe cambiar con la misma rapidez. El reto de la entrega es reducir los tiempos de entrega para sistemas grandes y complejos sin comprometer la calidad del sistema. 40

3. El reto de la confianza. Puesto que el software tiene relación con todos los aspectos de nuestra vida. es esencial que podamos confiar en él. Esto es especialmente importante en sistemas remotos de software a los que se accede a talvés de páginas web o de interfaces de servicios web. El reto de la confianza es desarrollar técnicas que de muestren que los usuarios pueden confiar en el software. 41

REPORTE DE LECTURA EQUIPO # 2 INGENIERÍA DEL SOFTWARE ASISTIDA POR COMPUTADORA

Ingeniería del Software Asistida por Computadora (CASE) es el nombre que se le da al software que se utiliza para ayudar a las actividades del proceso del software como la ingeniería de requerimientos, el diseño, el desarrollo de programas y las pruebas. Proporciona ayuda al proceso del software automatizando algunas de sus actividades. Así como proporcionando información acerca del software en desarrollo. Algunos ejemplos de las actividades de CASE son: El desarrollo modelo de gráficos de sistemas, comprensión del diseño, generación de interface de usuarios, la depuración de programas por medio de la provisión de la información proporcionada, la conversión automática de programas de una versión anterior de un lenguaje de programación. La tecnología CASE está disponible para la mayoría de las actividades rutinarias en el proceso del software. Esto permite algunas mejoras en la calidad y productividad del software, las mejoras por la utilización de CASE están limitadas por dos factores: 1.- Esencialmente la ingeniería del software es una actividad de diseño que se basa en la creatividad. Los sistemas CASE automatizan las actividades rutinarias 2.- En la mayoría de las organizaciones la ingeniería del software es una actividad de equipo y los ingenieros invierten mucho tiempo interactuando con los otros miembros del equipo. Actualmente, la tecnología CASE está madura y hay herramientas disponibles y bancos de trabajo de un amplio rango de proveedores. Sin embargo, más que centrarse en alguna herramienta específica. Los procesos del software son las actividades relacionadas con la producción de un sistema software. Todos los procesos del software incluyen la especificación el diseño, la implementación, la validación y la evolución del software. Los modelos genéricos del proceso describen la organización de los procesos del software, los modelos de Iteración de procesos presentan el proceso del software como un ciclo de actividades, la ingeniería de requerimientos es el proceso de desarrollar una especificación del software, los procesos de diseño e Implementación comprenden la transformación de la especificación de los requerimientos en un sistema software ejecutable. El Proceso Unificado de Racional es un modelo del proceso moderno y genérico que se organiza en fases (Inicio, elaboración, construcción y transición), pero que separa las actividades (requerimientos, análisis y diseño, etc.) de estas fases. La tecnología CASE proporciona ayuda automatizada a los procesos del software, las herramientas CASE ayudan a las actividades Individuales del proceso; los bancos de trabajo ayudan a un conjunto de actividades relacionadas; los entornos ayudan a todas o a la mayoría de las actividades del proceso del software, la validación del software es el proceso de verificar que el sistema se ajusta a su especificación y que satisface las necesidades reales de los usuarios del sistema, la evolución del software se interesa en modificar los sistemas software existentes para cumplir los nuevos requerimientos. 42

Ingeniería de software asistida por computadora

Edgar Javier Urquijo Rascón Oscar Fermín Vega Cota

ÍNDICE PRIMERA PARTE (EDGAR) SEGUNDA PARTE (OSCAR) TERCERA PARTE (EDGAR)

Concepto Ingeniería del Software Asistida por Computadora (CASE) es el nombre que se le da al software que se utiliza para ayudar a las actividades del proceso del software como la ingeniería de requerimientos, el diseño. el desarrollo de programas y las pruebas. Por lo tanto, las herramientas CASE incluyen editores de diseño. diccionarios de datos, compiladores, depuradores, herramientas de construcción de sistemas. etcétera.

La tecnología CASE proporciona ayuda al proceso del software automatizando algunas de sus actividades. así como proporcionando información acerca del software en desarrollo. Algunos ejemplos de las actividades que se pueden automatizar utilizando CASE son: l. El desarrollo de modelos gráficos del sistema como parte de la especificación de requerimientos o del diseño de software. 2. La comprensión del diseño utilizando un diccionario de datos que tiene información sobre las entidades y relaciones del diseño. 3. La generación de interfaces de usuario a partir de la descripción gráfica de la interfaz que es elaborada de forma interactiva por el usuario. 4. La depuración de programas por medio de la provisión de la información proporcionada por los programas en ejecución. 5. La conversión automática de programas de una versión anterior de una lenguaje de programación. como COBOL. a una versión más reciente.

La tecnología CASE está disponible para ía mayoría de las actividades rutinarias en el proceso del software. Esto permite algunas mejoras en la calidad y productividad del software, aunque éstas sean menores que lali predichas por los primeros partidarios de CASE. Éstos sugirieron que se tendría una mejora mayor si se utilizamn entornos CASE integrados. En realidad. Las mejoras reales son del 40% (Huff, 1992). Aunque esto es significante. las predicciones que se hicieron cuando se introdujeron las herramientas CASE en los años 80 y 90 fueron que el uso de la tecnología CASE generaría entonces ahorros en los costos del proceso del software.

Las mejoras por la utilización de CASE están limitadas por dos factores: 1. Esencialmente. la ingeniería del software es una actividad de diseño que se basa en la creatividad. Los sistemas CASE automatizan las actividades rutinarias. pero los intentos de utilizar la inteligencia artificial para proporcionar ayuda al diseño no han tenido éxito. 2. En la mayoría de las organizaciones. la ingeniería del software es una actividad de equipo. y los ingenieros invierten mucho tiempo interactuando con los otros miembros del equipo. La tecnología CASE no proporciona mucha ayuda para esto. 48

Actualmente, la tecnología CASE está madura y hay herramientas disponibles y bancos de trabajo de un amplio rango de proveedores. Sin embargo, más que centrarse en alguna herramienta específica. aquí se presenta una visión general, con algunos comentarios de apoyo específico en otros capítulos. En la página web se incluyen enlaces a otro material de CASE y a proveedores de herramientas CASE.

Puntos clave  Los procesos del software son las actividades relacionadas con la producción de un sistema software. Los modelos del proceso del software son representantes abstractas de estos procesos  Todos los procesos del software incluyen la especificación. el diseño, la implementación. la validación y la evolución del software.  Los modelos genéricos del proceso describen la organización de los procesos del software. Ejemplos de estos modelos son el modelo en cascada, el desarrollo evolutivo y la ingeniería del software basada en componentes.  Los modelos de Iteración de procesos presentan el proceso del software como un ciclo de actividades. La ventaja de este enfoque es que evita compromisos prematuros con una especificación o diseño. Ejemplos de este tipo de modelos son el desarrollo Incremental y el modelo en espiral.  La ingeniería de requerimientos es el proceso de desarrollar una especificación del software. Las especificaciones pretenden comunicar las necesidades del sistema del cliente a los desarrolladores del sistema.  Los procesos de diseño e Implementación comprenden la transformación de la especificación de los requerimientos en un sistema software ejecutable. Los métodos sistemáticos de diseño se pueden utilizar como parte de esta transformación.

 la validación del software es el proceso de verificar que el sistema se ajusta a su especificación y que satisface las necesidades reales de los usuarios del sistema.  la evolución del software se interesa en modificar los sistemas software existentes para cumplir los nuevos requerimientos. Esto se está convirtiendo en el enfoque normal para el desarrollo de sistemas de pequeño y mediano tamaño.  • El Proceso Unificado de Racional es un modelo del proceso moderno y genérico que se organiza en fases (Inicio, elaboración, construcción y transición), pero que separa las actividades (requerimientos, análisis y diseño, etc.) de estas fases.  • La tecnología CASE proporciona ayuda automatizada a los procesos del software. las herramientas CASE ayudan a las actividades Individuales del proceso; los bancos de trabajo ayudan a un conjunto de actividades relacionadas; los entornos ayudan a todas o a la mayoría de las actividades del proceso del software.

•INVESTIGACIÓN DE CLASE MODELO RUP ¿Qué es RUP? Es un proceso de ingeniería de software, que hace una propuesta orientada por disciplinas para lograr las tareas y responsabilidades de una organización que desarrolla software. Su meta principal es asegurar la producción de software de alta calidad que cumpla con las necesidades de los usuarios, con una planeación y presupuesto predecible. ¿Para quién es RUP? Diseñado para: –Profesionales en el desarrollo de software. –Interesados en productos de software. –Profesionales en la ingeniería y administración de procesos de software. ¿Por qué usar RUP? –Provee un entorno de proceso de desarrollo configurable, basado en estándares. –Permite tener claro y accesible el proceso de desarrollo que se sigue. –Permite ser configurado a las necesidades de la organización y del proyecto. –Provee a cada participante con la parte del proceso que le compete directamente, filtrando el resto. Características •Dirigido por Casos de Uso: –Los casos de uso son los artefactos primarios para establecer el comportamiento deseado del sistema •Centrado en la Arquitectura: –La arquitectura es utilizada para conceptualizar, construir, administrar y evolucionar el sistema en desarrollo •Iterativo e Incremental: –Maneja una serie de entregas ejecutables –Integra continuamente la arquitectura para producir nuevas versiones mejoradas •Conceptualmente amplio y diverso •Enfoque orientado a objetos •En evolución continua •Adaptable •Repetible •Permite mediciones: –Estimación de costos y tiempo, nivel de avance, etc. 53

INVESTIGACIÓN DE CLASE DE LAS 4 FASE DEL MODELO RUP 4 FASES SECUENCIALES •INICIO Se logra un acuerdo todos los interesados teniendo en cuenta el ciclo de vida para el proyecto generando el cuerpo del proyecto: Caso de negocios, Síntesis de arquitectura posible, Define el alcance del proyecto. •ELABORACION Establecimiento de la estructura base para la arquitectura del sistema, proporciona el diseño del mismo y el desarrollo de la siguiente fase Plan del proyecto, Especificación de características, Arquitectura base. •CONSTRUCCION Construir el producto, completa el desarrollo del sistema basado en la estructura base de la arquitectura. •TRANSICION Transición del producto a la comunidad del usuario, en si garantiza que el software esté listo para entregar al usuario. .

•INVESTIGACIÓN DE CLASE MÉTRICA-CALIDAD Son las que están relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia. Métricas de Calidad. Son todas las métricas de software que definen de una u otra forma la calidad del software como: Exactitud, Estructuración o modularidad, Pruebas, Mantenimiento, Reusabilidad, Cohesión del módulo, Acoplamiento del módulo, etc. Estas son los puntos críticos en el diseño, codificación, pruebas y mantenimiento. Proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. Se puede medir la calidad a lo largo del proceso de ingeniería del software y una vez que el software se ha distribuido al cliente y a los usuarios. Corrección: Es el grado con que el software realiza la función requerida. Facilidad de mantenimiento: Es la facilidad con que se puede corregir un programa si se encuentra un error o de realizar algún cambio. Tiempo medio entre cambios: Tiempo que lleva analizar el cambio requerido. Integridad: Mide la habilidad de un sistema para resistir ataques, en programas de datos y en documentos. Amenaza: Es la probabilidad de que un ataque de un tipo determinado ocurra en un tiempo determinado. Seguridad: Es la probabilidad de que se pueda repeler el ataque de un determinado tipo. Facilidad de uso: Cuanto es amigable con el usuario. 55

FASE DE GESTION DE PLANEACION *PLANIFICACION El propósito principal de la planificación es establecer un conjunto detallado de directrices que permite al equipo de trabajo saber exactamente que tiene que hacer cuando tiene que hacerse y que recursos tienen que estar disponibles *CALENDARIZACION DE PROYECTOS Es una actividad que distribuye estimaciones de esfuerzo a través de la duración planificada del proyecto para asignar el esfuerzo a tareas específicas Ing. De software *GESTION DE RIESGO Es una serie de pasos que ayudan a comprender y manejar la incertidumbre que implica el desarrollo de todo proyecto.

FRAMEWORK (Marco de trabajo) define, en términos generales, un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar. En el desarrollo de software, un framework o infraestructura digital, es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos de software concretos, que puede servir de base para la organización y desarrollo de software. Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto. Representa una arquitectura de software que modela las relaciones generales de las entidades del dominio, y provee una estructura y una especial metodología de trabajo, la cual extiende o utiliza las aplicaciones del dominio. Son diseñados con la intención de facilitar el desarrollo de software, permitiendo a los diseñadores y programadores pasar más tiempo identificando requerimientos de software que tratando con los tediosos detalles de bajo nivel de proveer un sistema funcional. Por ejemplo, un equipo que usa Apache Struts para desarrollar un sitio web de un banco, puede enfocarse en cómo los retiros de ahorros van a funcionar en lugar de preocuparse de cómo se controla la navegación entre las páginas en una forma libre de errores. Sin embargo, hay quejas comunes acerca de que el uso de frameworks añade código innecesario y que la preponderancia de frameworks competitivos y complementarios significa que el tiempo que se pasaba programando y diseñando ahora se gasta en aprender a usar los frameworks. Fuera de las aplicaciones en la informática, puede ser considerado como el conjunto de procesos y tecnologías usados para resolver un problema complejo. Es el esqueleto sobre el cual varios objetos 57 son integrados para facilitar una solución dada.

UML- LENGUAJE UNIFICADO DE MODELADO es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados. Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar. UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas. 58

MICROSOFT PROJECT, INTELIGENCIA ARTIFICIAL, LENGUAJE COBOL Microsoft Project Es un software de administración de proyectos diseñado, desarrollado y comercializado por Microsoft para asistir a administradores de proyectos en el desarrollo de planes, asignación de recursos a tareas, dar seguimiento al progreso, administrar presupuesto y analizar cargas de trabajo. El software Microsoft Office Project en todas sus versiones (la versión 2013 es la más reciente a febrero de 2013) es útil para la gestión de proyectos, aplicando procedimientos descritos en el PMBoK (Project Management Body of Knowledge) del Project Management Institute. La aplicación crea calendarización de rutas críticas, además de cadenas críticas y metodología de eventos en cadena disponibles como add-ons de terceros. Los calendarios pueden ser resource leveled, y las gráficas visualizadas en una Gráfica de Gantt. Adicionalmente, Project puede reconocer diferentes clases de usuarios, los cuales pueden contar con distintos niveles de acceso a proyectos, vistas y otros datos. Los objetos personalizables como calendarios, vistas, tablas, filtros y campos, son almacenados en un servidor que comparte la información con todos los usuarios. Microsoft Project y Project Server son piezas angulares del Microsoft Office Enterprise Project Management (EPM). 59

INTELIGENCIA ARTIFICIAL La capacidad de razonar de un agente no vivo.1 23 John McCarthy, acuñó el término en 1956, la definió: "Es la ciencia e ingenio de hacer máquinas inteligentes, especialmente programas de cómputo inteligentes."4 . •Búsqueda del estado requerido en el conjunto de los estados producidos por las acciones posibles. •Algoritmos genéticos (análogo al proceso de evolución de las cadenas de ADN). •Redes neuronales artificiales (análogo al funcionamiento físico del cerebro de animales y humanos). •Razonamiento mediante una lógica formal análogo al pensamiento abstracto humano. También existen distintos tipos de percepciones y acciones, pueden ser obtenidas y producidas, respectivamente por sensores físicos y sensores mecánicos en máquinas, pulsos eléctricos u ópticos en computadoras, tanto como por entradas y salidas de bits de un software y su entorno software. Varios ejemplos se encuentran en el área de control de sistemas, planificación automática, la habilidad de responder a diagnósticos y a consultas de los consumidores, reconocimiento de escritura, reconocimiento del habla y reconocimiento de patrones. Los sistemas de IA actualmente son parte de la rutina en campos como economía, medicina, ingeniería y la milicia, y se ha usado en gran variedad de aplicaciones de software, juegos de estrategia como ajedrez de computador y otros videojuegos. 60

LENGUAJE COBOL El lenguaje COBOL (acrónimo de COmmon BusinessOriented Language, Lenguaje Común Orientado a Negocios) fue creado en el año 1959 con el objetivo de crear un lenguaje de programación universal que pudiera ser usado en cualquier ordenador, ya que en los años 1960 existían numerosos modelos de ordenadores incompatibles entre sí, y que estuviera orientado principalmente a los negocios, es decir, a la llamada informática de gestión. •COBOL fue dotado de unas excelentes capacidades de auto documentación •Una buena gestión de archivos y una excelente gestión de los tipos de datos para la época, a través de la conocida sentencia PICTURE para la definición de campos estructurados. Para evitar errores de redondeo en los cálculos que se producen al convertir los números a binario y que son inaceptables en temas comerciales, COBOL puede emplear y emplea por defecto números en base diez. Para facilitar la creación de programas en COBOL, la sintaxis del mismo fue creada de forma que fuese parecida al idioma inglés, evitando el uso de símbolos que se impusieron en lenguajes de programación posteriores. Pese a esto, a comienzos de los ochenta se fue quedando anticuado respecto a los nuevos paradigmas de programación y a los lenguajes que los implementaban. En la revisión de 1985 se solucionó, incorporando a COBOL variables locales, recursividad, reserva de memoria dinámica y programación estructurada. En la revisión de 2002 se le añadió orientación a objetos, aunque desde la revisión de 1974 se podía crear un entorno de trabajo similar a la orientación a objetos, y un método de generación de pantallas gráficas estandarizado. Antes de la inclusión de las nuevas características en el estándar oficial, muchos fabricantes de compiladores las añadían de forma no estándar. En la actualidad este proceso se está viendo con la integración de COBOL con Internet. Existen varios compiladores que permiten emplear COBOL como lenguaje de scripting y de servicio web. También existen compiladores que permiten generar código COBOL para la plataforma .NET y EJB

REQUISITOS PRO IBM IBM Rational RequisitePro es una herramienta de gestión de requisitos y casos prácticos para los equipos de proyecto. Los equipos pueden crear y compartir sus requisitos mediante métodos conocidos basados en documentos, al tiempo que utilizan funciones de la base de datos como la rastreabilidad y el análisis de impacto. De esta manera se mejora la gestión de requisitos y comunicación, se aumenta la calidad y se acelera el tiempo de comercialización. Rational Requisite Pro es una herramienta fácil de utilizar que le ayuda a: •Evitar tareas de remodelación y duplicaciones gracias a la integración avanzada en tiempo real con Microsoft Word. •Gestionar la complejidad con vistas de rastreabilidad detalladas que muestran relaciones padre-hijo. •Mejorar la colaboración de equipos distribuidos geográficamente a través de una interfaz web escalable totalmente funcional e hilos de debate. •Capturar y analizar información de requisitos con personalización y filtrado detallado de atributos. •Aumentar la productividad haciendo un seguimiento de los cambios mediante comparaciones de las versiones del proyecto con líneas base de proyecto basadas en XML •Ajustar los objetivos empresariales con los productos finales del proyecto mediante la integración con varias herramientas en la plataforma de desarrollo y distribución de software de IBM Rational 62

SECOND LIFE Es un metaverso lanzado el 23 de junio de 2003, desarrollado por Linden Lab, al que se puede acceder gratuitamente Internet. Sus usuarios, conocidos como "residentes", pueden acceder a SL mediante el uso de uno de los múltiples programas de interfaz llamados viewers (visores), los cuales les permiten interactuar entre ellos mediante un ávatar.4 Los residentes pueden así explorar el mundo virtual, interactuar con otros residentes, establecer relaciones sociales, participar en diversas actividades tanto individuales como en grupo y crear y comerciar propiedad virtual y servicios entre ellos. SL está reservado para mayores de 18 años. Para acceder al programa es requisito imprescindible crear una cuenta, la cual da acceso al mundo y al ávatar individual. Los avatares son caracteres tridimensionales personalizables lo que le da a los usuarios la capacidad de convertirse el personaje que deseen y "disfrutar" (como el mismo nombre del programa indica) de una segunda vida. Su segundo atractivo más importante es la posibilidad de crear objetos e intercambiar diversidad de productos virtuales a través de un mercado abierto que tiene como moneda local el Linden Dólar (L$). En el mismo programa se incluye una herramienta de creación en 2D basada en simples figuras geométricas (conocidos como prims o primitivas) y que permite a los residentes la construcción de objetos virtuales. Estos elementos pueden usarse en combinación con el lenguaje de programación LSL o Linden Scripting Language a fin de añadir funcionalidad a los objetos. Objetos más complejos, como sculpties o complejos prims tridimensionales, texturas para ropas u objetos, animaciones o gestos pueden ser creados externamente e importados a SL. Los Términos de Servicio de SL (conocidos por su abreviatura inglesa: TOS) aseguraban, hasta recientes cambios, la retención de los derechos de autor por parte de los creadores de los objetos, mientras que Linden Labs proveía simples funciones de gestión de derechos digitales en sus servidores y su acceso. Los recientes cambios producidos en el TOS han eliminado gran parte de los derechos de los creadores, al establecerse Linden Labs como propietario de todo el software presente en sus servidores, eliminando el derecho de los creadores, al ser un entorno cerrado.

Para concluir en este curso se cumplieron todos los temas como ¿Qué es ingeniería de software? Un sistema informático está compuesto por hardware y software. Entre otros puntos como los costos de la ingeniería de software. Entre otros puntos como stak holders, requisitos de IBM, la clasificación de modelos de RUP, ya que esto sirve para un mejor proyecto porque se siguen varios pasos para un mejor proceso de ingeniería de software.