4.2. Propuesta Metodológica para Proyectos de Desarrollo de Software
4.2.2 Formulación del proyecto
Los proyectos que se formulen en un área de Tecnología deben estar en perfecta alineación con la estrategia del negocio, en armonía con los objetivos planteados en el Plan Estratégico de la organización y en concordancia con la legislación que regule las actividades de la empresa.
Una vez corroborado que el proyecto responde al logro de la estrategia organizacional y se encuentra de acuerdo a la legislación propia de sus funciones, se debe iniciar declarándolo de manera formal y dimensionando las características y especificaciones que debe cumplir el producto de software que se desarrollará; así como también, todo el trabajo que debe ser realizado para alcanzar el objetivo formulado.
De esta manera, la fase de formulación del proyecto se compone de las siguientes sub fases:
a) Identificación
b) Alcance
b.1 Estudio de viabilidad
b.2 Definición de requerimientos
Figura Nº 5. Fase de Formulación de Proyectos INICIO Identificación Alcance Definir requerimientos Estudiar viabilidad
a) Identificación del proyecto
Especificar la necesidad, oportunidad o idea del proyecto, qué es lo que se espera obtener, el objetivo a lograr, el impacto que generará y los entes organizacionales externos e internos que estarán involucrados en el mismo.
En una organización esta iniciativa debe ser realizada por el área del Negocio para ser trasladada al Área de Desarrollo de Software. Para tales efectos, se completa el formulario “FOR-01 Identificación del proyecto” (ver sección 4.2.6 de formularios) con todos los datos que se solicitan.
Es importante indicar que este documento con su aprobación obtiene un carácter de formalidad en el proyecto, porque le permite al área de Negocios solicitar sus requerimientos para poder responder a los objetivos institucionales planteados en el Plan Estratégico. Es por tal razón que la formulación de proyectos se convierte en una pieza fundamental para que la organización permanezca competitivamente en el mercado y apostar por estrategias exitosas que consientan en el logro de las metas.
El representante del Área de Desarrollo de Software recibe el documento de Identificación del proyecto y se debe reunir con el Patrocinador y con el Líder por parte del área que solicitó el proyecto, junto con el especialista técnico del producto de software. A partir de este momento estas personas conformarán el “Comité Ejecutivo del Proyecto”, cuyo papel principal es la toma de decisiones alrededor del mismo y cada reunión que se efectúe debe quedar documentada en el formulario FOR-07 Minuta del Proyecto.
La reunión de inicio se realiza con el fin de revisar y analizar el documento “FOR-01 Identificación del proyecto” y resolver sobre el mismo, sometido a su consideración para ser aprobado, denegado o pospuesto.
Esta actividad de acordar un acuerdo en el inicio de un proyecto debe ser realizada de conformidad con la contribución que puede dar el proyecto al logro de las estrategias, al cumplimiento de regulaciones y de acuerdo con el presupuesto.
Si el acuerdo tomado es aprobar el proyecto se procede con las siguientes decisiones:
⇒ ⇒⇒
⇒ Asignar prioridad al proyecto.
⇒ ⇒⇒
⇒ Nombrar un Líder del proyecto por la parte del negocio.
⇒ ⇒⇒
⇒ Asignar Líder del área de Desarrollo de Software.
⇒ ⇒⇒
⇒ Autoriza que se proceda con la realización del Alcance del proyecto.
⇒ ⇒⇒
⇒ Valorar si es necesario un estudio de viabilidad.
En los casos donde se posponen proyectos, se debe archivar el documento de identificación y asignar la posible fecha de estudio y si es rechazado se justifican las razones de la decisión.
Las actividades que se debe llevar a cabo en la sub fase de Identificación se especifican en la siguiente figura:
Figura Nº 6. Actividades de la Identificación de Proyectos Sí Pospone Actor1 Solicitan Llena formulario FOR-01
Actor1Actor1Actor1
Reunión TI Envía Revisión y análisis de documento A Apprruueebbaa Rechaza Indica fecha posible y archiva Archiva previa justificación
Asigna Responsable y equipo de trabajo.
Asigna prioridad.
Autoriza inicio del alcance del proyecto.
Define si se requiere un estudio de viabilidad
b) Alcance del proyecto
Asegurar que se incluyan las especificaciones requeridas para satisfacer las necesidades, mediante la dimensión de las características y funcionalidades del producto de software a
desarrollar.
Mediante la definición del alcance se identifican las metas, objetivos y entregables que tiene la iniciativa del negocio.
En esta sub fase se deben considerar los siguientes elementos:
⇒ ⇒⇒
⇒ Una descripción (lo más detallada y precisa) de las características, funcionalidades, especificaciones y requisitos que debe poseer el producto de software.
⇒ ⇒⇒
⇒ Los límites del proyecto (lo que incluye y lo que no incluye), los criterios de aceptación y cualquier elemento que pueda afectar o restringir al proyecto.
⇒ ⇒⇒
⇒ Los objetivos del proyecto - beneficios.
⇒ ⇒⇒
⇒ La definición de los principales entregables y criterios de aceptación.
⇒ ⇒⇒
⇒ Estrategia (alinear a TI con el negocio).
Es primordial indicar que esta actividad es indispensable para esclarecer la necesidad de efectuar el proyecto y con un desarrollo adecuado se producirá un producto final satisfactorio, de lo contrario se corre el riesgo de generar insatisfacción, reprocesos y atrasos por la frecuente incorporación de cambios.
El entregable de esta actividad es el documento FOR-02 “Alcance del proyecto” (ver sección 4.2.6 de formularios) y deben participar los líderes tanto del Negocio como del Área de Desarrollo de Software. Una vez finalizado el documento de Alcance, el Director del Proyecto, procederá la realización del estudio de viabilidad (en los casos aprobados por la reunión de inicio) y se debe llevar a cabo la definición de los requerimientos, que permiten detallar las especificaciones por parte del usuario.
b.1) Estudio de viabilidad
Se refiere a la realización de un análisis más detallado del proyecto y debe realizarse si el documento de Identificación del Proyecto analizado en la reunión de inicio indica la necesidad de efectuarse Su propósito es obtener información técnica, operacional y económica, que permita evaluar el nuevo proyecto y emitir un criterio sobre su viabilidad.
El estudio de viabilidad se realiza mediante el registro del FOR-03 “Estudio de viabilidad”, y es efectuado por parte del Líder del Negocio que determina la viabilidad económica y operacional y el Líder del Área de Desarrollo de Software que especifica la viabilidad técnica del proyecto.
A continuación se describe qué debe contener cada una de las partes del estudio de viabilidad:
Viabilidad Técnica:
El objetivo es analizar las diferentes alternativas técnicas que existen para llevar acabo el proyecto, ya sea que se realice internamente o se contrate externamente. Debe contener lo siguiente:
⇒ ⇒⇒
⇒ Alternativas de solución, ventajas y desventajas
⇒ ⇒⇒
⇒ Recomendación mejor opción.
⇒ ⇒⇒
⇒ Responder la interrogante: ¿El proyecto puede realizarse con el equipo actual, la tecnología existente y el personal disponible?
⇒ ⇒⇒
⇒ Se debe evaluar los siguientes aspectos:
o Los recursos necesarios para que el proyecto brinde los resultados esperados.
o La posibilidad de adquirir nuevos equipos.
o La capacidad de los equipos actuales (si los hubiese).
o La garantía de exactitud, confiabilidad, facilidad de acceso y seguridad que proporciona el equipo actual (si existiera), o en su defecto, el equipo propuesto.
Viabilidad Operacional:
El objetivo es determinar si operacionalmente el producto a desarrollar podrá ponerse en operación eficazmente. Debemos respondernos las siguientes preguntas:
⇒ ⇒⇒
⇒ ¿Quién es la oficina responsable?,
⇒ ⇒⇒
⇒ ¿Existirá resistencia al cambio por parte de los usuarios?
⇒ ⇒⇒
⇒ ¿Cuáles son las implicaciones que se puedan presentar en otras áreas, por el nuevo producto?
⇒ ⇒⇒
⇒ ¿Cuales son las entradas o insumos (información) para el nuevo proyecto?
⇒ ⇒⇒
⇒ ¿Qué procesos involucra el nuevo proyecto?
Viabilidad Económica:
Un nuevo proyecto debe ser considerado por la organización como una buena inversión. Debemos responder las siguientes preguntas:
⇒ ⇒⇒
⇒ ¿Los beneficios que se obtienen serán suficientes para aceptar los costos?
⇒ ⇒⇒
⇒ ¿Los costos asociados con la decisión de no realizar el proyecto, son tan elevados que se debe rechazar el proyecto?
⇒ ⇒⇒
⇒ ¿Se cuenta con los recursos económicos para realizarlo?
Se deberán identificar claramente los siguientes aspectos:
⇒ ⇒⇒
⇒ El costo de la investigación del desarrollo del producto o servicio.
⇒ ⇒⇒
⇒ El costo del equipo y del desarrollo para el proyecto propuesto.
⇒ ⇒⇒
⇒ La disminución de errores que representan costos muy altos.
⇒ ⇒⇒
⇒ ⇒⇒
⇒ Los beneficios que se obtendrán.
Por lo tanto, será necesario estimar el retorno financiero que el proyecto otorga al ejecutarse mediante el uso de flujos de costos, ingresos o ahorros, para determinar la tasa interna de retorno.
Una vez finalizado el estudio de viabilidad se debe remitir al Director del Proyecto, quién con base al resultado del impacto decide remitirlo al Comité Ejecutivo del Proyecto, para que considere el impacto de acuerdo con su complejidad arquitectónica, tecnológica y de negocios. Dependiendo del criterio del Comité Ejecutivo se continua o no con el mismo.
Las actividades descritas para efectuar el estudio de viabilidad se esquematizan en la siguiente figura:
Figura Nº 7. Informe del Estudio de Viabilidad Análisis de impacto de la solución escogida en términos de: Operación Técnicos Económicos Impacto?
Produce reporte del estudio de viabilidad ALTO BAJO No produce reporte del estudio de viabilidad
b.2) Definición de Requerimientos
Se deben definir los requerimientos generales del proyecto de tal forma que se logre obtener un panorama más amplio de cuál es el producto que se desea desarrollar. Por tal razón, es necesario que el usuario desarrolle los requerimientos utilizando el estándar FOR-04 “Documento de Especificación de Requerimientos y Criterios de Aceptación”, abreviado DERCA.
Este documento deberá contener una descripción completa de las necesidades y funcionalidades del sistema que será desarrollado; describe el alcance del sistema y la forma en como hará sus funciones, definiendo los requerimientos funcionales y los no funcionales.
En el DERCA se definen todos los requerimientos de hardware (hw) y software (sw), diagramas, modelos de sistemas y cualquier otra información que sirva de soporte y guía para fases posteriores.
Es importante destacar que la especificación de requerimientos es el resultado final de las actividades de análisis y evaluación de los mismos; este documento resultante será utilizado como fuente básica de comunicación entre los clientes o usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la implementación del sistema.
Asimismo, es necesario indicar que en el CVDS como primera actividad se debe ejecutar la Definición de Requerimientos y las etapas siguientes del ciclo se desarrollan en la fase de Planificación y se ponen en práctica en la fase de Ejecución del proyecto:
Los clientes o usuarios utilizan el DERCA para comparar si lo que se está proponiendo, coincide con las necesidades de la organización. Los analistas y programadores la utilizan para determinar el producto que debe desarrollarse. El personal de pruebas elaborará las pruebas funcionales y de sistemas en base a este documento. Para el Director del Proyecto sirve como referencia y control de la evolución del sistema.
Una vez llevado a cabo el DERCA, se procede con la validación del mismo, por parte del usuario y el analista de sistemas. Esto permite demostrar que los requerimientos
definidos en el sistema son los que realmente quiere el usuario; además revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes.
Durante la actividad de validación pueden hacerse preguntas en base a cada una de las características que se desean revisar en los requerimientos, de la siguiente manera:
Cuadro Nº 2. Validación de las características de los requerimientos
Característica del DERCA Cuestionamiento
Completo ¿Están incluidas todas las funciones requeridas por el usuario?
Consistente ¿Existen conflictos en los requerimientos?
Sin ambigüedad ¿Tiene alguno de los requerimientos más de una interpretación?
Entendible ¿Está cada requerimiento claramente representado?
Factible ¿Pueden los requerimientos ser implementados con la tecnología y el presupuesto disponible?
Claridad ¿Está el DERCA escrito en un lenguaje apropiado?
Modificable ¿Existe facilidad para hacer cambios en los requerimientos?
Rastreable ¿Está claramente definido el origen de cada requisito?
Verificable ¿Pueden los requerimientos ser sometidos a medidas cuantitativas?
En caso de presentarse en la validación alguna inconsistencia se debe corregir el documento de especificación de requerimientos.
Una vez confirmada la validación, el Director de Proyectos debe remitir el documento FOR-02 Alcance del proyecto junto con el FOR-04 Documento de Especificación de Requerimientos y Criterios de Aceptación (DERCA) al Comité Ejecutivo del Proyecto, para que procedan con la revisión del mismo y si todos consienten se aprueba para continuar con la siguiente fase.
En la Figura Nº 8 se especifica el flujo del proceso para la etapa Formulación del proyecto.
Figura Nº 8. Flujo del Proceso de Formulación de Proyectos El área de negocio interesada completa el formulario FOR-01 El documento es revisado en reunión de inicio del proyecto (FOR-07 Minuta)
Tecnología convoca a reunión a Comité Ejecutivo
del proyecto Justifica y archiva ¿Se aprueba? El formulario FOR-01 Identificación del proyecto
es enviado al área de Tecnología
completa el FOR-02 Alcance del proyecto
Estudio viabilidad FOR-03 -Técnica (Analista) -Operacional (Usuario) -Económica (Usuario) Requiere estudio viabilidad
No Asigna Director y equipo Asigna prioridad. Define si se requiere un estudio de viabilidad Planificación Sí Sí No ¿Impacto? Produce reporte del
estudio de viabilidad para Comité Ejecutivo
No produce reporte del estudio de viabilidad Bajo Alto Deciden continuar? Justifica y archiva No Sí
Considerar las necesidades y expectativas de los
involucrados.
Definir los requerimientos generales del proyecto
FOR-04 DERCA
Se procede a validar los requerimientos definidos en el DERCA ¿Todo esta conforme? Sí No Corregir requerimientos definidos en el DERCA Aprobar alcance y requerimientos Reunión con el Comité Ejecutivo del Proyecto