Please enable JavaScript.

Coggle requires JavaScript to display documents.

ROLES EN EL DESARROLLO DE SOFTWARE - Coggle Diagram

- - - - Un miembro no capacitado no entenderá el lenguaje técnico utilizado por el resto de los miembros. Muchas veces, entenderá una cosa diferente a la expresada por sus pares. Esto es común debido a diferencias en el lenguaje.
      - Un miembro no capacitado, no conoce el ciclo de vida del desarrollo, ni los problemas que se presentan durante el desarrollo. Sería muy bueno que el miembro pudiera aportar sus conocimientos en su dominio del problema durante todo el ciclo de desarrollo del proyecto. Saber cuando exigir y cuando ceder. Conocer los estándares de desarrollo, de documentación, de aseguramiento de la calidad
      - Un miembro no capacitado no presupuesta su involucración en el proyecto, sólo su participación. Este solo hecho reduce las posibilidades de éxito del proyecto. También aumenta los tiempos de desarrollo, disminuye la calidad del sistema, aumentan los riesgos de rechazo del sistema por parte de la comunidad de clientes, etc.
      - Lo anterior sugiere que es necesario contar con “miembros comprometidos” para desarrollar correctamente el proyecto. Aspectos a considerar son los de crear un lenguaje común entre el equipo de desarrollo, así como hacer que entiendan claramente sus deberes y obligaciones.
- - - - Algunos de los objetivos de un administrador de proyecto son los siguientes:
        
        Tener el producto “a tiempo”, “bajo presupuesto” y con los requisitos de calidad definidos.
        
        Terminar el proyecto con los recursos asignados.
        
        Coordinar los esfuerzos generales del proyecto, ayudando a cada uno de sus integrantes a cumplir sus objetivos particulares. Al final, se cumplirá el objetivo general.
        
        Cumplir con éxito las diferentes fases de un proyecto, utilizando herramientas de administración.
        
        Cumplir con las expectativas del cliente.
    - - CORDINE TODAS LAS CATIVIDADES
        
        Entregar un plan de trabajo general basado en diagramas Gantt y de flujo de actividades, apoyado con el plan de trabajo de cada rol.
        
        El plan de trabajo general deberá contener estimaciones de horas-hombre de cada actividad, que permita estimar los recursos humanos requeridos.
        
        Desarrollar el contrato junto con el cliente.
        
        Realizar actividades de organización, dirección y control.
        
        Trabajar con los analistas para estudiar las necesidades de los clientes y los requisitos del sistema.
    - - El administrador deberá tener una comunicación fluida con cada miembro del equipo para analizar problemas particulares, y si es necesario, tomar acciones correctivas. En particular, el administrador de proyecto deberá apoyar de la siguiente forma a cada rol:
        
        • Analistas: Trabajar con los analistas para estudiar las necesidades de los clientes y los requisitos del sistema.
        
        • Diseñadores: Trabajar con ellos para diseñar la arquitectura del sistema de acuerdo con los recursos asignados al proyecto. El administrador de proyecto requiere la arquitectura del sistema para determinar el plan de trabajo de los demás roles.
        
        • Tésters: Trabajar con ellos para determinar que tipo de testeo deberá utilizarse, y con que profundidad, de acuerdo con los requisitos de seguridad en el diseño del sistema y de los recursos disponibles. Los resultados de los tests ayudan a determinar el éxito del proyecto, preocupación principal de la administración de proyecto.
        
        • Aseguradores de calidad: La información provista por este rol ayuda a conocer el avance del proyecto. Este rol observa si cada una de las actividades se realiza de acuerdo a las especificaciones planificadas.
        
        • Ingenieros de manutención: Generalmente la manutención utiliza una cantidad muy importante de recursos del proyecto. Por ello, el administrador debe conocer los planes de manutención, y de ser necesario, ajustarlos a los recursos disponibles.
        
        • Documentadores: El administrador de proyecto tomará como referencia los documentos controlados por los documentadores para elaborar planes y la evaluación del proyecto.
        
        • Clientes: El administrador de proyecto deberá administrar la relación con los clientes, desarrollando una comunicación fluida con éstos, y siendo la cara visible del proyecto.
- - - - Un analista es una persona con capacidades de comunicación, debido a que deberá tener un contacto estrecho con el cliente. Por lo mismo anterior, debe ser una persona sociable, expresando sus ideas en forma clara en un lenguaje común con el cliente. También debe tener la capacidad de escuchar y entender al cliente. Se espera que los analistas tengan un alto grado de desarrollo de su inteligencia emocional.
        Los analistas deben conocer y manejar perfectamente los métodos y las tecnologías de apoyo para realizar las fases de análisis. Además, se espera creatividad, lo que le permitirá establecer diferentes alternativas de modelos para la arquitectura del sistema a construir.
    - - • Preparar un documento con preguntas a realizar al cliente durante las entrevistas.
        
        • Determinar las fechas de reunión con el cliente.
        
        • Generar un documento de especificación de requisitos de usuario en base a los acuerdos alcanzados en la primera reunión.
        
        • Presentación del documento de especificación al cliente en la siguiente reunión.
        
        • De ser necesario, realizar las modificaciones al documento de especificación de requisitos de usuario y presentarlas al cliente en la próxima reunión. Repetir esta actividad las veces que sea necesario.
        
        • Estudiar la metodología de diseño.
        
        • Explorar las herramientas CASE a utilizar.
        
        • Generar los diagramas de arquitectura.
        
        • Revisar los diagramas de arquitectura con los diseñadores.
        
        • De ser necesario, realizar las modificaciones a los diagramas.
        
        • Presentar los diagramas de arquitectura finales.
        
        • Construir el documento de requisitos de software.
        
        • Revisar el documento con los ingenieros de aseguramiento de la calidad y cliente, realizando modificaciones de ser necesario.
- - - - • Para sistemas de tamaño pequeño y mediano, el diseño arquitectónico es realizado por una o dos personas calificadas. Deben mostrar habilidad inusual para sintetizar soluciones construibles por sobre un gran conjunto de restricciones.
      - • Generalmente son los más capacitados para realizar decisiones estratégicas debido a su experiencia previa en la construcción de sistemas similares.
      - • No son necesariamente los desarrolladores con más experiencia.
      - • Deben tener habilidades de programación adecuadas.
      - • Deben conocer muy bien la metodología de diseño utilizada, así como sus herramientas de apoyo.
  - - - • Organizar el sistema en subsistemas.
      - • Identificar concurrencias inherentes al problema.
      - • Asignar los subsistemas a procesos y tareas.
      - • Seleccionar un administrador de datos.
      - • Identificar recursos globales y determinar mecanismos de acceso.
      - • Elegir un enfoque para implementar el control de la ejecución.
      - • Considerar condiciones de borde.
- - - - • Menor cantidad de problemas de testeo.
      - • Aumento de la productividad de los programadores.
      - • Aumento de la eficiencia en la manutención del programa.
      - • Aumento de la eficiencia en la modificación del programa.
      - Adicionalmente, otros objetivos importantes son:
      - • Reducir el tiempo de codificación, aumentando la productividad del programador.
      - • Disminuir el número de errores que ocurren durante el proceso de desarrollo.
      - • Disminuir el esfuerzo de corregir errores en secciones del código que se encuentran deficientes, remplazando secciones cuando se descubren técnicas más confiables, funcionales o eficientes.
      - • Disminuir los costos del ciclo de vida del software.
  - - - El desarrollo de las herramientas utilitarias y rutinas comunes debe realizarse antes de la entrega del documento que contiene el diseño arquitectónico del sistema. Estos utilitarios ayudan al programador a realizar la codificación más rápida debido a que puede focalizarse sólo en la codificación de los factores especificados en el documento de diseño en vez de ocupar tiempo en la codificación de otras rutinas que son necesarias en todo programa. En estas funciones utilitarias, el programador debe construir algunas rutinas que considere necesarias, dependiendo del tipo de aplicación. Algunas herramientas de desarrollo han integrado herramientas que contienen rutinas comunes para cada programa, así como rutinas para ambientes específicos. Este factor debe ser considerado en la selección del lenguaje y herramientas de desarrollo.
      - Un factor muy importante en la construcción de un sistema es el paradigma de programación utilizado. Uno de los paradigmas muy utilizados es el orientado a objetos, el cual tiene varias ventajas sobre otras metodologías de programación.
      - Así mismo, existen varias técnicas de diseño y análisis orientado a objetos. Dicha elección es vital para la elección del lenguaje de programación. Por ello, si la metodología de diseño utilizada es orientada al objeto, se sugiere utilizar un lenguaje orientado a objetos.
      - En un equipo de programación, la revisión personal consiste en inspeccionar el código escrito por otro programador, con el propósito de evaluarlo. La evaluación incluye buscar errores de diseño, programación, estilo y documentación. De esa forma, es posible mantener el código en forma más eficiente durante las actividades de programación, disminuyendo los posibles problemas durante las actividades de integración.
  - - - • Administrador de proyecto: El programador debe entregar un reporte con los resultados de las actividades de programación cuando el administrador lo solicite. Debe además. Ayudarle al administrador en la estimación de tiempos y costos de las actividades de programación.
      - • Analista: Deben interactuar con los analistas para determinar el ambiente apropiado para el sistema.
      - • Diseñador: El rol de programador depende mucho del rol de diseñador, debido a que debe utilizar herramientas adaptadas a la metodología utilizada en las actividades de diseño. El diseñador también le ayuda al programador a
      - seleccionar el lenguaje de programación adecuado.
      - • Téster: El programador debe interactuar con el téster para determinar una forma apropiada de construir los tests y de testear los programas. El programador debe estar presente durante el testeo de código, cuando situaciones no esperadas suceden o es necesario realizar pequeñas modificaciones al código.
      - • Administrador de configuración: El programador debe entregar la última versión del diseño al administrador de configuración. El programador debe pedir la última versión del diseño al administrador de configuración, debiendo atender los diferentes pedidos de cambio del código. El programador puede solicitar cambios en otras partes del sistema a través del administrador de la configuración. La petición se realiza llenando el formulario correspondiente y enviándoselo al administrador de configuración.
      - • Ingeniero de manutención: El programador tiene mucha influencia en el rol de manutención, debido a que si el código está claro, será fácil de mantener. Dependiendo de las metodologías y herramientas empleadas, será más fácil o más difícil mantener los sistemas.
      - • Asegurador de calidad: El asegurador de calidad debe verificar la calidad del sistema construido. El programador deberá entregarle su plan de trabajo al asegurador de calidad.
- - - - El objetivo principal de la labor de téster es el de diseñar tests que en forma sistemática, permita eliminar diferentes clases de errores, realizando esto con la mínima cantidad de tiempo y esfuerzo.
        
        • Proveer una buena indicación de la confiabilidad del software y algunas indicaciones de la calidad del software.
        
        • Demostrar que las funciones del sistema parecen estar funcionando de acuerdo a sus especificaciones.
        
        • Construir buenos casos de tests que tengan altas probabilidades de encontrar errores aún no descubiertos.
        
        • Aplicar métodos para diseñar casos de tests efectivos.
    - - Los tésters deben utilizar una metodología que en forma sistemática, organizada y estructurada, les permita detectar y corregir, los errores y defectos introducidos en el proceso de desarrollo del sistema. Típicamente, se utilizan dos técnicas para ello: el test de la caja blanca y el test de la caja negra.
        
        Los tests de caja blanca corresponden a un método de diseño de casos de tests que utilizan la estructura de control del diseño procedural para derivar los casos de tests.
        
        Usando este método, el téster puede derivar casos de tests para lo siguiente:
        
        • Asegurarse que todos las trayectorias independientes en un módulo han sido visitadas al menos una vez.
        
        • Ejercitar todas las decisiones lógicas en sus lados verdadero y falso.
        
        • Ejecutar todos los loops en sus límites y sobre sus límites operacionales.
        
        • Ejercitar estructuras de datos internas para asegurar su validez.
    - - • Participar en la revisión de los requisitos del sistema.
        
        • Construir un plan de testeo.
        
        • Coordinarse con los diseñadores para incluir el test del diseño en el documento.
        
        • Ejecutar los tests de bajo nivel.
        
        • Ejecutar los tests de mediano nivel.
        
        • Ejecutar los tests de alto nivel.
        
        • Construir la documentación del proceso de tests.
- - - - • Administrador de proyecto: El asegurador de calidad revisa el plan de administración de proyecto, para asegurarse que se crea y que se sigue.
      - • Analista: El asegurador de calidad revisa la especificación de requisitos de usuario y de software, para asegurarse que es una representación correcta y completa de las expectativas del cliente, y que es suficientemente clara para todos en el grupo de desarrollo, especialmente para el diseñador.
      - • Diseñador: El asegurador de calidad revisa la fase de diseño arquitectónico, para asegurarse que el diseñador seleccionó la metodología apropiada y que el producto final de esta fase cumple con requisitos de rendimiento, diseño y
      - • Programador: El asegurador de calidad revisa la fase de diseño detallado, para asegurarse que el código producido cumple con la especificación de requisitos establecida y que cumple con los atributos de calidad en uso.
      - • Téster: El asegurador de calidad revisa el plan de testeo, para asegurarse que es creado, que es adecuado para el proyecto específico, y que se aplica en cada fase del proceso de desarrollo hasta la entrega del producto.
      - • Documentador: El asegurador de calidad revisa la documentación, para asegurarse que corresponde con el software desarrollado, y que cumple con el estándar en uso.
      - • Administrador de configuración: El asegurador de calidad revisa los registros de cambios, errores y de configuración, para asegurarse de que los cambios han sido implementados apropiadamente, y que las
  - - - De entre las actividades del Asegurador de Calidad, la más importante es la de participar en las revisiones técnicas formales (RTF). Si estas revisiones están bien conducidas, son la forma más efectiva de encontrar, revelar y corregir errores mientras aún es barato encontrarlos y arreglarlos.
      - El estándar ESA incluye revisiones en las fases RU/R, RS/R, DA/R y DD/R. No obstante, las RTFs son especialmente requeridas en la fase de diseño arquitectónico. Esto, debido a que las actividades de diseño introducen entre el 50 y 65% de todos los errores durante el proceso de desarrollo. Se ha demostrado que las RTFs descubren del orden del 75% de los errores de diseño.
      - Los objetivos de las RTFs son: 1. descubrir errores en funciones, lógica e implementación en cualquiera de las representaciones del software; 2. verificar que el software bajo revisión cumple con los requisitos; 3. asegurarse que el software ha sido representado de acuerdo al estándar en uso; 4. alcanzar software que es desarrollado en forma uniforme; y 5. hacer el proyecto más manejable.
- - - - • Si los roles producen un ítem de configuración de software que ha sido identificado y puesto en el repositorio de administración de la configuración de software.
      - • Si pertenecen al Cuerpo de Control de Cambios.
      - • Si solicitan un cambio de ítem de la configuración de software.
      - • Si la persona debe implementar un cambio.
- - - - Una de las metas necesarias de tener en cuenta en toda organización de desarrollo de software que se considere exitosa es que el software que evoluciona, continúe satisfaciendo las expectativas de los usuarios durante dicho proceso. Para lograr esta
      - meta, es necesario aplicar prácticas de ingeniería de software durante la evolución del producto. La mayoría de estas prácticas tratan de crear y modificar software de forma de maximizar la probabilidad de satisfacer las expectativas de sus usuarios. Otras prácticas tratan de asegurar que el producto cumplirá con las expectativas de dichos usuarios. Estas últimas son ampliamente conocidas como la validación y verificación de software (V&V).
      - Validación se refiere al proceso de evaluación del software al final de su proceso de desarrollo para asegurarse que está libre de fallas y cumple con sus requisitos. Una falla se define como un comportamiento incorrecto del producto. Validación se refiere al proceso de determinar si el producto en una determinada fase del proceso de desarrollo cumple con los requisitos establecidos en la fase anterior.
  - - - • Correctitud: En que grado el producto está libre de fallas.
        
        • Consistencia: En que grado el producto es consistente consigo mismo y con otros productos.
        
        • Necesidad: En que grado lo que hay en el producto es necesario.
        
        • Suficiencia: En que grado el producto es completo.
        
        • Rendimiento: En que grado el producto satisface los requisitos de rendimiento.
        
        Estos objetivos proveen un marco en que es posible determinar la aplicabilidad de varios enfoques y técnicas de V&V.
  - - - El ingeniero a cargo del proceso de V&V de software debe interactuar con otros roles.
      - A continuación se detallan las interacciones más relevantes:
      - • Analista: El ingeniero de V&V tiene la responsabilidad de verificar que el analista especifica correctamente los requisitos de usuario y de software. Debe además, verificar la documentación producida en diferentes fases del desarrollo del sistema.
      - • Diseñador: El ingeniero de V&V debe evaluar el nivel de concordancia entre los requisitos de usuario y el modelo diseñado del sistema, buscando errores de interpretación en los requisitos, y características faltantes o mal concebidas.
      - • Programador: El ingeniero de V&V debe verificar la correctitud del proceso de traducción de diseño de software a su implementación en código. La verificación de código es la última oportunidad de encontrar y eliminar errores pudiesen causar costos innecesarios y atrasos por realizar actividades de testeo sobre código pobre.
      - • Téster: Se requiere coordinación con este rol en la ejecución de los casos de tests, de acuerdo con las necesidades del cliente.
- - - - • Administrador de proyecto: La información del repositorio ayuda al administrador a realizar los planes, agenda y presupuestos del proceso de desarrollo de software.
      - • Administrador de configuración: El administrador de configuración y documentador comparten documentación a través del repositorio. Cuando se autoriza un cambio de un documento, debe ser reflejado en el sistema de administración de documentos. El propósito de esto es evitar inconsistencias y
      - permitir al equipo de desarrollo el acceso a la versión más reciente de cada documento.
      - • Validación y verificación: El documentador mantiene una relación con el ingeniero de V&V a través del registro elaborado durante las reuniones de revisión. Este registro, así como las minutas elaboradas son utilizadas durante el desarrollo de los planes y agendas de las reuniones de revisión.
      - • Asegurador de calidad: A los aseguradores de calidad se les ha confiado que garanticen la calidad del producto a ser desarrollado. Toda la documentación del proyecto es parte del producto. Por ello, parte del trabajo del asegurador de calidad es de garantizar la calidad de la documentación generada.
      - • Ingeniero de manutención: La documentación generada durante el desarrollo del producto es usado durante la fase de operación y manutención del sistema. Si durante esta fase se realizan cambios, será necesario reflejarlos en la documentación correspondiente para mantener la consistencia de la documentación con la operación del sistema.
  - - - El documentador requerirá herramientas para la elaboración de documentos (minutas, documentos de acuerdos, manual de usuario) y herramientas de apoyo para la elaboración y administración del repositorio de documentos. Dentro del primer conjunto de herramientas se encuentran las siguientes:
      - • Editor de texto, que permite elaborar documentos fácilmente y almacenarlos en diferentes formatos, incluyendo HTML. Debe incluir una herramienta para el chequeo ortográfico y de gramática.
      - • Navegador Web y editor HTML, que permita editar y publicar documentos HTML, proveyendo diversas funciones.
- - - - • Modificar el software para adaptar nuevas funciones o modificar algunas funciones existentes.
      - • Modernizar el software por medio de cambios al sistema.
      - • Asegurarse de que el equipo de desarrollo esté informado de los errores encontrados en el sistema.
  - - - • Establecer y coordinar la organización de manutención.
      - • Definir los procesos de evaluación e información.
      - • Definición de una secuencia estándar de eventos para cada requisito de manutención.
      - • Establecer un sistema de registro e información de las actividades de manutención.
      - • Definición de las actividades de revisión y evaluación.
  - - - • Administrador de proyecto. Debe supervisar y controlar los cambios requeridos, utilizando los estándares del proyecto.
      - • Analista. Debido a que probablemente será necesario adaptar o perfeccionar el sistema durante el tiempo, los analistas requerirán determinar nuevos requisitos.
      - • Diseñador. Es necesario involucrar al diseñador para rediseñar las partes del sistema que requieren ser corregidas, agregadas o perfeccionadas.
      - • Programador. La naturaleza de las actividades requeridas para cubrir la fase de manutención está estrechamente ligada con el rol de programador. Durante el uso del sistema es probable que se detecten errores, siendo necesario comunicárselos al equipo de desarrollo para su reparación.
      - • Téster. Debe testear las partes que han sido modificadas para chequear si están adecuadas para ser liberadas como parte del sistema.
      - • Asegurador de calidad. Es responsable de asegurar que el resultado del producto es de la calidad definida por el estándar en uso.
      - • Validación y verificación. Es responsable de revisar que el cliente quede completamente satisfecho con el producto entregado.
- - - - Un cliente comprometido se relacionará principalmente con el administrador de proyecto y con los analistas en forma frecuente. No obstante, también necesitará relacionarse con otros roles con el propósito de controlar, monitorear y aceptar el sistema. A continuación se detalla dichas relaciones:
      - • Administrador de proyecto. El cliente comprometido llevará toda la relación formal del proyecto a través de su administrador. En otras palabras, toda la comunicación formal entre las dos partes del proyecto se hace a través de estas dos personas. El cliente deberá además, cuidar la relación con el equipo de desarrollo.
      - • Analista. El cliente comprometido participará en reuniones sistemáticas de análisis, dirigidas por los analistas. Deberá además participar en las RTFs de análisis, tales como las fases de revisión RU/R y RS/R.
      - • Diseñador: El cliente comprometido debe participar en las fases de revisión DA/R y DD/R junto a los diseñadores.
      - • Programador. El cliente comprometido debe participar en la fase de revisión DD/R junto a los programadores.
      - • Téster. El cliente debe preparar el plan de aceptación parcial y plan de aceptación definitiva, con apoyo del téster. Además, deberá trabajar con el téster para apoyar la construcción del plan de testeo.
      - • Asegurador de calidad. El cliente comprometido debe apoyar al asegurador de calidad en su búsqueda de diferencias entre los requisitos de usuario y las funcionalidades implementadas en el sistema.