miércoles, 11 de julio de 2012

unidad 3

Unidad 03: Gestión de proyectos de Software 3.01 Gestión de proyectos La gestión de proyectos también conocida como gerencia o administración de proyectos es la disciplina que guía e integra los procesos de planificar, captar, dinamizar y organizar talentos y administrar recursos, con el fin de culminar todo el trabajo requerido para desarrollar todo el proyecto y cumplir con el alcance, dentro de límites de tiempo, y costo definidos: sin stress y con buen clima interpersonal. Todo lo cual requiere liderar los talentos, y evaluar y regular continuamente las acciones necesarias y suficientes. Un proyecto es un esfuerzo temporal, único y progresivo, emprendido para crear un producto -bien o servicio- también único -o una serie de ellos- con objetivos y metas también pre-definidos. Otras denominaciones equivalentes según los países: gerencia o gestión de proyectos, gestión integral de proyectos, dirección integrada de proyectos (España), etc. Es una disciplina de gerencia y no una herramienta ingenieril, confusión derivada a su intenso uso en proyectos civiles. Las características o atributos comunes a la mayoría de los proyectos == ojo, incluso -por supesto- de prestación de servicios. · Objetivos y metas (el proyecto debe ser o hacerse viable, sustentable y medible, con talentos y recursos asignados, sin stress y con buen clima laboral y contractual) · Calendario de actividades (debe tener un programa detallado de actividades en función del tiempo -o plan de trabajo- cónsono con alcance, metas, talentos y recursos...) · Complejidad manejable (hace sencillo lo complejo, inter relacionando con visión de totalidad los múltiples elementos componentes y las inter relaciones entre ellos) · Administra recursos (especifica y logra disponibilidad de talentos (conocimientos y competencias), capital y esfuerzo humano de diversas áreas de la organización, comunidad, etc.) · Organización matricial (define estructura, sistemas, valores, simbolos, personas y talentos, asigna responsabilidades y recursos: talentos y logros vs. compensaciones fijas y variables; x ej. consultor, coach, facilitador, ejecutor, diseñador, gerente, patrocinador, cliente interno, etc.) · Sistema de comunicación y control (sistema manual o automatizado de registro y difusión de documentación e información sobre marcha del proyecto, precisando desviaciones y correctivos) 3.02 Métricas de proceso y proyecto de Software En la actualidad existe una cierta unanimidad en que el atributo que contribuye, fundamentalmente, a determinar la posición de la empresa en el largo plazo es la opinión de los clientes sobre el producto o servicio que reciben. Resulta obvio que, para que los clientes se formen una opinión positiva, la empresa debe satisfacer sobradamente todas sus necesidades y expectativas. Es lo que se ha dado en llamar calidad del servicio. Por tanto, si satisfacer las expectativas del cliente es tan importante como se ha dicho, entonces es necesario disponer de información adecuada sobre los clientes que contenga aspectos relacionados con sus necesidades, con los atributos en los que se fijan para determinar el nivel de calidad conseguido. La calidad, y más concretamente la calidad del servicio, se está convirtiendo en nuestros días en un requisito imprescindible para competir en las organizaciones industriales y comerciales de todo el mundo, ya que las implicaciones que tiene en la cuenta de resultados, tanto en el corto como en el largo plazo, son muy positivas para las empresas envueltas en este tipo de procesos. De esta forma, la calidad del servicio se convierte en un elemento estratégico que confiere una ventaja diferenciadora y perdurable en el tiempo a aquellas que tratan de alcanzarla. Eficacia en la eliminación de defectos. La eficacia de eliminación de defectos (EDD) es una medida de habilidad de filtrara de las actividades de la garantía de la calidad de control m al aplicarse a todas las actividades del marco de trabajo del proceso. 3.03 Estimación para proyectos de Software La gestión de todo proyecto de software siempre comienza con la planificación del proyecto y sus actividades. Antes de que se empiece con el proyecto, el gestor y su equipo deben hacer una estimación del proyecto, es decir, el trabajo, el esfuerzo, los recursos hardware y software que se necesitarán, el costo y el tiempo necesario para culminar el proyecto. En la planificación del proyecto se determinará tareas y tiempos que se deben cumplir, así como también, los responsables de que se cumplan. La estimación del proyecto determinará casi con exactitud el verdadero costo y el esfuerzo persona-mes que se necesita en el desarrollo de un proyecto. El objetivo principal de la planificación de todo proyecto de software es proporcionar un conjunto de actividades que les permita a los gestores de proyecto, estimar los recursos que se necesitan, costos, y tareas definidas. El equipo de software se debe adaptar al plan y a cada una de las tareas que se han definido. El plan debe irse actualizando conforme avanza el proyecto y se cumplan las actividades. El ámbito del software describe las funcionalidades y características del software que se entregaran a los usuarios finales (stakeholders), la información de entrada y salida, la documentación que se presenta a los usuarios como consecuencia de utilizar el software, así como también el desempeño y las restricciones del software. El ámbito del software se lo puede definir usando algunas de las siguientes técnicas: Después de una comunicación con todos los participantes se desarrolla una descripción narrativa del ámbito del software. Los usuarios finales desarrollan un conjunto de casos de uso. Cada una de las funciones del ámbito deben ser evaluadas y si es necesario redefinidas antes de comenzar con la estimación del proyecto. A partir de la definición del ámbito, el gestor del proyecto y su equipo deben decir si es posible o no construir el software de acuerdo a las especificaciones realizadas. La estimación de los recursos es necesaria para poder determinar el esfuerzo de desarrollo del software. Existen tres categorías de los recursos de ingeniería del software: personal, componentes de software reutilizables y el entorno de desarrollo. Los recursos humanos (personal), son seleccionados según la evaluación del ámbito del software y las habilidades que tengan para ser partícipes del desarrollo del software. El número de personas que se necesitan para un proyecto de software se lo puede determinar después de haber hecho la estimación del esfuerzo de desarrollo. La reutilización de los recursos de software es importante en un software basado en componentes. Estos recursos son importantes a la hora de minimizar costos y tiempo de desarrollo. Muchas de las veces la reutilización de estos componentes es obviada en la planificación del software. El entorno que soporta un proyecto de software incorpora hardware y software. El hardware proporciona una plataforma para soportar las herramientas software utilizadas para desarrollar los productos de trabajo. La estimación de los proyecto software puede hacer la diferencia entre el beneficio o la perdida para el desarrollador. Lograr una adecuada estimación del proyecto, de estimaciones de costos y esfuerzo confiables, tiene algunas opciones como: · Demorar la estimación hasta más tarde en el proyecto. · Basar las estimaciones en proyectos similares que ya hayan sido completados. · Emplear técnicas de descomposición relativamente simples para generar estimaciones de costo y esfuerzo del proyecto. · Utilizar uno o más modelos empíricos en la estimación de costo y esfuerzo. La estimación del proyecto de software es una forma de resolver problemas, pero en muchas ocasiones el problema es demasiado complejo por lo que es necesario descomponerlo en problemas más pequeños. El tamaño del software representa un desafío para el panificador del proyecto. El tamaño se refiere a un resultado cuantificable del proyecto de software. El tamaño se puede medir en líneas de código (LDC) o como puntos de función (PF). 3.04 Calendarización de proyectos de Software El reciente aumento de aplicaciones en donde se utiliza la computadora ha sido posible debido a un hardware de bajo costo, por lo cual la demanda de software ha crecido de forma exponencial. Esto implica que son necesarias técnicas y tecnología eficientes de Ingeniería de Software para resolver los múltiples problemas que se derivan de las aplicaciones en donde se desarrollan sistemas de software de gran tamaño. No es posible presentar una solución global o precisa a todos los problemas de la Ingeniería de software o presentar una solución única para resolver los problemas de la Ingeniería de Software. Cada proyecto de software presenta distintos problemas en su desarrollo, los cuales involucran personas, equipo, usuarios del software y ambiente de la aplicación. Calendarización Es una actividad que distribuye estimaciones de esfuerzo a través de la duración planificada del proyecto, al asignar el esfuerzo a tareas específicas de ingeniería del software. Principios Básicos · Compartimentación. · Interdependencia. · Asignación de tiempo. · Validación del esfuerzo. · Definición de responsabilidades. · Definición de resultados. · Definición de hitos. ¿Por qué las cosas van mal? La mayoría de los proyectos de software fracasan por falta de tiempo de calendario que por otras causas combinadas ¿Por qué esta causa de desastre es tan común? 1.- Las técnicas de estimación son pobremente desarrolladas. Reflejan suposiciones falsas, por ejemplo, que todo irá bien. 2.- Se confunde esfuerzo con progreso, suponiendo que hombres y meses son intercambiables. 3.- El progreso de la Calendarización es pobremente monitoreado. 4.- Cuando un resbalón en la Calendarización es reconocido, la respuesta tradicional es añadir mano de obra. Esto es similar a apagar un fuego con gasolina. Otros aspectos que se considerarán son: Optimismo. Los programadores son optimistas, tal vez porque la mayoría son jóvenes o por la juventud de la programación. Se supone en principio, que todo irá bien. El medio de la programación, cosas mentales, a diferencia de otras disciplinas, es muy tratable, de tal forma que se esperan pocas dificultades en la implementación. El Hombre-Mes El costo varía como el producto del número de hombres y el número de meses. El progreso no. De aquí que el hombre-mes como una unidad para medir el tamaño de un trabajo es un mito peligroso y engañoso. Esto implica que hombres y meses no son intercambiables. Hombres y meses son activos intercambiables sólo cuando una tarea puede partirse entre muchos trabajadores sin ninguna comunicación entre ellos. Prueba del Sistema (Test) Ninguna parte de la calendarización es tan ampliamente afectada por las restricciones secuenciales como el componente de depuración y prueba. Debido al optimismo se esperaría que el número de bugs sea más pequeño de lo que es. Estimación Cobarde Para el programador, la urgencia del patrón puede gobernar la conclusión calendarizada de la tarea, pero no gobernar la conclusión real. Cuando una comida no está lista en un cierto tiempo, el cliente tiene dos caminos, o espera o la come cruda. El cliente del software tiene opciones equivalentes. Una calendarización falsa para satisfacer los deseos del patrón es más común en esta disciplina que en alguna otra parte de la ingeniería. Es difícil hacer una defensa fuerte de la estimación de tiempos que es derivada de métodos no cuantitativos, soportada porpocos datos, y certificada principalmente por las corazonadas de los directivos. Es necesario desarrollar y publicar cifras de productividad, cifras de incidencias de bugs, reglas de estimación y así sucesivamente. Y publicarlas en beneficio de la profesión. Simplificando todo lo anterior, se enuncia la Ley deBrooke: Añadir mano de obra a un proyecto de software atrasado lo hace peor. Esto desmitifica el hombre-mes. El número de meses de un proyecto depende sus restricción es secuenciales. El máximo número de hombres depende del número de sub tareas independientes. De esas dos cantidades se pueden derivar calendarios usando menos hombres y más meses. No se pueden calendarios efectivos usando más hombres y menos meses. La mayor parte de proyectos de software han fracasado por falta de tiempo de calendario que por otras causas combinadas. 3.05 Gestión de riesgo La Gestión de riesgos: es un enfoque estructurado para manejar la incertidumbre relativa a una amenaza, a través de una secuencia de actividades humanas que incluyen evaluación de riesgo, estrategias de desarrollo para manejarlo y mitigación del riesgo utilizando recursos gerenciales. Las estrategias incluyen transferir el riesgo a otra parte, evadir el riesgo, reducir los efectos negativos del riesgo y aceptar algunas o todas las consecuencias de un riesgo particular. Algunas veces, el manejo de riesgos se centra en la contención de riesgo por causas físicas o legales (por ejemplo, desastres naturales o incendios, accidentes, muerte o demandas). Por otra parte, la gestión de riesgo financiero se enfoca en los riesgos que pueden ser manejados usando instrumentos financieros y comerciales. El objetivo de la gestión de riesgos es reducir diferentes riesgos relativos a un ámbito preseleccionado a un nivel aceptado por la sociedad. Puede referirse a numerosos tipos de amenazas causadas por el medio ambiente, la tecnología, los seres humanos, las organizaciones y la política. Por otro lado, involucra todos los recursos disponibles por los seres humanos o, en particular, por una entidad de manejo de riesgos (persona, staff, organización). Así, la administración de riesgo empresarial es un proceso realizado por el consejo directivo de una entidad, la administración y el personal de dicha entidad. Es aplicado en el establecimiento de estrategias de toda la empresa, diseñada para identificar eventos potenciales que puedan afectar a la entidad y administrar los riesgos para proporcionar una seguridad e integridad razonable referente al logro de objetivos. 3.06 Gestión de calidad "Aspectos de la función de gestión que determinan y aplican la política de la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la planificación de la calidad, el control de la calidad, la garantía de calidad y la mejora de la calidad". Dentro de la gestión de la calidad se observa: Gestión de la calidad de software (ISO 9000): Conjunto de actividades de la función general de la dirección que determina la calidad, los objetivos y las responsabilidades y se implanta por medios tales como la planificación de la calidad, el control de la calidad, el aseguramiento (garantía) de la calidad y la mejora de la calidad, en el marco del sistema de calidad. Política de calidad (ISO 9000): Directrices y objetivos generales de una organización, relativos a la calidad, tal como se expresan formalmente por la alta dirección. La gestión de la calidad se aplica normalmente a nivel de empresa. También puede haber una gestión de calidad dentro de la gestión de cada proyecto. El aseguramiento de la calidad Ante todo se debe conocer: Aseguramiento de la calidad: "Conjunto de acciones planificadas y sistemáticas necesarias para proporcionar la confianza adecuada de que un producto o servicio satisfará los requerimientos dados sobre calidad". Aseguramiento de la calidad de software: Conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto (software) satisfará los requisitos dados de calidad. El aseguramiento de calidad del software se diseña para cada aplicación antes de comenzar a desarrollarla. Hay quienes prefieren decir garantía de calidad en vez de aseguramiento. La garantía, puede confundir con garantía de productos, mientras que el aseguramiento pretende dar confianza en que el producto tiene calidad. El aseguramiento de calidad del software está presente en: · Métodos y herramientas de análisis, diseño, programación y prueba. · Inspecciones técnicas formales en todos los pasos del proceso de desarrollo del software. · Estrategias de prueba multiescala. · Control de la documentación del software y de los cambios realizados. · Procedimientos para ajustarse a los estándares (y dejar claro cuando se está fuera de ellos). · Mecanismos de medida (métricas). · Registro de auditorias y realización de informes. Las actividades para el aseguramiento de calidad del software se detallan en: · Métricas de software para el control del proyecto. · Verificación y validación del software a lo largo del ciclo de vida (Incluye las pruebas y los procesos de revisión e inspección). · La gestión de la configuración del software. Algunos métodos del aseguramiento: · Revisiones técnicas y de gestión (su objetivo es la evaluación). · Inspección (su objetivo es la verificación). ¿Estamos construyendo el producto correcto?. · Pruebas (su objetivo es la validación). ¿Estamos construyendo el producto correctamente?. · Auditorias (su objetivo es la confirmación del cumplimiento). El control de la calidad Se debe conocer: · Control de calidad: "Conjunto de técnicas y actividades de carácter operativo, utilizadas para verificar los requerimientos relativos a la calidad del producto o servicio". · Control de la calidad del software: Técnicas y actividades de carácter operativo, utilizadas para verificar los requisitos relativos a la calidad, centradas en mantener bajo control el proceso de desarrollo y eliminar las causas de los defectos en las diferentes fases del ciclo de vida. El control de la calidad del software está centrado en dos objetivos fundamentales: · Mantener bajo control un proceso. · Eliminar las causas de los defectos en las diferentes fases del ciclo de vida. · En general, se puede decir que el control de de la calidad del software son las actividades para evaluar la calidad de los productos desarrollados. Las estrategias de trabajo se representan como sigue: Descripción: http://www.monografias.com/trabajos59/calidad-software/Image2.gif Sistema de calidad Estructura organizativa, procedimientos, procesos y recursos necesarios para implantar la gestión de calidad. El sistema de calidad se debe adecuar a los objetivos de la calidad de la empresa. La dirección de la empresa es la responsable de fijar la política de calidad y las decisiones relativas a iniciar, desarrollar, implantar y actualizar el sistema de calidad. Un sistema de calidad consta de varias partes: Documentación · Manual de calidad. Es el documento principal para establecer e implantar un sistema de calidad. · Puede haber manuales a nivel de empresa, departamento, producto, específicos (compras, proyectos). Parte física: locales, herramientas ordenadores, etc. Aspectos humanos: · Formación de personal. · Creación y coordinación de equipos de trabajo. Normativas: · ISO 3.07 Gestión de cambio La Gestión del Cambio es llamada usualmente Gestión de la Configuración del Software (GCS o GC). Se debe de tener muy claro lo que es Soporte y Gestión de la Configuración. Soporte: Conjunto de actividades de ingeniería del software que ocurren después de que éste se ha entregado al cliente y ha sido puesto en operación. Gestión de la configuración del software: Conjunto de actividades de seguimiento y control que se inician cuando empieza un proyecto de ingeniería del software y terminan sólo cuando éste se retira de operación. GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE La Gestión de la Configuración del Software es un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida. La GCS es una actividad de garantía de calidad de software que se aplica en todas las fases del proceso de ingeniería del software. El resultado del proceso de ingeniería del software es una información que se puede dividir en tres amplias categorías: 1. Programas de computadora (tanto en forma de código fuente como ejecutable) 2. Documentos que describen los programas (manuales tanto técnicos como de usuario) 3. Estructuras de datos (contenidas en el programa o externas a él) Estos resultados son elementos que se denominan colectivamente configuración del software. Origen de los cambios. Nuevas condiciones en el negocio o mercado (cambios en los requisitos del producto o reglas del negocio) · Nuevas necesidades del cliente (modificación de los datos que producen los sistemas, funcionalidad que entregan los productos o los servicios) · La reorganización o el crecimiento o reducción del negocio (cambios en las prioridades del proyecto o estructura del equipo de ingeniería del software) · Restricciones presupuestales o de calendarización (redefinición del sistema o producto) Unidad 04: Temas avanzados de Ingeniería del software 1.01 Métodos formales En ingeniería de software un método formal es un camino a la construcción y análisis de modelos matemáticos que permitan una automatización del desarrollo de sistemas informáticos. Los métodos formales se caracterizan por emplear técnicas y herramientas matemáticas para lograr una facilitación a la hora de encarar la construcción o el análisis de un modelo matemático de un sistema. Los métodos formales permiten al ingeniero del software crear una especificación sin ambigüedades que sea más completa y constante que las que se utilizan en los métodos convencionales u orientados a objetos. La teoría de conjuntos y las notaciones lógicas se utilizan para crear una sentencia clara de hechos (o de requisitos). Esta especificación matemática entonces se puede analizar para comprobar que sea correcta y constante. Como esta especificación se crea utilizando notaciones matemáticas inherentemente es menos ambigua que los nodos informales de presentación. Ventajas · Se comprende mejor el sistema. · La comunicación con el cliente mejora ya que se dispone de una descripción clara y no ambigua de los requisitos del usuario. · El sistema se describe de manera más precisa. · El sistema se asegura matemáticamente que es correcto según las especificaciones. · Mayor calidad software respecto al cumplimiento de las especificaciones. · Mayor productividad Desventajas · El desarrollo de herramientas que apoyen la aplicación de métodos formales es complicado y los programas resultantes son incómodos para los usuarios. · Los investigadores por lo general no conocen la realidad industrial. · Es escasa la colaboración entre la industria y el mundo académico, que en ocasiones se muestra demasiado dogmático. · Se considera que la aplicación de métodos formales encarece los productos y ralentiza su desarrollo. Métodos de Verificación Entre los métodos de verificación más utilizados, se encuentran: Aserciones E/S Precondición más débil Aserciones E/S Basado en la lógica de Hoare. El programa, en lógica de Hoare, se especifica mediante aserciones que relacionan las entradas y salidas del programa. Se garantiza que si la entrada actual satisface las restricciones de entrada (precondiciones) la salida satisface las restricciones de salida (poscondiciones). Se utiliza una expresión del tipo P{programa}Q, siendo P y Q aserciones de la lógica, para indicar que si P es cierto antes de la ejecución del programa y dicho programa termina, entonces Q es cierto tras la ejecución de dicho programa. Este método permite tanto la corrección parcial como total de los programas.: · Es cierto a la entrada del bucle · Es cierto en cualquier paso del bucle · Junto con la negación de la condición del bucle, implica que el predicado se cumple a la salida del bucle. Precondición más débil Básicamente, consiste en dar una pos condición POST y encontrar operando hacia atrás, un programa S tal que wp(S, POST) (la precondición) se satisfaga en un amplio conjunto de situaciones. Dada una proposición (P) S (Q) donde S es un conjunto de sentencias de un módulo de un programa, y donde P y Q son los predicados que se cumplen antes y después de S respectivamente, se dice que P es la precondición más débil (wp) de S, si es la condición mínima que garantiza que R es cierto tras la ejecución de S. 4.02 Ingeniería del Software de sala limpia La ingeniería del software de sala limpia es un enfoque formal para el desarrollo del software, que pueda dar lugar a un software con una calidad notablemente alta. Emplea la especificación de estructura de cajas para el modelado de análisis y diseño, haciendo hincapié en la verificación de la corrección, más que en la comprobación, como mecanismo fundamental para encontrar y eliminar errores. Se aplica una comprobación estadística de uso para desarrollar la información relativa a la tasa de fallos necesaria para certificar la fiabilidad del producto software. La filosofía de sala limpia es un enfoque riguroso de la ingeniería del software. Se trata de un modelo de proceso del software que hace hincapié en la verificación matemática de la corrección, y en la certificación de la fiabilidad del software. El resultado final es una tasa de fallo extremadamente baja, que sería difícil o imposible de conseguir empleando métodos menos formales. La sucesión de tareas de sala limpia para cada incremento, se manifiesta mediante los requerimientos globales del producto que se van desarrollando empleando los métodos de la ingeniería de sistemas. Una vez asignada la funcionalidad al elemento de software del sistema, el tubo de la sala limpia comienza sus incrementos y se producen las siguientes tareas: 1 Planificación de incrementos. La planificación incremental permite calidad temprana y continua interacción con el usuario. Facilita mejoras de proceso mientras progresa el desarrollo. El acercamiento incremental evita los riesgos inherentes a la integración tardía en el ciclo de desarrollo. 1 Recolección de requisitos. El propósito del proceso del análisis de requerimientos consiste, por una parte, en definir requisitos para el producto software, incluyendo función, uso, ambiente, y funcionamiento; la parte complementara constituye el obtener un acuerdo con el cliente en los requisitos como base para la función y especificación de uso. 2 Especificación de la estructura de cajas. Tres tipos especiales de funciones matemáticas son importantes en el desarrollo de sala limpia, debido a su correspondencia y correlación en el proceso de descomposición y verificación. Estas funciones son conocidas como la caja negra, la caja de estado y caja limpia. En la estructura de las cajas se pueden aplicar una variedad de estrategias de descomposición, además se puede incluir funcionalidad y orientación a objeto. 3 Diseño formal. Mediante el uso del enfoque de estructura de cajas, el diseño de sala limpia es una extensión natural y sin discontinuidades de la especificación. Los participantes proporcionan los objetivos, los criterios de entrada, las tareas, la verificación, las medidas y los criterios comunes de la salida en los procesos, así como elementos de proceso común. 4 Verificación de corrección. El equipo de sala limpia lleva a cabo una serie de rigurosas actividades de verificación de corrección, las cuales se aplican primero al diseño y después al código. El propósito del proceso de verificación de la corrección, es verificar la corrección del incremento asociado al producto software utilizando técnicas matemáticas. 5 Generación de código, inspección y verificación. Las especificaciones de estructura de caja que se representan mediante un lenguaje especializado se traducen en un lenguaje de programación adecuado. 6 Planificación de la comprobación estadística. Se refiere a la comprobación estadística de uso y certificación. El propósito del proceso estadístico de uso y certificación es demostrar la aptitud del software para el uso en un experimento estadístico formal. La “aptitud para el uso” se define con respecto a los modelos de uso y a las metas de la certificación empleados en el proceso de prueba. Las metas de certificación, primero establecidas en el plan de medida y refinadas en el plan de prueba de incremento, se pueden expresar en términos tales como el índice de confiabilidad del software. Una caja encapsula el sistema con un cierto grado de detalle. Mediante un proceso de refinamiento progresivo, se van refinando las cajas para formar una jerarquía en la cual cada caja tiene una transferencia. Para esto, al interior de la ingeniería del software de sala limpia, se utilizan tres tipos de cajas: Caja negra. Especifica el comportamiento del sistema, o de una parte de un sistema. Caja de estado. Esta caja encapsula los datos de estados y de servicios de forma análoga a los objetos. En esta vista de especificación, se representan las entradas a la caja de estados y sus salidas. Caja transparente. Las funciones de transición que están implicadas en la caja de estados se definen en la caja transparente. El diseño que se utiliza en la ingeniería del software de sala limpia hace mucho uso de la filosofía de programación estructurada. Esta filosofía contiene las funciones básicas de procesamiento, las que se refinan utilizando una expansión progresiva de funciones matemáticas en estructuras de conectivas lógicas. La técnica y estrategia de la comprobación de la sala limpia es fundamentalmente distinta de los enfoques convencionales de comprobación. 4.03 Ingeniería del Software basada en componentes El desarrollo de software basado en componentes permite reutilizar piezas de código preelaborado que permiten realizar diversas tareas, conllevando a diversos beneficios como las mejoras a la calidad, la reducción del ciclo de desarrollo y el mayor retorno sobre la inversión. Al comparar la evolución del ambiente de IT con el crecimiento de las metrópolis actuales, podemos entender el origen de muchos problemas que se han presentado históricamente en la construcción de software y vislumbrar las posibles y probables soluciones que nos llevarán hacia la industrialización del software moderno. Este proceso de industrialización ha dado ya sus inicios con implementaciones como la plataforma .net, la cual impulsa la idea de industrializar el software utilizando tecnologías de componentes. Los avances y mejoras presentados en esta plataforma van mucho más allá de las implementaciones iniciales como COM y CORBA, convirtiendo a los componentes .net en verdaderas piezas de ensamblaje, en un estilo muy similar a las líneas de ensamblaje modernas. Asimismo, los nuevos paradigmas como las Fábricas de Software proveen de los medios para hacer la transición desde el 'hacer a mano' hacia la fabricación o manufactura de software. Si hay algo que ha aprendido el ser humano desde tiempos muy antiguos es a reutilizar el conocimiento existente para sus cada vez más ambiciosas empresas. En efecto, al reutilizar trozos de experiencias, ideas y artefactos, no solo nos aseguramos de no cometer los mismos errores del pasado, sino que logramos construir cosas cada vez más grandes y maravillosas, con bases firmes y calidad incomparable. Este concepto de la reutilización, uno de los primeros que se nos enseñan a quienes entramos al mundo del desarrollo de software, habremos de utilizarlo desde el mismo instante en que escribamos nuestra primera línea de código. Los sistemas de hoy en día son cada vez más complejos, deben ser construidos en tiempo récord y deben cumplir con los estándares más altos de calidad. Para hacer frente a esto, se concibió y perfeccionó lo que hoy conocemos como Ingeniería de Software Basada en Componentes (ISBC), la cual se centra en el diseño y construcción de sistemas computacionales que utilizan componentes de software reutilizables. Esta ciencia trabaja bajo la filosofía de "comprar, no construir", una idea que ya es común en casi todas las industrias existentes, pero relativamente nueva en lo que a la construcción de software se refiere. Para este momento, ya muchos conocen las ventajas de este enfoque de desarrollo y, de la misma forma, muchos se preguntan día a día el por qué son tan pocos los que realmente alcanzan el éxito siguiendo esta filosofía. En realidad, hasta ahora solo hemos tanteado un poco con las posibilidades del software basado en componentes, y es justo hora, en la presente década, que la industria del software despegará y se perfeccionará para estar a la par de cualquier otra industria del medio. Las analogías que nos han llevado a estudiar a los sistemas comparándolos con las complejas metrópolis de la actualidad, así como las iniciativas más innovadoras como las Fábricas de Software de Microsoft, son la clara representación de que estamos a punto de presenciar un nuevo gran cambio en la forma como pensamos en software. 4.04 Reingeniería Reingeniería significa volver a empezar arrancando de nuevo; reingeniería no es hacer más con menos. Es rediseñar los procesos de manera que estos no estén fragmentados. Entonces la compañía se las podrá arreglar sin burocracias e ineficiencias. Las organizaciones que continuamente adaptan sus burocracias, estrategias, sistemas, productos y culturas alas sacudidas y fuerzas, diezmarán a los competidores. Tales organizaciones se adaptarán en las crisis que confunden a los demás en la industria, aumentan sus fortalezas al máximo y desarrollan otras nuevas al ocurriréste. Estas organizaciones son, o serán, maestros de la reingeniería organizacional, un enfoque que ayuda a una organización a adaptarse al cambio. Cuando triunfa el esfuerzo de reingeniería, las empresas cosechan grandes beneficios. DIAGNOSTICO PARA LA APLICACIÓN DE LA REINGENIERÍA. El objetivo de la reingeniería son los procesos y no las organizaciones. Las compañías rediseñan el trabajo querealiza las personas empleadas en esas dependencias, las unidades organizacionales provienen de departamentos, divisiones y además son visibles (organigramas) y tienen nombre, en cambio los proceses no. En una empresa los procesos responden a actividades naturales de negocios pero las estructuras organizacionales los fragmentan y los oscurecen, también carecen de dirección porque a una persona(encargada del departamento) no le asignan responsabilidades (proceso). PASOS PARA APLICAR LA REINGENIERÍA Una vez diagnosticado y seleccionado el proceso que tiene fallas, tomando en cuenta los aspectos anteriores, seguimos los siguientes pasos para aplicar la reingeniería en el proceso: Formulación de una estrategia: requisitos del mercado, identificando mercados a los cuales se sirven, productos y servicios que se ofrecen. Desarrollos de productos: es un insumo para producir nuevos diseños de productos. Desarrollo de capacidad de manufactura: Capacidad instalada en cuanto a recursos tecnológicos y humanos que se cuentan para el desarrollo del producto. Comunicación con el cliente: A través de estudios hacia nuestros clientes, por medio de encuestas, estudios de mercado, etc., se trata de detectar los requerimientos de los clientes y tratar de estar un paso delante de lo que estos, puedan necesitar. ROLES DE LA REINGENIERÍA Para llevar a cabo la reingeniería de procesos se han identificado los siguientes roles: · Líder. · Dueño o responsable del proceso. · Equipo de reingeniería. · Comité directivo. Es un alto ejecutivo que respalda, autoriza y motiva el esfuerzo total de reingeniería. Debe tener la autoridad suficiente para que persuada a la gente de aceptar los cambios radicales que implica la reingeniería. Debe mantener el objetivo final del proceso, necesita la visión para reinventar la empresa bajo nuevos esquemas competitivos, mantiene comunicados a empleados y directivos de los propósitos a lograr, así como los avances logrados. Designa a quienes serán los dueños de los procesos y asigna la responsabilidad de los avances en el rendimiento. ERRORES COMUNES EN LA REINGENIERÍA · Tratar de corregir un proceso en lugar de cambiarlo · No concentrarse en los procesos · No hacer caso de los valores y las creencias de los empleados · Conformarse con resultados de poca importancia · Limitar de ante mano la definición del problema y el alcance del esfuerzo de reingeniería · Dejar que las culturas y las actitudes corporativas existentes impidan que empiece la reingeniería · Tratar de que la reingeniería se haga de abajo para arriba · Confiar el liderazgo a una persona que no entiende de reingeniería · Escatimar los recursos destinados a la reingeniería 4.05 Importancia del Software Este término fue introducido a finales de los 60 a raíz de la crisis del software. Esta crisis fue el resultado de la introducción de la tercera generación del hardware. El hardware dejo de ser un impedimento para el desarrollo de la informática; redujo los costos y mejoro la calidad y eficiencia en el software producido La crisis se caracterizo por los siguientes problemas: · Imprecisión en la planificación del proyecto y estimación de los costos. · Baja calidad del software. · Dificultad de mantenimiento de programas con un diseño poco estructurado, etc. Por otra parte se exige que el software sea eficaz y barato tanto en el desarrollo como en la compra. También se requiere una serie de características como fiabilidad, facilidad de mantenimiento y de uso, eficiencia, etc. Descripción: images8.jpg Objetivos de la ingeniería de software En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver los problemas, la informática aporta herramientas y procedimientos sobre los que se apoya la ingeniería de software. · Mejorar la calidad de los productos de software · Aumentar la productividad y trabajo de los ingenieros del software. · Facilitar el control del proceso de desarrollo de software. · Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente. · Definir una disciplina que garantice la producción y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado. LA CALIDAD DE SOFTWARE Y SU IMPORTANCIA EN EL MERCADO Descripción: images4.jpg · La mala calidad de software desarrollado provoca: insatisfacción y desconfianza del cliente, además de baja en la demanda y utilidades. · En el mercado existen productos de toda calidad y precio. · La calidad de software puede medirse en base a ciertos atributos estándar. ¿Quién tiene que estar satisfecho con el software? Información general Producir software con calidad, a un costo razonable, produce beneficios tanto para los clientes como para los desarrolladores. Calidad. Medida de cierta característica deseable. Proceso de software. Conjunto de actividades, métodos, prácticas y transformaciones usados para desarrollar y mantener el software y productos asociados (planes, documentos, código, casos de prueba, manuales de usuario, recursos humanos). Atributos de calidad del software Los atributos de calidad son características que sirven para medir un software. · Funcionalidad. Capacidad de hacer lo requerido. · Usabilidad. Cuán fácil de aprender a manejarlo y operarlo. · Confiabilidad. Medida de confianza que se tiene al sistema. · Mantenibilidad. Cuán fácil es analizar y modificar el software. · Testabilidad. Cuán fácil es testear. · Portabilidad. Dependencia hardware, software, instalación, migración de datos. · Reusabilidad. Encapsulamiento, datos, componentes, interoperación. y parametrización. · Eficiencia. Uso de recursos, tiempo de respuesta. Usabilidad · Aprendizaje. Fácil de aprender a usar. · Transparencia. Fácil de entender, recordar cómo se usa. · Operabilidad. Fácil y eficiente de operar. · Sensibilidad. Ejecuta funciones de manera oportuna. · Personalizable. Fácil cambia apariencia. · Multilingüe. Varios idiomas. · Acceso a funciones directas. Comandos internos a accesos de funciones. · Teclas abreviadas. Para accesos directos por teclado. · Consistencia. Comandos consistentes con el entorno. Confiabilidad Caracteriza como el sistema responde ante fallas. Descripción: images11.jpg · Disponibilidad. Caídas del sistema, fallas de comunicación. · Tolerancia a fallas. Operación inadecuada, errores de programación, notificaciones y ayudas. · Madurez. Evolución del sistema. · Recuperabilidad. Bd (transacciones), reconfiguración. Proceso del SW Mediante la implantación de un proceso de sw se puede controlar sistemáticamente el desarrollo del sw. Descripción: images1.jpg · Uso de metodologías de trabajo (ej. XP) · Uso de herramientas (cvs, xunit, control de bugs) Ciclo de vida de una función: Aceptación Descripción: images10.jpg Software Evolutivo Descripción: images3.jpgLa evolución supone creatividad e innovación permanente. Lavacar 1.1 Lavacar 2.1 Lavacar 3.1 Lavacar 4.1 · Se añaden funciones sobre una “estructura” anterior · Se remueven funciones innecesarias · El SW evoluciona hasta alcanzar una madurez · El SW está vigente mientras cubra las expectativas del cliente · Eventualmente sale de circulación Modelo de Mercado Descripción: images6.jpg · Producir para mercado masivo = SW de uso general = bajar costo del SW. · Producir para segmentos de mercado = SW exclusivo para clientes exclusivos = tiene costos altos pero pueden bajarse mediante componentes, reutilización de código, parametrización, módulos, funciones y componentes. · Calidad de servicio. Resumen · Para producir SW con calidad debe definirse y usarse: un modelo de calidad, un modelo de proceso de SW, un modelo mercado.

No hay comentarios:

Publicar un comentario en la entrada