Concepto de Proyecto Informático.
Actualmente el concepto de proyecto se aplica al campo de la informática. Este cambio no surgió de la noche a la mañana, sino que fue debido a la evolución de los propios sistemas informáticos. Esta constantemente dobla su capacidad y posibilidades, pero también las exigencias que debe cumplir, siendo la eficacia y rentabilidad de su sistema informática un factor muy importante para las empresas modernas.
Este notable aumento de la complejidad de la informática ha sido la que ha hecho necesario su consideración como proyecto, asociándose las técnicas y procedimientos de diseño, planificación y gestión del proyecto tradicional.
Así, podemos definir entonces como un Proyecto Informático al:
Conjunto de tareas y actividades limitadas en el tiempo, encaminadas a alcanzar un objetivo bien definido, en un plazo determinado y con determinados recursos dados (humanos, materiales, presupuestarios, etc.) que contribuyan al logro de los efectos específicos que un programa define. Este se lleva a cabo para crear un producto o servicio y expresa el nivel operativo del proceso de planificación gestión y control.
Objetivos de un proyecto.
Una de las fases más complejas del proyecto es la de definir los objetivos. La persona que encarga el proyecto rara vez conoce claramente los objetivos, tan solo tiene una idea general de querer informatizar algún proceso o gestionar algo. Este es uno de los inconvenientes con que se encuentra el informático en las primeras fases del proyecto. El no definir los objetivos correctamente es la causa de muchos de los problemas que se presentan durante el ciclo de desarrollo del proyecto como pueden ser:
El cliente puede no quedar satisfecho con el producto final, ya que es posible que no haya definido correctamente lo que quiere.
El cliente puede introducir objetivos o restricciones durante la ejecución del proyecto que afecten de manera sustancial al mismo.
La no concreción o ambigüedad de los objetivos puede provocar que nadie se responsabilice de los fallos, ya que gran parte del proyecto habrá sido dejado al criterio del programador, en vez de ser este únicamente el técnico que permita obtener los objetivos impuestos por el cliente.
Los objetivos debe fijarlos quien encarga el proyecto, y estos deben ser claros, concretos y no ambiguos, además deben quedar definidos desde el primer momento en que se establezca el convenio de trabajo.
Ciclo de vida de un software.
Por ciclo de vida, se entiende: La sucesión de etapas por las que pasa el software desde que un nuevo proyecto es concebido hasta que se deja de usar. Cada una de estas etapas lleva asociada una serie de tareas que deben realizarse, y una serie de documentos (en sentido amplio: software) que serán la salida de cada una de estas fases y servirán de entrada en la fase siguiente.
La elección de un paradigma u otro se realizan de acuerdo con la naturaleza del proyecto y de la aplicación, los métodos a usar y los controles y entregas requeridos
La elección del ciclo de vida más apropiado para un proyecto es una cuestión fundamental en la estrategia con la que se afronta, ya que incide muy decisivamente en la velocidad con la que se llevará a cabo el proyecto y la satisfacción que generará al cliente. El ciclo de vida claramente dominante hasta hace relativamente poco era el modelo en cascada donde existen las fases de recogida de requisitos, análisis, diseño, codificación, pruebas y mantenimiento del producto. Todas ellas se ejecutan en secuencia, lo que le ha dado a este tipo de ciclo de vida su nombre.
Modelos de ciclos de vida de un software
Existen diversos modelos de ciclo de vida, es decir, diversas formas de ver el proceso de desarrollo de software, y cada uno de ellos va asociado a un paradigma de la ingeniería del software, es decir, a una serie de métodos, herramientas y procedimientos que debemos usar a lo largo de un proyecto. Aquí veremos algunos de los principales modelos de ciclo de vida.
"Modelo en cascada".
El modelo en cascada es el ciclo de vida clásico, su principal característica es la naturaleza estrictamente secuencial de la ejecución de sus fases. Al aprobar cada una de ellas se genera la documentación adecuada que permite comenzar con la siguiente, ante defectos que se detectan en la ejecución de una fase determinada posiblemente haya necesidad de volver a la fase inmediatamente anterior y corregir o modificar algunos de sus contenidos, pero es algo que se debe evitar en la medida de lo posible. Esta naturaleza se explica con el carácter más homogéneo de las aplicaciones y la plataforma tecnológica mucho más simple de hace unas décadas (las aplicaciones eran prácticamente siempre aplicaciones de gestión sobre host con un nivel de complejidad relativamente simple frente a las actuales). Este modelo resulta adecuado cuando los requisitos están bien definidos, son estables desde el comienzo del proyecto y se dominan las metodologías y herramientas utilizadas en el proyecto, ya que minimiza el tiempo dedicado a cada una de las tareas.
Ventajas:
Minimiza las tareas de desarrollo repetidas y por tanto el esfuerzo de desarrollo invertido en total.
Minimiza la carga de planificación de los ciclos iterativos de otros ciclos de vida.
Permite afrontar la complejidad de proyectos grandes de una manera muy ordenada y aumenta así las posibilidades de éxito.
Ayuda a trabajar mejor con equipos de desarrollo de relativamente baja calificación por el alto control de cada actividad y sus resultados.
Inconvenientes
Es muy inflexible, por tanto solamente resulta adecuado cuando hay requerimientos muy bien definidos y muy estables, algo que es difícil de encontrar.
Retroceder en las fases para corregir errores que se han cometido en fases previas o adaptar el proyecto a cambios resulta muy difícil y costoso en esfuerzo.
Aunque la documentación elaborada permite un seguimiento bueno del proyecto para una persona calificada, los resultados tangibles para el cliente aparecen prácticamente al final del proyecto, algo que muchas veces no aceptan los clientes.
"Modelo prototipo".
Fase A: El objetivo de la fase A es verificar la adecuación del sistema que se va a desarrollar a los requerimientos expresados por el usuario. Exige una evaluación por parte de éste: una vez el prototipo aceptado ya se tiene un modelo a escala del sistema completo que hay que construir.
Fase B: El punto de entrada en la fase B es el prototipo construido y aceptado en el que se han detallado los diseños de pantalla y listados, los encadenamientos de módulos y los flujos de datos. Con estas informaciones contrastadas ya se tiene la descomposición en programas, con lo que este modelo de ciclo de vida en la fase B se ocupa del desarrollo y prueba de los programas y de la integración de los mismos en la solución final.
Ventajas:
El caso de requerimientos cambiantes e incapacidad de parte del cliente para definirlos con el suficiente detalle se da con frecuencia, abordar el proyecto de esta manera es una solución muy natural ante este problema y evita en gran medida los conflictos con el cliente.
El cliente participa muy activamente en el desarrollo, por tanto, las posibilidades de alcanzar un producto que haga lo "que el quiere" son altas.
Aporta resultados tangibles que permiten al cliente medir el progreso del proyecto.
En muchas ocasiones el cliente gana tiempo en el sentido que ya le resultan útiles los primeros prototipos y amortiza la inversión desde un punto muy temprano mientras que se sigue mejorando el resultado final. Esta faceta frecuentemente hace que el cliente esté dispuesto a asumir una inversión global algo mayor a la que estaría dispuesto hacer si tuviera que esperar hasta la entrega final del producto, añade por tanto mucha flexibilidad a la negociación del proyecto
Inconvenientes:
En proyectos de cierta envergadura es prácticamente imposible saber cuando se llegará al producto final, ni cuantos prototipos intermedios serán necesarios hasta entonces.
No es fácil convencer al cliente de la necesidad de tirar determinados prototipos "a la basura", hay una gran tentación de no llegar al final con las iteraciones necesarias.
Desde el punto de vista de los desarrolladores, este ciclo de vida puede ser una tentación a desarrollar de forma anárquica, es decir, dejar de lado la modificación de la especificación de requisitos, análisis, etc. que corresponde a cada iteración.
"Modelo Desarrollo en espiral".
El desarrollo en espiral es un ciclo de vida muy orientado a la eliminación progresiva de los riesgos, es un ciclo de vida iterativo en cuyas iteraciones se enfocan uno o más riesgos objetivos que han de superarse hasta que el nivel de riesgo sea suficientemente bajo para continuar con un ciclo menos complejo.
En cada iteración se realizan los siguientes pasos:
Planificación: Determinar objetivos, alternativas y restricciones.
Análisis de riesgo: Análisis de riesgos y evaluación de alternativas.
Ingeniería: Desarrollo de los entregables o prototipos de la iteración.
Evaluación del resultado: Evaluación y validación del resultado.
Ventajas:
Puesto que se trata de un modelo orientado a los riesgos del proyecto da un nivel de seguridad muy elevado al proyecto, los riesgos se eliminan al principio que es cuando mejor se puede reaccionar a ellos y en el caso negativo extremo de detectar la inviabilidad del proyecto, minimiza la inversión realizada en él.
Una mayor inversión en esfuerzo (y con ello tiempo y dinero) se traduce directamente en mayor seguridad del proyecto, ya que permite gestionar con mayor dedicación los riesgos.
El cliente dispone mediante los prototipos de resultados tangibles en cada iteración y participa de una manera muy interactiva en la evolución del proyecto con lo cual se mejoran mucho las posibilidades de satisfacción del resultado. Inconvenientes:
El único inconveniente es la complejidad y carga de gestión de este modelo.
El desarrollo orientado a prototipos que se evalúa progresivamente no se debe confundir con este modelo en espiral, aunque tienen bastante parecido en cuanto a su carácter iterativo, en el modelo en espiral se trata de enfocar los mayores riesgos desarrollando primero las facetas relacionadas con ellos y eliminarlos así cuanto antes, es decir, los riesgos determinan la evolución del proyecto. En el desarrollo evolutivo de prototipos se parte de un concepto inicial de la aplicación y es este concepto el que evoluciona. Es decir, en este modelo se desarrolla un primer prototipo relativamente completo, frecuentemente destinado a ser ya utilizado por cliente. El cliente aporta realimentación y con ella se desarrolla la siguiente versión, y así sucesivamente hasta que se alcance una versión que le satisface. Resulta útil cuando el cliente tiene prisa en desarrollar la aplicación, pero no es capaz de definirla con exactitud y el mismo tiene que aprender más de la problemática que debe resolver con la aplicación. También resulta adecuado cuando se prevé que los requerimientos van a tener una tasa de cambio alta durante el desarrollo del proyecto.
"Modelo Desarrollo orientado a Hitos"
Con frecuencia se da el caso que el factor limitante es el tiempo más que el presupuesto o el detalle de la funcionalidad. En estos casos puede ser muy oportuno aplicar este ciclo de vida que asume ciertas indefinición en la envergadura final de las funcionalidades implementadas, pero fija claramente un punto final en el tiempo. En un desarrollo grande puede ser además muy útil para gestionar el desarrollo de módulos individuales no críticos con el fin de que no retrasen el progreso global del proyecto.
En este ciclo de vida básicamente se trabaja secuencialmente en la base estable del producto que incluye llegar hasta el diseño de la arquitectura, pero a partir de ahí se trabaja en ciclos iterativos sobre el diseño detallado, codificación y pruebas. Los contenidos de estos ciclos se priorizan para optimizar según la relevancia de las funcionalidades implementadas.
Ventajas:
Es una estrategia relativamente óptima ante una situación de fecha límite rígida.
Permite reducir mucho el riesgo en proyectos grandes si se gestionan sus módulos de menor prioridad con esta técnica.
Inconvenientes:
Si se consiguen implementar relativamente pocas funcionalidades de las previstas se habrá perdido mucho tiempo en la especificación y diseño de funcionalidades no implementadas al final, por tanto hay que medir bien la ambición del trabajo previo a los ciclos iterativos.
Nótese que se combina en cierta manera el enfoque clásico con el modelo en espiral dividiendo la parte más gruesa del desarrollo en fase priorizadas que permiten optimizar la relevancia del trabajo realizado dentro de unos límites de tiempo, obsérvese especialmente el matiz que la fase de diseño no iterativa se limita al diseño de la arquitectura ya que no varía con las iteraciones.
"Modelo de desarrollo en versiones sucesivas".
Este modelo de ciclo de vida pretende resolver uno de los problemas del modelo en cascada: La tardía aparición de un modelo funcional del sistema en desarrollo.
Para ello se realiza una serie de iteraciones sobre el propio modelo en cascada. En la primera se obtiene una primera versión del sistema. En cada una de las demás iteraciones el modelo se refina hasta alcanzar una versión definitiva que satisfaga plenamente los requerimientos de usuario.
En cada iteración, se reelaboran los requerimientos según se encuentren carencias o inexactitudes con la idea original del usuario. Los nuevos requerimientos se someten a análisis, se modifican los diseños, y se procede a las modificaciones pertinentes del código. Finalmente se procede a probar la nueva versión del modelo. Si el resultado obtenido se ajusta a los deseos del usuario, el proceso finaliza, en caso contrario se procede a una nueva iteración.
Las versiones obtenidas pueden obedecer también a un único plan inalterable. En este caso lo que se hace es realizar una implementación gradual de los requerimientos, en la que se pasa de un esbozo funcional a versiones cada vez más refinadas y cercanas a las especificaciones. En esta forma se denomina Modelo evolutivo.
Los principales inconvenientes de este paradigma están en las tareas de modificación de código, que resultan complejas y sujetas a errores salvo que se haga uso de herramientas automáticas o lenguajes de cuarta generación. Otro problema es que las posibles incorrecciones, o los "parches" incorporados a una versión, permanecen en ella y se convierten en la base para el código posterior. De esta forma, una mala estructuración, arquitectura defectuosa o soluciones parciales que sirven para hacer operativamente correcta una versión, degradan el trabajo invertido en la construcción de las siguientes.
"Modelo de transformación".
Este modelo trata de resolver los problemas asociados a la dificultad de modificar el código en paradigmas como el de versiones sucesivas. Para ello parte de la premisa de la existencia de un sistema que pueda convertir fácilmente los requerimientos en código.
Los pasos seguidos en este modelo son:
Una especificación formal del sistema.
Una transformación automática (o asistida) de las especificaciones a código.
Una serie de iteraciones sobre el código obtenido con objeto de mejorarlo.
Prueba general del resultado.
Iteraciones para ajustar el resultado a las especificaciones. Si se realiza alguna modificación sobre éstas se repite el proceso hasta que requerimientos y código final sean válidos.
La principal dificultad para la aplicación de este modelo de desarrollo está en la falta de un sistema adecuado para transformar los requerimientos en código. Esta transformación puede ser llevada a cabo en pequeños proyectos dedicados a tareas específicas, pero no es posible generalizar su aplicación.
"Modelo Mixto"
Los modelos presentados solo son algunos de los existentes, ante un proyecto concreto cabe la posibilidad de combinar modelos diferentes si el perfil del proyecto lo hace aconsejable, es decir, los modelos presentados no se deben interpretar con un espíritu excesivamente purista, sino tomarlos como estrategias de base ante una serie de características de un proyecto.
Lo importante es que se haga el ejercicio de plantear una estrategia de desarrollo que responda de una manera coherente a la situación previsible del proyecto al que se aplica. Los modelos aquí presentados pueden ser válidos para muchas ocasiones, y si no lo fueran constituirán una "inspiración" para diseñar un modelo a medida más adecuado.
Para ayudar a realizar este ejercicio aportamos una serie de preguntas:
¿Cómo de bien entendemos el cliente y yo los requisitos al comienzo del
proyecto? ¿Es probable que cambien a lo largo del proyecto?
¿Entiendo la arquitectura del sistema? ¿Necesitaré realizar cambios significativos en la arquitectura del sistema durante el desarrollo del proyecto?
¿Qué nivel de fiabilidad necesito?
¿En qué medida tengo que planificar y diseñar en vista de las futuras versiones?
¿Cuál es el nivel de riesgo del proyecto?
¿Debo tener en cuenta fechas límite?
¿Será necesario disponer de capacidad de maniobra para realizar correcciones en la mitad del proyecto?
¿Me va a exigir la dirección resultados intermedios tangibles?
Tipos de proyectos informáticos
Las tipologías existentes responden a la necesidad de clasificación de los distintos proyectos que se presentan. Las tipologías relevantes para proyectos de informática son:
Proyectos de Desarrollo de aplicaciones: elaboración y puesta en marcha de programas o sistemas computacionales.
Proyectos de Equipamiento: adquisición por primera vez de equipos, incluyendo tanto hardware como software básico.
Proyectos de Mejoramiento, ampliación o reposición: aumento de capacidad y calidad de servicios de hardware y/o mejoramiento de software.
Atendiendo al criterio de riesgo en la ejecución y grados de libertad en la implantación podemos distinguir otra tipología de proyectos:
Proyectos de investigación básica: La investigación básica es la que se realiza con total libertad hasta el punto que a veces no existen objetivos marcados. Su libertad es máxima y el riesgo de no conseguir algún resultado es muy grande
Proyectos de investigación aplicada: Existen menos grados de libertad y se pueden marcar algunos objetivos a conseguir, no obstante el riesgo sigue siendo alto en este tipo de proyectos. Es en este tipo donde empieza a aplicarse el concepto de proyecto definido anteriormente, ya que cada investigación ira dirigida a un propósito determinado y se le asignaran unos recursos, aunque estos pueden ser cambiantes con el tiempo.
Proyectos de investigación y desarrollo: Estos ya son aplicaciones muy específicas que han de dar lugar a la producción de prototipos y donde se realiza un diseño previo, se proponen unos objetivos y se realiza un estudio de viabilidad.
Proyectos correspondientes a la construcción de cualquier elemento: El grado de libertad de que se dispone en este tipo de proyectos es todavía menor que en los anteriores, ya que conocemos el coste, la cantidad y la naturaleza de los recursos.
Vemos que se puede considerar proyecto según la definición que hemos considerado a los tres últimos tipos pero no así al proyecto de investigación básica.
Por otra parte, es conocida la gran diferencia existente entre los objetivos y finalidades de la empresa publica y privada, por lo que, los proyectos pueden ser a su vez públicos o privados.
Esta diferenciación tiene unas características distintas, aunque no lo suficientemente grande como para hacer un estudio diferenciado de sus metodologías de desarrollo.
Sin embargo aunque los proyectos informáticos para la educación se pueden considerar en las tipologías mencionadas anteriormente, existe una específica creada para este fin:
Macroproyectos: Estos involucran a toda la comunidad educativa, ejemplo: Proyecto Educativo Institucional, o sea es el proyecto principal que se desarrolla en una institución escolar y a la cual responden todos los demás proyectos.
Mesoproyectos: En estos están involucran algunos componentes de una comunidad educativa específica, ejemplo: Proyecto de Informática Educativa de un departamento docente.
Microproyectos: Son diseñados, desarrollados y evaluados en el ámbito de un aula o en distintos proyectos de menos complejidad que se creen dentro del aula dividida en grupo, ejemplo: Proyecto sobre Protección Ecológica en la Escuela. Este se centra principalmente en el aprendizaje de los alumnos.
Este último se divide en dos grupos:
Según el origen del tema:
Provenientes del mundo real: Se basan en una realidad específica que envuelve a los participantes o sea un caso real.
Simulación de un contexto hipotético: Se generan para una situación hipotética o simulada, conocido también como caso de estudio.
Según el diseño:
No estructurados: Es cuando el diseño es claro y específico, elaborados en forma intuitiva, generalmente por los propios alumnos.
Semi-estructurados: Estos siguen un formato específico pero dejan la posibilidad de realizar cambios, redefinir metas y objetivos durante su desarrollo.
Estructurados: Tienen un diseño claro y específico, que no da lugar a cambios ni modificaciones.
Roles, competencias y funciones
Con el objetivo de ayudar a optimizar el trabajo en los proyectos informáticos surgen determinados roles que juegan diferentes funciones y llevan asociado ciertas habilidades para el desarrollo de un proyecto. Estos roles son asignados por el profesor o líder de proyecto y esta en correspondencia con las características de los miembros del equipo.
Desde el comienzo mismo de un proyectos no todos los roles quedan definido, algunos de estos surgen a medida que se desarrolla el proyecto, otros al final del mismo. Igualmente algunos roles iniciales son sustituidos por otros que desarrollan la misma función pero con mayor grado de dificultad, puede suceder que un rol inicial desaparezca, esto da la posibilidad de que un mismo miembro del equipo asuma varios roles, ya que durante el periodo que dure el proyecto, y al final del mismo, surgen otros roles asociados a otras funciones necesarias para la terminación y posterior mantenimiento del producto resultante. Bajo este concepto, cualquier miembro del equipo puede asumir dos o más roles en un mismo proyecto.
Roles definido:
Jefe de proyecto.
Planificador de equipo.
Especificador de requerimientos (incluye las funciones del Administrador de requerimientos).
Analista del sistema (incluye las funciones del Diseñador del sistema).
Diseñador de interfaz de usuario (incluye las funciones del Artista gráfico).
Administrador del sistema (incluye las funciones del Responsable de despliegue).
Arquitecto de software (incluye las funciones del Especialista en herramientas).
Líder de Gestión de configuración.
Diseñador de Base de Datos.
Implantador e Integrador (en su máximo desempeño acredita al Líder de desarrollo).
Diseñador de pruebas.
Escritor técnico.
Estos roles pueden estructurarse en 5 grupos fundamentales:
Roles propios de la actividad de dirección de los proyectos.
Roles característicos de la actividad de analista del software.
Roles relacionados con la actividad de soporte a los productos de software.
Roles propios de la actividad de desarrolladores de software.
Roles vinculados a la realización de pruebas al producto elaborado.
A continuación describimos cada uno de los grupos con sus correspondientes roles:
Dirección de los proyectos: Organiza los roles que están involucrados fundamentalmente en la gestión y configuración del proceso de ingeniería de software. El grupo de dirección esta formado por los roles siguientes:
Jefe de proyecto:
Funciones:
Gestiona y asigna recursos humanos y de otro tipo.
Define las prioridades de las tareas dentro y/o relacionadas con el proyecto.
Coordina las interacciones con los clientes y los usuarios finales.
Planifica las iteraciones.
Planifica y asigna las tareas de la forma más razonable posible.
Define la organización y estructura del proyecto.
Establece las líneas de trabajo a seguir para garantizar la calidad e integridad de los artefactos del proyecto.
Motiva y organiza el equipo de trabajo para lograr un objetivo definido.
Establece los horarios de trabajo del equipo de desarrollo.
Planifica y realiza las reuniones de control del equipo de desarrollo en el tiempo establecido.
Mantiene el control del resultado de estas reuniones.
Informa sobre el estado actual del proyecto.
Mantiene el plan del proyecto.
Suministra al equipo el informe del ciclo de desarrollo.
Artefactos y controles:
a. Lista de Stakeholders y Responsabilidades.
b. Documento Visión del proyecto.
c. Contratos con el cliente.
d. Compromisos del cliente.
e. Carta de liberación del sistema.
f. Lista de Riesgos.
g. Reporte de Estatus del Proyecto. Entre ellos:
Desviación de tiempos.
Desviación del presupuesto.
Riesgos.
Errores.
Problemas.
i. Planificación del proyecto (project).
j. Registro de control de tiempo de los miembros del equipo.
Habilidades:
1. Dominar técnicas de motivación, organización.
2. Dominar técnicas de distribución y asignación de recursos humanos y materiales.
3. Utilizar métodos de comunicación.
4. Conocer completo ciclo de vida de un proyecto (software).
5. Dominar técnicas de planificación de tiempo, estimación de costos, estimación de proyectos y estimación de riesgos.
6. Dominar la Organización de equipos de desarrollo de software, estructuración de equipo, distribución de tareas y administración del tiempo.
7. Dominar los artefactos generados en un proceso de desarrollo de software.
8. Dominar los Controles de versiones.
9. Dominar las herramientas de planificación como el Microsoft Project.
10. Conocer metodologías Ágiles de desarrollo de software.
11. Dominar las metodologías de investigación.
12. Dominar Normas de Calidad y Estándares Internacionales.
Líder de desarrollo:
Funciones:
Guía al equipo de desarrollo en una estrategia de desarrollo.
Establece las estrategias según el tamaño de la tarea y el tiempo disponible, según estimaciones.
Conduce el desarrollo del producto hacia los requerimientos.
Guía al equipo en el más alto nivel de diseño.
Guía al equipo en la especificación del diseño del software.
Guía al equipo en las pruebas del sistema.
Guía al equipo en la producción de la documentación del usuario.
Participa en la producción del reporte de desarrollo.
Habilidades:
1. Conocer la algoritmización y habilidades como programador en diferentes lenguajes de programación.
2. Dominar el diseño de Bases de Datos.
3. Dominar los Diferentes Gestores de Bases de Datos.
4. Dominar las diferentes plataformas de desarrollo.
5. Conocer las Tecnologías de avanzada.
6. Dominar e interpretar los artefactos generados por el proceso de desarrollo de software.
Planificador de equipo:
Funciones:
Se encarga de la planificación de las tareas del equipo y de cada miembro en específico.
Divulga el estado de desarrollo del proyecto entre los miembros del equipo.
Planifica el trabajo del equipo para el siguiente ciclo de desarrollo.
Planifica el horario de trabajo.
Confecciona el plan de balance.
Controla que el desarrollo marche de acuerdo al plan.
Participa en la elaboración del reporte de estado del proyecto en el ciclo.
Artefactos y Controles:
a. Plan del Proyecto.
b. Plan de Trabajo General (Gantt).
c. Plan de Trabajo por Fase (Gantt).
d. Estimación en Puntos de Función.
e. Estimación de Esfuerzo.
f. Control de Versiones del Plan de Trabajo.
g. Carta de Aceptación de Compromisos.
Habilidades:
1. Dominar las Técnicas de planificación y organización.
2. Conocer las herramientas de planificación como el Microsoft Project.
3. Conocer la Estimación de costos, esfuerzo y tiempo de desarrollo.
Administrador de configuración:
Funciones:
Define y supervisa el proceso de control de cambios.
Responsable de proporcionar al equipo de desarrollo la
infraestructura general, de gestión de cambios y ambiente de trabajo.Establece, controla e informa al Líder de Proyecto
sobre la política de control de cambios.Responsable del funcionamiento correcto de los servidores
y las estaciones de trabajo durante el desarrollo y pruebas del software.Responsable de las salvas del proyecto y de la base de
datos.Responsable de la correcta instalación y configuración
del producto en el lugar de destino.
Artefactos y Controles:
a. Reporte de Configuración.
b. Herramienta de control de configuración (Source Safe).
c. Otros elementos.
Habilidades:
1. Dominar las infraestructuras y plataformas de desarrollo.
2. Dominar los softwares para el control de versiones.
3. Dominar las Herramientas para la configuración de las estaciones de trabajo y los servidores.
4. Dominar la instalación y configuración de sistemas operativos del lado del cliente y del servidor.
Especificador de requerimientos:
Funciones:
Lidera al equipo que realiza la captación de requerimientos.
Se encarga de especificar los detalles de una o varias partes de la funcionalidad del sistema, describiendo uno o varios aspectos de los requisitos.
Artefactos:
a. Especificación de Requerimientos:
Artefactos de ingeniería en la especificación de requerimientos.
Casos de Uso, Flujos de Eventos, Modelo Conceptual, Glosario de Términos, Requerimientos No Funcionales, Diagrama de Distribución, Prototipo GUI
b. Controles en la especificación de requerimientos.
Firma de Validación del Cliente.
Autorización del Líder de Proyecto.
Control de la Versión.
Priorización de Casos de Uso.
c. Especificación de Caso de Uso. d. Documento de Visión. e. Matriz de Requerimientos. f. Control de Casos de Uso y su Estatus. g. Solicitud de Cambios. h. Control de Cambios.
i. Diagramas de Actividad.
j. Diagramas de clases de alto nivel.
k. Conjunto de normas adheridas.
l. Diagrama de despliegue.
m. Diagrama de paquetes.
Habilidades:
1. Dominar las Técnicas de Recopilación de Información.
2. Dominar los artefactos generados en el proceso de captación de requerimientos.
3. Dominar los procesos de gestión de cambios, especificación de casos de uso.
4. Descubrir los procesos de negocio: Aquí los analistas deben entender perfectamente los procesos de negocio del cliente, entrevistando al cliente, o una persona bien informada designada por el cliente, y pidiendo a la persona entrevistada examinar los procesos relevantes gradualmente.
5. Realizar un Análisis de Dominio: El analista se entrevista con el cliente con el objetivo de conocer las entidades principales en el dominio del cliente. Durante la conversación entre el cliente y el analista se deben tomar apuntes. Desde estos apuntes, se buscarán las clases para los objetos del modelo, buscando los sustantivos (Eje.: proveedor, pedido, factura…) y convirtiéndolos en clases. Después se verá que algunos de estos sustantivos pueden ser atributos de otros en vez de entidades por sí mismas. También se buscarán los métodos para estas clases, buscando los verbos (Eje.: Calcular, imprimir, Agregar…).
6. Identificar Sistemas de Cooperación: Durante el proceso de desarrollo el equipo averiguará de qué sistemas dependerá el nuevo sistema y qué otros sistemas dependerán de él.
7. Descubrir los Requerimientos del Sistema: En esta acción el equipo se compone de personas con poder de decisión de la organización del cliente, usuarios potenciales y miembros del equipo de desarrollo. Un Facilitador modera la sesión. El trabajo del Facilitador debe ser el de obtener de las personas que representan al cliente, y de los usuarios, qué es lo que quieren que el sistema haga. Al menos dos miembros del equipo deberían tomar apuntes y el modelador de objetos debería refinar el diagrama de clases que se obtuvo antes.
Analista del software: Agrupa los roles que están involucrados fundamentalmente en la extracción e investigación de los requisitos del sistema. Este grupo esta formado por los siguientes roles:
Analista del sistema:
Funciones:
Dirige y coordina el proceso de extracción de requisitos y desarrollo del modelo de casos de uso, definiendo las funcionalidades y límites del sistema.
Responsable del diseño del sistema, dentro de los límites de: Los requisitos, la arquitectura, y el proceso de desarrollo del proyecto.
Habilidades:
1. Entender el Uso del Sistema: En la reunión con los usuarios potenciales, los desarrolladores deben descubrir a los actores que inician cada Caso de Uso y a los actores que se beneficiarán de ellos (Un actor puede ser tanto un sistema como una persona).
2. Desarrollar Casos de Uso: Se debe seguir trabajando con los usuarios. El objetivo es analizar la secuencia de pasos a ejecutar por cada Caso de Uso del diagrama.
3. Refinar los Diagramas de Clases: El modelador de objetos, observando todas las discusiones de las reuniones, refina los diagramas de clases. El o ella deberán rellenar los nombres de las asociaciones, localizar las clases abstractas, multiplicidad, generalizaciones y agregaciones.
4. Analizar los cambios de Estado de los Objetos: También el modelador de objetos refina el modelo mostrando los cambios en el estado de un objeto.
5. Definir las interacciones entre los objetos: En este momento el equipo de desarrollo cuenta con juegos de casos de uso y un diagrama de clases refinado, es hora de definir cómo los objetos actúan entre sí. El modelador de objetos desarrolla un juego de diagramas que incluye los cambios de estado.
6. Analizar la Integración con los Sistemas Cooperantes: El ingeniero de sistema, que hasta ahora ha estado de forma paralela en todos los pasos procedentes, descubre los detalles específicos para la integración con el resto de los sistemas con los que se debe cooperar. ¿Qué tipo de comunicación se debe emplear? ¿Cuál será la arquitectura de red? ¿El sistema tendrá acceso a una base de datos? Y si lo tendrá, ¿a que tipo de base de datos?
7. Conocer UML.
Artefactos:
a. Diagrama de Casos de Uso.
b. Descripción de Casos de Uso.
c. Diagrama de Clases.
d. Diagrama de Estado.
e. Diagrama de secuencia.
f. Diagrama de Colaboración.
g. Diagrama de despliegue.
h. Modelo de Datos.
Debe conocer además todo lo concerniente a Administración de Riesgos:
a. Lista de Riesgos.
b. Control de Asuntos Pendientes y Problemas.
c. Reporte de Quejas del Cliente.
Diseñador de la interfaz de usuario:
Funciones:
Coordina el diseño de la interfaz de usuario, utiliza los requisitos de uso y crea prototipos candidatos de interfaz de usuario de acuerdo a ellos.
Encargado de realizar el trabajo artístico que requiera el proyecto (íconos, pantalla de splash, gráficos, etc.)
Habilidades:
1. Conocer como se pueden categorizar los usuarios y explicar cada uno, los pasos en el proceso del diseño de la interfaz y definir cada uno de ellos.
2. Explicar los aspectos del diseño.
3. Conocer en qué consiste la evaluación del diseño.
4. Dominar las herramientas de implementación de interfases.
5. Trabajar con herramientas de diseño tales como (Macromedia Flash, Adobe PhotoShop, Fireworks, etc.).
6. Conocer Teoría de diseño y de logotipos.
Soporte a los productos de Software: Roles que no están directamente vinculados a la definición, gestión, desarrollo, o pruebas del software; pero que son necesarios como soporte del proceso de desarrollo de este, para producir materiales adicionales que requiere el producto final.
Escritor técnico:
Funciones:
Responsable de producir los materiales de soporte a los usuarios finales como por ejemplo: guías de usuarios, textos de la ayuda, notas asociadas a la salida del software, etc.
Habilidades:
1. Dominar técnicas de comunicación.
2. Dominar técnicas de redacción.
3. Dominar Microsoft Word.
4. Conocer Herramientas de creación de ayudas.
Administrador del sistema:
Funciones:
Encargado de mantener el ambiente de desarrollo tanto de hardware como de software.
Administración del sistema.
Realización de copias de respaldo.
Responsable de planificar la transición del producto hacia la comunidad de usuarios finales, asegurando que los planes se establezcan correctamente, tratando los problemas y monitoreando el progreso.
Habilidades:
1. Conocer la instalación, configuración y administración de sistemas operativos.
2. Conocer el hardware de computadoras.
3. Conocer el hardware de redes.
4. Dominar las técnicas de planificación.
5. Dominar las técnicas de recopilación de información.
Artefactos y Controles:
a. Plan de transición del producto.
b. Plan de encuestas de satisfacción de los clientes y usuarios finales.
c. Registro de Resultados de encuestas de satisfacción.
Desarrolladores de software: En el grupo de los desarrolladores se organizan los roles que están involucrados fundamentalmente en el diseño e implantación de software. En él se agrupan:
Arquitecto de software:
Funciones:
Responsable de la arquitectura del software.
Decisiones técnicas más importantes en cuanto a las restricciones del diseño global e implantación del proyecto.
Responsable de la selección, gestión y obtención de las herramientas que se utilizarán en el proyecto.
Debe instalar, configurar y asegurar que estas herramientas funcionan como se espera.
Habilidades:
1. Usar y manejar herramientas CASE como Racional Rose y otras.
2. Conocer y diseñar la arquitectura apropiada de sistemas informáticos según su naturaleza y complejidad.
3. Tener un amplio conocimiento de patrones de diseño.
4. Estar familiarizado con las herramientas que son más útiles en un proyecto específico, además de saber solucionar cualquier problema que surja con estas.
Diseñador de base de datos:
Funciones:
Responsable del diseño del almacén de datos persistentes utilizado por el sistema.
Responsable de las actualizaciones, correcciones y mantenimiento de la Base de Datos del Sistema.
Habilidades:
1. Conocer y dominar sobre el diseño y administración de bases de datos.
2. Dominar varios de los principales sistemas de gestión de bases de datos más utilizados hoy en día.
3. Saber utilizar herramientas CASE, estas pueden ser Rational Rose y Erwin Studio, las cuales forman parte del programa de estudio de la carrera.
Implantador e integrador:
Funciones:
Responsable de la implantación y pruebas de los componentes.
Programa todo lo preescrito en la etapa de diseño.
Responsable de planificar y llevar a cabo la integración de elementos de implantación para producir versiones compiladas.
Habilidades:
1. Dominar las técnicas de programación.
2. Conocer la mayor cantidad posible de lenguajes
de programación.3. Dominar Herramientas para la creación de
paquetes e instaladores.
Pruebas al producto: Organiza todos los roles que tratan habilidades
especificas para las pruebas. Debe tenerse en cuenta que existen roles adicionales
implicados en la disciplina de pruebas que se derivan y extienden de las habilidades
básicas de otros grupos de roles. En este grupo se incluyen los roles:
Diseñador de pruebas:
Funciones:
Lleva la responsabilidad general de asegurar el éxito del esfuerzo en las actividades de pruebas. Incluye la defensa de la calidad y pruebas, gestión y planificación de recursos, y la resolución de problemas que obstruyan la realización de las pruebas.
Encargado de definir la estrategia de pruebas y asegurar su correcta implementación.
También implica la identificación de las técnicas apropiadas, herramientas e instrucciones necesarias para implantar las pruebas necesarias.
Habilidades:
1. Conocer el proceso de planificación de las pruebas necesarias para cada iteración (pruebas de sistema y pruebas de integración).
2. Diseñar e implantar las pruebas diseñando los casos de prueba.
a. Describir casos de prueba de cada construcción.
b. Identificar y estructurar los procedimientos de prueba.
3. Dominar diseño de pruebas.
4. Dominar Herramientas de control de errores.
5. Dominar las Normas y Estándares Internacionales.
6. Dominar las técnicas de recopilación y organización de información.
Debe dominar los siguientes artefactos:
a. Modelo de pruebas.
b. Casos de prueba.
c. Procedimientos de prueba.
d. Componentes de prueba.
e. Plan de prueba.
f. Defectos.
g. Evaluación de la prueba.
h. Artefactos de Auditorías.
i. Reporte de no conformidades.
j. Checklist de auditoria a proyecto.
k. Reporte de acciones correctivas.
l. Pruebas.
m. Control de pruebas a Casos de Uso.
n. Control de errores.
Equipo de desarrollo cliente-usuario
Asimismo existen dos actores en la elaboración del proyecto que vale la pena mencionar:
Cliente o usuario. Cuyos derechos y obligaciones son:
Fija los objetivos del proyecto.
Decide el inicio del proyecto.
Hace seguimiento del proyecto.
Sugiere modificaciones a los límites del proyecto.
Recibe el prototipo y lo evalúa.
Cumple con obligaciones financieras.
Introducción al Proceso de Software Personal.
El desarrollo de productos software implica algo más que escribir instrucciones de programación juntas y ejecutarlas en un ordenador. Requiere cumplir requisitos del cliente a un costo y planificación acordada. El Proceso de Software Personal (PSP) mostrará como producir de forma regular software de alta calidad. Utilizando el PSP obtendrás datos que muestren la efectividad de tu trabajo e identifique tus puntos fuertes y tus debilidades, además estarás practicando las habilidades y métodos que ingenieros del software han desarrollado durante muchos años de pruebas y errores.
El proceso de software personal fue diseñado para ayudar a los ingenieros del software a hacer bien su trabajo. Muestra como aplicar métodos avanzados de ingeniería a sus tareas diarias. Proporciona métodos detallados de planificación y estimación, que muestra a los ingenieros como controlar su rendimiento frente a sus planes y explica como los procesos definidos guían su trabajo.
Estos métodos de planificación y estimación también serán valiosos en el trabajo del programador puesto que forma parte, y como todas, importante, dentro del proceso de software. Además, puede mejorar el rendimiento del programador si se logra una buena planificación por parte de este.
La disciplina del PSP proporciona un marco de trabajo estructurado para desarrollar las habilidades personales. En otros campos, los profesionales demuestran su competencia básica antes de que se le permita desarrollar el trabajo más simple, mientras que en el software, los ingenieros sin entrenamiento en el PSP deben aprender las habilidades que se necesitan en el trabajo, esto no solo es costoso y consume tiempo, sino que aumenta el riesgo. Algo similar ocurre con los programadores.
Ingeniero del Software:
Disciplina relacionada con el desarrollo de software. Un producto de software es el conjunto completo de programas informáticos, procedimientos, documentación y datos especificados para su suministro a un cliente; el desarrollo se ocupa de todas las actividades técnicas y de gestión necesaria para crear el producto, y realizar el desarrollo eficazmente significa cumplir las necesidades del cliente ajustándose a unos límites de tiempo, coste y calidad.
El concepto de ingeniería de software surgió en unas reuniones de trabajo organizadas por la Organización del Tratado del Atlántico Norte (OTAN) en 1968 y 1969 para estudiar lo que entonces se describía como "la crisis del software". Había demasiados proyectos de desarrollo de soporte lógico que experimentaban fallos, los cuales se atribuían al rápido aumento en la escala y complejidad del software en cuestión. Se reconoció que era necesario un planteamiento más sistemático en el desarrollo de software, que debía basarse en principios de ingeniería ya establecidos.
El software evoluciona a través de muchas versiones, a medida que se corrigen errores, se mejora el funcionamiento y se responde a las modificaciones que surgen en los requisitos. Cada nueva versión se crea a través de un proceso de desarrollo de software. Típicamente, el proceso se divide en cuatro fases principales:
Análisis y especificación de requisitos: Donde se establece qué debe lograr el producto de software.
Diseño: Determina cómo cumplirá el software esos requisitos.
Puesta en práctica: Crea el producto de software que se ha diseñado (esto combina el desarrollo de nuevos componentes con la reutilización o modificación de componentes anteriores).
Prueba: Garantiza que el producto de software funciona como se pretende.
Los productos intermedios, como las especificaciones de requisitos y los diseños de software, también se revisan en profundidad antes de pasar a la siguiente fase de desarrollo.
El software no siempre se ha desarrollado de forma controlada, y en la actualidad hay algunos sistemas que presentan grandes dificultades para su mantenimiento. El organismo de normalización ISO (International Standards Organization) ha definido los requisitos de un sistema de gestión de calidad de carácter general que cubre el desarrollo de cualquier producto (ISO 9001) y ha publicado directrices específicas para aplicar esa norma al desarrollo de software (ISO 9000-3). Una organización que ponga en práctica un sistema de gestión de calidad según esa norma puede ser auditada y recibir una certificación formal de su proceso de desarrollo.
Los ingenieros informáticos están implicados en un gran número de áreas de aplicación, que cada vez son más. Algunos ejemplos son la realización de transacciones rápidas de valores en el mercado bursátil, el almacenamiento, intercambio y presentación de información en Internet, los videojuegos, la mejora de imágenes obtenidas por telescopios y el control de marcapasos cardiacos. En todos los casos, los principios de la ingeniería de software ayudan a garantizar que los sistemas resultantes son fiables y funcionan del modo requerido.
El trabajo de un ingeniero del software es entregar productos software de alta calidad a unos costes establecidos y en un plazo determinado. Después de años de dolorosas experiencias, muchos especialistas de la rama del software han aprendido que para hacer un trabajo efectivo necesitan:
Planificar su trabajo.
Hacer su trabajo de acuerdo con el plan.
Esforzarse en producir productos de máxima calidad.
Gráfico para mejorar la calidad de un software:
La gestión del tiempo:
A continuación se presentan una serie de fundamentos que las personas conocen de forma no conciente puesto que diariamente realizan una serie de procesos que automatizarían su trabajo.
Los fundamentos para gestionar el tiempo son:
Probablemente harás esta semana lo mismo que hiciste la semana pasada. En general la forma en que utilizaste tu tiempo la semana anterior es una buena aproximación a la forma en que gastarás tu tiempo en futuras semanas, aunque debes tener en cuenta que hay excepciones, semanas de exámenes por ejemplo. (A esta probabilidad comúnmente se le conoce como rutina y las excepciones son cambios en la rutina).
Para hacer un plan realista, tienes que controlar tu forma de gastar tu tiempo. Aunque recuerdes como gastaste tu tiempo la última semana, te sorprenderías de tus datos reales; con frecuencia el tiempo que empleas en un determinado trabajo es diferente al que esperabas. Por lo tanto para saber cómo utilizar tu tiempo necesitas tener registros exactos del mismo. (Realmente uno no acostumbra medir cuánto tiempo demora en tomar una ducha, o en realizar un ejercicio de matemáticas de baja, mediana o alta complejidad. Se tienen en cuenta otros tiempos como el tiempo que demoramos en caminar de la casa a la casa de la novia o novio o el tiempo que demora una guagua en su recorrido. Incluso estos tiempos pueden verse afectados por otros elementos como encontrarse con un conocido en el trayecto, o que exista más o menos personal en el recorrido de la guagua).
Para comprobar la exactitud de tus estimaciones de tiempo y planes, debes documentarlas y posteriormente compararlas con las que realmente haces. La planificación es una cualidad que pocas personas han aprendido; el primer paso para aprender a hacer buenos planes, es hacer planes. Así que, escribe un plan para que posteriormente tengas con que comparar tus datos actuales. (Es ideal planificar el día y ponerse objetivos a cumplir en las próximas 24 horas, por ejemplo. Al final de la jornada se tiene escrito que se pudo y que no se pudo realizar y las posibles alteraciones que condujeron a esta situación.)
Para hacer más precisos tus planes, determina las equivocaciones de los planes anteriores, y qué podrías haber hecho para mejorar. Cuando hagas el trabajo planificado registra el tiempo que utilizas. Cuando tengas copias documentadas de tus planes y hayas registrado a que has dedicado tu tiempo puedes comparar y ver donde estaba equivocado el plan y como puede ser mejorado el proceso.
Para gestionar tu tiempo, planifica tu tiempo y sigue el plan. Determinar qué podrías hacer para producir mejores planes es la parte más fácil. Llevarlo a cabo es lo realmente difícil; sobran los ejemplos de resoluciones que nunca se llevan a cabo como dejar de fumar, practicar ejercicios o seguir una dieta.
Aprender a establecer planes es importante, pero aprender a seguir estos planes es absolutamente crucial.
El control del tiempo:
Después de lo estudiado anteriormente queda preguntar: ¿Comprende como utilizas tu tiempo?
Para practicar la gestión del tiempo, lo primero que se debe hacer es comprender como gastas tu tiempo, para esto:
Clasifica tus principales actividades: Cuando comiences a controlar tu tiempo probablemente encontrarás que gran parte del mismo lo dedicas relativamente a pocas actividades, de 3 a 5 categorías deberán ser suficientes para controlar tu tiempo. Ejemplo: Importantes, priorizadas, normal.
Registra el tiempo dedicado a cada una de las actividades principales: Se necesita de bastante disciplina personal para registrar el tiempo de forma consistente. Al principio puede que lo olvides con frecuencia por tanto debes esforzarte para ganar la práctica necesaria para que sea natural en ti.
Registra el tiempo de forma normalizada: Normalizar los registros de tiempo es necesario porque el volumen de datos aumentará rápidamente. Si no registras y almacenas cuidadosamente estos datos se perderán o estarán desorganizados y en tal caso no te serán útiles.
Guarda los tiempos en un lugar adecuado: Puesto que con frecuencia necesitarás los datos almacenados, es conveniente tenerlos en un lugar adecuado.
El cuaderno de ingeniería:
Se propone utilizar un cuaderno de ingeniería para guardar los registros de tiempo y así controlar cómo gastas tu tiempo. El diseño particular del cuaderno no es clave, pero la práctica general indica que se debe etiquetar el cuaderno con un número de cuaderno, también con tu nombre y numero de teléfono o dirección de correo; debe tener la fecha de inicio de introducción de los datos y cuando lo hayas terminado escribir la fecha del último registro. Se propone además numerar cada página y utilizar las dos primeras para una breve tabla de contenidos.
El cuaderno esta estructurado generalmente por una Portada de cuaderno de ingeniería (Anexo 1), una Página de contenido del cuaderno (Anexo 2) y las Páginas del cuaderno de ingeniería (Anexo 3) en dependencia de la magnitud del proyecto.
El control del tiempo:
La forma de mejorar la calidad de tu trabajo comienza por entender lo que haces realmente, el primer paso en este proceso es definir las tareas y averiguar cuanto tiempo gastas en cada una de ellas. Es mucho más fácil controlar la cantidad de tiempo que dedicas a cualquier proyecto que incrementar tu productividad. Si no sabes como utilizas realmente tu tiempo, no serás capaz de gestionar la forma de utilizarlo.
Cuando registres el tiempo recuerda que el objetivo es obtener datos de como trabajas realmente. Para empezar utiliza los métodos descritos aquí, después de haber intentado utilizar estos métodos, tienes libertad para adaptarlo a tu manera de trabajar. No importa el formulario que uses, pero, si quieres gestionar tu tiempo debes controlarlo continuamente.
Cuando las personas hablan sobre lo que hacen, a menudo utilizan las horas como medida, pero esto a veces no es muy útil; puesto que la cantidad típica de tiempo no interrumpido que los ingenieros dedican a sus tareas es generalmente inferior a una hora, medir el trabajo en unidades de horas no proporcionara el detalle necesario para posteriormente planificar y gestionar tu trabajo. Una vez que has decidido controlar tu tiempo, es más fácil controlarlo en minutos que en horas.
Para registrar los tiempos que realmente dedicamos a cada tarea utilizaremos la tabla de registros de tiempo (Anexo 4). En la parte superior de la tabla, llamada cabecera tiene unos espacios para poner tu nombre y el nombre o número de clase. Las columnas del cuerpo de la tabla son para registrar los datos de tiempo. Cada periodo de tiempo se introduce en una línea de la siguiente forma:
Fecha: La fecha de realización de alguna actividad como asistir a clases o escribir un programa
Comienzo: La hora de comienzo de la actividad.
Fin: La hora a la que terminas la actividad.
Interrupción: Cualquier pérdida de tiempo debido a interrupciones.
? tiempo: El tiempo dedicado a cada actividad en minutos (tiempo final menos tiempo inicial menos tiempo de interrupciones).
Actividad: Nombre descriptivo de la actividad.
Comentarios: Una descripción más completa.
Completados: Rellena esta columna cuando hayas completado la actividad.
Unidades: El numero de unidades de la tarea acabada.
Control de interrupciones: Un problema común con el control del tiempo son las interrupciones, puesto que el tiempo de las interrupciones no es tiempo de trabajo productivo, debes controlar las interrupciones, el cuaderno de registros de tiempo te ayuda a esto.
Control de tareas finalizadas: Para controlar como gastas tu tiempo, necesitas controlar los resultados producidos, nuevamente el cuaderno de registros de tiempo te ayuda a identificar rápidamente el tiempo dedicado a las distintas tareas y lo que has hecho.
El cuaderno de ingeniería resulta un lugar adecuado para guardar el cuaderno de registros de tiempo.
Planificación de periodos y productos
Existen dos clases de planificación; la primera esta basada en un periodo de tiempo que puede ser cualquier intervalo del calendario: un día, una semana, un mes, o un año. Un plan del periodo hace referencia a la forma de planificar la utilización del tiempo por ese periodo. La segunda clase esta en la actividad, como desarrollar un programa o escribir un informe. Los productos pueden ser tangibles como programas o informes, o intangibles como el conocimiento que adquieres al leer un libro o el servicio que proporciona cuando trabajas en una oficina.
Todos nosotros utilizamos planes de periodos y proyectos en nuestra vida diaria, y aunque están muy relacionados son diferentes, por ejemplo, comemos, dormimos y trabajamos en ciertos periodos de tiempo del día o la semana, y nuestros gastos e ingresos también están gobernados por planes semanales, mensuales o anuales; no podemos hacer un plan de uno de ellos sin planificar también el otro. Las dos están relacionadas como se puede observar en el plan de periodo y producto (Anexo 5) que se ejemplifica.
El resumen semanal de actividades:
Para hacer un plan del periodo, es importante entender como gastas tu tiempo. El primer paso es registrar tu tiempo utilizando el cuaderno de registros de tiempos. Puesto que los registros de tiempos son muy detallados para el propósito de planificación, necesitas resumir los datos de una forma más útil. El resumen semanal de actividades (Anexo 6) muestra los formatos de tiempo que son más adecuados para la planificación del periodo.
Anota tu nombre y la fecha.
Anota las categorías de las actividades como cabecera de las columnas.
Para cada día suma todos los minutos para cada actividad de los registros de tiempo y anota los resultados en la columna correspondiente.
Después de completar todas las casillas para cada día, se obtiene el total para cada día en la columna total.
De igual manera se obtiene el total por actividades.
Rellena los datos referentes a los resúmenes utilizando los datos de semanas anteriores y calculando en cada caso promedio máximo y mínimo; en un caso sin incluir la última semana y luego incluyéndola.
Los datos en el resumen semanal de actividades te ayudarán a entender como gastas tu tiempo, puedes utilizar estos datos para planificar las semanas subsiguientes. Aunque al principio aprenderás mucho del resumen semanal, pronto suministrara poca información cada semana, cuando llegues a este punto puedes largar los periodos de resumen.
La planificación del producto:
La planificación es una parte crítica del trabajo de un ingeniero del software y por lo tanto tienes que saber como hacerla. El plan del producto te ayudará a decidir cuánto tiempo necesitas para hacer tu trabajo y cuando lo acabarás. Los planes también ayudan a controlar el progreso mientras se esta haciendo el trabajo. Los ingenieros utilizan los planes del producto para entender el estado de su proyecto. Con planes razonablemente detallados y precisos pueden juzgar donde se encuentra el proyecto frente al plan.
El primer paso para hacer un plan del producto es tener una definición clara del producto que quieres producir. Un adecuado plan del producto requiere tres cosas:
El tamaño y las características más importantes del producto a realizar.
Una estimación del tiempo requerido para hacer el trabajo.
Una previsión de la planificación.
El producto podría ser un programa ejecutable, un diseño de un programa o un plan de pruebas. Un plan del producto identifica el producto a hacer y contiene estimaciones del tamaño del producto, las horas de trabajo a realizar y la programación. Productos más complejos requieren una planificación más sofisticada y más tipo de información, tales como asignación de responsabilidad, planes de personal, especificaciones de procesos o productos, dependencias con otros grupos, pruebas especiales y cuestiones de calidad. Por lo que se hace importante hacer una planificación del producto que se adecue a la magnitud y complejidad del trabajo a realizar.
Antes de continuar es necesario definir algunos términos que emplearemos en lo adelante:
Un producto es algo que produces para una asignatura, una empresa o un cliente determinado.
Un proyecto generalmente concluye con un producto.
Una tarea se define como un elemento de trabajo.
Los planes describen la forma en que un proyecto concreto va a ser hecho: Cómo, cuándo y qué coste tendrá. También puedes planificar tareas individuales.
Un trabajo es lo que haces, tanto un proyecto como una tarea en específico.
El cuaderno de trabajo:
El cuaderno de trabajos (Anexo 7) es un documento de planificación del producto, este trata datos del producto mientras que el registro de tiempos y el resumen semanal contienen datos de planificación de periodos. La ventaja principal del cuaderno de trabajos es que proporciona una forma concisa de registrar y acceder a una gran cantidad de datos históricos de proyectos.
Trabajo (Tr): Cuando estés planificando una actividad asígnale un número de trabajo empezando por el 1.
Fecha: Fecha de comienzo del trabajo.
Proceso (P): Escribe el tipo de tarea.
Tiempo (T) estimado: Calcula el tiempo que crees que vas a demorar.
Unidades (U) estimadas: Para las unidades elementales escribe un 1. Luego esto cambiará al introducir las medidas de tamaño.
Tiempo (T) real: Al terminar el trabajo anota el tiempo que le has dedicado
Unidades (U) reales: Registra las unidades reales al terminar el trabajo
Velocidad (V) real: La velocidad es el tiempo divido por las unidades.
Tiempo (T) hasta la fecha: Al acabar el trabajo calcula y anota el tiempo empleado hasta la fecha para todas las tareas del mismo proceso.
Unidades (U) hasta la fecha: Anota las unidades para todas las tareas del mismo tipo realizadas hasta la fecha.
Velocidad (V) hasta la fecha: La velocidad es el tiempo divido por las unidades.
Máximo hasta la fecha: Calcula el máximo entre las velocidades reales de las tareas de cada tipo.
Mínimo hasta la fecha: Calcula el mínimo entre las velocidades reales de las tareas de cada tipo.
La clave para una buena estimación es aprender a hacer estimaciones equilibradas, la ventaja de hacer estimaciones equilibradas es que en promedio tus trabajos durarán aproximadamente lo que hayas estimado.
El tamaño del producto:
La planificación del producto no es un proceso exacto, esta es una habilidad que se puede desarrollar y mejorar. Para eso comienza con datos de trabajos parecidos y compara la nueva tarea con los trabajos anteriores. Busca trabajos previos que hayas hecho del mismo tamaño y planificación entonces basándote en el tamaño de los trabajos que anteriormente hayas realizado, estima el tamaño del nuevo trabajo a realizar.
Puesto que las tareas, a menudo, varían considerablemente de tamaño y complejidad, sería útil tener una forma de comparar sus tamaños. Cuando estés estimando el tiempo requerido para codificar un programa, basa las estimaciones en los tiempos que anteriormente has dedicado a codificar programas parecidos. La medida que utilizamos para el tamaño del programa, es la línea de texto del programa fuente (LOC: Lines Of Code); para asegurar que los tamaños analizados sean coherentes, debes adoptar una forma estándar de codificar los programas. Debes revisar la media de minutos por LOC y basar las estimaciones en las medias más recientes (últimos 5-10 programas), puesto que tus tiempos en minutos por LOC cambiarán bastante con la experiencia.
Aunque utilizar las medidas de tamaño parece bastante sencillo, hay que tener en cuenta algunas cosas, pues la productividad de distintas clases de trabajo, serán bastantes diferentes. Para tratar estas cuestiones, deberías guardar de forma separada los registros de tamaño y tiempo para las distintas clases de trabajo que haces.
La estimación del tamaño del producto.
Aunque ahora pareciera que puedes estimar el tiempo de codificar un programa, no es tan sencillo.
Para codificar programas, sin embargo, no es posible una contabilización de los mismos hasta que no los has desarrollado.
Existen varios métodos para estimar los tamaños de los programas antes de desarrollarlo para estimar los tamaños de los programas primero, examina los requisitos para los programas a desarrollar. Después, clasifica los tamaños relativos de los nuevos programas entre los programas que has escrito ya. Finalmente basándote en tu experiencia, estima sus LOC. Un ejemplo de este procedimiento se puede observar en el formulario para la estimación del producto (Anexo 8). Este formulario no es más que una lista de programas desarrollados por el estudiante y clasificados por tamaños. La lista muestra el tamaño del programa en LOC, el tiempo de desarrollo en minutos, las velocidades en minutos/LOC y una breve descripción de la función del programa. Examinado dichos datos en tu programa, y considerando que sabes bastante sobre lo que vas a codificar, puedes juzgar donde se ubicara este programa en la lista de tamaños.
La gestión de los compromisos:
Estar comprometido, es un estado mental. Por cualquier razón, te has comprometido a hacer algo, y sientes que deberías hacerlo. Un compromiso, sin embargo, es algo más que hacer lo que desees hacer, hay algo que alguien quiere que hagas. En efecto, esta es la cuestión clave en los compromisos: ¿Quién es la persona con quien te has comprometido? En sentido legal o contractual, estás comprometido con alguien: Tu profesor, tu director, o tu jefe, pero más importante, sin embargo, son los compromisos íntimos que hagas contigo mismo.
El principal problema con muchas programaciones y planes de software, es que la dirección los ve como compromisos contractuales, pero los ingenieros no lo ve como un compromiso personal. La diferencia como veremos esta en gran parte en como se hacen los compromisos.
Con un compromiso contractual una o más personas deben ponerse de acuerdo antes sobre la acción a realizar, por ejemplo tu compromiso con el profesor de hacer el ejercicio asignado. Otro ejemplo, podría ser tu contrato de escribir un programa para un cliente.
Cuando te comprometes, te pones de acuerdo para realizar una tarea específica en un tiempo determinado y por una recompensa o compensación. Esto indica que hay dos elementos adicionales en los compromisos. Además de comprometerte en la tarea, las partes también se ponen de acuerdo sobre el tiempo en que va a ser hecha y el pago u otra retribución que recibirá. Un ejemplo podría ser la obligación del cliente de pagarte por desarrollo e instalación de algún software.
Una característica de los compromisos personales es que son voluntarios. Supongamos, por ejemplo, que ti cliente necesite el programa antes y te dice que lo acabes dos semanas antes de lo inicialmente establecido. Él, nunca pregunto si podías realizar la proeza, y tú, por tu parte, no te comprometiste. Aunque pudieses con el compromiso, probablemente, no querrás sentirte personalmente comprometido a hacerlo.
 Página anterior | Volver al principio del trabajo | Página siguiente  |