Descarga la aplicación para disfrutar aún más
Vista previa del material en texto
Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 1 UNIDAD VII ANALISIS Y DISEÑO DE SISTEMAS 1. Técnicas para el análisis de requerimientos de software En la Ingeniería de requisitos, el análisis de los requerimientos del software es la etapa que sigue después que estos han sido levantados y documentados en un registro o matriz de trazabilidad. (Plantilla de matriz de trazabilidad, archivo .xls en plataforma Slack). La matriz de trazabilidad de requisitos es un cuadro que vincula los requisitos del proyecto desde su origen hasta los entregables que lo satisfacen. La matriz de requisitos ayuda a asegurar que cada requerimiento agrega valor al negocio, mostrándote el vínculo entre requisitos, necesidades de negocio y objetivos de proyecto. De esta forma puedes hacer un seguimiento durante el ciclo de vida, mejorando la ingeniería de requisitos al asegurar que estos sean entregados según especificaciones. La especificación de requerimientos, es una actividad que cada vez toma mayor preponderancia en la gerencia de proyectos, dado que se ha demostrado que una causa recurrente en su fracaso se origina de una inadecuada especificación de requisitos. El análisis de requerimientos consiste en aplicar una serie de técnicas para desglosar y analizar los requisitos y sus partes, algunas de estas técnicas son: Modelado de procesos, Modelado de dominio, casos de uso, inspecciones, listas de chequeo y prototipos. a) Descomposición funcional La descomposición funcional se refiere al proceso de identificar y resolver las relaciones funcionales en sus partes constituyentes, de tal forma que la función global pueda ser reconstruida a partir de sus partes. Por lo general, la descomposición funcional se realiza para identificar y entender los componentes o partes que constituyen un todo (o función global). En este proceso, es vital identificar las interacciones entre componentes. Aplicado a la Ingeniería de requisitos, consiste en tomar los requerimientos de software, dividirlos en partes y analizarlos individualmente. De ser necesario, se pueden descomponer en más partes hasta lograr un nivel adecuado de detalle. En cierto sentido, el proceso es similar al de la elaboración de una estructura de desglose de trabajo de un proyecto. En Ingeniería de sistemas, la descomposición funcional consiste en definir un sistema en términos funcionales, para luego definir funciones de más bajo nivel y establecer las relaciones con estas funciones de alto nivel. La intención es dividir un sistema de tal forma que cada componente se pueda describir sin necesidad de referir a otro componente. De esta forma, cada parte del sistema tendrá funciones independientes, que pueden reusarse y reemplazarse. Plantilla de estructura de desglose de trabajo (EDT) La Estructura de Desglose del Trabajo (EDT) es una descomposición jerárquica del alcance total del trabajo a realizar en un proyecto, para cumplir con sus objetivos y crear sus entregables. nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 2 La Estructura de Desglose del Trabajo, permite subdividir los entregables y el trabajo del proyecto en componentes más pequeños y fáciles de manejar, proporcionando una visión estructurada de lo que se debe entregar. Organiza define el alcance total del proyecto y representa el trabajo especificado en el enunciado del alcance del proyecto aprobado y vigente. Se elabora a partir del enunciado del alcance y la documentación de requisitos del proyecto b) Especificación vía Sentencias Textuales Es la forma tradicional de la especificación de requerimientos de software. Se usan especificaciones textuales en lenguaje natural, que se documentan en matrices de trazabilidad de requerimientos o definiciones del alcance. El procedimiento consiste en tomar el requerimiento producto del levantamiento de información, para desarrollar una narrativa más detallada. No usa herramientas visuales como los flujogramas o estructura como los casos de uso, es simplemente una descripción más detallada del requerimiento en lenguaje natural. c) Modelado del Proceso • Comprende la elaboración de diagramas de flujo de procesos (Flujogramas) a partir de los requerimientos del software. nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 3 • Existen diversas herramientas de modelado de procesos, cada una de las cuales posee sus propios símbolos y reglas. • Es muy útil para entender el trabajo realizado en múltiples pasos, tareas, roles y departamentos intervinientes. • Los procesos son iniciados por eventos y pueden abarcar actividades automatizadas, manuales o combinación entre ambas. • Su naturaleza visual ayuda a la comprensión y comunicación a terceros. • Cuando los procesos son complejos, deben desglosarse en componentes (subprocesos). • La relación entre los diagramas de flujo y la gerencia de proyectos es fundamental para el éxito. d) Modelo de dominio Imagen de: Wikipedia • En Ingeniería de software, en análisis de dominio consiste en analizar sistemas o software relacionados en un dominio, con la finalidad de encontrar sus partes comunes y partes que los diferencian. • Produce un modelo de contexto de negocio para todo el sistema. • Un modelo de dominio comprende diagramas conceptuales que incluyen tanto el comportamiento de un sistema como sus datos. • Un tipo de modelo de dominio son los diagramas de funcionalidades (Features Diagrams), que es una representación “compacta” del sistema o aplicación en términos de sus características. • El análisis de dominio produce modelos orientados a objetos o modelos relacionales de datos, que pueden ser usados por los desarrolladores de software como base de arquitecturas de software y aplicaciones. Casos de Uso https://en.wikipedia.org/wiki/Feature_model http://www.pmoinformatica.com/2013/10/el-rol-del-arquitecto-de-software.html https://1.bp.blogspot.com/-gsyn22AQmZM/V6jKnAFPsmI/AAAAAAAAEag/ds22SQ37MJIL614EWQyz9s4VM5i461HmQCLcB/s1600/T%C3%A9cnicas+de+an%C3%A1lisis+de+requerimientos+-+Diagrama+de+funcionalidades.jpg nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 4 Imagen de: Microsoft Developer Network (MSDN) • En el Lenguaje de Modelado Unificado (UML), un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Plantilla para elaborar casos de uso • En el ámbito académico y profesional, es una de las técnicas demayor difusión para especificar el comportamiento del Sistema. • Formato simple y estructurado que puede ser compartido entre usuarios y desarrolladores. • Además de usarse para analizar los requerimientos de software, también pueden usarse en el diseño del sistema e inclusive para definir pruebas de caja negra (Testing). • Son útiles en sistemas informáticos orientados a la funcionalidad (transacciones con el usuario), que se van a implementar orientados a objetos y con UML. • No son la mejor opción en sistemas sin usuarios, o dominados fundamentalmente por requerimientos no funcionales. Checklists • La lista de chequeo (Checklist) consiste en una serie de preguntas o revisiones que se realizan sobre los requerimientos de software, que nos sean presentados de forma escrita. • Una lista de chequeo puede realizar preguntas como: o ¿Se han especificado los requisitos de hardware y software? o ¿Se han realizado consideraciones de seguridad? o ¿El nivel de granularidad del requerimiento se ha incluido? o ¿Se ha incluido el código de referencia en para identificar el requisito en el desglose de requerimientos? o ¿Está escrito el requerimiento en un lenguaje claro y conciso? o ¿El requerimiento es único? (no existe duplicidad con otro requerimiento). o Y muchas preguntas más. • La lista de chequeo sirve de marco de trabajo y procedimental para revisar el requerimiento, facilitando su análisis de forma estructurada. • Los requerimientos se pueden revisar sobre la matriz de trazabilidad de requerimientos o sobre la definición del alcance. https://msdn.microsoft.com/es-es/library/dd409427.aspx https://3.bp.blogspot.com/-lhv3NzcIlw0/V6jKWzpMryI/AAAAAAAAEac/T5wHnkT2jcYTmw0fK4Eu18gQ2hlQx8IZgCLcB/s1600/T%C3%A9cnicas+de+an%C3%A1lisis+de+requerimientos+-+Casos+de+uso.png nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 5 Inspección • Revisión no destructiva de los requerimientos de software. Por ejemplo: o Examinar un software visualmente para constatar que las pantallas solicitadas se encuentran incluidas. o Verificar la inclusión de los campos necesarios para el ingreso de datos. o Verificar la existencia de los botones necesarios para iniciar la funcionalidad que ha sido requerida. o Verificar que el requerimiento se apega a los estándares definidos para la aplicación. Por ejemplo estándares de navegación entre pantallas y estándares de interfaz gráfica. • De forma similar al uso de la lista de chequeo, la inspección consiste en tomar el requerimiento definido en la matriz de trazabilidad o definición de alcance, leerlo y producir un resultado para su corrección. Prototipos Designed by Freepik • Consiste en elaborar representaciones visuales (interfaz gráfica con el usuario) de los requerimientos de software. • Es una herramienta muy útil para validar con los usuarios, clientes e interesados de proyecto que el diseño funcional corresponde con los requerimientos de software (Que existe entendimiento común entre desarrolladores de software y usuarios). • Permite a desarrolladores y usuarios entender mejor los requerimientos, determinar cuáles son indispensables y cuales deseables, e identificar riesgos de forma temprana. • Puede enfocarse en toda la solución o sólo en áreas específicas. • Puede extenderse innecesariamente en el tiempo si las discusiones se realizan en torno al como en lugar de en torno al que. • La elaboración de prototipos conlleva iteraciones entre desarrolladores y usuarios, en los cuales se van elaborando varios prototipos y sometidos a evaluación del cliente. https://2.bp.blogspot.com/-V4Krr02103I/V6jMHtWihJI/AAAAAAAAEaw/nVsV178EIcgD7q_IeoRCiAp1BSJVxx72gCLcB/s1600/T%C3%A9cnicas+de+an%C3%A1lisis+de+requerimientos+-+Prototipos.jpg nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 6 Gerencia de los Interesados (Stakeholders) La ingeniería de requisitos en un proyecto está íntimamente relacionada con la gerencia de los interesados (stakeholders), pues son quienes originan los requisitos y tienen mayor influencia en su aceptación. La Gestión de los interesados del proyecto (Stakeholders), es una función que cada vez adquiere mayor importancia en la Gerencia de proyectos, pues ha quedado demostrado que lograr la participación eficaz de los interesados en la ejecución y toma de decisiones es fundamental para el éxito. La gestión eficaz de los interesados del proyecto parte de la oportuna identificación y mantenimiento de un registro de los mismos, para lo cual el Gerente de proyectos cuenta con un instrumento que se denomina registro de los interesados. En él se documenta información sobre los datos de contacto de cada uno de los interesados, sus requerimientos, expectativas, evaluación de su grado de influencia, interés y postura (a favor o contraria) entre otros aspectos Descripción de la plantilla del registro de los interesados Información de identificación • Nombre: Nombre y apellido completo del interesado. • Posición: Posición o cargo que la persona desempeña en la organización. • Organización / Empresa: Los interesados pueden pertenecer a la misma organización que ejecuta el proyecto o a otras relacionadas, tales como: clientes, proveedores, entes gubernamentales y asociaciones civiles. Aquí se registra a que organización pertenece el interesado y el departamento o unidad organizacional. • Ubicación: Localización geográfica del interesado, por ejemplo la ciudad o región en la cual esta su oficina. • Información de contacto: Datos necesarios para poder ubicar a la persona, por ejemplo dirección exacta de correo (físico), dirección de correo electrónico, teléfono fijo, teléfono móvil, nombre de usuario de chat o Skype y cualquier otra información necesaria. Información de evaluación • Requisitos principales: Aquí se escribe que es lo principal que el interesado requiere del proyecto en términos de entregables o información. Usualmente se relaciona con los requerimientos detallados que se levantan en la fase de identificación de requerimientos (que forma parte de la definición de alcance del proyecto). • Expectativas principales: Beneficios que el interesado espera obtener del proyecto, o también que esperan ganar (o perder) como consecuencia del proyecto. Balancear las expectativas de todos los interesados puede llegar a ser todo un reto para la Gerencia de proyectos • Grado de influencia: Es el grado de "poder" que el interesado tiene para afectar positiva o negativamente el resultado o éxito del proyecto • Grado de interés: Es el grado en el cual el interesado es afectado positiva o negativamente (según su punto de vista) por el proyecto, pudiendo ser Bajo, Medio y Alto. • Fase de mayor interés: Fase del ciclo de vida del proyecto en la cual el interesado está más involucrado, concentra sus intereses o tiene mayor grado de actividad. Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 7 Clasificación • Interno / Externo: Los interesados internos son personasy grupos que trabajan directamente en la organización ejecutora del proyecto, como por ejemplo empleados, gerentes y los dueños de la empresa. Los interesados externos son personas o grupos no directamente relacionados con la organización, pero que tienen interés e influencia, por ejemplo accionistas, entes gubernamentales, proveedores o subcontratistas, grupos de la sociedad (asociaciones civiles), clientes y acreedores. • Partidario / Neutral / Reticente: Un aspecto importante de la gerencia de interesados es poder identificar la postura de estos frente al proyecto, dado que las estrategias de gestión de cada interesado pueden variar dependiendo si el interesado ejerce su influencia para favorecer el proyecto, obstaculizarlo o se muestra neutral. Como lidiar con implicados (stakeholders) problemáticos Todo proyecto de cualquier área tendrá que enfrentar tarde o temprano algún participante o implicado problemático (Ej. Usuarios finales, Clientes, jefes de departamento, integrantes de equipo, etc.), diversas pueden ser las situaciones, amenaza para la agenda personal, estabilidad, resistencia al cambio o a las nuevas tecnologías. Para lidiar con esto, en primer lugar debe entenderse su visión de la organización, motivaciones y objetivos, para luego desarrollar estrategias en función de sus niveles de influencia y participación en el proyecto. Presentamos a continuación algunas estrategias para entender las motivaciones de implicados problemáticos, contrarrestar su influencia e inclusive ganar su cooperación. Entender las motivaciones y niveles de influencia de los implicados (stakeholders) • Dedicar tiempo a entender las motivaciones detrás de la crítica y resistencia. • Conversar con el staff (subalternos) y pares. • Entender claramente sus metas y objetivos, colocando especial atención en el trabajo que hacen en la organización, como lo hacen y como les afecta el proyecto. • Determinar cuáles son sus expectativas y lo que espera ganar del proyecto. • Colóquese en los zapatos del implicado, entienda su visión de la organización y del proyecto. • Determine si el proyecto le agrega o quita valor a su área funcional de alguna forma. • Si participa directamente en el proyecto, preguntarle que problemas ha encontrado realizando el trabajo. • Identificar si existe alguna manera de satisfacer sus objetivos sin poner en riesgo el éxito del proyecto. Estrategias para lidiar con implicados problemáticos cuando su participación es clave • Darse cuenta que no es posible complacer a todos los implicados en todos los aspectos del proyecto. • Los objetivos y metas del proyecto deben ser claros y establecidos al principio del proyecto. • Involucrar a todos los implicados claves desde el principio del proyecto, haciéndoles participar en la toma de decisiones. • Tome en cuenta las expectativas de los implicados claves. • Asegure la transparencia en la forma de llevar el proyecto y evite agendas ocultas. Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 8 • Cuando modificaciones aceptables al proyecto eliminen las objeciones de ciertos implicados, realizar dichas modificaciones, de esta forma, podría transformarse su opinión negativa en neutral o positiva. • Si es posible, alinear los objetivos y el valor proporcionado por el proyecto con los puntos de interés de los implicados, siempre y cuando no estén en conflicto. Estrategias para lidiar con implicados problemáticos no claves y de baja influencia • Aunque su participación no sea clave, las expectativas deben ser tomadas en cuenta para evitar resistencia. • Si es posible, evite la participación de implicados negativos en actividades críticas del proyecto. • Realicé alianzas con otros implicados que estén de acuerdo con el proyecto, ellos podrían ayudar a convencerlo de los beneficios del proyecto. • Hacer seguimiento y cumplir con los compromisos asumidos con los implicados. • Ganar su confianza manteniéndoles informados de los avances del proyecto. Conclusión Las grandes organizaciones son complejas redes de relaciones, alianzas, agendas personales, grupos de poder y niveles de influencia. Implicados problemáticos cuya participación es clave para el éxito del proyecto deben ser atendidos de inmediato con estrategias directas. Flujograma de procesos y gerencia de proyectos Según un estudio del Project Management Institute (PMI), presentado en el PMI Pulse of the Profession 2015, el 40% de los fracasos en los proyectos están siendo ocasionados por inexactitudes en el levantamiento y documentación de la ingeniería de requisitos. La experiencia ha demostrado que al utilizar el modelado de flujogramas en la ingeniería de requerimientos, se pueden identificar con mayor facilidad los puntos clave, establecer las relaciones entre requerimientos y lograr un entendimiento común entre todas las partes del producto final que aportará tu proyecto. Aquel dicho que reza que “una imagen vale más que mil palabras” es muy aplicable a la ingeniería de requerimientos, por lo cual dedicamos este artículo a describir la importancia del modelado visual y cómo podemos utilizarlo para mejorar la definición de alcance y descripciones de las necesidades de los interesados, para así garantizar el éxito de los proyectos. ¿Tienen relación la elaboración de flujogramas con la gerencia de proyectos? El Project Management Intitute (PMI) y su metodología PMI para la dirección de proyectos reconocen la ingeniería de requisitos como un aspecto fundamental para determinar las necesidades de los interesados, para así definir un alcance que logré aportar valor a sus operaciones. La guía de dirección de proyectos del PMI, el PMBOK 5ta edición, reconoce procesos para recopilar los requisitos de los interesados (Proceso 5.2) y posteriormente definir el alcance a partir de los mismos (proceso 5.3). Los flujogramas de procesos están definidos como herramientas de la dirección de proyectos para recopilar requisitos y definir alcance, y como veremos a continuación pueden ayudarte Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 9 en una mejor definición que se corresponda con las expectativas de los interesados. El reconocimiento del PMI de está realidad inclusive ha motivado el desarrollo de una nueva certificación de Profesional en Análisis de Negocio del PMI (PMI-PBA) Qué es un flujograma de procesos? Un flujograma, incluye los pasos de un determinado proceso que se quiera representar, interconectados con flechas que indican las posibles direcciones o rutas que puede seguir. Aquí en la imagen presentamos un ejemplo. Los flujogramas manejan otros símbolos, por ejemplo decisorios para representar escenarios que pueden seguirse. También se pueden representar los entregables o documentos que produce un determinado proceso. ¿Cuáles son los beneficios de usar los flujogramas en la ingeniería de requisitos? • Los flujogramas de procesos pueden ayudarte a poder discernir las descripciones de los requerimientos de los interesados, transformando esas extensas cantidades de texto en “historias” que pueden leerse fácilmente. • Es más fácil analizar y discutir un flujograma que una descripción extensa de requisitos. • Cuando representamos los requerimientos en descripciones de texto, las relaciones entre ellos suelen opacarse. Con un flujograma puedes reconocer donde estas relaciones ocurren, identificando puntos clave, que podríanrepresentar riesgos para la operación de los clientes del producto final de tu proyecto. • Los modelos visuales ayudan a identificar donde pueden existir posibles redundancias en las funcionalidades y datos, para mejorar así las definiciones de requisitos y alcance. nicoj Resaltar Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 10 • En muchas ocasiones los requisitos no están definidos con claridad, ni siquiera por los interesados que tienen la necesidad. El modelado visual de un flujograma de proceso puede ayudarnos en las mesas de trabajo con las áreas clientes, para hacer las preguntas adecuadas y desarrollar un entendimiento común de sus necesidades. • Al aportar una visibilidad del panorama completo, abstrayéndonos de detalles técnicos, los modelos de flujograma pueden ayudar a los interesados a identificar requerimientos faltantes que no se les hayan ocurrido todavía. ¿Qué ocurre si no tengo tiempo de detenerme e invertir considerable tiempo en representar los requisitos como flujogramas? Es potestad de la Gerencia de proyectos el decidir que modelos visuales usar, cuando usarlos y que tan detallados hacerlos. Al igual que con un libro de recetas, puedes tomar solo lo que necesitas y hacer tu propio récipe. A veces el modelado puede verse como una actividad extenuante, que nos consume mucho tiempo, que no tenemos pues la gerencia y los interesados conceden muy poco tiempo para elicitar los requisitos de un proyecto. Sin embargo, invertir un poco más de tiempo en esto al principio te ahorrará dolores de cabeza y retrasos al final, por lo que definitivamente es recomendable no obviar este paso. Si no haces el modelado visual al principio, tarde o temprano tendrás que elaborarlo de todas formas, bien sea cuando te reúnas con los ejecutores para identificar la causa de algún defecto, o cuando tengas que explicarles a los interesados cual fue tu entendimiento del requerimiento y que les entregaras. Lo que si puedes hacer, es ir elaborando prácticas y procedimientos para que puedas elaborar estos flujogramas con mayor eficiencia. Puedes ir creando una base de plantillas de flujogramas, que puedas archivar. Estas plantillas estarán disponibles para futuros proyectos. ¿Qué otros modelos visuales pueden usarse en la ingeniería de requerimientos? Además de los flujogramas, existen otras herramientas visuales que puedes usar para documentar los requisitos de los interesados en la gerencia de proyectos. Algunas de las más usadas son las tablas, flujogramas, matrices, diagramas de árbol, modelos de objetivo de negocio y muchas otras. A continuación te describimos dos de ellas: Modelo de objetivos de negocio Muy útiles para representar visualmente cual es el valor que está aportado el producto final de tu proyecto a los interesados. Aquí un ejemplo: nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 11 Los modelos de objetivos concatenan problemas que enfrenta el cliente con objetivos de negocio específicos para atender esos problemas, y luego se relacionan con un concepto de producto. Al definir estos objetivos de negocio es recomendable usar métricas de éxito. Arboles de funcionalidades Permiten organizar las funcionalidades de un producto y agruparlas, capturando todo el alcance de un proyecto en un modelo visual de alto nivel. Aquí presentamos un ejemplo: http://2.bp.blogspot.com/-w0ib6QdwDNg/VZl-YnMLpuI/AAAAAAAADy8/m_4Bjrj3NTc/s1600/Modelo+de+objetivos+de+negocio+600.png http://4.bp.blogspot.com/-VkgsHStxW_k/VZl15XLKOuI/AAAAAAAADyk/ggw7Gj7yLWg/s1600/Arboles+de+funcionalidades+600.png nicoj Resaltar nicoj Resaltar Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 12 ARQUITECTURA DE SOFTWARE El rol del Arquitecto de software Al principio, podía pensarse que simplemente se había “remarcado” el rol del Analista de Sistemas, sin embargo, hoy en día existen multitudes de títulos de arquitecto, como: Arquitecto Empresarial, Arquitecto de Aplicación, Arquitecto de Soluciones, Arquitecto de Tecnología de Información, Arquitecto de Datos, etc. Pmoinformatica.com, "La Oficina de Proyectos de Informática", presenta: algunos comentarios sobre cuáles son las funciones de los Arquitectos de Software en la actualidad. Qué hace un Arquitecto de Software • Revisa las necesidades del negocio junto con los requerimientos no funcionales, y los relaciona con la solución que se necesita implementar para cubrirlas. • Se asegura de la calidad de la solución y de su mantenimiento en el tiempo. • Toma decisiones de diseño de alto nivel. • Dicta estándares técnicos, de codificación, herramientas y plataformas. Los diferentes arquitectos de software • Arquitecto Empresarial: Maneja la interacción entre el lado del negocio y de Tecnología de Información en la organización. Es el principal encargado en determinar la situación actual (AS-IS) y el estado deseado (TO-BE) desde la perspectiva del negocio y Tecnología de Información. • Arquitecto de Aplicación: Es un arquitecto de Software que trabaja con una sola de las aplicaciones de la solución (Los proyectos pueden implicar múltiples aplicaciones). Puede ser u rol tiempo parcial o completo. En la mayoría de los casos, el arquitecto de aplicación es un desarrollador de software activo en el proyecto. • Arquitecto de Solución: A diferencia del Arquitecto de Aplicación, el Arquitecto de Soluciones trabaja con todas las aplicaciones, cuyas interacciones son necesarias para suministrar la solución completa al cliente. • Arquitecto de Tecnología de Información (TI): Es quien decide cuales recursos de TI serán aplicados para satisfacer las necesidades del negocio, tomando en cuenta la eficiencia operacional y organizacional, por medio de la integración y gestión de la información. El Rol implica tanto habilidades en software de información como en la infraestructura de TI. • Arquitecto de Datos: Es el responsable de asegurar que los datos de la organización se soporten en una arquitectura de datos que apoye a la organización en el logro de sus objetivos estratégicos. La arquitectura de datos debe cubrir tanto las bases de datos como la integración, es decir los medios para acceder a los datos. Entre las muchas funciones está incluido el modelado de los datos. Todo desarrollador debe ser un arquitecto No necesariamente, hoy en día existe la tendencia a creer que todo desarrollador debe tener habilidades de Arquitecto, eso en sí no es un problema, sin embargo no todos los desarrolladores son buenos arquitectos. No es un asunto de capacidad, simplemente algunos desarrolladores son buenos resolviendo problemas específicos que requieren profundización, mientras que otros son buenos manejando mayores niveles de abstracción. nicoj Resaltar Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 13 La Tecnología cambia rápidamente Otro reto para los arquitectos de Software es la rapidezcon la que surgen nuevas tecnologías y productos. Todo arquitecto necesita invertir grandes cantidades de tiempo personal, solamente para mantenerse al día. Las Funciones del Arquitecto de Software • Elaborar la arquitectura y diseño de software a partir de los requerimientos del usuario. Haciendo uso de patrones de diseño previamente conocidos, por experiencia personal o manteniéndose actualizado con las últimas técnicas y patrones. • Crear consenso y entendimiento de la arquitectura. Debe involucrar a cada miembro del equipo, y lograr acuerdos respecto a la arquitectura, la cual debe comunicar y vender. • Entender los requerimientos no funcionales: o La mayoría de los requerimientos no funcionales son de naturaleza técnica, y suelen tener mucha influencia en la arquitectura. o El entendimiento adecuado de estos requerimientos es crucial para desempeñar este rol. o No basta con asumir cuales son esos requerimientos, se necesita indagar sobre ellos y determinar las necesidades reales. • Definir la Arquitectura: o Incluir estructuras, lineamientos, principios y liderazgo sobre los aspectos técnicos del software. o Esta responsabilidad varía mucho si se está trabajando con un sistema con arquitectura definida frente a diseñar un nuevo sistema. • Seleccionar Tecnologías: o Puede llegar a ser un reto, considerando todos los elementos a considerar: costo, licenciamiento, relaciones con proveedores, estrategia de tecnología, compatibilidad, interoperabilidad, soporte, instalación, políticas de actualización, ambientes de usuario final, etc. o Seleccionar tecnologías se trata de evaluar los riesgos, reduciéndolos cuando existe alta complejidad e incertidumbre y aumentarlos cuando existen beneficios (oportunidades). o Todos los componentes deben ser evaluados, incluyendo los bloques generales, hasta el detalle de librerías y frameworks. o Toda decisión de tecnología debería ser revisada y aprobada. • Evaluar Arquitecturas: o Al diseñar el software, el arquitecto debe preguntarse si la arquitectura seleccionada podrá satisfacer los requerimientos funcionales y en especial los no funcionales. o Las arquitecturas también se pueden probar, y si hacemos esto al principio, podemos evitar el fracaso del proyecto. Diferencias entre el Arquitecto de Software del Líder de Desarrollo • El líder de desarrollo se enfoca en conocimiento detallado de áreas específicas mientras que el arquitecto de software necesita ver los problemas de forma amplia, desde diferentes perspectivas, enfocándose en integrar las partes en una red que permita solucionar el problema global. • El Arquitecto de Software maneja el problema y la solución a una mayor escala y nivel de abstracción. • Sus decisiones tienen mayor impacto en la duración del proyecto y los riesgos. • Hacer Arquitectura de Software es tener una visión holística, ver el panorama amplio, para entender como funcional el sistema como un todo. http://www.pmoinformatica.com/2013/01/requerimientos-no-funcionales-porque.html nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 14 Diferentes Funciones según el tipo de Arquitecto de Software Según el arquitecto sea Empresarial, De Aplicación o de Solución, manejará distintos niveles de complejidad, como se muestra en la siguiente tabla que obtuvimos de Wikipedia. Tipo de Arquitecto Pensamiento Estratégico Interacciones entre Sistemas Comunicaciones Diseño Empresarial Entre Proyectos. Altamente abstracto. En toda la organización. Mínimo, de Alto Nivel. Soluciones Enfocado en una solución. Muy detallado. Múltiples equipos de Proyecto. Detallado. Aplicaciones Reutilización y mantenimiento de componentes. Centrado en una sola aplicación. Un solo equipo de proyecto. Muy detallado. Posibles candidatos Los posibles candidatos son Líderes de Desarrollo o Desarrolladores de nivel avanzado, que durante su evaluación puedan mostrar: • Varios años de experiencia en la tecnología de desarrollo de software que se está buscando. • Ejecución de forma consistente y continua de proyectos exitosos en la tecnología de software o soluciones que se está buscando. • Invierten tiempo en el autoaprendizaje de las mejores prácticas de desarrollo y se mantienen actualizados en los patrones de diseño e ingeniería de software. • Invierten tiempo en mantenerse actualizados en las últimas tecnologías de informática y desarrollo de software. • Abordan la arquitectura de software con enfoque crítico y demuestran tener criterio propio. • Muestran interés en que su propio desarrollo y el de sus pares se apegué a los patrones de diseño e ingeniería de software. Los candidatos a Arquitectos de Software también pueden ser personas que desarrollaron pequeños proyectos en los cuales eran el único desarrollador (desempeñaban la función de Arquitecto y Desarrollador simultáneamente), por supuesto siempre tomando en cuenta la capacidad y tecnología. Herramientas que debe manejar • Lenguaje de documentación visual (ej. UML). • Diseño de Base de datos. • Procesos y herramientas de desarrollo. Aspectos positivos de ser un Arquitecto de Software • Es un rol clave que tiene potencial de agregar mucho valor si se desempeña adecuadamente, lo cual implica por lo general mayor sueldo. • Debe interactuar con personas clave en la organización, equipo de desarrollo y comunidad de usuarios, por lo que es un rol bastante visible. Esto implica mayores oportunidades de carrera. Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 15 Retos a enfrentar • Uno de los principales problemas que enfrenta un arquitecto de software en el día a día, son los requerimientos funcionales con información incorrecta o incompleta. Requiere de mucha habilidad el poder identificar requerimientos mal documentados antes que sea demasiado tarde. • Para ser un buen arquitecto de software, es necesario estar en constante estudio de las nuevas técnicas, patrones y herramientas. Para lograr esto se requiere esfuerzo, incluyendo sacrificios de tiempo personal y familiar para invertirlo en autoestudio, cursos, entre otros. • El rol implica balancear tantos factores que “es muy fácil fracasar”, si esto ocurre, uno de los primeros que tendrá que rendir cuentas es el Arquitecto de Software, por lo que “el reto es no fracasar”. • Con frecuencia, la complejidad del rol es subestimada, por lo que corresponde al Arquitecto ser un buen comunicador para demostrar el valor agregado del diseño y arquitectura en el proceso de desarrollo de software. IDENTIFICACION DE RIESGOS Todo proyecto siempre posee niveles de incertidumbre sobre la actividad a realizar y el producto a entregar, son riesgos que deben ser gestionados. Se exploran cinco preguntas y respuestas sobre la identificación de los riesgos en un proyecto, incluyendo quien debe participar, cuando debe hacerse, cuando termina (o más bien no termina) la identificación de riesgos, la importancia de la creatividad, el pensamiento innovador, herramientas y técnicas para la identificación de los riesgos. El verdadero valor de un plan de riesgos, no reside en el cálculo de valor monetario, sino en la identificación de todos los riesgos y en la definición de planes de respuesta. Identificar riesgos en un proyecto no se trata sólo de herramientas y técnicas, la creatividad, el pensamiento innovadory participación de todos los integrantes del equipo juegan un papel importante. Presentamos a continuación 5 preguntas y respuestas sobre la identificación de riesgos: 1.- ¿Quién debe participar? La identificación de riesgos es un ejercicio en el cual debe participar integrantes claves de todas las áreas técnicas involucradas en un proyecto, específicamente: • El Sponsor del Proyecto. • Gerente / Jefe de Proyecto. • Integrantes del equipo. • Representantes del cliente o área de negocio solicitante del proyecto. • Usuarios finales del producto o sus representantes (no necesariamente es el mismo cliente). • Expertos técnicos externos al proyecto. • Otros sponsors y gerentes de proyectos similares. • Otros involucrados en el proyecto. • Expertos de la oficina de gestión de proyectos o unidad de gestión de riesgos. No necesariamente todos los integrantes del equipo deben participar, puede hacerse con Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 16 integrantes clave, sin embargo, deben existir canales de comunicación para que cualquier persona pueda levantar alertas sobre algún riesgo. Los expertos técnicos poseen conocimiento detallado del producto y sus implicaciones técnicas, desempeñando labores de consultoría. Al igual que los expertos de la oficina de gestión de proyectos o unidad de gestión de riesgos quienes poseen conocimientos en metodología. 2.- ¿Cuándo debe hacerse? El primer y mayor esfuerzo de identificación de riesgos debe hacerse durante la fase de planificación del mismo, antes de comprometer el cronograma y presupuesto final del proyecto. La forma proceder consiste en: • Antes de iniciar la identificación de los riesgos, es necesario tener avance en la primera versión de la definición de alcance, cronograma, presupuesto, planes de calidad y comunicaciones. • Luego, se recopilan todos los riesgos identificados durante dicha elaboración y se documentan en el registro de riesgos. • Cuantificar y desarrollar planes de respuesta para los riesgos identificados. • Revisar nuevamente el alcance, cronograma, presupuesto y plan de calidad, para ajustar los mismos según los planes de respuesta al riesgo determinados. Por ejemplo, si se decidió eliminar una actividad riesgosa del alcance, el documento de definición de alcance es actualizado, o por ejemplo si se decidió incluir una holgura para compensar por un posible retraso en un insumo, esto debe registrarse en el cronograma. De nada sirve identificar los riesgos si después no se toman acciones en los planes para responder a los mismos. La Oficina de Proyectos de Informática ofrece al público una Plantilla para la Gestión de riesgos en la cual se pueden documentar todos los riesgos identificados. 3.- ¿La identificación de riesgos se hace solamente en la fase de planificación? No, la identificación de riesgos debe ser continua durante todo el proyecto, no concluye con la fase de planificación. Una vez comience la ejecución del proyecto, periódicamente deben revisarse el registro de riesgos para determinar si los mismos continúan vigentes o si existen nuevos riesgos. Si se identifican nuevos riesgos o algunos cambian de nivel de impacto, deben realizarse correcciones a los planes de proyecto en las áreas de alcance, cronograma, presupuesto, calidad, comunicaciones, etc. La figura muestra como la identificación de riesgos se realiza en distintas etapas del proyecto. Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 17 Por ejemplo, si al principio del proyecto habíamos reservado cierta holgura para cubrir un riesgo y durante la ejecución, para luego determinar que dicho riesgo no ocurrirá (tiene baja probabilidad), podríamos eliminar la holgura y terminar antes de la fecha. Otro ejemplo, si identificamos un nuevo riesgo sobre la calidad del producto, podríamos evaluar incluir pruebas adicionales en el plan de calidad, lo cual a su vez supondrían cambios en las definiciones de alcance, cronograma y presupuesto. 4.- ¿Cómo influyen la creatividad y el pensamiento innovador en la identificación de riesgos? La creatividad y el pensamiento innovador desempeñan un papel fundamental, el fomentar que los Gerentes de Proyectos y miembros del equipo a que realmente se involucren en la identificación de riesgos, permitirá un mayor campo sobre el cual realizar análisis y planeación de las respuestas. El Análisis de escenarios y las sesiones de tormenta de ideas (Brainstorming) son aspectos importantes, pero lo es más aún el fomentar un ambiente de trabajo en el cual a los integrantes del equipo estén abiertos a nuevas ideas y cierto grado de pesimismo. Es necesario motivar e inclusive premiar a miembros del equipo que sin tapujos planteen situaciones riesgosas y muestren interés en identificar todas las áreas en que posibles fallas puedan ocurrir. Cuando de identificación de riesgos se trata, entre más creativo sea, menor expuesto se estará a la incertidumbre en el logro de los objetivos. 5.- ¿Cuáles son las herramientas y técnicas a usar en la identificación de los riesgos? El registro de riesgos De entrada, es importante contar con un instrumento que sirva para el registro de los riesgos que se van a documentar en el proyecto. Nuestro blog “La Oficina de Proyectos de Informática” cuenta con una plantilla. http://4.bp.blogspot.com/-9ekvhHkMuVc/UIwRmhpBCDI/AAAAAAAAAiw/NnMejauWStc/s1600/Lamina+Identificacion+de+Riesgos.png Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 18 Catalogo de riesgos También, es importante contar con un marco de referencia de los riesgos presentes en el proyecto que se está ejecutando, para esto, puede solicitarse un “catalogo de riesgos” a la Oficina de gestión de proyectos o unidad de gestión de riesgos. Si no se cuenta con estos recursos, se puede emplear consultores en gestión de riesgos y consultar a expertos técnicos en el área de proyecto. Un catalogo de riesgos por lo general consiste en documentación de un conjunto de riesgos que pueden estar presente en un determinado proyecto, clasificados en categorías como por ejemplo económicos, gestión de proyectos, cliente, proveedores, producto, etc. Esta lista de riesgos predefinidos puede variar según la industria. El catalogo de riesgos se puede organizar de forma de lista de chequeo (Checklist) en la cual cada riesgo genérico es analizado por el equipo y se determina si está presente o no en el proyecto. Técnicas para identificar los riesgos Una vez se cuente con las herramientas, se ejecutan una o varias reuniones con los involucrados mencionados en el punto 1, en el cual cada participante va aportando sus conocimientos para identificar los riesgos del proyecto. Entre las técnicas a utilizar destacan: Las sesiones de tormenta de ideas, entrevistas individuales o técnica delphi. Bajo esta última, los expertos son consultados de forma individual vía correspondencia. Durante las reuniones, se hace uso de técnicas de diagramación para entender mejor los problemas, se revisa el checklist o catalogo de riesgos como base de referencia, y se analizan las causas raíz de las situaciones que ocasionan los riesgos. El análisis de fortalezas ydebilidades de la organización (FODA) y analizar las premisas del proyecto pueden ser buenas fuentes de información para identificar los riesgos puede ser. Por ejemplo, poner como premisa que no ocurrirán retrasos en el procesamiento en aduana de cierto material podría ser demasiado optimista, representando un riesgo sobre el comienzo a tiempo de una actividad. También se puede recurrir al juicio de expertos, proporcionado por Sponsors o Gerentes, integrantes del equipo (expertos técnicos) que han participado en proyectos similares o inclusive consultores externos expertos en la industria. Conclusión Para el éxito de la gestión de riesgos es imprescindible que estos sean identificados de forma temprana, siendo clave que esto ocurra antes de comprometer con el cliente del producto el alcance, fecha de entrega y presupuesto del proyecto. Una vez identificados, sus planes de respuesta deben ser contemplados en la planificación en la forma de cambios de alcance en las actividades, modificación de la forma de realizar el trabajo, inclusión de holguras y reservas de presupuesto, así como decisiones de incorporación de personal con mayor experticia o subcontrataciones con terceros. Plantillas Scrum: Hoja de ruta del producto Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 19 La hoja de ruta del producto (Agile Product RoadMap) describe como se visiona la evolución del producto a lo largo de varias salidas a producción, similar a un plan de producto, ve más allá de un proyecto o Release individual, describiendo la ruta que seguirá el producto en los próximos 12 meses o mas. A diferencia dela lista de producto (Product Backlog) el cual es un documento ideal para capturar ideas y requerimientos, la hoja de ruta es para describir como se desarrollará el producto en el futuro. Se presenta una Plantilla Scrum para la hoja de ruta de producto, en la cual podrás ver una hoja de ruta, la cual se divide en flujos de trabajo, a los cuales se les asignan funcionalidades y des presenta la línea de tiempo en cuanto a los objetivos para desarrollar y lanzar a producción. Descripción de la plantilla La Plantilla Scrum de la Hoja de ruta del producto, abarca los siguientes elementos: • Período de tiempo: Son los períodos de tiempo en los cuales se presentará la información, por ejemplo meses, trimestres, semestres, etc. • Flujos de trabajo: Cada flujo de trabajo es una línea de producción o grupo de trabajo. De esta forma cada grupo de trabajo puede desarrollar funcionalidades para el Software con recursos independientes de los otros, pudiendo trabajar en paralelo. • Funcionalidades: En la lista de producto (Product Backlog) en Scrum pueden agruparse los requerimientos similares en funcionalidades, estas son asignadas a cada flujo de trabajo, señalando las fechas de comienzo y fin estimadas para desarrollarlas. http://www.pmoinformatica.com/2013/11/plantillas-scrum-pila-producto-product.html https://4.bp.blogspot.com/-YcGTFlT8pS0/WeVZicgaimI/AAAAAAAAFF8/pQ-6i9m0BRML7c8wvnUYdplNy4wCWTizwCLcBGAs/s1600/Plantillas+Scrum+Hoja+de+ruta+de+producto.jpg Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 20 Anexo Matriz de Trazabilidad de Requisitos Descripción del contenido de la matriz de requisitos La matriz de trazabilidad de requerimientos del proyecto es el instrumento base para el diseño y ejecución de la ingeniería de requisitos. Aquí describimos el contenido de cada columna de la plantilla de matriz de requisitos e información que debes completar en cada una. • Identificación: Código de identificación de mayor nivel definido para el requisito. Puede definirse con números, por ejemplo 001, 002, 003, y así sucesivamente. • Sub identificación: Sub código de identificación que puede utilizarse para definir requisitos detallados y asociarlos a un requisito padre. De esta forma se define la trazabilidad entre requisitos de alto nivel con requisitos más detallados. Puede definirse según el número de requisito padre, por ejemplo para el caso de 001 podría definirse el requisito 1.1 y 1.2. Pueden también definirse niveles adicionales de detalle de requisito, por ejemplo el requisito 1.1.1 y 1.1.2 estarían asociados a 1.1. • Descripción del requisito: Se proporciona una descripción de que comprende o en qué consiste el requisito. La descripción del requisito depende del tipo que sea, por ejemplo requisitos del negocio, requisitos de los interesados, requisitos funcionales, requisitos no funcionales, requisitos del proyecto o requisitos del producto (solución). • Versión: Número de versión del requisito en su estado actual. De esta forma los requisitos se pueden ir detallando o modificando en versiones sucesivas. • Estado actual: Puede ser solicitado, aprobado, asignado, completado, cancelado, diferido, aceptado, entre otros. • Última fecha de estado registrado: Fecha en la que se realizó el último cambio de estado del requisito. • Criterios de aceptación: Lista los criterios de aceptación, una lista de puntos o condiciones específicas que deben cumplirse para poder registrar que el requisito ha sido satisfecho. • Nivel de complejidad: Puede definirse una complejidad de forma cualitativa, por ejemplo baja, moderada o alta. Esto dependerá del criterio del evaluador. • Necesidad, oportunidades u objetivos de negocio: Vínculo del requisito con la estrategia de la organización, listando necesidades específicas que tenga el área de negocio, objetivos de la planificación estratégica que busca lograr u oportunidades de negocio o del mercado. Esto también se puede vincular con la Gerencia del portafolio al que pertenece el proyecto. • Objetivos del proyecto: Vínculo del requisito con los objetivos del proyecto. Aquí se establece la trazabilidad entre el requisito y los objetivos específicos del proyecto definidos e su alcance. • Entregables (EDT): Entregables de la estructura desagregada de tarea (EDT) en los cuales está inmerso el requisito. Puede especificarse tanto el nombre del elemento de la EDT como su código EDT. • Diseño del producto: Implicaciones que tiene el requisito desde el punto de vista del diseño del producto. Aquí se especifica como el diseño del producto incorpora los componentes necesarios para poder satisfacer el requerimiento. • Desarrollo del producto: Implicaciones del requisito en el desarrollo del producto. Describe como los procedimientos de trabajo, metodología o estándares usados incorporan el requisito. Esto aplica principalmente para requisitos que definen la forma de trabajar, estándares a cumplir, entre otros. Facultad de Ingeniería – UNJu Sistemas de Información Prof. Adj. Lic. Analia Herrera Cognetta 21 • Estrategia y escenarios de pruebas: Listado de las estrategias y escenarios de pruebas que se contemplarán para validar la aceptación del requisito. Estos se definen a partir de los criterios de aceptación. • Interesado (Stakeholder) dueño del requisito: Nombre, departamento y cargo del interesado (Stakeholder) que originó la solicitud del requerimiento particular. Debe corresponder con el que es especificado en el registro de interesados del proyecto. • Nivel de prioridad: Según la evaluación de la importancia del requisito para el logrode los objetivos del proyecto, se asigna un nivel de prioridad. Este nivel también puede depender del grado de influencia del interesado y estrategias que se estén empleando para gestionar la participación de los interesados.
Compartir