1.

Desarrollo y construcción de sistemas de información

2.Los participantes
3.El proceso: el ciclo de vida del sistema de información
◦ Análisis
◦ Diseño de sistemas: la arquitectura
◦ Construcción
◦ Implantación o puesta en marcha
◦ Mantenimiento
4. Enfoques y metodologías clásicas para el desarrollo de sistemas de información
◦ Enfoque clásico: el ciclo de vida en cascada
◦ Enfoque estructurado: el desarrollo basado en prototipos
5. Enfoques modernos basados en el desarrollo de software.
◦ La programación orientada a objetos y los sistemas hipermedia
◦ Las metodologías Agile
6. La estandarización de las metodologías: La ISO/IEC 12207 Métrica y Magerit
7. La gestión económica del proceso: el análisis coste-beneficio y el análisis de riesgos.
8. Buenas prácticas en la provisión y gestión de TI: ISO/IEC 20000 e ITIL
9. La Web semántica, los datos abiertos y su calidad.
◦ LOD y las cinco estrellas de Tim Berners-Lee.
◦ La métrica MELODA.

Factores que hacen que las empresas se planteen la creación de
nuevos SI:
◦ Los actuales sistemas no se justan a las necesidades, actuales o
nuevas. Aparece necesidades:

Mayor capacidad de transacción.

Comunicación con socios, clientes, proveedores.

Ahorro en costes.

Competir mejor en productos o servicios.

Adaptarse a nuevos requerimientos legales, etc.
◦ La tecnología permite aprovechar nuevas oportunidades, actualizando
los SI.
◦ Es necesario plantear un enfoque estructurado para solventar los
problemas que se pueden presentar al desarrollar o implementar nuevos
SI.
1. Desarrollo y construcción de SI

Factores que hacen que las empresas se planteen la creación de

nuevos SI:
• Los cambio tecnológicos (ordenadores, programas, sistemas de comunicación
móvil, etc.)provocan cambios en los procesos de tratamiento de los
información.
• Los entornos cambiantes en los que compiten las empresas, cambian sus
necesidades de información

La implantación de SI, a menudo, conlleva un cambio organizativo.
Hay que definir:
• Objetivos a conseguir, en función de la estrategia corporativa.
• Tamaño de la inversión a realizar.
• Resultados esperados.
• Medios internos y externos.
• Coordinar el desarrollo de los nuevos procesos con el funcionamiento normal
de los sistemas anteriores.

Hay que establecer un estrategia de SI.
PLANIFICACION ESTRATEGICA DE LOS SI

Constituye el mejor modo de explicitar la manera en la que los SI y las TIC van a
apoyar la estrategia de negocio.

Con la planificación estratégica de los SI:
◦ Se valorará la necesidad de nuevos desarrollos.
◦ Se plantearán los objetivos a conseguir con ellos.

Deberá ir acompañada de:
◦ Un análisis Coste-Beneficio.
◦ Análisis de riesgos a asumir.
Fases de Desarrollo de un SI
Fases o actividades Propósito
Análisis de factibilidad Evaluar las posibilidades, técnicas,
o estudio de viabilidad financieras y organizativas del
proyecto
ANÁLISIS
Análisis de Establecer el alcance, los objetivos y
requerimientos requisitos del sistema
Análisis funcional Especificación estructurada de lo que
debe hacer el sistema para dar una
solución a los requerimientos del
usuario
DISEÑO Obtener un conjunto de
especificaciones que contemplarán
como tiene que trabajar el sistema
CONSTRUCCIÓN Obtención del sistema completamente
construido y probado
Pruebas unitarias
Pruebas de Integración
PUESTA EN MARCHA o puesta en servicio del sistema y
IMPLANTACIÓN adaptación final por parte de los
usuarios (pruebas de aceptación)
MANTENIMIENTO Seguimiento del funcionamiento del
sistema, evaluación de actualizaciones
y cambios y apoyo a usuarios
Producto / Documento
Informe de Viabilidad
Documento de Requisitos del Sistema
Documento de Especificación Funcional del
Sistema
Documento de Pruebas del Sistema
Documento de Diseño Técnico
Documento de Pruebas del Sistema +
ampliaciones relativas a la definición del
entorno de pruebas
Software correspondiente
Documentación Técnica de Programación
Manual de usuario
Documento de Pruebas del Sistema +
informes de las pruebas unitarias, de
integración y globales.
Informe de evaluación
Colectivos que intervienen en la construcción de SI

1. LOS GESTORES DE SI
2. LOS USUARIOS
3. PERSONAL DE DESARROLLO (consultores)

Analistas

Diseñadores

Programadores y técnicos en general
Gestores (Directivos, genéricos y especialistas):
–La coordinación y dirección de recursos humanos aplicados al proyecto
–La aplicación de la legislación de protección y uso de datos
–El establecimiento de estrategias y metodologías de desarrollo
–La elaboración de presupuestos y control del coste del proyecto
–La toma de decisiones críticas frente a problemas derivados del proceso
–Informar a la alta dirección
–Asegurar la disponibilidad de recursos
–Asesorar sobre la organización
–Promover la participación activa del equipo humano
 Colectivos que intervienen en la construcción de SI
1. LOS GESTORES DE SI

Deben tomar un papel proactivo en el desarrollo del proyecto.

Deben tener conocimientos técnicos y de gestión.

Son responsables de elaborar la planificación y control de los sistemas a desarrollar.

Tomarán decisiones respecto a:
◦ Metodología a seguir.
◦ Arquitectura a utilizar en función de la disponibilidad.
◦ Aplicación de la legislación de protección y uso de datos.
◦ Aseguramiento de que todas las necesidades se han tenido en cuenta.
◦ Especificar presupuestos y controlar el coste del proyecto.
◦ Tomar decisiones críticas frente a problemas que surjan.
◦ Informar a la alta dirección.
 Colectivos que intervienen en la construcción de SI

2. LOS USUARIOS

Deben participar en el proceso como para asegurarse que se
mejoran las deficiencias de los sistemas anteriores y recoge
los requerimientos.

Cuanto mejor se involucren en el proyecto, mejor aceptarán
el cambio al nuevo sistema y habrá menos fuentes de
conflicto.

Tiene un papel trascendental.

Son todas las personas que interactúan con el sistema.
 Colectivos que intervienen en la construcción de SI
3. EL PERSONAL DE DESARROLLO
3.1 ANALISTAS
• Profesionales con formación técnica y empresarial.
• Tienen capacidad para identificar los problemas y posibles
soluciones.
• Deberán describir y analizar:

El sistema actual, sus componentes de hardware y software, sus
deficiencias y suficiencias.

La organización o contexto en el que debe funcionar el sistema
(estructura, responsables, usuarios, etc.).

El conjunto de las posibles soluciones y su comportamiento requerido
independientemente de la tecnología utilizada en la implantación.
 Colectivos que intervienen en la construcción de SI
3. EL PERSONAL DE DESARROLLO
3.2 DISEÑADORES
• Manejan tecnología y lenguajes de programación.
• Son creativos.
• Diseñan los modelos que servirán de base para que los técnicos construyan
el sistema.
• Son los “ingenieros” del sistema.
• Son responsables de:

Diseño

Revisión

Pruebas del sistema

Generar documentación a largo del proceso.
 Colectivos que intervienen en la construcción de SI

3. EL PERSONAL DE DESARROLLO
3.3 PROGRAMADORES Y TECNICOS
• Son los encargados de construir el sistema.
• Instalan el hardware y las comunicaciones.
• Deben mantener comunicación fluida con los usuarios
finales.
https://www.youtube.com/watch?v=gRyvda1Ox
tw

http://outsourceando.blogspot.com/2012/0
8/por-que-fracasan-los-proyectos-de-
ti.html
CICLO DE VIDA DE UN PROYECTO DE SI

Conjunto de fases o actividades que siguen una determinada secuencia desde el
reconocimiento de necesidades y análisis de la situación, pasando por el diseño y
construcción del sistema hasta su implantación y mantenimiento.

CONSTRUCCIÓN PUESTA EN
MARCHA

DISEÑO MANTENIMIENTO

ANALISIS

Figura 1. Proceso de desarrollo de un sistema de información


Enfoque Estructurado:
◦ Implica dar solución a los problemas a enfrentar de modo ordenado
◦ Especificando bien y formalmente las situaciones a resolver
◦ Desarrollar esos modelos y probarlos
◦ El proceso debe estar documentado
◦ Y poseer mecanismos de retroalimentación para permitir hacer correcciones a lo
largo del mismo.

Problemas de no seguir un modelo estructurado:
◦ Dificultad para estimar tiempos, costes y esfuerzos.
◦ Falta de calidad del sistema o software producido.
CICLO DE VIDA DE UN PROYECTO DE SI

Al finalizar las fases, se obtienen una serie de productos (documentos, diagramas,

programas), que permite evaluar lo realizado hasta ese momento y continuar con la
fase siguiente o modificar algún aspecto de las fases anteriores.

Esta documentación, servirá para un mejor mantenimiento del sistema al final del
proceso.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI

2.1. Análisis
2.2. Diseño de sistemas: la arquitectura de SI
2.3. Construcción
2.4. Puesta en marcha
2.5. Mantenimiento
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI
2.1. Análisis
• Con esta etapa comienza al construcción de un SI.
• Constituye el núcleo principal del desarrollo, junto con la etapa de diseño.
• Objetivos:

Identificar las necesidades de los usuarios.

Especificar la solución y sus requerimientos.

Evaluar la viabilidad del proyecto.

Asignar funciones al software, al hardware, a las personas, a la BD y a otros
elementos del sistema.

Establecer restricciones de coste y tiempo.
• Tres tipos de análisis:
2.1.1. Análisis de viabilidad
2.1.2. Análisis de requerimientos
2.1.3. Análisis Funcional
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI
2.1.1 Análisis de viabilidad o factibilidad
• Consiste en diagnosticar si el proyecto es realizable en términos,
económicos y organizativos.
• Desde el punto de vista técnico, se abordarán cuestiones tales
como:

Definición del problema

Requerimientos de medios y disponibilidad de la tecnología
necesaria

Planteamiento de soluciones

Riesgos a gestionar

Duración del proyecto (plazos), etc.
Aspectos relativos a la gestión de riesgos

Desviaciones o riesgos Causas Acciones preventivas

- Desviación en presupuestos
- Beneficios menores a los
esperados
- Desviación o incumplimiento de
plazos
- Mala definición o cálculo de los
resultados
- Deficiente estimación de costes
- Desconocimiento de la
tecnología a utilizar
- Falta de experiencia o
conocimiento de la metodología
- Evaluar el riesgo y
comunicarlo a directivos
mejor y más explícitamente
- Desarrollar planes de
contingencia
- Mejor definición de proyectos
- Diversificar el riesgo
combinando proyectos
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI
2.1.1 Análisis de viabilidad o factibilidad
• Desde el punto de vista económico, se valora la inversión
y se determinan los costes del proyecto.
• Se suele hacer un análisis coste-beneficio
Análisis coste-beneficio
Utilidades -Se valora la inversión que supone el nuevo sistema de información
-Se facilita el cálculo de costes
-Permite una mejor evaluación posterior de los resultados finales

Costes -De análisis y diseño

asociados -De adquisición de hardware
-De adquisición o programación de software
-De formación
-De conversión
-De oportunidad
-De Mantenimiento
-De nuevo personal

Potenciales Ahorro en costes de recursos humanos

Beneficios Ahorro en tiempos de procesamiento
Ahorro por disminución de errores y aumento de calidad en general
Mejor servicio
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI

2.1.1 Análisis de viabilidad o factibilidad

• Desde la perspectiva organizativa, se deberán determinar
cuestiones clave como:
o Las áreas afectadas
o La congruencia con los objetivos estratégicos
o La necesidad de realizar cambios organizativos y los aspectos
relacionados con ellos:
o Resistencia al cambio
o Apoyo
o Barrera de la cultura organizativa, etc.
 FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI

2.1.2 Análisis de requerimientos

• Junto con el análisis de viabilidad, trata de establecer el alcance,
objetivos y requerimientos del sistema nuevo.
• El papel más importante lo juegan los usuarios, que son los
encargados de plantear los requisitos del nuevo sistema.
• Con las especificaciones generales y los requerimientos se trabaja en
el análisis funcional.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI

2.1.3 Análisis funcional

• Comienza cuando se acepta el análisis de requerimientos
• Consiste en elaborar un conjunto de especificaciones
formales que describan:

Lo que va a hacer el sistema

Los componentes de los que estará formado

Definición de datos, procesos e interfaces de usuario
• Se planifican las pruebas que debe superar el sistema.
• Las necesidades del usuario se transforman en
especificaciones formales utilizando la construcción de
modelos mediante técnicas de análisis estructurado.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI

ANALISIS ESTRUCTURADO
• Técnica de modelización del flujo y contenido de la información
procedente de la fase de análisis.
• Los modelos sirven:

Para verificar que se han tenido en cuenta los requisitos expresados
por los usuarios.

Para realizar la labor posterior de diseño.
• Las técnicas en las que se apoya son:
1. Diagrama de flujo de datos.
2. Diccionario de datos.
3. Especificaciones de proceso.
4. Modelos Entidad-Relación.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI

ANALISIS ESTRUCTURADO
1. Diagrama de flujo de datos

Es una técnica gráfica que representa el flujo de
información y las transformaciones de los datos.

Simboliza el flujo de información.

Se puede usar para representar un sistema o software.

Los elementos que se utilizan son:
◦ ENTIDADES Son elementos del sistema u otros
sistemas, que reciben la información que va a ser transformada y
que reside fuera de los límites del sistema que se representa.
◦ PROCESOS Son las transformaciones que se aplican a los
datos.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI

ANALISIS ESTRUCTURADO
1. Diagrama de flujo de datos
◦ FLUJOS Son elementos del sistema u otros sistemas, que
reciben la información que va a ser transformada y que reside fuera de
los límites del sistema que se representa.
◦ ALMACENES DE DATOS Información siempre disponible donde los
datos quedan retenidos.
2. Diccionario de datos

Representa la información que se transforma.
3. Especificaciones de proceso

Definiciones literales de los procesos.

Describen como se transforma la información (la entrada que se produce,
el algoritmo que se aplica y la salida que genera)
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI
ANALISIS ESTRUCTURADO
4. Modelos Entidad-Relación

Permiten identificar los conjuntos de datos y sus relaciones, usando una
notación gráfica.

Con los modelos y sus representaciones gráficas se responde a cuestiones
relativas a:
◦ Datos principales a procesar.
◦ Composición de cada conjunto de datos y sus atributos.
◦ Relación entre los conjuntos de datos y los procesos que los
transforman.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI

HERRAMIENTAS CASE

Permiten desarrollar software de manera formal y estructurada con la
ayuda de un ordenador.

Permiten automatizar los trabajos de desarrollo y mantenimiento de
software.

Con ellas se consigue un uso más eficiente y de mejor calidad de las
técnicas del análisis estructurado.

Otras utilidades son:
◦ Generación de bases de datos a partir de las especificaciones de diseño.
◦ Generación de código fuente a partir de las especificaciones funcionales.
◦ Elaboración de prototipos, etc.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI
2.2. DISEÑO DE SISTEMAS

• Su objetivo es convertir los modelos lógicos realizados en la etapa de

análisis en el modelo concreto en forma y estructura del sistema que se
construirá en la siguiente fase.
• Existirán varios diseños posibles, de entre los cuales se elegirá el que mejor
cumpla los requerimientos en función de los recursos disponibles:

Tecnológicos

Organizativos

Económicos

Temporales
• Un SI será mejor (en términos de eficiencia y generación de valor) que otro
en condiciones similares, dependiendo del grado de cumplimiento de los
requerimientos de diseño que, a su vez, dependerá de la forma en que se ha
llevado a cabo la etapa de análisis.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI

2.2. DISEÑO DE SISTEMAS

• Los analistas cumplen tres cometidos en esta fase:
1. Asignar tareas a procesadores, siguiendo las especificaciones del análisis.
2. Crear una jerarquía apropiada de módulos y sus interfaces dentro de cada
tarea.
3. Transformar el modelo entidad-relación en un diseño de BD (diseño de
datos).
• Estas funciones se plasman en modelos que constituyen la “arquitectura del
sistema”: organización fundamental de un sistema representada por:

Sus componentes.

Las relaciones entre ellos y con el entorno.

Los principios que guían si diseño y evolución.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI

2.2. DISEÑO DE SISTEMAS

• En función del aspecto que traten se diferencian varios tipos de arquitecturas:

de aplicaciones, define los componentes que llevan a cabo tareas de
computación, sus interfaces y la comunicación entre ellos.

de hardware, determina las unidades de proceso y su organización.

de disponibilidad, gestiona los mecanismos que permiten mantener los
SI funcionando.

de procesamiento, trata el modo en que se procesan los datos.

de redes, trata los protocolos que gestionan la comunicación entre los
dispositivo.

de BD, persigue realizar la estructura de datos idónea.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI

2.2. DISEÑO DE SISTEMAS

TIPOS DE ARQUITECTURAS DE APLICACIONES:

1. A. Monolíticas o centralizadas

Procesos y datos en la misma máquina

Ventajas:

Software más sencillo de manejar y mantener

Mayor seguridad en el acceso y las modificaciones de los datos.

Inconvenientes: (son las ventajas de las A. Distribuidas)

Falta de flexibilidad y escalabilidad del hardware y software.

Sobrecarga de trabajo de los sistemas cuando los accesos son muy
numerosos.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI
2.2. DISEÑO DE SISTEMAS
TIPOS DE ARQUITECTURAS DE APLICACIONES:
2. A. en dos capas o Distribuidas

Sitúan la aplicación en dos máquinas, utilizando una aplicación puente
“middleware “entre ambas.

Se dividen en:

Arquitectura cliente/servidor

Divide la aplicación en partes entre una máquina (servidor) y otra
(cliente).

Los datos viajan del cliente al servidor y viceversa.

Arquitectura web

Se basa en la organización de máquinas virtuales.

Las máquinas acceden y ejecutan aplicaciones java residentes en
ordenadores vía Internet.

Son recomendables para SI que superen las barreras de la
organización.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI

2.2. DISEÑO DE SISTEMAS

TIPOS DE ARQUITECTURAS DE APLICACIONES:
3. A. en tres capas o totalmente distribuidas

Se reparten las tres funciones de la aplicación en máquinas diferentes.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI
2.3. CONSTRUCCION

• A su comienzo se deberá tener la decisión de si se va adquirir un software

estándar o si se desarrollará un sistema a medida con medios propios o
subcontratando a terceros (outsourcing).

• Si se opta por un paquete estándar:

En la fase de diseño se tratará de amoldar las necesidades de los usuarios a
las utilidades del paquete, intentando personalizarlo al máximo.

Para elegir entre todos los paquetes disponibles en el mercado, se evaluarán
criterios de flexibilidad, facilidad de uso y requerimientos de hardware.

La implantación suele ser menos costosa, menos arriesgada y más rápida.

Como contrapartida, podría no dar los beneficios esperados bien por no
adaptarse realmente a las necesidades o bien por presentar problemas de
integración.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI
2.3. CONSTRUCCION
• Si se opta por subcontratar un desarrollo:

Se podría subcontratar adicionalmente a la realización del desarrollo el
servicio de explotar el sistema.

Puede resultar muy costoso para la empresa tener personal dedicado a
estas tareas.

La subcontratación permite variabilizar los costes del servicio.

Presenta el riesgo de perder el control sobre un activo estratégico.
• La construcción se consigue siguiendo las especificaciones de diseño de
hardware, software, y de estructura de datos de la fase anterior.
• Implica la realización de actividades:

Construcción de los códigos de programa o aplicaciones.

Especificaciones de requisitos de nuevo hardware.

Construcción de estructura de datos.

Elaboración de procedimientos, etc.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI

2.3. CONSTRUCCION

• Implica la realización de actividades:

Realización de pruebas unitarias (consisten en comprobar la validación de
todos los módulos de los programas para detectar errores).

Realización de pruebas de integración (tratan de unir todos los módulos
y probar el sistema en conjunto).

Al final de esta fase se obtendrá un sistema completamente construido y
probado, listo para implantarse en la organización.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI

2.3. IMPLANTACIÓN O PUESTA EN MARCHA

• Su objetivo es poner en servicio el sistema construido y conseguir la
adaptación final a los usuarios.
• Se realizan actividades:

Instalación de componentes físicos y lógicos.

Volcado de datos y conversión de archivos de formatos antiguos.

Formación del personal y documentación detallada.

Realización de controles de seguridad de la migración a nuevo sistema.

Pruebas de aceptación (demostraciones formales a los usuarios).

Para pasar del sistema antiguo al nuevo existen varias opciones:

Rodaje en paralelo Ambos sistemas, el antiguo y el nuevo, conviven durante un período determinado para asegurarse de no
perder datos ni funcionalidad si surge algún problema

Sistema Piloto Una pequeña parte de la empresa o área funcional es convertida al nuevo sistema. Se minimiza el riesgo
para la organización

Conversión gradual El sistema antiguo se va reemplazando por el nuevo de forma paulatina

Reemplazamiento directo La conversión se hace de una vez y de forma rápida

FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI

2.4. MANTENIMIENTO

• Tiene como fin que, las condiciones que permiten el adecuado funcionamiento
del sistema permanezcan:

Control de fallos de hardware y software.

Mantenimiento o modificación de procedimientos.
• Con el estudio de las labores de mantenimiento los gestores de los SI pueden
conocer los fallos desarrollo de sistemas anteriores y mejorarlos.
• La fase de mantenimiento dura hasta que el sistema deje de permanecer en la
organización.
FASES DE LAS ETAPAS DEL CICLO DE VIDA DE UN SI
Herramientas utilizadas en las diferentes etapas.
Fases o actividades Técnicas y herramientas Participantes
Análisis de
factibilidad o estudio
de viabilidad
ANÁLISIS

Análisis de Entrevistas Gestores, usuarios y analistas

requerimientos
Análisis funcional Diagramas de Flujo Analistas
Modelos Entidad-Relación
Diccionarios de datos
DISEÑO Programas y lenguajes Diseñadores técnicos
específicos
CONSTRUCCIÓN Paquetes estándar o Sw Programadores y técnicos en
producido general.
Hw adquirido
PUESTA EN MARCHA o Documentación previa Analistas, programadores y
IMPLANTACIÓN Sistemas de pruebas técnicos en general.
Medidas de seguridad
MANTENIMIENTO Informes de adaptación y Gestores, técnicos y usuarios
fallos
4.1. El desarrollo basado en cascada

4.2. El desarrollo basado en prototipos

PRINCIPIOS FUNDAMENTALES PARA IMPLANTAR UN BUEN SISTEMA

•Visión de negocio. El sistema de información a desarrollar tiene que tener siempre como
marco de referencia el negocio.

•Apoyo de la dirección. La dirección de la empresa debe apoyar y comprometerse con el proyecto.

•Orientación al usuario.

•Flexibilidad. Búsqueda de capacidad de adaptación. Es decir, crear entornos de información

distribuida orientados al usuario final que permita cambios o adaptaciones, procesos muy
estructurados y lo más automatizados posibles, simplificar procesos, etc.

•Integración. Que los datos sean únicos y disponibles.

•Comunicación. Búsqueda permanente de la comunicación entre personas y organizaciones

mediante la incorporación de innovaciones tecnológicas y persiguiendo la usabilidad del sistema.

•Eficiencia. El sistema de información a diseñar e implantar debe mejorar la eficiencia de la

organización.

•Auditabilidad.
4.1. Enfoque clásico: el ciclo de vida en cascada

ANALISIS

DISEÑO

CONSTRUCCIÓN

IMPLANTACIÓN

MANTENIMIENTO
4.1. Enfoque clásico: el ciclo de vida en cascada
•Se caracteriza por:
•Una delimitación muy formal de las fases, de forma
que hasta no se cierre la anterior, no podrá comenzar la
siguiente.
•Basarse en procedimientos manuales en los que las
herramientas no se integran entre si.
•Inconvenientes:
•Alto coste y dificultad para eliminar errores (efecto
bola de nieve)
•Se genera un gran volumen de documentación.
•Actualmente sólo se usa para sistemas muy grandes,
que requieren alta formalización y especificación de
requerimientos.
4.2. Enfoque estructurado: desarrollo basado en
prototipos.
•Se basa en la elaboración de sucesivos modelos del sistema
“prototipos” que se van perfeccionando mediante la
evaluación de los usuarios.
•Se aplica a situaciones de incertidumbre respecto a los
requerimientos y en sistemas con pocos usuarios y transac.
•Clases de prototipos:
•Verticales, no recogen todas las funciones del producto final.
•Horizontales, recoge todas las funciones, pero no las
desarrolla totalmente.
•Características:
•Posibilidad de realizar fases de forma paralela, aprovechando
mejor los tiempos.
•Los fallos se detectan más rápidamente debido a la repetición
de pruebas y el refinamiento.
4.2. Enfoque estructurado: desarrollo basado en prototipos.

A N A L IS IS C O N ST R U C C IÓ N M A N T E N IM IE N T O
P r o to tip o I
D IS E Ñ O IM P L A N T A C IÓ N

P r u e b a y r e fin a m i e n t o

A N A L IS IS C O N ST R U C C IÓ N M A N T E N IM IE N T O
P r o to tip o II
D IS E Ñ O IM P L A N T A C IÓ N

P r u e b a y r e fin a m i e n t o

.........................

A N A L IS IS C O N ST R U C C IÓ N M A N T E N IM IE N T O
D e fin itiv o
D IS E Ñ O IM P L A N T A C IÓ N
4.2. Enfoque estructurado: desarrollo basado en prototipos.
•Ventajas:
•Incremento de la productividad del equipo de desarrollo.
•Incremento de la calidad del producto final.
•Disminución de los costes de mantenimiento del producto y de los
tiempos de desarrollo.
•Mejor reacción de usuario al experimentar con el producto.
•Demuestran la viabilidad del sistema.
•Inconvenientes:
•Requiere continuas inversiones en los sucesivos prototipos.
•Tientan a los gestores en convertir rápidamente el prototipo en el
sistema definitivo.
•Se arrastran decisiones del diseño de prototipos al producto final.
 Período de aparición Metodologías y técnicas
Años 70 Programación estructurada
Metodología de análisis y diseño de sistemas estructurados
(Structured Systems Analysis and Design Methodology) SSADM

Años 80
Ingeniería de la Información y herramientas (Computer Aided
Software Engineering) CASE

Desarrollo de aplicaciones (Rapid Application Development)

RAD
Años 90
Diseño orientado a objetos (Object Oriented Design) OOD

Lenguaje de modelado unificado (Unified Model Language)

UML
Proceso racional unificado (Rational Unified Process) RUP

Metodología de diseño hipermedia orientado a objetos (Object

Finales de los 90, nuevo milenio Oriented Hypermedia Design Methodology) OOHDM

Metodología de diseño hipermedia orientado a objetos basada

en escenarios (Scenario-based Object Oriented Hypermedia
Design Methodology) SOHDM
 5.1. La programación orientada a objetos y
los sistemas hipermedia

5.2. Las metodologías Agile

5.1. La programación orientada a objetos y los sistemas
hipermedia.

los objetos (datos y operaciones que se pueden realizar con

ellos) y no los procesos como la unidad básica de análisis y
diseño de sistemas.

En la fase de análisis se identifican objetos, sus procesos

y sus datos, en la de diseño se especifica el
comportamiento de esos objetos y en la de
implementación se traducen los diseños a programas de una
manera más rápida y automatizada gracias a herramientas
como el lenguaje UML.
5.2. Las metodologías Agiles

El concepto de metodología Agile (o Ágil) surge a finales de los 90 y principio de la

década de los 2000 como respuesta a dos problemas fundamentales: corregir cierta
mala praxis en el desarrollo de proyectos de software que daba lugar a productos de
peor calidad y reducir la exigencia de documentación y estructuración de tareas de las
metodologías anteriores denominadas “pesadas”.

Manifiesto Agile
Los cuatro valores fundamentales recogidos en este manifiesto son:
–Los individuos y las interacciones por delante de procesos y herramientas.
–El producto funcionando frente al exceso de documentación.
–La colaboración con el cliente ante la negociación contractual.
–La respuesta ante los cambios frente al plan establecido.

https://www.youtube.com/watch?v=eUDccKP
ex30
Metodología Origen Concepto

1993-1995 Método de desarrollo de software

Scrum

Años 50 Técnica para gestionar visualmente las tareas

Kanban

1999 Metodología de desarrollo de software

eXtreme Programming (XP)

1999 Enfoque de desarrollo ágil de software

Feature Driven Development (FDD)

Años 80 Filosofía de management aplicada al desarrollo de

software

Lean Development (LD)

6. La estandarización de las metodologías: La ISO/IEC
12207 Métrica y Magerit

Uno de los objetivo de los responsables de toda organización es

garantizar la calidad de la información: disponer con rapidez de
información completa y fiable.

Para alcanzar este fin último, es necesario definir una serie de etapas
intermedias:
◦ Asegurar la calidad en la construcción de los equipos lógicos .
◦ Verificar que los productos que se generen tienen un nivel
adecuado de calidad.
◦ Conseguir que la construcción de los equipos lógicos se desarrolle en
unos plazos y con unos costes razonables, cumpliendo las
previsiones iniciales.
6. La estandarización de las metodologías: La ISO/IEC
12207 Métrica y Magerit

• Para satisfacer esas etapas, la Subdirección General de

Coordinación Informática del Ministerio para las Administraciones
Públicas, ha desarrollado un plan de acción:

La elaboración de un Plan General de Garantía de Calidad,
aplicable al desarrollo de equipos lógicos.

La elaboración de la Metodología de Desarrollo de Sistemas de
información METRICA.
6. La estandarización de las metodologías: La ISO/IEC
12207 Métrica y Magerit

OBJETIVOS

Conjunto de métodos, procedimientos, técnicas y herramientas
que faciliten la construcción de Sistemas de Información, para:

Satisfacer todas las necesidades de los departamentos usuarios
implicados.

Generar la documentación asociada: instrucciones de
operación, documentación del mantenimiento y la explotación, etc.

Dar solución a los objetivos considerados prioritarios en la
Administración.

Desarrollar Sistemas cuando el usuario los necesite y de acuerdo
con los presupuestos y duración estimados.

Facilitar su mantenimiento para soportar los cambios futuros de
la organización.
7. La gestión económica del proceso: el análisis coste-beneficio y
el análisis de riesgos

Utilidades - Se valora la inversión que supone el nuevo sistema de información

- Se facilita el cálculo de costes

- Permite una mejor evaluación posterior de los resultados finales

Costes - De análisis y diseño - De conversión

asociados
- De adquisición de hardware - De oportunidad

- De adquisición o programación de software - De Mantenimiento

- De formación - De nuevo personal

Potenciales Ahorro en costes de recursos humanos

Beneficios
Ahorro en tiempos de procesamiento

Ahorro por disminución de errores y aumento de calidad en general

Mejor servicio

Mejor toma de decisiones

7. La gestión económica del proceso: el análisis coste-beneficio y
el análisis de riesgos

Es importante analizar:

Tamaño del proyecto,
proyecto costes, tiempo necesario para realizarlo o
número de personas implicadas.

Grado de conocimiento de tecnología que se va a utilizar, si se trata
de una tecnología nueva o el grupo de desarrollo ya tiene experiencia
en el uso de la misma.

Nivel de definición del resultado a obtener, si los resultados a obtener
están especificados claramente o son conocidos y la estimación de la
probabilidad de que cambien.

Dificultades a la hora de aplicar una determinada metodología.
7. La gestión económica del proceso: el análisis coste-beneficio y
el análisis de riesgos

Una mejor aprobación de proyectos. Así, generalmente, a mayor riesgo

el nivel necesario de aprobación será normalmente mayor y los beneficios
exigibles serán también mayores. También es cierto que un mayor riesgo se
verá acompañado probablemente de un mayor apoyo, soporte y comprensión
por parte de los responsables de la organización.

Un mejor cálculo de costes.

Un desarrollo de planes de contingencia que nos indiquen qué hacer de
antemano y ayuden a tener previstas medidas adecuadas a aplicar en el caso
de que se produzca el mismo.

Una mejor definición de proyectos, de manera que podamos modificar lo
que le hace arriesgado, y podamos reducir la complejidad.

Una adecuada gestión de la denominada “cartera de riesgos”: cada
empresa ha de combinar de forma adecuada proyectos de mayor y de menor
riesgo. El perfil óptimo va a depender de la importancia estratégica de la
tecnología de la información.
7. La gestión económica del proceso: el análisis coste-beneficio y
el análisis de riesgos

Desviaciones o riesgos Causas Acciones preventivas

- Desviación en - Mala definición o cálculo - Evaluar el riesgo y

presupuestos de los resultados
- Beneficios menores a - Deficiente estimación de
los esperados costes
- Desviación o - Desconocimiento de la
incumplimiento de tecnología a utilizar
plazos
- Falta de experiencia o
conocimiento de la
metodología
comunicarlo a
directivos mejor y más
explícitamente
- Desarrollar planes de
contingencia
- Mejor definición de
proyectos
- Diversificar el riesgo
combinando proyectos
8. Buenas
prácticas en la provisión y gestión de TI:
ISO/IEC 20000 e ITIL

La ISO/IEC 20000-1 del 2011 es un estándar aplicable para los sistemas de

gestión de servicios de tecnología de la información (TI). En él se especifican los
requerimientos aplicables a los proveedores de servicios para planificar,
establecer, implementar, operar, monitorizar, revisar, mantener y mejorar un
sistema de gestión de servicios de TI.
8. Buenas
prácticas en la provisión y gestión de TI:
ISO/IEC 20000 e ITIL
Ventajas,
Ventajas

Proporciona a los proveedores de servicios externos un
elemento diferencial que les permite ampliar su negocio al
convertirse cada vez más en un requisito contractual.

Hace posible que las empresas puedan gestionar a los
proveedores de servicios externos con mayor eficacia
ofreciendo mayores oportunidades para mejorar la eficacia,
fiabilidad y coherencia de los servicios de tecnología de la
información.

Con las auditorías de certificación se evalúan periódicamente
los procesos de gestión de servicios, lo que ayuda a mantener
y mejorar la eficacia.
8. Buenas
prácticas en la provisión y gestión de TI:
ISO/IEC 20000 e ITIL
Inconvenientes:

La propia orientación hacia el servicio que desvirtúa el
verdadero valor o importancia de los procesos como vehículos
que permiten mejores servicios.

La falta de un mayor tratamiento de aspectos claves como son

los recursos humanos asociados a la TI y el tratamiento de la
seguridad de la información.

Su utilización como un modelo completo cuando en realidad es

un compendio de buenas prácticas lo que a veces hace difícil
su utilización en procesos de desarrollo de sistemas de
información y más aún de creación de software.
9. La Web semántica, los datos abiertos y su calidad

La Web que manejamos ha dejado de ser un repositorio virtual

para publicar y compartir documentos para ir convirtiéndose en
un universo de datos conectados y estructurados que pueden ser
procesados por máquinas.
máquinas

Esta idea es la que subyace en el concepto de Web semántica y

constituye precisamente uno de los objetivos fundamentales de
los desarrollos impulsados por el World Wide Web
Consortium (W3C). Consorcio creado en los 90 y dirigido por Tim
Berners-Lee creador de las tecnologías base de la Web: URL,
HTTP, HTML.

La Web semántica trata de poner a disposición de las máquinas

más información para facilitarnos a nosotros las respuestas que
necesitamos de forma más rápida. Pasando de ser un medio de
publicación de documentos a un medio para compartir datos
estructurados.

.
9. La Web semántica, los datos abiertos y su calidad

Los datos abiertos son datos que pueden ser

utilizados, reutilizados y redistribuidos
libremente por cualquier persona, y que se
encuentran sujetos, cuando más, al
requerimiento de atribución y de
compartirse de la misma manera en que
aparecen

https://www.youtube.com/watch?v=1AaVyQv
PXsc

https://www.youtube.com/watch?v=nVT9LQP
6tP4
9. La Web semántica, los datos abiertos y su calidad

Por tanto, para que los datos sean abiertos deben

cumplir las siguientes características básicas:
◦ Poder ser usados y compartidos gratuita o
comercialmente sin limitaciones a ese uso.
◦ Su acceso no tiene por qué ser gratuito ya que su
creación, mantenimiento y publicación suele
generar costes si bien este debe ser en todo
momento razonable.
◦ La calidad de los datos abiertos se mide por la
usabilidad no por el formato si bien este, así
como su estructura, relación o posibilidad de ser
leídos por máquinas, los hacen más reutilizables.
9. La Web semántica, los datos abiertos y su calidad

Los gobiernos permitiéndoles ser más transparentes

mediante la publicación de datos sobre los resultados de
inversiones o acciones públicas o en qué se han utilizado
los fondos.

Las empresas ofreciéndoles nuevas oportunidades de crear
negocio

Los ciudadanos en general que pueden conocer para su
utilidad más y mejores datos sobre clima, ciudades,
impactos, contaminación, productos sanitarios, etc.
9. La Web semántica, los datos abiertos y su calidad

el Linked Open Data (LOD) es el concepto

resultante de considerar dos fenómenos
tecnológicos claves y revolucionarios: la
Web semántica y los datos abiertos en los
que resulta fundamental la calidad de los
datos en términos de sus posibilidades de
reutilización y vinculación.

https://www.youtube.com/watch?v=uju4wT9
uBIA
9. La Web semántica, los datos abiertos y su calidad

En definitiva, el Linked Open Data (LOD) es el concepto resultante de

considerar dos fenómenos tecnológicos claves y revolucionarios: la Web
semántica y los datos abiertos en los que resulta fundamental la calidad
de los datos en términos de sus posibilidades de reutilización y
vinculación.
Estrellas Significado

 Por ejemplo, ficheros en pdf o una imagen escaneada publicada en Internet no legible por máquina. El
publicador no recae en coste al publicarla.

 Por ejemplo, ficheros .xls La información está estructura y es legible por una máquina. Se puede tratar
con algún software comercial.

 Por ejemplo, ficheros .csv La información está estructura y es legible por una máquina, pero se puede
tratar con cualquier software libre. Hay algo de coste en el propietario si la tiene que transformar.

 Además de cumplir las tres estrellas los datos cumplen estándares y formatos abiertos recomendados
por el W3C (Web semántica) como RDF. Importante esfuerzo del publicador a transformaciones de
Linked Data.

 Además de las cuatro estrellas publicadores diferentes utilizan los mismas estructuras de definición
de conceptos y datos de modo que se puedan enlazar con datos similares publicados por sus
homólogos.
9. MELODA

MELODA (MEtric for reLeasing Open DAta), tal y como

está definida en la propia Web de la iniciativa es una
métrica que: “ayuda a los editores de datos (públicos y
privados) a sacar el máximo provecho de los datos
que liberan para su reutilización, pero también a los
reutilizadores de datos a saber qué es lo que será más
útil para crear nuevos productos y servicios”
https://www.meloda.org/what-is-meloda-
for/