1. No category

Facultad de Ciencias Naturales e Ingenierías
Tecnología en Desarrollo de Sistemas Informáticos
Planeación de Sistemas Informáticos
Página 1 de 5
TALLER
1.
2.
3.
4.
En grupos de tres personas.
Realice la Lectura la lectura que se encuentra a continuación.
Hagan una análisis de las actividades y discutan cuales consideran de mayor relevancia.
Seleccione 5 que ustedes consideren de mayor importancia y justifique su Respuesta.
10 actividades críticas a incluir en todo plan de desarrollo
de un software
Tomado de: http://www.pmoinformatica.com/2012/10/10-actividades-criticas-incluir-en-todo.html
En el mundo de la informática, los clientes e inclusive nuestros Gerentes y Directores, esperan que
cuando nos presenten un problema de ingeniería de software estemos en capacidad de responder
de inmediato ¿para qué fecha cree usted que podría estar desarrollado y entregado? Sin embargo,
debe tenerse extremo cuidado al proporcionar fechas, pues los desarrollos de software suelen
presentar muchos imponderables, que deben ser cuidadosamente analizados.
Una de las peores situaciones que se le pueden presentar a un analistas-programador de software,
arquitecto, líder de equipo o Gerente de proyecto, es darse cuenta en la mitad de la ejecución,
que actividades críticas no fueron consideradas cuando se planificó y comunicó una fecha de
entrega. En este artículo, se exploran una serie aspectos con frecuencia omitidos, pero que deben
considerarse en la planificación de todo desarrollo de software. Estos aspectos van desde los
tiempos para aprobaciones de los diseños, integraciones de códigos, instalación de ambientes de
prueba, entre otros.
Para ayudar a los analistas-programadores, líderes de grupo y Gerentes de Proyectos de Software
en esta tarea, presentamos a continuación las actividades críticas que no deben faltar en un plan
de desarrollo de software.
Introducción
La planificación toma tiempo de realizar, tratar de acelerarla es incrementar innecesariamente los
riesgos de proyectos de software, los cuales de por sí ya son de alto riesgo debido a los retos que
suelen enfrentar.
Ing. Karina Ramírez Duran [email protected]
Facultad de Ciencias Naturales e Ingenierías
Tecnología en Desarrollo de Sistemas Informáticos
Planeación de Sistemas Informáticos
Página 2 de 5
Las actividades que debe incluir un plan de desarrollo de un software son conocidas por la
comunidad informática, Análisis, Diseño, Desarrollo, Pruebas e Implementación. La secuencia en
que se ejecutan puede cambiar dependiendo del enfoque metodológico, si es predictivo,
iteraciones planeadas, o ágil. Estas actividades macro esconden aspectos críticos que deben ser
anticipados y gestionados para llevar a feliz término el proyecto.
Las actividades expuestas a continuación, deben ser consideradas en la planificación de tiempo o
(el cronograma) y de recursos del proyecto, es decir tiempo y esfuerzo de analistasprogramadores, analistas de pruebas u otros integrantes.
Actividades críticas a incluir en todo plan de proyecto de desarrollo de software
1.- Lapsos de correcciones y aprobación de los diseños de software:
Al recibirse un diseño del software, debe asumirse que presentará errores o dudas, por lo que es
necesario considerar tiempos para revisarlo, comunicar las correcciones, realizaras y volver a
revisar.
Adicionalmente, el diseño debe ser aprobado, lo cual puede suponer enviar un correo o
documento físico y buscar las firmas. Entre más larga sea la lista de involucrados, más puede
tardar la aprobación. Por supuesto, siempre se podrá comenzar a desarrollar para no retrasar el
proyecto, sin embargo, si se solicita algún cambio después podría implicar retrabajo.
2.- Instalación del ambiente de desarrollo
La instalación del ambiente de desarrollo para cada analista programador, así como de los
servidores de aplicación, base de datos o de otro tipo compartidos por el equipo es una actividad
predecesora obligatoria para comenzar el desarrollo.
Se puede realizar en paralelo con el análisis y diseño, sin embargo, debe tomarse en cuenta que
depende de recursos como equipos de computación y personal del área de tecnología e implica
configuraciones de aplicaciones, bases de datos y de otro tipo que pudieran tener incertidumbre
en su duración.
Adicionalmente, si es un desarrollo complejo con múltiples desarrolladores, podría implicar la
habilitación de un controlador de versiones, descarga de las últimas fuentes de código,
homologación de fuentes de código y bases de datos con el ambiente de producción.
Ing. Karina Ramírez Duran [email protected]
Facultad de Ciencias Naturales e Ingenierías
Tecnología en Desarrollo de Sistemas Informáticos
Planeación de Sistemas Informáticos
Página 3 de 5
3.- Dudas sobre los diseños que se presenten durante el desarrollo
No existe el diseño de software que sobreviva intacto la fase de desarrollo, siempre surgirán dudas
funcionales y técnicas, sobre las cuales será necesario hacer comunicaciones y esperar respuestas
de personas, las cuales, al no estar dedicadas al proyecto, pudieran ocasionar retraso. Por ende, se
debe asumir en la planificación que las dudas sobre el diseño se presentarán, asignando tiempo y
esfuerzo para su resolución.
4.- Integraciones de código de distintos desarrolladores
Durante el desarrollo, múltiples trabajos podrían estarse realizando en paralelo por distintos
analistas programadores en distintas capas (por ejemplo Bases de datos, aplicación y
presentación). Cada una de estas partes será probada, pero ¿Qué hay de la integración? y ¿no
debemos probar después de integrar?.
Deben contemplarse tiempos para integraciones de código y las pruebas de esa integración antes
de entregarlo al equipo de pruebas.
5.- Integraciones de código de otros proyectos
En el punto anterior abarcamos las integraciones de código de un mismo proyecto, pero, ¿qué
ocurre si tenemos varios proyectos en paralelo sobre un mismo sistema o aplicación?, o por
ejemplo si algún otro equipo de desarrollo realizó una implementación en producción durante la
ejecución de nuestro proyecto. Será necesario integrar con la última fuente de código y homologar
nuevamente los ambientes de bases de datos.
Asimismo, ¿qué ocurre cuando existen varios proyectos paralelos?, pues debe analizarse la hoja de
ruta del conjunto de proyectos, verificando la fecha de implementación en producción, decidiendo
en función de esto las integraciones a realizar, tomando en consideración que esto crea
dependencias entre proyectos.
6.- Instalación del ambiente de pruebas
El hecho que el producto desarrollado este empaquetado y entregado al equipo de pruebas no
significa que estas pueden comenzar, primero se necesita realizar la instalación o despliegue
(dependiendo de la tecnología en que se desarrolle) en el ambiente de pruebas.
Si se trata de un ambiente compartido en la organización, esto podría implicar solicitar tiempo al
administrador en horario no laborable, realizar la instalación, probar, corregir posibles errores de
despliegue, entre otras actividades. Por ende, es recomendable contemplar las mismas en la
planificación.
7.- Preparación de pruebas
Ing. Karina Ramírez Duran [email protected]
Facultad de Ciencias Naturales e Ingenierías
Tecnología en Desarrollo de Sistemas Informáticos
Planeación de Sistemas Informáticos
Página 4 de 5
¿Y qué hay de la preparación de las pruebas?, en cuanto al diseño de casos y recopilación de los
datos de prueba. ¿Qué ocurriría si esperamos a que el desarrollo esté entregado para comenzar a
hacer esto?, ¿no retrasaría esto el proyecto? Por ende, lo recomendable es contemplar la
actividad en la planificación y comenzar a ejecutarla en paralelo con el desarrollo, para que esté
terminada al momento de iniciar las pruebas.
8.- Correcciones de errores (bugs)
¿Podemos asumir que la ejecución de pruebas ocurrirá sin errores?, consideramos que no, de
hecho, la experiencia indica que algunos errores pueden ser difíciles de analizar y corregir, e
inclusive tardar más en ser remediados que la prueba en sí.
Debe considerarse en la planificación los tiempos y recursos (léase tiempo de los analistasprogramadores) para corregir estas incidencias. Usualmente, se pueden calcular como una
fracción o porcentaje de la ejecución de pruebas.
9.- Cambios de alcance
La teoría del desarrollo de sistemas y de la gerencia de proyectos nos dice que si ocurre un cambio
de alcance, el impacto del mismo debe ser considerado en tiempo y recursos, resultando en
muchos casos en un incremento del presupuesto y movimiento de la fecha, pero, ¿ocurre así en la
realidad?, ¿está dispuesto un cliente final a aprobarle un cambio en la fecha o presupuesto?, ¿Qué
ocurre si son muchos cambios de bajo esfuerzo?.
Usualmente este tipo de situaciones resultan en negociaciones con el cliente, en la cual se dicen
cosas como, ¿no se realizó una fase de análisis del proyecto?, ¿Por qué es un cambio de alcance,
no debió haber sido identificado en esa fase?, ¿No es el trabajo del Gerente de Proyectos el
prevenir estas situaciones?
En todo caso, los proyectos de desarrollo de software por su naturaleza intangible están sujetos a
tener cambios cuando el cliente los prueba, por ende, ¿Por qué no considerar dichos posibles
cambios en la planificación?, (por ejemplo como una holgura para ajustes y modificaciones).
Ing. Karina Ramírez Duran [email protected]
Facultad de Ciencias Naturales e Ingenierías
Tecnología en Desarrollo de Sistemas Informáticos
Planeación de Sistemas Informáticos
Página 5 de 5
Cabe destacar que los enfoques de desarrollo ágil atiende este tema de forma muy eficiente, al
incorporar la elaboración progresiva que permite al cliente realizar cambios a su producto de
software.
10.- Período de soporte posimplantación
¿El desarrollo del software termina con su puesta en producción?, ¿qué hay del llamado período
de estabilización de la solución?, ¿Quién atiende las dudas de los usuarios con el uso del
producto?, ¿Quién evalúa si se están reportando falsos errores?, o ¿Cómo se responde ante un
error real?.
En todo caso, y dado que el software por lo general se produce bajo períodos de garantía, es
necesario contemplar en la planificación la ocupación de analistas programadores y analistas de
pruebas, quienes brindarán soporte durante el período de estabilización. Durante este período, se
realizará la transferencia de conocimientos al equipo de soporte de la organización, hasta que esté
en capacidad de brindar dicho soporte y termine el período de garantía.
Conclusión
Las actividades que se han mencionado son con frecuencia omitidas en la planificación, sobre todo
cuando es preparada de forma apresurada y no se le da tiempo suficiente al desarrollador, al
equipo de trabajo y al Gerente de proyectos de analizar todas las premisas, ocasionando la no
identificación de todos los recursos y riesgos antes de presentar una fecha de entrega.
Ing. Karina Ramírez Duran [email protected]