martes, 19 de octubre de 2010

Métricas del SW



 Métricas Orientadas al tamaño



 Es para saber en que tiempo voy a terminar el software y cuantas personas voy a necesitar. Son medidas directas al software y el proceso por el cual se desarrolla, si una organización de software mantiene registros sencillos, se puede crear una tabla de datos orientados al tamaño como se muestra en la siguiente figura:





La tabla lista cada proyecto del desarrollo del software de los últimos años correspondientes, datos orientados al tamaño de c/u. Refiriéndonos a la entrada de la tabla del proyecto 999-01 se desarrollaron 12.1 KLDC (miles de líneas de código) con un esfuerzo de 24 personas mes y un costo de 168 mil dólares. Debe tenerse en cuenta que el esfuerzo y el costo registrados en la tabla incluyen todas las actividades de la ingeniería de software como son análisis, diseño, codificación y prueba. Otra información del proyecto 222-01 indica que se desarrollaron 365
paginas mientras que se encontraron 29 errores tras entregárselo al cliente, dentro del primer año de utilización también sabemos que trabajaron 3 personas en el desarrollo del proyecto. 
En los rendimientos del sistema y los rudimentarios datos contenidos en la tabla se puede
desarrollar, para cada proyecto un conjunto de métricas sencillas de productividad y calidad orientadas al tamaño. Se obtienen las siguientes formulas:


Productividad = KLDC/persona-mes
Calidad = errores/KLDC
Documentación = pags. Doc/ KLDC
Costo = $/KLDC
persona-mes es el esfuerzo



Métricas Orientadas a la función

Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcularlas las LDC, las métricas orientadas a la función se centran en la funcionalidad o utilidad del programa. Las métricas orientadas a la función fueron el principio propuestas por Albercht quien sugirió un acercamiento a la medida de la productividad denominado método del punto de función. Los puntos de función que obtienen utilizando una función empírica basando en medidas cuantitativas del dominio de información del software y valoraciones subjetivos de la complejidad del software. Los puntos de función se calculan rellenando la tabla como se muestra en la siguiente figura:


Calculo de métricas de punto de función.





Se determinan 5 características del ámbito de la información y los cálculos aparecen en la posición apropiada de la tabla. Los valores del ámbito de información están definidos de la siguiente manera.

1. Números de entrada de usuario: se cuenta cada entrada del usuario que proporcione al software diferentes datos orientados a la aplicación. Las entradas deben ser distinguidas de las peticiones que se contabilizan por separado.
2. Numero de salida del usuario: se encuentra cada salida que proporciona la usuario información orientada ala aplicación. En este contexto las salidas se refieren a informes, pantalla, mensajes de error. Los elementos de datos individuales dentro de un informe se encuentran por separado.
3. Números de peticiones al usuario: una petición esta definida como una entrada interactiva que resulta de la generación de algún tipo de respuesta en forma de salida interactiva. Se cuenta cada petición por separado.
4. Numero de archivos: se cuenta cada archivo maestro lógico, o sea una agrupación lógica de datos que puede ser una parte en una gran base de datos o un archivo independiente.
5. Numero de interfaces externas: se cuentan todas las interfaces legibles por la maquina por ejemplo: archivos de datos, en cinta o discos que son utilizados para transmitir información a otro sistema.

Cuando han sido recogidos los datos anteriores se asocian el valor de complejidad a cada cuenta. Las organizaciones que utilizan métodos de puntos de función desarrollan criterios para determinar si una entrada es denominada simple, media o compleja. No obstante la determinación de la complejidad es algo subjetivo.

Para calcular los puntos de función se utiliza la siguiente relación.

PF = CUENTA_TOTAL * [0.65 + 0.01 * SUM(fi)]
Donde CUENTA_TOTAL es la suma de todas las entradas de PF obtenidas de la tabla anterior.
Fi donde i puede ser de uno hasta 14 los valores de ajuste de complejidad basados en las
respuestas a las cuestiones señaladas de la siguiente tabla.
Evaluar cada factor en escala 0 a 5.




Los valores constantes de la ecuación anterior y los factores de peso aplicados en las encuestas de los ámbitos de información han sido determinados empíricamente. Una vez calculado los puntos de función se usan de forma analógica a las LDC como medida de la productividad, calidad y otros productos del software.

Productividad = PF / persona-mes
Calidad = Errores / PF
Costo = Dólares / PF
Documentación = Pags. Doc / PF

La medida de puntos de función se diseño originalmente para ser utilizadas en aplicación de sistemas de información de gestión. Sin embargo, algunas aplicaciones se les denomina puntos de características. La medida del punto de característica da cabida a aplicaciones cuya complejidad algoritmica es alta. Las aplicaciones de software de tiempo real de control de procesos y de sistemas que encontrados tienden a tener una complejidad algoritmica alta y por tanto fácilmente tratables por puntos de características.


Métricas ampliadas de punto de función


Los puntos de función fueron diseñados originalmente para sistemas de información y por eso le da más importancia a los datos y menos a los aspectos de control y funcionales. Para subsanar esto, se han propuesto los puntos de característica y los puntos de función 3D.

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.

Puntos de función 3D.

donde:

    * Estructuras internas de datos. Son arreglos, listas ligadas, pilas, colas, etc.
    * Datos externos.
    * Entradas de usuario. Definidas igual que para el punto de función.
    * Salidas de usuario. Definidas igual que para el punto de función.
    * Peticiones de usuario. Definidas igual que para el punto de función.
    * Transformaciones. Son las operaciones internas requeridas para transformar datos de entrada en datos de salida. Multiplicar dos matrices cuenta como una transformación. Leer datos de un archivo y guardarlos en memoria no.
    * Transiciones. Ocurre cuando el software pasa de un estado a otro como resultado de algún suceso. En un sistema de altas, bajas y cambios, al tomar la opción de altas, pasa del estado "menú principal" al estado "procesa altas" y puede ser que en ese momento pida datos para dar la alta.

Indicaciones:

    * Para cada medida, contar por separado, de acuerdo a algún criterio de asignación de complejidad, las veces que aparezca con complejidad baja, media y alta.
    * Para cada medida, multiplicar cada cuenta por el factor de complejidad correspondiente, sumar las tres cantidades y escribir el total en la columna de la extrema derecha.
    * Sumar la columna de la extrema derecha y obtener el punto de función 3D.


Métricas Orientadas a la  Calidad


Corrección: medir la funcionalidad del software(para lo que fue hecho).

Facilidad de Mantenimiento: facilidad para corregir errores y adaptarse a los cambios.

Integridad: medir la capacidad del sistema para resistir ataques accidentales o intencionales en su seguridad.

Integridad= 1-(amenaza*(1-seguridad)

Amenaza =probabilidad que un ataque suceda en un tiempo determinado.
Seguridad = probabilidad de que se repela la amenaza.

Facilidad de uso: se mide en términos de interfaz de usuario.

Eficacia en la eliminacion de defectos


Cuando se considera un proyecto como un todo se define:

EED=  E/ (E+D)
E: numero de errores encontrados antes de entregar el software al usuario final
D: numero de defectos encontrados después de la entrega.

Nota: El valor ideal de EDD es 1

Al aplicarla antes de que ocurra una  actividad  se define como:

EEDi= Ei/(Ei+Ei+1)

Ei: numero de errores encontrados durante la actividad
Ei+1: numero de errores encontrados durante la actividad i+1 de ingeniería del software.


Métricas para las pequeñas organizaciones


  • Tiempo transcurrido desde el momento en que se hizo la solicitud hasta que la evaluación esta completa
  • Esfuerzo para realizar la evaluación.
  • Tiempo transcurrido desde que se completa la evaluación hasta la asignación del pedido de cambio de personal.
  • Esfuerzo requerido para hacer el cambio.
  • Tiempo requerido para hacer el cambio.
  • Errores descubiertos durante el trabajo para hacer el cambio.
  • Defectos descubiertos después de que el cambio es liberado a la base de cliente.
Programa de métricas y planificación


Aplicación de métricas Orientadas al Tamaño y Orientadas a la función a los casos de estudio

Caso FES


1.Objetivos del Negocio.
Automatizar sus actividades a fin de mejorar la Gestión de Fondos asignados a los diversos programas.

2.Nuevos saberes/Aprendizajes.

La Fundación Friedrich Ebert (FES) fue creada en 1925 como legado político de Friedrich Ebert, el primer presidente alemán elegido democráticamente. La Fundación es una institución político-cultural privada, sin fines de lucro, comprometida con los principios y los valores fundamentales de la democracia social.

El trabajo de la Fundación tiene como objetivo fomentar la participación, el pluralismo y la justicia social así como fortalecer el estado de derecho y promover la búsqueda de soluciones pacíficas de conflictos en la esfera estatal y en la sociedad civil. La FES trabaja con partidos políticos, sindicatos, instituciones de investigación y enseñanza, movimientos cívicos y organizaciones de la sociedad civil; igualmente, con entidades estatales y organismos internacionales.

En sus prioridades de trabajo, las oficinas de la FES se orientan por sus cometidos principales, los grandes retos políticos globales y por las necesidades de sus respectivas contrapartes. La asesoría política, la formación socio-política y el intercambio internacional de experiencias se realizan mediante consultorías, conferencias, seminarios y talleres.


El trabajo internacional de la FES es financiado, en su mayor parte, con fondos proporcionados por el Ministerio Federal de Cooperación Económica y Desarrollo y el Ministerio Federal de Relaciones Exteriores. Con recursos de otros organismos, entre ellos de la Unión Europea, se financian numerosos proyectos específicos.

3.Subojetivos.

Mejorar la  Gestión de Fondos asignados a los programas Nicas y control de:

Agenda de Eventos:
    Lugar.
    Fecha
    Participantes
        Invitaciones.
        Confirmación.
        Llenado de datos.
Exponencias
    Temas.
    Documentos.
    Materiales de Apoyo.
    Informes.
    Publicación.
Refrigerios y Alimentos.


4.Entidades y atributos de los Subojetivos


5.Objetivos de Medición.

Nuestros objetivos con respecto a la medición del Software es tratar de que el mismo trabaje con gran funcionalidad y eficiencia del cual tratamos de que se realice con gran calidad para que no haya problemas en el momento de la implementación. Así como que tenga la facilidad de darle mantenimiento o control de errores para que no haya ningún tipo de problema. Todo esto con el fin de crear un software que se ha muy fiable y de gran particularidad y que se ha de agrado a la Fundación.

6. Preguntas Cuantitativas e Indicadores relacionados.

1. ¿Requiere el sistema copias de seguridad y de recuperación fiables?
2. ¿Se requiere comunicación de datos?
3. ¿Existen funciones de procesamiento distribuido?
4. ¿Es crítico el rendimiento?
5. ¿Se ejecutaría el sistema en un entorno operativo existente y fuertemente utilizado?
6. ¿Requiere el sistema entrada de datos interactiva?
7. ¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas u operaciones?
8. ¿Se actualizan los archivos maestros de forma interactiva?
9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones?
10. ¿Es complejo el procesamiento interno?
11. ¿Se ha diseñado el código para ser reutilizable?
12. ¿Están incluidas en el diseño la conversi6n y la instalaci6n?
13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?
14. ¿Se ha diseñado la aplicaci6n para facilitar los cambios y para ser fácilmente utilizada por el usuario?

Cada una de las preguntas anteriores es respondida usando una escala con rangos desde 0 (no importante o aplicable) hasta 5 (absolutamente esencial).


7.Recolecta de datos y cálculos de indicadores.


 Según el modo y el modelo, mis constantes tienen los valores siguientes:


Esto es para determinar los Factores ∑ F


PF= CUT * (0.65 + 0.01 * ∑ F)

PF=714 * (0.65 + 0.01 * 54)
    =714*(0.65 + 0.54)
    =714*(1.19)
    =849.66
   =850

P= a (Kl) b
P=3 * (0.85)
  = 2.50

TD= C * Pd
    = 2.5 * (2.5)0.35
    =3.44
   

CT= P/TD * Salario Prom.del personal
   = (2.50)/(3.44) * U$ 200
   = U$ 145.34




M(x)=





M(X): ∑pesos

Atributos de Software:
3.40

Atributos de Hardware:
4

Atributo de Personal:
1.53

Atributo del Proyecto:
3.44

∑pesos
3.40
4
1.53
3.44
_______
12.37



Medidas a usar.

Definición Operativa de Resultados:

PF (Punto de función)= Esto quiere decir que en el punto de función tiene 850 líneas de código o sea 0.85 Kl.

P= Equivalente al número de personas que van a desarrollar el software osea como máximo 3 integrantes.

TD= Tiempo de desarrollo (meses) En este caso son 3 mese y medio para desarrollar un software complejo.

CT= Ganancia o costo total del software total en este caso es de U$145.

M(x)= Es un multiplicador que depende de 15 o 17 atributos y del peso cualitativo.


Acciones de Mejora.

  • Aumentar el personal capacitado para el desarrollo del software.
  • Es recomendable comenzar por automatizar las pruebas de aquellos procesos que aporten mayor valor, aunque la labor sea a priori más compleja.
  • Es necesario decidir qué mostrar, cuándo y a quién, fijando diferentes niveles de abstracción o agrupación de datos.
 
 
Caso Agencia de viajes Sky Light Tours


1-Objetivo del Negocio:

Realizar una mercadotecnia defensiva para promocionar sus servicios  en los diferentes medios de comunicación.

2-Nuevos saberes /aprendizaje

 
Sky Light tour Operadora  fue fundada en febrero de 2004, por su Gerente General Lic. Ivania Sequeira, como un proyecto familiar con el objetivo de unificar los ingresos dentro del entorno familiar y dejar herramientas de trabajo a sus hijos.

Es una empresa turística que brinda los servicios en venta de boletos aéreos, paquetes turísticos, renta de automóviles, en todo el territorio nacional e internacional.
Brindan  servicios personalizados a los organismos internacionales, empresas  privadas y público en general

Todas las transacciones de los servicios turísticos son realizadas vía internet, telefónicamente o visitas personales a los diferentes clientes.

3- Sub-objetivos:

Sitio Web
Mapa País:
    Ciudades:
    Hoteles
    Descripción
    Servicios: Habitaciones,  Piscina, restaurante, recreaciones (Alquiler vehicular).
    Promociones: paquetes turísticos, viajes.
Aerolíneas:
    Clase
    Origen
    Destino
    Promociones
Clientes:
    Información: paquetes turísticos ,  Promoción de boletos aéreos
    Encuesta
    Sugerencias


4- Entidades y atributos de los Sub-objetivos
 
 
 
5- Objetivos de medición:

Mejorar el proceso de software, ya que ayudan a  la planificación, seguimiento y control del proyecto.
Evaluar la calidad del software que se va a producir
Analizar los indicadores
Realizar guías y acciones de gestión y técnicas
Tener una visión en cuanto a la efectividad del proceso de desarrollo


6- Preguntas Cuantitativas  e indicadores relacionados.



1. ¿Requiere el sistema copias de seguridad y de recuperación fiables?
2. ¿Se requiere comunicación de datos?
3. ¿Existen funciones de procesamiento distribuido?
4. ¿Es crítico el rendimiento?
5. ¿Se ejecutaría el sistema en un entorno operativo existente y fuertemente utilizado?
6. ¿Requiere el sistema entrada de datos interactiva?
7. ¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas u operaciones?
8. ¿Se actualizan los archivos maestros de forma interactiva?
9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones?
10. ¿Es complejo el procesamiento interno?
11. ¿Se ha diseñado el código para ser reutilizable?
12. ¿Están incluidas en el diseño la conversión y la instalación?
13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?
14. ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario?


7- Recolecta de datos y  Cálculos de indicadores relacionados.

Según el modo y el modelo seleccionado, las  constantes tienen los valores siguientes:



Esto es para determinar los Factores ∑ F




PF= CUT * (0.65 + 0.01 * ∑ F)
PF=  726   * (0.65 + 0.01 * 59 )
    =   726 *(0.65 + 0.59 )
    =   726 *(1.24)
    =   900
  

P= a (Kl) b
P=3 * (0.9)1.12
  = 2.66= 3 personas
 

TD= C * Pd
    = 2.5 * (2.6)0.35
    = 3.49
     
CT= P/TD * Salario Prom.del personal
   = (2.66)/(3.49) * U$ 200
   = U$ 152.43



 M(X): ∑pesos

Atributos de Software:
3.40

Atributos de Hardware:
4

Atributo de Personal:
5.41

Atributo del Proyecto:
3.2

∑Pesos
3.40
4
5.41
3.2
_______
16.01


8- Medidas  a usar (definición Operativa de resultados).


PF (Punto de función)= Esto quiere decir que en el punto de función tiene  900  líneas de código o sea 0.9 Kl.

P= Equivalente al número de personas que van a desarrollar el software osea como máximo  3 integrantes.

TD= Tiempo de desarrollo (meses) En este caso son 3  meses y medio para desarrollar un software complejo.

CT= Ganancia o costo total del software total en este caso es de U$ 152.43.

M(x)= Es un multiplicador que depende de 15 o 17 atributos y del peso cualitativo.Prototipo de Interfaz
 
 
Interfaz de Agencia de Viajes





Interfaz de Hoteles



Interfaz de Aerolínea



Interfaz de Alquiler de Vehículos


Gestión de Configuración del 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).

Garantía de la calidad de Software SQA

Consiste en los medios de la supervisión tecnología de dotación lógica los procesos y los métodos aseguraban calidad. Hace esto por medio de intervenciones de sistema de gerencia de la calidad debajo de cuál se crea el sistema de software. Estas intervenciones son movidas hacia atrás por unos o más estándares, generalmente ISO 9000.

La garantía de calidad del software se relaciona con la práctica de garantía de calidad en producto fabricación. Hay, sin embargo, algunas diferencias notables entre el software y un producto manufacturado. Estas diferencias provienen el hecho de que el producto manufacturado es físico y puede ser visto mientras que el producto de software no es visible.


Por lo tanto su función, ventaja y costes no están según lo medido fácilmente. Cuál es más, cuando un producto manufacturado cae la planta de fabricación, es esencialmente un completo, producto final, mientras que el software nunca se acaba. El software vive, crece, se desarrolla, y transforma, desemejante de sus contrapartes tangibles. Por lo tanto, los procesos y los métodos para manejar, para supervisar, y para medir su calidad en curso son tan líquido y a veces evasivos como son los defectos que se significan para mantener cheque.



Ventajas de SQA:


Satisfacción de cliente mejorada: La satisfacción de cliente mejorada significa relaciones más de largo, más provechosas del cliente, testimonials positivos del cliente, y las ondas del negocio de la remisión generadas de la palabra positiva de la boca.

Coste reducido de desarrollo: Porque el proceso de la garantía de calidad del software se diseña para prevenir defectos e ineficacias del software, los proyectos que incorporan riguroso, prueba del objetivo encontrarán que los costes del desarrollo están reducidos puesto que todas las fases más posteriores del ciclo vital del desarrollo llegan a ser aerodinámicas y simplificados perceptiblemente.

Coste de mantenimiento reducido: los usos Insecto-infestados son molestos apoyar. El coste combinado de memorias, de vueltas, y de remiendos innecesarios puede ser espantoso. Y eso no dice nada de qué tendrá que ser pasada en ayuda de cliente en curso, sea por el teléfono, email, o en persona



Metodología de la SQA


La prueba del software es tanto un arte como una ciencia. En grande, los usos complejos, tales como sistemas operativos, es prácticamente imposible planchar hacia fuera cada solo insecto antes de lanzarlo ambos de un punto de vista de la dificultad y debido a los apremios del tiempo. Diversos usos del software requieren diversos acercamientos cuando viene a la prueba, pero algunas de las tareas mas comunes del QA del software incluyen:


Prueba de la validación

La prueba de la validación es el acto de los datos que entran que el probador sabe para ser erróneo en un uso. Por ejemplo, mecanografiando “hola” en una caja de corregir que está esperando recibir una entrada numérica.

Comparación de los datos

Comparando la salida de un uso con parámetros específicos a un sistema previamente creado de los datos con los mismos parámetros que se saben para ser exactos.


Prueba de la tensión

Una prueba de tensión es cuando el software se utiliza tan pesadamente como sea posible por un período de la hora de considerar si hace frente a los altos niveles de la carga. De uso frecuente para el software del servidor que tendrá múltiple los usuarios conectaron con él simultáneamente. También conocido como prueba de la destrucción.

Prueba de la utilidad

A veces consiguiendo a los usuarios que son desconocedores con el software intentarlo durante algún tiempo y ofrecer la regeneración a los reveladores sobre lo que encontraron difíciles de hacer es la mejor manera de llevar a cabo mejoras a un interfaz utilizador.


Puntos Importantes


1. Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.

2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.

3. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo: el deseo por facilitar el uso y un buen mantenimiento). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software queda en entredicho.

Análisis y Gestión del Riesgo

Tablas de Riesgos

Concepto del Espectro de Gestión

Personal (Cargos)
  1. Operador de PC.
  2. Técnico de Soporte y Mantenimiento.
  3. Técnico de Reparación de PC, impresora, monitor, etc.
  4. Técnico en Programación.
  5. Técnico de Redes de Computadoras, Telefónicas, de comunicación.
  6. Ingenieros en Computación.
  7. Ingenieros en Sistemas.
  8. Ingenieros en Telecomunicaciones.
  9. Ingenieros Electrónicos
  10. Administrador de Bases de Datos
  11. Administrador de Redes.
  12. Administrador de Servidores.
  13. Administrador de Sistemas de Información.
  14. Analista 
  15. Diseñador de sitio web
  16. Diseñador de Interfaz.
  17. Desarrollador.
  18. Evaluador.
  19. Auditor.
  20. Director de Informática.
  21. Director de Centros.
  22. Capacitador  

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»



Salarios

Los salarios en Nicaragua estan en un rango de U$100- 2000.


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.



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.

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

  • Gestión basada en el rendimiento.
  • Gestión de formas del riesgo.
  • Riesgo.
  • Oportunidad de su problema.
  • Impacto.
  • Costo Empiríco y estimación de la planificación.
  • Gestión basada en métricas.
  • Seguimiento de defectos frente a objetivos de calidad.
  • Gestión del programa personal. 

Aplicación de Modelos al Caso de Estudio Fundación FES

Caso de estudio Modelo Secuencial Lineal



Fase de Análisis

Requerimientos del Usuario.

Agenda de Eventos:

Lugar y fecha.
Cantidad de participantes.
Invitaciones.
Confirmaciones.
Llenado de datos.
Expositores .
Temas.
Documentos.
Materiales de apoyo.
Refrigerios.


Según lo analizado en el caso de la Fundación Fredrick Ebert Stifford lo que se pretende o lo que ellos requieren automatizar es su agenda de eventos. Dentro del cual se requiere llevar un registro del lugar, fecha de cada evento, la cantidad de participantes que asistirán y de acuerdo a esto hacer las invitaciones, confirmar la asistencia y proceder al llenado de datos.

También se pretende llevar control y registro de los temas, documentos y materiales de apoyo que requieren los expositores así como el menú del evento (refrigerios u otros alimentos).


Fase de Diseño

Caso de Uso : Nivel 1 (Ejemplo 1):



Caso de Uso : (Ejemplo 2):





Diagrama de Clases




Fase Código


Tabla de Participante:
 
create procedure Tabla_Participante
as
create table Participante
(id_participante smallint PRIMARY KEY,
nombre nvarchar(50) NOT NULL,
apellido nvarchar(50),
direccion nvarchar(50),
telefono nchar(10))
GO

Tabla de Comida:


create table Comida
(id_dato smallint PRIMARY KEY,
nombre nvarchar(50) NOT NULL,
descripción nvarchar(50),
Porción nvarchar(50))
GO
 
sp_help Comida

Tabla de Evento:
 
create table Evento
(id_evento smallint PRIMARY KEY,
lugar nvarchar(50),
fecha datetime,
hora nchar(10))
GO
 
sp_help Evento


Fase Prueba








Con la realización de esta prueba se tuvo que usar el software SQL Server 2005 para la validación de las tablas de la base de datos.

Se llego a la conclusión que para la automatización de la agenda de eventos  se requiere la implementación de la base de datos junto con una serie de peticiones realizadas por el usuario para optimizar el control de las actividades.



Modelos de desarrollo del Software

 Modelo Secuencial Lineal

Análisis de los requisitos del software: El proceso de reunión de requisitos se intensifica y se centra especialmente en el software.

Diseño: El diseño del software es realmente un proceso de muchos pasos que se centra en cuatro atributos distintos de programa: estructura de datos, arquitectura de software, representaciones de interfaz y detalle procedimental (algoritmo).

Generación de código: El diseño se debe traducir en una forma legible por la máquina.

Pruebas: El proceso de pruebas se centra en los procesos lógicos internos del software, asegurando que todas las sentencias se han comprobado, y en los procesos externos funcionales.

Mantenimiento: El software indudablemente sufrirá cambios después de ser entregado al cliente (una excepción posible es el software empotrado).



*   
   Modelo de Construcción de Prototipos
El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición.Lo ideal sería que el prototipo sirviera como un mecanismo para identificar los requisitos del software.



Modelo de Desarrollo Rápido de Aplicaciones.(DRA)
Es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto.

Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:

  • Modelado de Gestión.
  • Modelado de datos.
  • Modelado del proceso.
  • Generación de aplicaciones.
 
 
 Modelo Incremental
  
 El modelo incremental combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofía interactiva de construcción de prototipos.

Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial. Como un resultado de utilización y/o de evaluación, se desarrolla un plan para el incremento siguiente.

Modelo Espiral
En el modelo espiral, el software se desarrolla en una serie de versiones incrementales.
El siguiente grafico representa un modelo en espiral que contiene seis regiones de tareas:
  1. comunicación con el cliente
  2. planificación
  3. análisis de riesgos
  4. ingeniería
  5. construcción y acción
  6. evaluación del cliente.
 Modelo de Desarrollo Concurrente


La actividad de análisis (que estaba en el estado ninguno mientras que se iniciaba la comunicación inicial con el cliente) ahora hace una transición al estado bajo desarrollo. Sin embargo, si el cliente indica que se deben hacer cambios en requisitos, la actividad análisis cambia del estado bajo desarrollo al estado cambios en espera.

El modelo de proceso concurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la ingeniería del software. 
Modelo de desarrollo basado en componentes

El proceso de Software

Capas



Dichas capas se describen a continuación:

Cualquier disciplina de ingeniería (incluida la ingeniería del software) debe descansar sobre un esfuerzo de organización de calidad. La gestión total de la calidad y las filosofías similares fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de enfoques cada vez más robustos para la ingeniería del software.

El fundamento de la ingeniería de software es la capa proceso. El proceso define un marco de trabajo para  un conjunto de áreas clave, las cuales forman  la base del control de gestión  de proyectos de software y establecen el contexto en el cual: se aplican los métodos técnicos, se producen resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente.

Los métodos de la ingeniería de software indican cómo construir técnicamente el software.  Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. Estos métodos dependen de un conjunto de principios básicos que gobiernan cada  área de la tecnología e incluyen actividades de modelado y otras técnicas descriptivas.

Las herramientas de la ingeniería del software proporcionan un soporte automático o semi-automático para el proceso y los métodos, a estas herramientas se les llama herramientas CASE (Computer-Aided Software Engineering).


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ónse necesitan para definir un sistema correcto.

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. Los métodos aplicados durante la fase de desarrollo variarán, aunque las tres tareas específicas técnicas deberían ocurrir siempre: diseño del software , generación de código y prueba del software.

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.

 


Actividades Protectoras



  • Revisiones tecnicas formales.
  • Garantía de calidad de sofware.
  • Gestión de configuración de sofware.
  • Preparación y producción de documentos.
  • Gestión de reutilizació.
  • Mediciones.
  • Gestión de riesgos.

Marco de Trabajo Común

viernes, 15 de octubre de 2010

El Producto del Software

Características


Mantenibles:

Debe ser posible que el software evolucione y que siga cumpliendo con sus especificaciones.

Confiabilidad:

El software no debe causar daños físicos o económicos en el caso de fallos.

Eficiencia:

El software no debe desperdiciar los recursos del sistema.

Utilización adecuada:

El software debe contar con una interfaz de usuario adecuada y su documentación.

viernes, 1 de octubre de 2010

Principio de W5HH


El principio WWWWWHH conducen a la definición de las características clave del proyecto y el plan del proyecto resultante:

¿Por qué se desarrolla el sistema?

Dicho de otra forma, ¿justifica el propósito del negocio el gasto en personal, tiempo y dinero? La respuesta a esta pregunta permite a todas las partes evaluar la validez de las razones del negocio para el trabajo del software.

¿Qué se realizará y cuándo?
La respuesta a estas preguntas ayuda al equipo a establecer la planificación del proyecto identificando las tareas clave del proyecto y los hitos requeridos por el cliente.

¿Quién es el responsable de una función?
¿Dónde están situados organizacionalmente? 

No todos los roles y responsabilidades residen en el equipo de software. El cliente, los usuarios, y otros directivos también tienen responsabilidades.

¿Cómo estará realizado el trabajo desde el punto de vista técnico y de gestión?
Una vez establecido el ámbito del producto, se debe definir una estrategia técnica y de gestión para el proyecto.

¿Qué cantidad de cada recurso se necesita?
 La respuesta a esta pregunta se deriva de las estimaciones realizadas basadas en respuestas a las preguntas anteriores.

El principio W5HH de Boehm es aplicable sin tener en cuenta el tamaño o la complejidad del proyecto de software. Las preguntas señaladas proporcionan un perfil de planificación al gestor del proyecto y al equipo de software.