Siempre preguntan algunos amigos Ing. Percy Bravo ¿Qué es RUP, ¿Cómo se aplica en el desarrollo de software? y ¿Que beneficios nos da?, bueno acá detallo información poniendo como ejemplo el desarrollo de de un sistema para una clínica u hospital, esperando les sea útil.

Definiciones:

Es una guía de buena practica utilizada para desarrollo de software y junto con el lenguaje unificado de modelado (UML), constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. (Ian Sommerville, 2005:76-77).

Etapas

- Inicio, El Objetivo en esta etapa es determinar la visión del proyecto. En esta etapa se debe de presentar el Project Charter, el Scope Statement, en donde se describirá el alcance, tiempo y costo del presente proyecto. Asimismo, se entregara el documento visión con la especificación de los requerimientos funcionales y no funcionales del proyecto.

- Elaboración, En esta etapa el objetivo es determinar la arquitectura óptima. En esta etapa se presentaran toda la documentación del análisis, diagramas de caso de uso del negocio y del sistema, para que se logre un mayor entendimiento de los casos de uso con su correspondiente especificación y lo más importante identificar los riesgos del proyectos.

- Construcción, En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial, es decir, corresponde al desarrollo de la arquitectura del sistema de registros clínicos, la implementación y el testeo o pruebas. Se divide por 04 vistas en las cuales se entregaran la siguiente documentación:

Vista lógica: Diagrama de clases y modelo Entidad-Relación.

Vista de implementación: Diagrama de Secuencia, Diagrama de estados y Diagrama de Colaboración.

Vista conceptual: Modelo de dominio.

Vista física: Mapa de comportamiento a nivel de hardware.

- Transición, El objetivo es llegar a obtener el producto final del presente proyecto, comprende el despliegue del sistema en los equipos de la Unidad especializada del hospital.

Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los Objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes. En esta etapa se harán las pruebas con iteraciones para tener mejores resultados.

Fases del Proceso Unificado de Desarrollo:

Según Ian Sommerville, la metodología RUP, se divide en 4 fases el desarrollo del

software:

- Fase de Inicio: durante la fase de inicio las iteraciones hacen mayor énfasis en actividades del modelado del negocio y requisitos.

En esta fase se deben presentar los entregables:

√ Documento visión del proyecto.

√ Modelado de casos de uso con una lista de todos los casos de uso y los actores que pueden ser identificados.

√ Caso de uso inicial del negocio el cual incluye: contexto del negocio, criterios de éxito, y planificación financiera.

√ Plan del proyecto que muestre las fases y las iteraciones.

El objetivo de esta fase, es entender las funciones del negocio, tanto en su estructura como en sus procesos. Su objetivo es modelar funciones y roles que organizan en la organización para realizar más fácilmente la reingeniería de procesos o la implementación de un nuevo sistema. También se describe lo que el sistema tendría que realizar y permitir que los desarrolladores y el cliente estén de acuerdo con esta descripción. Para ello se debe de realizar lo siguiente:

√ Describir los requerimientos funcionales y no funcionales.

√ Capturar un glosario o vocabulario del sistema o proyecto.

√ Encontrar actores y casos de uso.

√ Describir los casos de uso mediante su flujo principal, variaciones y excepciones.

√ Asignar prioridades a los casos de uso encontrados para poder planificar la iteración en forma de análisis, diseño e implementación.

√ Modelar la interfaz de usuario (diseño lógico).

√ Prototipo de la interfaz de usuario (diseño físico).

- Fase de Elaboración: se orientan al desarrollo de la arquitectura, que incluye los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la arquitectura. En esta fase se debe realizar lo siguiente:

√ Un modelo de Casos de Uso con todos los actores identificados y la mayor parte de las descripciones de Casos de Uso.

√ Descripción de la arquitectura del software.

√ Prototipo ejecutable de arquitectura.

√ Plan del proyecto, incluyendo iteraciones y criterios de evaluación para cada iteración.

En esta fase se especifican los requerimientos y se describen sobre cómo se van a implementar en el sistema: transformar los requisitos al diseño del sistema, desarrollar una arquitectura para el sistema, y adaptar el diseño para que sea consistente con el entorno de implementación.

- Fase de construcción: se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás. El resultado final es un sistema ejecutable. Para ello se debe realizar lo siguiente:

√ El producto de software integrado sobre la plataforma adecuada.

√ Una descripción de la versión actual.

√ Cada implementador decide en qué orden implementa los elementos del subsistema.

√ Si encuentra errores de diseño, los notifica.

√ Se integra el sistema siguiendo el plan.

- Fase de transición: permite mantener la integridad de todos que se crean en el proceso, así como de mantener información del proceso evolutivo que han seguido. En la fase del Entorno, la finalidad es dar soporte al proyecto con las adecuadas herramientas, procesos y métodos. Brinda una especificación de las herramientas que se van a necesitar en cada momento, así como definir la instancia concreta del proceso que se va a seguir.

En concreto las responsabilidades de este flujo de trabajo incluyen:

√ Selección y adquisición de herramientas.

√ Establecer y configurar las herramientas para que se ajusten a la organización.

√ Configuración del proceso.

√ Mejora del proceso.

√ Servicios técnicos. (Ian Sommerville, 2005:76-77).

Beneficios del Proceso Unificado de Desarrollo:

Según Ian Sommerville (2005:76-77), los beneficios del proceso unificado de desarrollo son:

√ Las mejores prácticas más probadas de la industria: Son las mejores prácticas de desarrollo adoptadas en cientos proyectos mundialmente y enseñadas como parte de la currícula en cientos de universidades, la metodología RUP se convirtió rápidamente en el estándar de facto para el proceso de desarrollo en la industria de software.

√ Proceso hecho práctico: Diferente que otras metodologías comerciales, la plataforma RUP hace que el proceso sea práctico con bases de conocimiento y guías para ayudar en el despegue de la planificación del proyecto, integrar rápidamente a los miembros del equipo y poner en acción el proceso personalizado.

√ Se adapta a las necesidades de los proyectos: Solo la plataforma RUP proporciona un framework de proceso configurable que permite seleccionar e implantar los componentes específicos de proceso necesarios para proporcionar un proceso consistente y customizado para cada equipo y proyecto.

Una de las mejores prácticas centrales de RUP es la noción de desarrollar iterativamente. Rational Unified Process organiza los proyectos en términos de disciplinas y fases, consistiendo cada una en una o más iteraciones. Con esta aproximación iterativa, el énfasis de cada workflow variará a través del ciclo de vida. La aproximación iterativa ayuda a mitigar los riesgos en forma temprana y continua, con un progreso demostrable y frecuentes releases ejecutables.

Atte

Percy Bravo

CRMR - Metodología de Trabajo de Auditoría Informática

CRMR son las siglas de <>; su traducción más adecuada, Evaluación de la gestión de recursos informáticos. En cualquier caso, esta terminología quiere destacar la posibilidad de realizar una evaluación de eficiencia de utilización de los recursos por medio del management.

Una revisión de esta naturaleza no tiene en sí misma el grado de profundidad de una auditoría informática global, pero proporciona soluciones más rápidas a problemas concretos y notorios.

Supuestos de aplicación:

En función de la definición dada, la metodología abreviada CRMR es aplicable más a deficiencias organizativas y gerenciales que a problemas de tipo técnico, pero no cubre cualquier área de un Centro de Procesos de Datos.

El método CRMR puede aplicarse cuando se producen algunas de las situaciones que se citan:

• Se detecta una mala respuesta a las peticiones y necesidades de los usuarios.
• Los resultados del Centro de Procesos de Datos no están a disposición de los usuarios en el momento oportuno.
• Se genera con alguna frecuencia información errónea por fallos de datos o proceso.
• Existen sobrecargas frecuentes de capacidad de proceso.
• Existen costes excesivos de proceso en el Centro de Proceso de Datos.

Efectivamente, son éstas y no otras las situaciones que el auditor informático encuentra con mayor frecuencia. Aunque pueden existir factores técnicos que causen las debilidades descritas, hay que convenir en la mayor incidencia de fallos de gestión.

Áreas de aplicación:

Las áreas en que el método CRMR puede ser aplicado se corresponden con las sujetas a las condiciones de aplicación señaladas en punto anterior:

• Gestión de Datos.
• Control de Operaciones.
• Control y utilización de recursos materiales y humanos.
• Interfaces y relaciones con usuarios.
• Planificación.
• Organización y administración.

Ciertamente, el CRMR no es adecuado para evaluar la procedencia de adquisición de nuevos equipos (Capacity Planning) o para revisar muy a fondo los caminos críticos o las holguras de un Proyecto complejo.

Objetivos:

CRMR tiene como objetivo fundamental evaluar el grado de bondad o ineficiencia de los procedimientos y métodos de gestión que se observan en un Centro de Proceso de Datos. Las Recomendaciones que se emitan como resultado de la aplicación del CRMR, tendrán como finalidad algunas de las que se relacionan:

• Identificar y fijas responsabilidades.
• Mejorar la flexibilidad de realización de actividades.
• Aumentar la productividad.
• Disminuir costes
• Mejorar los métodos y procedimientos de Dirección.

Alcance

Se fijarán los límites que abarcará el CRMR, antes de comenzar el trabajo.

Se establecen tres clases:

1. Reducido. El resultado consiste en señalar las áreas de actuación con potencialidad inmediata de obtención de beneficios.
2. Medio. En este caso, el CRMR ya establece conclusiones y Recomendaciones, tal y como se hace en la auditoría informática ordinaria.

Amplio. El CRMR incluye Planes de Acción, aportando técnicas de implementación de las Recomendaciones, a la par que desarrolla las conclusiones.

Información necesaria para la evaluación del CRMR

Se determinan en este punto los requisitos necesarios para que esta simbiosis de auditoría y consultoría pueda llevarse a cabo con éxito.

1. El trabajo de campo del CRMR ha de realizarse completamente integrado en la estructura del Centro de Proceso de Datos del cliente, y con los recursos de éste.
2. Se deberá cumplir un detallado programa de trabajo por tareas.
3. El auditor-consultor recabará determinada información necesaria del cliente.

Se tratan a continuación los tres requisitos expuestos:

1. Integración del auditor en el Centro de Procesos de Datos a revisar

No debe olvidarse que se están evaluando actividades desde el punto de vista gerencial. El contacto permanente del auditor con el trabajo ordinario del Centro de Proceso de Datos permite a aquél determinar el tipo de esquema organizativo que se sigue.

2. Programa de trabajo clasificado por tareas

Todo trabajo habrá de ser descompuesto en tareas. Cada una de ellas se someterá a la siguiente sistemática:

• Identificación de la tarea.
• Descripción de la tarea.
• Descripción de la función de dirección cuando la tarea se realiza incorrectamente.
• Descripción de ventajas, sugerencias y beneficios que puede originar un cambio o modificación de tarea
• Test para la evaluación de la práctica directiva en relación con la tarea.
• Posibilidades de agrupación de tareas.
• Ajustes en función de las peculiaridades de un departamento concreto.
• Registro de resultados, conclusiones y Recomendaciones.

Información necesaria para la realización del CRMR

El cliente es el que facilita la información que el auditor contrastará con su trabajo de campo.

Se exhibe a continuación una Checklist completa de los datos necesarios para confeccionar el CRMR:

• Datos de mantenimiento preventivo de Hardware.
• Informes de anomalías de los Sistemas.
• Procedimientos estándar de actualización.
• Procedimientos de emergencia.
• Monitarización de los Sistemas.
• Informes del rendimiento de los Sistemas.
• Mantenimiento de las Librerías de Programas.
• Gestión de Espacio en disco.
• Documentación de entrega de Aplicaciones a Explotación.
• Documentación de alta de cadenas en Explotación.
• Utilización de CPU, canales y discos.
• Datos de paginación de los Sistemas.
• Volumen total y libre de almacenamiento.
• Ocupación media de disco.
• Manuales de Procedimientos de Explotación.

Esta información cubre ampliamente el espectro del CRMR y permite ejercer el seguimiento de las Recomendaciones realizadas.

http://percybravobaldeon.blogspot.com/2011/10/percy-bravo-baldeon.html