0 Modelos COCOMO,SLIM y Modelo de capacidad y de madurez.

lunes, 18 de octubre de 2010
Introducción

Es un modelo de estimación de costes.

Creado por Barry W. Boehm.

Incluye 3 submodelos con un nivel de detalle cada vez mayor.


Características principales:

Está basado en modelos de estimaciones matemáticas.

Está orientado al producto final, no a fases intermedias.

Se basa en la cantidad de líneas de codigo del proyecto.

Inconvenientes del modelo:

Comentarios en líneas de código.

Estimaciones sobre un nº de líneas de código variable.

No se le da importancia a la productividad, referente a los hábitos de trabajo

Dificultad para contemplar costes de revisiones, reuniones…

Modelos de estimación:

*Modelo básico

*Modelo intermedio

*Modelo avanzado

Modos:

Orgánico.

Semiacoplado.

Empotrado.

Modo Básico:
El modelo básico se usa para obtener una aproximación rápida del esfuerzo.

Usa las variables a, b, c y d, que varían en función de los modos.

Conforme se aumenta la complejidad del modo, aumentan los valores de las variables (esfuerzo).

Modelo básico.

Personas necesarias para llevar a cabo el proyecto:
(MM) = a*(Klb)
Tiempo de desarrollo del proyecto:
(TDEV) = c*(MMd)
Personas necesarias para el proyecto:
(CosteH) = MM/TDEV
Coste total del proyecto:
(CosteM) = CosteH * Salario medio

Modelo Intermedio:

Añade al modelo básico 15 factores de ajuste o guías de coste.
Logramos mayor precisión en la estimación gracias a los nuevos factores.
La fórmula es la misma que la del modelo básico pero con el añadido del factor (multiplicando).

Atributos del modelo:
Software:
RELY: Indica las consecuencias para el usuario si falla el producto.
DATA: Relación Tamaño de la BD / Líneas de código.
CPLX: Complejidad del producto.

Hardware:
TIME: Limitaciones en el porcentaje del uso de la CPU.
STOR: Limitaciones en el porcentaje del uso de la memoria.
VIRT: Volatilidad de la máquina virtual.
TURN: Tiempo de respuesta.

Personal:
ACAP: calificación de los analistas.
AEXP: experiencia del personal.
PCAP: calificación de los programadores.
VEXP: experiencia del personal en la máquina virtual.
LEXP: experiencia en el lenguaje.

Proyecto:
MODP: uso de prácticas modernas de programación.
TOOL: uso de herramientas de desarrollo de software.
SCED: limitaciones en el cumplimiento de la planificación.

Modelo SLIM:

Propuesto por Putnam.
Diseñado para proyectos grandes, aunque se puede adaptar a pequeños.
Se basa en la curva de Rayleigh

Parámetros del Modelo SLIM:

C: factor de tecnología
K: esfuerzo total medido en años-persona
td: tiempo de finalización del proyecto medido en años.
Se ven las consecuencias de variar estos parámtros

Ecuaciones del Modelo SLIM:




Las potencias de las ecuaciones se calcularon a partir de datos experimentales de desarrollo de productos software.

Modelo CMM:

Propuesto por el SEI
Evalúa la forma de desarrollar software de una organización
El CMM cuantifica la calidad del desarollo en 5 niveles distintos
El modelo ha evolucionado actualmente hasta el CMMI

Niveles del CMM:

Nivel 1: Inicial
Nivel 2: Repetible
Nivel 3: Definido
Nivel 4: Gestionado
Nivel 5: Optimizado

0 Uso de Técnicas de cuarta Generación

Las técnicas de cuarta generación son un conjunto muy diverso de métodos y herramientas que tienen por objeto el de facilitar el desarrollo del software, facilitan al que desarrolla el software la propiedad de especificar algunas características del mismo a alto nivel, mas tarde, la herramienta genera automáticamente el código fuente a partir de esta especificación.

Los tipos más comunes de generadores de código curen uno o varios de los siguientes aspectos:

•Acceso a base de datos: utilizando lenguajes de consulta de alto nivel.

•Generadores de códigos: a partir de una especificación de los requisitos se genera automáticamente toda la aplicación.

•Generación de pantallas: permitiendo diseñar la pantalla dibujándola directamente, incluyendo además el control del cursor y la gestión de los errores de los datos de entrada.

•Gestión de entornos gráficos.

•Generación de informes.


Los pasos de los paradigmas son: Recolección de requerimientos, Estrategia de Diseño, Implementación usando T4G y Producto.

Como otros paradigmas, T4G comienza con el paso de recolección de requerimientos. Idealmente el cliente debe describir los requerimientos y estos debe traducirse directamente en un prototipo operacional pero este no funciona. El cliente puede no estar seguro de lo que necesita, puede ser ambiguo en la especificación de hechos que son conocidos y puede ser incapaz o no desear especificar la información en la forma que una herramienta T4G puede construirla además las herramientas actuales T4G no son lo suficientemente sofisticadas para acomodar realmente lenguaje natural y no lo serán por algún tiempo en este momento el dialogo cliente técnico descrito por los otros paradigmas permanecen como una pequeña parte esencial del enfoque T4G. Para aplicaciones pequeñas puede ser posible ir directamente desde el paso de establecimiento de requerimientos a la implementación, usando un lenguaje de cuarta generación no procedimental (L4G) sin embargo es necesario un mayor esfuerzo para desarrollar una estrategia del diseño para el sistema incluso si se utiliza un L4G. El uso de T4G sin 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, pobre mantenimiento, mala aceptación por el cliente) que se encuentran cuando se desarrolla software usando los métodos convencionales. La implementación usando L4G facilita el que desarrolla al software la descripción de los resultados deseados, los cuales se traducen automáticamente en código fuente para producir dichos resultados. Obviamente debe existir una estructura de datos con información relevante y debe estar rápidamente accesible al L4G. El último paso de la figura anterior contiene la palabra producto para transformar una implementación T4G en un producto, el que lo desarrollo debe dirigir una prueba completa, desarrollar una documentación con sentido y ejecutar todas las otras actividades de transición requeridas en los otros paradigmas de la ingeniería de software. Además del software desarrollado con T4g, debe ser construido de forma que facilite que el mantenimiento y pueda ser ejecutado de una forma expeditiva. Los defensores aducen reducciones dramáticas en el tiempo de desarrollo en el software y una mejora significativa en la productividad de la gente que construye el software. Los retractores de este paradigma aducen que los lenguajes de programación, que el código fuente producido por tales herramientas es ineficiente y que el mantenimiento de grandes sistema de software desarrollado usando T4g está abierto a discusión.

Entre las críticas más habituales están las siguientes:

•No son más fáciles de utilizar que que los lenguajes de tercera generación.

•El código fuente que produce es ineficiente, al estar generado automáticamente no pueden hacer uso de de los trucos habituales para aumentar el rendimiento, que se basan en el buen conocimiento de cada caso en particular.

•Sólo son aplicables al software de gestión, la mayoría de las herramientas de cuarta generación están orientadas a la generación a partir de grandes bases de datos, pero últimamente están surgiendo herramientas que generan esquemas de códigos para aplicaciones de ingeniería y de tiempo real.

Algunos lenguajes de cuarta generación:

Progress 4GL, o Progress Open Edge como se han llamado sus últimas versiones, es un lenguaje muy utilizado pues es portable y muy confiable. Es una plataforma diseñada para ayudar a los desarrolladores en la construcción de aplicaciones empresariales de forma rápida, esto ayuda a recuperar la inversión de manera más rápida. Tiene la facilidad de fácilmente conectarse e integrarse con clientes, con otras aplicaciones y con distintas bases de datos.


SQL (Structured Query Language): SQL (lenguaje de consultas estructurado) es un lenguaje de acceso a bases de datos relacionales con el cual se pueden crear y manipular las mismas.


WinDev: Permite el desarrollo de interfaz gráfica. Se pueden realizar muchos tipos de aplicaciones, entre ellas: Gestión, industriales, médicas. En WinDev la calidad de las aplicaciones dependen menos del equipo de desarrollo que con otras herramientas, esto debido a que trae un conjunto de funciones avanzadas sin la necesidad de que alguien las programe, por ejemplo, puede ser que el entorno detecte que mejoras para aumentar el rendimiento y la velocidad del sistema y este mismo las sugiere y las realiza automáticamente, además, posee una herramienta generadora de reportes automática.


PowerBuilder: Es un entorno gráfico de programación orientado a objetos para el desarrollo de aplicaciones cliente/servidor, distribuidas y web. Incluye herramientas para generar reportes, acceder bases de datos y para crear interfaz gráfica.


Mathematica: En Mathematica se contemplan muchos de los aspectos técnicos de la computación como el manejo numérico, la conversión de datos, la visualización y la creación de interfaces para el usuario. El avance intelectual que hizo posible el desarrollo de un paquete tan completo fue la invención de un lenguaje que fuera capaz de manipular la gran cantidad de objetos que alberga la computaron técnica. Por su completitud es un paquete que a pesar de inicialmente ser usado por técnicos ha pasado a ser un ambiente manejado por gran cantidad de personas que han aprendido desplegar todas las utilidades que el programa ofrece como por ejemplo los estudiantes a los que les permite aprender de manera interactiva.

Conclusión:

La evolución de los lenguajes tiende cada vez más a alejarnos de la maquina o hardware, creando una mayor abstracción de los problemas a resolver, esto es beneficioso pues genera un ahorro significativo de recursos como el tiempo que es tan valioso actualmente.

Los Lenguajes de Cuarta Generación tienden a ser muy compatibles entre sus mismas evoluciones lo que nos permite crear aplicaciones con la confianza de que el trabajo realizado no será desechado más adelante.

Paquetes tan poderosos como Mathematica hacen posible que las técnicas de computación mejoren constantemente pues brindan una mayor facilidad para el análisis y diseño de nuevas herramientas, mientas también ayudan a áreas tan importantes como la educación, todo esto empleando la misma herramienta.

Es importante resaltar que para utilizar un 4GL se debe tener claro que si se desea manipular para sacarle un mayor rendimiento, se debe de hacer cambiando la forma normal de hacer software. Para esto, los programadores deben de volverse analistas, deben dominar técnicas estructuradas, conceptos de diseño de interfaz grafica, conceptos de arquitectura, conceptos de orientación a objetos y de principios de diseño. Y todo esto para poder obtener una mayor productividad, una mayor facilidad al dar mantenimiento y además una mejor apariencia de la aplicación.

0 Gestion de configuracion de software

Es un conjunto de actividades aplicadas a la Línea Base para gestionar los cambios del software a lo largo del ciclo de vida e implica una revisión técnica formal (RTF) de los Elementos de Configuración del Software( ECS).

Los ECS son objetos que poseen sus nombres, atributos y relaciones entre ellos. Una manera fácil de obtenerlos, es respondiendo las preguntas orientadoras:

¿Cómo identifico y gestiono las diferentes versiones existentes de un mismo software (y su documentación)?

¿Cómo controlo los cambios, antes y después que he entregado software al cliente?

¿Quién tiene la responsabilidad de aprobar y asignar prioridades en los cambios (la organización o mi equipo de trabajo)?

¿Cómo garantizo que los cambios realizados han sido los adecuados?

¿Qué mecanismos se usan para avisar a otros, de los cambios realizados?


Los cambios se clasifican como completos y parciales:

CAMBIOS COMPLETOS: Implica una modificación general en las diversas líneas base. Y para ello se usa V 1.0, 1.1, 1.2, ….
CAMBIOS PARCIALES: Implica una modificación dirigida en alguna línea base. Y para ello se usa V 1.0, 1.0.1, 1.0.2, ….

En el caso de obtener otro software similar al existente. Se utiliza V 1.0, 2.0, 3.0

Para constatar la magnitud del cambio, se practica la
AUDITORÍA DE SISTEMAS.

0 Caso de Estudio #2

Programa de Métricas

1.    Objetivo/s del Negocio
Realizar una mercadotecnia defensiva de sus servicios de viaje

2.    Nuevos saberes/aprendizaje
Conocimiento de los servicios que ofrece la compañía
ü  Contactos
·         Hoteles
·         Aerolíneas
·         Rentacar
ü  Paquetes turísticos
ü  Promociones de boletos de avión
ü  informes
·         Encuestas
·         Sugerencias


3.    Sub-objetivos
Pagina Web






4.    Entidades y Atributos de los sub-objetivos



 5.    Objetivo/s de medición
Medimos para tener una idea del tiempo que se necesita invertir en el desarrollo del software, los recursos humanos y monetarios a utilizar.

6.    Preguntas cuantitativas e indicadores relacionales
Preguntas
Indicadores
¿Cuál es el esfuerzo necesario para desarrollar el software?
Esfuerzo(E)

¿Cuántas personas van a ser necesarias para conformar el equipo de trabajo?
Personas(P)
¿Cuánto tiempo va a ser invertido para el desarrollo e implementación del software?
Tiempo de desarrollo(TD)
¿Cuál es el coste de inversión para el software?
Costo(CT)

7.    Recolección de datos y calculo de indicadores

P=3.00*(0.367)1.12
P=0.975 = 1

TD=2.5*(0.976)0.35
TD=2.47 = 2 ½ meses

CT= (0.976/2.47)*275
CT=108.66 = 109
E=0.976*16.12
E=15.73 = 16

8.    Medidas a usar(Definición operativa de los resultados)

·         En el cálculo de las personas se llego a la conclusión de que no se necesita de un grupo de trabajo porque una persona es suficiente para realizar todo el trabajo que requiere.
·         En el cálculo del tiempo de desarrollo de software concluimos que la duración del desarrollo del proyecto será de dos meses y medio.
·         En el cálculo del costo concluimos que la ganancia del proyecto después de finalizar todos los pagos(viáticos, salarios, licencia, alquiler y servicios generales) es de $109(ciento nueve dólares).
·         En el cálculo del esfuerzo nos dimos cuenta de que la persona que desarrollara el software realizara en dos meses y medio lo que hubieran realizado 16 personas manualmente.

9.    Acciones de mejora
No hay acciones de mejora porque los cálculos son equitativos a la realidad y por tanto pasamos a la implementación. 

1.     Plan de implementación(Diagrama de proyect)




Interfaces.
 





 Cuadro de Gestion de Riesgo





0 Caso de Estudio #1

Programa de Métricas


1. Objetivo/s del Negocio
Mejorar gestión de fondos asignados a los programas en Nicaragua.


2. Nuevos saberes/aprendizaje


Conocimiento de la agenda de eventos de la organización FES
*Lugar
*Fecha
*Refrigerio y alimentos
*Exponencias
•Temas
•Documentación
•Material de apoyo
*Participantes
• Invitaciones
• Confirmación
• Llenado de datos
*Informes
• Fotos
• Videos
*Publicaciones
• Comentarios(charlas)
• Encuestas
• Gráficos


3. Sub-objetivos
Agenda de eventos.


4. Entidades y Atributos de los sub-objetivos




5. Objetivo/s de medición 

Medimos para tener una idea del tiempo que se necesita invertir en el desarrollo del software, los recursos humanos y monetarios a utilizar.


6. Preguntas cuantitativas e indicadores relacionales

Preguntas
Indicadores
¿Cuál es el esfuerzo necesario para desarrollar el software?
Esfuerzo(E)

¿Cuántas personas van a ser necesarias para conformar el equipo de trabajo?
Personas(P)
¿Cuánto tiempo va a ser invertido para el desarrollo e implementación del software?
Tiempo de desarrollo(TD)
¿Cuál es el coste de inversión para el software?
Costo(CT)

7. Recolección de datos y calculo de indicadores
P=3.00*(0.85)1.12
P=2.5=3


TD=2.5*(2.5)0.35
TD=3.44=3 1/2 meses



CT=(2.5/3.44) *275
CT= 199.85=200

8. Medidas a usar(Definición operativa de los resultados)


• En el cálculo de las personas se llego a la concusión de q el grupo de trabajo va a estar conformado por no más de 3 integrantes.
• En el cálculo del tiempo de desarrollo de software se determino que la duración del proyecto sería de 3 meses y medio equivalente a 14 semanas.
• En el cálculo del costo concluimos que la ganancia del proyecto después de finalizar todos los pagos(viáticos, salarios, licencias, alquiler y servicios generales) es de $200(doscientos dólares).


9. Acciones de mejora
No hay acciones de mejora porque los cálculos son equitativos a la realidad y por tanto pasamos a la implementación.


10. Plan de implementación(Diagrama de proyect)



Interfaces






  

Cuadro de Gestion de Riesgo




0 El software: Mitos, Aplicaciones y Fases genericas.

viernes, 1 de octubre de 2010
Que es el Software?

El software de computadora es el producto que diseñan y construyen los ingenieros del software. Esto abarca programas que se ejecutan dentro de una computadora de cualquier tamaño y arquitectura, documentos que comprenden formularios virtuales e impresos y datos que combinan números y texto y también incluyen representaciones de información de audio, video e imágenes.

Características:

1. El software se desarrolla, no se fabrica en un sentido clásico.

Aunque existen similitudes entre el desarrollo del software y la construcción del hardware, ambas actividades son fundamentalmente diferentes. En ambas actividades la buena calidad se adquiere mediante un buen diseño, pero la fase de construcción del hardware puede introducir problemas de calidad que no existen (o son fácilmente corregibles) en el software.

2. El software no se «estropea».

El software no es susceptible a los males del entorno que hacen que el hardware se estropee. . Los defectos no detectados harán que falle el programa durante las primeras etapas de su vida. Sin embargo, una vez que se corrigen(suponiendo que no se introducen nuevos errores) la curva se aplana.

3. Aunque la industria tiende a ensamblar componentes, la mayoría del software se construye a medida.

Consideremos la forma en la que se diseña y se construye el hardware de control para un producto basado en computadora. El ingeniero de diseño construye un sencillo esquema de la circuitería digital, hace algún análisis fundamental para asegurar que se consigue la función adecuada y va al armario donde se encuentran los catálogos de componentes digitales. Después de seleccionar cada componente, puede solicitarse la compra.

Mitos:

Mitos de gestión: Los gestores con responsabilidad sobre el software, como los gestores en la mayoría de las disciplinas, están normalmente bajo la presión de cumplir los presupuestos, hacer que no se retrase el proyecto y mejorar la calidad. Igual que se agarra al vacío una persona que se ahoga, un gestor de software se agarra frecuentemente a un mito del software, aunque tal creencia sólo disminuya la presión temporalmente.

Mitos del Cliente: Un cliente que solicita una aplicación de software puede ser una persona del despacho de al lado, un grupo técnico de la sala de abajo, el departamento de ventas o una compañía exterior que solicita un software bajo contrato. En muchos casos, el cliente cree en los mitos que existen sobre el software, debido a que los gestores y desarrolladores del software hacen muy poco para corregir la mala información. Los mitos conducen a que el cliente se cree una falsa expectativa y, finalmente, quede insatisfecho con el que desarrolla el software.

Mitos de los desarrolladores: Los mitos en los que aún creen muchos desarrolladores se han ido fomentando durante 50 años de cultura informática. Durante los primeros días del desarrollo del software, la programación se veía como un arte. Las viejas formas y actitudes tardan en morir.

Aplicaciones:

Software de sistemas: El software de sistemas es un conjunto de programas que han sido escritos para servir a otros programas.

Software de tiempo real: El software que coordina/analiza/controla sucesos del mundo real conforme ocurren, se denomina de tiempo real.

Software de gestión: El proceso de la información comercial constituye la mayor de las áreas de aplicación del software.

Software de ingeniería y científico: El software de ingeniería y científico está caracterizado por los algoritmos de «manejo de números». Las aplicaciones van desde la astronomía a la vulcanología, desde el análisis de la presión de los automotores a la dinámica orbital de las lanzaderas espaciales y desde la biología molecular a la fabricación automática.

Software de inteligencia artificial: El software de inteligencia artificial (IA) hace uso de algoritmos no numéricos para resolver problemas complejos para los que no son adecuados el cálculo o el análisis directo. Los sistemas expertos, también llamados sistemas basados en el conocimiento, reconocimiento de patrones (imágenes y voz), redes neuronales artificiales, prueba de teoremas, y los juegos son representativos de las aplicaciones de esta categoría.

Fases Genéricas:

La fase de definición se centra sobre el qué: Es decir, durante la definición, el que desarrolla el software intenta identificar qué información ha de ser procesada, qué función y rendimiento se desea, qué comportamiento del sistema, qué interfaces van a ser establecidas, qué restricciones de diseño existen, y qué criterios de validación
se necesitan para definir un sistema correcto. Por tanto, han de identificarse los requisitos clave del sistema y del software.

La fase de desarrollo se centra en el cómo: Es decir, durante el desarrollo un ingeniero del software intenta definir cómo han de diseñarse las estructuras de datos,
cómo ha de implementarse la función dentro de una arquitectura de software, cómo han de implementarse los detalles procedimentales, cómo han de caracterizarse interfaces, cómo ha de traducirse el diseño en un lenguaje de programación (o lenguaje no procedimental) y cómo ha de realizarse la prueba.

La fase de mantenimiento: se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. Durante la fase de mantenimiento se encuentran cuatro tipos de cambios.

Corrección. Incluso llevando a cabo las mejores actividades de garantía de calidad, es muy probable que el cliente descubra los defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos.

Adaptación. Con el paso del tiempo, es probable que cambie el entorno original (por ejemplo: CPU, el sistema operativo, las reglas de empresa, las características externas de productos) para el que se desarrolló el software. El mantenimiento adaptativo produce modificación en el software para acomodarlo a los cambios de su entorno externo.

Mejora. Conforme se utilice el software, el cliente/usuario puede descubrir funciones adicionales que van a producir beneficios. El mantenimiento perfectivo lleva al software más allá de sus requisitos funcionales originales.

Prevención. El software de computadora se deteriora debido al cambio, y por esto el mantenimiento preventivo también llamado reingeniería del software, se debe conducir a permitir que el software sirva para las necesidades de los usuarios finales. En esencia, el mantenimiento preventivo hace cambios en programas de computadora a fin de que se puedan corregir, adaptar y mejorar más fácilmente.

0 Metodos formales

¿Qué es un método formal?
Es cualquier técnica que trata la construcción y el análisis de modelos matemáticos que contribuyen a la automatización de desarrollo de sistema de información.

Ventajas de los métodos formales:
1.Se comprende mejor el sistema.
2.La comunicación con el cliente mejora.
3.El sistema se describe más precisamente.
4.El sistema asegura matemáticamente que es correcto según las especificaciones.
5.Mayor calidad del software respecto al cumplimiento de especificaciones.
6.Mayor productividad.

Clasificación:
1.Especificaciones basadas en lógicas de primer orden y teoría de conjunto.
2.Especificaciones algebraicas.

Especificaciones de comportamientos:

1.Métodos basados en algebra de proceso.
2.Métodos basados en redes petri.
3.Métodos en lógica temporal.

Métodos de verificación:

1.Aserciones entrada y salida.
2.Precondición más débil.
3.Inducción estructural.

10 mandamientos de los métodos:

1.Seleccionaras la notación adecuada.
2.Formalizaras, pero no de mas.
3.Estimaras los costos.
4.Poseerás un experto en métodos formales a tu disposición.
5.No abandoras tus métodos formales de desarrollo.
6.Documentaras suficientemente.
7.No comprometerás los estándares de calidad.
8.No serás dogmatico.
9.Comprobaras, comprobaras y volverás a comprobar.
10.Reutilizaras cuanto puedas.


Los 7 mitos sobre los métodos formales:

1.Garantizar que el software este perfecto.
2.Se centran en demostrar corrección.
3.Son útiles solo para sistemas críticos.
4.Requieren matemáticos entrenados.
5.Aumentan el costo de desarrollo.
6.Son incomprensibles para los usuarios.
7.No se usan en grandes proyectos reales.