02-El proceso de creaci n del software(07AGO14)€¦ · de software, sin importar su tamaño o complejidad. Además, el marco de trabajo del proceso abarca un conjunto de actividades

Universidad Don Bosco (UDB) Facultad de Ingeniería / Escuela de Ingeniería en Computación

…/ 23 ... El pr oceso de creación del software

UNIDAD II: EL PROCESO DE CREACIÓN DEL SOFTWARE

CONTENIDOS Introducción 2.1. Marco de trabajo para el proceso de creación de software

2.1.1. Marco de trabajo genérico 2.1.2. Modelos del proceso del software

2.2. Integración del modelo de capacidad de madurez (IMCM) 2.2.1. Niveles de capacidad (continuo) 2.2.2. Niveles de madurez (discreto)

2.3. Metodologías de desarrollo de sistemas 2.3.1. Actores involucrados en el desarrollo de sistemas 2.3.2. Actividades necesarias para desarrollar sistemas de información

2.4. Etapas en los proyectos de creación de software 2.5. Confiabilidad en el diseño de sistemas 2.6. Medición del desempeño de sistemas computarizados (benchmarking) OBJETIVOS DE LA UNIDAD • Identificar el marco de trabajo para el proceso de creación del software. • Aplicar la integración del modelo de capacidad de madurez (IMCM) en el desarrollo de software. • Aplicar las diferentes metodologías de desarrollo de software al proceso de creación del software. • Enumerar las diferentes etapas en los proyectos de desarrollo de software. • Aplicar técnicas que abonen a la confiabilidad en el diseño de sistemas. • Aplicar técnicas para la medición del desempeño de sistemas computarizados. Introducción La ingeniería de software define un marco de trabajo que describe el proceso de creación del software, las actividades generales, el modelado y los patrones de procesos. El proceso de creación del software es una especie de mapa que ayuda a crear un resultado de alta calidad y a tiempo. La construcción del software de computadora es un proceso iterativo de aprendizaje, y el resultado, es una materialización del conocimiento recolectado, depurado y organizado conforme el proceso estuvo en ejecución. Un proceso de software define el enfoque que se adopta mientras el software está en desarrollo; pero la ingeniería de software también abarca las tecnologías que requiere el proceso (métodos y técnicas y herramientas automatizadas). El marco de trabajo de referencia que se utilizará estará definido por: • La Guía al Cuerpo de Conocimiento de Ingeniería de Software (SWEBOK, por sus siglas en inglés). • La Guía de los Fundamentos para la Dirección de Proyectos (Guía del PMBOK). • La Norma ISO 12207 (Ciclo de Vida del Software). Iniciaremos por definir que es un proceso: • Un proceso , entendido de manera general, es una serie de pasos que incluyen actividades,

restricciones y recursos que resultan en un producto determinado con ciertas características (SÁNCHEZ, 2012).

• Un proceso es una secuencia de pasos que se lleva a cabo para un propósito determinado (IEEE, 1990).



Un proceso de software: • Un proceso de software es un conjunto coherente de políticas, estructuras organizativas,

tecnologías, procedimientos y artefactos que se necesitan para concebir, desarrollar, implantar y mantener un producto software.

Un proceso de software incluye, entre otros, los siguientes elementos: a) Métodos y técnicas empleados como guías para llevar a cabo las actividades que componen un

proyecto software. b) Aspectos de gestión de equipos y personas. Otras definiciones a considerar: Un proyecto es un esfuerzo que se lleva a cabo una sola vez, que tiene objetivos bien definidos y que se produce dentro de un plazo determinado. Un proyecto de Ingeniería de Software es un proyecto cuyo objetivo es obtener un producto de software que satisfaga ciertos requisitos, en el plazo previsto y dentro del presupuesto. El ciclo de vida de un desarrollo de software es el período e tiempo que comienza cuando se toma la decisión de desarrollar un producto de software y que concluye cuando se entrega el software. 2.1. Marco de trabajo para el proceso de creación d e software Un marco de trabajo establece la base para un proceso de software completo al identificar un número pequeño de actividades del marco de trabajo aplicables a todos los proyectos de software, sin importar su tamaño o complejidad. Además, el marco de trabajo del proceso abarca un conjunto de actividades sombrilla, aplicables a lo largo del proceso del software. El marco de trabajo para el proceso de creación del software está definido por una serie de tareas relacionadas que produce un producto de trabajo en la ingeniería de software. Cada acción la forman tareas de trabajo individuales que completan alguna parte del trabajo implicado por la acción.

Figura 1. Marco de trabajo del proceso de software.



Foro de discusión

El proceso de creación de software La ingeniería de software define un marco de trabajo que describe el proceso de creación del software, las actividades generales, el modelado y los patrones de procesos. El proceso de creación del software es una especie de mapa que ayuda a crear un resultado de alta calidad y a tiempo. ¿Quién hace ingeniería de software? Un proceso de software define el enfoque que se adopta mientras el software está en desarrollo; pero la ingeniería de software también abarca las tecnologías que requiere el proceso (métodos y técnicas y herramientas automatizadas); pero, ¿Quién hace ingeniería de software? Reflexiona y argumenta.

Sistema de educación a distancia UDB: http://moodle.udb.edu.sv/ead/

2.1.1. Marco de trabajo genérico Actividades del marco de trabajo del proceso general de creación del software: Comunicación. Esta actividad implica una intensa colaboración y comunicación con los clientes; además, abarca la investigación de requisitos y otras actividades relacionadas. Planeación. Esta actividad establece un plan para el trabajo de la ingeniería de software. Describe las tareas técnicas que deben realizarse, los riesgos probables, los recursos que serán requeridos, los productos del trabajo que han de producirse y un programa de trabajo. Modelado. Esta actividad abarca la creación de modelos que permiten al desarrollador y al cliente entender mejor los requisitos del software y el diseño que logrará satisfacerlos. Construcción. Esta actividad combina la generación del código (ya sea manual o automatizado) y la realización de pruebas necesarias para descubrir errores en el código. Despliegue. El software (como una entidad completa o un incremento completado de manera parcial) se entrega al cliente, quien evalúa el producto recibido y proporciona información basada en su evaluación. El marco de trabajo descrito en la visión general de la ingeniería de software lo completa una serie de actividades sombrilla. Las actividades típicas en esta categoría incluyen: Seguimiento y control del proyecto de software: permite que el equipo de software evalúe el progreso comparándolo con el plan de proyecto y así tomar las acciones necesarias para mantener el programa. Gestión de riesgo: evalúa los riesgos que pudieran afectar los resultados del proyecto o la calidad del producto. Aseguramiento de la calidad del software: define y conduce las actividades requeridas para asegurar la calidad del software. Revisiones técnicas formales: evalúa los productos del trabajo de la ingeniería de software en un esfuerzo encaminado en descubrir y eliminar los errores antes de que éstos se propaguen a la siguiente acción o actividad. Medición: define y recolecta mediciones del proceso, el proyecto y el producto para ayudar a equipo a entregar software que satisfaga las necesidades del cliente; se puede usar en conjunto con todas las actividades del marco de trabajo o actividades sombrilla. Gestión de la configuración del software: maneja los efectos del cambio a través del proceso del software.



Gestión de la reutilización: define los criterios para la reutilización de productos del trabajo (se incluyen componentes del software) y establece mecanismos para la creación de componentes reutilizables. Preparación y producción del producto de trabajo: abarca las actividades requeridas para crear productos del trabajo como modelos, documentos, registros, formatos y listas. Las actividades sombrilla se aplican durante el proceso del software. La Guía del PMBOK considera 5 grupos de procesos para la Dirección de Proyectos y nueve áreas del conocimiento (ver figura 2).

Figura 2. Grupos de procesos y áreas del conocimiento para la Dirección de Proyectos,

según la Guía del PMBOK. La gestión de los grupos de procesos según la Guía del PMBOK tiene el siguiente flujo (ver figura):

Figura 3. Grupos de Procesos de la Dirección de Proyectos.

Fuente Guía del PMBOK, versión 4.



2.1.2. Modelos del proceso del software La elaboración del modelo la componen dos acciones de la ingeniería de software: análisis y diseño. El análisis abarca un conjunto de tareas de trabajo (por ejemplo, la investigación, elaboración, negociación y validación de requerimientos) que conducen a la creación del modelo de análisis (o la especificación de requerimientos). El diseño abarca tareas de trabajos (diseño de datos, diseño arquitectónico, diseño de interfaz y diseño al nivel de componentes) que crean un modelo de diseño (una especificación de diseño).

Figura 4. Acciones que conforman el modelo de la ingeniería de software.

Un modelo de proceso de software es una representación abstracta de un proceso del software que pueden utilizar para explicar diferentes enfoques para el desarrollo del software. Los modelos del proceso son: • Modelo Cascada • Desarrollo Evolutivo o Espiral • Modelo Incremental • Desarrollo Iterativo



Modelo Cascada

Figura 5. Modelo cascada.

Características Desventajas Limitaciones

• Es el más utilizado. • Es una visión del proceso de

desarrollo de software como una sucesión de etapas que producen productos intermedios.

• Para que el proyecto tenga éxito deben desarrollarse todas las fases.

• Las fases continúan hasta que los objetivos se han cumplido.

• Si se cambia el orden de las fases, el producto final será de inferior calidad.

• Se tarda mucho tiempo en pasar por todo el ciclo

• El mantenimiento se realiza en el código fuente

• Las revisiones de proyectos de gran complejidad son muy difíciles.

• No se permiten las iteraciones.

• Los requisitos se congelan al principio del proyecto.

• No existe un proyecto “enseñable” hasta el final del proyecto.

Modelo Espiral

Figura 6. Modelo espiral.



Características Ventajas Desventajas

• Incorpora objetivos de calidad y gestión de riesgos

• Elimina errores y alternativas • Permite iteraciones, vuelta atrás y

finalizaciones rápidas • Cada ciclo empieza identificando:

- Los objetivos de la porción correspondiente - Las alternativas - Restricciones

• Cada ciclo se completa con una revisión que incluye todo el ciclo anterior y el plan para el siguiente

• Utiliza las fases de modelos tradicionales. Se centra en la eliminación de errores y alternativas poco atractivas.

• Su orientación a detectar y prevenir el riesgo evita muchas dificultades.

• Complicado: Consume muchos recursos.

• Las etapas y sus E/S no están claramente definidas.

Modelo Incremental

Figura 7. Modelo incremental.

Características

• Es una repetición de varios ciclos de vida en cascada. • Al final de cada ciclo se entrega una versión parcial del software incrementada con cierta

funcionalidad nueva respecto a las entregas anteriores. • Los ciclos se repiten hasta obtener un producto completo. • Los usuarios disponen antes del software, aunque no sea completo, por lo que pueden sugerir

mejoras. • Se suele aplicar a desarrollos de gran tamaño.



Modelo Iterativo

Figura 8. Modelo Iterativo.

Características

• Es también una repetición de varios ciclos de vida en cascada. • Al final de cada ciclo se entrega una versión completa del software mejorada respecto a la anterior. • Los ciclos se repiten hasta obtener un producto satisfactorio. • Los usuarios deben evaluar el producto en cada iteración y proponer mejoras. • Se suele aplicar en desarrollos en los que los requisitos no están claros, las primeras versiones

pueden ser prototipos que se desechan posteriormente. 2.2. Integración del modelo de capacidad de madurez (IMCM) El Softwate Engineering Institute (SEI, Instituto de Ingeniería de Software) ha desarrollado un modelo completo que se basa en un conjunto de funciones de ingeniería del software que deberían estar presentes conforme organizaciones alcanzan diferentes niveles de madurez del proceso. Para determinar el estado actual de madurez del proceso de una organización, el SEI utiliza un cuestionario de evaluación y un esquema de cinco grados. El enfoque del SEI proporciona una medida de la efectividad global de las prácticas de ingeniería del software de una compañía que se ajusta a las directrices establecidas por la integración del modelo de capacidad de madurez (IMCM). El IMCM representa un modelo completo de 2 formas diferentes:



Figura 9. Formas en que es representada la integración del modelo de capacidad de madurez (IMCM).

2.2.1. Niveles de capacidad (continuo) Cada área del proceso se evalúa de manera formal contra las metas y prácticas específicas y se clasifica de acuerdo con los siguientes niveles de capacidad: Nivel 0: Incompleto. El área del proceso (por ejemplo, la gestión de requisitos) aún no se realiza o todavía no alcanzan todas las metas y objetivos definidos para el nivel 1 de capacidad. Nivel 1: Realizado. Todas las metas específicas del área del proceso (como las definió la IMCM) han sido satisfechas. Las tareas de trabajo requeridas para producir el producto específico han sido realizadas. Nivel 2: Administrado. Todos los criterios del nivel 1 han sido satisfechos. Además, todo el trabajo asociado con el área de procesos se ajusta a una política organizacional definida; toda la gente que ejecuta el trabajo tiene acceso a recursos adecuados para realizar su labor; los clientes están implicados de manera activa en el área de proceso, cuando esto se requiere; todas las áreas de trabajo y productos están “monitoreados, controlados y revisados; y son evaluados n apego a la descripción del proceso”. Nivel 3: Definido. Todos los criterios del nivel 2 se han cumplido. Además, el proceso está “adaptado al conjunto de procesos estándar de la organización de la organización de acuerdo con las políticas de adaptación de la misma, y contribuye a la información de los productos del trabajo, mediciones y otras mejorías del proceso para los activos del proceso organizacional”. Nivel 4: Administrado en forma cuantitativa. Todos los criterios del nivel 3 han sido cumplidos. Además, el área del proceso se controla y mejora mediante mediciones y evaluaciones cuantitativas. “Los objetivos cuantitativos para la calidad y el desempeño del proceso están establecidos y se utilizan como un criterio para administrar el proceso”. Nivel 5: Mejorado. Todos los criterios del nivel 4 han sido satisfechos. Además el área del proceso “se adapta y mejora mediante el uso de medios cuantitativo (estadísticos) para conocer las necesidades cambiantes del cliente y mejorar de manera continua la eficacia del área del proceso que se está considerando”.



La IMCM define cada área del proceso en función de “metas específicas” y de las “prácticas específicas” requeridas para alcanzar dichas metas. Las metas específicas establecen las características que deben existir para que las actividades implicadas por un área del proceso sean efectivas. Las prácticas específicas convierten una meta en un conjunto de actividades relacionadas con el proceso.

Figura 10. Niveles de capacidad del software.

2.2.2. Niveles de madurez (discreto)

Nivel Enfoque Áreas de proceso

Optimización Mejora continua del proceso Innovación organizacional y despliegue Análisis causal y resolución

Gestión Cuantitativa

Gestión cuantitativa Ejecución del proceso organizacional Gestión cuantitativa del proyecto

Definido Estandarización del proceso

Desarrollo de requisitos Solución técnica Integración del producto Verificación Validación Enfoque del proceso organizacional Definición del proceso organizacional Capacitación organizacional Gestión integrada del proyecto Gestión integrada del proveedor Gestión del riesgo Análisis y resolución de la decisión Ambiente organizacional para la integración Equipo integrado

Gestionado Gestión básica del proyecto

Gestión de requisitos Planeación del proyecto Gestión de acuerdos del proveedor Medición y análisis Aseguramiento de la calidad del producto y del proceso Gestión de la configuración

Ejecutado Tabla 1. Áreas del proceso requeridas para alcanzar un nivel de madurez.



2.3. Metodologías de desarrollo de sistemas La Metodología de Desarrollo de Sistemas de Información es un instrumento útil para la sistematización de las actividades que dan soporte al ciclo de vida del software, lo cual permite alcanzar los siguientes objetivos: • Proporcionar o definir Sistemas de Información requeridos que ayuden a conseguir los fines de la

Institución. • Promover la participación activa del Usuario en el proceso de desarrollo de Sistemas de Información. • Dotar a la Institución de productos de software que satisfagan las necesidades de los usuarios. • Mejorar la productividad de las Unidades de Informáticas de la Administración Pública, permitiendo

una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización de software en la medida de lo posible.

• Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.

• Facilitar la operación, mantenimiento y uso de los productos de software obtenidos. 2.3.1. Actores involucrados en el desarrollo de sis temas Administrador de Aplicaciones Es el encargado de mantener un registro actualizado de las aplicaciones, componentes, rutinas y parámetros de comunicación existentes entre las aplicaciones. Administrador de Datos Encargado de mantener un registro actualizado del modelo físico de datos y evaluar el nivel de normalización de los modelos de datos. Administrador de Procesos Es el encargado de mantener un registro y una arquitectura actualizada de los procesos de negocio de la Institución. Analista de Atención a Usuarios Es el responsable de la capacitación de los usuarios y de la implantación de los sistemas de información. Analista de Calidad Es el responsable de planificar, evaluar y realizar las pruebas de calidad del sistema de información, en los hitos determinados por la Metodología. Analista Funcional Es el responsable de modelar los procesos de negocio en el desarrollo de los sistemas de información. Analista de Investigación Tecnológica Es el encargado de proponer y asegurar el uso de tecnologías adecuadas para la implantación del nuevo sistema. Analista de Seguridad Informática Es el encargado de verificar y velar por el cumplimiento de las políticas de seguridad Informática de la Institución. Analista de Sistemas Es el responsable de llevar a cabo toda la fase técnica del desarrollo del sistema de información, especialmente el Modelamiento de Requerimientos y de Tecnología.



Analista de Soporte Técnico Es el encargado de verificar y proveer todo lo necesario para la fase de construcción, pruebas e implantación de los sistemas. Analista de Telecomunicaciones Es el encargado de proponer y asegurar que los modelos sean óptimos para no afectar las comunicaciones. Área Cliente Unidad que solicita un sistema de información o un cambio en el mismo. Puede ser cualquier unidad organizacional de la Institución que requiera la implantación de un sistema de información para optimizar su labor o para modificar el existente atendiendo a un cambio en la normatividad o una mejora. Comité de Gestión Conformado por el Coordinador del Proyecto, Líder Usuario, Ejecutivo del Proyecto y Sectorista (opcional) Adicionalmente podrán incorporarse otros participantes que se requiera dependiendo de la naturaleza del proyecto. Tiene las siguientes funciones: • Participar en las reuniones de gestión, en las cuales se comunica el avance y situación del proyecto. • Aprobar las versiones de la Formulación del Proyecto. Ejecutivo de Proyecto Persona de rango ejecutivo, preferentemente del área para la cual se está desarrollando la solución y cuya presencia otorga importancia al proyecto. Tiene las siguientes funciones: • Aprobar la versión inicial del documento Formulación del Proyecto. • Participar en los momentos claves como el inicio y término de cada fase o cuando el Coordinador del

Proyecto estime conveniente convocar su participación. • Proponer al Líder Usuario y Equipo Usuario como participantes del Proyecto. • Proponer, conjuntamente con el Coordinador del Proyecto, al Equipo Consultivo. • Resolver los casos de controversia que se puedan generar en el Comité de Gestión en base a la

opinión institucional. • Promover la participación de los usuarios. Equipo de Implantación Está conformado por algunos integrantes del equipo de trabajo y se encargan de llevar a cabo la implantación del sistema. Equipo de Usuarios Pertenecen al área usuaria directamente comprometida con el proyecto, pudiendo ser cualquier unidad organizacional de la Institución. Son propuestos por el Ejecutivo del Proyecto y son designados por el Jefe de la Unidad Organizacional donde laboran. Participan activamente durante todo el proceso de desarrollo del sistema de información. También son miembros del equipo de usuarios los integrantes del área responsable de la Atención a Usuarios de la unidad de informática. Coordinador del Proyecto Persona responsable del éxito del proyecto. Tiene la visión y la experiencia necesaria para coordinar los esfuerzos y organizar las actividades realizadas por los integrantes de un grupo de trabajo enfocados en el desarrollo de una solución. Tiene las siguientes funciones: • Velar por el éxito y cumplimiento de los objetivos propuestos en el proyecto. • Organizar y gestionar las diversas variables del proyecto: Participantes, costos, plazos, riesgos y

calidad. • Establecer hitos de control del proyecto. • Verificar la ejecución del proyecto. • Proponer al Líder Técnico y Equipo de Trabajo como participantes del Proyecto.



• Proponer, conjuntamente con el Ejecutivo del Proyecto, al Equipo Consultivo. • Motivar al personal del proyecto. • Resolver conflictos. • Generar acciones preventivas y correctivas. • Definir y organizar las actividades. Líder Usuario Persona que conoce al detalle la operatividad y funcionalidad del área usuaria solicitante. Es propuesto por el Ejecutivo del Proyecto y designado por el Jefe de unidad organizacional donde labora. Tiene las siguientes funciones: • Participar activamente en todas las fases del Proyecto. • Actuar como intermediario entre el Coordinador del Proyecto y los usuarios. • Definir y centralizar requerimientos de los usuarios. • Aprobar los entregables dirigidos a los usuarios finales que elabora el Equipo de Trabajo a lo largo

del proyecto. Operador Es el responsable de la instalación del sistema en el ambiente de producción. Participante de Actividad Es el encargado de ofrecer todo el apoyo técnico necesario para que el responsable de la actividad pueda culminar con éxito la actividad encomendada. Programador de Sistemas Es el responsable de la creación del código que dará lugar al producto resultante sobre la base del Modelamiento de Tecnología.

Figura 11. Actores involucrados en el proceso de desarrollo de sistemas.

2.3.2. Actividades necesarias para desarrollar sist emas de información El desarrollo de sistemas de información implica dar seguimiento de forma sistematizada a las siguientes actividades: • Planificación inicial y modelado del área de aplicación (modelado del negocio). • Recopilación de requerimientos. • Análisis y diseño. • Implementación.



• Pruebas • Evaluación de resultados y retroalimentación. • Puesta en funcionamiento. Una de la metodología de desarrollo de sistemas más utilizada durante los procesos de creación del software es el Racional Unified Process (RUP).

Descripción general Características principales

• El RUP es un proceso de ingeniería de software.

• Utiliza el paradigma de orientación a objetos para su descripción.

• Es un marco de proceso configurable para satisfacer necesidades específicas.

• Implementa las mejores prácticas de desarrollo de software.

• Dirigido por casos de uso. Los casos de uso capturan requerimientos funcionales y representan piezas de funcionalidad que brindan un resultado de valor al usuario.

• Centrado en una arquitectura. Comprende los aspectos estáticos y dinámicos más importantes del sistema.

• Iterativo e incremental. El trabajo se divide en piezas pequeñas o miniproyectos; cada uno proveyendo un subproducto incremental.

Casos de uso

Descripción general Principios generales de los casos de uso

• Secuencia de pasos que un sistema realiza para proveer un resultado de valor para un actor particular.

• Se enfocan en la funcionalidad del sistema y necesitan de requerimientos adicionales para proveer una especificación completa de los requerimientos de software.

• Se concentra en el qué y no en el cómo. • Los casos de uso se utilizan principalmente para capturar los

requerimientos de comportamiento de un sistema. • Posicionan los requerimientos de software en contexto:

muestran cómo el sistema provee valor a sus patrocinadores al mismo tiempo que los hace más fáciles de entender.

• No existen en aislamiento. Se deben considerar aspectos económicos, tecnológicos, políticos y del negocio y cómo el sistema afectará esos aspectos.

• Son una herramienta sintética más que analítica. El problema es que nos ahogamos en un mar de requerimientos.

Figura 12. Relación entre los casos de uso y los requerimientos.

Los diagramas de casos de uso se emplean para visualizar el comportamiento de un sistema, un subsistema o una clase, de forma que los usuarios puedan comprender cómo utilizar ese elemento y de



forma que los desarrolladores puedan implementarlo. La figura 4.20 muestra un diagrama de casos de uso para modelar el comportamiento de un teléfono móvil.

Figura 13. Ejemplo de diagrama de casos de uso

Los diagramas de casos de uso muestran un conjunto de casos de uso, actores y sus relaciones, estas pueden ser relaciones de dependencia, generalización y asociación. También pueden contener paquetes, que se emplean para agrupar elementos del modelo en partes mayores. Usos comunes Los diagramas de casos de uso se emplean para modelar la vista de casos de uso estática de un sistema. Esta vista cubre principalmente el comportamiento del sistema (los servicios visibles externamente que proporciona el sistema en el contexto de su entorno). Cuando se modela la vista de casos de uso estática de un sistema, normalmente se emplearán los diagramas de casos de uso de una de las dos formas siguientes: 1. Para modelar el contexto de un sistema Modelar el contexto de un sistema implica dibujar una línea alrededor de todo el sistema y asegurar qué actores queda fuera del sistema e interactúan con él. Aquí, se emplearán los diagramas de casos de uso para especificar los actores y significado de sus roles. 2. Para modelar los requisitos de un sistema. El modelado de los requisitos de un sistema implica especificar qué debería hacer el sistema (desde un punto de vista externo), independientemente de cómo se haga. Aquí se emplearán los diagramas de casos de uso, para especificar el comportamiento deseado del sistema. De esta forma, un diagrama de casos de uso permite ver el sistema entero como una caja negra; se puede ver qué hay fuera del sistema y cómo reacciona a los elementos externos, pero no se puede ver cómo funciona por dentro. Por ejemplo, la figura 14 muestra el contexto de un sistema de validación de tarjetas de crédito, destacando los actores en torno al sistema. Se puede ver que existen Clientes, de los cuales hay dos categorías (Cliente individual y Cliente corporativo). Estos actores representan los roles que juegan las personas que interactúan con el sistema. En este contexto, también hay actores que representan a otras instituciones tales como Comercio (que es donde los Clientes realizan una transacción con tarjeta para comprar un artículo o servicio) y Entidad Financiera (que presta servicio como sucursal bancaria para la cuenta de la tarjeta de crédito). En el mundo real estos dos actores probablemente sean sistemas con gran cantidad de software.



Figura 14. Modelado del contexto de un sistema

La figura 14 extiende la anterior (figura 13), aunque omite las relaciones entre los actores y los casos de uso, añade casos de uso adicionales que son invisibles para el cliente normal, aunque son comportamientos fundamentales del sistema. Este diagrama es valioso porque ofrece un punto de vista común para los usuarios finales, los expertos del dominio y los desarrolladores para visualizar, especificar, construir y documentar sus decisiones sobre los requisitos funcionales del sistema. Por ejemplo, Detectar fraude de tarjeta es un comportamiento importante tanto para el Comercio como para la Entidad Financiera. Análogamente, Informe estado de Cuentas, es otro comportamiento requerido del sistema por varias entidades.

Figura 15. Modelado de los requisitos de un sistema

Elementos estructurales Los elementos estructurales en UML, en su mayoría, son las partes estáticas del modelo y representan cosas que son conceptuales o materiales. Clases Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase implementa una o más interfaces. Gráficamente se representa como un rectángulo que incluye su nombre, sus atributos y sus operaciones.



Figura 16. Representación gráfica de clases

Interfaz Una interfaz es una colección de operaciones que especifican un servicio de una determinada clase o componente. Una interfaz describe el comportamiento visible externamente de ese elemento, puede mostrar el comportamiento completo o sólo una parte del mismo. Una interfaz describe un conjunto de especificaciones de operaciones, pero nunca su implementación. Se representa con un circulo, como podemos ver en la figura 4.6, y rara vez se encuentra aislada sino que más bien conectada a la clase o componente que realiza.

Figura 17. Representación gráfica de una interfaz

Colaboración Define una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Las colaboraciones tienen una dimensión tanto estructural como de comportamiento. Una misma clase puede participar en diferentes colaboraciones. Las colaboraciones representan la implementación de patrones que forman un sistema. Se representa mediante una elipse con borde discontinuo, como en la figura 18.

Figura 18. Representación gráfica de una colaboración

Casos de Uso Un caso de uso es la descripción de un conjunto de acciones que un sistema ejecuta y que produce un determinado resultado que es de interés para un actor particular. Un caso de uso se utiliza para organizar los aspectos del comportamiento en un modelo. Un caso de uso es realizado por una colaboración. Se representa como en la figura 4.8, una elipse con borde continuo.



Figura 19. Representación gráfica de casos de uso

Clase Activa Es una clase cuyos objetos tienen uno o más procesos o hilos de ejecución por lo y tanto pueden dar lugar a actividades de control. Una clase activa es igual que una clase, excepto que sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos. Se representa igual que una clase, pero con líneas más gruesas.

Figura 20. Representación gráfica de una clase activa

Componentes Un componente es una parte física y reemplazable de un sistema que conforma con un conjunto de interfaces y proporciona la implementación de dicho conjunto. Un componente representa típicamente el empaquetamiento físico de diferentes elementos lógicos, como clases, interfaces y colaboraciones.

Figura 21. Representación gráfica de componentes

Nodos Un nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional que, por lo general, dispone de algo de memoria y, con frecuencia, de capacidad de procesamiento. Un conjunto de componentes puede residir en un nodo.

Figura 22. Representación gráfica de nodos



Estos siete elementos vistos son los elementos estructurales básicos que se pueden incluir en un modelo UML. Existen variaciones sobre estos elementos básicos, tales como actores, señales, utilidades (tipos de clases), procesos e hilos (tipos de clases activas) y aplicaciones, documentos, archivos, bibliotecas, páginas y tablas (tipos de componentes). Elementos de comportamiento Los elementos de comportamiento son las partes dinámicas de un modelo. Se podría decir que son los verbos de un modelo y representan el comportamiento en el tiempo y en el espacio. Los principales elementos son los dos que siguen. Interacción Es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular para conseguir un propósito específico. Una interacción involucra otros muchos elementos, incluyendo mensajes, secuencias de acción (comportamiento invocado por un objeto) y enlaces (conexiones entre objetos). La representación de un mensaje es una flecha dirigida que normalmente con el nombre de la operación.

Figura 23. Representación gráfica de mensajes

Maquinas de estados Es un comportamiento que especifica las secuencias de estados por las que van pasando los objetos o las interacciones durante su vida en respuesta a eventos, junto con las respuestas a esos eventos. Una maquina de estados involucra otros elementos como son estados, transiciones (flujo de un estado a otro), eventos (que disparan una transición) y actividades (respuesta de una transición).

Figura 24. Representación gráfica de estados

Elementos de agrupación Los elementos de agrupación forman la parte organizativa de los modelos UML. El principal elemento de agrupación es el paquete, que es un mecanismo de propósito general para organizar elementos en grupos. Los elementos estructurales, los elementos de comportamiento, incluso los propios elementos de agrupación se pueden incluir en un paquete. Un paquete es puramente conceptual (sólo existe en tiempo de desarrollo). Gráficamente se representa como una carpeta conteniendo normalmente su nombre y, a veces, su contenido.



Figura 25. Representación gráfica de paquetes

Elementos de anotación Los elementos de anotación son las partes explicativas de los modelos UML. Son comentarios que se pueden aplicar para describir, clasificar y hacer observaciones sobre cualquier elemento de un modelo. El tipo principal de anotación es la nota que simplemente es un símbolo para mostrar restricciones y comentarios junto a un elemento o un conjunto de elementos.

Figura 26. Representación gráfica de notas

Relaciones con UML Relaciones Existen cuatro tipos de relaciones entre los elementos de un modelo UML. Dependencia, asociación, generalización y realización. Dependencia Es una relación semántica entre dos elementos en la cual un cambio a un elemento (el elemento independiente) puede afectar a la semántica del otro elemento (elemento dependiente). Se representa como una línea discontinua, posiblemente dirigida, que a veces incluye una etiqueta.

Figura 27. Representación gráfica de dependencias

Asociación Es una relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. La agregación es un tipo especial de asociación y representa una relación estructural entre un todo y sus partes. La asociación se representa con una línea continua, posiblemente dirigida, que a veces incluye una etiqueta. A menudo se incluyen otros adornos para indicar la multiplicidad y roles de los objetos involucrados.

Figura 28. Representación gráfica de asociaciones



Generalización Es una relación de especialización / generalización en la cual los objetos del elemento especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre). De esta forma, el hijo comparte la estructura y el comportamiento del padre. Gráficamente, la generalización se representa con una línea con punta de flecha vacía.

Figura 29. Representación gráfica de generalización

Realización Es una relación semántica entre clasificadores, donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Se pueden encontrar relaciones de realización en dos sitios: entre interfaces y las clases y componentes que las realizan, y entre los casos de uso y las colaboraciones que los realizan. La realización se representa como una mezcla entre la generalización y la dependencia, esto es, una línea discontinua con una punta de flecha vacía.

Figura 30. Representación gráfica de realización

Arquitectura de software El conjunto de decisiones significativas acerca de la organización de un sistema, la selección de los elementos estructurales, sus interfaces y comportamiento y la composición de estos elementos en subsistemas progresivamente más grandes. La arquitectura de software no se limita a definir la estructura y el comportamiento: incluye usabilidad, rendimiento, robustez, reutilización, restricciones económicas y tecnológicas, además de preocupaciones sobre la estética.

Figura 31. Las 4 +1 vista.



Flujo de trabajo de RUP según las fases de desarrol lo de sistemas

Figura 32. Flujo de trabajo de RUP según las fases de desarrollo de sistemas.

Factores críticos de éxito en el desarrollo • Alta participación de los actores involucrados en el proceso (equipo de trabajo). • Alta participación de los usuarios finales de las herramientas. • Establecer canales de comunicación sólidos. • Establecer un horizonte de largo plazo en los requerimientos, pero de oportunidad en su

implementación. • Identificar y divulgar indicadores de avance del proceso. • Recursos económicos. • Sostenibilidad del proyecto. • Administración formal del proceso. 2.4. Etapas en los proyectos de creación de softwar e Un proyecto para el desarrollo de software es finalmente un “proyecto” y por lo mismo su administración sigue las reglas de éste: 1. La planeación es la etapa más importante. Algunos escritores han dicho que el tiempo invertido en una buena planeación se recupera en 10 veces en la ejecución. Lo primero que tenemos que hacer es Definir el Proyecto. ¿Cuál es el objetivo por el cual lo vamos a desarrollar? ¿Qué queremos alcanzar? ¿Quién o quienes lo van a utilizar? ¿Cuándo lo van a utilizar? En el caso de los proyectos de software a esta etapa se le denomina DISEÑO, y consiste en un documento que describe los objetivos educativos, el usuario y contexto; las herramientas de desarrollo incluyendo la plataforma en la que se trabajará no sólo el desarrollo sino principalmente ya la aplicación. 2. A partir de saber con toda claridad pedagógica e informática adonde queremos llegar, principia el DISEÑO (Planeación). La planeación nos ofrece herramientas que la hacen más clara: Mapas mentales, diagramas y a través de ellas podemos identificar los componentes de la solución definida y sobre todo fijar las ESPECIFICACIONES para cada uno. Estas especificaciones cubren: las de calidad de ese módulo o componente; el tiempo en el cual se deberá alcanzar dicho resultado, el costo del mismo y el responsable o responsables de dicho logro.



En la etapa de planeación, podemos auxiliarnos de herramientas como las gráficas de Gant, el PERT o la Ruta Crítica; que son representaciones que nos auxilian a visualizar con más claridad y uniformidad la secuencia adecuada de las actividades que habremos de seguir para alcanzar nuestro objetivo. Ésta es una especie de aplicación de mapas mentales al diseño de software. Se inicia con una “lluvia de ideas” que permite clarificar el proyecto y contar con elementos de planeación y resulta estimulante ya que no hay mapas “correctos” o “incorrectos”. Se puede revisar y repetir cuantas veces sea necesario. Es similar a otras técnicas (B. PAPER, TKJ, entre otras) que utilizan papel para escribir ideas o problemas que se van conjuntando en la pared. Una aportación importante es que evita la crítica prematura de las ideas y para cada ítem hay tiempo límite (3 – 5 minutos como máximo por etapa). Permite registrar las ideas, evaluar y seleccionar esas ideas y detallar para poder costear y calendarizar el proyecto. En cuanto a los datos generales podemos utilizar el Modelo NOM para enmarcar el proyecto y después detallar cada ítem. La forma de trabajo de esta técnica es atractiva por su lógica, ya que de un tema central, determinamos subtemas o aspectos del tema central y los proyectamos en líneas, como ramas, nombrando cada rama. Después estos subtemas los volvemos a subdividir, limitándonos en inicio a tres niveles para ver el tema en su conjunto; pero dejando la oportunidad de seguir subdividiendo para llegar a todos los niveles significativos en cada rama. Para cada elemento del mapa (sub-subtema), se define qué medio se empleará y se pone su inicial a un lado. Por ejemplo: T = Texto, M = Música, S = Sonido (narración o efectos), G = Gráfico (imágenes fijas), N = Animación, V = Video; y se determinan en qué ramas o subrayas va a participar el usuario y el tipo de participación y se anota C, para indicar que se requiere un Código en ese lugar. Algo interesante que enfatiza esta técnica es distinguir cuando se cuenta con los insumos, definiendo entonces el lugar del que se recabarán; o cuando no se cuenta con ellos. Otra ventaja que presenta es llevarnos a identificar la complejidad de desarrollo de las diferentes ramas y señalar tanto la más sencilla como la más compleja. A partir de esta reflexión nos pide identificar cuál es la rama más atractiva no sólo para el desarrollador sino especialmente para el financiador. En materia del presupuesto nos lleva a dos escenarios: uno óptimo y otro mínimo, restando a las inversiones o gastos aquellos insumos con los que ya cuenta la institución. Nos lleva también a una fase indispensable: la reconsideración del presupuesto. Para ello, sugiere regresar al mapa mental y determinar si se puede reducir en ambición o alcance el proyecto, ajustándolo a los recursos disponibles y sobre todo a no desanimarnos. El objetivo del ejercicio es prever para evitarse luego sorpresas y desilusiones, en el peor de los casos, pensar en etapas. Abundando sobre el tema del presupuesto, uno de los secretos para contar con un presupuesto correcto es el de identificar, en cada módulo, las actividades con las que se alcanzará el objetivo del mismo. La planeación tiene un sentido sistémico y que depende el corte de la realidad que se haga, la aplicación de los nombres para cada nivel de la taxonomía. Así, una vez contando con él: • OBJETIVO (Qué), éste lo descomponemos en: • METAS (Qué y cuándo), que son partes del objetivo que alcanzaremos en un tiempo determinado.

Una vez teniendo éstas, identificamos las: • ESTRATEGIAS (Cómo), y dependiendo de la complejidad del proyecto, puede haber Políticas,

Líneas de Acción u otras categorías dentro de este apartado, que básicamente me dice como alcanzar las metas de mi objetivo.

• ACTIVIDADES (Qué voy a hacer). En una forma matricial, cada uno de estos elementos, tiene especificaciones, de calidad, tiempo y costo; así como un responsable.



Mientras que las especificaciones de calidad son definidas en un orden descendente, es decir la suma de metas debe dar el objetivo; la suma de estrategias debe dar la meta; y la suma de actividades dan la estrategia. El tiempo y costo, se trabajan de forma ascendente. La suma de los tiempos de las actividades dan el de la estrategia; la suma de los tiempos de las estrategias, dan el de la meta y la suma de los tiempos de las metas dan el del objetivo, salvo por las actividades realizadas en paralelo (en cuyo caso se puede utilizar la ruta crítica). Algo similar ocurre en el presupuesto: la suma de los costos de las actividades dan el costo de la estrategia; la suma de los costos de las estrategias dan el costo de la meta y la suma de los costos de las metas dan el del objetivo. Por ello, para poder contar con un presupuesto realista, debemos ubicarnos en nuestra realidad y evitar las dos tentaciones al planear. Considerar que contamos con más de lo que en realidad tenemos o partir de que nada tenemos. Ambos casos son engañosos. No se puede decir que “se cuenta” con algo que tiene la institución, hasta no aclarar que verdaderamente se puede utilizar y por la otra parte, la forma más sencilla de que un tomador de decisiones nos diga que no, es pretendiendo que se nos dote de todo para un proyecto. No cabe duda de que presupuestar adecuadamente es también un reto a la inventiva del desarrollador. ¿Con cuántos insumos podremos contar aunque no se nos asignen? ¿Cómo ganarnos la confianza con nuestros resultados para que cada vez sea menor el desgaste de la negociación? Ya en la realidad de la elaboración de presupuesto se recomienda elaborar una matriz. En una entrada (filas) tener todas las actividades con sus especificaciones, y en las columnas abrir los rubros de gasto. Conviene reflexionar, al hacer el estimado de costos, que casi siempre estamos sólo considerando los directos adicionales; y que no repercutimos la parte alícuota de alquiler, teléfono, comunicaciones, servicios generales, entre otros. Tratándose de un proyecto de cómputo, es muy importante ir detallando lo que se espera que el programa haga. Esto lo pueden hacer en un lenguaje coloquial, es decir, como si lo platicaran (pseudocódigo). 3. Ya contando con nuestra planeación a detalle, viene la etapa del Desarrollo. Es decir, llevar a cabo lo que se planeó. La planeación nos debe dejar un documento tan detallado como sea posible sobre lo que vamos a hacer, cómo lo vamos a hacer y cómo lo vamos a evaluar. Contando con el pseudocódigo, el programador puede pasarlo a un conjunto de instrucciones, rutinas o procedimientos, descripción de objetos, propiedades, mensajes y eventos, que ya son entendibles para el software que opera en la computadora. La codificación es un elemento muy importante, pero debemos contar en paralelo los insumos didácticos previstos: ilustraciones, videos, textos, reactivos, entre otros. Una parte importante es cuando integramos los elementos que fueron elaborados por separado y los convertimos en una unidad y evaluamos el funcionamiento del protocolo, primeramente y del programa en su totalidad, más adelante. En un proyecto informático, que bien lo debería ser en los de todo tipo, resalta la importancia de contar con un prototipo. Al usar el prototipo se puede evaluar el diseño, incorporar cualquier cambio en un siguiente prototipo, y eventualmente, refinar el diseño para la aplicación o sistema final. El prototipo es una forma en la que se obtiene una idea global de la funcionalidad entera del programa (aunque ninguna de las funciones opere todavía en detalle); y simultáneamente, permite ver el funcionamiento a fondo de algunos módulos representativos del desempeño del conjunto. Después de ver funcionar nuestros prototipos podemos terminar o ajustar nuestra planeación con la elaboración final de los requerimientos.



Dice Gándara: “La versión final deberá ser no solamente eficaz y correcta, sino fácil de usar, amigable; la amigabilidad se evalúa por referencia a la facilidad de aprendizaje, la retención de lo aprendido, el número de errores en la ejecución sucesiva por parte del usuario, y la experiencia subjetiva de uso (que debe ser agradable y no tensa y frustrante). Todos estos criterios pueden evaluarse formal e informalmente, mediante procesos de observación directa (o ‘etnográficos’), por encuestas y cuestionarios estadísticamente significativos, mediante simulaciones de uso y ‘protocolos’ de observación/ejecución - a veces apoyados por dispositivos como cámaras de video o grabadoras de audio ante las cuales los usuarios comentan y describen lo que están haciendo. Independientemente del procedimiento, lo crucial es reconocer que, a final de cuentas, es la opinión del usuario la vale, independientemente de los ‘expertos’ opinen”. 4. Entrega y evaluación. Si hemos seguido fielmente nuestra planeación y hemos aprovechado la retroalimentación de los usuarios con el prototipo, la liberación del programa se convierte en algo de rutina. A manera de conclusión Desafortunadamente eso no es lo común. Una mala o incompleta planeación, actividades que nos brincamos o requerimientos siempre dinámicos de los usuarios, llevan a que esta etapa se alargue más de lo debido. Por ello, enfatizaremos que una planeación adecuada que nos permita acordar un objetivo con especificaciones que realmente resuelven el problema detectado, manejadas sistémicamente a través de sus especificaciones en los diferentes niveles que lo componen; permitirán un éxito de nuestro desarrollo. En caso contrario podemos enfrentarnos a un desaliento, desperdicio de recursos y “vacunación” en contra del desarrollo de software educativo. A continuación se listas las etapas y secuencia de actividades durante el proceso de creación del software (ciclo de vida del software conforme el modelo de referencia ISO 12207): 1. MODELAMIENTO DE PROCESOS DE NEGOCIO Identificación de los Procesos de Negocio Identificación de los Actores del Entorno del Negocio Descripción de los Casos de Uso del Negocio Especificación de reglas de Negocio Especificación de Necesidades Externas a la Unidad de informática 2. MODELAMIENTO DE REQUERIMIENTOS Y ANALISIS DEL SISTEMA DE INFORMACION Determinación del Alcance del Sistema 2.1. OBTENCIÓN DE REQUERIMIENTOS Obtención del Modelo de Casos de Uso del Sistema Determinación de Subsistemas de Análisis Especificación de la Interface de Usuario Identificación de Perfiles y Diálogos Especificación del Comportamiento Dinámico de la Interface Especificación de Formatos de Impresión 2.2. ANÁLISIS DE LOS CASOS DE USO Identificación de Clases Asociadas a un Caso de Uso Descripción de la Interacción de Objetos 2.3. ANÁLISIS DE CLASES Análisis de Clases 2.4. ANALISIS DE PAQUETES Análisis de Paquetes



3. DISEÑO DEL SISTEMA 3.1. ELABORACIÓN DEL MODELO DE DATOS Elaboración del Modelo Conceptual de Datos Elaboración del Modelo Lógico de Datos Normalización del Modelo Lógico de Datos 3.2. ELABORACIÓN DEL MODELO DE PROCESOS DEL SISTEMA DE INFORMACION Obtención del Modelo de Procesos del Sistema 3.4. ESPECIFICACION DE INTERFACES CON OTROS SISTEMAS Especificación de Interfaces con otros Sistemas 3.5. DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA 3.6. DISEÑO DE LA ARQUITECTURA DE MÓDULOS DEL SISTEMA 4. DESARROLLO 4.1. CONSTRUCCIÓN Y PRUEBAS DEL SISTEMA DE INFORMACIÓN Estándares de programación y procedimientos Documentación 4.2. PRUEBAS DEL SISTEMA Defectos y fallas del software La prueba del sistema Documentación de la prueba 5. IMPLANTACIÓN DEL SISTEMA DE INFORMACIÓN Entrega del sistema Entrenamiento Documentación 6. PUESTA EN MARCHA DEL SISTEMA 7. MANTENIMIENTO DEL SISTEMA Problemas de mantenimiento Técnicas y herramientas para el mantenimiento Los procesos del ciclo de vida del software según el Estándar ISO/EIC 12207 son: Procesos principales del ciclo de vida : Son los procesos para iniciar o llevar a cabo el desarrollo, operación o mantenimiento del software. Procesos de apoyo del ciclo de vida : Un proceso de apoyo es el que apoya a otro proceso como parte esencial del mismo. Un proceso de apoyo se emplea y ejecuta por otro proceso, según sus necesidades. Procesos organizativos del ciclo de vida : Se emplean por una organización para establecer e implementar una infraestructura constituida por procesos y personal asociado al ciclo de vida y para mejorar continuamente esta infraestructura. Se usan habitualmente fuera del ámbito de proyectos y contratos, contribuye a la mejora de la organización.



Figura 33. Procesos del ciclo de vida del software según el Estándar ISO/EIC 12207.

2.5. Confiabilidad en el diseño de sistemas La aplicación de conceptos, metas y procedimientos de confiabilidad ha estado prácticamente limitada a instalaciones existentes en operación y mantenimiento. La aplicación de los conceptos de confiabilidad se ha reflejado en los resultados al mejorar la disponibilidad de las instalaciones, lo cual a su vez ha redundado en un incremento de valor de las mismas. Si se busca maximizar el valor del dinero invertido (optimizar los costes) durante el ciclo de vida del proyecto, la aplicación de los conceptos, metas y procedimientos de confiabilidad no debería limitarse a la etapa de ingeniería, éstos deberían ser aplicados a lo largo de todo el ciclo de vida del proyecto asociado a la instalación. Esto es lo que se conoce como Confiabilidad desde Diseño (CDD). La aplicación de la confiabilidad tendrá un mayor impacto en los resultados, si se aplica desde la etapa más temprana de un proyecto, “Durante la fase de diseño”, razón por la cual, se hace necesaria la generación de un documento que especifique las acciones a seguir en confiabilidad durante la etapa de diseño de proyectos.



La metodología propuesta es una guía para la dirección y gestión de los proyectos en mantenimiento desde la etapa de diseño, se dan las acciones y lineamientos de confiabilidad que deben considerarse durante la fase de diseño de los proyectos, específicamente la fase de Definición y Desarrollo (Visualización, Conceptualización y Definición). La metodología puede ser usada por el personal que participa durante las fases de diseño de los proyectos y tiene el propósito de asegurar, normalizar y uniformar de una manera ordenada la aplicación de los conceptos, procedimientos y metodologías de confiabilidad durante la fase de diseño e integrarlas o “atarlas” con las actividades y documentos que se generan durante el desarrollo de los proyectos de ingeniería. Entendiendo como proyectos de ingeniería a aquellos proyectos para la operación de nuevas instalaciones, ampliaciones y “revampings” dentro de todas las áreas operacionales de la empresa. Un aspecto a considerar a lo largo del ciclo de vida de un proyecto es lograr un balance adecuado entre productividad y seguridad a un costo óptimo. Esto tiene un efecto directo en la confiabilidad, y por lo tanto debe considerarse como parte de los aspectos de confiabilidad a ser aplicados en el ciclo de vida del proyecto. Se consigue a través de la gestión del riesgo definiendo las estrategias para cada uno de los siguientes aspectos, algunos de los cuáles están estrechamente relacionados: • Diseño (Diseño robusto vs. Diseño bajo costo). • Estrategia de mantenimiento y operación. • Gestión de eventos anormales. • Desincorporación del activo. • Manejo de personal y cultura corporativa. • Responsabilidad en seguridad. • Gestión de escasez de recursos Confiabilidad en las etapas del proyecto

Figura 34. Confiabilidad en el diseño de sistemas.

La aplicación de confiabilidad en la fase de diseño se divide en tres fases: Visualización, Conceptualización y Definición. Cada fase viene esencialmente dividida en Acciones de confiabilidad y Lineamientos de confiabilidad. En la primera se dan las acciones, procedimientos o documentos a realizar o generar durante la fase correspondiente. También se especifica el responsable



(grupo o posición dentro del proyecto), los ejecutores (participantes) y en algunos casos, una breve explicación de la acción con ejemplos concretos que ayuden a aclarar las ideas. Los lineamientos de confiabilidad, se refieren a acciones y sugerencias ("tips" básicos) a llevar a cabo para facilitar y ayudar la aplicación de los conceptos de confiabilidad durante la fase correspondiente. La aplicación de confiabilidad en la fase de diseño de los proyectos debe regirse por los siguientes principios fundamentales: La aplicación de confiabilidad en la fase de diseño, no requiere la intervención de un grupo de especialistas adicionales o con conocimientos particulares, ni tampoco cambiar la estructura organizacional (a excepción, si se detectan deficiencias en la misma). Los mismos participantes habituales de los proyectos son los que deben aportar la confiabilidad a través de sus acciones y la generación de documentos. • Concientizar a los participantes de los proyectos de ingeniería, la importancia y la necesidad de

aplicar confiabilidad desde diseño como forma de maximizar la utilización del activo o el valor del dinero invertido a lo largo del ciclo de vida del proyecto.

• La aplicación de los conceptos y procedimientos de ingeniería de control de riesgo son fundamentales para incrementar la confiabilidad de las instalaciones. Existe una estrecha vinculación entre productividad y seguridad y debe establecerse un balance entre ambos, aún cuando lo que se busca es lograr altos niveles de productividad y seguridad. Estos aspectos deben considerarse desde la fase de diseño y como parte integral de aplicación de confiabilidad.

• Aún cuando los conceptos de confiabilidad puedan ser comprendidos por la dirección media, ingenieros y otros participantes de un proyecto, es muy importante la participación y la comprensión de la alta dirección.

Durante la ejecución de los proyectos y a fin de asegurar la aplicación exitosa de conceptos de confiabilidad en la fase de diseño, es importante cumplir ciertos lineamientos que son comunes en cada fase del proyecto. A continuación, se citan los más importantes: • Mantener siempre presente la alineación del proyecto con los requerimientos del plan de negocios. • Identificar el riesgo de desviación con respecto al plan de negocios y hacer un análisis continuo de

los potenciales riesgos identificados que podrían impedir el cumplimiento de esos lineamientos. • Asegurar que cada participante de un proyecto comprenda la aplicación de los conceptos de

confiabilidad durante la fase de diseño de los proyectos. Esto incluye a la dirección encargada del negocio, personal de mantenimiento y operaciones y todos los ingenieros que participan en el proyecto.

• Asegurar que los recursos estarán disponibles para cuando se requieran. Este proceso requiere el concurso de equipos multidisciplinarios y deben tener planificado el tiempo para asegurar su participación. Este tiempo debe contemplar, además de reuniones de trabajo, tiempo para recopilación de información y trabajo de preparación.

• Asegurar que la información estará disponible y que los participantes de los proyectos sepan como tener acceso a la misma antes que ésta sea utilizada.

• No separar las actividades de confiabilidad de las actividades de ingeniería. Estas actividades no deben ser realizadas de manera paralela sino integradas.

• Evitar en lo posible realizar cambios en los miembros claves del equipo durante la fase de Conceptualización y Definición. Está demostrado que puede afectar negativamente los resultados del proyecto.

• Comunicar los resultados de aplicar confiabilidad a la dirección y al equipo de trabajo.



2.6. Medición del desempeño de sistemas computariza dos (benchmarking)

Foro de discusión

Medición del desempeño de sistemas computarizados La medición del desempeño de sistemas computarizados nos permite evaluar las fortalezas, pero principalmente las debilidades sobre las que tenemos que trabajar para convertirlas en fortaleza; no obstante, la medición del desempeño de sistemas computarizados está determinada por dos factores críticos: la elección de las métricas correctas de desempeño así como las metodologías y herramientas que permita manejar la vasta cantidad de datos para determinar el nivel de dichas métricas. ¿Cómo podemos medir el desempeño de los sistemas co mputarizados? “El “benchmark” es el punto de referencia sobre el cual hemos de compararnos y medirnos. Reflexiona y argumenta y describe otras formas de medición del desempeño de sistemas computarizados.

Sistema de educación a distancia UDB: http://moodle.udb.edu.sv/ead/

Hoy en día, dado el ambiente de alta competitividad en el que se desenvuelven las organizaciones, resulta de suma importancia evaluar y monitorear continuamente aquellas variables que determinan el desempeño y que son críticas para el éxito de las organizaciones. Si se eligen correctamente un conjunto de criterios que representen un balance del desempeño global, y se miden en forma acertada, la organización en su conjunto alineará sus esfuerzos en la búsqueda de sus metas y en el cumplimiento de su estrategia. Una metodología muy utilizada para medir el desempeño de los sistemas computarizados es el benchmark o benchmarking. Se denomina “Benchmarking” al estudio comparativo en áreas o sectores de empresas competidoras con el fin de mejorar el funcionamiento de la propia organización. “El “benchmark” es el punto de referencia sobre el cual hemos de compararnos y medirnos. Tenemos que comprender las fortalezas de nuestros competidores, cómo funcionan y cuando sea el caso, adaptar y construir sobre sus prácticas excelentes las nuestras para lograr ser líderes”1. Ante todo significa dos cosas:

a) Proponerse metas utilizando normas externas y objetivos, “aprendiendo de los otros”. b) Fijar metas comparables, cuantificables, comprendiendo la naturaleza del proceso. Es decir, sin

olvidar los conocimientos y la experiencia de directivos y trabajadores, y la cultura empresaria. El Benchmarking debe comenzar al menos por tener en claro cuáles son los factores clave del negocio (por ejemplo: ¿qué volumen de combustible debo vender para "pagar" los costos fijos?, ¿qué porcentaje aporta el resto de los productos a la rentabilidad del negocio?

1 http://www.microsoft.com/spain/empresas/rrhh/benchmarking.mspx, Benchmarking como instrumento para la

mejora continuada de RRHH, Raúl Píriz.



Figura 35. Comparación del benchmarking con el ciclo de Deming.

El proceso de “Benchmarking” 1) Determinar qué actividades serán las que mejor se adapten al negocio, para medirlas. 2) Determinar los factores clave de estas actividades, orientándolas hacia el crecimiento del valor que puedan añadir. 3) Buscar las empresas más avanzadas en estas actividades, ya sean competidoras o empresas de sectores distintos. 4) Medir las prácticas más avanzadas, de modo que permitan cuantificar prestaciones y reconocer cómo se consiguen tales resultados. 5) Medir las propias prestaciones y compararlas con las mejores. 6) Desarrollar planes para igualar y superar las prácticas más avanzadas. 7) Obtener el compromiso con todos los niveles de la organización. 8) Poner en práctica el plan y supervisar los resultados. Cada una de las fases del “Benchmarking” -planificación, ejecución y aplicación de mejoras- requiere habilidades distintas.



Figura 36. Flujograma proceso de benchmarking

Valoración de algunos Factores Claves de Éxito en l a aplicación del Benchmarking a) Planeación estratégica. b) Cultura de la innovación. c) Satisfacción del cliente. d) Administración basada en procesos. e) Mejoramiento continuo. “El proceso de creación del software” Tercera Edición. Agosto de 2014. Elaborado y Presentado por Milton José Narváez Sandino, Ingeniero en Computación y Sistemas, para la asignatura Ingeniería de Software. Universidad Don Bosco (UDB) – Facultad de Ingenierí a – Escuela de Ingeniería en Computación (EIC).



FUENTES DE CONSULTA

BIBLIOGRAFIA BOOCH, GRADY; RUMBAUGH, JAMES; JACOMSON, IVAR (2007). El lenguaje unificado de modelado, Manual de referencia. Segunda edición, Editorial Pearson Addison Wesley. BRUGGE, BERND (2001). Ingeniería de software orientada a objetos, Editorial Pearson Prentice Hall. BARRIENTOS HERBERT (__). Metodología para el desarrollo de las herramientas informáticas de la REyE, San José, Costa Rica. IEEE (2004). Guide to the Software Engineering Body of Knowledge, 2004 version. A project of the IEEE Computer Society and Professional Practices Committee. PFLEEGER, SHARI LAWRENCE (2002). Ingeniería de software – Teoría y práctica, primera edición, Editorial Pearson Prentice Hall. PRESSMAN, ROGER S. (2006). Ingeniería de software, un enfoque práctico, sexta edición. Editorial McGrawHill, México. SÁNCHEZ, SALVADOR; SICILIA, MIGUEL ÁNGEL; RODRÍGUEZ, DANIEL (2012). Ingeniería del Software. Un enfoque desde la guía SWEBOK, Primera Edición, Editorial Alfaomega. SCHACH, STEPHEN R. (2005). Análisis y diseño orientado a objetos con UML y el proceso unificado. Editorial McGraw-Hill. SCHACH, STEPHEN R. (2002). Ingeniería de software clásica y orientada a objetos, sexta edición. Editorial McGrawHill, México. SOMMERVILLE, IAN (2005). Ingeniería de software, sexta edición, Editorial Pearson Addison Wesley. MURCH, R. (2000). Project Management: Best Practices for IT Professionals, Prentice-Hall, Columbus. INTERNET Périssé, Marcelo Claudio. Proyecto Informático / Una Metodología Simplificada. Citado de internet del URL: http://www.cyta.com.ar/biblioteca/bddoc/bdlibros/proyectoinformatico/libro/c6/c6.htm. Píriz, Raúl. Benchmarking como instrumento para la mejora continuada de RRHH. Citado de internet del URL: http://www.microsoft.com/spain/empresas/rrhh/benchmarking.mspx. Reflexiones sobre los costos y la metodología del desarrollo del software educativo. Citado de internet del URL: http://ana-educadistancia.blogspot.com/2007/05/reflexiones-sobre-los-costos-del.html.

Documents

02-El proceso de creaci n del software(07AGO14)€¦ · de software, sin importar su tamaño o complejidad. Además, el marco de trabajo del proceso abarca un conjunto de actividades