TRABAJO INVESTIGATIVO 01INGENIERIA DE SOFTWARE Presenta Camilo Andrés Frontado Escobar Erik Alexis Valderrama Alejandro Jiménez Mateus Harold Jhovany López Medina Docente Juan Carlos Guevara B. Asignatura Ingeniería de software Universidad Distrital Francisco José de Caldas Tecnología en Sistematización de datos Facultad Tecnológica Bogotá D.C Colombia - 14 de Febrero de 2016 CONTENIDO 2. Introducción……………………………………………………………………….…2 3. Ingeniería de software……………………………………………………………...3 3.1. Definición……………………………...……………………….………………….3 3.2. Objetivos……………………………...………………………..……………........3 3.3. Características………………………..……………………………………..……4 3.4. Historia………………………………..……………………………………..........4 4. Modelos de ciclo de vida del software…...………………………………………5 5. Metodologías de desarrollo de software ……...……………………………….13 6. Estándares para garantizar la calidad de software…...……………………….29 7. Modelos de evaluación de calidad de software………...………………..…….35 8. Elementos de un proyecto de desarrollo de software…..………………...…..39 9. Conclusiones………………………………………………………………...….…40 10. Bibliografía…………………………………………………………………..……41 2. INTRODUCCION Los ingenieros enfocados hacia el desarrollo de software siempre han tenido que enfrentarse con la realidad de una responsabilidad al entregar software de calidad, para ello tienen que adaptarse a las peticiones que requiere el cliente, llevándolas a un lenguaje en donde pueda establecer una simplificación de la realidad, proveyéndose de herramientas creadas por los estándares desarrollados por la ISO y la IEEE. A su vez de acuerdo a su propia perspectiva en base a los conocimientos adquiridos en su experiencia en la realización de proyectos sistematización de información, establece reglas de comportamiento que provean una metodología organizacional que le permite entregar su trabajo en el menor tiempo posible, el menor costo entre los rangos establecidos y en las mejores condiciones, para que los procesos a ser llevados por el usuario tengan tareas simples de entender para un funcionamiento adecuado del sistema creado. 3. INGENIERÌA DE SOFTWARE 3.1. Definición El IEEE cumputer society define la ingeniería de software como: Aplicación de un enfoque sistemático, disciplinario y cuantificable al desarrollo, operación y mantenimiento del software, es decir, la aplicación de la ingeniería al software. Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como desarrollo de software o producción de software (Bohem, 1976). El estudio de los métodos en la Aplicación de un enfoque sistemático, disciplinario y cuantificable al desarrollo, operación y mantenimiento del software, es decir, la aplicación de la ingeniería al software. 3.2. Objetivos Dirigir y coordinar el desarrollo de aplicaciones complejas. Intervenir en todas las fases del ciclo de vida de un producto. Estimar los costes de un proyecto y determinar los tiempos de desarrollo. Hacer el seguimiento de costes y plazos. Dirigir equipos de trabajo de desarrollo software. Organizar la realización de pruebas que verifiquen el correcto funcionamiento de los programas y que se ajustan a los requisitos de análisis y diseño. Diseñar, construir y administrar bases de datos. Dirigir y asesorar a los programadores durante el desarrollo de aplicaciones. Introducir procedimientos de calidad en los sistemas, evaluando métricas e indicadores y controlando la calidad del software producido. Organizar y supervisar el trabajo de su equipo de los técnicos de mantenimiento y los ingenieros de sistemas y redes. 3.3. Características - el software no se crea, se desarrolla. El software no se descompone, se desactualizada. El software se hace a la medida - Uso de Metodologías y herramientas para un buen desarrollo de software. Estar enfocado en cumplir las diferentes normas de calidad en cada proceso del ciclo de vida puestas por el IEEE o ISO. 3.4. Historia Cuando aparecieron las primeras computadoras digitales en la década de 1940, el desarrollo de software era algo tan nuevo que era casi imposible hacer predicciones de las fechas estimadas de finalización del proyecto y muchos de ellos sobrepasaban los presupuestos y tiempo estimados. Los desarrolladores tenían que volver a escribir todos sus programas para correr en máquinas nuevas que salían cada uno o dos años, haciendo obsoletas las ya existentes. El término Ingeniería del software apareció por primera vez a finales de la década de 1950. La Ingeniería de software fue estimulada por la crisis del software de las décadas de entre 1960 y 1980. La Ingeniería del software viene a ayudar a identificar y corregir mediante principios y metodologías los procesos de desarrollo y mantenimiento de sistemas de software. Aparte de la crisis del software de las décadas de entre 1960 y 1980, la ingeniería de software se ve afectada por accidentes que conllevaron a la muerte de tres personas; esto sucedió cuando la máquina de radioterapia Therac-25 emite una sobredosis masiva de radiación y afecto contra la vida de estas personas. Esto remarca los riesgos de control por software, afectando directamente al nombre de la ingeniería de software. A principios de los 1980, la ingeniería del software ya había surgido como una genuina profesión, para estar al lado de las ciencias de la computación y la ingeniería tradicional. Antes de esto, las tareas eran corridas poniendo tarjetas perforadas como entrada en el lector de tarjetas de la máquina y se esperaban los resultados devueltos por la impresora. Debido a la necesidad de traducir frecuentemente el software viejo para atender las necesidades de las nuevas máquinas, se desarrollaron lenguajes de orden superior. A medida que apareció el software libre, las organizaciones de usuarios comúnmente lo liberaban. Para la década de 1980, el costo de propiedad y mantenimiento del software fue dos veces más caro que el propio desarrollo del software, y durante la década de 1990, el costo de propiedad y mantenimiento aumentó 30 % con respecto a la década anterior. En 1995, muchos de los proyectos de desarrollo estaban operacionales, pero no eran considerados exitosos. El proyecto de software medio sobrepasaba en un 50 % la estimación de tiempo previamente realizada, además, el 75 % de todos los grandes productos de software que eran entregados al cliente tenían fallas tan graves, que no eran usados en lo absoluto o simplemente no cumplían con los requerimientos del cliente. Algunos expertos argumentaron que la crisis del software era debido a la falta de disciplina de los programadores. Cada nueva tecnología y práctica de la década de 1970 a la de 1990 fue pregonada como la única solución a todos los problemas y el caos que llevó a la crisis del software. Lo cierto es que la búsqueda de una única clave para el éxito nunca funcionó. El campo de la ingeniería de software parece un campo demasiado complejo y amplio para una única solución que sirva para mejorar la mayoría de los problemas, y cada problema representa sólo una pequeña porción de todos los problemas de software. El auge del uso del Internet llevó a un vertiginoso crecimiento en la demanda de sistemas internacionales de despliegue de información en la World Wide Web. Los desarrolladores se vieron en la tarea de manejar ilustraciones, mapas, fotografías y animaciones, a un ritmo nunca antes visto, con casi ningún método para optimizar la visualización y almacenamiento de imágenes. También fueron necesarios sistemas para traducir el flujo de información en múltiples idiomas extranjeros a lenguaje natural humano, con muchos sistemas de software diseñados para uso multilenguaje, basado en traductores humanos. La ingeniería de software contribuyo alrededor de 90,000 millones de dólares por año ya que entra en juego el Internet; esto hace que los desarrolladores tuviesen que manejar imágenes mapas y animaciones para optimizar la visualización/almacenamiento de imágenes (como el uso de imágenes en miniatura). El uso de los navegadores y utilización de lenguaje HTML cambia drásticamente la visión y recepción de la información. Después de una fuerte y creciente demanda surge la necesidad de crear soluciones de software a bajo costo, esto conlleva al uso de metodologías más simples y rápidas que desarrollan software funcional. Cabe señalar que los sistemas más pequeños tenían un enfoque más simple y rápido para poder administrar el desarrollo de cálculos y algoritmos de software. 4. MODELOS DE CICLO DE VIDA DEL SOFTWARE 4.1. NOMBRES La definición de un modelo de ciclo de vida del software está dada por el estado de las fases por las cuales se desarrolla un proyecto de software, estas fases desde la inicial hasta la final permiten la validación del desarrollo de la aplicación, gracias a esto se garantiza que el software cumpla con los requisitos de aplicación y verificación de los procedimientos de desarrollo, existen diferentes modelos de ciclo de vida del software los cuales han sido diseñados con el fin de rectificar errores, seguir lineamientos y estándares básicos en cuanto a desarrollo de software se refiere, mejoramiento en la calidad del software, cumplimientos de plazos de implementación y reducción de costos asociados. A continuación, mencionaremos los principales modelos de ciclo de vida del software: MODELO EN CASCADA: El modelo de ciclo de vida en cascada, es el más básico de todos los modelos, y sirve como bloque de construcción para los demás modelos de ciclo de vida. MODELO EN V: El modelo de ciclo de vida en V proviene del principio que establece que los procedimientos utilizados para probar si la aplicación cumple las especificaciones ya deben haberse creado en la fase de diseño. MODELO EN ESPIRAL: El modelo de ciclo de vida en espiral, es aquel donde el esfuerzo es iterativo, tan pronto como se completa una fase de desarrollo se comienza la otra. MODELO DE DESARROLLO CONCURRENTE: El modelo de ciclo de vida de desarrollo concurrente, define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la ingeniería del software. MODELO DE DESARROLLO INCREMENTAL: El modelo de ciclo de vida de desarrollo incremental, es aquel donde el proceso de construcción se basa en el incremento de subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo. MODELO DE DESARROLLO EVOLUTIVO: Consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. 4.2. EXPLICACIÓN DEL FUNCIONAMIENTO MODELO EN CASCADA: En el modelo en cascada se presenta una estructura secuencial, La visión del modelo en cascada es muy simple, se dice que el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuyen a la satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la fase. Las flechas muestran el flujo de información entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrás representan la retroalimentación. Está formado por las siguientes fases o etapas: - Análisis del Sistema - Análisis de Requisitos de Software - Diseño - Codificación - Prueba - Mantenimiento El desarrollo de las fases, como se ha mencionado antes, se produce de manera secuencial. Una vez se produce el análisis del sistema y de los requisitos del software demandado por el cliente, (fases en las que la intervención del cliente es absolutamente necesaria), se procede a la fase de diseño de la arquitectura global del software. Modelo en cascada MODELO EN V: En el modelo en V o también conocido como modelo de 4 niveles, se basa en el modelo de cascada pura a diferencia de que contiene dos sub etapas adicionales, El modelo de ciclo de vida V proviene del principio que establece que los procedimientos utilizados para probar si la aplicación cumple las especificaciones ya deben haberse creado en la fase de diseño. Modelo en V La anterior figura muestra como cada una de las fases de desarrollo (izquierda de la imagen), se alinean con la fase de testeo. - Lado Izquierdo: Especificaciones de los requerimientos del servicio hasta el detalle del diseño del servicio. Lado Derecho: Se focaliza en las actividades de validación que se llevan a cabo en contra de las especificaciones definidas a la izquierda. A cada uno de los pasos de la izquierda, hay implicación directa con la parte equivalente en el lado derecho. Dentro de cada uno de los ciclos del desarrollo repetitivo se pueden aplicar los conceptos del Modelo V sobre requerimientos de aprobación de estabilidad contra el diseño, con cada diseño repetitivo considerado para el grado de integridad y competencia que justificara el lanzamiento al cliente para juicio y valoración. MODELO EN ESPIRAL: El modelo en espiral, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteracciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema diseñado. El modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas. Modelo en espiral - Comunicación con el cliente: Las tareas requeridas para establecer comunicación entre el desarrollador y el cliente. - Planificación: Las tareas requeridas para definir recursos, el tiempo y otra información relacionadas con el proyecto. - Análisis de riesgos: Las tareas requeridas para evaluar riesgos técnicos y de gestión. - Ingeniería: Las tareas requeridas representaciones de la aplicación. - Construcción y entrega: Las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo: documentación y práctica) - Evaluación del cliente: Las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación. para construir una o más MODELO DE DESARROLLO CONCURRENTE: El Modelo de Desarrollo Concurrente, se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas. Este modelo se utiliza a menudo la arquitectura de desarrollo de aplicaciones cliente/servidor. Provee una meta-descripción del proceso del software. El modelo concurrente tiene la capacidad de describir las múltiples actividades del software ocurriendo simultáneamente. La mayoría de los modelos de procesos de desarrollo del software son dirigidos por el tiempo; cuanto más tarde sea, más atrás se encontrará en el proceso de desarrollo. Un modelo de proceso concurrente está dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones. El modelo de proceso concurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la ingeniería del software. Durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparará la actividad de análisis del estado hecho al estado cambios en espera. Esto genera la corrección del modelo de análisis de sucesos, que disparará la actividad de análisis del estado hecho al estado cambios en espera. Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo. Modelo de desarrollo concurrente Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones: 1. Dimensión de sistemas. 2. Dimensión de componentes. Los aspectos del nivel de sistema se afrontan mediante tres actividades: diseño, ensamblaje y uso. En realidad, el modelo de proceso concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto. MODELO DE DESARROLLO INCREMENTAL: El Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de prototipos. En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena, utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente. Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva, pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional. El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se puede añadir personal, de ser necesario. Por otro lado, los incrementos se pueden planear para gestionar riesgos técnicos. Modelo Incremental Las características del modelo incremental son las siguientes: - Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. - El usuario se involucra más. - Difícil de evaluar el coste total. - Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. - Requiere gestores experimentados. - Los errores en los requisitos se detectan tarde. - El resultado puede ser muy positivo. MODELO DE DESARROLLO EVOLUTIVO: El Modelo de desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de las recomendaciones o nuevos requerimientos por parte del cliente o del usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de separarse. Existen dos tipos de desarrollo evolutivo: - Desarrollo exploratorio: Es aquel donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente. - Prototipos desechables: Es aquel donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo. Modelo de desarrollo evolutivo Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más ventajas en comparación con un enfoque en cascada ya que el sistema se va ajustando a las necesidades del cliente, a la vez que él mismo entiende mejor sus propios requerimientos. Sin embargo, el enfoque evolutivo desde una perspectiva de ingeniería y gestión suele tener dos grandes problemas: El proceso no es visible. Los administradores tienen que hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión del sistema. A menudo los sistemas tienen una estructura deficiente. Los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en él se convierte cada vez más en una tarea difícil y costosa. Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado para sistemas pequeños y medianos. En los sistemas grandes, los constantes cambios en el desarrollo solo dificultan la estabilidad y la integración de los avances de los distintos grupos de trabajo que puedan existir. La mayoría de las empresas que desarrollan grandes sistemas usan un modelo mixto que usa las mayores fortalezas de los enfoques evolutivos y de cascada. 5. METODOLOGIAS DE DESARROLLO DE SOFTWARE 5.1. NOMBRES SCRUM: Scrum es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspección continua, adaptación, auto-gestión e innovación. RATIONAL UNIFIED PROCESS (RUP): Es una metodología cuyo fin es entregar un producto de software. Se estructura todos los procesos y se mide la eficiencia de la organización, en este proceso de desarrollo de software se utiliza el lenguaje unificado de modelado UML, el cual constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. STRUCTURED ANALYSIS AND DESIGN TECHNIQUE (SADT): Es una técnica de análisis y diseño de sistemas que ha sido ampliamente utilizada para la definición de sistemas, el análisis de requisitos de software y el diseño de sistemas/software consiste en un conjunto de procedimientos que permiten al analista descomponer las funciones del software (o del sistema) EXTREME PROGRAMMING (XP): Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. ENTERPRISE UNIFIED PROCESS (EUP): La metodología Enterprise Unified Process, EUP, se basa en la extensión de la metodología Rational Unified Process, RUP. Esta extensión se da en dos fases más y una sección de disciplinas de soporte que agrega cuatro disciplinas más a las que ya cuenta la metodología RUP. AGILE UNIFIED PROCESS (AUP): La metodologia AUP aplica técnicas ágiles incluyendo Desarrollo Dirigido por Pruebas (test driven development - TDD), Modelado Ágil, Gestión de Cambios Ágil, y Refactorización de Base de Datos para mejorar la productividad. 5.2. ETAPAS Y ACTIVIDADES SCRUM: Es una metodología de desarrollo muy simple, que requiere trabajo duro porque no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto. Scrum es una metodología ágil, y como tal: - - Es un modo de desarrollo de carácter adaptable más que predictivo. Orientado a las personas más que a los procesos. Emplea la estructura de desarrollo ágil: incremental basada en iteraciones y revisiones. Se comienza con la visión general del producto, especificando y dando detalle a las funcionalidades o partes que tienen mayor prioridad de desarrollo y que pueden llevarse a cabo en un periodo de tiempo breve (normalmente de 30 días). Cada uno de estos periodos de desarrollo es una iteración que finaliza con la producción de un incremento operativo del producto. Estas iteraciones son la base del desarrollo ágil, y Scrum gestiona su evolución a través de reuniones breves diarias en las que todo el equipo revisa el trabajo realizado el día anterior y el previsto para el día siguiente. Que se requiere para aplicar correctamente la metodología Scrum: Actores: - - Product Owner: Representa la voz del cliente. Escribe historias de usuario, las prioriza, y las coloca en el Product Backlog. Scrum Master: Protege al equipo de distracciones y de otros elementos externos (presiones no razonables). Elimina obstáculos que alejen al grupo de la consecución de objetivos del sprint. No es el líder del grupo, ya que el grupo se autogestiona. Equipo: Tiene la responsabilidad de entregar el producto. Scrum, propone tres herramientas o "artefactos" para mantener organizados nuestros proyectos. Estos artefactos, ayudan a planificar y revisar cada uno de los Sprints, aportando medios ineludibles para efectuar cada una de las ceremonias que veremos en un siguiente capítulo. Describiremos ahora, cada uno de los artefactos, su definición e importancia para Scrum: Backlog de Producto: Es un listado dinámico y públicamente visible para todos los involucrados en el proyecto. En él, el Dueño de Producto, mantiene una lista actualizada de requerimientos funcionales para el software. Esta lista, representa "qué es lo que se pretende" pero sin mencionar "cómo hacerlo", ya que esta última, como vimos en el capítulo anterior, será tarea del Scrum Team. El Backlog de Producto, es creado y modificado únicamente por el Dueño de Producto. Durante la ceremonia de planificación, el Scrum Team obtendrá los ítems del producto, que deberá desarrollar durante el Sprint. Formato del Backlog de Producto El Backlog de producto, es una lista de ítems que representan los requerimientos funcionales esperados para el software. Para cada uno de estos ítems, será necesario especificar: - El grado de prioridad Esfuerzo que demanda Granulidad Criterios de aceptación Backlog de Sprint: Es la recopilación sintética de items del Backlog de Producto, negociados entre el Dueño de Producto y el Scrum Team en la ceremonia de planificación, reunión que se realiza al comienzo del Sprint. Esta recopilación, que durante la planificación ha sido propuesta por el Dueño de Producto y ya negociada, es aquella que el Scrum Team se compromete a construir durante el Sprint en curso. El Backlog de Sprint, generalmente, se visualiza mediante tableros físicos también llamados Scrum Taskboard que hacen visible el proceso de construcción, a toda persona que ingrese al área de desarrollo. Para armar el Backlog de Sprint, el Scrum Team, divide los items en tareas “tasks” de que no demanden una labor superar a una jornada de trabajo. Es decir, que una tarea, no debería superar las 8 horas de trabajo. Estas tareas, serán divididas en pendientes, en curso y terminadas y cada una de ellas, debe permitir visualizar, como mínimo, el esfuerzo que demanda su construcción y el nombre del miembro del equipo que se ha asignado dicha tarea. Es muy frecuente, a la vez de ser una práctica recomendada, que cada tarea sea a la vez, "etiquetada", diferenciando, por ejemplo, cuando representa un bug, una tarea de diseño, un test, etc. Incremento de Funcionalidad: Es el que el equipo entrega al finalizar el Sprint. El mismo debe asemejarse a un "software funcionando", permitiendo implementarse operativamente sin restricciones en un ambiente productivo. RATIONAL UNIFIED PROCESS (RUP): El RUP es un conjunto de metodologías adaptables al contexto y necesidades de cada organización. Describe cómo aplicar enfoques para el desarrollo del software, llevando a cabo unos pasos para su realización. Se centra en la producción y mantenimiento de modelos del sistema. Sus principales características son: - Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo) Pretende implementar las mejores prácticas en Ingeniería de Software Desarrollo iterativo Administración de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificación de la calidad del software El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como, por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso). Ciclo de vida del RUP: El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en 4 fases e iteraciones: 1. Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores. 2. Fase de elaboración: En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar. 3. Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requerimientos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. 4. Fase de Cierre: El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto. La metodología RUP está constituida por 6 principios claves estos son: 1. 2. 3. 4. 5. 6. Adaptación del proceso. Balancear prioridades. Colaboración entre equipos. Demostrar valor iterativamente. Elevar el nivel de abstracción. Enfocarse en la calidad. RUP en cada una de sus fases (pertenecientes a la estructura estática) realiza una serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema (entre otros). Estos artefactos (entre otros) son los siguientes: Inicio: - Documento Visión Especificación de Requerimientos Elaboración: - Diagramas de caso de uso Construcción: - Documento Arquitectura que trabaja con las siguientes vistas: Vista lógica: - Diagrama de clases Modelo E-R (Si el sistema así lo requiere) Vista de implementación: - Diagrama de Secuencia Diagrama de estados Diagrama de Colaboración Vista conceptual: - Modelo de dominio Vista física: - Mapa de comportamiento a nivel de hardware STRUCTURED ANALYSIS AND DESIGN TECHNIQUE (SADT): La metodología SADT engloba un conjunto de herramientas automáticas de soporte para los procedimientos de análisis y un método organizativo bien definido mediante el que se aplican las herramientas. Quedan especificadas revisiones y puntos de referencia que permiten una validación de la comunicación entre el cliente y el desarrollador. Etapas De La Planeación Estratégica De Sistemas Para llevar a cabo una planeación de sistemas se requiere de 3 pasos: - Establecer las metas de los sistemas, Determinar y asignar prioridades a las solicitudes de proyectos de sistemas. Evaluar los recursos y la capacidad de los sistemas. Establecer las metas de los sistemas: Este paso implica la revisión de la dimensión de las operaciones de la organización, las políticas de sistemas y el plan de la empresa. El objetivo principal es establecer las metas de la organización y enlazarlas con las metas de los sistemas. A partir de esto empiezan a surgir ideas de proyectos en sistemas para dar soporte a estas metas. Para dar forma a las ideas de proyectos, se recopila información de entrada de los miembros del equipo, incluyendo información de otras personas que puedan contribuir al proceso de planeación como consultores y auditores internos. El proceso de planeación deberá alinear sus actividades con la estrategia de la empresa, enfocando los proyectos hacia las metas estratégicas de la compañía e identificando las áreas en las que probablemente se encontraran oportunidades con altos beneficios. A partir de este proceso de investigación se plantean metas generales de sistemas de información. Estas metas pueden proponerse como: - Diseño e implementación de sistemas que apoyen a las metas organizacionales, Aprovechar las oportunidades de negocios proporcionadas por las nuevas tecnologías informáticas y seguir una metodología de desarrollo de sistemas que interactúe con los usuarios y proporcione el estado de los sistemas. Determinar y asignar prioridades a las solicitudes de proyectos de sistemas. Durante el paso anterior se tiene una gran comunicación entre los usuarios y el personal de sistemas. A partir de esta interacción empiezan a formalizarse los proyectos, formado por algunas ideas de los usuarios como ideas provenientes por el personal de sistemas. Siendo, en cualquier caso, se producen solicitudes de proyectos de sistemas y se realiza en un intercambio libre de ideas. Para ello ninguna compañía, ni su sistema de información cuentan con los recursos necesarios para atender a las solicitudes de proyectos de sistemas, ni todas las solicitudes son buenas. El resultado final es un conjunto de diagramas que contienen las actividades del proceso, cuidadosamente coordinados y organizados en niveles, que empiezan por el diagrama de nivel más general y terminan por los de detalle. Cualquier actividad compleja puede subdividirse en actividades más detalladas. Los flujos que interconectan actividades se clasifican en cuatro tipos de acuerdo a su significado: - Entrada: hace referencia a la información que se utilizará para producir las salidas de la actividad. La entrada es transformada por la actividad. Salida: se trata de información que se produce en la actividad. Control: se trata de restricciones que afectan a una actividad. Regula la producción de las salidas a partir de las entradas, pudiendo indicar cómo y cuando se producen las salidas. Mecanismo: normalmente se refiere a maquinas, personas, recursos o sistemas existentes que ejecutan la actividad. Es importante incluir aquellos mecanismos que serán diferentes en el entorno actual y en el entorno futuro. Al incorporar controles que regulan las actividades, los flujos de salida de una actividad pueden actuar como controles e incluso mecanismos en la actividad precedente o dependiente. Los diagramas SADT requieren una serie de puntos de partida: - Concretar el tema a tratar. Asumir un punto de vista determinado. Fijar un objetivo. El primero permite definir el ámbito dentro y fuera de la organización y el segundo proporciona una guía al construir el modelo. Por último, el objetivo ayuda a decidir cuándo se finaliza en la construcción del modelo. EXTREME PROGRAMMING (XP): La metodología de Programación Extrema es una de las llamadas Metodologías Ágiles de desarrollo de software más exitosas de los tiempos recientes, nace como nueva disciplina de desarrollo de software. La programación extrema se basa en la simplicidad, la comunicación y el reciclado continuo de código, para algunos no es más que aplicar una pura lógica. Los Valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda edición de Extreme Programming Explained. Los cinco valores se detallan a continuación: - - - - - La Simplicidad: Es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hace que la complejidad aumente exponencialmente. La Comunicación: Se realiza de diferentes formas, para los Programadores el código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. El código auto-documentado es más fiable que los comentarios ya que éstos últimos pronto quedan desfasados con el código a medida que es modificado. Debe comentarse sólo aquello que no va a variar, por ejemplo, el objetivo de una clase o la funcionalidad de un método. Las Pruebas Unitarias: son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de cómo utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide qué características tienen prioridad y siempre debe estar disponible para solucionar dudas. Retroalimentación feedback: Al estar el cliente integrado en el Proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante. Considérense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El código también es una fuente de retroalimentación gracias a las Herramientas de desarrollo. Coraje o valentía: Los puntos anteriores parecen tener sentido común, entonces, ¿por qué coraje? Para los gerentes la programación en parejas puede ser difícil de aceptar, porque les parece como si la productividad se fuese a reducir a la mitad ya que solo la mitad de los programadores está escribiendo código. Las Cuatro Actividades Básicas Ahora que tenemos nuestros cuatro valores estamos preparados para construir una Disciplina de Desarrollo de software. ¿Qué tareas debemos de llevar a cabo para desarrollar un buen software? Codificar: Es la única actividad de la que no podremos prescindir. Sin código fuente no hay programa, aunque hay gente que cuenta que existe software en producción del que se perdió el código fuente. Por tanto, necesitamos codificar y plasmar nuestras ideas a través del código. En una programación en PX en pareja el código expresa tu interpretación del problema, así podemos utilizarlo para comunicar, para hacer mías tus ideas, y por tanto para aprender y mejorar. Hacer pruebas: Las características del software que no pueden ser demostradas mediante pruebas simplemente no existen. Las pruebas me dan la oportunidad de saber si lo que implementé es lo que en realidad yo pensaba que había implementado. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema entonces has acabado por completo. Escuchar: Los programadores no lo conocemos todo, y sobre todo muchas cosas que las personas de negocios piensan que son interesantes. Si ellos pudieran programarse su propio software ¿para qué nos querrían? Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quién necesita la información. Diseñar: El Diseño crea una estructura que organiza la lógica del sistema, un buen diseño permite que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, divídela en varias. Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos cuanto antes. A continuación, describimos los artefactos de Xp, entre los que se encuentran: Historias de Usuario, Tareas de Ingeniería y Tarjetas CRC. Historias de Usuario Representan una breve descripción del comportamiento del sistema, emplea terminología del cliente sin lenguaje técnico, se realiza una por cada característica principal del sistema, se emplean para hacer estimaciones de tiempo y para el plan de lanzamientos, reemplazan un gran documento de requisitos y presiden la creación de las pruebas de aceptación. Estas deben proporcionar sólo el detalle suficiente como para poder hacer razonable la estimación de cuánto tiempo requiere la implementación de la historia, difiere de los casos de uso porque son escritos por el cliente, no por los programadores, empleando terminología del cliente. "Las historias de usuario son más "amigables" que los casos de uso formales". Tareas de Ingeniería: La siguiente es una breve descripción de la tarjeta que contiene los datos mínimos que contiene una tarea de ingeniería. Tarjetas CRC (Clase - Responsabilidad – Colaborador): Estas tarjetas se dividen en tres secciones que contienen la información del nombre de la clase, sus responsabilidades y sus colaboradores. En la siguiente figura se muestra cómo se distribuye esta información. ENTERPRISE UNIFIED PROCESS (EUP): La metodología Enterprise Unified Process, EUP, se basa en la extensión de la metodología Rational Unified Process, RUP. Esta extensión se da en dos fases más y una sección de disciplinas de soporte que agrega cuatro disciplinas más a las que ya cuenta la metodología RUP. La diferencia teórica entre RUP y EUP es que la metodología RUP se enfoca únicamente en el ciclo de vida del desarrollo de software, en cambio el EUP cubre el ciclo de vida de la tecnología de información, es decir, abarca una visión más amplia que el desarrollo de software enfocándose en las etapas siguientes a la elaboración del software, etapas como por ejemplo la inserción del nuevo sistema en una empresa donde se cuenta con otro sistema antiguo, para esto se deberá de decidir si los dos sistemas van en paralelo o si uno se retira por completo o en otro caso si se complementan. Esta descripción es un pequeño ejemplo de los temas que se deben de tomar en cuenta fuera de únicamente la elaboración del software. Describiendo las fases agregadas por EUP, se podrá tener una compresión más clara de este tema. Las dos nuevas fases son: La fase de Producción, cuyo objetivo principal es mantener un sistema en perfecto estado, permitiendo que el sistema se encuentre accesible y utilizable por todos los usuarios; además, brinda ayuda a usuarios para el manejo del sistema en caso este presente algún desperfecto, siendo así se recopila esta información para poder preparar una nueva versión del sistema. La fase de Retiro, es la segunda fase cuyo objetivo es remover el sistema actual implementado en un entorno empresarial de tal manera que se minimicen los impactos que les puedan brindar a los usuarios para que continúen con sus operaciones empresariales de una manera normal. Las disciplinas agregadas por EUP son: La disciplina de Modelamiento de Negocio Empresarial, la que aparte de modelar el negocio del proyecto en general se basa en especificar las actividades y procesos empresariales de los cuales se puede extraer información que ayuda para saber que nuevos procesos o actividades, que no se han tomado en cuenta, se pueden automatizar. La disciplina de Administración del Portafolio se basa en organizar los pequeños componentes de software, que muchas veces se realizan por separado, con el fin de unificarlos y administrarlos según los objetivos que cada uno de estos tengan. La disciplina de Arquitectura Empresarial está relacionada a modelos que demuestran cómo funcionan los diferentes tipos de arquitectura, prototipos y buenas prácticas. Dentro de esta disciplina se toman en cuenta las arquitecturas de negocio, aplicación, datos y red; esto organiza el proyecto a un mayor nivel ya que dentro de cada arquitectura se especifican diferentes tipos de documentos asociados a estas cuatro ramas que todo software debe contener. La disciplina de Estrategia de Re-uso, se basa en reutilizar componentes de software que son necesitados en más de un proceso, se toma en cuenta su documentación y organización por cada proceso empresarial. La Administración de Recursos Humanos es una disciplina que apoya a la organización de planes, actividades y calendarios según responsabilidades al momento del desarrollo de software, a su vez se toma en cuenta las interacciones entre los colaboradores del proyecto, es decir formación de grupos de trabajo. La disciplina de Administración Empresarial se basa en el objetivo principal de definir cómo una organización crea, mantiene y administra información física del proyecto a realizar. Finalmente, la última disciplina añadida por EUP es la disciplina Mejora de Procesos de Software, ésta asegura que la organización pueda definir, implementar y envolver más de un proceso apropiado brindando ayuda para conocer las metas finales de tu proyecto determinadas en base a tus necesidades de negocio. AGILE UNIFIED PROCESS (AUP): El Proceso Unificado Agil de Scott Ambler o Agile Unified Process (AUP) en inglés es una versión simplificada del Proceso Unificado de Rational (RUP). Este describe de una manera simple y fácil de entender la forma de desarrollar aplicaciones de software de negocio usando técnicas ágiles y conceptos que aún se mantienen válidos en RUP. El AUP aplica técnicas ágiles incluyendo Desarrollo Dirigido por Pruebas (test driven development - TDD), Modelado Agil, Gestión de Cambios Agil, y Refactorización de Base de Datos para mejorar la productividad. El proceso unificado (Unified Process o UP) es un marco de desarrollo software iterativo e incremental. A menudo es considerado como un proceso altamente ceremonioso porque especifica muchas actividades y artefactos involucrados en el desarrollo de un proyecto software. Dado que es un marco de procesos, puede ser adaptado y la más conocida es RUP (Rational Unified Process) de IBM. AUP se preocupa especialmente de la gestión de riesgos. Propone que aquellos elementos con alto riesgo obtengan prioridad en el proceso de desarrollo y sean abordados en etapas tempranas del mismo. Para ello, se crean y mantienen listas identificando los riesgos desde etapas iníciales del proyecto. Especialmente relevante en este sentido es el desarrollo de prototipos ejecutables durante la base de elaboración del producto, donde se demuestre la validez de la arquitectura para los requisitos clave del producto y que determinan los riesgos técnicos. El proceso AUP establece un Modelo más simple que el que aparece en RUP por lo que reúne en una única disciplina las disciplinas de Modelado de Negocio, Requisitos y Análisis y Diseño. El resto de disciplinas (Implementación, Pruebas, Despliegue, Gestión de Configuración, Gestión y Entorno) coinciden con las restantes de RUP. CICLO DE VIDA DEL PROCESO UNIFICADO AGIL (AUP): Al igual que en RUP, en AUP se establecen cuatro fases que transcurren de manera consecutiva y que acaban con hitos claros alcanzados: Inception(Concepción): El objetivo de esta fase es obtener una comprensión común cliente-equipo de desarrollo del alcance del nuevo sistema y definir una o varias arquitecturas candidatas para el mismo. Elaboración: El objetivo es que el equipo de desarrollo profundice en la comprensión de los requisitos del sistema y en validar la arquitectura. Construcción: Durante la fase de construcción el sistema es desarrollado y probado al completo en el ambiente de desarrollo. Transición: el sistema se lleva a los entornos de preproducción donde se somete a pruebas de validación y aceptación y finalmente se despliega en los sistemas de producción. Las disciplinas se llevan a cabo de manera sistemática, a la definición de las actividades que realizan los miembros del equipo de desarrollo a fin de desarrollar, validar, y entregar el software de trabajo que responda a las necesidades de sus interlocutores. Las disciplinas son: 1. Modelo. El objetivo de esta disciplina es entender el negocio de la organización, el problema de dominio que se abordan en el proyecto, y determinar una solución viable para resolver el problema de dominio. 2. Aplicación. El objetivo de esta disciplina es transformar su modelo (s) en código ejecutable y realizar un nivel básico de las pruebas, en particular, la unidad de pruebas. 3. Prueba. El objetivo de esta disciplina consiste en realizar una evaluación objetiva para garantizar la calidad. Esto incluye la búsqueda de defectos, validar que el sistema funciona tal como está establecido, y verificando que se cumplan los requisitos. 4. Despliegue. El objetivo de esta disciplina es la prestación y ejecución del sistema y que el mismo este a disposición de los usuarios finales. 5. Gestión de configuración. El objetivo de esta disciplina es la gestión de acceso a herramientas de su proyecto. Esto incluye no sólo el seguimiento de las versiones con el tiempo, sino también el control y gestión del cambio para ellos. 6. Gestión de proyectos. El objetivo de esta disciplina es dirigir las actividades que se lleva a cabo en el proyecto. Esto incluye la gestión de riesgos, la dirección de personas (la asignación de tareas, el seguimiento de los progresos, etc), coordinación con el personal y los sistemas fuera del alcance del proyecto para asegurarse de que es entregado a tiempo y dentro del presupuesto. 7. Entorno. El objetivo de esta disciplina es apoyar el resto de los esfuerzos por garantizar que el proceso sea el adecuado, la orientación (normas y directrices), y herramientas (hardware, software, etc) estén disponibles para el equipo según sea necesario. INCREMENTO Y DESARROLLO DE AUP: Los equipos de AUP suelen ofrecer versiones de desarrollo al final de cada iteración en preproducción área (s). Una versión de desarrollo de una aplicación es algo que podrían ser liberados en la producción si se ponen a través de su pre-producción de garantía de calidad (QA), las pruebas y los procesos de despliegue. La primera producción de liberación a menudo toma más tiempo para entregar versiones posteriores. La primera producción de liberación puede tomar doce meses para entregar la segunda versión de nueve meses, y luego otras liberaciones se entregan cada seis meses. Una de las primeras se centra en cuestiones de despliegue, no sólo permite evitar los problemas, sino que también permite tomar ventaja de sus experiencias durante el desarrollo. Por ejemplo, cuando despliegue un software en su área deberá tomar notas de lo que funciona y lo que no, toma nota de que puede servir como la columna vertebral de su instalación de scripts. PRINCIPIOS DE LA AUP: La AUP es ágil, porque está basada en los siguientes principios: 1. El personal sabe lo que está haciendo. La gente no va a leer detallado el proceso de documentación, pero algunos quieren una orientación de alto nivel y / o formación de vez en cuando. La AUP producto proporciona enlaces a muchos de los detalles, si usted está interesado, pero no obliga a aquellos que no lo deseen. 2. Simplicidad. Todo se describe concisamente utilizando un puñado de páginas, no miles de ellos. 3. Agilidad. Ágil ARRIBA El ajuste a los valores y principios de la Alianza Ágil. 4. Centrarse en actividades de alto valor. La atención se centra en las actividades que se ve que son esenciales para el de desarrollo, no todas las actividades que suceden forman parte del proyecto. 5. Herramienta de la independencia. Usted puede usar cualquier conjunto de herramientas que usted desea con el ágil UP. Lo aconsejable es utilizar las herramientas que son las más adecuadas para el trabajo, que a menudo son las herramientas simples o incluso herramientas de código abierto. 6. Adaptación de este producto para satisfacer sus propias necesidades. La AUP producto es de fácil acomodo común a través de cualquier herramienta de edición de HTML. No se necesita comprar una herramienta especial, o tomar un curso, para adaptar la AUP. 6. ESTANDARES 6.1 IEEE-STD-830: ESPECIFICACIONES DE REQUERIMIENTOS DEL SISTEMA La IEEE 830 se centra en el análisis y desarrollo de requerimientos, es un documento en el cual se integran los requerimientos del sistema desde cualquier punto de vista (usuario, cliente y desarrollador), se crea con la base fundamental de no caer en errores que permitan poner en peligro el proyecto, incurriendo en coste o impidiendo la entrega estimada de dicha solución. Se debe considerar que el ERS (Especificaciones de requerimientos del sistema) debe comprender la totalidad de los requerimientos funcionales y no funcionales, estableciendo un acuerdo entre el cliente y el desarrollador, es una base fundamental en el desarrollo del software. Es decir el desarrollador exige detalladamente que debe hacer el software, exigiendo paramétricamente ¿Qué debe hacer el programa?, ¿Cuáles son los parámetros de entrada y de salida que intervienen en el proceso?, ¿En qué maquina van a ser ejecutados los procesos? y ¿Qué tipos de usuarios directa o indirectamente intervendrán en el sistema?; todas estas preguntas determinan que la satisfacción del cliente se adapte a lo que exigió al principio. Un ejemplo de aplicación, se puede considerar que en la documentación de las tesis de grado para las carreras enfocadas a los sistemas de información, la mayoría de universidades exigen una documentación en donde se analizan los requerimiento de la empresa cuando se habla de una pasantía en donde se va a la etapa de levantamiento de información en donde se solicita los requerimientos que se darán para las pautas de la solución final. Para más claro un ejemplo de una tesis de grado de Cedeño Lolima en donde se especifican los requisitos funcionales y no funcionales para un sistema de automatización de los servicios administrativos en el área de medicina de la Universidad de Oriente- Núcleo Monagas. Requisitos Funcionales del Sistema Requisitos No funcionales del Sistema Tomado de https://docs.google.com/viewer? a=v&pid=sites&srcid=dWRvLmVkdS52ZXxhZHNpfGd4OjE5MDRjYmQxNjFiZjY4OTI 6.2 SPICE/ISO/IEC15504: DETERMINACIÓN DE LA CAPACIDAD DE MEJORA DEL PROCESO DE SOFTWARE La norma ISO 15504 es utilizada para mejorar la capacidad y madurez de los procesos, en donde se evalúan los actividades primarias, de soporte y de organización que intervienen en un software, gestionando los recursos y dimensionando la capacidad al momento de la evaluación con el fin de llegar a una optimización accediendo a diferentes niveles de madurez. Aplicando estas técnicas estandarizadas se obtienen ventajas que aportan a las empresas un buen desarrollo y mantenimiento. Componentes Esta norma se conforma por un conjunto de actividades que interviene en el proceso completo de desarrollo de un software, desde la definición y entendimiento del problema a automatizar hasta la entrega y demostración del mismo. Niveles de madurez establecidos en la Norma ISO 15504 Aplicación Un ejemplo de la aplicación se puede ver en el documento “Una aplicación de la norma ISO/IEC 15504 para la evaluación por niveles de madurez de Pymes y pequeños equipos de desarrollo”, desarrollado por Javier Garzas, Carlos Manuel Fernandez y Mario Piatinni en la Universidad Autónoma del Estado de México, en donde se buscaba minimizar los problemas que en la actualidad PYMEs y pequeños grupos tienen para la búsqueda de mejorar los proceso con las organizaciones asociadas a procesos de software indexadas. El documento completo se puede encontrar http://www.redalyc.org/articulo.oa?id=92217153012 . en la siguiente url: 6.3 ISO/IEC 12207: CICLO DE VIDA DEL PROCESO DEL SOFTWARE La norma 12207 está orientada a los procesos de ciclo de vida del software, establece actividades que se aplican desde la definición de requisitos hasta la finalización del uso del servicio del sistema, su objetivo principal es esclarecer un lenguaje de uso común para todo tipo de individuo que intervenga en la solución final. Componentes Este estándar fue concebido a partir del interés de la adquisición de software, el software indica una serie de procesos, entre la recolección de requisitos específicos del sistema hasta la culminación del software, estos procesos se agrupan en tres categorías: - Procesos principales: Son los promotores para mejorar las funciones en el ciclo de vida. - Procesos de apoyo: Identifica una necesidad, prepara la solicitud y selecciona un proveedor Procesos organizativos: Determina procesos y recursos para gestionar el proyecto. Vista General de los procesos y subdivisión de procesos en el ciclo de vida de software Aquí se entiende la estructura general de subdivisión de un proceso. El cada proceso de ciclo vida, el cual está dividido en un con junto de actividades, en el cual cada uno está conformado por un conjunto de tareas para ser llevadas a cabo secuencialmente. Su estructura se basa en el principio de modularidad, que pretende establecer procesos con un mínimo de acoplamiento y una máxima cohesión y de responsabilidad, el cual busca establecer un grupo para cada proceso, facilitando la aplicación de propiedades, en los cuales pueden intervenir uno o más individuos. Aplicación Aunque la mayoría de veces esta norma se aplica a los diferentes proyectos uno lo plasman Francisco J. Pino, Félix García, Francisco Ruiz, Mario Piattini en el artículo “Adaptación de las Normas ISO/IEC 12207:2002 e ISO/IEC 1504:2003 para la Evaluación de la Madure de Procesos Software en Países en Desarrollo“, en donde se especifica un modelo para motivar a las micro, pequeña y medianas empresas del sector encargado para la producción de software y en general al gremio computo-informático, a mejorar sus procesos de desarrollo con el objetivo de garantizar para ellas misma un nivel de madurez en sus procesos internos de división de plan de trabajo, y de forma un poco especifica esclarecer un modelo de calidad que les permita mantener un reconocimiento que les permita una mejor competencia internacional, por lo cual es de vital importancia esclarecer sus mejores características y compararlas con modelos internacionales que reconocidos por tu optimización hacia el mejoramiento, evaluación y calidad. 6.4 IEEE STD 730 – PLAN DE ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE Es el proceso por el cual se desarrolla un plan de calidad para desarrollar un proyecto determinado, esto define la calidad del software y describe como valorarla. Aunque medir la calidad del software es difícil por la complejidad que lleva se desarrollaron pautas que nos hacen asegurar la calidad del software. Este estándar es una recomendación, para aplicar la SQA (Saber, Querer Saber y Aprendido), verificando el coste que puede desvariar en componentes que permiten asegurar: - La minimización de errores en la ejecución por parte del usuario Satisfacción del cliente Cumplimiento de los requisitos extrínsecos, expresos e intrínsecos La cercanía a la visión de todo tipo de usuario Para esto tenemos que basarnos en diagramas de adaptación de series de pasos, que permiten establecer procesos que aseguren la calidad de software (Plan SQA) Diagrama general de asegurar la calidad del software Componentes Propósito: Se debe especificar con claridad cuál es el propósito del plan en el desarrollo del proyecto específico analizado la ubicación del proyecto, la organización y los estándares que se usaran. Referencias: Es donde se establecen las referencias que se usaran en el proyecto, implica la documentación que se usó en el desarrollo de un buen escrito, hacer un llamado a los estándares que se están usando a su vez información adicional que se utilizó de manera implícita. Roles y Responsabilidades: Identifica personas responsables de cada uno de los procesos, indicando nombres el rol que poseen y una especificación de las actividades de las cuales son responsables dentro del proyecto. Documentación: En esta parte se especificada de manera clara y objetiva toda la información que se generara en cada fase del proyecto, esto nos ayuda a especificar en cada parte del proyecto la información que se está generando. Estándares, prácticas, convenciones y métricas: Se especifican los estándares que se usaran, definir las métricas y la forma en la cual se obtendrán, también solamente se especifican como se usara cada estándar en cada parte. Revisiones y auditorias: Se indica el momento y los elementos que se estarán revisando durante el proyecto, aquí es donde verificamos por los cuales aseguramos la calidad y verificar los roles que son los encargados uno a uno. Reporte de problemas: Especificar los problemas de calidad y la persona indicada para reportarlos, además de especificar un mecanismo de resolución, aquí se puede verificar de manera preventiva ayudando la calidad del producto, las personas encargadas y como trabajan. Técnicas, herramientas y metodologías: Especifican la metodología que se usaran dentro del proyecto, mirando un plan de trabajo. Se indican las herramientas que se usaran junto con las técnicas que ayudaran para el cumplimiento de la metodología del trabajo. Mecanismo de control: Indica los mecanismos para asegurar que cada etapa se lleva a cabo en el tiempo previsto, se verifican las especificaciones de cada proceso. Aplicación La revista de la Escuela de Administración de Negocios describió en 1999 una sección en donde Saulo Ernesto Rojas Salamanca especificaba la Calidad del Software en la Industria de la Informática, donde se ha especificado las características del Plan de Aseguramiento de Calidad para intervenir con las técnicas de ingeniería, para complementar los modelos para el mejoramiento de la teoría de software. 7. MODELOS DE EVALUACIÓN DE CALIDAD DE SOFTWARE 7.1. MODELO DE McCALL Fue el primer modelo, presentado en el 1977 y se originó motivado por Air Forcé y Dod. Este modelo se focaliza en el producto final identificando atributos claves desde el punto de vista del cliente, a su vez estos atributos se denominan factores de calidad y son normalmente atributos externos pero también se incluyen algunos atributos internos. Los factores de calidad son demasiados abstractos para ser medidos directamente, por lo que por cada uno de ellos se introduce atributos de bajo nivel denominados criterios de calidad, para los cuales, algunos son atributos internos, lo cual refleja la creencia de McCall que el atributo interno tiene un efecto directo en el atributo externo correspondiente. El modelo de McCall organiza los factores de calidad en tres perspectivas, ver figura 1, desde los cuales el usuario puede contemplar la calidad de un producto: Revisión del producto, habilidad para ser cambiado. Transición del producto, adaptabilidad al nuevo ambiente. Operación del producto, características de operación. Figura 1. Estructura modelo de McCall, tomada de http://vanevargas.jimdo.com/m %C3%B3dulos/modelos/modelo-de-mccall/ La revisión del producto incluye los siguientes factores de calidad: Mantenibilidad: Esfuerzo requerido para localizar y corregir fallas, McCall incluye en el factor de mantenibilidad criterios como la consistencia, simplicidad, concisidad, auto-descripción y la modularidad. Flexibilidad: Facilidad de realizar cambios, el cual incluye factores como la expansibilidad, generalidad, auto-descripción y modularidad. Testeabilidad: Facilidad para realizar el testing, para asegurarse que el producto no tiene errores y cumple con la especificación. Este factor incluye criterios como la simplicidad y la instrumentación. La transición del producto incluye los siguientes factores de calidad: Portabilidad: Esfuerzo requerido para transferir entre distintos ambientes de operación. Contiene criterios como la auto-descripción, modularidad, independencia de la máquina y del sistema operativo. Reusabilidad: Facilidad de reusar el software en diferentes contextos, este factor contiene los mismos criterios de la portabilidad. Interoperabilidad: Esfuerzo requerido para acoplar el producto con otros sistemas. Sus criterios son la modularidad, la interoperabilidad en comunicación y en los datos. La operación del producto incluye los siguientes factores: Correctitud: Grado en el que el producto cumple con su especificación. Cuenta con criterios como la trazabilidad, completitud y la consistencia. Confiabilidad: Habilidad del producto de responder ante situaciones no esperadas. Contiene criterios como la tolerancia a errores, la consistencia, simplicidad y exactitud. Eficiencia: Uso de los recursos tales como tiempo de ejecución y memoria de ejecución. Sus criterios son la eficiencia en tiempo y espacio. Integridad: Protección del programa y sus datos de accesos no autorizados. Cuenta con criterios de control de acceso y auditoria de acceso. Usabilidad: Facilidad de operación del producto por parte de los usuarios. Contiene criterios como la operabilidad, entrenamiento, comunicación, volumen de E/S y tasa de E/S. 7.2. MODELO DE BOEHM Es el segundo modelo de calidad más conocido, fue presentado por Barry Boehm en 1978, este modelo introduce características de alto nivel, características de nivel intermedio y características de bajo nivel, ver Figura 2, cada una de las cuales contribuye al nivel general de calidad. Utilidad Mantenibilidad Utilidad general Alto nivel Modelo de Boehm Nivel intermedio Bajo nivel / Portabilidad, } Confiabilidad, Eficiencia, Usabilidad, Testeabilidad, Facilidad de entendimiento, flexibilidad Independencia, Autocontención, Auto-contención Exactitud, Completitud, Consistencia, Robustez/integridad, Accesibilidad, Eficiencia, Comunicación, Auto descripción, Estructuración, Legibilidad, Aumentabilidad Figura2. Estructura modelo de Boehm Las características de alto nivel representan requerimientos generales de uso, los cuales pueden ser: Utilidad per-se: cuan (usable, confiable, eficiente) es el producto en sí mismo. Mantenibilidad: cuan fácil es modificarlo, entenderlo y retestearlo. Utilidad general: si puede seguir usándose si se cambia el ambiente. Las características de nivel intermedio representan los factores de calidad de Boehm: Portabilidad (utilidad general) Confiabilidad (utilidad per-se) Eficiencia (utilidad per-se) Usabilidad (utilidad per-se) Testeabilidad (mantenibilidad) Facilidad de entendimiento (mantenibilidad) Modificabilidad o flexibilidad (mantenibilidad) El nivel más bajo corresponde a características directamente asociadas a una o dos métricas de calidad. De portabilidad: Independencia de dispositivos Auto-contención De confiabilidad: Auto-contención Exactitud Completitud Consistencia Robustez/integridad De eficiencia Accesibilidad Eficiencia de uso de dispositivos De usabilidad Robustez/integridad Accesibilidad Comunicación De testeabilidad Comunicación Auto descripción Estructuración De entendibilidad Consistencia Estructuración Concisidad Legibilidad De modificabilidad Estructuración Aumentabilidad 8. ELEMENTOS DE UN PROYECTO DE DESARROLLO DE SOFTWARE Programas: que cuando se ejecutan realizan una o varias funciones con el rendimiento esperado. Documentación: que describe el funcionamiento, la estructura, operación y uso de los programas. Estructura de datos: que permiten que los programas manipulen adecuadamente la información. Personas: las encargadas de ejecutar y desarrollar cada una de las etapas del proyecto de software. Tiempo: encargado de delimitar los lapsos de cada uno de las etapas del ciclo de vida, tareas y la totalidad del proyecto. Dinero: el cual proveerá para cada uno de los gastos de las personas, y cubrirá los riesgos a lo largo de cada etapa del proyecto. 9. CONCLUSIONES - Para entender mejor la ingeniería de software primero es necesario analizar cada parte de lo que se quiere llevar a cabo y las razones de porque la calidad interviene en la cuantificación del proyecto, el desarrollo de la aplicación y el manteniendo de un software. - La calidad de un producto ya no está centrada solo en la satisfacción del cliente, la evolución de la calidad ahora nos permite y exige tener un producto de calidad debido a un proceso y una gestión que es necesario llevar a cabo. La calidad debe estar implícita en cada área y proceso de la empresa y no así solo en el producto final. - Para lograr que las empresas produzcan productos de calidad deben regirse a normas y estándares a nivel mundial, para ello hay organizaciones dedicadas a elaborar modelos y parámetros que permiten lograr una mayor calidad para la empresa. Una de ellas son las normas ISO, reconocidas internacionalmente y están siempre en un proceso de mejora continua para garantizar que las empresas certificadas por dichas normas ofrezcan al usuario final un producto o servicio de calidad. 10. BIBLIOGRAFIA http://www.cc.uah.es/drg/b/HispaSWEBOK.Borrador.pdf http://www.etsisi.upm.es/estudios/grados/software/objetivos http://ingenieriasoftbejarano.blogspot.com.co/2012/10/caracteristicas-y-tiposde-software.html https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software#Historia http://arantxa.ii.uam.es/~proyectos/teoria/C5_Proyectos%20de%20desarrollo %20software.pdf http://vanevargas.jimdo.com/m%C3%B3dulos/modelos/modelo-de-mccall/ http://www.cs.uns.edu.ar/~prf/teaching/SQ07/clase6.pdf http://image.slidesharecdn.com/iso15504web-101229173148phpapp01/95/isoiec-15504-introduccin-a-la-norma-de-evaluacin-de-procesosde-software-13-728.jpg?cb=1293643937 https://es.wikipedia.org/wiki/Modelo_de_evaluaci %C3%B3n_de_procesos_software_ISO_15504_SPICE https://prezi.com/jiybg8h9q3mx/estandares-ansiieee-730-1984-y-983-1986/ http://www.radikewl.com/5055484.html http://www.ati.es/gt/calidad-sftware/presentacion.htm http://www.ceisufro.cl/investigacion/lineas-de-investigacion/ http://www.ecured.cu/ISO_15504 http://www.iso15504.es/ http://juanmarcosteoria2.blogspot.com.co/2008/01/normas-iso-12207.html http://es.slideshare.net/oprbguitar/norma-tecnica-peruana-iso-12207 http://unfviso12207.webcindario.com/index.php?mod=proceso_organizativos http://es.ccm.net/contents/223-ciclo-de-vida-del-software http://html.rincondelvago.com/el-ciclo-de-vida-del-software.html http://www.ecured.cu/Modelo_Espiral http://ingenieraupoliana.blogspot.com.co/2010/10/modelo-de-desarrolloconcurrente.html http://tema3isoftware.blogspot.com.co/p/modelos-de-desarrollo-tecnicas-y.html https://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologiascrum.html https://procesosdesoftware.wikispaces.com/METODOLOGIA+RUP http://e.exam-10.com/doc/10444/index.html?page=7 http://ingenieriadesoftware.mex.tl/63758_AUP.html http://www.monografias.com/trabajos6/sista/sista.shtml http://www.desarrolloweb.com/articulos/artefactos-scrum.html http://www.ecured.cu/Programaci%C3%B3n_Extrema_(XP) http://es.slideshare.net/joseluisdifu/proceso-unificado-gil-aup-17171038 https://prezi.com/24dgrrbjbn91/norma-iso-12207/ https://prezi.com/8ohm8mnwrujq/norma-internacional-iso-iec-122072008/ http://www.monografias.com/trabajos99/articulo-ntp-iso-iec-12207/articulo-ntpiso-iec-12207.shtml http://tecnomaestros.awardspace.com/estandares_iso.php http://seispice.blogspot.com.co/2012/05/spiceiso-iec-15504-norma-spiceisoiec.html http://www.redalyc.org/articulo.oa?id=92217153012 http://geekswithblogs.net/dthakur/archive/2004/09/02/10570.aspx http://ieee730.blogspot.com.co/ https://standards.ieee.org/findstds/standard/730-2014.html https://prezi.com/jiybg8h9q3mx/estandares-ansiieee-730-1984-y-983-1986/ http://es.slideshare.net/Juan_Tapias/formato-ieee830srs-lleno http://www.academia.edu/6647065/Especificaci %C3%B3n_de_Requisitos_Software_seg%C3%BAn_el_est %C3%A1ndar_de_IEEE_830 http://es.slideshare.net/mrcordova/ciclo-de-vida-del-software-ieee12207-2011 http://pfsanchez.blogspot.com.co/2007/01/ingeniera-de-software-estndaresdel.html http://ocw.uc3m.es/ingenieria-telematica/software-decomunicaciones/transparencias/introduccion-a-la-ingenieria-del-software http://www.monografias.com/trabajos5/inso/inso.shtml http://es.slideshare.net/soreygarcia/introduccin-a-la-ingenieria-de-software14023309 http://www.siigroup.es/pfw_files/cma/Website/Site_ESP/nuestra_actividad/sprint .png http://humanos.uci.cu/wp-content/uploads/2010/03/RUP.png http://www.opentrends.net/image/image_gallery?uuid=6eeb5c22-26ef-4a1e9f41-299ab942e964&groupId=10156&t=1361534289835 https://lh4.googleusercontent.com/aNCCbl6q23ANOXaakUSLVS9GLperwEuRe glpkVw23-GijbUaw9EY9l89IuwoG4jloIKRJUJ9ZFghEg95ed41oCQkB3h51eHhw2e-0LURqy9_g_dtjKzqJ3c https://www.youtube.com/watch?v=8iL-U1ONFJ8 https://www.youtube.com/watch?v=rwTrlieEcuQ
Report "Trabajo Investigativo 01 - Ingenieria de Software"