Se adjuntan un esquema sobre elementos de un sistema de información, además de los procesos del ciclo de vida de software - Curso Desarrollo de software

1. ELEMENTOS DE UN
SISTEMA DE INFORMACIÓN
ESTRUCTURA DE UN Es de una manera simple, tener en orden los
SISTEMA DE subsistemas. Esta se estructura por niveles
INFORMACIÓN
NIVELES
Es el proceso de las
PRIMERO:
actividades diarias o
OPERACIONES Y
TRANSACCIONES rutinarias de una
organización
Permite el análisis de
SEGUNDO:
EL resultados para la toma de
OPERATIVO decisiones a corto plazo y
de consecuencias limitadas.
TERCERO: Realiza el análisis de
EL resultados para la toma de
TÁCTICO decisiones a medio plazo
Con ella se utiliza la
CUARTO: EL
ESTRATÉGICO información para decidir
las líneas maestras de la
organización a largo plazo

2. Gracias a los sistemas de
TIPOS SISTEMA DE información,perfeccionan las
INFORMACIÓN actividades llevadas a cabo en una
organización para alcanzar ventajas
competitivas. Esta se organiza por
tipos
TIPOS
SISTEMA DE Tiene como fin mejorar las
OPERACIONES Y actividades rutinarias de
TRANSACCIONES una empresa u organización
TIPOS DE
TRANSACCION
ES
Entran al sistema a medida que llegan y
ITERATIVAS
su respuesta es inmediata
Se reúne por grupos antes de entrar al
POR LOTES sistema y su respuesta no es inmediata
SISTEMA DE Dan soporte a los trabajadores que usan la
AUTOMATIZACIÓN información para transformarla y repartirla
DE OFICINA totalmente en la organización o fuera de ella
SISTEMA DE Permite el conocimiento a personas como: científicos,
MANEJO DE ingenieros, arquitectos o personal que opere con el
CONOCIMIENTO conocimiento para crear uno nuevo

3. SISTEMA DE
INFORMACIÓN Proporciona información que será empleada en los
ADMINISTRATIVA O procesos administrativos de decisión para solucionar
GERENCIAL problemas empresariales
SISTEMA DE Provee de información a los directivos que han de
APOYO DE tomar decisiones sobre situaciones particulares,
DECISIONES además para circunstancias no muy estructuradas.
SISTEMA DE APOYO
Ayuda a grupos de trabajadores a tomar
DE DECISIONES DE
GRUPO decisiones semi-estructuradas o no estructuradas
SISTEMA DE
La información dada es evaluada y analizada por ejecutivos, para la
PLANIFICACIÓN
ESTRATÉGICA misión de la organización. Se aplican en áreas específicas como CRM
(costumerrelationship Management), análisis de competitividad y
detección de fraudes
INTELIGENCIA Es el conjunto de procesos, técnicas y herramientas de ayuda a las
DE NEGOCIOS decisiones de negocios basadas en tecnología de la información.
Son los pasos que se deben seguir
PASOS
para la correcta toma de decisiones
PRIMER PASO:
Es el origen de los datos para la utilización de la
FUNTES DE
DATOS empresa
SEGUNDO PASO: Es una colección de datos orientada a un determinado
DATA
ámbito (empresa, organización, etc.), integrado, no
WAREHOUSE
volátil y variable en el tiempo, que ayuda a la toma de
decisiones en la entidad en la que se utiliza
TERCER PASO:
Permite buscar los datos que se
EXPLORACIÓN DE
DATOS necesitan en una datawarehouse

4. CUARTO PASO:
MINERÍA DE Es el proceso que intenta descubrir patrones en
DATOS grandes volúmenes de conjunto de datos para
extraer esa información y transformarla a una
estructura comprensible para su uso posterior
QUINTO PASO: Se presentan los datos a los
PRESENTACIÓN directivos de la empresa una
DE DATOS
vez completado el cuarto paso
SEXTO PASO: Los directivos toman una decisión definitiva para
DECISIÓN el mejoramiento de la empresa basado en la
información que se obtuvo del sistema
PRINCIPIOS GENERALES El estudio de las características comunes de los
DE UN SISTEMA sistemas se conoce como teoría de sistemas. Un
sistema se divide en subsistemas.
Hay 4 principios de sistemas
PRINCIPIOS DE
SISTEMAS
Cuanto más especializado sea un sistema menos
capaz es de adaptarse a circunstancias diferentes
Cuanto mayor sea el sistema, mayor es el número de
recursos que deben dedicarse a su mantenimiento
Los sistemas siempre forman parte de sistemas mayores
y siempre puede dividirse en sistemas menores
Los sistemas crecen

5. Se abarcan aspectos que nos ayudan a especificar,
diseñar, implementar, validar, distribuir y mantener
sistemas uniendo diversas partes de información para
INGENIERÍA DE formar un todo.
SISTEMAS
Al tener relación con un sistema, es necesario tener en
consideración aspectos importantes como lo es el
hardware o parte física, el software o parte lógica,
como también las interacciones que los usuarios tiene
con el sistema, y el entorno donde se utilizará dicho
FASES sistema.
DEFINICIÓN DE
REQUISITOS
Se incluyen propiedades funcionales que son difíciles de
comprender (abstractas) donde se tienen puntos de vista
generales.
Posterior se deben tener las propiedades del sistema,
donde poder encontrar atributos para el buen manejo de
nuestro sistema de tal manera que la información sea
utilizada de manera útil.
Se debe considerar las características que el sistema no
debe mostrar, en la mayoría de los casos es conveniente
utilizarlo como medio de seguridad de la información,
evitando problemas al proteger los datos.

6. DISEÑO
La división de requisitos se debe llevar a cabo ya que es
un proceso donde ramificamos, como por ejemplo: 1.- los
funcionales que son aquellos requisitos que el usuario
necesita que el software efectúe, como por ejemplo el
realizar una factura. 2.- No funcionales que son los
recursos para que el sistema trabaje de manera segura. 3.-
Empresariales, útil para la toma de decisiones.
Mediante la identificación de subsistemas se puede
obtener un diseño concreto de como poder trabajar el
sistema en sí, porque se conoce cada parte del
funcionamiento de un proceso.
Al tener subsistemas definidos es característico asignar
requisitos a los subsistemasporque de esta manera
vamos restringiendo o permitiendo control de procesos
pequeños y de esta manera tener un sistema con una
buena jerarquía.
Para poder comprender lo que un subsistema realiza es
necesario Especificar su funcionalidad, algo parecido a
una documentación para tener la certeza de donde
realizar modificaciones o reparaciones en momentos de
desperfectos de subsistemas.
Posteriormente se deben definir las interfaces del
sistema, una interfaz es una superficie de contacto, por
tanto al realizar este proceso distinguimos la forma en que
nuestro sistema funcionará, por ejemplo una interfaz
entre dos dispositivos, que nos servirá para enlazar una
comunicación entre ellos compartiendo información.

7. DESARROLLO DE LOS SUBSITEMAS
Para la implementación de los subsistemas se necesita
detallar exhaustivamente la forma en que trabajaran,
estudiando de manera concisa como trabajan. Para tal
caso se hace necesario utilizar procesos de ingeniería
como diseño, implementación, etc.
Cuando cada subsistema debe desarrollarse como parte
del proceso de cada usuario se realiza la Adquisición del
sistema,o comúnmente llamado COTS, que es un
comercial fuera de alguna plataforma, el cual debe de ser
llenado como un requisito.
INTEGRACIÓN DEL SISTEMA
La integración Big Bang, es cuando combinamos todos los
componentes, probando el sistema como un todo, aunque
realizando este proceso puede ser muy tedioso, debido a
que si aparecen muchos errores, será difícil encontrar en
que parte del sistema se encuentran.
La integración creciente o incremental, es muy útil a
diferencia del bigbang, debido a que con este proceso se
lleva un estudio de segmentos de un programa de tal
manera que cuando se encuentren errores, estos sean
aislados y corregidos de una mejor manera, probando así
todos sus componentes e interfaces.
INSTALACIÓN DEL SISTEMA
Es cuando ubicamos el sistema en el lugar donde realizará
operaciones, normalmente en equipos donde acepte
desarrollarse eficazmente, cumpliendo los requisitos de
los usuarios.

8. EVOLUCIÓN
Una de las fases ventajosas de un sistema, ya que con ello
se puede corregir errores que estén interfiriendo en el
buen funcionamiento del sistema, como también
introducir nuevos requisitos que servirán para mejorar el
sistema.
DESMANTELAMIENTO
En algunas ocasiones se hace necesario desechar el
sistema completo, en otras palabras poner el sistema
fuera de servicio, destruyendo todo lo creado, en
ocasiones para mejorar un servicio que no estaba
funcionando de manera correcta.
Antes de realizar alguna adquisición de algún sistema es
ADQUISICIÓN DEL necesario tener en cuenta, las especificaciones de alto nivel
SISTEMA
que indique que es lo que debe hacer el sistema. Además se
deben verificar todos los aspectos arquitectónicos para saber
que partes del sistema se pueden comprar, y cuales requieren
desarrollo.
Existen sistemas grandes y complejos que requieren que haya
sistemas creados que cumplan con los requisitos de la
empresa, como también partes del sistema que se tienen que
crear para terminar de cumplir los requisitos necesarios para
que el sistema completo funcione de manera perfecta a los
requerimientos de los usuarios.
FORMAS DE ADQUISICIÓN
Esta forma se da cuando los sistemas comerciales ya hechos
satisfacen los requisitos de la empresa, cuando no es necesario
COMPRAR COMO UN TODO
el desarrollo de un sistema, aunque esto conlleve seleccionar
proveedores, para poder elegir un sistema.

9. Cuando se selecciona este tipo de adquisición se deben tener
PARTES SEPARADAS QUE las consideraciones necesarias, debido a que se deben lograr
DEBEN INTEGRARSE cubrir todos los requerimientos de la empresa, y cuando se
integren las partes compradas y desarrolladas la funcionalidad,
cumpla con los requisitos que los clientes pidan.
Tipo de adquisición utilizado cuando ningún otro subsistema
del mercado cumple con los requisitos de un sistema completo
SISTEMA DISEÑADO Y
y por lo tanto deben de crearse y desarrollarse los sistemas
DESARROLLADO
desde lo más mínimo hasta lo más complejo para poder
satisfacer las necesidades del cliente.

10. PROCESOS DEL CICLO DE
VIDA
Ciclo de Vida del Software: Modelo del Ciclo de Vida: En él se
Aproximación lógica a la incluyen aspectos como el proceso,
adquisición, el suministro, el las actividades y las tareas que se
desarrollo, la explotación y el involucran en el sistema, mostrado
mantenimiento del software como un marco de referencia.
Este tipo de proceso es útil para las personas
que realizan el desarrollo del software
PROCESOS durante su ciclo de vida, sirviendo de gran
PRINCIPALES relevancia al momento de darle
mantenimiento o explotar el sistema
PROCESO DE En este subproceso se llevan a cabo todas
las actividades y todas las tareas necesarias
ADQUISICIÓN para poder comprar un producto software.
PROCESO DE Son actividades que se realiza para poder proveer algo
a alguien que lo requiera, en este caso el sistema,
SUMINISTRO actividad realizada por el suministrador
PROCESO DE Proceso importante porque con esto se tiene
que cumplir los requisitos, realizando diseño,
DESARROLLO codificación, pruebas e instalación.
PROCESO DE Se llevan a cabo exploraciones integras del sistema buscando
toda la utilidad posible de los procesos que genera el sistema,
EXPLOTACIÓN como también darle soporte operativo a los usuarios para que
apliquen de buena forma el sistema.
PROCESO DE Este tipo de subproceso no siempre está presente en el
funcionamiento cotidiano del software. Aparece cuando se hace
MANTENIMIENTO necesario su implementación como para modificar el software con
motivo de algún error, o simplemente para modificar la
documentación del mismo, de la misma manera su utilización se
hace compleja al momento de realizar una mejora en el sistema.

11. PROCESO DE Sirve como apoyo al resto del sistema y es
aplicado a cualquier punto del ciclo de vida
SOPORTE cuando el sistema lo requiera.
PROCESO DE En este subproceso de soporte se lleva a cabo un
registro de información de los procesos producidos
DOCUMENTACIÓN o cuando se da una actividad del ciclo de vida.
PROCESO DE GESTIÓN Se Aplican procedimientos y técnicas que aplican al
desarrollo del sistema durante todo el ciclo de vida del
DE LA CONFIGURACIÓN mismo.
Con este proceso aseguramos la calidad, la confianza de
PROCESO DE ASEGURAMIENTO que los procesos y producto software cumplan con los
DE LA CALIDAD requisitos especificados y se ajustan a los planes que se
establecen.
PROCESO DE Proceso útil, porque nos ayuda a realizar un muestreo para ver si
los requisitos del sistema o los procesos del mismo están
VERIFICACIÓN completos y están correctos.
Proceso para determinar si un sistema o el software final cumplen
PROCESO DE con los requisitos para poder ser utilizado, teniendo la certeza de
VALIDACIÓN que ya no posea errores y sea de calidad para el usuario en
cuando a su desempeño
PROCESO DE Se evalúa el estado del software y de sus productos para
verificación y certeza de su funcionamiento como proceso del ciclo
REVISIÓN CONJUNTA de vida o como una fase de proyecto.
Es parecido a un control de procesos, ya que con esto se
PROCESO DE determina si los requisitos se han cumplido, como también si los
AUDITORÍA planes o el contrato mantengan sus especificaciones finales
hechas de buena forma.
PROCESO DE Proceso útil, ya que con esto podemos analizar y
consecuentemente eliminar los problemas que se descubren
RESOLUCIÓN DE
durante el desarrollo, la explotación o el mantenimiento del
PROBLEMAS software.

12. PROCESO DE LA Proceso realizado por la organización para realizar
funciones como la dirección, el orden, la
ORGANIZACIÓN organización, la formación del personal o la mejora
(GENERALES) de algún proceso.
PROCESO DE Actividad que realiza una organización con el fin de
poder controlar, planificar, revisar, para poder tener
GESTIÓN una buena dirección y orden de sus procesos.
Conjunto de elementos y servicios necesarios para
PROCESO DE poder tener todo en buen funcionamiento y tener
INFRAESTRUCTURA preparado todo para poder generar otros elementos
necesarios para su utilización posterior.
Proceso interesante porque con esto podemos
PROCESO DE perfeccionar algo que ya hemos realizado, realizando
MEJORA valoraciones, mediciones y un control específico de
procesos para tener todo en orden.
PROCESO DE Con esto parte del proceso organizacional logramos a que el
personal mantenga un orden específico que cumpla con los
FORMACIÓN requerimientos de la empresa.
Para llevar a cabo esta parte del ciclo de vida es
PROCESO DE necesario conocer los procesos, las organizaciones
ADAPTACIÓN y las relaciones que estos contengan bajo diferentes
puntos de vista.
El comprador y el proveedor de software firman un
BAJO EL PUNTO DE VISTA DE CONTRATO contrato, empleando los procesos necesarios para
la adquisición del software.
Toda la organización gestiona sus procesos para
BAJO EL PUNTO DE VISTA DE GESTIÓN
el respectivo software, como por ejemplo los
requerimientos del comprador.
BAJO EL PUNTO DE VISTA DE EXPLOTACIÓN El técnico proporciona el servicio de explotación
del software a los usuarios del mismo.
Se llevan a cabo modificaciones del software,
BAJO EL PUNTO DE VISTA DE INGENIERÍA
realizando tareas específicas de planificación y
diseño, como de mantenimiento.
Proporciona ayuda o apoyo para las tareas
BAJO EL PUNTO DE VISTA DE SOPORTE
únicas y específicas, y que se cumplan de
acuerdo a los requisitos.

13. MODELO DE PROCESOS
Debe ser algo entendible. Esto puede dar la
oportunidad de organizar y documentar la
información sobre un sistema.
MODELOS Formado por fases donde la naturaleza
TRADICIONALES del software no es tomado en cuenta.
CLASICO, LINEAL O EN CASCADA
ESTRUCTURADO
BASADO EN PROTOTIPOS
DESARROLLO RÁPIDO DE APLICACIONES RAD
MODELOS Modelo que se adapta a la evolución de los
EVOLUTIVOS requisitos del sistema de acuerdo al tiempo
EN ESPIRAL
EVOLUTIVO
INCREMENTAL
MODELO DE DESARROLLO CONCURRENTE
MODELOS ORIENTADOS Una de las principales técnicas para aumentar la
A LA REUTILIZACIÓN productividad, utilizado para mejorar la eficiencia y la
calidad del software
BASADO EN COMPONENTES
PROCESO UNIFICADO

14. MODELOS PARA SISTEMAS Posee un alto grado de ser repetido y ocultar
ORIENTADOS A OBJETOS cosas con otras en su totalidad
DE AGRUPAMIENTO
FUENTE
BASADO EN COMPONENTES
PROCESO UNIFICADO
Es un proceso que se repite y es incremental
PROCESOS ÁGILES donde los requerimientos y soluciones
evolucionan.
PROGRAMACIÓN EXTREMA XP
DESARROLLO DE SOFTWARE ADAPTIVO
KANBAN
CRYSTAL CLEAR
SCRUM
MÉTODO DE DESARROLLLO DE SISTEMAS DINÁMICOS

15. MODELOS CARACTERISTICAS VENTAJAS DESVENTAJAS
 Es sencillo y fácil  Sencillo.  Un error
de entender. grave
 Aplicable detectado en
 Este modelo está cuando es un la última fase
MODELO compuesto por una problema puede ser
CLASICO serie de pasos estable y se letal.
secuenciales. trabaja con
técnicas  Inestabilidad
 Para poder pasar a conocidas. de los
la siguiente fase se requisitos no
tiene que haber se ve un
conseguido todos producto
los objetivos de la hasta muy
fase anterior. tarde en el
proceso.
 Las revisiones
de proyectos
de gran
complejidad
son muy
difíciles.
 La participación  Aparece un  El cliente no
directa del cliente diseño rápido entiende
en la construcción centrado en porque hay
del software los aspectos que desechar
requerido.  Visibles para el prototipo.
el cliente.
 Tras recoger los  Riesgos de
requisitos tanto del  Permite software de
MODELO cliente como del identificar los mala calidad:
ITERARIVOS sistema, se requisitos Utilizar un SO
BASADOS EN comienza con el incrementalm o lenguaje de
PROTOTIPOS diseño rápido del ente. programación
prototipo. inadecuado
 Permite pero
 Prototipo de probar conocido.
evolutivo: el alternativas a
prototipo inicial se los
refina desarrollador
progresivamente es.
hasta convertirse
en versión final.  Tiene una
alta

16.  Prototipo visibilidad,
desechable: De tanto para
cada prototipo se clientes y
extraen ideas para los
buenas que se desarrollador
usan para hacer el es ven
siguiente, pero resultados
cada prototipo se rápidamente.
tira entero.
 El prototipo evalúa
el cliente y lo utiliza
para refinar los
requisitos.
 Se desarrolla una  Es  El proceso no
implementación interactivo: es visible.
inicial y se refina a Con cada
través de incremento  Los cambios
MODELOS diferentes se entrega al tienden a
EVOLUTIVOS versiones. cliente un corromper la
producto estructura del
 Las actividades de operacional software.
especificación, al cliente, que
desarrollo y puede  La primera
validación se llevan evaluarlo. iteración
a cabo puede
concurrentemente  Personal: plantear los
y con Permite mismos
realimentación variar el problemas.
entre ellas. personal
asignado a
 La especificación cada
se puede iteración.
desarrollar de
forma creciente.
 Son iterativos

17.  Tratar primero las
áreas de mayor  Enfoque realista  Convencer
riesgo. gestión explícita cliente
de riesgos enfoque
 Múltiples iteraciones centra su controlable.
sobre varias regiones atención en la
de tareas. reutilización n  Requiere de
en la experiencia en
 Vuelta a la espiral: reutilización de la
ciclo N Número de componentes y identificación
iteraciones eliminación de de riesgos.
MODELO EN predeterminadas o errores en
ESPERIA calculadas. información  Requiere
descubierta en refinamiento
 Se pueden variar las fases iniciales. para uso
actividades de generalizado.
desarrollo: Familia de  Los objetivos de
modelos de calidad son el
procesos. primer objetivo
Integra
 El modelo en espiral desarrollo con
es bastante mantenimiento
adecuado para la
gestión de riesgos
ƒSe puede añadir
una actividad de
gestión de riesgos
 Exige conocer
 Desarrollo de  Rapidez bien los
sistemas en poco requisitos y
tiempo la  Válido para delimitar el
adaptación a “alta aplicaciones ámbito del
velocidad”la modularizables. proyecto.
cascada de Equipos
MODELO trabajando en  N Número de
DESARROLLO paralelo Aplicando personas.
RAPIDO DE tecnología de
APLICACIONES componentes.  Clientes y
desarrolladores
comprometidos.
 Gestión de
riesgos técnicos
altos uso de
nueva
tecnología, alto
grado de
interoperabilidad

18. con sistemas
existentes.
 Configura  Cualificación  Las unidades
aplicaciones a partir de software
de componentes de componentes. reutilizables
software pueden ser de
preparados.  Adaptación de diferente
MODELO componentes. tamaño.
ORIENTADOS A  Se enmarca en un
LA contexto más  Elimina
REUTILIZACION amplio: ingeniería conflictos de
del software basada integración
en componentes enmascarami
ento de caja
blanca, gris o
negra.
 Composición
de
componentes:
Ensambla
componentes
cualificados,
adaptados y
diseñados
para la
arquitectura
establecida
 Ingeniería de
componentes
 Actualización
de
componente:
El software
actual se
reemplaza a
medida que
se dispone de
nuevas
versiones de
componentes.

19.  Eliminación de las  Adaptación de  Podríamos
fronteras entre componentes: decir que en
fases elimina nuestra
conflictos de investigación
 Desarrollo basado integración no hemos
en componentes encontrado
reutilizables  Enmascarami desventajas
ento de caja sobre el
 Desarrollo iterativo blanca, gris o análisis
e incremental negra. orientado a
objetos, y si
 Existe un ciclo de  Composición las hay son
desarrollo que de pocas.
permite la evolución componentes:
del sistema ensambla  Quizás una de
componentes ellas sea que
 El sistema se divide cualificados, a la hora de
MODELO PARA en un conjunto de adaptados y realizar el
SISTEMAS particiones que se diseñados análisis y los
ORIENTADOS A van para la requerimientos
OBJETOS arquitectura , se torna un
 Desarrollando e establecida. poco
integrando de forma complicado o
incremental  Ingeniería de difícil según lo
componentes: cita el autor.
 Se pueden diseño de
combinar con componentes
modelos para su
tradicionales. reutilización.
 Diferenciación de la  Actualización
experiencia en de
Objetos y Atributos componentes:
el software
 Distinción entre el actual se
todo y sus partes reemplazan a
medida que
 Formación y se dispone de
distinción de clases nuevas
de objetos. versiones de
componentes.

20.  Menor énfasis
El juego de la planificación en el análisis,  Incremental.
diseño y
- Versiones pequeñas documentació  Entregas
- Programación en parejas n pequeñas de
- Propiedad colectiva software, con
- Diseño sencillo  Equipos ciclos rápidos
- Hacer pruebas pequeños
MODELO - Integración continua  Desarrollo
POCESOS incremental
AGILES
 Programación
(planificación
temporal) en
cajas de
tiempo
 Supervivencia
en un entorno
caótico.
 Las características  Diseño  Confluencia de
de sistemas y arquitectónico disciplinas:
aplicaciones sistemas de
basados en Web  Diseño de la información
influye navegación ingeniería de
enormemente en el Diseño de la software y
MODELOS DE proceso de interfaz diseño gráfico
PROCESOS DE Ingeniería Web. que requiere
LA INGENIERIA  Pruebas de equipos
WEB  Intensivas de red las multidisciplinar
controladas por aplicaciones es y
contenido Web. polivalentes.
 Evolución continua  Cambio
necesidad de
 Inmediatez Estética. soluciones que
permita
flexibilidad i
adaptación
conforme el
proyecto
cambia.
 Requisitos
fuertes de
seguridad,rend
imiento,
usabilidad.