1. Unidad 4. Ciclo de vida de un
Sistema de Información
Análisis
Diseño
Implementación
Pruebas y mantenimiento
Universidad del Quindío
Teoría de Sistemas
2. Loren Eliana Garzón Páez
Diana Patricia Oyola Chambo
Cristian David Herrera Bolaños
Jessica Castellano Andica
Carolina Ortiz Duque
Andrés Steven Acevedo Silva
Lina María Reyes Prada
Juan Alvarez Celis
Grupo expositor:
4. Es el proceso por el cual se investiga,
examina la situación de una empresa
con el propósito de implementar y
mejorar los procesos y procedimientos
de la misma.
¿En que consiste análisis
de un S.I?
5. El proceso consiste en recoger información
sobre el sistema vigente (llamado as-
is sistem), que puede estar o no
computadorizado, identificar sus fortalezas y
problemas, y analizarlo para producir un
concepto para el nuevo sistema (llamado to-
be system). La meta de la fase del análisis es
entender los requerimientos para el nuevo
sistema y desarrollar un concepto de
sistema que determinará si es o no
necesario un nuevo sistema.
6. Automatización del proceso de
administración (BPA
Business process automation),
mejoramiento del proceso de
administración (BPI
Business process improvement), y
reingeniería del proceso de administración
(BPR
Business process reengineering).
Estrategias para el análisis de
un S.I
7. Las 3 estrategias para el Análisis
• Automatización
Mejoramiento
• Reingeniería
8. Automatización del proceso
administrativo
Hace referencia básicamente a los cambios
en la manera de operar la organización por el
uso de la tecnología de la computadora para
hacer parte del trabajo. La automatización
del proceso generalmente provee mayor
eficiencia para los usuarios, aunque los
servicios no se vean impactados.
9. Mejoramiento del proceso
administrativo
Son cambios moderados a la forma tradicional
de operar de la organización con el propósito de
tomar ventaja de las nuevas oportunidades que
ofrece la tecnología, o copiar lo que la
competencia está haciendo. BPI puede mejora
la eficiencia (haciendo las cosas correctas) y
mejorar la efectividad (haciendo correctamente
las cosas).
10. Reingeniería del proceso
administrativo
Son cambios fundamentales de la forma que
opera la organización para tomar ventaja de
las nuevas ideas y de la nueva tecnología.
Requiere un rediseño completo del negocio
antes del sistema de información para que
soporte el nuevo sistema. Por ejemplo, los
estudiantes no necesitan autorización para
sacar los materiales de la biblioteca, pues
tienen acceso vía Web al texto en su
totalidad.
11. Estrategia Identificación del
sistema vigente
Identificación del
mejoramiento
Desarrollo del
concepto del nuevo
sistema
Automatizació
n del proceso
administrativo
Recogida de
información
extensiva
Análisis del problema
Raíz que causa el
problema
Recogida de
información mínima
Mejoramiento
del proceso
administrativo
Recogida de
información
extensiva
Tiempo de duración del
análisis
Recogida de
información
moderada
Reingeniería
del proceso
administrativo
Recogida de
información
mínima
Análisis del resultado
Análisis de la tecnología
Eliminación de actividad
Recogida de
información
extensiva
12. Desarrollo de un plan de análisis
consiste en la planificación de aquellas funciones
que el equipo del proyecto conducirá durante la fase
del análisis. El plan del análisis ha de especificar las
actividades que se requieren en cada una de las
tres etapas de esta fase: para comprender el sistema
actual (as-is system), para identificar áreas de
mejoramiento y para desarrollar un concepto del
nuevo sistema (to-be system).
Una de las actividades centrales de este plan de
análisis están las relacionadas con la recopilación
de información que se requiere para el desarrollo
de las tres etapas del análisis, así como el desarrollo
de los modelos de procesos y de datos.
13. Características de las estrategias para el análisis
Automatización
del proceso
administrativo
Mejoramiento
del proceso
administrativo
Reingeniería del
proceso
administrativo
Valor potencial
del negocio
Bajo-Moderado Modearado Alto
Costo del
proyecto
Bajo
Bajo-
Moderado
Alto
Amplitud del
análisis
Mínima
Mínima-
Moderada
Muy amplia
Riesgo
Poco-Moderado
Poco-
Moderado
Mucho
15. DEFINICIÓN:
El Diseño de Sistemas se define como el proceso para aplicar ciertas
técnicas y principios con el propósito de definir un dispositivo, un proceso o
un Sistema, con suficientes detalles como para permitir su interpretación y
realización física.
OBJETIVO:
El objetivo del proceso de Diseño del Sistema Información (DSI) es la
definición de la arquitectura del sistema y del entorno tecnológico que le
va a dar soporte, junto con la especificación detallada de los componentes
del sistema de información.
16.
17. ETAPAS DEL DISEÑO DE SISTEMAS:
El Diseño de los Datos: Transforma el modelo de dominio de la
información, creado durante el análisis, en las estructuras de
datos necesarios para implementar el Software.
El Diseño Arquitectónico: Define la relación entre cada uno de los
elementos estructurales del programa
El Diseño de la Interfaz: Describe como se comunica el Software
consigo mismo, con los sistemas que operan junto con el y con los
operadores y usuarios que lo emplean.
El Diseño de Procedimientos: Transforma elementos estructurales
de la arquitectura del programa. La importancia del Diseño del
Software se puede definir en una sola palabra Calidad, dentro del
diseño es donde se fomenta la calidad del Proyecto. El Diseño es
la única manera de materializar con precisión los requerimientos
del cliente. El proceso del Diseño es el conjunto de pasos
repetitivos que permiten al diseñador describir todos los aspectos
del Sistema a construir.
18. CRITERIOS TÉCNICOS PARA UN BUEN DISEÑO:
Un diseño debe presentar una organización jerárquica que haga un uso
inteligente del control entre los componentes del software.
El diseño debe ser modular, es decir, se debe hacer una partición lógica
del Software en elementos que realicen funciones y subfunciones
especificas.
Un diseño debe contener abstracciones de datos y procedimientos.
Debe producir módulos que presenten características de funcionamiento
independiente.
Debe conducir a interfaces que reduzcan la complejidad de las conexiones
entre los módulos y el entorno exterior.
Debe producir un diseño usando un método que pudiera repetirse según
la información obtenida durante el análisis de los requisitos de Software.
19. Estos criterios no se consiguen por casualidad. El proceso de Diseño
del Software exige buena calidad a través de la aplicación de
principios fundamentales de Diseño, Metodología sistemática y una
revisión exhaustiva.
Cuando se va a diseñar un Sistema de Computadoras se debe tener
presente que el proceso de un diseño incluye, concebir y planear
algo en la mente, así como hacer un dibujo, modelo o croquis.
20. DISEÑO DE LA SALIDA:
En este caso la salida se refiere a los resultados e informaciones
generadas por el Sistema. Para la mayoría de los usuarios la salida es la
única razón para el desarrollo de un Sistema y la base de evaluación de su
utilidad. Sin embargo cuando se realiza un sistema, como analistas deben
realizar lo siguiente:
Determine que información presentar.
Decidir si la información será presentada en forma visual, verbal o
impresora y seleccionar el medio de salida.
Disponga la presentación de la información en un formato aceptable.
Decida como distribuir la salida entre los posibles destinatarios.
22. En esta fase se realizan las actividades
necesarias para poner a disposición el sistema
de información.
1. Revisar la formulación del proyecto.
2. Se estudia su alcance.
3. Se define un plan para su implementación.
4. Especificar los integrantes del equipo de
trabajo.
OBJETIVO
23. QUE ES LA IMPLEMENTACIÓN EN UN
SISTEMA DE INFORMACIÓN
Es la fase más costosa y consume más tiempo, esto es
porque muchas personas, herramientas y recursos
están involucrados en este proceso.
24. El cumplimiento de los requerimientos de
implantación definidos en el Catalogo de
Requerimientos y especificados en la
actividad.
La estrategia de transición del sistema antiguo
al nuevo.
SE TIENE EN CUENTA:
26. ACTIVIDAD 1: DEFINICIÓN DEL PLAN DE
IMPLANTACIÓN
ACTIVIDAD 2: PREPARACIÓN DEL ENTORNO DE
PRODUCCIÓN
ACTIVIDAD 3: CAPACITACIÓN PARA LA
IMPLANTACIÓN
ACTIVIDAD 4: PUBLICACIÓN DE PROCEDIMIENTOS
NORMATIVOS
ACTIVIDAD 5: INSTALACION DEL SISTEMA
ACTIVIDAD 6: PUESTA EN MARCHA DEL SISTEMA
ACTIVIDAD 7: REUNION DE GESTION
DESARROLLO DEL PROCEDIMIENTO DE
IMPLANTACIÓN
28. PRUEBAS
Errar es humano y la etapa de pruebas tiene como objetivo
detectar los errores que se hayan podido cometer en las etapas
anteriores del proyecto (y, eventualmente, corregirlos). Lo suyo,
además, es hacerlo antes de que el usuario final del sistema los
tenga que sufrir. De hecho, una prueba es un éxito cuando se
detecta un error (y no al revés, como nos gustaría pensar).
29. La búsqueda de errores que se realiza en la etapa de pruebas puede
adaptar distintas formas, en función del contexto y de la fase del
proyecto en la que nos encontremos:
Las pruebas de unidad: Sirven para comprobar el correcto funcionamiento
de un componente concreto de nuestro sistema. Es este tipo de pruebas,
el "probador" debe buscar situaciones límite que expongan las
limitaciones de la implementación del componente, ya sea tratando éste
como una caja negra ("pruebas de caja negra") o fijándonos en su
estructura interna ("pruebas de caja blanca"). Resulta recomendable que,
conforme vamos añadiéndole nueva funcionalidad a nuestras
aplicaciones, vayamos creando nuevos tests con los medir nuestro
progreso y también repitamos los antiguos para comprobar que lo que
antes funcionaba sigue funcionando (test de regresión).
30. Las 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. En algunas empresas, como
Microsoft, se hace una compilación diaria utilizando los componentes
del sistema tal como estén en ese momento (daily build) y se somete al
sistema a una serie de pruebas básicas (la prueba de humo, smoke
test) que garanticen que el proyecto podrá seguir avanzando al día
siguiente. El causante de que la compilación diaria falle suele tener
que quedarse a hacer horas extra para que sus compañeros puedan
seguir trabajando al día siguiente...
31. Pruebas alfa: Una vez "finalizado" el sistema, se realizan en el seno de la
organización encargada del desarrollo del sistema. 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: Cuando el sistema no es un producto a medida, sino que se
venderá como un producto en el mercado, también se suelen realiza 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: Se suelen realizar en sistemas a medida que si se supera
con éxito, marcará finalmente el final del proceso de desarrollo y el comienzo
de la etapa de mantenimiento.
Por último, a lo largo de todo el ciclo de vida del software, se suelen hacer
revisiones de todos los productos generados a lo largo del proyecto, desde el
documento de especificación de requerimientos hasta el código de los distintos
módulos de una aplicación. Estas revisiones, de carácter más o menos formal,
ayuden a verificar la corrección del producto revisado y también a validarlo
(comprobar que se ajusta a los requerimientos reales del sistema).
32. MANTENIMIENTO DE LOS SISTEMAS
DE INFORMACION
Llamamos mantenimiento a las modificaciones que se
realizan en el producto software después de la
entrega al usuario. Estas modificaciones podrán ser
realizadas para mejorar el rendimiento, corregir
defectos, adaptar el producto software a un nuevo de
entorno, software o hardware, u otras propiedades
deseables en el producto.
33. Barrera de Mantenimiento
Se define como el porcentaje máximo o límite de los
recursos que son necesarios para el mantenimiento
del software. El llegar a la barrera de mantenimiento
imposibilitaría la realización de nuevos desarrollos.
34. Actividades de Mantenimiento
son cada una de las actividades que se deben realizar
en el proceso del mantenimiento, estas actividades
serán: Gestión de peticiones, comprensión del
software y de los cambios que se deben realizar sobre
el mismo, modificación del software.
35. TIPOS DE MANTENIMIENTO
Correctivo: Se trata del mantenimiento que se realiza
a cabo para corregir los errores detectados durante la
explotación del sistema.
Perceptivo (evolutivo): Se trata del mantenimiento
que se realiza para las incorporaciones,
modificaciones y eliminaciones al programa. Es el
mantenimiento que mayor coste supone (hasta un
60% relativo respecto al resto de mantenimientos).
36. Adaptativo: Se trata del mantenimiento llevado a cabo para
adaptar o modificar el sistema a un nuevo entorno
tecnológico (software, hardware, etc.).
Perfectivo: Se trata del mantenimiento que se realiza para
prevenir futuros problemas o para facilitar el
mantenimiento futuro del sistema.
37. La estructura propuesta para el Proceso de
Mantenimiento de MÉTRICA Versión 3
comprende las siguientes actividades:
