COCOMO

Es un modelo que permite estimar el costo, el esfuerzo, y programar la hora de planificar una nueva actividad de desarrollo de software.

El modelo provee tres “niveles” de aplicación: básico, intermedio y avanzado, basados en los factores considerados por el modelo.

Básico, es un modelo estático simplemente evaluado que calcula el esfuerzo (y costo) del desarrollo del software como función del programa expresado en líneas de código (LDC estimados).

Intermedio, calcula el esfuerzo del desarrollo del software como función del tamaño del programa y un conjunto de “guías de costo” que incluye una evaluación subjetiva del producto, hardware, personal y de los atributos del proyecto.

Avanzado, incorpora todas las características de la versión intermedia con una evaluación del impacto de las vías de costo en cada fase (análisis, diseño, etc) del proceso de la ingeniería de software.

 Las ecuaciones de estimación del esfuerzo de desarrollo tienen la forma

con     

 • S el número de miles de líneas de código fuente

 • m(X) es un multiplicador que depende de 15 atributos

 • en la siguiente tabla se muestran los coeficientes para los diferentes modos

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).

ANÁLISIS ESTRUCTURADO

El análisis estructurado es un método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Cuando los analistas de sistemas abordan una situación poco familiar, siempre existe una pregunta sobre donde comenzar el análisis. Una situación dinámica siempre puede ser vista como abrumadora debido a que muchas de las actividades se llevan a cabo constantemente, como señalo MARY HELEN es su seminario. El análisis estructurado permite el analista conocer un sistema o proceso (actividad) en una forma lógica y manejable el mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente.

             Significado de estructurado

¿qué es lo que desea estructurar? ¿ que significa estructurar? El objetivo que persigue el análisis estructurado es organizar las tareas asociada con la determinación de requerimientos para obtener la comprensión completa y exacta de una situación dada. A partir de aquí determina los requerimientos que serán la base de un sistema nuevo o modificado.

En el análisis estructurado la palabra estructura significa qué: 1) el método intenta estructurar el proceso de determinación de los requerimientos comenzando con la documentación del sistema existente; 2) el proceso está organizado de tal forma que intenta incluir todos los detalles relevante que describe al sistema en uso; 3) es fácil verificar cuando se han omitido detalles relevantes; 4) la identificación de los requerimientos será similar entre varios analistas e incluirá las mejora soluciones y estrategias para las oportunidades para de desarrollo de sistemas; y 5) los documentos de trabajo generados para documentar los sistemas existente o propuesto son dispositivos de comunicación eficientes.

Componentes del análisis estructurado

El análisis estructurado hace uso de los siguientes componentes.

Símbolos gráficos Iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes.

Descripciones de procesos y procedimientos Declaraciones formales que emplean técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema.

Reglas Estándares para describir y documentar el sistema en forma correcta y completa.

El método de análisis estructurado se ha convertido en sinónimo del análisis de flujo de datos, que es una herramienta; quizá esto se deba a que la herramienta es esencial para documentar el sistema existente y determinar los requerimientos de información por medio del método estructurado.

DOCUMENTOS PARA ESPECIFICACIÓN FORMAL DE REQUISITOS

La Especificación de Requisitos Software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso  que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales . Además de los casos de uso, la ERS también contiene requisitos no funcionales  (o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación (Como por ejemplo restricciones en el diseño o estándares de calidad).

Hay muchas técnicas para extraer información útil de documentos escritos en un lenguaje natural que nos permiten construir documentos más precisos y formales, los cuales expresan los requerimientos del sistema de manera menos ambigua. Algunas de estas técnicas incluyen la creación de los casos de uso del sistema. Un caso de uso es una secuencia de acciones que proveen una cierta funcionalidad a un actor del sistema. Un caso de uso describe una manera en la cual un actor del mundo real interactúa con el sistema. Cada una de estas formas de interacción es un evento al cual el sistema deberá dar una respuesta. Podemos entonces establecer una correspondencia entre los casos de uso del sistema y una lista de eventos del sistema.Por otro lado, sabemos de los beneficios de contar con especificaciones formales en las primeras etapas de desarrollo del sistema. Nuestro trabajo consiste en desarrollar una técnica para obtener a partir de un conjunto de casos de uso, bajo la forma de lista de eventos, a una especificación formal inicial escrita en RSL (the RAISE Specification Language) [RLG92, RLM95], consistente en signaturas de funciones de más alto nivel del sistema y tipos expresados como sorts. Cabe destacar que la misma técnica puede ser aplicada para cada caso de uso, para de esta manera derivar no sólo las signaturas sino también el cuerpo de las funciones de más alto nivel del sistema.

En la práctica es común describir los requerimientos en un documentollamado Especificación de Requerimientos del Software (SRS -Software Requirements Specification).

¿Para qué sirve un SRS?

• Comunicar de manera precisa los requerimientos, objetivos y presunciones del dominio

• Contrato

– legal, documento interno o a modo de memorando

• Base para estimación (tamaño, costo, tiempo) y planificación de proyecto

• Base para evaluación de producto final

– verificación y validación

– Debería tener suficiente información para decidir si el producto final es aceptable

(satisface los requerimientos)

• Base para el control de cambios

– Requerimientos cambian, software evoluciona, el entorno evoluciona.

Lectores de un SRS

• Clientes y Usuarios

– Interesados en validar objetivos del sistema y descripción de alto nivel de la funcionalidad

– Generalmente no interesados en los requerimientos detallados del sistema.

• Analistas (de sistemas, de requerimientos),

– Escribirán especificaciones de otros sistemas que interactúan con este.

– El SRS sirve mas allá de la puesta en producción!

• Desarrolladores (ej. arquitectos, diseñadores,programadores, ...)

– Deben implementar los requerimientos

• Testers (V&V’ers)

– Deben determinar la satisfacción de los requerimientos

• Gerentes

– Medir y controlar el proceso desarrollo

ANÁLISIS DE REQUISITOS

El análisis consiste en producir un documento de especificaciones de requisitos que describa lo que el futuro sistema debe hacer, pero no como debe hacerlo.por ello algunos autores lo llaman determinación de requisitos.

Definición : el análisis de requisitos es el proceso de estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema, de hardware o de software; así como su estudio y refinamiento. Requisito : es una condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo. Aplicado a los sistemas es los que debe cumplir o poseer un sistema para satisfacer un contrato, una norma o una especificación

La definición de los requisitos debe ser fruto del trabajo de usuarios y desarrolladores del softw, a través del análisis, esto es así por: el cliente no suele entender el proceso de diseño y desarrollo del softw. Como para redactar una ERS( especificación de requerimientos de softw.) los analistas no suelen entender completamente el problema del cliente.

La fase de análisis de requisitos consta de : Definirlos requisitos de softw .: es una tarea iterativa para crear una especificación preliminar de requisitos, a partir de la información obtenida según las técnicas de recojo de información.(entrevista, JAD) Definir los requisitos de Interfaces : del softw. Con el resto del sistema y el exterior. Como los usuarios, el hardware, otras aplicaciones. La interfaz con el usuario es critica para la facilidad de uso.

Integrar los requisitos: es un documento de especificación y asignarles prioridades. El usuario tiene papel fundamental en la aprobación o no de los mismos. Así mismo se asigna prioridades en función de su importancia otra manera de describir las actividades que se realiza en la fase de análisis de requisitos es: Extracción o determinación de requisitos: los clientes descubren revelan, comprenden los requisitos que desean.

Análisis de Requisitos : proceso de razonamiento sobre los requisitos obtenidos en la etapa anterior, resolviendo posibles inconsistencias Especificación de Requisitos . El proceso de registro de los requisitos, para lo que se puede recurrir al lenguaje natural, gráficos etc. Validación de los requisitos .: los usuarios confirman que los requisitos especificados son validos, consistentes, completos.

Estas actividades no tienen que realizarse en secuencia ya que hay continuas iteraciones y solapamientos entre ellas, su realización se apoyan en diferentes técnicas así: para la extracción o determinación de requisitos se emplea técnicas de recogida de información (JAD, entrevistas etc). Para el análisis y la especificación existen técnicas gráficas (DFD), análisis estructurado

Para la validación se recurre a la lista de comprobación de distintos aspectos de las especificaciones que suelen usarse con técnicas de revisión.

Especificación: Documento que define, de forma completa, precisa y verificable, los  requisitos, el diseño, el comportamiento u otras características de un sistema o de un componente de un sistema.

Software: Conjunto de programas, procedimientos y documentación asociada a la operación de un sistema informático.

Con estas premisas puede definirse la Especificación de Requisitos del Software (ERS) como la documentación de los requisitos esenciales (funciones, rendimiento, diseño, restricciones y atributos) del software y de sus interfaces externas [IEEE,1990]. Las dos características fundamentales de una ERS eficaz son: Incluir información veraz, es decir, coherente con las necesidades reales del usuario que se desean satisfacer. Comunicar dicha información de forma veraz, es decir, de tal manera que se pueda comprender perfectamente  Las exigencias para una ERS conducen a no excederse a la hora de definirla y construirla, sino mas bien a abordar la descripción de lo que hay que desarrollar, no el cómo, el cuándo, etc. Se desarrolla el software. Esto implica:

Describir correctamente todos los requisitos de software sin incluir requisitos necesarios.

ACTIVIDADES INICIALES PARA RECOLECCIÓN DE INFORMACIÓN

Contempla cuatro niveles (ver cuadro). Los primeros dos niveles, el epistemológico y el teórico, se desarrollan en los módulos 2 y 5. El nivel metodológico corresponde a la definición: del tipo de estudio (exploratorio, descriptivo, explicativo), del método de investigación (observación, inducción, deducción, análisis, síntesis), de técnicas y procedimientos para la recolección de la información (encuestas, entrevista, etc.) y al tratamiento que se va a dar a la información

INFORMACIÓN PRIMARIA Y SECUNDARIA

Sucede con frecuencia, en cualquier tipo de investigación, que se recoge todo un conjunto de datos que más tarde se someten a un análisis cuidadoso o a un comentario interpretativo. Por ejemplo, en una investigación clínica o médica las observaciones que tienen el carácter de historias de casos, han sido recolectadas durante un largo tiempo y sólo posteriormente el investigador las analiza y las interpreta.

También puede suceder que un economista desee investigar el problema

del desempleo en Colombia durante los últimos diez años. Para ganar tiempo y dinero, el economista decide examinar los datos del desempleo que durante esa época recolectó el DANE, a través de sus encuestas,sobre empleo y desempleo; con base en esos datos recogidos de antemanohace su propia investigación.

Información primaria: Es aquella que el investigador recoge directamentea través de un contacto inmediato con su objeto de análisis.

Información secundaria: Es aquella que el investigador recoge a partir de investigaciones ya hechas por otros investigadores con propósitos diferentes.

TÉCNICAS DE RECOLECCIÓN DE LA INFORMACIÓN

OBSERVACION es una situacion real, clasificando y consignando los acontecimientos pertenecientes de acuerdo con algún esquema previsto y Según el problema que se estudia Al igual con los otros métodos, previamente a la ejecución de la observación el investigador debe definir los objetivos que persigue, determinar su unidad de observación, las condiciones en que asumirá la observación y las conductas que deberán registrarse.Cuando se decide utilizarla hay que tomar en cuenta ciertas consideraciones. Como método de recolección de datos, debe ser planificado cuidadosamente para que reúna los requisitos de validez y confiabilidad. Se le debe conducir de manera hábil y sistemática y tener destreza en el registro de datos, diferenciando los aspectos significativos de la situación y los que no tienen importancia.

Encuesta.- Este método consiste en obtener información de los sujetos de estudio, proporcionada por ellos mismos, sobre opiniones, actitudes o sugerencias. Hay dos maneras de obtener la entrevista y el cuestionario

Entrevista.-Es la comunicación establecida entre el investigador y el sujeto de estudiado a fin de obtener respuestas verbales a las interrogantes planteadas sobre el problema propuesto.

Mapa de procesos.-Este ofrece una visión general de una sistema de gestión. en el que se representan los procesos que componen el sistema así como sus relaciones principales.

Diagramas de flujo.- Es una representación gráfica de un algoritmo. Se utiliza en disciplinas como la programación, la economía, los procesos industriales y la psicología cognitiva  Estos diagramas utilizan símbolos con significados bien definidos que representan los pasos del algoritmo, y representan el flujo de ejecución mediante flechas que conectan los puntos de inicio y de término.

Cuestionario.-Es el método que utiliza un instrumento o formulario impreso, destinado a obtener repuestas sobre el problema en estudio y que el investido o consultado llena por si mismo.

Diagrama de gannt.- Es una herramienta gráfica cuyo objetivo es mostrar el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado

BIBLIOGRAFIA:http://www.slideshare.net/erikamolina/metodos-para-recolectar informacion

CALIDAD EN EL DESARROLLO DEL SOFTWARE

la calidad, al igual que la belleza, está en el ojo de quien lo mira sin embargo, desde el punto de vista de medición, se debe tener una definición precisa en términos de atributos del software que sean dññe interés al usuario en general, éstos son atributos externos sin embargo, muchas propuestas miden y analizan atributos internos.

Primero definamos la calidad como la medida en que un producto satisface el requerimiento del cliente.

Uno de los problemas que han permanecido actualmente en el mundo de la computación es la calidad del software. Este tema ha sido motivo de preocupación para especialistas, ingenieros, investigadores y comercializadores de software, los cuales han realizado gran cantidad de investigaciones con dos objetivos fundamentales:

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

OJO

No existe modelo; cada caso es diferente, cada mercado es distinto y cada orientación (proyectos o productos) hace que no orientación (proyectos o productos) hace que no exista un ejemplo de referencia.

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

La documentación para desarrolladores es aquélla que se utiliza para el propio desarrollo del producto y, sobre todo, para su mantenimiento futuro. Se documenta para comunicar estructura y comportamiento del sistema o de sus partes, para visualizar y controlar la arquitectura del sistema, para comprender mejor el mismo y para controlar el riesgo, entre otras cosas. Obviamente, cuanto más complejo es el sistema, más importante es la documentación.

Buena parte de la documentación para los usuarios puede empezar a generarse desde que comienza el estudio de requisitos del sistema. Esto está bastante en consonancia con las ideas de extreme programming y con metodologías basadas en casos de uso.

La documentación para administradores o soporte técnico, a veces llamada manual de operaciones, contiene toda la información sobre el sistema terminado que no hace al uso por un usuario final. Es necesario que tenga una descripción de los errores posibles del sistema, así como los procedimientos de recuperación. Como esto no es algo estático, pues la aparición de nuevos errores, problemas de compatibilidad y demás nunca se puede descartar, en general el manual de operaciones es un documento que va engrosándose con el tiempo.