Professional Documents
Culture Documents
Sistemas de
Informacin
1.Planificacin
2.Anlisis
3.Diseo
4.Implantacin
5.Mantenimiento
Planificacin
Implementac
in
Anlisis
Diseo
PLANIFICACIN DE SISTEMAS
Como sabemos, la planificacin de los sistemas de informacin es la primera etapa de un moderno ciclo de
desarrollo y se puede considerar compuesta a su vez de tres sub-etapas:
Estudio de la misin y de los objetivos de la empresa.
Establecer una arquitectura de la informacin.
Analizar las reas de empresa.
Estudio de la misin y de los objetivos de la empresa.
Para que los S.I sean verdaderamente tiles, han de contribuir a la misin de la empresa. Para aumentar el
impacto positivo de las inversiones en sistemas de informacin, han de dirigirse a los objetivos, reas y
actividades que contribuyan en mayor medida al cumplimiento de la misin.
Anlisis de los factores fundamentales para el xito.
Anlisis contextual. Especial referencia a la competencia.
Anlisis de las actividades sobre la base de la cadena de valor.
Anlisis del sistema de las actividades.
PLANIFICACIN DE SISTEMAS
Definicin de una arquitectura de informacin.
La arquitectura de informacin se encarga del estudio, anlisis, organizacin, disposicin y
estructuracin de la informacin en la organizacin, y de la seleccin y presentacin de los datos en
los sistemas de informacin interactivos.
Su principal objetivo es facilitar al mximo los procesos de comprensin y asimilacin de la
informacin, as como las tareas que ejecutan los usuarios en un espacio de informacin definido.
Durante esta etapa de definicin se han de
realizar una serie de actividades que siguen
una determinada secuencia, que se muestra a
continuacin junto con el diccionario de
planificacin en el que se archivan todos los
documentos que se van generando.
PLANIFICACIN DE SISTEMAS
Es un examen general en un doble sentido, abarca todo un rea de empresa y el nivel de detalle no es muy elevado.
Las tcnicas de estudio y anlisis buscan conjuntamente el rediseo de los procesos para hacerlos ms eficaces y
eficientes. En los ltimos aos se ha hablado de la reingeniera de procesos o rediseo radical de los sistemas de
informacin para mejorarlos y simplificarlos de forma intensa.
Para desarrollar esta fase ser necesario:
Constituir un equipo de anlisis multifuncional.
Identificar las medidas de rendimiento del rea de empresa.
Ampliar y desarrollar los modelos de reas de empresa.
Valoracin del rendimiento del rea de empresa y de los sistemas.
Establecer proyectos y prioridades.
Planificar proyectos de desarrollo reales.
Revisar las conclusiones y aprobar el plan.
ANLISIS DE SISTEMAS
El anlisis de sistemas es el estudio de una aplicacin del sistema de informacin y de empresa actual y la
definicin de las necesidades y las prioridades de usuario para conseguir una aplicacin nueva o mejorada.
Trata bsicamente de determinar los objetivos y lmites del sistema objeto de anlisis, caracterizar su
estructura y funcionamiento, marcar las directrices que permitan alcanzar los objetivos propuestos y evaluar
sus consecuencia.
Incluye las siguientes fases:
Anlisis de la Viabilidad del Proyecto (o fase de inspeccin).
Anlisis del sistema actual ( o fase de estudio).
Definicin y establecimiento de prioridades entre las necesidades de usuarios( o fase de definicin).
DISEO DE SISTEMAS
El diseo de sistemas se define como el proceso de aplicar ciertas tcnicas y principios con el propsito
de definir un dispositivo, un proceso o un sistema, con suficientes detalles como para permitir su
interpretacin y realizacin fsica.
La fase de diseo de sistemas encierra cuatro etapas:
El diseo de los datos: trasforma el modelo de dominio de la informacin, creado durante el anlisis, en
las estructuras de datos necesarios para implementar el software.
El diseo arquitectnico: define la relacin entre cada uno de los elementos estructurales del programa.
El diseo 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 diseo de procedimientos: transforma elementos estructurales de la arquitectura del programa. La
importancia del diseo del software se puede definir en una sola palabra Calidad, dentro del diseo es
donde se fomenta la calidad del proyecto.
EL DISEO DE PROCEDIMIENTOS
El diseo es la nica manera de materializar con precisin los requerimientos del cliente.
El diseo del software es un proceso y un modelado a la vez. El proceso de diseo es un conjunto de pasos repetitivos
que permiten al diseador describir todos los aspectos del sistema a construir.
A lo largo del diseo se evala la calidad del desarrollo del proyecto con un conjunto de revisiones tcnicas:
El diseo debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis y debe acumular todos
los requisitos implcitos que desea el cliente.
Debe ser una gua que puedan leer y entender los que construyan el cdigo y los que prueban y mantienen el software.
El diseo debe proporcionar una completa idea de lo que es el software.
DISEO DE SISTEMAS
Diseo de la salida.
En este caso salida se refiere a los resultados e informaciones generadas por
el sistema. Para la mayora de los usuarios la salida es la nica razn para el
desarrollo de un sistema y la base de evaluacin de su utilidad.
Cuando se realiza un sistema, como analistas deben realizar lo siguiente:
Determine que informacin presentar. Decidir si la informacin ser
presentada en forma visual, verbal o impresa y seleccionar el medio de salida.
Disponga la presentacin de la informacin en un formato aceptable.
Decidir como distribuir la salida entre los posibles destinatarios.
DISEO DE SISTEMAS
Diseo de archivos.
Incluye decisiones con respecto a la naturaleza y contenido del propio archivo, como si fuera a
emplear para guardar detalles de las transacciones, datos histricos, o informacin de
referencia.
Entre las decisiones que se toman durante el diseo de archivos, se encuentran las siguientes:
Los datos que deben incluirse en el formato de registros contenidos en el archivo.
La longitud de cada registro, con base en las caractersticas de los datos que contenga.
La secuencia a disposicin de los registros dentro del archivo.
No todos los sistemas requieren del diseo de todos los archivos, ya que la mayora de ellos
pueden utilizar los del viejo sistema y solo tenga que enlazarse el nuevo sistema al archivo
maestro donde se encuentran los registros.
DISEO DE SISTEMAS
Diseo de interacciones con la base de datos.
La mayora de los sistemas de informacin ya sean implantados en sistemas de cmputos
grandes o pequeos, utilizan una base de datos que pueden abarcar varias aplicaciones, por esta
razn estos sistemas utilizan un administrador de base de datos, en este caso el diseador no
construye la base de datos sino que consulta a su administrador para ponerse de acuerdo en el
uso de la base de datos en el sistema.
DISEO DE SISTEMAS
Herramientas de especificacin.
Apoyan el proceso de formular las caractersticas que debe tener una aplicacin, tales como
entradas, salidas, procesamiento y especificaciones de control. Muchas incluyen herramientas para
crear especificaciones de datos.
Generadores de cdigos.
Producen el cdigo fuente y las aplicaciones a partir de especificaciones funcionales bien
articuladas.
DISEO DE SISTEMAS
Herramientas para pruebas.
Apoyan la fase de la evaluacin de un sistema o de partes del mismo contra las
especificaciones.
Incluyen facilidades para examinar la correcta operacin del sistema as como el grado de
perfeccin alcanzado en comparacin con las expectativas.
La revolucin del procesamiento de datos de manera computarizada, junto con las practicas
de diseo sofisticadas estn cambiando de forma dramtica la manera en que se trasladan
las especificaciones de diseo de sistemas de informacin funcionales.
FASE DE IMPLANTACIN
Es la ltima fase del desarrollo de sistemas. Es el proceso de instalar equipos o software nuevos, como
resultado de un anlisis y diseo previo como resultado de la sustitucin o mejoramiento de la forma de
llevar a cabo un proceso automatizado.
Al implantar un sistema de informacin lo primero que debemos hacer es asegurarnos que el sistema
sea operacional, es decir, que funcione de acuerdo con lo que requiere el anlisis y permita que los
usuarios puedan operar con l.
Existen varios enfoques de implementacin:
Es darle responsabilidad a los grupos.
Uso de diferentes estrategias para el entrenamiento de los usuarios.
El analista de sistemas necesita ponderar la situacin y proponer un plan de conversin que sea
adecuado para la organizacin.
El analista necesita formular medidas de desempeo con las cuales evaluar a los usuarios.
Debe convertir fsicamente el sistema de informacin antiguo en el nuevo modificado.
FASE DE IMPLANTACIN
Capacitacin de usuarios del sistema.
Es ensear a los usuarios que se relacionan u operan en un proceso de implantacin.
La responsabilidad de esta capacitacin de los usuarios primarios y secundarios es del analista,
desde el personal de captura de datos hasta aquellos que toman las decisiones sin usar un
ordenador.
La empresa puede contratar los servicios de instructores externos pero el analista es la persona
que puede ofrecer la mejor capacitacin debido a que conoce al personal y el sistema mejor que
cualquier otra persona.
Si falta el analista la empresa puede contratar otros servicios de capacitacin como son:
Vendedores: son aquellos que proporcionan capacitacin gratuita fuera de la empresa de uno o dos das.
Instructor pagado externamente: son aquellos que pueden ensear todo acerca de los ordenadores
pero para algunos usuarios esta no es una capacitacin necesaria.
Instructores en casa: estn familiarizados con el personal y pueden adecuar los materiales a sus
necesidades, pero le faltara experiencia en sistemas de informacin que es realmente la necesidad del
usuario.
El objetivo de la capacitacin es lograr que los usuarios tengan el dominio necesario de las cosas
bsicas acerca de las maquinarias y procesos que se emplean para su operacin de manera eficiente y
segura.
Diseo
Codificacin
Prueba
Mantenimiento
MODELO INCREMENTAL.
Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de
reducir los riesgos es construir slo una parte del sistema, reservando otros aspectos para niveles
posteriores. El desarrollo incremental es el proceso de construccin siempre incrementando
subconjuntos de requerimientos del sistema.
El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:
Construir un sistema pequeo tiene siempre menos riesgo que construir un sistema grande.
Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si los requerimientos
planeados para los niveles subsiguientes son correctos.
Si un error importante es realizado, slo la ltima iteracin necesita ser descartada.
Reduciendo el tiempo de desarrollo de un sistema decrecen las probabilidades que esos requerimientos
de usuarios puedan cambiar durante el desarrollo.
Si un error importante es realizado, el incremento previo puede ser usado.
Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del
prximo incremento.
MODELO DE PROTOTIPADO DE
REQUERIMIENTOS.
El prototipado de requerimientos es la creacin de una implementacin parcial de un
sistema, para el propsito explcito de aprender sobre los requerimientos del
sistema.
Un prototipo es construido de una manera rpida tal como sea posible. Esto es dado a
los usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten
con el prototipo. Estos individuos luego proveen la retroalimentacin sobre lo que a
ellos les gust y no les gust acerca del prototipo proporcionado, quienes capturan en
la documentacin actual de la especificacin de requerimientos la informacin
entregada por los usuarios para el desarrollo del sistema real.
MODELO EN ESPIRAL
Es un modelo evolutivo que combina el modelo clsico con el diseo de prototipos.
Incluye la etapa de anlisis de riesgos.
Es ideal para crear productos con diferentes versiones mejoradas.
Este es el enfoque ms realista actualmente. El modelo en espiral se divide en un numero de
actividades estructurales, tambin llamadas regiones de tareas.
Generalmente, existen entre tres y seis regiones de tareas:
Comunicacin con el cliente: las tareas requeridas para establecer comunicacin entre el
desarrollador y el cliente.
Planificacin: las tareas requeridas para definir recursos, el tiempo y otras informaciones
relacionadas con el proyecto. Son todos los requerimientos.
Anlisis de riesgos: las tareas requeridas para evaluar riesgos tcnicos y otras informaciones
relacionadas con el proyecto.
Ingeniera: las tareas requeridas para construir una o ms representaciones de la aplicacin.
Construccin y adaptacin: las tareas requeridas para construir, probar, instalar y proporcionar
soporte al usuario.
Evaluacin del cliente: las tareas requeridas para obtener la reaccin del cliente segn la evaluacin
de las representaciones del software creadas durante la etapa de ingeniera e implementacin
durante la etapa de instalacin.
EL MODELO EN ESPIRAL
Planificacin
Anlisis de riesgos
Comunicacin
con el cliente
Ingeniera
Evaluacin del
cliente
Construccin y adaptacin
MODELO DE CONSTRUCCIN DE
PROTOTIPOS
Recoleccin
refinamiento
requisitos
Producto de
ingeniera
Diseo
rpido
Refinamiento
del prototipo
Construccin
del prototipo
Evaluacin
del prototipo
por el cliente
MODELO DE CONSTRUCCIN DE
PROTOTIPOS
Este modelo arranca con el establecimiento de los requerimientos del sistema, se definen
los objetivos del sistema y los requisitos conocidos con base en las reas de mayor
prioridad e importancia para el sistema.
Luego se hace un diseo preliminar , sobre el cual se construye un prototipo o modelo del
sistema, compuesto a menudo de ventanas, tablas de la Base de Datos, formatos de
entrada y de salida bsicos.
Un prototipo es una representacin o modelo del producto de programacin que incorpora
componentes del producto real. Por lo regular, un prototipo tiene un funcionamiento
limitado en cuanto a capacidades, confiabilidad o eficiencia.
MTODO SCRUM
Roles Principales[editar]
Product Owner
ElProduct Ownerrepresenta la voz del cliente. Se asegura de que el equipo Scrum
trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner escribe
historias de usuario, las prioriza, y las coloca en elProduct Backlog.
ScrumMaster (o Facilitador)
ElScrumes facilitado por unScrumMaster, cuyo trabajo primario es eliminar los
obstculos que impiden que el equipo alcance el objetivo del sprint. ElScrumMasterno
es el lder del equipo (porque ellos se auto-organizan), sino que acta como una
proteccin entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se
asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que
hace que las reglas se cumplan.
Equipo de desarrollo
El equipo tiene la responsabilidad de entregar el producto. Es recomendable un pequeo
equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el
trabajo (anlisis, diseo, desarrollo, pruebas, documentacin, etc).
Cundo se utiliza?