viernes, 23 de noviembre de 2007
viernes, 16 de noviembre de 2007
Descargue Mi recopliacion de las actividades....
Se llama yo.PDF, pero es de martin Arroyo (yo)
>>> Download
Se llama yo.PDF, pero es de martin Arroyo (yo)
>>> Download
martes, 16 de octubre de 2007
Análisis y Modelado de Software: Roles
Validación y Verificación
Definición de la Validación y la Verificación
La validación es el proceso de evaluación del software al final de su proceso de desarrollo para asegurarse que está libre de fallas y cumple con sus requisitos.
La verificación se refiere al proceso de determinar si el producto en una determinada fase del proceso de desarrollo cumple con los requisitos establecidos en la fase anterior.
Objetivos
El objetivo principal del proceso de V&V es el de analizar y testear el software en forma completa durante el desarrollo para determinar que el software ejecute sus funcionalidad correctamente.
Asegurarse que no ejecute funciones no definidas, y proveer información sobre su calidad y confiabilidad.
Evaluar cuan bien el software está cumpliendo con sus requisitos técnicos y sus objetivos de seguridad y confiabilidad relativos al sistema.
Las tareas de la V&V de software son analizar, revisar, demostrar y testear todas las salidas del desarrollo de software.
Identificación de Objetivos
Correctitud: En que grado el producto está libre de fallas.
Consistencia: En que grado el producto es consistente consigo mismo y con otros productos.
Necesidad: En que grado lo que hay en el producto es necesario.
Suficiencia: En que grado el producto es completo.
Rendimiento: En que grado el producto satisface los requisitos de rendimiento.
Limitaciones
Fundamentos teóricos.
No resulta práctico probar todos los datos.
No resulta práctico probar todos los caminos posibles en el software.
No es posible realizar una prueba de correctitud absoluta.
Relación con otros roles
Analista: El ingeniero de V&V tiene la responsabilidad de verificar que el analista especifica correctamente los requisitos de usuario y de software.
Diseñador: El ingeniero de V&V debe evaluar el nivel de concordancia entre los requisitos de usuario y el modelo diseñado del sistema, buscando errores de interpretación en los requisitos, y características faltantes o mal concebidas.
Programador: El ingeniero de V&V debe verificar la correctitud del proceso de traducción de diseño de software a su implementación en código.
Téster: Se requiere coordinación con este rol en la ejecución de los casos de tests, de acuerdo con las necesidades del cliente.
Ingeniero de manutención: El ingeniero de V&V requiere realizar chequeos periódicos para asegurarse que la integridad del sistema se mantiene, que los cambios que afectan su operación han sido documentados, y los operadores han recibido entrenamiento en procedimientos nuevos o que han cambiado.
Actividades Y Metas
Administración de V&V de software: El proceso requiere ser administrado y realizado en forma completa durante todo el proceso de desarrollo de software.
Planificación: Planificar y mantener el proceso de V&V.
Coordinación: Coordinar e interpretar rendimiento y calidad del esfuerzo del proceso de V&V.
Reportar: Reportar discrepancias a la brevedad posible al usuario o al grupo de desarrollo.
Monitoreo: Identificar tempranamente caminos de problemas, focalizando las tareas de V&V en ellos.
Evaluación de resultados: Proveer una evaluación técnica del rendimiento del software y sus atributos de calidad en cada revisión de software.
Evaluación del impacto del cambio: Determinar el impacto completo de los cambios de software propuestos.
Monitoreo del progreso técnico de V&V y calidad de resultados: Durante cada actividad de V&V, se debe revisar las tareas planificadas de V&V, incluyendo nuevas para mantenerse focalizado en las funciones críticas de rendimiento y calidad del software.
Examinar documentación temprana del proyecto: Muchas veces los llamados documentos conceptuales, para verificar que el sistema que se construirá no es sólo posible, pero que además utiliza las reglas, convenciones, algoritmos y prácticas apropiadas al dominio de aplicación del sistema.
V&V de los requisitos de usuario: Realizado para asegurarse que los requisitos de usuario especificados son correctos, completos, consistentes, fieles, legibles y es posible testearlos, y que además, satisfacerán los requisitos de software.
V&V de los requisitos de software: Realizado para asegurarse que los requisitos de software especificados son correctos, completos, consistentes, fieles, legibles, es posible mapearlos desde los requisitos de usuario y es posible testearlos, y que además, satisfacerán los requisitos de diseño.
V&V del diseño de software: Provee seguridad de que los requisitos de software no son mal interpretados o implementados en forma incompleta.
V&V del código: Asegurarse que se utilicen los estándares en uso, que usualmente consideran programación estructurada, reuso de código, adopción de estándares y estilos de programación, etc.
Administración de tests: Una actividad importante en la actividad de V&V es la de asegurarse que se consideren y planifiquen todos los testeos requeridos para el sistema.
V&V de la transferencia: Asegurarse que se consideren todos los detalles de la instalación y puesta en marcha del sistema, así como la migración y/o poblamiento de sus datos y posibles problemas de eficiencia que empiezan a aparecer.
V&V de la operación y manutención Cuando se realiza un cambio en el software, en necesario repetir todas las actividades de V&V pertinentes para asegurarse que nada queda fuera.
Manutención
Definición de Manutención
La manutención es la última fase del proceso de desarrollo de software. Sin embargo, la manutención toma una parte importante del presupuesto destinado al desarrollo. Por otro lado, a medida que se desarrollan más programas, la cantidad de esfuerzo y recursos dedicados a la manutención crecerá.
Objetivos
Modificar el software para adaptar nuevas funciones o modificar algunas funciones existentes.
Modernizar el software por medio de cambios al sistema.
Asegurarse de que el equipo de desarrollo esté informado de los errores encontrados en el sistema.
Actividades y Metas
Manutención correctiva: Diagnóstico y corrección de errores encontrados durante el uso del programa.
Manutención adaptiva: Adaptar el sistema a los cambios que pueden producirse en el hardware, sistema operativo, periféricos y herramientas de trabajo.
Manutención perfectiva: Satisfacer la demanda de recomendaciones por parte de los usuarios del sistema.
Relación con otros roles
Administrador de proyecto: Debe supervisar y controlar los cambios requeridos, utilizando los estándares del proyecto.
Analista: Debido a que probablemente será necesario adaptar o perfeccionar el sistema durante el tiempo, los analistas requerirán determinar nuevos requisitos.
Diseñador: Es necesario involucrar al diseñador para rediseñar las partes del sistema que requieren ser corregidas, agregadas o perfeccionadas.
Programador: La naturaleza de las actividades requeridas para cubrir la fase de manutención está estrechamente ligada con el rol de programador.
Téster: Debe testear las partes que han sido modificadas para chequear si están adecuadas para ser liberadas como parte del sistema.
Asegurador de calidad: Es responsable de asegurar que el resultado del producto es de la calidad definida por el estándar en uso.
Validación y verificación: Es responsable de revisar que el cliente quede completamente satisfecho con el producto entregado.
Herramientas de apoyo
El ingeniero de manutención debe utilizar para realizar su labor, una herramienta que le permita capturar requisitos de manutención, y además controlar la organización de la manutención dentro del proyecto.
Perfil
El perfil del ingeniero de manutención, como es el caso de otras formas de administración, requiere de la creación y preservación de una atmósfera adecuada que permita llevar a cabo las actividades de la mejor forma posible.
Plan de Trabajo
Planificación y coordinación de la organización de manutención durante el proyecto.
Definición de procedimientos de evaluación e información.
Desarrollo de herramientas para administrar los requisitos de manutención.
Definición de una secuencia estándar de eventos para cada requisito de manutención.
Definición de un sistema de registro e información de las actividades de manutención y organización de la manutención.
Documentación
Definición de la Documentación
La documentación se clasifica en dos:
Documentación de procesos. Los documentos pertenecientes a esta categoría registran la información del proceso de desarrollo y manutención del sistema. El objetivo de esta documentación es hacer “visible” el proceso de desarrollo,
manteniendo información sobre planificación, reportes, estándares, etc.
Documentación de producto. Estos documentos describen el desarrollo del
producto desde los puntos de vista técnico (documentación de sistema) y
usuario del sistema (documentación de usuario), siendo el usuario un usuario
final o un usuario administrador del sistema.
Objetivos
Permitir el almacenamiento y recuperación de la documentación de los procesos y productos más recientes durante el desarrollo, manteniendo así la información al día.
Mantener la consistencia en la apariencia y estructura de los documentos.
Asegurarse que los cambios que necesitan hacerse en el sistema serán reflejados en la documentación correspondiente.
Elaborar, almacenar y permitir la recuperación de las actas y registros
generados durante las reuniones de revisión.
Construir el manual de usuarios del sistema, MUS, que contempla los aspectos de uso del sistema.
Actividades y Metas
Diseñar y construir un repositorio de información compartido, donde se almacenará la documentación.
Tener accesible y organizada la última versión de todos los documentos generados durante el proceso de desarrollo, en un repositorio común.
Especificar el formato que será usado para elaborar la documentación.
Asegurarse que los documentos mantienen el estándar de documentación definido para el proyecto antes de incluirlos en el repositorio.
Toda la información almacenada en el repositorio tendrá el formato definido, y se ajustará al estándar de documentación en uso.
Durante las reuniones de revisiones, el documentador elaborará las actas de la reunión.
Estos documentos serán usados luego por el ingeniero de validación y verificación.
Es necesario mantener la historia del proyecto en el repositorio. Al término del proyecto, el repositorio contendrá toda la información histórica del proyecto.
Relación con otros roles
Administrador de proyecto: La información del repositorio ayuda al administrador a realizar los planes, agenda y presupuestos del proceso de desarrollo de software.
Administrador de configuración: El administrador de configuración y documentador comparten documentación a través del repositorio. Cuando se autoriza un cambio de un documento, debe ser reflejado en el sistema de
Administración de documentos. El propósito de esto es evitar inconsistencias y permitir al equipo de desarrollo el acceso a la versión más reciente de cada documento.
Validación y verificación: El documentador mantiene una relación con el ingeniero de V&V a través del registro elaborado durante las reuniones de revisión.
Asegurador de calidad: A los aseguradores de calidad se les ha confiado que garanticen la calidad del producto a ser desarrollado.
Ingeniero de manutención: La documentación generada durante el desarrollo del producto es usado durante la fase de operación y manutención del sistema.
Herramientas de apoyo
Editor de texto, que permite elaborar documentos fácilmente y almacenarlos en
diferentes formatos, incluyendo HTML. Debe incluir una herramienta para el
chequeo ortográfico y de gramática.
Navegador Web y editor HTML, que permita editar y publicar documentos
HTML, proveyendo diversas funciones.
Perfil
El documentador debe ser una persona ordenada, con capacidades de mantener una
gran cantidad de información en forma ordenada y accesible. Todo el contenido de los
documentos debe ser organizado en forma clara. Esta claridad debe ser consecuencia
del formato en que se presenta la información. El documentador debe poseer
capacidades para no sólo apoyar su trabajo con tecnología, sino que además, deberá
diseñar y construir el repositorio para la documentación del proyecto. Esto incluye, al
menos, la definición del modelo de datos, definición de las interfaces, definición de los
perfiles de acceso de los usuarios, y la definición del protocolo social de uso de los
documentos.
Plan de Trabajo
Definir su formato.
Diseño y elaboración del repositorio central usado para almacenar información:
Análisis de las características deseadas del repositorio.
Estudio de las herramientas que serán usadas para elaborar el repositorio.
Elaborar el diseño lógico de la base de datos.
Construir el repositorio.
Incluir un puntero entre la base de datos y el sitio Web del proyecto, en caso que sean diferentes.
Elaboración de las actas de reunión y documentos de acuerdo:
Almacenamiento de los documentos generados:
Definición de la Validación y la Verificación
La validación es el proceso de evaluación del software al final de su proceso de desarrollo para asegurarse que está libre de fallas y cumple con sus requisitos.
La verificación se refiere al proceso de determinar si el producto en una determinada fase del proceso de desarrollo cumple con los requisitos establecidos en la fase anterior.
Objetivos
El objetivo principal del proceso de V&V es el de analizar y testear el software en forma completa durante el desarrollo para determinar que el software ejecute sus funcionalidad correctamente.
Asegurarse que no ejecute funciones no definidas, y proveer información sobre su calidad y confiabilidad.
Evaluar cuan bien el software está cumpliendo con sus requisitos técnicos y sus objetivos de seguridad y confiabilidad relativos al sistema.
Las tareas de la V&V de software son analizar, revisar, demostrar y testear todas las salidas del desarrollo de software.
Identificación de Objetivos
Correctitud: En que grado el producto está libre de fallas.
Consistencia: En que grado el producto es consistente consigo mismo y con otros productos.
Necesidad: En que grado lo que hay en el producto es necesario.
Suficiencia: En que grado el producto es completo.
Rendimiento: En que grado el producto satisface los requisitos de rendimiento.
Limitaciones
Fundamentos teóricos.
No resulta práctico probar todos los datos.
No resulta práctico probar todos los caminos posibles en el software.
No es posible realizar una prueba de correctitud absoluta.
Relación con otros roles
Analista: El ingeniero de V&V tiene la responsabilidad de verificar que el analista especifica correctamente los requisitos de usuario y de software.
Diseñador: El ingeniero de V&V debe evaluar el nivel de concordancia entre los requisitos de usuario y el modelo diseñado del sistema, buscando errores de interpretación en los requisitos, y características faltantes o mal concebidas.
Programador: El ingeniero de V&V debe verificar la correctitud del proceso de traducción de diseño de software a su implementación en código.
Téster: Se requiere coordinación con este rol en la ejecución de los casos de tests, de acuerdo con las necesidades del cliente.
Ingeniero de manutención: El ingeniero de V&V requiere realizar chequeos periódicos para asegurarse que la integridad del sistema se mantiene, que los cambios que afectan su operación han sido documentados, y los operadores han recibido entrenamiento en procedimientos nuevos o que han cambiado.
Actividades Y Metas
Administración de V&V de software: El proceso requiere ser administrado y realizado en forma completa durante todo el proceso de desarrollo de software.
Planificación: Planificar y mantener el proceso de V&V.
Coordinación: Coordinar e interpretar rendimiento y calidad del esfuerzo del proceso de V&V.
Reportar: Reportar discrepancias a la brevedad posible al usuario o al grupo de desarrollo.
Monitoreo: Identificar tempranamente caminos de problemas, focalizando las tareas de V&V en ellos.
Evaluación de resultados: Proveer una evaluación técnica del rendimiento del software y sus atributos de calidad en cada revisión de software.
Evaluación del impacto del cambio: Determinar el impacto completo de los cambios de software propuestos.
Monitoreo del progreso técnico de V&V y calidad de resultados: Durante cada actividad de V&V, se debe revisar las tareas planificadas de V&V, incluyendo nuevas para mantenerse focalizado en las funciones críticas de rendimiento y calidad del software.
Examinar documentación temprana del proyecto: Muchas veces los llamados documentos conceptuales, para verificar que el sistema que se construirá no es sólo posible, pero que además utiliza las reglas, convenciones, algoritmos y prácticas apropiadas al dominio de aplicación del sistema.
V&V de los requisitos de usuario: Realizado para asegurarse que los requisitos de usuario especificados son correctos, completos, consistentes, fieles, legibles y es posible testearlos, y que además, satisfacerán los requisitos de software.
V&V de los requisitos de software: Realizado para asegurarse que los requisitos de software especificados son correctos, completos, consistentes, fieles, legibles, es posible mapearlos desde los requisitos de usuario y es posible testearlos, y que además, satisfacerán los requisitos de diseño.
V&V del diseño de software: Provee seguridad de que los requisitos de software no son mal interpretados o implementados en forma incompleta.
V&V del código: Asegurarse que se utilicen los estándares en uso, que usualmente consideran programación estructurada, reuso de código, adopción de estándares y estilos de programación, etc.
Administración de tests: Una actividad importante en la actividad de V&V es la de asegurarse que se consideren y planifiquen todos los testeos requeridos para el sistema.
V&V de la transferencia: Asegurarse que se consideren todos los detalles de la instalación y puesta en marcha del sistema, así como la migración y/o poblamiento de sus datos y posibles problemas de eficiencia que empiezan a aparecer.
V&V de la operación y manutención Cuando se realiza un cambio en el software, en necesario repetir todas las actividades de V&V pertinentes para asegurarse que nada queda fuera.
Manutención
Definición de Manutención
La manutención es la última fase del proceso de desarrollo de software. Sin embargo, la manutención toma una parte importante del presupuesto destinado al desarrollo. Por otro lado, a medida que se desarrollan más programas, la cantidad de esfuerzo y recursos dedicados a la manutención crecerá.
Objetivos
Modificar el software para adaptar nuevas funciones o modificar algunas funciones existentes.
Modernizar el software por medio de cambios al sistema.
Asegurarse de que el equipo de desarrollo esté informado de los errores encontrados en el sistema.
Actividades y Metas
Manutención correctiva: Diagnóstico y corrección de errores encontrados durante el uso del programa.
Manutención adaptiva: Adaptar el sistema a los cambios que pueden producirse en el hardware, sistema operativo, periféricos y herramientas de trabajo.
Manutención perfectiva: Satisfacer la demanda de recomendaciones por parte de los usuarios del sistema.
Relación con otros roles
Administrador de proyecto: Debe supervisar y controlar los cambios requeridos, utilizando los estándares del proyecto.
Analista: Debido a que probablemente será necesario adaptar o perfeccionar el sistema durante el tiempo, los analistas requerirán determinar nuevos requisitos.
Diseñador: Es necesario involucrar al diseñador para rediseñar las partes del sistema que requieren ser corregidas, agregadas o perfeccionadas.
Programador: La naturaleza de las actividades requeridas para cubrir la fase de manutención está estrechamente ligada con el rol de programador.
Téster: Debe testear las partes que han sido modificadas para chequear si están adecuadas para ser liberadas como parte del sistema.
Asegurador de calidad: Es responsable de asegurar que el resultado del producto es de la calidad definida por el estándar en uso.
Validación y verificación: Es responsable de revisar que el cliente quede completamente satisfecho con el producto entregado.
Herramientas de apoyo
El ingeniero de manutención debe utilizar para realizar su labor, una herramienta que le permita capturar requisitos de manutención, y además controlar la organización de la manutención dentro del proyecto.
Perfil
El perfil del ingeniero de manutención, como es el caso de otras formas de administración, requiere de la creación y preservación de una atmósfera adecuada que permita llevar a cabo las actividades de la mejor forma posible.
Plan de Trabajo
Planificación y coordinación de la organización de manutención durante el proyecto.
Definición de procedimientos de evaluación e información.
Desarrollo de herramientas para administrar los requisitos de manutención.
Definición de una secuencia estándar de eventos para cada requisito de manutención.
Definición de un sistema de registro e información de las actividades de manutención y organización de la manutención.
Documentación
Definición de la Documentación
La documentación se clasifica en dos:
Documentación de procesos. Los documentos pertenecientes a esta categoría registran la información del proceso de desarrollo y manutención del sistema. El objetivo de esta documentación es hacer “visible” el proceso de desarrollo,
manteniendo información sobre planificación, reportes, estándares, etc.
Documentación de producto. Estos documentos describen el desarrollo del
producto desde los puntos de vista técnico (documentación de sistema) y
usuario del sistema (documentación de usuario), siendo el usuario un usuario
final o un usuario administrador del sistema.
Objetivos
Permitir el almacenamiento y recuperación de la documentación de los procesos y productos más recientes durante el desarrollo, manteniendo así la información al día.
Mantener la consistencia en la apariencia y estructura de los documentos.
Asegurarse que los cambios que necesitan hacerse en el sistema serán reflejados en la documentación correspondiente.
Elaborar, almacenar y permitir la recuperación de las actas y registros
generados durante las reuniones de revisión.
Construir el manual de usuarios del sistema, MUS, que contempla los aspectos de uso del sistema.
Actividades y Metas
Diseñar y construir un repositorio de información compartido, donde se almacenará la documentación.
Tener accesible y organizada la última versión de todos los documentos generados durante el proceso de desarrollo, en un repositorio común.
Especificar el formato que será usado para elaborar la documentación.
Asegurarse que los documentos mantienen el estándar de documentación definido para el proyecto antes de incluirlos en el repositorio.
Toda la información almacenada en el repositorio tendrá el formato definido, y se ajustará al estándar de documentación en uso.
Durante las reuniones de revisiones, el documentador elaborará las actas de la reunión.
Estos documentos serán usados luego por el ingeniero de validación y verificación.
Es necesario mantener la historia del proyecto en el repositorio. Al término del proyecto, el repositorio contendrá toda la información histórica del proyecto.
Relación con otros roles
Administrador de proyecto: La información del repositorio ayuda al administrador a realizar los planes, agenda y presupuestos del proceso de desarrollo de software.
Administrador de configuración: El administrador de configuración y documentador comparten documentación a través del repositorio. Cuando se autoriza un cambio de un documento, debe ser reflejado en el sistema de
Administración de documentos. El propósito de esto es evitar inconsistencias y permitir al equipo de desarrollo el acceso a la versión más reciente de cada documento.
Validación y verificación: El documentador mantiene una relación con el ingeniero de V&V a través del registro elaborado durante las reuniones de revisión.
Asegurador de calidad: A los aseguradores de calidad se les ha confiado que garanticen la calidad del producto a ser desarrollado.
Ingeniero de manutención: La documentación generada durante el desarrollo del producto es usado durante la fase de operación y manutención del sistema.
Herramientas de apoyo
Editor de texto, que permite elaborar documentos fácilmente y almacenarlos en
diferentes formatos, incluyendo HTML. Debe incluir una herramienta para el
chequeo ortográfico y de gramática.
Navegador Web y editor HTML, que permita editar y publicar documentos
HTML, proveyendo diversas funciones.
Perfil
El documentador debe ser una persona ordenada, con capacidades de mantener una
gran cantidad de información en forma ordenada y accesible. Todo el contenido de los
documentos debe ser organizado en forma clara. Esta claridad debe ser consecuencia
del formato en que se presenta la información. El documentador debe poseer
capacidades para no sólo apoyar su trabajo con tecnología, sino que además, deberá
diseñar y construir el repositorio para la documentación del proyecto. Esto incluye, al
menos, la definición del modelo de datos, definición de las interfaces, definición de los
perfiles de acceso de los usuarios, y la definición del protocolo social de uso de los
documentos.
Plan de Trabajo
Definir su formato.
Diseño y elaboración del repositorio central usado para almacenar información:
Análisis de las características deseadas del repositorio.
Estudio de las herramientas que serán usadas para elaborar el repositorio.
Elaborar el diseño lógico de la base de datos.
Construir el repositorio.
Incluir un puntero entre la base de datos y el sitio Web del proyecto, en caso que sean diferentes.
Elaboración de las actas de reunión y documentos de acuerdo:
Almacenamiento de los documentos generados:
martes, 9 de octubre de 2007
Análisis y modelado de software
Analisis de software
Analisis de software
El modelado de software puede contribuir más en el futuro ya que últimamente se está invirtiendo mucho en el análisis de software, pues así se pueden evitar errores después de la realización del código que pueden ser muy costosos.
Análisis de modelados abstractos y código
El análisis de modelos
La producción de líneas de código es una medida de desarrollo de productividad común, pero es caro. El código solo sirve si es correcto, por eso, un modelo puede ser estructurado de mejor manera y más efiiente. Esto conlleva a que cualquier posibilidad de analizar el sistema antes de hacerlo debería tomarse en cuenta, especialmente en la temprana edad del mismo, ya que puede exponer errores del sistema que en caso de haberse realizado de ese modo, el error pudo haber costado mucho.
Análisis VS Descripción
Los investigadores que trabajan con modelos abstractos se dividen en dos campos:
-Los que se han enfocado principalmente en el formulario de modelo y han tratado el análisis como secundario, quienes favorecen el razonamiento sobre la amenabilidad hacia la automatización.
-Los que se enfocan más en el análisis y prestan menor atención a la manera en el que el modelo se expresa.
Modelos globales VS Modelos locales.
-El método orientado a objetos, quemuestra que objetos existen y como se relacionan.
-Los diagramas de estado y transición, que muestra el estado de los objetos y la transición entre ellos.
Se dice que el modelado de objetos es "estático" y la transición de diagramas son "dinámicas". Los modelos de objetos son casi siempre diagrmas de clase, mostrando clases, sus campos y las relaciones entre clases. Un diagrama de clase es una representación parcial de la estructura sintáctica del código en comparación con un diagrama de transición.
En un modelo global, el estaod del sistema como un todo es expresado directamente; en un modelo local, el estado global emerge de las definiciones de los estados locales.
Simulación VS Comprobación
La simulación siempre ha se visto con sospecha por los académicos. Es mejor checar una propiedad exhaustivamente que analizar solo un pequeño espacio. Por eso el modelado de comprobación es más efectivo que la simulación en exponer errores sutiles.
Pero en la otra mano, la simulación es muy útil, cuando se construye un modelo muy grande, es más fácil cometer erores que la simulación de inmediato expone.
Verificación VS Refutación
La comprobación rara vez es totalmente automatizada, desde que los lenguajes de modelado son cada vez más efectivos, por eso hay dos acercamientos: la verificación y la refutación.
El acercamiento de la verificación tiene el intento del análisis a encontrar una prueba para la propiedad dada. Si no se encunetra tal prueba, la propiedad puede aguantar, pero tales análisis rara vez fallan de una manera que permite al usuario determinarsi es la prueba de la estrategia o el modelo en sí que está fallando.
El acercamiento de la refutación tiene el intento del análisis a refutar la propiedad dada para encontrar un contra ejemplo. Estos análisis emplean algunos formularios de búsqueda en un espacio que ha sido artificialmente relacionado. Si no se encuentra un contraejemplo o la relación es inapropieda o en realidad la propiedad se mantiene..
Declarativo VS Estilo Operacional
En un lenguaje declarativo para modelos globales, las invariantes y operaciones son escritas como fórmulas lógicas. Lenguajes para modelos locales, tienden a ser más operacionales, definiendo transiciones en una manera programadora.
Las descripciones operacionales corren el riego de cometer tendencias de implementación, pero los modelos locales raramente sufren de ello.
Análisis de código
Los actuales lenguajes de modelado tienen un talón de Aquiles: la falta de cualquier correspondencia hecha con la actual implementación. Un diseñador o ingeniero no puede confiar en el modelo para reflejar exactamente de el comportamiento del programa será entendiblemente reluctante usar el modelo como razón para entender el comportamiento del sistema. De hehco, un modelo incorrecto puede serpeor que si no hubiera un modelo en absoluto, si este desorienta al ingeniero o al diseñador hacia una manera incorrecta de comprender las causas del comportamiento del sistema.
El resultado práctico de la falta de correspondencia hecha entre el modelo y la implementación, es que el modelos se convierte menos útil durante el proceso de desarrollo de software, al punto donde es descartado como una fuente útil de información en las últimas etapas de desarrollo y mantenimiento.
Estático VS Dinámico
Los análisis estáticos analizan el programa para obtener información que es válida para todas las ejecuciones posibles. Los análisis dinámicos utilizan el programa para recolectar información mientras está corriendo.
Los análisis dinámicos tienen una ventaja que detallan información sobre una sola ejecución, así es más fácil de obtener que detallando información que es válida para todas la s ejecuciones.
Sonido VS Sin sonido
Los análisis estáticos de sonido producen información que está garantizada para mantener todos los programas en ejecución; los análisis dinámicos de sonido producen información que está garantizada para esperar la ejecución analizada. Los análisis sin sonido no tienen tal garantía.
Velocidad VS Precisión
Los típicos análisis estáticos exhiben un análisis tiempo vs intercambio de precisión. Se ilustra este intercambio discutiendo 2 distinciones fundamentales: La distinción entre análisis de flujo sensible y análisis de fljo insensible, y también la distinción entre el análisis de contexto sensible y el de contexto insensible.
Los análisis de flujo sensible toman la orden de ejecución de las declaraciones del programa en cuenta. Ellos normalmente utilizan alguna forma iterativa de análisis de flujo de información para producir un resultado de análisis potencialmente diferente para cada punto del programa.
Los análisis de flujo insensible no toman la orden de ejecución de las declaraciones del programa en cuenta, y por eso son incapaces de extraer cualquier propiedad que dependa de esta orden. Ellos usan una forma de análisis de contra-base para producir resultados de análisis simples que son válidos para todo el programa.
Un análisis de contexto sensible produce resultados diferentes para cada análisis de contexto diferente.
Un análisis de contexto insensible produce un solo resultado que es usado directamente por todos los contextos.
Analisis de software
El modelado de software puede contribuir más en el futuro ya que últimamente se está invirtiendo mucho en el análisis de software, pues así se pueden evitar errores después de la realización del código que pueden ser muy costosos.
Análisis de modelados abstractos y código
El análisis de modelos
La producción de líneas de código es una medida de desarrollo de productividad común, pero es caro. El código solo sirve si es correcto, por eso, un modelo puede ser estructurado de mejor manera y más efiiente. Esto conlleva a que cualquier posibilidad de analizar el sistema antes de hacerlo debería tomarse en cuenta, especialmente en la temprana edad del mismo, ya que puede exponer errores del sistema que en caso de haberse realizado de ese modo, el error pudo haber costado mucho.
Análisis VS Descripción
Los investigadores que trabajan con modelos abstractos se dividen en dos campos:
-Los que se han enfocado principalmente en el formulario de modelo y han tratado el análisis como secundario, quienes favorecen el razonamiento sobre la amenabilidad hacia la automatización.
-Los que se enfocan más en el análisis y prestan menor atención a la manera en el que el modelo se expresa.
Modelos globales VS Modelos locales.
-El método orientado a objetos, quemuestra que objetos existen y como se relacionan.
-Los diagramas de estado y transición, que muestra el estado de los objetos y la transición entre ellos.
Se dice que el modelado de objetos es "estático" y la transición de diagramas son "dinámicas". Los modelos de objetos son casi siempre diagrmas de clase, mostrando clases, sus campos y las relaciones entre clases. Un diagrama de clase es una representación parcial de la estructura sintáctica del código en comparación con un diagrama de transición.
En un modelo global, el estaod del sistema como un todo es expresado directamente; en un modelo local, el estado global emerge de las definiciones de los estados locales.
Simulación VS Comprobación
La simulación siempre ha se visto con sospecha por los académicos. Es mejor checar una propiedad exhaustivamente que analizar solo un pequeño espacio. Por eso el modelado de comprobación es más efectivo que la simulación en exponer errores sutiles.
Pero en la otra mano, la simulación es muy útil, cuando se construye un modelo muy grande, es más fácil cometer erores que la simulación de inmediato expone.
Verificación VS Refutación
La comprobación rara vez es totalmente automatizada, desde que los lenguajes de modelado son cada vez más efectivos, por eso hay dos acercamientos: la verificación y la refutación.
El acercamiento de la verificación tiene el intento del análisis a encontrar una prueba para la propiedad dada. Si no se encunetra tal prueba, la propiedad puede aguantar, pero tales análisis rara vez fallan de una manera que permite al usuario determinarsi es la prueba de la estrategia o el modelo en sí que está fallando.
El acercamiento de la refutación tiene el intento del análisis a refutar la propiedad dada para encontrar un contra ejemplo. Estos análisis emplean algunos formularios de búsqueda en un espacio que ha sido artificialmente relacionado. Si no se encuentra un contraejemplo o la relación es inapropieda o en realidad la propiedad se mantiene..
Declarativo VS Estilo Operacional
En un lenguaje declarativo para modelos globales, las invariantes y operaciones son escritas como fórmulas lógicas. Lenguajes para modelos locales, tienden a ser más operacionales, definiendo transiciones en una manera programadora.
Las descripciones operacionales corren el riego de cometer tendencias de implementación, pero los modelos locales raramente sufren de ello.
Análisis de código
Los actuales lenguajes de modelado tienen un talón de Aquiles: la falta de cualquier correspondencia hecha con la actual implementación. Un diseñador o ingeniero no puede confiar en el modelo para reflejar exactamente de el comportamiento del programa será entendiblemente reluctante usar el modelo como razón para entender el comportamiento del sistema. De hehco, un modelo incorrecto puede serpeor que si no hubiera un modelo en absoluto, si este desorienta al ingeniero o al diseñador hacia una manera incorrecta de comprender las causas del comportamiento del sistema.
El resultado práctico de la falta de correspondencia hecha entre el modelo y la implementación, es que el modelos se convierte menos útil durante el proceso de desarrollo de software, al punto donde es descartado como una fuente útil de información en las últimas etapas de desarrollo y mantenimiento.
Estático VS Dinámico
Los análisis estáticos analizan el programa para obtener información que es válida para todas las ejecuciones posibles. Los análisis dinámicos utilizan el programa para recolectar información mientras está corriendo.
Los análisis dinámicos tienen una ventaja que detallan información sobre una sola ejecución, así es más fácil de obtener que detallando información que es válida para todas la s ejecuciones.
Sonido VS Sin sonido
Los análisis estáticos de sonido producen información que está garantizada para mantener todos los programas en ejecución; los análisis dinámicos de sonido producen información que está garantizada para esperar la ejecución analizada. Los análisis sin sonido no tienen tal garantía.
Velocidad VS Precisión
Los típicos análisis estáticos exhiben un análisis tiempo vs intercambio de precisión. Se ilustra este intercambio discutiendo 2 distinciones fundamentales: La distinción entre análisis de flujo sensible y análisis de fljo insensible, y también la distinción entre el análisis de contexto sensible y el de contexto insensible.
Los análisis de flujo sensible toman la orden de ejecución de las declaraciones del programa en cuenta. Ellos normalmente utilizan alguna forma iterativa de análisis de flujo de información para producir un resultado de análisis potencialmente diferente para cada punto del programa.
Los análisis de flujo insensible no toman la orden de ejecución de las declaraciones del programa en cuenta, y por eso son incapaces de extraer cualquier propiedad que dependa de esta orden. Ellos usan una forma de análisis de contra-base para producir resultados de análisis simples que son válidos para todo el programa.
Un análisis de contexto sensible produce resultados diferentes para cada análisis de contexto diferente.
Un análisis de contexto insensible produce un solo resultado que es usado directamente por todos los contextos.
domingo, 30 de septiembre de 2007
Metodologias de la ingenieria en Software [Extracto]
Original por:
León Welicki
Fernando Cano Garcia
"Exprimido" por:
Electrocats Team
Si usted es el profesor, Tenga en cuenta que es extenso por que incluimos las tablas de ROLES EN LOS PROYECTOS, por eso el texto se muestra tan extenso
El rol de las personas en las metodologías de ingeniería del software ha variado sustancialmente durante la. vida de esta disciplina. En un inicio, el desarrollo de software estaba al alcance. de unas pocas personas, altamente capacitadas. Los avances en los campos del hardware y software trajeron como consecuencia obvia y directa mayor potencia computacional y la posibilidad de trabajar con mayores niveles de abstracción, dando lugar a diferentes .metodologías de ingeniería del software.
Las personas al Inicio de la Informática: Protoingeniería del Software
Los "proto-ingenieros de software", eran visionarios altamente calificados, generalmente adelantados a su tiempo. Eran personas únicas: la historia de la informática no podría concebirse sin sus aportaciones. Si en lugar de ellos hubieran sido otros, seguramente la informática no sería la que conocemos actualmente.
Aunque parezca que estamos hablando de hace mucho tiempo, en algunos casos sólo han transcurrido un par de décadas. Para ilustrar esto, proveeremos 2 ejemplos:
Cuando Dijkstra contrajo matrimonio, quiso dejar constancia que su profesión era "programador". Como esta profesión no existía, no le fue permitido y tuvo que registrarse como "físico teórico"
John Von Newmann: fue el precursor de la separación..entre el hardware y el software, por tanto inventor del concepto de programa almacenado. Fue quien propuso al bit como unidad de información y resolvió el problema de la obtención de respuestas fiables con componentes no fiables (bit de paridad).
Alan M. Turing: matemático inglés creador de la Máquina de Turing, el antecedente teórico del ordenador moderno. Demostró que la base esencial de la informática podía modelarse con una máquina teórica muy simple. Creó el primer ordenador teórico en Fue un hombre muy peculiar, que llego a verse a si mismo como un ordenador
Metodologías Estructuradas Clásicas
Las metodologías estructuradas hacen fuerte separación ente los datos y los procesos. Producen una gran cantidad de modelos y documentación y se basan en ciclos de vida en cascada.
El enfoque estructurado tiene un alto grado de especialización en sus perfiles y las relaciones entre ellos tienen fuertes raíces en los principios de la descomposición funcional. Para ilustrar este concepto, podemos citar la fuerte separación que existe entre el programador y el analista. En el Análisis Estructurado Moderno, idealmente el analista no habla directamente con el programador! sino que lo hace a través del diseñador. Adicionalmente, se intenta mecanizar las tareas del programador, teniendo como ideal la generación del código mediante herramientas CASE. El programador es altamente reemplazable.
Metodologías Orientadas a Objetos Clásicas
Ante la necesidad de normalizar el proceso desarrollo se propusieron unas metodologías que priman las fases, actividades y tareas antes que a las personas: lo más importante es el rol que juega la persona dentro del proceso de desarrollo. Esto se ha justificado históricamente argumentando que el desarrollo de software es una actividad compleja que debe estar dirigida por un proceso y debe llevarse a cabo en grupos.
Para cubrir todas las fases se necesitan distintos y diversos perfiles, que no se encuentran en una sola persona. El rol se asigna dependiendo de la experiencia, formación y capacidades de cada individuo.
Una de las ventajas de estos procesos es que el intercambio de un recurso es relativamente fácil: cuanto más identificadas se tengan las tareas que realiza un rol, más fácil es formar a una persona en esas tareas específicas.
En un proyecto de RUP existen los siguientes roles :
Jefe de proyecto Supervisor y responsable del proyecto
Analista del Proceso de Negocio Coordina el modelado de los CU de negocio
Diseñador del Proceso de Negocio Describe el worfl1ow de uno o varios casos de uso de negocio
Revisor del Proceso de Negocio Revisa los artefactos generados del workflow de Modelado de Negocio
Analista de Sistemas Es el responsable de un conjunto de requisitos: Requisitos funcionales,
Requisitos no funcionales
Especificador de Casos de Uso Asumen las responsabilidades de las descripciones detalladas de uno o más casos de uso
Diseñador de Interfaces de Usuario Forma visual de los interfaces de usuario, esquema de pantallas, modelos de interfaz grafica
Arquitecto Describe el modelo de la arquitectura, es responsable de la integridad del
modelo de análisis y de la integridad de los modelos de diseño y despliemle
Revisor de Requisitos Revisa los artefactos generados en el workt1ow de Análisis de Requisitos
lngeniero de Componentes Define y mantiene las responsabilidades, atributos, relaciones y requisitos de una o varias clases de análisis
Ingeniero de Casos de Uso Analiza un Caso de Uso, Captura requisitos. especiales sobre ]a ealización del caso de uso y es responsable de la integridad de una o más realizaciones de casos de uso-diseño
lntegrador de Sistemas Planifica la secuecia de construcciones nece"sarias en cada iteración "
Diseñador de Pruebas Responsable de la integridad del modelo de pruebas y plantear las pruebas
Ingeniero de Pruebas de implantación Verifica los componentes integrados en la construcción que se derivan de los casos de prueba Que especifican una realización de un caso de uso-diseño
Ingeniero de Pruebas de Sistemas Prueba de las pruebas técnicas: rendimiento, estrés, carga,.. de una iteracción completa
Jefe de Control de Cambio Concreta las acciones de cambio obtenidas del plan de cambios
Administrador de Sistemas Configuración y adaptar e] proceso a las necesidades y restricciones
Experto en Herramientas Conocedor de las herramientas deben ajustarse a cada actividad: modelado, gestión de requisitos. entomos de desarrollo, gestión de configuración,
pruebas, planificación. documentación
Escritor Técnico Encargado de documentar los manuales de usuario y explotación
Programador Programador del código fuente
Personal Técnico Encargado de la formación
Las personas en las metodologías ágiles
En los procesos ágiles, las personas vuelven a tomar un valor importante: el éxito de estos procesos es función de la participación, preparación e involucramiento de las personas en el mismo. Generalmente estos procesos deben ser conducidos y llevados a cabo por personas con características muy especiales. El cambio de estas personas afecta fuertemente al proceso. De hecho, estos procesos están también orientados a las personas, buscando un mayor estado de bienestar para las personas que llevan a cabo el proceso de software a cambio de un mayor grado de compromiso. Por lo tanto, podemos decir que las personas tienen un rol muy importante en este tipo de procesos.
Procesos ágiles
Los procesos ágiles ofrecen un enfoque diametralmente opuesto al de las metodologías predictivos para gestionar y controlar el desarrollo de productos y proyectos de software.
Se basan en principios tales como la temprana y continua entrega de software de valor; la actitud positiva frente al cambio de requerimientos en función de las necesidades del . cliente; la motivación individual de los integrantes del proyecto; la comunicacion fluida entre. el personal de desarrollo y de negocios; la excelencia técnica; la simplicidad; la comunicación personal; la emergencia y la autoorganización. Todos estos principios han sido extraídos del Manifiesto Ágil, un documento que surge como producto de la reunión realizada por un grupo de reconocidos ingenieros de software en cuya idea común crear un "llamado a las armas a favor de métodos más ágiles de desarrollo de software".
Las personas son muy importantes en Extreme Programming. De hecho, el motivo de su existencia según Kent Beck es mejorar la calidad de vida de los integrantes de los equipos de desarrollo de software.
A los programadores, XP les promete que serán capaces de trabajar en cosas que realmente les importan, cada día. No tendrán que enfrentarse solos a situaciones aterradoras. Podrán aprovechar todas sus energías para hacer que su sistema tenga éxito. Tomaran las decisiones que puedan tomar mejor y.no tomarán aquellas para los que no sean los mejores preparados
A los clientes y directivos, XP les promete que obtendrá el mayor valor posible de cada semana de programación. Cada pocas semanas podrán ver progresos concretos en las metas que les importan. Podrán cambiar la dirección del proyecto a mitad del desarrollo, sin incurrir en costes excesivos
Como se puede apreciar, estas promesas apuntan al bienestar social de los 2 stakeholders determinantes en un proceso de desarrollo: el equipo de desarrollo y el cliente.
Para lograr esto, se basa en un conjunto de valores humanos, a saber: comunicación, sencillez, realimentación y valentía. Estos valores se materializan a través de una serie de prácticas, entre ellas programación en parejas, 40 horas de trabajo semanales, diseño sencillo, comunicación con el cliente, propiedad colectiva del código.
En un proyecto de XP existen los siguientes roles :
Rol Descripción
El Programador Es el corazón de XP. Según Beck, si los programadores pudieran tomar
decisiones que cuidadosamente equilibrascn las prioridades a corto y largo
plazo no habría necesidad de otro personal técmco en el proyecto .
Además de un peñtl técnico, debe tener que tener habilidades de
comunicación y coordinación con otros programadores. el hábito de la
simplicidad evitando la "violencia intelectual" . estar dispuesto a dejar de
lado la propiedad del código.
El Cliente Es la otra mitad de la dualidad esencial de XP. El programador sabe como
programar, el cliente sabe que programar. Debe tener habilidades de
comunicación. un fuerte control sobre su sensación y ansias de poder sobre el
proyecto, capacidad de abstracción y comprensión funcional del proyecto.
El encargado de pruebas Es el responsable de ayudar al cliente a escoger y escribir pruebas
funcionales. Es responsable también de hacer funcionar las pruebas
regularmente y comunicar sus resultados al resto del equipo. Debe ser una
persona con capacidad de abstracción y mucho tacto y facilidad de
comunicación. dado que esta en un lugar intermedio entre los programadores
y el cliente.
El Controlador Es la conciencia del equipo . Su trabajo es cerrar el bucle de la
realimentación . Es responsable también de vigilar nformación sobre el estado del proyecto sin molestar al resto del equipo.
El Preparador Es el responsable del proceso en su conjunto, llamando la atención a los
integrantes del equipo cuando se desvían del proceso. Debe entender al
proceso con más profundidad que el resto de los integrantes y determinar en
que forma aplicarlo para obtener mejores resultados. Debe ser una persona
con fuerte temperamento, capaz de soportar y filtrar presiones políticas para
poder mantener la calma interna aun cuando hay mucha ansiedad fuera del
equipo. Debe poder también dirigir sin agobiar y saber cuando ser incisivo y
hasta grosero con un miembro del equipo. Además de las mencionadas, debe
tener habilidades parecidas a las del resto de los roles.
El Consultor Es una persona encargada. de dar solución a un problema puntual que el
equipo de XP no puede resolver
El Gran Jefe Es el jefe del proyecto. Sus principales características deben ser confianza,
coraje y brindar autonomía al equipo.
martes, 11 de septiembre de 2007
Definicion del problema
Bueno, primeramente en mi equipo se decidio analizar y hacer la documentacion de un sistema para cibercafé. El problema se basa en que en el equipo un integrante, tiene un cibercafé y otro está presto a instalar uno.
Esto nos facilita un poco la resolucion, ya que conocemos propiamente el problema, y somos los analistas resolviendo un problema propio.
El problema se basa en que el administrador no recuerda la hora de entrada del usuario, aun que tiene un sistema rudimentario [Libreta y pluma] que no le resulta muy agradable, no lo usa y resulta deficiente. Ademas los usuarios falsean su hora de entrada por no pagar la cuota real.
Entonces el enunciado del problema quedaria de la siguiente manera: "Se solicita al analista que realice un sistema que capture la hora de entrada del usuario y haga una cootizacion de la cuota, permitiendo hacer un descuento a consideracion del administrador del ciber, y que maneje las entradas por dia."
Esto nos facilita un poco la resolucion, ya que conocemos propiamente el problema, y somos los analistas resolviendo un problema propio.
El problema se basa en que el administrador no recuerda la hora de entrada del usuario, aun que tiene un sistema rudimentario [Libreta y pluma] que no le resulta muy agradable, no lo usa y resulta deficiente. Ademas los usuarios falsean su hora de entrada por no pagar la cuota real.
Entonces el enunciado del problema quedaria de la siguiente manera: "Se solicita al analista que realice un sistema que capture la hora de entrada del usuario y haga una cootizacion de la cuota, permitiendo hacer un descuento a consideracion del administrador del ciber, y que maneje las entradas por dia."
Suscribirse a:
Entradas (Atom)
