UNIVERSIDAD FRANCISCO DE PAULA SANTANDER F05

FACULTAD DE INGENIERIA
PROGRAMA DE INGENIERIA DE SISTEMAS
Lectura página

CICLO DE VIDA FRENTE A UN MODELO

Los términos ciclo de vida del sistema y modelos de desarrollo del sistema con frecuencia
son intercambios.

 Cuando un sistema evoluciona del desarrollo a la operación y al mantenimiento,

debe darse una conversión
 En algún punto en el tiempo, se vuelve obsoleto (o se vuelve inminente) y el ciclo
cambia de la operación y el mantenimiento al redesarrollo.

En realidad, un sistema puede estar en más de una etapa al mismo tiempo.

El modelo es el proceso estándar para construir y mantener ese sistema y todos los demás
sistemas de información a través de sus ciclos de vida.

PRINCIPIOS FUNDAMENTALES PARA EL DESARROLLO DE SISTEMAS

Principio 1: Hacer participar a los usuarios del sistema.

Piense en el desarrollo de sistemas como una sociedad absoluta ara el desarrollo de

sistemas exitosos.

Los analistas, diseñadores y constructores son responsables por el desarrollo del sistema,
deben hacer participar a sus propietarios y usuarios, insistir en su participación y buscar
un acuerdo por parte de todos los interesados en relación con las decisiones que puedan
afectarlos.

La mala comunicación y los malos entendidos continúan como un problema.

Principio 2. Utilizar un método de solución de problema.

1. estudiar y entender el problema, su contexto y su impacto

2. definir los requerimientos que deben satisfacer para alcanzar una solución
3. identificar alternativas de soluciones que satisfaga los requerimientos y elegir la mejor
solución
4. diseñar y/o implantar la solución elegida
5. observar y evaluar el impacto de la solución y depurarla
 UNIVERSIDAD FRANCISCO DE PAULA SANTANDER F05
FACULTAD DE INGENIERIA
PROGRAMA DE INGENIERIA DE SISTEMAS
Lectura página

El proceso de solución de problemas de una metodología, cuando se aplica

correctamente, puede reducir o eliminar riesgos.

Principio 3. Establecer fases y actividades

Todos los modelos de desarrollo tienen fases y actividades. El numero y alcance de ambas
varían de autor en autor, de experto en experto, de modelo en modelo y de empresa a
empresa.

Las fases son:

 definición del alcance

 análisis del problema
 análisis de requerimientos
 diseño lógico
 análisis de decisión
 diseño físico e integración
 construcción y pruebas
 instalación y entrega

estas fases no son absolutamente secuenciales, tienden a traslapases entre ellas. Estas
pueden ser personalizadas para las necesidades de un proyecto dado (eje. Vencimientos,
complejidad, estrategia, recursos, entre otros aspectos).

Principio 4. Documentar a través del desarrollo.

La documentación mejora las comunicaciones y la aceptación. La documentación revela la

fortaleza y debilidades del sistema para los múltiples interesados. Estimula la participación
de los usuarios y reasegura la administración acerca del progreso.

Principio 5. Establecer estándares.

Todos los sistemas de información en el mundo perfecto deberían estar integrados de tal
forma que se comportan como un solo sistema. Desafortunadamente nunca sucede esto
debido a que los SI son desarrollados y remplazados durante un largo periodo.

La integración de los Sistemas generalmente se ha vuelto crítica para el éxito de los SI de

cualquier organización.
 UNIVERSIDAD FRANCISCO DE PAULA SANTANDER F05
FACULTAD DE INGENIERIA
PROGRAMA DE INGENIERIA DE SISTEMAS
Lectura página

Para lograr la integración, las organizaciones se apegan a estándares. En muchos casos,

éstos toman forma de arquitectura tecnológica de información empresarial. Una
arquitectura TI establece estándares que sirven para dirigir soluciones de tecnologías y si
hacia una visión o configuración de la tecnología común.

Tecnología de bases de datos. . Que motores de BD se utilizarán (Oracle, IBM, DB2,

SQL Server de Microsoft)? ¿en que plataformas se operaran (UNIX, Linux,
Windows, XP, MVS) ¿ que tecnologías se utilizaran para cargar en las bases de
datos de procesamiento de transacciones en línea (OLTP), almacenes de datos
operacionales y almacenes de datos ( extract Transform y Load (RTL)?

Tecnologías de software. ¿Qué ambientes/lenguajes de desarrollo de aplicaciones

serían utilizados para escribir software (websphere de IBM con Java, Visual Studios.
NET de Microsoft con Visual Basic . NET, Visual C++ o Visual C++, Powerbuider de
Sybase, oracle Forms de Oracle)’

Tecnología de interfaz. ¿Cómo serán desarrolladas las interfaces de usuario, con

componentes de MS Windows o lenguajes Web y componentes (ej., un editor
xhtml como dreamweawe de Macromedia, un motor de portal como el websphere
de IBM)?¿cómo se intercambiaran los datos entre los distintos Si (ej. Un corredor
de datos como MQ Messaging de IBM, un intercambio de datos basado en XML o
una interfaz programada personalizada)?

En ausencia de una arquitectura TI, cada SI y aplicación puede ser construido con
tecnologías radicalmente diferentes.

Principio 6. Administrar el proceso del proyecto

Asegura que el proceso o administración elegidos por la organización se utilice en forma

consistente en todos los proyectos. La administración del proyecto asegura que el SI se a
desarrollado a un costo mínimo, dentro de un marco de tiempo especifico y con una
calidad aceptable.

Principio 7. Justificar Si como inversiones de capital.

Los Si son inversiones de capita, tal como una flota de camiones o un nuevo edificio. Los
propietarios del sistema se comprometen con esta inversión.

Al igual que la administración de proyectos y de proceso, el análisis de costo-beneficio se

realiza a lo largo del proceso de desarrollo del sistema,
 UNIVERSIDAD FRANCISCO DE PAULA SANTANDER F05
FACULTAD DE INGENIERIA
PROGRAMA DE INGENIERIA DE SISTEMAS
Lectura página

Como los SI son reconocidos como inversiones de capital, los proyectos de desarrollo de
sistemas a menudo son conducidos por la planeación empresarial. muchas unidades de
negocio de tecnología de información contemporánea crean y mantienen un Plan
estratégico de sistemas de información. Dicho plan identifica y prioriza los proyectos de
desarrollo de sí. De manera ideal, un plan de sistemas de información. Este plan
estratégico de sistemas es conducido por un plan estratégico de la empresa que define
una dirección para todo el negocio.

Principio 8. No tena cancelar o revisar el alcance.

Hay un dicho: “No tire dinero bueno tras el dinero malo”. En otras palabras, no tema
cancelar un proyecto o revisar un alcance, sin importar cuánto dinero se haya gastado
hasta el momento; recorte sus pérdidas.

En cada punto de revisión, el analista debe considerar las siguientes opciones:

 Cancelar el proyecto si ya no es factible

 Reevaluar y ajustar los costos y el programa su el alcance del proyecto se debe
incrementar
 Reducir el alcance su el presupuesto del proyecto y el programa están congelados y
no son suficientes para cubrir todos los objetivos del proyecto.

Principio 9. Divida y vencerá.

Dividimos el sistema en subsistemas y componentes con el fin de conquistar con mayor

facilidad el problema y construir un sistema mas grande. En el análisis de sistemas, a
menudo llamamos a esto dividir. Al dividir repetidamente un problema mas grande
(sistema) en piezas más manejables (subsistemas), el analista puede simplicar el proceso
de solución de problemas. Este método divide y vencer también complementar la
comunicación y la administración de proyectos al permitir que diferentes piezas del
sistema sean comunicadas a interesados distintos y mas apropiados.

Principio 10. Diseñar sistemas para crecimiento y cambio.

Los negocios cambian con el paso del tiempo. Sus necesidades cambian. Sus prioridades
cambian. En consecuencia, los Si que respaldan el negocio deben cambiar con el paso del
tiempo. Por esta razón, buenas metodologías deben abrazar la realidad del cambio.

Los sistemas deben se rediseñados para incorporar tanto los requerimientos de

crecimiento como de cambio. En otras palabras, los SI bien diseñados pueden escalar y
 UNIVERSIDAD FRANCISCO DE PAULA SANTANDER F05
FACULTAD DE INGENIERIA
PROGRAMA DE INGENIERIA DE SISTEMAS
Lectura página

adaptarse al negocio. pero sin importar que tan bien diseñemos los Sistemas para
crecimiento y cambio, siempre llegará el momento cuando simplemente ya no puedan
soportar el negocio.

Tomado de:

Whitten Bentley. Analisis de Sistemas Diseño y Métodos. Mc Graw Hill. 7 edicion 2008