h1

Metodologia de Desarrollo de Sofware*

11/29/2006

Wizdoc [Icon By Buuf]  Tips & Tricks
*Basada en RUP[1]

Fases

Fase Objetivo(s) Entregable(s)
Incepción
  • Desarrollar el análisis de negocio hasta el punto necesario para justificar la puesta en marcha del proyecto.
  • Delimitar el alcance del sistema propuesto:
    • Qué debemos cubrir con el proyecto de desarrollo:
      • Recopilación de requisitos del sistema.
      • Definición de criterios de evaluación/éxito.
    • Qué debe cubrir la arquitectura.
    • Límites dentro de los cuales se buscarán riesgos críticos.
    • Delimitar estimaciones de costo, calendario y recuperación de la inversión.
  • Aprovisionamiento de los recursos con que inicia el proyecto:
    • Las reglas del juego[2]
    • Estaciones de trabajo
    • Ambiente de desarrollo
  • Documento de contexto del sistema
  • Documento preeliminar de arquitectura tecnológica
  • Elaboración
    • Recopilación y refinamiento de los requisitos:
      • Identificación de actores.
      • Identificación de casos de uso.
      • Identificación de flujos de trabajo y procesos del sistema.
      • Identificación y/o definición de la estructura de la base de datos.
      • Identificación de componentes de la interfaz de usuario:
        • Navegación y flujos de pantallas
        • Detalle de pantallas y las validaciones sobre los campos que contienen
      • Generación del modelo de diseño del sistema.[3]
    • Refinamiento de la arquitectura tecnológica
      • Análisis y diseño de la arquitectura:
        • Identificar dependencias con otros sistemas
        • Recopilar/documentar mejores prácticas del dominio del problema y plasmarlas en el diseño de la arquitectura.
      • Pruebas de concepto.[4]
      • Construcción de un proyecto base.[5], [6]
      • Construcción de un demo o maqueta.[7]
  • Matriz de requerimientos contra productos
  • Documento de casos de uso
  • Documento de definición de base de datos
  • Documento de procesos
  • Documento de interfaz de usuario
  • Documento de modelo de diseño
  • Documento de arquitectura tecnológica
  • Proyecto Base (interno)
  • Demo o maqueta (externo)
  • Documento de viabilidad del proyecto[8]
  • Construcción
    • Construcción de los componentes que integran al sistema[9]:
      • Scripts de generación o modificación de las estructuras en la base de datos.
      • Construcción de los componentes de persistencia.
      • Construcción de los componentes de negocio.
      • Construcción de los componentes de presentación.
      • Construcción de los componentes de integración.
    • Validación de los componentes que se van construyendo por parte del usuario final o enlace correspondiente:
      • Desarrollo de prototipos con funcionalidad incremental.
      • Generación de componentes adicionales mediante control de cambios autorizados.[10]
      • Pruebas unitarias de los componentes desarrollados.
  • Componentes funcionales que integran al sistema
  • Bitácoras acerca de requerimientos no funcionales del sistema
  • Transición
    • Lograr que el sistema y los componentes que lo integran cumplan con los requerimientos plasmados en la fase de incepción:
      • Realizar pruebas integrales sobre los componentes desarrollados.
      • Realizar pruebas de estrés sobre el sistema en su conjunto.
      • Realizar pruebas de aceptación con el usuario (verificar que los componentes del sistema cumplan con las expectativas).
      • Corregir cualquier incidencia detectada y reiniciar el ciclo de pruebas.
    • Dar capacitación al usuario final en el uso del sistema desarrollado.
    • Dar capacitación a los usuarios de IT con respecto a la transferencia del conocimiento (mantenimiento, despliegue) del sistema.
    • Generación de los manuales de operación e instalación del sistema.[11]
  • Matrices de pruebas
  • Tracking de incidencias detectadas y su resolución
  • Material de capacitación para los usuarios finales, IT y de soporte técnico
  • Manuales de operación e instalación del sistema[11]
  • Carta(s) de aceptación de los servicios y productos realizados
  • Carta(s) de cierre de proyecto y liberación de factura
  • Principios básicos y mejores prácticas

    Principio Descripción
    Desarrollo de software iterativo Dada multitud de factores que intervienen en el desarrollo de un sistema IT, no es posible definir un plano estático del sistema y seguirlo al pie de la letra. La mayoría de las veces, dicho plano sufrirá modificaciones, pues se integrarán nuevos requerimientos, limitaciones arquitectónicas o un mejor entendimiento del problema original. Para prevenir o mitigar los riesgos inherentes a esta dinámica, lo más recomendable es refinar las especificaciones mediante prototipos. Dichos prototipos pueden comenzar por un top-bottom[12], agregando funcionalidad con cada iteración realizada. Por ejemplo:

    Iteración Descripción/funcionalidad Objetivo de prototipo
    1 Pantallas HTML sin funcionalidad Validar que las pantallas definidas por el usuario son de su agrado o poseen una distribución de usabilidad correcta.
    2 Se agrega validación JavaScript a las pantallas Validar que las validaciones requeridas por el usuario son congruentes.
    3 Se agrega conexión a base de datos, se recuperan catálogos de la base y se despliegan en los combos () de las pantallas. Validar el despliegue de las pantallas como una aplicación web en el contexto de un framework de desarrollo (por ejemplo, Struts o Tapestry), probar pools de conexiones, verificar accesibilidad a catálogos en base de datos y si ya existe, probar la infraestructura de persistencia (por ejemplo, Hibernate o simples DAOs).
    4 Agregar validaciones de negocio (sencillas) Permite al usuario verificar validaciones sencillas en el servidor, asimismo proporciona una vista previa de la infraestructura de negocio utilizada (por ejemplo EJBs o el framework de desarrollo Spring).
    N Prototipo con funcionalidad casi completa Permite al usuario visualizar el sistema antes de iniciar las pruebas de aceptación, que por la naturaleza iterativa del desarrollo ya deberán ser mínimas.
    Administración de requerimientos Por falta de una buena administración de requerimientos fracasan cerca del 85% de los proyectos[13]. Para no convertirse en una estadística, es necesario apoyarse en el siguiente checklist:

    • Recopilar y documentar TODOS los requerimientos.
    • Separar los requerimientos por tipo:
      • De usuario: la lista de tareas para llevar a cabo un objetivo. Esto se traduce en los casos de uso.
      • De negocio: los objetivos del sponsor: bajar costos, mejorar rendimiento, cambiar de hardware. Esto se debe plasmar en la arquitectura tecnológica.
      • Funcionales: qué salida da una entrada. Esto puede combinarse con los requerimientos de usuario y de negocio para refinar los casos de uso.
      • No funcionales: tareas secundarias necesarias para llevar a cabo exitosamente el proyecto. Por ejemplo, poblar la base de datos de pruebas.
      • De proceso: limitaciones técnicas que influyan en todo lo demás. Por ejemplo, que el sponsor insista en desarrollar el sistema usando la metodología definida por el PMBOK[14] para administrarlo (proceso no tecnológico); o que el usuario solicite que los web services publicados por el sistema utilicen el framework Axis (proceso tecnológico).
    • Generar una matriz de productos contra requerimientos. Esto facilita el visualizar todo lo que abarca el sistema y permite distribuir cargas de trabajo. Validar con el usuario/sponsor que todo lo que no este en esta matriz, no será tomado en cuenta.
    • Utilizar una herramienta de administración de requerimientos. En sistemas sencillos, bastará Excel; en proyectos complejos es necesario un software especializado (por ejemplo: IBM Rational Requisite Pro).
    • Utilizar una metodología de administración de requerimientos (por ejemplo: el apartado Project Scope Management del PMBOK.[14])
    Usar una arquitectura basada en componentes Una arquitectura basada en componentes facilita la reutilización, asignación de cargas de trabajo y seguimiento de avances (y dado el caso, de defectos). A partir de esta premisa se desprenden algunas buenas prácticas de definición de arquitectura:

    • Siempre hay que validar para qué servidor de aplicaciones y base de datos se está desarrollando el sistema (esto permite prevenir o mitigar riesgos relacionados a integración de plataformas).
    • Tratar lo más que se pueda de no depender de los tipos de datos, componentes o librerías de dichas plataformas. De hecho, sólo por requerimientos de proceso se deberían utilizar estos elementos.
    • Usar Opensource. Los frameworks y herramientas de desarrollo opensource como Hibernate, Spring, Tapestry, Struts, Axis, XMLBeans, JBoss, Glassfish, Eclipse y muchos otros facilitan el trabajo de desarrollo. Siempre enfatizar que opensource no significa mala calidad (por ejemplo: Glassfish es iniciativa de Sun Microsystems, Oracle y la fundación Apache; Eclipse de IBM y Hibernate del JBoss Group).
    • Separar siempre las arquitecturas en N-Capas:
      • Presentación
      • Negocio
      • Persistencia
      • Infraestructura
      • Opcional: Integración
    • Patrones de diseño, mejores prácticas y blueprints. Tanto las plataformas .NET como Java EE tienen mejores prácticas y blueprints publicados para mejorar características tales como facilidad de desarrollo, desempeño, usabilidad y reutilización de código. Incluso éstas están basadas en patrones de diseño definidos desde hace más de diez años[15] por lo que como arquitecto, es indispensable conocer todas estas herramientas.
    • Siempre generar y documentar Pruebas de Concepto sobre los requerimientos.[Ver Prueba de Concepto]
    • Siempre debe generarse un Proyecto Base.[Ver Proyecto Base]
    Modelado Visual del Sistema Siempre es importante poder documentar los componentes de un sistema de forma que puedan ser comprendidos por todos los involucrados en su ciclo de vida. El lenguaje de modelado más utilizado por el momento es UML[16], el cual facilita mucho el análisis y diseño de cualquier sistema por los diferentes diagramas que contiene[17]:

    • Diagramas de comportamiento
      • Diagrama de Casos de Uso. Análisis de requerimientos: especialmente requerimientos de usuario.
      • Diagrama de Estados. Análisis de requerimientos: especialmente requerimientos funcionales.
      • Diagrama de Actividad. Análisis de requerimientos: especialmente requerimientos funcionales que incluyen flujos de negocio.
    • Diagramas de estructura
      • Diagrama de Clases. Diseño: que componentes integran al sistema al nivel más bajo, incluyendo relaciones entre éstos (herencia, multiplicidad, etc).
      • Diagrama de Objetos. Diseño: que instancias de los componentes mencionados en el diagrama de clases integran al sistema.
      • Diagrama de Componentes. Diseño: que componentes a nivel medio integran al sistema. (puede definirse al nivel que se quiera: ya sea 1 componente = 1 capa ó 1 componente = 1 instancia de una clase).
      • Diagrama de Despliegue. Diseño: conceptualmente cómo debería desplegarse el sistema dentro de la infraestructura física del usuario.
      • Diagrama de Paquetes. Diseño: cómo se definen los paquetes/librerías que componen al sistema.
    • Diagramas de Interacción
      • Diagrama de Secuencia/Colaboración.[18] Diseño: cómo se define el comportamiento de un conjunto de componentes a lo largo del tiempo.
    Verificar la calidad del Software Este tema requiere una extensa descripción en sí mismo, sin embargo existen algunos tips que pueden ser de mucha ayuda:

    • La definición primordial: un SQA (Software Quality Assurance) no es un tester; es alguien que audita todos los productos relacionados al ciclo de vida del proyecto y ofrece alternativas a aquello que no cumple con las especificaciones.
    • Contar siempre con un SQA asignado. Este rol debe tomarlo un recurso con capacidad técnica y que demuestre autoridad en la materia: preferentemente el líder tecnológico o el arquitecto del mismo proyecto. De nada sirve un becario externo con un checklist que no conoce el contexto del problema o la solución propuesta.
    • Puede parecer obvio, pero es necesario definir estándares de desarrollo (codificación, nomenclatura, patrones de diseño), documentación (versionamiento, formatos) y proceso (metodologías, procedimientos de liberación).
    • Contar de forma rutinaria con Peer Reviews formales, que incluyan bitácoras de auditorías realizadas y registro de incidencias detectadas.
    • El repositorio debe contener versiones de los documentos correctas; asimismo debe almacenar una versión desplegable del proyecto (por ejemplo: debe compilar correctamente y poder instalarse en un servidor de aplicaciones sin modificaciones mas que en archivos de propiedades y de configuración).
    • Nuevamente: deben existir pruebas de concepto y un proyecto base generado por el arquitecto.
    • En caso de detectar incidencias, una vez que han sido resueltas es necesario correr toda la suite de pruebas desde el principio (nada de: "¡esto si corre en mi maquina y así lo subí al repositorio!").
    • Utilizar una metodología de administración de la calidad (por ejemplo: el apartado Project Quality Management del PMBOK[14] ó el apartado Software Quality del SWEBOK.[19]).
    Control de Cambios El control de cambios corresponde al área de project management, sin embargo es tarea del arquitecto o líder técnico apoyar al project manager a llevar dicho control, determinando dimensionamientos y estimación de impacto para los cambios que se vayan generando por parte del usuario durante las etapas por las que atraviesa el proyecto. Algunos tips esenciales:

    • Utilizar una metodología de administración de requerimientos (por ejemplo: el apartado Project Scope Management del PMBOK.[14]).
    • Determinar dimensionamientos e impacto de nuevos requerimientos en función de la capacidad real de los recursos que implementarán los cambios solicitados.
    • Si es posible, determinar los dimensionamientos en función de las características negociables del cambio (Alcance, Costo, Tiempo, Calidad)[20] y apoyar al project manager para la negociación con el usuario.
    • No tener miedo a decir no o no estar de acuerdo. En más de una empresa, el project manager tiene rol dual de administrador y agente de ventas; por lo que en muchas ocaciones dice que sí a todo lo que propone el usuario. Es indispensable que el arquitecto o líder técnico no permita esta situación, pues el decir que sí a todo sin modificar el plan de trabajo o recursos siempre impactará de forma negativa al proyecto.
    Administración de recursos humanos Todo proyecto depende de recursos humanos. Si el project manager no sabe administrar personal (ya sea por inexperiencia o incapacidad) recae en el arquitecto o líder técnico la responsabilidad de administrar dichos recursos de forma eficiente para llevar a buen término el proyecto. Sin entrar en discuciones acerca de teorías de psicología industrial, el mejor consejo a seguir es el mejor administrador es aquél que guía a su gente y la deja trabajar.

    Un buen libro de referencia es Peopleware[21]. Cito dos comentarios[22] acerca de este libro en Amazon.com (traducción del editor):

    Resumido en una oración, Peopleware nos dice lo siguiente: proporcionar a gente inteligente espacio físico, responsabilidad intelectual y dirección estratégica. DeMarco y Lister abogan por oficinas privadas y ventanas; por crear equipos con objetivos alineados y trabajo individual limitado; por administradores que encuentren buen personal y que depositen su vida en las manos de ese personal. La función del administrador, ellos relatan, no es hacer que la gente trabaje sino hacer posible que la gente trabaje.

    ¿Alguna vez se preguntaron por qué todos en Microsoft tienen su propia oficina, con paredes y una puerta que se cierra? La respuesta está ahí [en el libro]. ¿Por qué los administradores reprimen tanto a sus equipos para hacer las cosas? La respuesta está ahí también. ¿Por qué hay tantos equipos SWAT en Microsoft que son remarcablemente productivos? Principalmente porque Bill Gates ha construido una compañía repleta de administradores que leen Peopleware. No bastan mis palabras para recomendar este libro. Ésta es la publicación que todo administrador de software debe leer… no sólo una vez, sino una vez al año.


    Referencias / Pies de Página

    1. El Proceso Unificado de Desarrollo de Software; Jacobson, Booch, Rumbaugh; Ed. Addison Wesley.
    2. Reglas o engagement rules incluyen definición de roles y estrategia de implementación; en caso de contar con recursos recién adquiridos, incluirá metodologías, estándares e incluso si fuera necesario, políticas y procedimientos relacionados a la ejecución del proyecto.
    3. El modelo de diseño del sistema implica el refinamiento de los requisitos en base a los casos de uso y los procesos al grado de pseudocodigo; el diseño del sistema va muy de la mano de la definición final de la arquitectura tecnológica y las pruebas de concepto realizadas para definirla.
    4. Las pruebas de concepto (Proof Of Concept – POC) consisten en determinar si algún componente o requisito técnico del sistema es viable; asimismo permiten descubrir riesgos ocultos y su mitigación. El resultado final siempre debería desembocar en un procedimiento de instalación/integración/uso o un informe de inviabilidad y su justificación.
    5. El proyecto base y los componentes que lo constituyen siempre estarán determinados por las pruebas de concepto que se hayan realizado. Es indispensable realizar todas las pruebas de concepto necesarias antes de generar el proyecto base así como el documento final de arquitectura tecnológica.
    6. El proyecto base debe contar con todos los componentes de software (Servidor de aplicaciones, frameworks de desarrollo, estructura de paquetes y directorios, etc.), scripts de compilación y recursos adicionales (imágenes, hojas de estilo) necesarios para que el equipo de trabajo pueda descargarlo del repositorio de versiones e implemente la construcción sobre éste. Nótese que este proyecto base debe ser generado por el arquitecto de software asignado al proyecto.
    7. Dependiendo de los factores ambientales del proyecto, puede ser necesario generar una maqueta que permita al usuario ver el avance realizado. El demo o maqueta facilita la aceptación de todo el trabajo realizado hasta este momento. Nota: el demo no necesariamente debe ser funcional, por lo que no se toma como equivalente al proyecto base.
    8. Hasta este punto el proyecto todavía se encuentra en la fase conceptual. Una vez que se ha cerrado esta fase, se generarán productos tangibles (código) y se realizarán tareas de alto riesgo; por lo que si el proyecto no puede continuar a la siguiente etapa, todavía hay tiempo de redimensionarlo o cancelarlo en su conjunto sin demasiado impacto.
    9. El desarrollo de estos componentes debe estar siendo validado constantemente con el usuario final o el enlace de sistemas correspondiente; para ello es indispensable realizar la construcción de prototipos funcionales de forma iterativa e incremental, donde cada iteración debe terminar con el visto bueno del usuario.
    10. El control de cambios corresponde al área de project management, sin embargo es tarea del arquitecto o líder técnico apoyar al project manager a llevar dicho control, determinando dimensionamientos y estimación de impacto para los cambios que se vayan generando por parte del usuario durante las etapas por las que atraviesa el proyecto.
    11. Si es necesario, también puede requerirse la generación de manuales técnicos que faciliten el mantenimiento del sistema desarrollado por parte del departamento de IT o soporte técnico.
    12. Es decir, que se comenzará con lo que verá directamente el usuario (capa de presentación) y posteriormente se irán desarrollando los componentes con los que cada vez menos visualización tendrá el usuario. Una secuencia estándar en un sistema web podría ser:
      • Pantallas.
      • Infraestructura de persistencia básica (por ejemplo: catálogos).
      • Infraestructura de negocio básica.
      • Persistencia compleja.
      • Negocio complejo.
    13. Larman, Craig. Applying UML and Patterns. Ed. Prentice Hall
    14. Duncan, William E. A Guide to the Project Management Body of Knowledge. PMI Standards Commitee, Project Management Institute.
    15. Gamma et al. Design Patterns: Elements of Reusable Object-Oriented Software.
    16. Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Ed. Addison Wesley, 3a. edición.
    17. UML Reference Card [http://www.holub.com/goodies/uml/].
    18. Ambos diagramas son equivalentes; lo único que cambia es la representación de éstos. Ver [17]
    19. Abran, Alain y Moore, James Guide to the Software Engineering Body of Knowledge. professional Practices Commitee, IEEE Computer Society.
    20. De acuerdo al PMBOK[14] todo proyecto puede definirse en función del alcance, tiempo, costo y calidad. Por ejemplo, si el usuario requiere una funcionalidad nueva pero necesita liberarla a producción en una fecha inamovible, (se tiene una restricción en tiempo) se pueden modificar los valores de los demás atributos: es posible variar el alcance (modificar el alcance del proyecto para poder reasignar recursos a las nuevas tareas), costo (por asignación de recursos extra), o calidad (liberar una versión beta de la nueva funcionalidad) o usarse en combinación.
    21. DeMarco, Tom y Lister, Timothy. Peopleware : Productive Projects and Teams. Ed. Dorset House Publishing Company, Incorporated, 2a. edición.
    22. Walker, David. Hard numbers on good work environments y Spolsky, Joel. Anyone managing software projects should read this! Comentarios acerca del libro Peopleware[21] en Amazon.com.
      Dirección: [http://www.amazon.com/Peopleware-Productive-Projects-Teams-Ed/dp/0932633439].

    Responder

    Introduce tus datos o haz clic en un icono para iniciar sesión:

    Logo de WordPress.com

    Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

    Imagen de Twitter

    Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

    Foto de Facebook

    Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

    Google+ photo

    Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

    Conectando a %s

    A %d blogueros les gusta esto: