Ciclo de vida de un sistema de información

EL CICLO DE VIDA DE UN SISTEMA
DE INFORMACIÓN

Presentado por
Castro Morales Yeison De Jesús
Chaves Avellaneda Carlos Daniel
Lozano Guerrero Adriana
Polentino Pinzón Zayra Jasmín

•¿Qué es lo primero
que debemos hacer
cuando construimos
nuestro sistema de
información?
1. ANALISIS DEL SISTEMA DE
INFORMACIÓN

1. ANALISIS DEL SISTEMA DE INFORMACIÓN
¡Saber en concreto lo que
necesita la entidad para la
cual construimos el
sistema!
El análisis nos sirve para
saber en concreto que
necesita o cuales son los
requerimientos de nuestro
cliente

¿Cómo hacer el análisis?
Lo más óptimo es partir de
las siguientes preguntas
¿Qué es lo que realmente
necesita la organización?
¿Qué quiere hacer el
sistema?

• El análisis es en gran
medida,
responsabilidad del
analista de sistemas,
ANALISTA DE SISTEMAS
Estudia a la
organización para
determinar sus
PROBLEMAS NECESIDADES REQUERIMIENTOS
Con esto, se
pueden combinar
Recursos Humanos
Procesos Datos
Tecnología de la
información
Logrando mejoras en la organización

•Para efectuar el análisis se deben determinar los
requerimientos del sistema, lo que implica que
el analista debe tener conocimiento en:
-Técnicas de elicitación de requerimientos.
-Herramientas de modelado de sistemas.
-Metodologías de análisis de requerimientos.

ELICITACIÓN DE
REQUERIMIENTOS
Descubrir
Explicitar
Elucidar
Encontrar
Requerimientos o
necesidades de la
organización
Elicitar ¿Cómo?
Entrevistas con el bloque de
personas, sobre todo con usuarios
y propietarios del sistema
Diseño de cuestionarios y encuestas
Experiencia y
participación
activa en los
procesos de la
organización

MODELADO DE
SISTEMAS
Elaboración de
modelos para
Comunicar la estructura del
sistema
Especificar el
comportamiento del sistema
Comprender el modelo
diseñado
Encontrar la manera de
simplificarlo
Los modelos
vendrían ser los
“planos” del
Sistema, es decir
representan lo
que se desea o
anhela que sea
el sistema

MODELADO DE
SISTEMAS
Tipos de
modelo
Estructural
Estructuras de datos que
conforman el sistema
Puede representarse por
medio de
Diagramas entidad-relación
Comportamiento
Modela la dinámica de
procesos de la organización
Puede representarse por
medio de
Diagramas de Estados

• METODOLOGÍAS DE ANÁLISIS DE
REQUERIMIENTOS
• Teniendo ya la información sobre
las necesidades de la organización,
debemos buscar mecanismos o
técnicas que nos permiten estudiar
y comprender cuales son las
necesidades de la organización,
con base en ellos podremos hacer
los modelos de nuestro sistema.

DISEÑO
 Es el proceso de describir, organizar y estructurar los componentes del sistema. Tanto a
nivel arquitectónico como a nivel detallado, con la intención de construir el sistema
propuesto.
 El diseño de mas alto novel es llamado: diseño general, arquitectónico o conceptual.
 También se le conoce como actividad de modelaje.
 La información modelada en la identificación de los requerimientos se convierten en
modelos que representan la solución.
2. DISEÑO

Estrategias de Diseño
 Declaración de alto nivel sobre el enfoque del SI a
desarrollar. Incluye la funcionalidad del sistema, el
hardware y la plataforma del software del sistema, y el
método para su adquisición o desarrollo.
 La selección de la mejor alternativa del diseño del sistema
incluye al menos dos pasos básicos:
a). Generación de un conjunto comprehensivo de
alternativas de estrategias de diseño.
b). Selección de la mejor alternativa para el SI deseado,
sobre la base de todas las
restricciones organizacionales, económicas y técnicas, que
limitan su desarrollo.
2. ESTRATEGIASDEDISEÑO

Proceso de Selección
1. Dividir los requerimientos en conjunto de capacidades, en un rango que vaya
de lo mas simple que los usuarios aceptarían (los requerimientos mínimos)
hasta lo mas elaborado y avanzado en sistemas que la compañía podría llegar
a desarrollar (incluye todas las características deseadas por todos los
usuarios). Alternativamente, combinaciones de diferentes conjuntos de
capacidades podrían representar la posición de aquellas unidades
organizacionales que tienen conflictos acerca de lo que el sistema debería
hacer.
2. Enumerar los diferentes ambientes de implementación (HW, SW, red) que
potencialmente podrían ser usados para cometer los diferentes conjuntos de
capacidades.
3. Proponer diferentes maneras de cometer y desarrollar varios conjuntos de
capacidades con los diferentes ambientes de implementación.
4. Los analistas pueden recomendar lo que ellos creen es la mejor alternativa,
pero el cuerpo gerencial (una combinación de un comité y de los encargados
de hacerle seguimiento al desarrollo del proyecto de sistema) tomarán la
última decisión sobre cual estrategia de diseño de sistemas seguir.
2. PROCESODESELECCIÓN

Proceso de Selección
5. Los documentos que deben surgir como resultado de la generación de
alternativas de diseño de sistemas y, la selección de la mejor estrategia,
son:
 Por lo menos tres (3) estrategias de diseño de sistemas
sustancialmente diferentes para la construcción del nuevo SI.
 La mejor estrategia de diseño para alcanzar el SI deseado.
 La línea base del Proyecto de planificación para convertir la mejor
estrategia de diseño en un SI en plena operación.
2. PROCESO DE SELECCIÓN

Estrategias de Diseño
¿Cómo saber los límites del posible espacio solución?.
El equipo de analistas ya tiene recolectada la información necesaria para identificar el espacio
solución. Pero primero debe organizar sistemáticamente la información. En este sentido, existen
dos (2) consideraciones:
• La primera se refiere a los requerimientos del nuevo sistema que son mandatorios; si alguno de
ellos es olvidado, hace que la estrategia no tenga sentido. Para comparar diferentes estrategias de
diseño, los requerimientos del sistema pueden ser divididos en tres categorías: mandatorios,
esenciales y deseados.
• Las segunda se refiere a las restricciones para el desarrollo del sistema, tales como: fechas de
entrega del sistema, disponibilidad de recursos humanos y financieros, elementos del sistema
actual que deben conservarse, restricciones legales y contractuales y, la importancia o dinámica del
problema, ya que puede limitar cómo adquirir el sistema (comprar vs. desarrollar). Tanto los
requerimientos como las restricciones deben ser identificados y clasificados en orden de
importancia.
2. ESTRATEGIAS DE DISEÑO

Puntos a Considerar
SELECCIÓN DE SOFTWARE OFF-THE-SHELF.
Cuando se piensa comprar un software off-the-shelf, hay que comparar el paquete de software y el proceso
de desarrollo de la misma aplicación en casa, según los siguientes criterios: costo, funcionalidad, soporte del
vendedor, viabilidad del vendedor, flexibilidad, documentación, tiempo de respuesta y facilidad de
instalación. Además, hay que recurrir a métodos cuantitativos cuando se comparan distintos paquetes de
software.
HARDWARE Y SOFTWARE.
Es necesario determinar si la plataforma de HW y SW existente en la organización soporta el nuevo sistema o
si es necesario realizar mejoras de HW y/o adquisición de SW (manejadores de bases de datos, lenguajes de
programación, sistemas operativos, SW de red, generadores de código, entre otros). Esto tiene que ser parte
esencial de las alternativas de estrategias de diseño.
IMPLEMENTACIÓN.
Es necesario tener en cuenta los aspectos técnicos y sociales de la implementación del nuevo SI como parte
de las alternativas de estrategias de diseño. Los gerentes y los usuarios deben conocer qué tiempo tomará a
implementación, qué entrenamiento se requerirá, cómo será el impacto en los procesos, qué nuevas
habilidades serán necesarias, qué tan “doloroso” será el proceso.
2. PUNTOS A CONSIDERAR

2. PUNTOS A CONSIDERAR
ORGANIZACIONALES.
El costo (financiero y humano), la forma en que la gerencia será soportada y, la aceptación y uso que le darán
los usuarios al nuevo SI, son temas que las alternativas de estrategias de diseño no pueden dejar fuera. No
hay que olvidar que el SI a desarrollar está inmerso dentro de una organización y que ésta influye
directamente sobre el uso y aprovechamiento del SI, así como el funcionamiento de éste influye en el
desempeño de la organización.

3. FASE DE
IMPLEMENTACIÓN
Es la fase que incluye la adquisición (compra) de
hardware, adquisición o desarrollo de software,
preparación de los usuarios, contratación y adiestramiento
de personal, preparación del sitio y los datos, instalación,
pruebas, arranque y aceptación de los usuarios.

3. Obtención de hardware
Durante la fase de puesta en operación, la
organización deberá identificar y elegir a uno
o más proveedores de sistemas de
información. Tales proveedores son empresas
que ofrecen hardware, software, sistemas de
telecomunicaciones, bases de datos, personal
de sistemas de información y otros recursos
relacionados con sistemas de computación.

3. Adquisición de Software: ¿producirlo o
comprarlo?
• Decisión relativa a obtener el software necesario, ya sea de fuentes
internas o externas.
• En algunos casos, las compañías usan una mezcla de desarrollo
interno y externo de software. En otras palabras, el personal de la
propia empresa modifica o adapta programas de software de
propietario o existente (listo para la venta), es decir, desarrollado en
forma específica para las necesidades de la compañía.

3. Software de
desarrollo externo
Algunas de las
razones por las que
una empresa
compraría a arrendaría
software de desarrollo
externo incluyen
costos bajos, menor
riesgo en relación con
las características de
desempeño del
paquete, y facilidad de
instalación. Además, el
desarrollo necesario
también es menor
cuando se compra el
software, en
comparación con el
desarrollo interno
(dentro de la empresa)
En caso tal, la empresa contratista
del software de desarrollo debe
emprender medidas como:
• Modificación o adaptación del
software para satisfacer las
necesidades de la empresa
contratante
• Adquisición de interfaces de
software: por ejemplo, si una
compañía adquiere un paquete de
software de propietario para la
administración de inventarios, la
interfaz de software debe permitir
que el nuevo paquete funcione
conjuntamente con otros
programas como los de pedidos y
facturación de ventas.
• Pruebas y aceptación del
software
• Mantenimiento y realización de
modificaciones necesarias

3. Software de desarrollo interno:
desarrollado en la propia empresa
Ventajas
• satisfacción de los requisitos de los usuarios de la
compañía
• contar con más características
• flexibilidad en la relativo a adaptación y cambios
• brindan una ventaja competitiva a la empresa, pues no
es fácil que la competencia los duplique en el corto plazo

Se parte de un proyecto de
programación de software a cargo de
un grupo de programadores
(profesionales en SI), cuya tarea es
diseñar y poner en operación un
conjunto de programas que se ajusten
a las necesidades de la compañía en
busca de automatizar sus procesos.
De ahí que, el desarrollo de software en la
empresa requiere un volumen considerable de
planeación detallada. Un conjunto de pasos y
actividades planeadas que pueden optimizar las
probabilidades de que se desarrolle el software
idóneo. Estas fases componen el ciclo de vida de
programación, que a continuación se detalla:

Ciclo de vida de
programación

3. Preparación de usuarios: proceso de alistar a los
administradores, tomadores de decisiones, empleados,
otros usuarios y beneficiarios para el nuevo sistema de
información. Creación de perfiles y cuentas de usuario.
El soporte continuo brinda ayuda a los usuarios después
de que se instala el sistema nuevo o modificado.
El propósito general es cerciorarse de que los usuarios
entiendan el sistema nuevo o modificado y se beneficien
de él. Tal soporte puede consistir en hardware, software y
servicios adicionales.

3. Recurso humano: contratación y adiestramiento
• La implementación del nuevo
sistema puede requerir un
administrador de SI, analistas de
sistemas, programadores,
digitadores, entre otros. Deben
realizarse capacitación para el
personal de SI que utilizará el
sistema. El adiestramiento eficaz
ayuda a que el personal que
haga uso del nuevo sistema
realice su trabajo y brinde apoyo
a otros usuarios de la compañía.

3. Preparación de
datos
• Consiste en adecuar el espacio
dentro de la compañía para la
implementación del SI, lo que
implica uno o más ordenadores -
según la extensión del SI-,
mobiliario de oficina, red de
cableado, aire acondicionado,
además de la instalación de un
sistema de seguridad para
proteger al equipo.
• Si la organización busca
automatizar todos sus procesos
de trabajo, todos los archivos
manuales deben convertirse en
archivos de computadora, en un
proceso llamado preparación o
conversión de datos. Se utiliza un
sistema de base de datos u otro
software para mantener y
actualizar estos archivos
digitales.
3. Preparación del
Sitio

3. Instalación
• Proceso de colocar físicamente el
equipo de computación en el sitio
asignado y ponerlo en
funcionamiento. El líder o
administrador del SI debe supervisar
el proceso para cerciorarse de que
se instala en el sitio correcto todo el
equipo especificado en el contrato.
Después de instalado el sistema, el
fabricante o proveedor realiza varias
pruebas para verificar que el equipo
funciona en forma óptima.

Pruebas
unitarias
• Pruebas individuales de los programas
Pruebas
de Sistema
• Pruebas de todo un sistema de programas
Prueba
de
volumen
• Pruebas de una aplicación con un gran volumen de datos
Pruebas de
integración
• Pruebas conjuntas de todos los sistemas relacionados
Pruebas
de
aceptación
• Pruebas que requieren el usuario para la aceptación del sistema
3. PRUEBAS

Sistema
antiguo
Sistema nuevo
Conversión directa
Sistema
antiguo
Sistema nuevo
Métodos de fases
Sistema
antiguo
Piloto 1
Piloto 2
Piloto 3
Arranque piloto
Sistema
antiguo
Sistema nuevo
Arranque Paralelo
3. Arranque
Procedimiento que se inicia con las pruebas finales del sistema
de información; cuando termina el arranque, el sistema debe
estar en operación plena.

3. Aceptación de los usuarios
• Muchos fabricantes de SI usan un documento de
aceptación de usuarios - un documento formal que
firman los usuarios par indicar que una fase de la
instalación, o el sistema completo, están aprobados -.
Dada su importancia, muchas compañías obtienen
asesoría legal antes de firmarlo. También es posible que
participen los beneficiarios en tal aceptación, para
verificar que se hayan derivado en realidad los
beneficios para ellos.

4. PRUEBAS
Tiene como objetivo
detectar los errores
que se hayan podido
cometer en las
etapas anteriores del
proyecto (y,
eventualmente,
corregirlos).

Pruebas de
unidad
Sirven para
comprobar el
correcto
funcionamiento de
nuestro sistema.
Pruebas de caja
blanca:
estructura interna
Pruebas de caja
negra:
limitaciones de la
implementación del
componente.
Pruebas de
integración
Son las que se
realizan cuando
vamos juntando los
componentes que
conforman nuestro
sistema y sirven
para detectar errores
en sus interfaces.
Pruebas
alfa
Una vez "finalizado"
el sistema, se realizan
estas pruebas.
Estas pruebas,
realizadas desde el
punto de vista de un
usuario final, pueden
ayudar a pulir aspectos
de la interfaz de usuario
del sistema.

Pruebas
beta
Estas pruebas las hacen
usuarios finales del
sistema ajenos al
equipo de desarrollo y
pueden resultar vitales
para que un producto
tenga éxito en el
mercado.
Test de
aceptación
marcará oficialmente el
final del proceso de
desarrollo y el comienzo
de la etapa de
mantenimiento

5. MANTENIMIENTO
• Eliminar los defectos
que se detecten
durante su vida útil.
MANTENIMIENTO
CORRECTIVO
• Adaptarlo a nuevas
necesidades.
MANTENIMIENTO
ADAPTATIVO
• refactorizar alguna
parte de la
aplicación para
hacerla más
mantenible o más
eficiente
MANTENIMIENTO
PERFECTIVO

BIBLIOGRAFIA
http://www.knosys.es/wp-content/uploads/2014/09/mantenimiento_1.png
https://userscontent2.emaze.com/images/34d6dca4-eec0-474f-9d5f
fd75195f3408/e4add85730edf0b891a7062fa4293081.png
http://1.bp.blogspot.com/-o1JDzLKA33c/UgGs922zsEI/AAAAAAAAADM/fmcLg-
yhpoI/s1600/descarga+(7).jpg
http://1.bp.blogspot.com/-_1AZL9BP4bI/VVEBEaSSa5I/AAAAAAAABLQ/VU6iA7lfj_U/s1600/mantenimiento.jpg
http://flanagan.ugr.es/docencia/2005-2006/2/apuntes/ciclovida.pdf

http://www.baluart.net/images/Introduccin-a-las-pruebas-unitarias-en-P_F7ED/pruebas-unitarias-
php_thumb.jpg
http://www.ciens.ucv.ve:8080/genasig/sites/disist/archivos/clase1.pdf
http://flanagan.ugr.es/docencia/2005-2006/2/apuntes/ciclovida.pdf
Stair, Ralph M. and Reynorlds, George W.
Principios de sistemas de información, 2000.
México, International Thomson Editores, p.588-
602

Facultad de Ciencias Humanas y Bellas Artes
Tel: (57) 6 7 35 9300 Ext 875
Carrera 15 Calle 12 Norte
Armenia, Quindío - Colombia
cienciashumanas@uniquindio.edu.co
Este espacio es para dar la
información institucional al
final de la presentación.
Deberá poner el nombre de la
dependencia, agregar la
extensión telefónica y cambiar
el correo electrónico.

Ciclo de vida de un sistema de información

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Ciclo de vida de un sistema de información

Similar a Ciclo de vida de un sistema de información (20)

Más de Carlos Daniel Chaves Avellaneda

Más de Carlos Daniel Chaves Avellaneda (20)

Último

Último (16)

Ciclo de vida de un sistema de información