Sesion 1 SI-II

Ingeniera Informtica-UNSAAC
Sistemas de
Informacin II
19/10/16
Ing. Maritza Irpanocca Cusimayta
CAPITULO I:
SISTEMAS DE
INFORMACIN EN LA
PRCTICA
19/10/16
a) Sistemas de Informacin
Un SI se puede definir como un

conjunto
de
elementos
interrelacionados que recolectan
(recuperan), procesan almacenan y
distribuyen
informacin
para
apoyar la toma de decisiones y el
control en una organizacin.
b) Componentes de los Sistemas de

Informacin
Proveedores
ENTORNO
Clientes
Organizacin
Sistema de Informacin
Entrada
PROCESO
Clasificar
Ordenar
Calcular
Salida
Retroalimentacin
Agencias Reguladoras
Accionistas
Competidores
4
c) Tipos de Sistemas de
Informacin
Competidore
s
Nivel Gerencial
Clientes
Nivel Operativo
Sistemas
estratgicos
Sistemas de
Soporte a toma
de decisiones
Sistemas
transaccionales u
Operacionales
Sistemas para administrativos

Sistemas a nivel de conocimiento
BD
c.1) Sistemas de Informacin

Transaccionales
Encargados de procesar gran cantidad de
transacciones
rutinarias, es decir
son todas aquellas que se realizan
rutinariamente en la empresa entre estas tenemos el pago de
nomina, facturacin, entrega de mercanca y depsitos de
cheques. Estas transacciones varan de acuerdo al tipo de
empresa.
Base de
Datos
SGBD
Logstica
Produccin
Ventas y
Marketing
Contabilidad
Finanzas
Recursos
Humanos
c.2) Sistema de Soporte a Toma de

Suelen ser diseados especialmente para servir a los
decisiones
administradores en cualquier nivel de la organizacin.
Anlisis
multidimensional
Base de datos
Operacionales
Extraccin
Transformacin
Data
Warehouse
Sistema de
Soporte a
la toma de
decisiones
Data
Minin
g
Generacin
De relaciones
Datos Externos
c.3) Sistemas Estratgicos

Provee al ejecutivo acceso fcil a
informacin interna y externa al negocio

con el fin de dar seguimiento a los factores
crticos del xito.
La informacin se origina tanto dentro de
la compaa como en su entorno
d) Actividades Bsicas de un SI
Entrada de Informacin:
Las entradas pueden ser manuales (por el
usuario) o automticas (otros sistemas).
Las unidades tpicas de entrada de datos a las
computadoras son las terminales, los cdigos de
barras, los escners, la voz, los monitores
sensibles al tacto, el teclado y el mouse, entre
otras.
Entrada
Almacenamiento de informacin:
A travs de esta propiedad el sistema puede
recordar la informacin guardada en la seccin
o proceso anterior.
Esta informacin suele ser almacenada en
archivos, discos duros, discos compactos (CD),
Memorias USB, discos Externos.
10
Procesamiento de Informacin:
Es la capacidad del Sistema de Informacin
para efectuar clculos de acuerdo con una
secuencia de operaciones preestablecida.
Esta caracterstica de los sistemas permite la
transformacin
de
datos
fuente
en
informacin que puede ser utilizada para la
toma de decisiones.
11
Salida de Informacin:
Informacin procesada o bien datos de entrada al
exterior. Las unidades tpicas de salida son las
impresoras, terminales, la voz, los graficadores y
los plotters, entre otros.
La salida de un Sistema de Informacin puede
constituir la entrada a otro Sistema de
Informacin o mdulo. En este caso, tambin
existe una interfase automtica de salida.
Salida
12
e) Elementos de un Sistema de
Informacin
SOFTWARE. Los programas, las estructuras de datos y la documentacin
asociada, que sirve para realizar el mtodo lgico.
HARDWARE: Los dispositivos electrnicos que proporcionan la capacidad
de computacin y que proporcionan las funciones del mundo exterior.
PERSONAS: Los individuos que son usuarios y operadores del software y
del hardware.
BASES DE DATOS: Una coleccin grande y organizada de informacin a
la que se accede mediante el software y que es una parte integral del
funcionamiento del sistema.
DOCUMENTACION: Los manuales, los impresos y otra informacin
descriptiva que explica el uso y / o la operacin.
PROCESAMIENTO: Los pasos que definen el uso especifico de cada
elemento del sistema o el contexto procedimental en que reside el
sistema.
CONTROL: Los sistemas trabajan mejor cuando operan dentro de niveles
de control tolerables de rendimiento y avance del proyecto, cumplimiento
de estndares.
13
l) Qu es una organizacin?
Es un grupo estructurado de personas que
trabajan en comn, en el cumplimiento de

ciertas metas que los individuos no podran
alcanzar solos.
Las organizaciones pueden ser iguales en su
necesidad de cumplir metas, pero difieren
respecto a cuales son esas metas.
14
El Papel De El Analista De
Sistemas
Los analistas de sistemas generalmente valoran
la manera en que funcionan los negocios
examinando la entrada, el procesamiento de
datos y la salida de informacin con el propsito
de mejorar los procesos organizacionales.
Muchas mejoras involucran mejor apoyo para
las funciones de los negocios por medio del uso
de sistemas de informacin computarizados.
El analista debe ser capaz de trabajar con
personas de todas las descripciones y debe

tener
experiencia
en
el
trabajo
con
computadoras. El analista desempea muchos
papeles, balanceando a veces varios al mismo
tiempo. Los tres papeles principales del analista
de sistemas son: consultor, experto de soporte
y agente de cambio.
15
EL
ANALISTA
DE
SISTEMAS
COMO
CONSULTOR:
Frecuentemente acta como consultor y, por lo
tanto, puede ser contratado especficamente
para que se encargue de los asuntos de los
sistemas de informacin dentro de un negocio.
EL ANALISTA DE SISTEMAS COMO EXPERTO
DE SOPORTE:
En este papel el analista se apoya en su
experiencia profesional relacionada con el
hardware, software y su uso en el negocio.
EL ANALISTA DE SISTEMAS COMO AGENTE
DE CAMBIO:
Un agente de cambio puede ser definido como
una persona que sirve de catalizador para el
cambio, desarrolla un plan para el cambio y
trabaja junto con otros para facilitar ese
cambio.
16
Trabajo Grupal
Identifique los componentes del sistema de
Informacin de su proyecto.
A qu tipo de Sistema de Informacin
pertenece su proyecto?
Identifique los elementos del sistema de
informacin de su proyecto.
19/10/16
17
1.- El Producto
Que es?
El software de computadora es el producto que
disean y construyen los ingenieros del software.
Esto abarca programas que se ejecutan dentro de
una computadora de cualquier tamao y
arquitectura, documentos que comprenden
formularios virtuales e impresos y datos que
combinan nmeros y texto y tambin incluyen
representaciones de informacin de audio, videos
e imgenes.
18
Cul es el producto obtenido?

Desde el punto de vista de
un ingeniero de software, el
producto obtenido son los
programas, documentos y
los datos que configuran el
software de computadora.
Desde el punto de vista de
los usuarios el producto

obtenido es la informacin
resultante que hace de
algn modo el mundo
mejor a los usuarios.
19
El Software
Caractersticas del Software
a) El Software se desarrolla, no se fabrica en un sentido clsico.

Aunque existen similitudes entre el desarrollo del software y la
construccin del hardware, ambas actividades son

fundamentalmente diferentes.
La buena calidad se adquiere mediante un buen diseo, pero la fase de
construccin del hardware puede introducir problemas de calidad que
no existen (o son fcilmente corregibles) en el software.
Ambas actividades dependen de las personas, pero la relacin entre las
personas dedicadas y el trabajo realizado es completamente diferente
para el software
Ambas actividades requieren la construccin de un producto pero los
enfoques son diferentes.
20
b) El software no se estropea
Los defectos no detectados harn que falle el programa
durante las primeras etapas de su vida.
Durante su vida, el software sufre cambios (mantenimiento).
Conforme se hacen los cambios, es bastante probable que
se introduzcan nuevos defectos.
No hay piezas de repuesto para el software. Cada fallo en el
software indica un error en el diseo o en el proceso
mediante el que se tradujo el diseo a cdigo mquina
ejecutable. Por tanto, el mantenimiento del software tiene
una complejidad considerablemente mayor que la del
mantenimiento del hardware.
21
c) Aunque la industria tiende a ensamblar

componentes, la mayora del software se
construye a medida.
El componente de software debera disearse e
implementarse para que pueda volver a ser

reutilizado en muchos programas diferentes.
Los componentes reutilizables modernos
encapsulan tanto datos como procesos que se
aplican a los datos, permitiendo al ingeniero del
software crear nuevas aplicaciones a partir de las
partes reutilizables.
22
Mitos del Software

Mito.
Tenemos ya un libro que
est lleno de estndares y
procedimientos para
construir software, no le
proporciona ya a mi gente
todo lo que necesita saber?
Realidad.
Est muy bien que el libro
exista, pero se usa?,
conocen los trabajadores
su existencia?, refleja las
prcticas modernas de
desarrollo de software?, es
completo?, est diseado
para mejorar el tiempo de
entrega mientras mantiene
un enfoque de calidad?. En
muchos casos, la respuesta
a todas estas preguntas es
no.
23
Mito
Mi gente dispone de las
herramientas de desarrollo
de software ms
avanzadas, despus de
todo, les compramos las
computadoras ms
modernas.
Realidad
Se necesita mucho ms que el
ltimo modelo de
computadora grande o de PC
para hacer desarrollo de
software de gran calidad. Las
herramientas de ingeniera del
software asistida por
computadora (CASE) son ms
importantes que el hardware
para conseguir buena calidad
y productividad, aunque la
mayora de los desarrolladores
del software todava no las
utilicen eficazmente.
24
Mito
Si fallamos en la
planificacin, podemos
aadir ms programadores
y adelantar el tiempo
perdido (el llamado algunas
veces concepto de la
horda Mongoliana).
Realidad
El desarrollo de software no es
un proceso mecnico como la
fabricacin. En palabras de
Brooks : ...aadir gente a un
proyecto de software retrasado
lo retrasa an ms. Al
principio, esta declaracin
puede parecer un
contrasentido. Sin embargo,
cuando se aaden nuevas
personas, la necesidad de
aprender y comunicarse con el
equipo puede y hace que se
reduzca la cantidad de tiempo
gastado en el desarrollo
productivo. Puede aadirse
gente, pero slo de una manera
planificada y bien coordinada.
25
Mito
Una declaracin general de
los objetivos es suficiente
para comenzar a escribir
los programas -podemos
dar los detalles ms
adelante-.
Realidad
Una mala definicin inicial es
la principal causa del trabajo
errado en software. Es
esencial una descripcin
formal y detallada del mbito
de la informacin, funciones,
comportamiento,
rendimiento, interfaces,
ligaduras del diseo y
criterios de validacin. Estas
caractersticas pueden
determinarse slo despus de
una exhaustiva comunicacin
entre el cliente y el analista.
26
Mito
Los requisitos del proyecto
cambian continuamente,
pero los cambios pueden
acomodarse fcilmente, ya
que el software es flexible.
Realidad
Es verdad que los requisitos del software
cambian, pero el impacto del cambio vara
segn el momento en que se introduzca.
Si se pone cuidado al dar la definicin
inicial, los cambios solicitados al principio
pueden acomodarse fcilmente. El cliente
puede revisar los requisitos y recomendar
las modificaciones con relativamente poco
impacto en el costo. Cuando los cambios
se solicitan durante el diseo del software,
el impacto en el costo crece rpidamente.
Ya se han acordado los recursos a utilizar
y se ha establecido un marco de trabajo
del diseo. Los cambios pueden producir
trastornos que requieran recursos
adicionales e importantes modificaciones
del diseo; es decir, costo adicional. Los
cambios en la funcin, rendimiento,
interfaces u otras caractersticas, durante
la implementacin (codificacin y prueba)
pueden tener un impacto importante
sobre el costo. Cuando se solicitan al final
de un proyecto, los cambios pueden
producir un orden de magnitud ms caro
que el mismo cambio pedido al principio.
27
Mito
Una vez que
escribimos el
programa y hacemos
que funcione,
nuestro trabajo ha
terminado.
Realidad
Alguien dijo una vez:
cuanto ms pronto se
comience a escribir
cdigo, ms se tardar en
terminarlo. Los datos
industriales indican que
entre el 60 y el 80 por
ciento de todo el esfuerzo
dedicado a un programa
se realizar despus de
que se le haya entregado
al cliente por primera vez.
28
Mito
Hasta que no tengo el
programa
ejecutndose,
realmente no tengo
forma de comprobar su
calidad.
Realidad
Desde el principio del
proyecto se puede aplicar
uno de los mecanismos ms
efectivos para garantizar la
calidad del software: la
revisin tcnica formal.
La revisin del software es
un filtro de calidad que se
ha comprobado que es ms
efectivo que la prueba, para
encontrar ciertas clases de
defectos en el software.
29
Mito
Lo nico que se
entrega al terminar el
proyecto es el
programa funcionando.
Realidad
Un programa que funciona
es slo una parte de una
configuracin del software
que incluye muchos
elementos. La
documentacin
proporciona el fundamento
para un buen desarrollo y,
lo que es ms importante,
proporciona guas para la
tarea de mantenimiento
del software.
30
El Proceso
31
Qu es?
Cuando trabaja para construir un producto o
un sistema, es importante seguir una serie de
pasos predecibles-un mapa de carreteras que
le ayude a obtener el resultado oportuno de
calidad-.
El mapa de carreteras a seguir es llamado
proceso del software.
32
Quinlo hace?
Los ingenieros de software y sus gestores
adaptan el proceso a sus necesidades y
entonces lo siguen. Adems las personas que
han solicitado el software tienen un papel a
desempear en el proceso del software.
33
Por qu es importante?
Porque proporciona estabilidad, control y
organizacin a una actividad que puede, si no
se controla, volverse catica.
34
Cules son los pasos?

A un nivel detallado, el proceso que
adoptemos depende del software que
estamos construyendo.
Un proceso puede ser apropiado para crear
software de un sistema de aviacin, mientras
que un proceso diferente por completo puede
ser adecuado para la creacin de un sitio web.
35
Cul es el producto obtenido?

Desde el punto de vista de un ingeniero de
software, los productos obtenidos son
programas, documentos y datos que se
producen como consecuencia de las
actividades de ingeniera del software
definidas por el proceso.
36
Cmo puedo estar seguro de que lo he

hecho correctamente?
Hay una cantidad de mecanismos de
evaluacin del proceso del software que
permiten a las organizaciones determinar la
madurez de su proceso del software.
Sin embargo, la calidad, oportunidad y
viabilidad a largo plazo del producto que est
construyendo son los mejores indicadores de la
eficiencia del proceso que estamos utilizando.
37
Proceso, mtodos y
herramientas
La Ingeniera del software es un tecnologa
multicapa.
Cualquier enfoque de ingeniera (incluida
ingeniera del software) debe apoyarse sobre
un compromiso de organizacin de calidad.
Herramient
as
Mtodos
Procesos
Un enfoque de calidad
38
Una visin general de la

ingeniera del
Se deben cuestionar y responder las siguientes
software
preguntas:
Cul es el problema a resolver?

Cules son las caractersticas del software que se utiliza
para resolver el problema?

Cmo se construir el software?
Qu enfoque se va a utilizar para no contemplar los
errores que se cometieron en el diseo y en la
construccin del software?
Cmo se apoyar el software cuando los usuarios
soliciten correcciones, adaptaciones y mejoras del
software?
39
El trabajo que se asocia a la ingeniera del software se puede

dividir en tres fases genricas, con independencia del rea de
aplicacin, tamao o complejidad del proyecto.
La fase de definicin (qu informacin, funcin y
rendimiento, interfaces, restricciones y criterios de validacin).

La fase de desarrollo (cmo han de disearse las
estructuras de datos, implementar la funcin dentro de una
arquitectura de software, detalles procedimentales, interfaces,
lenguaje de programacin y cmo ha de realizarse la prueba).
La fase de mantenimiento (correccin de errores, se
encuentran cuatro tipos de cambios: )
Correccin
Adaptacin
Mejora
Prevencin
40
Existen diversas actividades protectoras:

Seguimiento y control del proyecto de software
Revisiones tcnicas formales
Garanta de calidad del software
Gestin de configuracin del software
Preparacin y produccin de documentos
Gestin de reutilizacin
Mediciones
Gestin de riesgos
41
EL CICLO DE VIDA
DEL DESARROLLO
DE SISTEMAS
42
EL CICLO DE VIDA DEL DESARROLLO DE

SISTEMAS
Es un enfoque por fases del anlisis y diseo
de sistemas.
Los sistemas son desarrollados de mejor
manera mediante el uso de un ciclo especfico
de actividades del analista y del usuario.
Aunque cada fase es presentada en forma
discreta, nunca se lleva a cabo como un paso
aparte, varias actividades pueden suceder
simultneamente, y las actividades pueden
ser repetidas.
43
EL CICLO DE VIDA DEL DESARROLLO DE

SISTEMAS
44
Etapas:
1. Identificacin de problemas,
2.
3.
4.
5.
6.
7.
oportunidades y objetivos.
Determinacin de los requerimientos de
informacin
Anlisis de las necesidades del sistema
Diseo del sistema recomendado
Desarrollo y documentacin del software.
Pruebas y mantenimiento del sistema
Implementacin y evaluacin del sistema.
45
1.- Identificacin de problemas, oportunidades

y objetivos
El analista tiene que ver con la identificacin
de problemas, oportunidades y objetivos.

Esta etapa es crtica para el xito del resto
de proyecto, debido a que nadie quiere
desperdiciar
el
tiempo
subsecuente
resolviendo el problema equivocado.
Esta fase requiere que el analista observe
honestamente lo que est sucediendo en un
negocio. Luego, junto con los dems
miembros de la organizacin, el analista
hace
resaltar
los
problemas.
Frecuentemente estos ya han sido vistos por
los dems, y son la razn por la cual el
analista fue llamado inicialmente.
46
Las personas involucradas en la
primera fase son los usuarios,

analistas y administradores de
sistemas que coordinan el proyecto.
Las actividades de esta fase
consisten en entrevistas a los
administradores de los usuarios,
estimacin del alcance del proyecto
y documentacin de los resultados.
La salida de esta fase es un estudio
de factibilidad que contiene una
definicin del problema y la
definicin de los objetivos.
Luego los administradores deben
tomar una decisin para ver si
continan con el proyecto propuesto.
47
2.- Determinacin de los requerimientos de

informacin.
En esta fase el analista est esforzndose
por comprender
qu informacin necesitan los usuarios para realizar
su trabajo.
Esta fase sirve para formar la imagen que el analista tiene
de la organizacin y sus objetivos.
Las herramientas que se utilizan son: muestreo e
investigacin
de
datos
relevantes,
entrevistas,
cuestionarios en las que se interacta directamente con el
usuario.
El analista de sistemas necesita saber los detalles de las
funciones actuales del sistema: quin (las personas que
estn involucradas), qu (la actividad del negocio), dnde
( el ambiente donde se lleva a cabo el trabajo), cundo (en
que momento) y cmo (de que manera se desarrollan los
procedimientos actuales)
48
3.- Anlisis de las necesidades

del
Para sistema
el anlisis de las necesidades del
sistema utilizamos la herramienta de
diagramas de flujo de datos para
diagramar la entrada, proceso y salida de
las funciones del negocio en forma grafica y
estructurada.
A partir de los diagramas de flujo de datos
se desarrolla un diccionario de datos, que
lista todos los conceptos de datos usados
en
el
sistema,
as
como
sus
especificaciones.
En este punto el analista prepara una
propuesta del sistema que sintetiza lo que
ha encontrado, proporciona anlisis de
costo/beneficio de las alternativas y hace
recomendaciones
49
4.- Diseo del sistema

El analista usa la informacin recolectada
recomendado
diseo lgico del sistema de informacin.
para realizar el
Disea procedimientos precisos para la captura de datos
correctos, tambin se disea la interfaz de usuario.

La interfaz conecta al usuario con el sistema y es por lo tanto
muy importante.
Esta fase tambin incluye el diseo de archivos o bases de
datos que guardaran la mayor parte de los datos necesarios
para los tomadores de decisiones de la organizacin.
Tambin se disea las salidas (ya sea en pantalla o impresora).
Por ultimo el analista debe disear procedimientos de control
y respaldo para proteger al sistema y a los datos
50
5.- Desarrollo y documentacin del

software
El analista trabaja con los programadores para
desarrollar el software.
Algunas tcnicas para comunicar al programador
incluyen diagramas estructurados, diagramas de
flujo, seudocdigo etc.
El analista trabaja con los usuarios para desarrollar
documentacin efectiva para el software,
incluyendo manuales de procedimientos.
La documentacin le dice al usuario la manera de
usar el software y tambin que hacer si suceden
problemas con el software
51
6.- Pruebas y mantenimiento

del sistema
Antes de que pueda ser usado, el sistema de
informacin debe ser probado.

Es mucho menos costoso encontrar problemas antes
de que el sistema sea entregado a los usuarios.
Algunas
pruebas
son
realizadas
por
los
programadores solos, y otras por los analistas junto
con los programadores.
El
mantenimiento
del
sistema
y
de
su
documentacin comienzan en esta fase y
es
efectuado rutinariamente a lo largo de la vida del
sistema de informacin.
52
7.- Implementacin y evaluacin

del sistema
El analista ayuda a implementar el anlisis de
informacin, esto incluye el entrenamiento

de los usuarios para que manejen el
sistema.
Adicionalmente el analista necesita un plan
para una conversin suave del sistema
antiguo al nuevo.
53
La importancia del
mantenimiento
Despus de que el sistema est instalado se le debe dar
mantenimiento, esto significa que los programas de

computadora deben ser modificados, mantenidos y
actualizados.
El mantenimiento se realiza por dos razones.

La primera de estas es para corregir errores de software.
La otra razn es para mejorar la capacidad del software en
respuesta a las necesidades organizacionales cambiantes y
por lo general involucran las siguientes situaciones:
1.
2.
3.
Los
usuarios
frecuentemente
solicitan
caractersticas
adicionales despus de que se familiarizan con el sistema de
computo y sus capacidades.
El negocio cambia a travs del tiempo.
El software y hardware estn cambiando a un ritmo acelerado.
54
Modelos (Metodologas) de Proceso del

Software
1. Modelo Lineal Secuencial (ciclo de vida
clsico
en cascada)
modelo
Es el modelo ms antiguo.
Se divide en etapas formales.
Se usa para construir sistemas complejos
grandes que exige un anlisis de requerimientos

Riguroso y formal, adems de controles estrictos.
Puede ser costoso, lento e inflexible.
No es conveniente para pequeos sistemas de
escritorio.
55
Sus etapas son:

Anlisis (requisitos, comprender el dominio de informacin
del software, la funcin requerida, comportamiento,

rendimiento e interconexin.)
Diseo (se centra en: estructura de datos, arquitectura de
software, representaciones de interfaz y detalle
procedimental (algoritmo).
El proceso del diseo traduce requisitos en una
representacin del software donde se pueda evaluar su
calidad antes de que comience la codificacin.)
Cdigo (el diseo se debe traducir en una forma legible por
la mquina).
Prueba (realizar las pruebas para la deteccin de errores).
56
Algunos problemas que se encuentran en este modelo son:

Los proyectos reales raras veces siguen el modelo
secuencial que propone el modelo. Como resultado, los

cambios pueden causar confusin cuando el equipo del
proyecto comienza.
A menudo es difcil que el cliente exponga explcitamente
todos los requisitos. El modelo lineal secuencial lo requiere y
tiene dificultades a la hora de acomodar la incertidumbre
natural al comienzo de muchos proyectos.
El cliente debe tener paciencia. Una versin de trabajo del
(los) programa(s) no estar disponible hasta que el proyecto
est muy avanzado. Un grave error puede ser desastroso si
no se detecta hasta que se revisa el programa.
57
2. El Modelo de Construccin de Prototipos

Consiste en construir rpida y econmicamente
un sistema experimental para que lo evalen

los usuarios finales.
Interactuando con el prototipo, los usuarios
pueden darse una mejor idea de sus requerimientos
de informacin.
El prototipo sirve de modelo preliminar.
Al proceso de construir el diseo preliminar,
probarlo, refinarlo y probarlo de nuevo,
se llama proceso iterativo.
Cada versin, refleja con ms precisin los
requerimientos de los usuarios
58
En la mayora de los proyectos, el primer sistema construido
apenas se puede utilizar.

Puede ser demasiado lento, demasiado grande o torpe en su
uso, o las tres a la vez.
No hay otra alternativa que comenzar de nuevo, aunque nos
duela pero es ms inteligente, y construir una versin
rediseada en la que se resuelvan estos problemas
Cuando se utiliza un concepto nuevo de sistema o una
tecnologa nueva, se tiene que construir un sistema que no
sirva y se tenga que tirar, porque incluso la mejor
planificacin no es eficiente como para que est perfecta la
primera vez.
Por lo tanto la pregunta de la gestin no es si construir un
sistema piloto y tirarlo. Tendremos que hacerlo. La nica
pregunta es si planificar de antemano construir un
desechable, o prometer entregrselo a los clientes.
59
3. El Modelo DRA
60
Utiliza una construccin basada en componentes

Los inconvenientes que presenta son:
Para proyectos grandes aunque por escalas, se requiere
recursos humanos suficientes como para crear el nmero

correcto de equipos.
Si no hay compromiso por ninguna de las partes constituyentes,
los proyectos fracasarn.
No todos los tipos de aplicaciones son apropiados. Si un sistema
no se puede modularizar, la construccin de los componentes
necesarios ser problemtico.
DRA no es adecuado cuando los riesgos tcnicos son altos.
61
Modelos Evolutivos (Iterativos)de

Proceso del Software
1.- El Modelo Incremental
62
2.- El Modelo Espiral
63
3.-Proceso Unificado de Desarrollo de

Software
(PUDS)
Utiliza el lenguaje Unificado de modelado (Unified Modeling

Language - UML), para representar todos los esquemas
necesarios en las distintas fases del desarrollo de software.
Dirigido por casos de uso, centrado en la arquitectura,
iterativo e incremental.
Un proceso de desarrollo de software es el conjunto de
actividades necesarias para transformar los requisitos de un
usuario en un sistema de software.
Requisito
s
del
usuario
Proceso de
desarrollo de
Software
Sistema
de
Software
64
El proceso unificado es un marco de trabajo
genrico que puede especializarse para una

gran variedad de sistemas software.
El proceso unificado est basado en
componentes, lo cual quiere decir que el
sistema de software en construccin est
formado por componentes de software
interconectados a travs de interfaces bien
definidas.
65
Se organiza en cuatro fases:

FASE DE INICIO: Es la etapa de concepcin y
entendimiento del problema.

FASE DE ELABORACIN: Es la etapa de diseo,
diagramacin y estructuracin del Sistema.
FASE DE CONSTRUCCIN: Es la etapa de
implementacin y pruebas del Sistema.
FASE DE TRANSICIN: Es la etapa de cambio de
hito o de cumplimiento de los objetivos por
iteracin.
66
UML (Unified Modeling

Languaje)
EL lenguaje Unificado de modelado es un
lenguaje grfico para la especificacin,

visualizacin, construccin y documentacin
de piezas de informacin usadas o producidas
durante el proceso de desarrollo de software.
A estas piezas de
informacin se les
conoce como
Artefactos
67
Permite la construccin de distintos modelos

Diagramas de clases, de casos de uso etc.
Es auto descriptivo porque puede expresarse por medio
de un diagrama de clases de UML
Utiliza bloques de construccin

Elementos :
Bloques bsicos
Relaciones :
Enlazan los elementos
Diagramas :
Agrupan colecciones de elementos
relacionados aportando un significado
68
Beneficios aportados por el UML

Provee a los desarrolladores un lenguaje de
modelamiento visual listo para utilizar.

Consolida un conjunto de conceptos que son
generalmente aceptados por muchos mtodos
y herramientas de modelado y necesarios en
aplicaciones.
Es independiente de los lenguajes de
programacin y de mtodos de proceso de
desarrollo de software.
69
UML : Diagramas
Ofrecen distintas perspectivas de una
abstraccin de la realidad
Un mismo elemento puede aparecer en
distintos diagramas
DINAMICOS:
(COMPORTAMIENTO)
Diagrama de Casos de Uso

Diagrama de Secuencia
ESTATICOS: (ESTRUCTURA)
Diagrama de Clases
Diagrama de Objetos
Diagrama de Colaboracin
Diagrama de
Componentes
Diagrama de Estados
Diagrama de Despliegue
Diagrama de Actividades
70
Diagramas Dinmicos del UML
71
Diagramas Estticos del UML
72
Trabajo Grupal
Describa a la empresa en la cual realizar su
Sistema de Informacin (Denominacin,

direccin, rubro, misin, visin).
19/10/16
73

Sesion 1 SI-II

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Sesion 1 SI-II

Enviado por

Direitos autorais:

Formatos disponíveis

Ingeniera Informtica-UNSAAC

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

Un SI se puede definir como un

Ing. Maritza Irpanocca Cusimayta

b) Componentes de los Sistemas de

Ing. Maritza Irpanocca Cusimayta

Sistemas para administrativos

c.1) Sistemas de Informacin

Ing. Maritza Irpanocca Cusimayta

c.2) Sistema de Soporte a Toma de

Ing. Maritza Irpanocca Cusimayta

c.3) Sistemas Estratgicos

informacin interna y externa al negocio

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

trabajan en comn, en el cumplimiento de

Ing. Maritza Irpanocca Cusimayta

El analista debe ser capaz de trabajar con

personas de todas las descripciones y debe

EL ANALISTA DE SISTEMAS COMO EXPERTO

EL ANALISTA DE SISTEMAS COMO AGENTE

Ing. Maritza Irpanocca Cusimayta

Cul es el producto obtenido?

Desde el punto de vista de

los usuarios el producto

Ing. Maritza Irpanocca Cusimayta

a) El Software se desarrolla, no se fabrica en un sentido clsico.

construccin del hardware, ambas actividades son

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

c) Aunque la industria tiende a ensamblar

implementarse para que pueda volver a ser

Ing. Maritza Irpanocca Cusimayta

Mitos del Software

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

Ing. Maritza Irpanocca Cusimayta

Cules son los pasos?

Ing. Maritza Irpanocca Cusimayta

Cul es el producto obtenido?

Ing. Maritza Irpanocca Cusimayta

Cmo puedo estar seguro de que lo he

Ing. Maritza Irpanocca Cusimayta

La Ingeniera del software es un tecnologa

Una visin general de la

Cul es el problema a resolver?

para resolver el problema?

El trabajo que se asocia a la ingeniera del software se puede

rendimiento, interfaces, restricciones y criterios de validacin).

Ing. Maritza Irpanocca Cusimayta

Existen diversas actividades protectoras: