viernes, 24 de mayo de 2013

El Modelo COCOMO

El Modelo "COCOMO"

El Modelo Constructivo de Costes (Constructive Cost Model) fue desarrollado por B. W. Boehm a finales de los 70 y comienzos de los 80, exponiéndolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981). COCOMO es una jerarquía de modelos de estimación de costes software que incluye submodelos básico, intermedio y detallado.

Pertenece a la categoría de modelos de sub-estimaciones basados en estimaciones matemáticas. Está orientado a la magnitud del producto final, midiendo el "tamaño" del proyecto, en líneas de código principalmente.

Modelo Básico

Este modelo trata de estimar, de una manera rápida y más o menos burda, la mayoría de proyectos pequeños y medianos. 
Se consideran tres modos de desarrollo en este modelo: orgánico, semiencajado y empotrado.

Modo orgánico
En este modo, un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. 
El tamaño del software varía de unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles de líneas (medio), mientras que en los otros dos modos el tamaño varía de pequeño a muy grandes (varios cientos de miles de líneas). En este modo, al igual que en los otros, el coste se incrementa a medida que el tamaño lo hace, y el tiempo de desarrollo se alarga.

Modo Empotrado
En este modo, el proyecto tiene unas fuertes restricciones, que pueden estar relacionadas con el procesador y la interface  del hardware. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla.

 Modo Semiencajado
Es un modo intermedio entre los dos anteriores. Dependiendo del problema, el grupo puede incluir una mezcla de personas experimentadas y no experimentadas.

Modelo Intermedio

En este modelo se introducen 15 atributos de coste para tener en cuenta el entorno de trabajo. Estos atributos se utilizan para ajustar el coste nominal del proyecto al entorno real, incrementando la precisión de la estimación.

Modelo Detallado

Este modelo puede procesar todas las características del proyecto para construir una estimación. Introduce dos características principales
1. Multiplicadores de esfuerzo sensitivos a la fase. Algunas fases se ven más afectadas que otras por los atributos. El modelo detallado proporciona un conjunto de multiplicadores de esfuerzo para cada atributo. Esto ayuda a determinar la asignación del personal para cada fase del proyecto.
2. Jerarquía del producto a tres niveles. Se definen tres niveles de producto. Estos son módulo, subsistema y sistema. La cuantificación se realiza al nivel apropiado, esto es, al nivel al que es más susceptible la variación.

Es uno de los modelos más documentados en la actualidad y es muy fácil de utilizar. Es correcto con referencia a los 63 proyectos utilizados, aunque de ello no se debe desprender que deba ser válido siempre. Una preocupación es la adaptación de las ecuaciones exponenciales a organizaciones específicas, cosa que no parece inmediatamente fácil.



Actividades iniciales para recolección de información

Actividades iniciales para recolección de información

Principios generales para las actividades de recolección de datos


La recolección de la información depende en gran medida del tipo de investigación y el problema que se estudia. Esta fase del trabajo incluye: seleccionar un instrumento de medición válido y confiable, aplicar el instrumento y codificar los mediciones o datos.

La medición requiere que se defina tanto lo que se está midiendo y también la manera como se hace, con el fin de que los lectores del informe de investigación sepan de lo que se está hablando.

Susan Pick (1992) señala que las mediciones pueden ser alteradas por diversos factores de los cuales menciona:
● Las características psicológicas, sociales, económicas, físicas, particulares de cada sujeto.
● Los problemas personales de índole pasajera.
● Las circunstancias especiales.
●Las diferencias en la administración de cuestionarios o entrevistas causadas por los entrevistadores.

Para facilitar la adecuada recolección de información mediante las técnicas aludidas, se recomienda el seguimiento de algunas pautas generales, entre ellas:
1. El estudio cuidadoso de este manual, que oriente la recolección de información y asegure que las categorías sean cubiertas mediante la aplicación de las técnicas.
2. La utilización de las guías de observación y de entrevistas que se ofrecen.
3. Los docentes y alumnos que van a ser sujetos de observación y de entrevistas deben ser informados de los motivos y las intenciones de la investigación, la posibilidad de utilizar la grabadora, cámara fotográfica o video grabadora, además, del lugar y del momento de las actividades de recolección de información.
4. La gestión de la observaciones y de entrevistas debe garantizar, hasta donde sea posible, una realización ininterrumpida y con la total atención del investigador (en este sentido, es indispensable apagar el celular).
5. La garantía, ante los sujetos observados y entrevistados, que los investigadores.


Metodologías para el desarrollo de software


Metodologías para el desarrollo de software

CONCEPTOS GENERALES

Metodología: Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software.

Tarea: Actividades elementales en que se dividen los procesos.

Procedimiento: Definición de la forma de ejecutar la tarea.

Técnica: Herramienta utilizada para aplicar un procedimiento. 
Se pueden utilizar una o varias.

Herramienta: Para realizar una técnica, podemos apoyarnos en las herramientas software que automatizan su aplicación.

Producto: Resultado de cada etapa.

METODOLOGÍA Vs CICLO DE VIDA

El ciclo de vida indica qué es lo que hay que obtener a lo largo del desarrollo del proyecto pero no cómo hacerlo. La metodología indica cómo hay que  obtener los distintos productos parciales y finales.

GENERACIONES DE METODOLOGÍA 
  • Desarrollo Convencional (Sin Metodología) .
  • Desarrollo Estructurado.
  • Desarrollo Orientado a Objetos.

CARACTERÍSTICAS DESEABLES DE UNA METODOLOGÍA
  • Existencia de reglas predefinidas
  •  Cobertura total del ciclo de desarrollo
  •  Verificaciones intermedias
  •  Planificación y control
  •  Comunicación efectiva
  •  Utilización sobre un abanico amplio de proyectos
  •  Fácil formación
  •  Herramientas CASE
  •  Actividades que mejoren el proceso de desarrollo
  •  Soporte al mantenimiento
  •  Soporte de la reutilización de software


El Proceso Unificado de Desarrollo de Software (RUP)


El Proceso Unificado es un proceso de software genérico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos.

Provee un enfoque disciplinado en la asignación de tareas y responsabilidades dentro de una organización de desarrollo. Su meta es asegurar la producción de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible.

Los conceptos anteriormente tratados dirigido por casos de uso, centrado en arquitectura, desarrollo iterativo e incremental son igualmente importantes. 
La arquitectura provee la estructura sobre la cual guiar el trabajo en interacciones  mientras que los casos de uso definen las metas y dirigen el trabajo en cada interacción. 
Remover cualquiera de estos conceptos reducirá severamente el valor del Proceso Unificado. Es como una mesa de tres patas, sin alguna de ellas, la mesa se caerá.


METODOLOGIA XP

La programación extrema es una metodología de desarrollo ligero (o ágil) basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas.
Este modelo de programación se basa en una serie de metodologías de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay alrededor de la programación.
Una de las características principales de este método de programación, es que sus ingredientes son conocidos desde el principio de la informática. Los autores de XP han seleccionado aquellos que han considerado mejores y han profundizado en sus relaciones y en cómo se refuerzan los unos con los otros. El resultado de esta selección ha sido esta metodología única y compacta. Por esto, aunque no está basada en principios nuevos, sí que el resultado es una nueva manera de ver el desarrollo de software.
El objetivo que se perseguía en el momento de crear esta metodología era la búsqueda de un método que hiciera que los desarrollos fueran más sencillos. Aplicando el sentido común.










Documentación durante el desarrollo del software


Documentación durante el desarrollo del software


En general se habla mucho de la documentación, pero no se la hace, no se le asigna presupuesto, no se la mantiene y casi nunca  está al día en los proyectos de desarrollo de software.

Lo importante es la disponibilidad de la documentación que se necesita en el momento en que se la necesita.

Muchas veces se hace porque hay que hacerla y se escribe, con pocas ganas, largos textos, a la vez que se está convencido de estar haciendo un trabajo inútil. A veces se peca por exceso y otras por defecto. Ocurre mucho en la Web y con productos RAD. En ocasiones se olvida que el mantenimiento también debe llegar a la documentación.

La documentación se suele clasificar en función de las personas o grupos a los cuales está
dirigida:
· Documentación para los desarrolladores
· Documentación para los usuarios
· Documentación para los administradores o soporte técnico

LAS PRUEBAS EN EL DESARROLLO DE SOFTWARE


La calidad no es algo que se pueda agregar al software después de desarrollado si no se hizo todo el desarrollo con la calidad en mente. 

Muchas veces parece que el software de calidad es aquél que brinda lo que se necesita con adecuada velocidad de procesamiento.

Desde el punto de vista de la programación, nos interesa la ausencia de errores
(corrección), la confiabilidad y la eficiencia. Dejando de lado las dos últimas, nos concentraremos en
este capítulo en las pruebas que determinen que un programa está libre de errores.


Categorías de pruebas


Según la naturaleza de lo que se esté controlando, las pruebas se pueden dividir en dos categorías:
· Pruebas centradas en la verificación
· Pruebas centradas en la validación
Las primeras sirven para determinar la consistencia entre los requerimientos y el programa terminado. Soporta metodologías formales de testeo, de mucho componente matemático. De todas maneras, hay que ser cuidadoso, porque no suele ser fácil encontrar qué es lo que hay que demostrar. La verificación consiste en determinar si estamos construyendo el sistema correctamente, a partir de los requisitos.


En general a los informáticos no les gustan las pruebas formales, en parte porque no las entienden y en parte porque requieren un proceso matemático relativamente complejo.



La validación consiste en saber si estamos construyendo el sistema correcto. Las tareas de validación son más informales. Las pruebas suelen mostrar la presencia de errores, pero nunca demuestran su ausencia.






Paginas Consultadas

http://materias.fi.uba.ar/7507/content/20101/lecturas/documentacion_pruebas.pdf



Calidad en el desarrollo del software


Calidad en el desarrollo del software

Calidad suele significar el conjunto de las cualidades. Cuando se dice que un caballo es de buena calidad, se da a entender que posee todas las cualidades entender que posee todas las cualidades que constituyen el caballo bueno. 

Por esta razón llamamos calidad y no esta razón llamamos calidad, y no cualidad."

El software, tanto en su vertiente de producto como de aplicación, conlleva una serie de especificidades con relación a la calidad.

Funcionamiento

Sería el nivel más bajo, asumido. El software debe funcionar siempre en todo momento debe funcionar siempre, en todo momento; debe permitimos utilizarlo cuando sea necesario. 

Funcionalidad

Sería el siguiente nivel, intermedio. El software deberá cubrir las funcionalidades software deberá cubrir las funcionalidades que publica; en resumen, debe hacer lo que dice que hace.

Usabilidad

Sería el nivel superior. No sólo un software debe hacer lo que dice que hace también debe hacer lo que dice que hace; también debe permitimos hacerlo de forma adecuada, natural. 

Debemos tener en cuenta que la consecuencia de un proceso es asegurar la calidad pero nunca es el objetivo final. La calidad de software no se certifica, lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en función de la normalización (ISO 9000, CMMI, Moprosoft...).

¿Cómo evaluar la calidad del software?

Desde el punto de vista del cliente, calidad del software es el grado en que un cliente o usuario percibe que el producto software satisface sus necesidades. Desde el punto de vista industrial del producto, calidad del software es la habilidad de un producto software de satisfacer una especificación de requerimientos.

A la hora de definir la calidad del software es importante diferenciar entre la calidad del PRODUCTO software y la calidad del PROCESO de desarrollo de éste (calidad de diseño y fabricación). Las metas que se establezcan para la calidad del producto van a determinar las que se establecen para la calidad del proceso de desarrollo, a la vez que la calidad que se espera del producto esta determinada por la calidad de los procesos.

Análisis

Entonces concluyendo esta edición podemos interpretar que hay varios puntos desde donde se analiza la calidad de un proyecto de software, desde el lado de los procesos, y desde el lado del funcionamiento global del software. Ya que como nos confirman el texto anterior ambas van enlazadas en una excelencia de calidad como resultado global de nuestro PROYECTO DE SOFTWARE.

Paginas Consultadas:








jueves, 23 de mayo de 2013

Análisis de requisitos


Análisis de requisitos


La ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refinan en detalle los requisitos del sistema y el papel asignado al software.

El análisis y la especificación de requisitos pueden parecer una tarea relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para malas interpretaciones o falta de información. 
Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero de software puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir”.

El análisis de requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño de software. El análisis de requerimientos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.

División del análisis.
  1. Reconocimiento del problema
  2. Evaluación y síntesis
  3. Modelado
  4. Especificación
  5. Revisión
    Funciones y habilidades del analista
       
   La función principal de un analista del software (o ingeniero de requisitos es llevar a cabo las actividades necesarias para cumplir con las cinco áreas de esfuerzo descritas en la sección anterior. Para lo cual hace uso de las siguientes técnicas :
    -Entrevistas
    -Talleres
    -Observación
    -Encuestas
    -Revisión documental
  -Uso de especificaciones formales para requerimientos (formatos estándar de documentos, UML, etc.)
    
    Tipos de requisitos
     
  Requisitos funcionales: Describen las interacciones entre el sistema y su ambiente, en forma independiente a su implementación. El ambiente incluye al usuario y cualquier otro sistema externo con el cual interactúe el sistema.
Requisitos no funcionales: Describen atributos sólo del sistema o del ambiente del sistema que no están relacionados directamente con los requisitos funcionales. Los requisitos no funcionales incluyen restricciones cuantitativas, como el tiempo de respuesta o precisión, tipo de plataforma (lenguajes de programación y/o sistemas operativos, etc.)












Técnicas de recolección de la información


Técnicas de recolección de la información


Existen 3 métodos interactivos que se pueden utilizar para la obtención de los requerimientos de información de los miembros de la organización. Dichos métodos son las entrevistas, el diseño conjunto de aplicaciones y la realización de encuestas mediante cuestionarios. La base de los métodos está en preguntas formuladas cuidadosamente.Cada uno de los métodos para la recuperación de información tiene su propio proceso para interactuar con los usuarios. 
Si se siguen estos enfoques ayudarán a garantizar el diseño y la implementación apropiados de entrevistas y cuestionarios.



ENTREVISTAS

Una entrevista es una conversación dirigida con un propósito específico que utiliza un formato de preguntas y respuestas. En la entrevista necesitamos obtener las opciones de los entrevistados y su parecer acerca del estado actual del sistema, metas organizacionales y personales y procedimientos informales.Además se debe tratar de captar los sentimientos de los entrevistados, y con ello,poder entender la cultura de la organización de una manera más compleja. Se debe de tratar de averiguar lo más que se pueda acerca de las metas de la organización por medio de las entrevistas; y dentro de ella, nosotros debemos de establecer un ambiente de confianza y de entendimiento rápidamente, pero al mismo tiempo, llevar el control de la entrevista.

Pasos para preparar una entrevista:

  • Leer los antecedentes.
  • Establecer los objetivos de la entrevista
  • Decidir a quien entrevistar
  • Preparar al entrevistado
  • Decidir el tipo de preguntas y el estructurado de las mismas.
CUESTIONARIOS

El uso de los cuestionarios es una técnica de recopilación de información que permite a los analistas de sistemas estudiar las actitudes, creencias, comportamiento y características de personas importantes dentro de la organización que podrían resultar afectadas por los sistemas actuales y los propuestos.

Al usar los cuestionarios, el analista podría estar buscando cuantificar lo que se haya descubierto con la entrevista. Por otra parte los cuestionarios se pueden usar para encuestar a una muestra considerable de usuarios de sistemas con el fin de detectar problemas o poner de manifiesto cuestiones importantes. La plantación de los cuestionarios implica una considerable cantidad de tiempo de planeación.


Análisis Personal

Determinando cada uno de los temas visto en este capitulo, damos cuenta que existe una vital importancia en cuanto al desarrollo de un software y su posterior evaluación en el mundo global de su resultado final, ya que debemos abarcar cada uno de estos temas, y hacer uso de manera correcta ya que para cada uno de los desarrollos y dependiendo de la factibilidad de nuestro proyecto entrará en uso ya sea la ENTREVISTA, la OBSERVACIÓN  o cualquiera de los diferentes métodos que tenemos por mencionar los principales.

Sabiendo también, relacionar con cada técnica o método las herramientas que usaremos en cada uno de los casos, ya que dentro de este contexto no debemos confundir un método o una técnica con una herramienta. Por ejemplo:

Si queremos ir a almorzar, y nos sirven un plato de pasta usaremos nuestra herramienta que seria un tenedor, y una técnica que seria la de digerir el alimento.


Paginas consultadas