Etapas en el desarrollo de un sistema informático

Enero 2014

Definición del alcance:

La primera fase de un proyecto típico es la definición del alcance. El propósito de la fase de definición de
alcance es de dos sentidos. Primero, responde la pregunta “¿vale la pena resolver este problema?”. Segundo y
suponiendo que el problema vale la pena, establece el tamaño y las fronteras del proyecto, la visión del
proyecto, cualquier restricción o limitación, los participantes requeridos del proyecto y finalmente, el
presupuesto y el programa.
Dado el problema inicial y la definición del alcance del proyecto, el analista puede conseguir el personal para
el equipo del proyecto, calcular el presupuesto para el desarrollo del sistema y preparar un programa para las
fases restantes. Finalmente, esta fase concluye con una decisión de seguir “adelante o detenerse” por parte de
los propietarios del sistema ya sea que estén de acuerdo con el alcance, presupuesto y programa propuesto
para el proyecto o bien deban reducir el alcance (para reducir costos y tiempo) o cancelar el proyecto.

El punto final y más importante es una declaración de trabajo. Una declaración de trabajo es un contrato o
acuerdo para desarrollar el sistema de información. Consolida la definición del problema, la definición del
alcance y el programa y el presupuesto para todas las partes que participaran en el proyecto.

Análisis del problema:

Siempre hay un sistema existente, sin importar si actualmente utiliza tecnología de la información. La fase del
análisis del problema estudia el sistema existente y analiza los resultados que proporciona al equipo del
proyecto con una comprensión más completa de los problemas que dispararon el proyecto. El analista con
frecuencia descubre nuevos problemas y responde la pregunta más importante, “¿los beneficios de solucionar
estos problemas exceden los costos de construir el sistema para resolver estos problemas?”.

Los objetivos para mejora de un sistema no definen entradas, salidas o procesos. En su lugar, definen el
criterio de negocios en el que cualquier sistema nuevo será evaluado. Por ejemplo, podríamos definir un
objetivo de mejoramiento de sistemas como cualquiera de los siguientes.

- Reducir el tiempo entre el proceso de pedidos y embarque en tres días.

- Reducir las pérdidas por mal crédito en 45 por ciento.

- Cumplir con nuevos requerimientos de calificación federal de ayuda financiera para una fecha exacta.
Cada sistema existente tiene su propia terminología, historia, cultura y detalles. Conocer esos aspectos del
sistema es un importante producto derivado de esta fase. De toda la información recopilada, el equipo del
proyecto obtiene una mejor comprensión de los problemas y oportunidades existentes del sistema. Luego de
revisar los resultados, los propietarios del sistema estarán de acuerdo o en desacuerdo con los objetivos de
mejoramiento del sistema recomendados.

En caso de que sea o no factible, el proyecto puede ser:

- Cancelado si se considera que no vale la pena resolver los problemas.

- Aprobado para continuar a la siguiente fase.

- Reducido o expandido en alcance (con modificaciones de presupuesto y programas) y luego aprobado

para continuar en la siguiente fase.

Análisis de requerimientos:

Aquí surgen nuevas preguntas “¿Qué capacidades debe proporcionar el nuevo sistema para sus
usuarios?”,¿Qué datos deben ser capturados y almacenados ? ¿Qué nivel de desempeño se espera?.

La fase de analisis de requerimientos define y prioriza los requerimientos del negocio. Dicho de manera
simple, el analista se aproxima a los usuarios para averiguar lo que necesitan o requieren del nuevo sistema,
al evitar cuidadosamente cualquier discusión de tecnologia o implantacion técnica.

Errores y omisiones en el analisis de requerimiento resultaran en la insastifacion del ususario con el sistema
final y modificaciones costosas. De nuevo, la definicion de requerimientos no especifica ninguna posibilidad
o solucion tecnica; pueder un documento pequeño como unas cuantas páginas o ser extenso con una pagina o
mas documentos por requerimiento.

Para producir una definición de requerimientos del negocio, el analista de sistemas trabaja muy de cerca con
los usuarios del sistema para identificar necesidades y prioridades. Esta informacion se recopila por medio de
entrevistas, cuestionarios y juntas. El desdio para el equipo es validar esos requerimientos. Los objetivos de
mejoras del sistema proporcionan la “clave de clasificacón” para requerimientos del negocio.

Siempre hay que tener en cuanta las necesidades del negocio, por eso los diseñadores y construcores de
sistemas dependen de analistas de sistemas competentes para trabajar con los usuarios, definir y documentar
requerimientos del negocio completos y precisos antes de aplicar cualquier tecnologia.

Diseño lógico:

La fase del diseño logico traduce los requerimientos del negocio a modelos de sistemas. El termino diseño
logico debe ser interpretado como “de tecnologia independiente”, lo que significa que las imágenes ilustran el
sistema en forma independiente de cualquier solucion tecnica posible, por tanto, modelan requerimientos del
negocio que deben ser satisfechos mediante cualquier solución técnica que quisíeramos considerar.
Análisis de decisión:

Dados los requerimientos de negocios y los modelos de sistema lógicos, normalmente hay diversas
alternativas para diseñar un nuevo sistema de información que satisfaga esos requerimientos. Algunas de las
preguntas pertinentes incluyen lo siguiente.

- ¿Qué tanto del sistema debe ser autorizado con tecnologia de información?

- ¿debemos comprar software o construirlo nosotros (llamado decision de comprar o desarrollar)?

- ¿Debemos diseñar el sistema para una red interna o debemos diseñar una solucion basada en la web?

- ¿Qué tecnologia de información (posiblemente en surgimiento) podrian ser utilies para esta aplicación?

Estas preguntas se responden en la fase de analisis de decision de la metodología. El propósito de esta fase es:

1 – identificar soluciones técnicas candidatas.

2 – analizar esas soluciones candidatas para evaluar su factibilidad

3 – recomendar un sistema candidato como la solución objeto para ser diseñada.

Luego de que las soluciones candidatas han sido identificadas, cada una se evalua con los siguientes criterios:

- Factibilidad técnica: ¿es la solución técnicamente practica? ¿Nuestro personal tiene la experiencia
técnica para diseñar y construir esa solución?

- Factibilidad operacional: ¿la solucion podrá satisfacer los requerimientos de los usuarios? ¿a qué grado?
¿Cómo cambiara la solución el ambiente de trabajo del usuario? ¿Cómo se sienten los usuarios acerca de
dicha solución?
- Factibilidad económica: ¿tiene la solución un costo aceptable?

- Factibilidad del programa: ¿puede la solución ser diseñada e implementada dentro de un periodo
aceptable?

- Factibilidad de riesgos: ¿Cuál es la probabilidad de una implantacion exitosa al utilizar la tecnología y su

enfoque?

El equipo de proyecto normalmente busca la solución mas factible, aquella que ofrece la mejor combinación
de factibilidad técnica, operacional, económica, de programa y de riesgo.

El punto de revision de factibilidad del comproomiso ajustado puede resultar en cualquiera de las siguientes
opciones:

- Aprobar y financiar la propuesta de sistema para el diseño y la construción.

- Aprobar o financiar una de las soluciones candidatas alternativas.

- Rechazar todas las soluciones candidatas y ya sea cancelar el proyecto o regresarlo para nuevas
recomendaciones.

- Aprovar una versión de alcance reducido de la solución propuesta.

Diseño físico e integración:

La fase de diseño se ocupa de los puntos de vista basados en la tecnología del sistema:

1 – especificaciones de diseño fisico de base de datos.

2 – el proceso físico de negocios y especificaciones de diseño de software.

3 – Especificaciones del usuario fisico e interfaz de sistemas.

Un proyecto rara vez se cancela despúes de la face de diseño a menos que este demaciado por encima de lo
presupuestado o retrasado en el programa.

Debe señalarse que en las metodologías modernas, existe una tendencia hacia la fusión de la fase de diseño
con nuestra siguiente fase, comnstrucción. En otras palabras, las fases de diseño y construcción normalmente
se traslapan.

Construcción y pruebas:

El propósito de la construccion y la fase de pruebas es doble:

1 – Construir y copiar un sistemas que satisfaga los requerimentos de negocios y las especificaciones de
diseño físico.

2 – Implantar las interfaces entre el nuevo sistema y los sistemas existentes. Dependiendo del tipo de sistema
que se está creando, el equipo del proyecto debe construir o instalar:

- Base de Datos: las bases de datos pueden incluir bases de datos de procesamiento de transacciones en
línea para respaldar las transacciones de negocios diarias, almacenes de datos operacionales para soportar los
informes, solicitudes diarias y almacenes de datos que soporten las necesidades de análisis de datos y de toma
de decisiones.

- Paquetes de software comerciales y/o software desarrollado a la medida: los paquetes se instalan y se
personalizan según sea necesario.

- Interfaz de usuario y de sistema: las interfaces de usuarios deben ser construidas y probadas para su
funcionalidad y estabilidad.

Uno de los aspectos más importantes de construcción es la realización de pruebas de componentes de sistema
individuales y el sistema en general. Una vez probado, un sistema está listo para la instalación y entrega.
Instalación y entrega:

Para proporcionar una transición suave hacia el nuevo sistema se debe preparar un plan de conversión. Este
plan debe requerir un cambio abrupto, donde se termina el sistema viejo y se reemplaza por el nuevo en una
fecha específica. En forma alternativa, el plan puede mantener ejecutándose los sistemas viejos y nuevos en
paralelo hasta que el nuevo sistema se considere aceptable para reemplazar el viejo.

La fase de instalación y entrega también incluye capacitar a los individuos que utilizarán el sistema final y
desarrollar documentación para ayudar a los usuarios de sistemas. La fase de implantación normalmente
incluye alguna forma de revisión posterior a la auditoria para calcular el éxito del proyecto de sistemas
terminado. Esta actividad promueve una mejora continua del proceso y una administración futura del
proyecto.

Operación del sistema y mantenimiento:

Una vez que el sistema este puesto en operación, requerirá de un soporte continuo para el resto de su vida útil
y productiva. El soporte de sistemas consiste en las siguientes actividades continuas:

- Ayuda a usuarios: eventualmente los usuarios requerirán ayuda adicional conforme surjan los problemas
no anticipados, se agreguen nuevos usuarios y demás.
- Arreglar los defectos de software: generalmente son errores que se pasaron por alto al momento de de
hacer las pruebas. Estos son inevitables, pero normalmente pueden ser resueltos, en la mayoría de los casos,
con el soporte de un experto.

- Recuperación del sistema: la pérdida de datos se puede dar por errores humanos o fallas en el hardware o
software. El analista de sistema o los especialistas de soporte técnico pueden ser llamados para recuperar el
sistema, es decir, restablecer los archivos y bases de datos del sistema y reiniciarlo.

- Adaptar el sistema a requerimientos nuevos: estos pueden ser nuevos problemas de negocios, nuevos
requerimientos de negocios, nuevos problemas técnicos o nuevos requerimientos de tecnología.

Eventualmente se espera que la retroalimentación del usuario y los problemas o las necesidades de negocios
cambiantes indiquen que es el momento de empezar de nuevo y de reinventar el sistema. En otras palabras, el
sistema ha llegado a una entropía y se debe iniciar un nuevo proyecto para crear un proceso de desarrollo de
sistema completamente nuevo.

Relaciones y dependencias entre las fases de diseño de un sistema.

Análisis Diseño
Inicio de del del Implantación
proyecto sistema sistema del sistema

Definición del
alcance X

X X
Análisis del
 problema

Análisis de
requerimientos X

Diseño lógico X

Análisis de
decisión (fase de transición de análisis de sistema)

Diseño físico e
integración X

Construcción
y pruebas X X

Instalación y
pruebas X

Publicado por REQUERIMIENTOS DE SOFTWARE en 19:14 No hay comentarios:

¿Qué son los requisitos y como se definen?

Los requerimientos son la descripción de una función o capacidad que debe cumplir un sistema.
Definen las características, funciones y finalidad que un software debe realizar, es decir, describen el
¿QUÉ? y el ¿COMO? de un proyecto y deben guiar a los diseñadores y desarrolladores durante todo el
proceso de creación del software.

La función de un analista de negocio consiste en recopilar los requerimientos en términos funcionales,

dejando el diseño, ejecución e implementación detallada a los desarrolladores. Por último, el jefe de
proyecto deberá asegurar que los cambios en los requerimientos son documentados y referenciados de
forma que a partir de ellos se pueda validar si los requerimientos han sido cumplidos.

Existen dos categorías principales de requerimientos de software: requerimientos funcionales y

requerimientos no funcionales.

 Los requerimientos funcionales describen las funciones que el sistema será capaz de realizar,
definiendo los cambios y modificaciones que el sistema realiza sobre las entradas para producir
salidas determinando la lógica de alto nivel. Estos requerimientos acabarán convirtiéndose en la
lógica y gran parte del código del sistema.
 Los requerimientos no funcionales establecen las restricciones del producto al ser
desarrollado. Es decir, definen las restricciones impuestas por el sistema, no por las necesidades del
negocio.