viernes, 24 de septiembre de 2010 | By: Wynnie Calero

Hitos

Hitos es una herramienta que administra en forma integrada y centralizada los Requerimientos que llegan a las áreas de soporte de las empresas y facilita la Gestión de Proyectos Corporativos, ayudando a las organizaciones a obtener productos competitivos y de calidad, según lo planeado.


*Infraestructura de procesos:A través de un potente workflow, Hitos permite crear y administrar los procesos definidos por el usuario, brindando una infraestructura integral en donde las organizaciones logran compartir la información, comunicarse y colaborar entre las distintas áreas.

*Soportes para modelos de calidad:Hitos ayuda a ordenar y sistematizar el flujo de los Requerimientos de Software y de los Requerimientos de Cambio que los usuarios realizan a las áreas de Sistemas, asegurando el cumplimiento de modelos como CMMI, para aquellas empresas que desarrollan software.

*Hitos gestion de proyectos:Es una herramienta flexible que permite a la organización lograr una gestión proactiva de los proyectos independientemente de sus dimensiones, colaborando en el cumplimiento de la planificación en tiempo y forma de todas las etapas del ciclo de vida de un proyecto. Tiene como objetivo principal la planificación, asignación de tareas y seguimiento de los recursos humanos y materiales, que intervienen en el desarrollo de un proyecto, a fin de supervisar su progreso y poder corregir desviaciones. Brinda la oportunidad de conocer, en todo momento, los problemas que se producen y resolverlos o paliarlos de manera inmediata, informando sobre el estado de los proyectos a quienes participan en ellos de una manera ágil y práctica.

*Hitos gestion de requerimiento:Hitos Gestión de Requerimientos fue concebido con el propósito de ordenar y sistematizar el flujo de los requerimientos internos/externos que los usuarios realizan en distintos circuitos (Proyectos de envergadura, Help Desk, Defectos, Errores, Soporte, Tareas Internas, etc.), administrando la forma en que sus necesidades llegan a las áreas de soporte y producción. Permite hacer un seguimiento de los requerimientos y de su evolución a través de los distintos estados que pueden asumir, gestionando requisitos para una amplia gama de proyectos, ofreciendo una verdadera ventaja competitiva a todo tipo de organizaciones.
Uso de Técnicas de cuarta Generación

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

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

•Acceso a base de datos: utilizando lenguajes de consulta de alto nivel.
•Generadores de códigos: a partir de una especificación de los requisitos se genera automáticamente toda la aplicación
•Generación de pantallas: permitiendo diseñar la pantalla dibujándola directamente, incluyendo además el control del cursor y la gestión de los errores de los datos de entrada.
•Gestión de entornos gráficos.
•Generación de informes.

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

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

•No son más fáciles de utilizar que que los lenguajes de tercera generación.
•El código fuente que produce es ineficiente, al estar generado automáticamente no pueden hacer uso de de los trucos habituales para aumentar el rendimiento, que se basan en el buen conocimiento de cada caso en particular.
•Sólo son aplicables al software de gestión, la mayoría de las herramientas de cuarta generación están orientadas a la generación a partir de grandes bases de datos, pero últimamente están surgiendo herramientas que generan esquemas de códigos para aplicaciones de ingeniería y de tiempo real.

Algunos lenguajes de cuarta generación:

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


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


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


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


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

Conclusión:

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

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

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

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

Actividades Protectoras del Software

Entre las actividades típicas de esta categoría se incluyen:

1. Seguimiento y control del proyecto de software
2. Revisiones técnicas formales
3. Garantía de calidad del software
4. Gestión de configuración del software
5.Preparación y producción de documentos
6. Gestión de reutilización
7. Mediciones
8. Gestión de riesgos

Las actividades de protección se aplican a lo largo de todo el proceso del software

Aplicaciones del Software

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

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

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

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

Software empotrado. Los productos inteligentes se han convertido en algo común en casi todos los mercados de consumo e industriales. El software empotrado reside en memoria de sólo lectura y se utiliza para controlar productos y sistemas de los mercados industriales y de consumo.

Software de computadoras personales. El mercado del software de computadoras personales ha germinado en las pasadas dos décadas. El procesamiento de textos, las hojas de cálculo, los gráficos por computadora, multimedia, entretenimientos, gestión de bases de datos, aplicaciones financieras, de negocios y personales y redes o acceso a bases de datos externas son algunas de los cientos de aplicaciones.

Software basado en Web. Las páginas Web buscadas por un explorador son software que incorpora instrucciones ejecutables (por ejemplo, CGI, HTML, Perl, o Java), y datos (por ejemplo, hipertexto y una variedad de formatos de audio y visuales). En esencia, la red viene a ser una gran computadora que proporciona un recurso software casi ilimitado que puede ser accedido por cualquiera con un modem.

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

Fases Genéricas del Software

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

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

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

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

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

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

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

Mitos del Software

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

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

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

Caracteristicas del Software

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

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

3. Aunque la industria tiende a ensamblar componentes, la mayoría del software se construye a medida.
Consideremos la forma en la que se diseña y se construye el hardware de control para un producto basado en computadora. El ingeniero de diseño construye un sencillo esquema de la circuitería digital, hace algún análisis fundamental para asegurar que se consigue la función adecuada y va al armario donde se encuentran los catálogos de componentes digitales. Después de seleccionar cada componente, puede solicitarse la compra.
martes, 21 de septiembre de 2010 | By: Wynnie Calero

El Principio W5HH

El principio WWWWWHH conduce 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?

*¿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.

Fases de Análisis y Diseño de Sistemas Orientada a Objetos

*Análisis: Tiene como objetivo que el analista construya un modelo de la situación del mundo real (comenzando desde la descripción del problema). El modelo del análisis es una abstracción precisa y resumida de lo que debe hacer el sistema y no de cómo lo hará.

*Diseño: Aquí se toman decisiones acerca de la arquitectura global del sistema.
El diseñador deberá decidir que características de rendimiento optimizar (uso de memoria, comunicaciones, etc.)

*Diseño de Objetos: Se construye un modelo de diseño basándose en el modelo de análisis que lleven incorporados detalles de implementación. El foco de atención son las estructuras de datos y los algoritmos necesarios para implementar cada una de las clases.

*Implementación: Se traduce lo especificado en las etapas anteriores a un lenguaje de programación.

Fases de Análisis y Diseño de Sistemas Estructurado

El método de ciclo de vida para el desarrollo de sistemas es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información. El método del ciclo de vida para el desarrollo de sistemas consta de 6 fases:

1)Investigación Preliminar: La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la petición de una persona.

2)Determinación de los requerimientos del sistema: El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave:
¿Qué es lo que hace?
¿Cómo se hace?
¿Con que frecuencia se presenta?
¿Qué tan grande es el volumen de transacciones o decisiones?
¿Cuál es el grado de eficiencia con el que se efectúan las tareas?
¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo origina?

3)Diseño del sistema: El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico.

4)Desarrollo del software: Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores.
Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.

5)Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga.Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados.

6)Implantación y evaluación: La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses.

Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones. La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:

*Evaluación operacional: Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de utilización.

*Impacto organizacional: Identificación y medición de los beneficios para la organización en áreas tales como finanzas, eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información externo e interno.

*Opinión de los administradores: evaluación de las actividades de directivos y administradores dentro de la organización así como de los usuarios finales.

*Desempeño del desarrollo: La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración de proyectos. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo.

Ventajas y Desventajas del RAD

Ventajas

*Comprar puede ahorrar dinero en comparación con construir.
*Los entregables pueden ser fácilmente trasladados a otra plataforma.
*El desarrollo se realiza a un nivel de abstracción mayor.
*Visibilidad temprana.
*Mayor flexibilidad.
*Menor codificación manual.
*Mayor involucramiento de los usuarios.
*Posiblemente menos fallas.
*Posiblemente menor costo.
*Ciclos de desarrollo más pequeños.
*Interfaz gráfica estándar.

Desventajas

*Comprar puede ser más caro que construir.
*Costo de herramientas integradas y equipo necesario.
*Progreso más difícil de medir.
*Menos eficiente.
*Menor precisión científica.
*Riesgo de revertirse a las prácticas sin control de antaño.
*Más fallas (por síndrome de "codificar a lo bestia").
*Prototipos pueden no escalar, un problema mayúsculo.
*Funciones reducidas (por "timeboxing").
*Dependencia en componentes de terceros: funcionalidad de más o de
menos, problemas legales.

Caracteristicas del RAD

Entre las principales características del RAD tenemos:

1.Equipos Híbridos

•Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo completo del sistema así como aquellas personas involucradas con los requisitos.
•Los desarrolladores de RAD deben ser "renacentistas": analistas, diseñadores y programadores en uno.

2. Herramientas Especializadas

*Desarrollo "visual"
*Creación de prototipos falsos (simulación pura)
*Creación de prototipos funcionales
*Múltiples lenguajes
*Calendario grupal
*Herramientas colaborativas y de trabajo en equipo
*Componentes reusables
*Interfaces estándares (API)
*Control de versiones

3. "Timeboxing"

•Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario.

4. Prototipos Iterativos y Evolucionarios

•Reunión JAD (Joint Application Development):
*Se reúnen los usuarios finales y los desarrolladores.
*Lluvia de ideas para obtener un borrador inicial de los requisitos.

•Iterar hasta acabar:
*Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales.
*Los diseñadores revisan el prototipo.
*Los clientes prueban el prototipo, depuran los requisitos.
*Los clientes y desarrolladores se reúnen para revisar juntos el producto, refinar los requisitos y generar solicitudes de cambios.
*Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se eliminan si es necesario para cumplir el calendario.

•Notas:

*Cada iteración dura entre un día y tres semanas.
*Reuniones de 2 horas con facilitador que mantiene enfocado al grupo

Modelo de Desarrollo Rapido de Aplicaciones y sus Faces

El desarrollo rápido de aplicaciones o RAD (Rapid Application Development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE.

Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar
También la usabilidad, utilidad y la rapidez de ejecución. El Desarrollo Rápido de Aplicaciones (DRA) (Rapid Application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos
y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos
cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:

•Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?

•Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.

•Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.

•Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.

•Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.
lunes, 20 de septiembre de 2010 | By: Wynnie Calero

Los siete mitos sobre los métodos formales

1.Los métodos formales garantizan que el software esta perfecto. El mito más importante es que los métodos formales serian todopoderosos, si nosotros humildes mortales pudiésemos aplicarlos. Este mito es pernicioso porque nos lleva a expectativas irreales y a la idea de que los métodos formales son de alguna forma todo o nada.

2.Los métodos formales se centran en demostrar corrección. En los Estados Unidos, gran parte del trabajo desarrollado en métodos formales se ha concentrado en la verificación de programas. Esto ha hecho que los métodos formales parezcan muy difíciles y no muy relevantes para la vida real.

3.Los métodos formales son útiles solo para sistemas críticos. Esta creencia se basa en la percepción de la dificultad que implica la aplicación de métodos formales. La verdad es que los sistemas críticos requieren un uso más acucioso de métodos formales, pero cualquier sistema puede beneficiarse con el uso de algunas técnicas de especificación formal.

4.Los métodos formales requieren matemáticos entrenados. Los métodos formales se basan en notaciones matemáticas, y muchas personas creen que esto los hace difíciles para la práctica de los ingenieros de software. Este mito, a su vez, se basa en la percepción de que las matemáticas son intrínsecamente difíciles.

5.Los métodos formales aumentan el costo del desarrollo. Se acostumbraba decir que a pesar que el costo que significaba usar métodos formales era muy alto, de todas formas era conveniente porque resultaba en menores costos de mantenimiento del software.

6.Los métodos formales son incomprensibles para los usuarios. Una especificación formal está llena de símbolos matemáticos que resultan incomprensibles para cualquiera que no esté familiarizado con la notación. De ahí que se suponga que son inútiles para clientes no matemáticos.

7.Los métodos formales no se usan en grandes proyectos reales. Los métodos formales se asocian comúnmente con departamentos académicos y organizaciones de investigación. Se piensa que solo estas organizaciones tienen la capacidad necesaria para usar métodos formales y que estos solo son apropiados para las aplicaciones idealizadas que estos grupos desarrollan.

Los diez mandamientos de los metodos formales

La decisión de hacer uso de los métodos formales en el mundo real no debe de adoptarse a la ligera. Bowen y Hinchley han acuñado los diez mandamientos de los métodos formales, como guía para aquellos que estén a punto de embarcarse en este importante enfoque de la Ingenieria del Software.

1.Seleccionarás la notación adecuada. Con objeto de seleccionar eficientemente dentro de la amplia gama de lenguajes de especificación formal existente, el ingeniero del software deberá considerar el vocabulario del lenguaje, el tipo de aplicación que haya que especificar y el grado de utilización del lenguaje.

2.Formalizarás, pero no de más. En general, resulta necesario aplicar los métodos formales a todos los aspectos de los sistemas de cierta envergadura. Aquellos componentes que sean críticos para la seguridad serán nuestras primeras opciones, e irán seguidos por aquellos componentes cuyo fallo no se pueda admitir (por razones de negocios).

3.Estimarás los costes. Los métodos formales tienen unos costes de arranque considerables. El entrenamiento del personal, la adquisición de herramientas de apoyo y la utilización de asesores bajo contrato dan lugar a unos costes elevados en la primera ocasión. Estos costes deben tenerse en cuenta cuando se esté considerando el beneficio obtenido frente a esa inversión asociada a los métodos formales.

4.Poseerás un experto en métodos formales a tu disposición. El entrenamiento de expertos y la asesoría continua son esenciales para el éxito cuando se utilizan los métodos formales por primera vez.

5.No abandonarás tus métodos formales de desarrollo. Es posible, y en muchos casos resulta deseable, integrar los métodos formales con los métodos convencionales y/o con métodos orientados a objetos. Cada uno de estos métodos posee sus ventajas y sus inconvenientes. Una combinación de ambos, aplicada de forma adecuada, puede producir excelentes resultados.

6.Documentarás suficientemente. Los métodos formales proporcionan un método conciso, sin ambigüedades y consistente para documentar los requisitos del sistema. Sin embargo, se recomienda que se adjunte un comentario en lenguaje natural a la especificación formal, para que sirva como mecanismo para reforzar la comprensión del sistema por parte de los lectores.

7.No comprometerás los estándares de calidad. Los métodos formales no tienen nada de mágico, y por esta razón, las demás actividades de SQA deben de seguir aplicándose cuando se desarrollen sistemas.

8.No serás dogmático. El ingeniero de software debe reconocer que los métodos formales no son una garantía de corrección. Es posible (o como algunos probablemente dirían) que el sistema final, aun cuando se haya desarrollado empleando métodos formales, siga conteniendo pequeñas omisiones, errores de menor importancia y otros atributos que no satisfagan nuestras expectativas.

9.Comprobarás, comprobarás y volverás a comprobar. Los métodos formales no absuelven al ingeniero del software de la necesidad de llevar a cabo unas comprobaciones exhaustivas y bien planeadas.

10.Reutilizarás cuanto puedas. A la larga, la única forma racional de reducir los costes del software y de incrementar la calidad del software pasa por la reutilización. Los métodos formales no modifican esta realidad. De hecho, quizás suceda que los métodos formales sean un enfoque adecuado cuando es preciso crear componentes para bibliotecas reutilizables.
viernes, 17 de septiembre de 2010 | By: Wynnie Calero

Metodos Formales

¿Qué es un Método Formal?

Definición: "Método formal es cualquier técnica que trate la construcción y/o el análisis de modelos matemáticos que contribuyen a la automatización del desarrollo de sistemas informáticos"

El papel de los métodos formales en la Ingeniería del Software

Los métodos formales se basan en el empleo de técnicas, lenguajes y herramientas definidos matemáticamente para cumplir objetivos tales como facilitar el análisis y construcción de sistemas confiables independientemente de su complejidad, delatando posibles inconsistencias o ambigüedades que de otra forma podrían pasar inadvertidas.

En los últimos años, la idea de que la formalización matemática del SW es el enfoque más apropiado para conseguir mejorar su calidad va adquiriendo cada vez más fuerza. Los partidarios de los métodos formales defienden que su empleo, a lo largo de todo el ciclo de vida, facilita el desarrollo de especificaciones claras, concisas y no ambiguas, permite el análisis funcional de la especificación y posibilita el desarrollo de implementaciones correctas respecto a su especificación. Sin embargo los detractores aseguran que el empleo de métodos formales supone un volumen de trabajo considerable, aumento en los costes y tiempo de desarrollo y que debe quedar supeditado a herramientas que lo automaticen.

Ventajas de los métodos formales

•Se comprende mejor el sistema.
•La comunicación con el cliente mejora ya que se dispone de una descripción clara y no ambigua de los requisitos del usuario.
•El sistema se describe de manera más precisa.
•El sistema se asegura matemáticamente que es correcto según las especificaciones.
•Mayor calidad software respecto al cumplimiento de las especificaciones.
•Mayor productividad

Problemática actual de los métodos formales

La falta de madurez en la práctica de los métodos formales es la causa de la imposibilidad de utilizarlos a nivel industrial tal y como se utilizan otros métodos de la Ingeniería del Software. Algunas de estas causas son las siguientes:

•El desarrollo de herramientas que apoyen la aplicación de métodos formales es complicado y los programas resultantes son incómodos para los usuarios.
•Los investigadores por lo general no conocen la realidad industrial.
•Es escasa la colaboración entre la industria y el mundo académico, que en ocasiones se muestra demasiado dogmático.
•Se considera que la aplicación de métodos formales encarece los productos y ralentiza su desarrollo.

Clasificación de los métodos formales

Se pueden encontrar multitud de métodos y técnicas formales con lo que los criterios de clasificación son bastante variados. La clasificación más común se realiza en base al modelo matemático subyacente en cada método, de esta manera podrían clasificarse en:

•Especificaciones basadas en lógica de primer orden y teoría de conjuntos: permiten especificar el sistema mediante un concepto formal de estados y operaciones sobre estados. Los datos y relaciones/funciones se describen en detalle y sus propiedades se expresan en lógica de primer orden. La semántica de los lenguajes está basada en la teoría de conjuntos. Los métodos de este tipo más conocidos son: Z, VDM y B.
•Especificaciones algebraicas: proponen una descripción de estructuras de datos estableciendo tipos y operaciones sobre esos tipos.