miércoles, 27 de octubre de 2010

Sala Limpia.

 La utilización integrada del modelado de ingeniería del software convencional, métodos formales, verificación de programas (demostraciones de corrección) y estadística SQA se han combinado en una técnica que puede dar lugar a un software de calidad extremadamente alta. La ingeniería del software de sala limpia es un enfoque que hace hincapié en la necesidad de incluir la corrección en el software a medida que éste se desarrolla. En lugar del ciclo clásico de análisis, diseño, pruebas y depuración, el enfoque de sala limpia sugiere un punto de vista distinto :

La filosofía que subyace tras la ingeniería del software de sala limpia consiste en evitar la dependencia de costosos procesos de eliminación de defectos, mediante la escritura de incrementos de código desde un primer momento, y mediante la verificación de su corrección antes de las pruebas.  Su modelo de proceso incluye la certificación estadística de calidad de los incrementos de código, a  medidad que estos se van añadiendo cn el sistema.

En muchos aspectos, el enfoque de sala limpia eleva la ingenicría del software a otro nivel. Al igual que las técnicas de métodos formales que se presentaban en el Capítulo 25, el proceso de sala limpia hace hincapié en el rigor en la especificación y en el diseño, y en la verificación formal de cada uno de los elementos del modelo de diseño Fesultante mediante el uso de pruebas de corrección basadas en fundamentos matemáticos. Al extender el enfoque adoptado en los métodos formales, el enfoque de sala limpia hace hincapié también en técnicas de control estadístico de calidad, incluyendo las comprobaciones basadas en el uso anticipado del software por parte de los clientes.

miércoles, 20 de octubre de 2010

Bibliografia

Ingenieria del Software : Un enfoque Practico. Quinta edicion.

Wikkipedia.

Monografias.com

Tabla de gestion del riesgo.


Riesgo
Probabilidad
Impacto
Estrategia de Recompensa.
Riesgo del Proyecto
Presupuesto
0.10
Ma
Sumar el 20% al costo real del software.
Planificación Temporal
0.08
Ma
Realizar un descuento del 5 % por cada mes de retraso.
Personal( Asignación y Organización)
0.02
De
Motivación, capacitación al personal.
Recursos
0.10
Ma
Optimizar los recursos.
Clientes y sus requisitos
0.18
Ma
Entablar una buena comunicación con el cliente.
Impacto
0.14
Ma
Crear una buena campaña publicitaria, promover en las diferentes empresas.
Riesgo Técnico.
Diseño
0.07
De
Crear un buen diseño llamativo y que cumpla con las necesidades del cliente.
Implementación
0.11
Ma
Brindar capacitación al usuario del software.
Interfaz
0.04
De
Atender las solicitudes del cliente.
Verificación
0.10
Ma
Establecer un periodo de prueba de un mes para realizar ciertas validaciones.
Mantenimiento
0.02
De
Fijar una fecha para dar mantenimiento al menos una vez al mes.
Riesgo del Negocio
Riesgo de Mercadeo.
0.24
Cr
Brindar un software de prueba para mostrar la funcionalidad y aceptación del mismo.
Riesgo Estratégico.
0.08
Ma
Realizar modificaciones requeridas por el cliente.
Riesgo de Mercadotecnia
0.19
Cr
Ofertar el software en los distintos medios de publicidad (Tv, radio, internet, etc.)
Riesgo de perder contacto con el personal del negocio.
0.20
Ma
Firmar contrato con representante jurídico del negocio.
Cierre del negocio.
0.34
Ca
Ofrecerlo a otras empresas y realizar modificaciones requeridas por el nuevo cliente.

jueves, 14 de octubre de 2010

Metricas del Sofware.


Metricas Orientadas al Tamaño.

Las métricas del software orientadas al tamaño provienen de la normalización de las medidas de calidad y/o productividad considerando el «tamaño» del software que se haya producido. Si una organización de software mantiene registros sencillos, se puede crear una tabla de datos orientados al tamaño. 

Para desarrollar métricas que se puedan comparar entre distintos proyectos, se seleccionan las líneas de código como valor de normalización. Con los rudimentarios datos contenidos en la tabla se pueden desarrollar para cada proyecto un conjunto de métricas simples orientadas al tamaño:  

errores por KLDC (miles de líneas de código) . 
defectos4 por KLDC. 
E por LDC. 
Páginas de documentación por KLDC.
Además, se pueden calcular otras métricas interesantes:

errores por persona-mes. 
LDC por persona-mes.
E por página de documentación.

 Ventajas 

Son fáciles de calcular.  
Muchos modelos de estimación de software usan LOC o KLOC como datos de entrada.  
Existen un amplio conjunto de datos y literatura basados en LOC. 

Desventajas 

Son dependientes del lenguaje de programación.  
Perjudica a los programas cortos pero bien diseñados.  
Su uso en estimación es díficil porque hay que estimar las LOC a producirse mucho antes de que se complete el análisis y el diseño.  

Métricas Orientadas a la Función.

Las métricas del software orientadas a la función utilizan una medida de la funcionalidad entregada por la aplicación como un valor de normalización. Ya que la «funcionalidad>>n o se puede medir directamente, se debe derivar indirectamente mediante otras medidas directas. Las métricas orientadas a la función fueron propuestas por primera vez por Albretch, quien sugirió una medida llamada punto defunción. Los puntos de función se derivan con una relación empírica según las medidas contables (directas) del dominio de información del software y las evaluaciones de la complejidad del software.

Una extensión del punto de función es la llamada puntos de características; es una ampliación de la medida del punto de función que se puede aplicar a sistemas y aplicaciones de ingeniería del software. La medida de punto de característica acomoda a aplicaciones en donde la complejidad del algoritmo es alta. Las aplicaciones de software de tiempo real, de control de procesos, y empotradas tienden a tener alta complejidad de algoritmos y por lo tanto son adecuadas para el punto de característica.

 Metricas Ampliadas al Punto de Función.


Métricas ampliadas de punto de función La medida de punto de función se diseñó originalmente para aplicarse a aplicaciones de sistemas de información de gestión. Para acomodar estas aplicaciones, se enfatizó la dimensión de datos (los valores de dominios
de información tratados anteriormente) para la exclusión de dimensiones (control) funcionales y de comportamiento. Por esta razón, la medida del punto de función era inadecuada para muchos sistemas de ingeniería y sistemas empotrados (que enfatizan función y control). Para remediar esta situación se ha propuesto un número de extensiones a la métrica del punto de función básica.

Una extensión del punto de función es la llamada puntos de características; es una ampliación de la medida del punto de función que se puede aplicar a sistemas y aplicaciones de ingeniería del software. La medida de punto de característica acomoda a aplicaciones
en donde la complejidad del algoritmo es alta. Las aplicaciones de software de tiempo real, de control de procesos, y empotradas tienden a tener alta complejidad de algoritmos y por lo tanto son adecuadas para el punto de característica.

Puntos de característica.
 
Se calcula igual que el punto de función y solo agrega la cuenta de algoritmos. En este contexto se define un algoritmo como un problema de cálculo limitado que se incluye dentro de un programa de computadora específico. Invertir una matriz, decodificar un string o manejar una interrupción son ejemplos de algoritmos.

  Metricas Orientadas a la Calidad del software y Organizaciones pequeñas.

Existen medidas de la calidad del software como: la corrección, la facilidad de mantenimiento, la integridad y la facilidad de uso ofrecen indicadores utilices para el equipo del proyecto, Gilb[GIL88] sugiere definiciones y mediciones para cada una de ellas: 

Corrección: es el grado en que el software desempeña la funcionara la que fue creado y se mide endefectos por KLOC. 

Facilidad de Mantenimiento: es la sencillez con que un programa puede corregirse si se encuentra un error; al adaptarse si su entorno cambia o mejorar si el cliente cambia los requisitos y se mide en forma indirecta en TMC (tiempo medio de cambio). 

Integridad: es la habilidad de un sistema para resistir ataques que requiere la definición de amenaza yseguridad y se calcula:
integridad = 1 – (amenaza x (1 - seguridad)).



Conceptos del Espectro de Gestion.

La gestión eficaz de un proyecto de software se centra en las cuatro P’s: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la evolución del proyecto se arriesga a construir una elegante solución para un problema equivocado. El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío. El gestor que emprende un proyecto sin un plan sólido arriesga el éxito del producto.
 

  Personal


La necesidad de contar con personal para el desarrollo del software altamente preparado y motivado se viene discutiendo desde los años 60.De hecho, el «factor humano» es tan importante que el Instituto de Ingeniería del Software ha desarrollado un Modelo de madurez de la capacidad de gestión de personal (MMCGP) «para aumentar la preparación de organizaciones del software para llevar a cabo las cada vez más complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de software.


El modelo de madurez de gestión de personal define las siguientes áreas clave prácticas para el personal que desarrolla software: reclutamiento, selección, gestión de rendimiento, entrenamiento, retribución, desarrollo de la carrera, diseño de la organización y del trabajo y desarrollo cultural y de espíritu de equipo.


El MMCGP es compañero del modelo de madurez de la capacidad software que guía a las organizaciones en la creación de un proceso de software maduro.


Producto


Antes de poder planificar un proyecto, se deberían establecer los objetivos y el ámbito del producto‘, se deberían considerar soluciones alternativas e identificar las dificultades técnicas y de gestión. Sin esta información, es imposible definir unas estimaciones razonables (y exactas) del coste; una valoración efectiva del riesgo, una subdivisión realista de las tareas del proyecto o una planificación del proyecto asequible que proporcione una indicación fiable del progreso.


El desarrollador de software y el cliente deben reunirse para definir los objetivos del producto y su ámbito. En muchos casos, esta actividad empieza como parte del proceso de ingeniería del sistema o del negocio y continúa como el primer paso en el análisis de los requisitos del software. Los objetivos identifican las metas generales del proyecto sin considerar cómo se conseguirán (desde el punto de vista del cliente).


El ámbito identifica los datos primarios, funciones y comportamientos que caracterizan al producto, y, más importante, intenta abordar estas características de una manera cuantitativa.
Una vez que se han entendido los objetivos y el ámbito del producto, se consideran soluciones alternativas.


Proceso


Un proceso de software  proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. Un pequeño número de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad. Diferentes conjuntos de tareas -tareas, hitos, productos del trabajo y puntos de garantía de calidad- permiten a las actividades estructurales adaptarse a las características del proyecto de software y a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras -tales como garantía de calidad del software, gestión de la configuración del software y medición- cubren el modelo de proceso. Las actividades protectoras son independientes de las estructurales y tienen lugar a lo largo del proceso.


Proyecto


Dirigimos los proyectos de software planificados y controlados por una razón principal -es la Única manera conocida de gestionar la complejidad-. Y todavía seguimos esforzándonos. En 1998, los datos de la industria del software indicaron que el 26 por 100 de proyectos de software fallaron completamente y que el 46 por 100 experimentaron un desbordamiento en la planificación y en el coste. Aunque la proporción de éxito para los proyectos de software ha mejorado un poco, nuestra proporción de fracaso de proyecto permanece más alto del que debería ser.


Para evitar el fracaso del proyecto, un gestor de proyectos de software y los ingenieros de software que construyeron el producto deben eludir un conjunto de señales de peligro comunes; comprender los factores del éxito críticos que conducen a la gestión correcta del proyecto y desarrollar un enfoque de sentido común para planificar, supervisar y controlar el proyecto.


Prácticas Criticas.


El Concilio Airlie ha desarrollado una lista de «prácticas críticas de software para la gestión basada en el rendimiento». Estas prácticas son «utilizadas de un modo consistente por, y consideradas críticas por, organizaciones y proyectos de software de mucho éxito cuyo rendimiento “final” es más consistente que los promedios de la industria» .En un esfuerzo por permitir a una organización de software determinar si un proyecto específico ha implementado prácticas críticas, el Concilio Airlie ha desarrollado un conjunto de preguntas de «Visión Rápida»  para un proyecto:


Gestión formal del riesgo. ¿Cuáles son los diez riesgos principales para este proyecto? Para cada uno de los riesgos ¿cuál es la oportunidad de que el riesgo se convierta en un problema y cuál es el impacto si lo hace?.


Coste empírico y estimación de la planificación. ¿Cuál es el tamaño actual estimado de la aplicación de software (sin incluir el software del sistema) que será entregada en la operación? ¿Cómo se obtuvo?.


Gestión de proyectos basada en métricas. ¿Dispone de un programa de métricas para dar una primera indicación de los problemas del desarrollo? Si es así, ¿cuál es la volatilidad de los requisitos actualmente? 


Seguimiento del valor ganado. ¿Informa mensualmente de las métricas del valor ganado ... ? Si
es así, ¿están calculadas estas métricas desde una red de actividades de tareas para el esfuerzo total a la próxima entrega?


Seguimiento de defectos frente a objetivos de calidad. ¿Realiza el seguimiento e informa periódicamente del número de defectos encontrados en cada prueba de inspección [revisión técnica formal] y ejecución desde el principio del programa y del número de defectos que se corrigen y se producen en la actualidad?.


Gestión del programa del personal. ¿Cuál es la media de rotación de la plantilla en los tres Últimos meses por cada uno de los distribuidores/desarrolladores involucrados en el desarrollo del software para este sistema?


 Si un equipo de proyectos de software no puede responder a estas preguntas, o las responde inadecuadamente, se debe realizar una revisión completa de las prácticas del proyecto.

(CONTINUACIÓN II ) Modelos de Desarrollo del Software.

MODELO BASADO EN COMPONENTES.

Las tecnologías de objetos proporcionan el marco de trabajo técnico para un modelo de proceso basado en componentes para la ingeniería del software. El paradigma orientado a objetos enfatiza la creación de clases que encapsulan tanto los datos como los algoritmos que se utilizan para manejar los datos. Si se diseñan y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por las diferentes aplicaciones y  arquitecturas de sistemas basados en computadora.


El modelo de desarrollo basado en componentes  incorpora muchas de las características del modelo en espiral. Es evolutivo por naturaleza, y exige un enfoque iterativo para la creación del software. Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software.


La actividad de la ingeniería comienza con la identificación de clases candidatas. Esto se lleva a cabo examinando los datos que se van a manejar por parte de la Aplicación y el algoritmo que se va a aplicar para conseguir el tratamientoI2. Los datos y los algoritmos correspondientes se empaquetan en una clase.


Las clases creadas en los proyectos de ingeniería del software anteriores, se almacenan en una biblioteca de clases o diccionario de datos (repository). Una vez identificadas las clases candidatas, la biblioteca de clases se examina para determinar si estas clases ya existen. En caso de que así fuera, se extraen de la biblioteca y se vuelven a utilizar. Si una clase candidata no reside en la biblioteca, se aplican los métodos orientados a objetos. Se compone así la primera iteración de la aplicación a construirse, mediante las clases extraídas de la biblioteca y las clases nuevas construidas para cumplir las necesidades Únicas de la aplicación. El flujo del proceso vuelve a la espiral y volverá a introducir por último la iteración ensambladora de componentes a través de la actividad de ingeniería.


El modelo de desarrollo basado en componentes conduce a la reutilización del  software, y la reutilización proporciona beneficios a los ingenieros de software. Según estudios de reutilización, QSM Associates, Inc. Informa que el ensamblaje de componentes lleva a una reducción del 70 por 100 de tiempo de ciclo de desarrollo, un 84 por 100 del coste del proyecto y un índice de productividad del 26.2, comparado con la norma de industria del 16.9. Aunque estos resultados están en función de la robustez de la biblioteca de componentes, no hay duda de que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros de software.


El proceso unificado de desarrollo de software representa un número de modelos de desarro la industria. Utilizando el Lenguaje de Modelado Unijcado (UML), el proceso unificado define los componentes que se utilizarán para construir el sistema y las interfaces que conectarán los componentes. Utilizando una combinacion del desarrollo incremental e iterativo, el proceso unificado define la función del sistema aplicando un enfoque basado en escenarios (desde el punto de vista del usuario). Entonces acopla la función con un marco de trabajo arquitectónico que identifica la forma que tomará el software.
 MODELO DE METODOS FORMALES.



El modelo de métodos formales comprende un conjunto de actividades que  conducen a la especificación matemática del software de computadora. Los métodos formales permiten que un ingeniero de software especifique,  desarrolle y verifique un sistema basado en computadora aplicando una notación rigurosa y matemática. Algunas organizaciones de desarrollo del software actualmente aplican una variación de este enfoque, llamado ingeniería del software de sala limpia.


Cuando se utilizan métodos formales  durante el desarrollo, proporcionan un mecanismo para eliminar muchos de los problemas que son difíciles de superar con paradigmas de la ingeniería del software. La ambigüedad, lo incompleto y la inconsistencia se descubren y se corrigen más fácilmente –no mediante un revisión a propósito para el caso, sino mediante la aplicación del análisis matemático-. Cuando se utilizan métodos formales durante el diseño, sirven como base'para la verificación de programas y por  consiguiente permiten que el ingeniero del software descubra y corrija errores que no se pudieron detectar de otra manera.


Aunque todavía no hay un enfoque establecido, los modelos de métodos formales ofrecen la promesa de un software libre de defectos. Sin embargo, se ha hablado de una gran preocupación sobre su aplicabilidad en un entorno de gestión:


1.    El desarrollo de modelos formales actualmente es bastante caro y lleva mucho tiempo. 


2.    Se requiere un estudio detallado porque pocos responsables del desarrollo de software tienen los antecedentes necesarios para aplicar métodos formales.


3.    Es difícil utilizar los modelos como un mecanismo de comunicación con clientes que no tienen muchos conocimientos técnicos.


No obstante es posible que el enfoque a través de métodos formales tenga más partidarios entre los desarrolladores del software que deben construir software de mucha seguridad (por ejemplo: los desarrolladores de aviónica y dispositivos médicos), y entre los desarrolladores que pasan grandes penurias económicas al aparecer errores de software. 

TECNICAS DE CUARTA GENERACION.


El término técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software que tienen algo en común: todas facilitan al ingeniero del software la especificación de algunas características del software a alto nivel. Luego, la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Cada vez parece más evidente que cuanto mayor sea el nivel en el que se especifique el software, más rápido se podrá construir el programa.


El paradigma T4G para la ingeniería del software se orienta hacia la posibilidad de especificar el software usando formas de lenguaje especializado o notaciones gráficas que describa el problema que hay que resolver en términos que los entienda el cliente. Actualmente, un entorno para el desarrollo de software que soporte el paradigma T4G puede incluir todas o algunas de las siguientes herramientas: lenguajes no procedimentales de consulta a bases de datos, generación de informes, manejo de datos, interacción y definición de pantallas, generación de códigos, capacidades gráficas de alto nivel y capacidades de hoja de cálculo, y generación automatizada de HTML y lenguajes similares utilizados para la creación de sitios web usando herramientas de software avanzado. Inicialmente, muchas de estas herramientas estaban disponibles, pero sólo para ámbitos de aplicación muy específicos, pero actualmente los entornos T4G se han extendido a todas las categorías de aplicaciones del software. Al igual que otros paradigmas, T4G comienza con el paso de reunión de requisitos. Idealmente, el cliente describe los requisitos, que son, a continuación, traducidos directamente a un prototipo operativo.


Sin embargo, en la práctica no se puede hacer eso. El cliente puede que no esté seguro de lo que necesita; puede ser ambiguo en la especificación de hechos que le son conocidos, y puede que no sea capaz o no esté dispuesto a especificar la información en la forma en que puede aceptar una herramienta T4G. Por esta razón, el diálogo cliente- desarrollador descrito por los otros paradigmas sigue siendo una parte esencial del enfoque T4G.


Para aplicaciones pequeñas, se puede ir directamente desde el paso de recolección de requisitos al paso de implementación, usando un lenguaje de cuarta generación no procedimental (L4G) o un modelo comprimido de red de iconos gráficos. Sin embargo, es necesario un mayor esfuerzo para desarrollar una estrategia de diseño para el sistema, incluso si se utiliza un L4G. 

 El uso de T4G sin diseño (para grandes proyectos) causará las mismas dificultades (poca calidad, mantenimiento pobre, mala aceptación por el cliente) que se encuentran cuando se desarrolla software mediante los enfoques convencionales.


La implementación mediante L4G permite, al que desarrolla el software, centrarse en la representación de los resultados deseados, que es lo que se traduce automáticamente en un código fuente que produce dichos resultados. Obviamente, debe existir una estructura de datos con información relevante y a la que el L4G pueda acceder rápidamente.

Para transformar una implementación T4G en un producto, el que lo desarrolla debe dirigir una prueba completa, desarrollar con sentido una documentación y ejecutar el resto de las actividades de integración que son también requeridas requeridas por otros paradigmas de ingeniería del software. Además, el software desarrollado con T4G debe ser construido de forma que facilite la realización del mantenimiento de forma Al igual que todos los paradigmas del software, el modelo T4G tiene ventajas e inconvenientes. Los defensores aducen reducciones drásticas en el tiempo de desarrollo del software y una mejora significativa en la productividad de la gente que construye el software.


Los detractores aducen que las herramientas actuales de T4G no son más fáciles de utilizar que los lenguajes de programación, que el código fuente producido por tales herramientas es «ineficiente» y que el mantenimiento de grandes sistemas de software desarrollados mediante T4G es cuestionable.


Hay algún mérito en lo que se refiere a indicaciones de ambos lados y es posible resumir el estado actual de los enfoques de T4G:


1.    El uso de T4G es un enfoque viable para muchas de las diferentes áreas de aplicación. Junto con las herramientas de ingeniería de software asistida por computadora (CASE) y los generadores de código, T4G ofrece una solución fiable a muchos problemas del software.

2.     
2. Los datos recogidos en compañías que usan T4G parecen indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas y de tamaño medio, y que la cantidad de análisis y diseño para las aplicaciones pequeñas también se reduce.


3. Sin embargo, el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o más tiempo de análisis, diseño y prueba (actividades de ingeniería del software), para lograr un ahorro sustancial de tiempo que puede conseguirse mediante la eliminación de la codificación. Resumiendo, las técnicas de cuarta generación ya se han convertido en una parte importante del desarrollo de software. Cuando se combinan con enfoques de ensamblaje de componentes (Sección 2.8), el paradigma T4G se puede convertir en el enfoque dominante hacia el desarrollo del software.