EL ROL DEL ADMINISTRADOR DENTRO DEL DESARROLLO DE SOFTWARE Edgar I. Morales Ponce Instituto Tecnológico de Durango champixdeluxe@hotmail.com RESUMEN En este trabajo se hace un análisis de la importancia del administrador dentro del desarrollo de software. El administrador de proyecto es la persona que administra y controla los recursos asignados a un proyecto, con el propósito de que se cumplan correctamente los planes definidos. o es dueño de nada, es sólo un administrador temporal de los recursos. 1. INTRODUCCIÓN En los últimos veinte años, los proyectos han tomado un papel central en el trabajo de los jóvenes y puede considerarse hoy en día como una herramienta para el cambio social, un eje clave para el desarrollo comunitario y también como herramienta para construir y/o fortalecer a la sociedad civil. Como consecuencia de lo anterior la administración de proyectos se ha convertido en una habilidad necesaria para las organizaciones de jóvenes y un tópico recurrente para el entrenamiento para el trabajo con jóvenes. La administración de proyectos requiere de una amplia variedad de habilidades que van desde el análisis político y social a habilidades comunicativas, de habilidades de administración de personas y recursos, habilidades para recabar fondos y técnicas de evaluación. El administrador, se encarga, como su nombre lo dice, de administrar, y controlar los recursos disponibles para el proyecto (dinero, personas, etc.), no es dueño de nada, así que debe dejar los recursos en la misma o mejor condición. Debe ayudar a cada integrante a cumplir sus objetivos particulares, y al final cumplir con el objetivo general, para lograr esto debe coordinar todas las actividades y los recursos.[1] 2. ROLES DE DESARROLLO DE SOFTWARE El desarrollo de software, es una actividad que necesita de diferentes capacidades para poderlo llevar a cabo, todas las capacidades es difícil encontrarlas en una sola persona, por lo que se necesita un grupo de personas con un rol en especifico para poder hacer esta actividad.. Debemos tener en cuenta que para llevar a cabo con éxito el desarrollo del sistema, cada una de las personas debe conocer perfectamente sus responsabilidades y actividades que le son asignadas.[1] 2.1 Administrador de Proyectos
PDF created with pdfFactory trial version www.pdffactory.com
El administrador, se encarga, como su nombre lo dice, de administrar, y controlar los recursos disponibles para el proyecto (dinero, personas, etc.), no es dueño de nada, así que debe dejar los recursos en la misma o mejor condición.[1]Se menciona un ejemplo claro de su función, debe enfocarse a todo el bosque, sin embargo debe cuidar a cada árbol, ya que cada árbol contribuye al bosque, este ejemplo se refiere a que debe ayudar a cada integrante a cumplir sus objetivos particulares, y al final cumplir con el objetivo general, para lograr esto debe coordinar todas las actividades y los recursos. 2.2 Analista La función de un analista, es descomponer un problema en subproblemas de menor complejidad, para así la suma de las soluciones de los subproblemas de una solución al problema. Una causa del fracaso de un sistema, es contar con un análisis pobre, porque los desarrolladores crean el proyecto que no cumple con los requisitos del cliente. Como el cliente es la persona que conoce a profundidad el problema, el analista tendrá diversas reuniones con el cliente para determinar los objetivos del cliente, así como también, en su caso, sugerirle al clientelo que le conviene; para esto tiene que estar preparado con un documento con preguntas hacia el cliente; y debido al contacto estrecho con el cliente, debe tener capacidad de comunicación. El analista transforma los requisitos de usuario en requisitos de software para proporcionarlos a los demás miembros, dichos requisitos de usuario tendrá que presentarlos al cliente, para tener su opinión y modificarlos, y volvérselos a mostrar, hasta que sean del agrado del cliente. [1] 2.3 Diseñador El diseñador, se encarga de transformar los requisitos de software en un modelo de implementación, que tiene como objetivo crear la estructura en niveles abstractos, en los cuales el cambio de un nivel a otro, debe respetar los requerimientos del cliente. [1] Su manera de lograr su objetivo, es descomponiendo en subsistemas que deben estar relacionados, así como definir las normas que tendrá dicho sistema (como acceso a datos), relacionarse con el programador, de tal manera que escojan que lenguaje de programación a utilizar. 2.4 Programador Los programadores tienen una función muy importante, que es la de transformar el modelo del sistema, en código fuente ejecutable. Es necesario que este actualizado de la industria de software, para saber quien le puede dar soporte y como beneficiará al proyecto. Un objetivo es el de tener el mínimo de errores en el proceso, para lograr esto se deben tener las herramientas necesarias, por eso es importante conocer el ambiente donde se desarrollará el software.[1] En este rol se pueden requerir dos o más programadores. Cada programador tiene su forma de
PDF created with pdfFactory trial version www.pdffactory.com
hacer el programa, pero si trabajan en grupo deben hacerlo bajo el mismo estándar. El diseñador puede ayudar a determinar cual lenguaje de programación es el apropiado para el proyecto, aunque se relaciona con todos, excepto con los clientes, ya que los clientes no pueden decirle que modificar del programa. 2.5 Téster En el desarrollo del proyecto, es posible que se presenten errores humanos, es labor del téster detectar y eliminar dichos errores. Utilizan dos métodos: caja blanca, hacer lo posible por que todo marche bien, y caja negra, encontrar errores. [1] Debe participar en la revisión de requisitos del sistema así como estar en contacto con los demás miembros para coordinar que todo esté bien. 2.6 Asegurador de Calidad Para la creación de software se requiere reducir costo y tiempo, obteniendo un producto con calidad reducida, es por eso que la calidad se toma como una meta final. El asegurador de calidad se encarga de revisar y asegurarse que el trabajo de los demás roles cumpla con los requisitos. Existen reuniones llamadas RTF que se encarga de verificar y modificar el proyecto si es necesario hasta que no tenga errores. [1] 2.7 Administración de Configuración La administración de configuración por lo general es enfocada al hardware, pero al aplicarla en software determina el buen funcionamiento del sistema. Existe para apoyar el desarrollo del software, así como su ciclo de vida y su evolución. Su función principal es identificar las características de los elementos del sistema, y controlar que los cambios que se implementen sean adecuadamente. [1] 2.8 Ingeniero de Validación y Verificación El proceso de validación y verificación, se refiere a que el sistema debe estar libre de fallas, y que cumple con las expectativas del usuario. Se encarga de que si existe un error, en el desarrollo del software, inmediatamente informar al grupo de desarrollo acerca de éste. Se debe asegurar que se planifiquen todos los testeos requeridos para el sistema, también verifica y evalúa los demás roles, buscando errores o características faltantes.[ 1] 2.9 Documentador La documentación, es para conocer la historia del proyecto, esta no se escribe al final, sino que se va adquiriendo conforme pasan las etapas. Existen dos tipos de documentación, una, es la documentación de procesos de elaboración, y otra es la del producto, que contiene el desarrollo del producto. El documentador debe contar con un repositorio. Además debe construir una manual de uso del sistema para el
PDF created with pdfFactory trial version www.pdffactory.com
usuario final. [1] El documentador sirve como comunicador de los diferentes miembros del equipo. Sobra mencionar que tiene que ser una persona muy ordenada. 2.10 Ingeniero en Manutención El ingeniero en manutención, se encarga de mantener el software, modernizándolo, haciendo modificaciones, existen actividades de manutención preventiva o correctiva. Lo que hace el ingeniero es diagnosticar y corregir los errores, luego adaptar al sistema los cambios, para así satisfacer las recomendaciones del sistema.[1] 3. MODELOS DE CICLOS DE VIDA DE SOFTWARE 3.1 Ciclo de Vida del Software El periodo de tiempo que comienza cuando se concibe un software y concluye cuando el producto ya no está disponible para su uso. El ciclo de vida del software típicamente incluye una fase de requisitos, una fase de diseño, una fase de pruebas, una fase de instalación y aceptación, una fase de operación y mantenimiento, y, con ocasiones, una fase de retirada. Un modelo de ciclo de vida es una abstracción particular que representa un ciclo de vida de software. Un modelo de ciclo de vida se denomina con frecuencia un ciclo de vida de desarrollo software (SDLC, siglas inglesas).[2] 3.2 Modelo en Cascada El primer modelo de proceso de desarrollo de software que se publicó, se derivó de procesos de ingeniería de sistemas más generales. Este modelo se muestra en la figura 1. Debido a la cascada de una frase a otra, dicho modelo se conoce como modelo en cascada o como ciclo de vida del software. Las principales etapas de este modelo se transforman en actividades fundamentales de desarrollo.[3] 1. Análisis y definición de requerimientos. Los servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Entonces, se definen en detalle y sirven como una especificación del sistema. [3] 2. Diseño del sistema y del software. El proceso de diseño del sistema divide los requerimientos en sistemas hardware o software. Establece una arquitectura completa del sistema. El diseño del software identifica y describe las abstracciones fundamentales del sistema software y sus relaciones. [3]
PDF created with pdfFactory trial version www.pdffactory.com
3. Implementación y prueba de unidades. Durante esta etapa, el diseño del software se lleva a cabo como un conjunto o unidades de programas. La prueba de unidades implica verificar que cada una cumpla su especificación.[3] 4. Integración y prueba del sistema. Los programas o las unidades individuales de programas se integran y prueban como un sistema completo para asegurar que se cumplan los requerimientos del software. Después de las pruebas, el sistema software se entrega al cliente.[3] 5. Funcionamiento y mantenimiento. Por lo general (aunque no necesariamente), ésta es la fase más larga del ciclo de vida. El sistema se instala y se pone en funcionamiento práctico. El mantenimiento implica corregir errores no descubiertos en las etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema y resaltar los servicios del sistema una vez que se descubren nuevos requerimientos.[3]
Figura 1. Modelo en Cascada 3.3 Iteración de Procesos Los cambios son inevitables en todos los proyectos de software grandes. Los requerimientos del sistema cambian cuando el negocio que procura el sistema responde a las presiones externas. Las prioridades de gestión también cambian. Cuando se dispone de nuevas tecnologías, cambian los diseños y la implementación. Esto significa que el proceso del software no es un proceso único; más bien, las actividades del proceso se repiten regularmente conforme el sistema se rehace en respuesta a peticiones de cambios. [4] Dos de los procesos que han sido diseñados explícitamente para apoyar la iteración de procesos son: Entrega incremental y Desarrollo en Espiral. [4] 3.3.1Entrega Incremental El modelo de desarrollo en cascada requiere que los clientes de un sistema cumplan un conjunto de requerimientos antes de que se inicie el diseño y que el diseñador
PDF created with pdfFactory trial version www.pdffactory.com
cumpla estrategias particulares de diseño antes de la implementación. Los cambios de requerimientos implican rehacer el trabajo de captura de éstos, de diseño e implementación. Sin embargo, la separación en el diseño y la implementación deben dar lugar a sistemas bien documentados susceptibles de cambios. En contraste, un enfoque de desarrollo evolutivo permite que los requerimientos y las decisiones de diseño se retrasen, pero también origina un software que puede estar débilmente estructurado y difícil de comprender y mantener. [3] La entrega incremental (ver figura 2) es un enfoque intermedio que combina las ventajas de estos modelos. En un proceso de desarrollo incremental, los clientes identifican, a grandes rasgos, los servicios que proporcionará el sistema. Identifican qué servicios son más importantes y cuáles menos.[ 2]
Figura 2. Modelo Incremental Entonces, se derivan varios incrementos en donde cada uno proporciona un subconjunto de la funcionalidad del sistema. La asignación de servicios a los incrementos depende de la prioridad del servicio con los servicios de prioridad más alta entregados primero. [3] Una vez que un incremento se completa y entrega, los clientes pueden ponerlo en servicio.[3] 3.3.2 Desarrollo en Espiral El modelo en espiral del proceso del software (Figura 3) fue originalmente propuesto por Boehm (Boehm, 1988). Más que representar el proceso del software como una secuencia de actividades con retrospectiva de una actividad a otra, se representa como una espiral. Cada ciclo en la espiral representa una fase del proceso del software. Así, el ciclo más interno podría referirse a la viabilidad del sistema. el siguiente ciclo a la definición de requerimientos, el siguiente ciclo al diseño del sistema, y así sucesivamente.[3] Cada ciclo de la espiral se divide en cuatro sectores: 1. Definición de objetivos. Para esta fase del proyecto se definen los objetivos específicos. Se identifican las restricciones del proceso y el producto, y se traza un plan detallado de gestión. Se identifican los riesgos del proyecto. Dependiendo de estos riesgos, se planean estrategias alternativas.[ 3 ]
PDF created with pdfFactory trial version www.pdffactory.com
2. Evaluación y reducción de riesgos. Se lleva a cabo un análisis detallado para cada uno de los riesgos del proyecto identificados. Se definen los pasos para reducir dichos riesgo. Por ejemplo, si existe el riesgo de tener requerimientos inapropiados. se puede desarrollar un prototipo del sistema.[ 3] 3. Desarrollo y validación. Después de la evaluación de riesgos. se elige un modelo para el desarrollo del sistema. Por ejemplo. si los riesgos en la interfaz de usuario son dominantes. un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si los riesgos de seguridad son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado, y así sucesivamente. El modelo en cascada puede ser el más apropiado para el desarrollo si el mayor riesgo identificado es la integración de los subsistemas.[ 3] 4. Planificación. El proyecto se revisa y se toma la decisión de si se debe continuar con un ciclo posterior de la espiral. Si se decide continuar. se desarrollan los planes para la siguiente fase del proyecto.[3]
Figura 3. Modelo en Espiral de Boehm para el proceso del Software (IEEE, 1988) 3.3.3 Modelo de Desarrollo Evolutivo Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximación incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.[3] El desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo no demanda una forma específica de observar el desarrollo de algún incremento. Así, el modelo cascada puede ser usado para administrar cada
PDF created with pdfFactory trial version www.pdffactory.com
esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado también.[ 3] Figura 4. Modelo de Desarrollo Evolutivo
4. GESTIÓN DEL PROYECTO 4.1 Gestión Gestión son todas las actividades y tareas ejecutadas por una o más personas con el propósito de planificar y controlar las actividades de otros para alcanzar un objetivo o completar una actividad que no puede ser realizada por otros actuando independientemente.[5] 4.2 Actividades de Gestión Es imposible redactar una descripción estándar del trabajo de un administrador de software. El trabajo difiere enormemente dependiendo de la organización y del producto de software a desarrollar. Sin embargo, en algún momento, muchos administradores son responsables de algunas o todas de las siguientes actividades: Redacción de la propuesta. Planeación y calendarización del proyecto. Costeo del proyecto. Supervisión y revisión del proyecto. Selección y evaluación de personal. Redacción y presentación de informes.[3] 4.3 Planificación del Proyecto de Software La gestión de un proyecto de software comienza con un conjunto de actividades que globalmente se denominan planificación del proyecto. Antes de que el proyecto comience, el gestor y el equipo de software deben realizar una estimación del trabajo a realizar, de recursos necesarios y del tiempo que transcurrirá desde el comienzo hasta el final de su realización.[6]
PDF created with pdfFactory trial version www.pdffactory.com
4.4 Análisis y Gestión de Riesgos Cuando se pone mucho en juego en un proyecto de software el sentido común nos aconseja realizar un análisis de riesgo. Y sin embargo, la mayoría de los jefes de proyecto lo hacen informal y superficialmente, si es que lo hacen. El tiempo invertido identificando, analizando y gestionando el riesgo merece la pena por muchas razones: menos trastornos durante el proyecto, una mayor habilidad de seguir y controlar el proyecto y la confianza que da planificar los problemas antes de que ocurran. El análisis de riesgos puede absorber una cantidad significativa del esfuerzo de planificación del proyecto.[6] 5. RESULTADOS La administración procura siempre el máximo aprovechamiento de los recursos, mediante su utilización eficiente. Administrar el grupo de trabajo, implica organizar y tratar los individuos en el trabajo. La causa principal de los problemas que se presentan al momento de realizar un proyecto de programación es la falta de planeación. 6. CONCLUSIONES La administración de proyectos implica una gran importancia, por lo que es usada en una gran diversidad de campos; desde proyectos espaciales, en bancos, en organizaciones, pero no solo es aplicado a estos campos, también es usado en el desarrollo de software. El administrador es el responsable de llevar al éxito el proyecto, es decir, que el sistema cumpla con los requerimientos especificados y las necesidades o expectativas del cliente o usuario. Para lograr esto tiene que estar involucrado en todas las etapas (diseño, programación, pruebas, etc.) del modelo de ciclo de vida que elija, debe verificar que cada etapa se cumpla correctamente para poder pasar a la siguiente, y no tener que empezar desde el principio (requisitos del cliente), de esta manera el administrador puede asegurar al cliente que el sistema tiene calidad. REFERENCIAS [1] D. Fuller, Apuntes de Taller de Ingenieria de Software, 2003. [2] “15-el-desarrollo-del-software.pdf.” [3] Somerville Ian, Ingeniería del Software, Madrid: Pearson Educación, 2005. [4] Rodríguez Corrales, Jiménez López, Longorio Vélez, Orduña Cabrera, Reyes Avila, López Morales, Ochoa Estrella, y Sánchez Islava, “Aplicación del método evolutivo incremental en el desarrollo de un simulador didáctico de trayectorias planas,” 2009. [5] C.M. Varas, “Gestión de Proyectos de Desarrollo de Software,” 2000.
PDF created with pdfFactory trial version www.pdffactory.com
[6] R.S. Pressman, Ingeniería del Software: Un Enfoque Práctico, España: McGraw Hill, 2002
PDF created with pdfFactory trial version www.pdffactory.com