Este documento presenta información sobre sistemas, ingeniería de sistemas, software y procesos de ingeniería de software. Explica que un sistema es un conjunto de elementos interrelacionados que trabajan juntos para lograr un objetivo común. La ingeniería de sistemas se define como la aplicación de principios de ingeniería para desarrollar sistemas exitosos. También describe conceptos clave como modelos de proceso prescriptivos y marcos de trabajo para guiar el desarrollo de software.

1. 5: “PROGRAMACIÓN DE
SISTEMAS COMPUTACIONALES,
MODELOS Y HERRAMIENTAS”
MAESTRÍA EN ALTA GERENCIA EN TICs E INNOVACIÓN PARA EL DESARROLLO (MAGTIC- 5ta. Versión)
© 2023 Módulo 1: Fundamentos de las Tecnologías de la Información y las Comunicaciones

2. SISTEMAS
Intuitivamente decimos que
cuando no hay “Sistema” se
produce el:
“Efecto 2+2=3”
Enfoque de sistemas

3. Vision sistémica:
La visión sistémica nos ayuda a
“ver” el todo, apreciar su energía y
descubrir sus características
distintivas, aquellas que son propias
del conjunto y que no existen en las
partes.
Esta visión permite ubicar al sistema
en su entorno o realidad dinámica,
integral, compleja e incierta, entre
otras características.

4. Pensamiento Sistemico:
“El pensamiento sistémico es la
disciplina que integra las demás
ramas, fusionándolas en un todo
coherente de teoría y práctica. .....Al
enfatizar cada una de las demás
disciplinas, el pensamiento
sistémico nos recuerda
continuamente que el todo puede
superar la suma de las partes”,
Peter Senge
“Efecto 2+2=5”

5. Definiciones de Sistema
Se origina en la palabra griega sunistánai,
que significa: causa que mantiene la
unidad.
Conjunto de reglas o principios sobre una
materia enlazados entre sí.
Conjunto de cosas que ordenadamente y
relacionadas entre sí, contribuyen a
determinado objetivo. (Diccionario de la
RAE).
Sistema es cualquier proceso que
convierte inputs en outputs. (H. Eisner)

6. ¡ESTE ES UN SISTEMA!
• Hay un conjunto de elementos : las piedras
• Están interrelacionados entre sí : la posición relativa
entre ellas
• Tienen un objetivo común : trasmitir una información
• Alguien necesita resolver una necesidad o problema

7. SISTEMAS
INGENIERIA
INGENIERIA
DE
SISTEMAS
Ingeniería de Sistemas
(Ingenierizar un sistema)

8. Ingeniería de Sistemas
(Origen teórico-científico)
+
“INGENIERÍA DE SISTEMAS”
• COMPONENTES
• INTERRELACIONES internas
• INTERRELACIONES con sistema
superior
• OBJETIVO COMÚN
• FORMULACION del PROBLEMA
• MODELOS REPRESENTATIVOS
• ALTERNATIVAS de SOLUCIÓN
• VALIDACIÓN por
EXPERIMENTACION
TEORÍA DE
SISTEMAS
Bertalanffy
METODO
CIENTÍFICO
Galileo

9.  “El diseño, producción y mantenimiento de
sistemas dentro de las restricciones de costo y
tiempo”, Sage (1992)
 “Una aproximación interdisciplinaria para
posibilitar la realización de sistemas exitosos”,
INCOSE (1999)
 “Las acciones técnicas y de control asociadas a
los procesos de desarrollo de un sistema y sus
capacidades” R. Stevens, P. Brook y S. Arnold.
Definicion de Ingenieria de Sistemas:

10.  Conozca el problema, el cliente y el usuario del
sistema
 Use criterios de efectividad basados en las
necesidades
 Establezca y administre los requerimientos
 Identifique y evalúe distintas alternativas de
solución
 Verifique y valide los requerimientos y el
desempeño
 Mantenga la integridad del sistema
 Use un proceso estructurado y documentado
Principios de la Ingenieria de Sistemas:

11. Esfuerzos Innecesarios
Cumplir con los Principios
de Ingeniería de Sistemas podría evitar:

12. Cumplir con los Principios
de Ingeniería de Sistemas podría evitar:
Fustraciones

13. Cumplir con los Principios
de Ingeniería de Sistemas podría evitar:
Desprestigio

14. Software
El software se forma con:
Las instrucciones (programas de
ordenador) que cuando se ejecutan
proporcionan las características,
funciones y el grado de
comportamiento deseado.
Las estructuras de datos que
permiten que los programas
manipulen adecuadamente la
información.
Los documentos que describen la
operación y el uso de los programas.

15. Características:
El software se desarrolla o construye,
no se manufactura en sentido clásico
(a pesar de las similitudes entre el
desarrollo de Sw y la manufactura del
Hw, ambas son diferentes).
El software no se desgasta, pero se
deteriora (cuando un componente del
Hw se desgasta se sustituye con un
repuesto. Pero en Sw no existen
repuestos). El software es inmune a
los males ambientales (polvo,
vibración, temperatura).

16. Curva de fallos de Hardware
Tiempo
Indice
de
fallos
Defectos fabricación
(ej: mortalidad infantil)
Estropeado
(desgaste)
Obsolescencia

17. Curva real de fallos de Software
Tiempo
Indice
de
fallos
Defectos fabricación
Curva ideal
Cambio Cambio Cambio
Obsolescencia

18. A pesar de que la industria tiene una
tendencia hacia la construcción por
componentes, la mayoría del software
aún se construye a medida.
Un componente Hw (tornillo) se puede
reutilizar.
Un componente de Sw se debe diseñar e
implementar de forma que pueda
utilizarse en muchos programas
(creación de ventanas gráficas, menús
desplegables) diferentes (encapsulan
tanto los datos como el proceso).

19. Categorias del Software
Software de sistemas
Software de aplicación
Software científico y de ingeniería
Software empotrado
Software de línea de productos
Software basadas en Web
Software de Inteligencia Artificial

20. La construcción del
software de ordenador
es un proceso iterativo
de aprendizaje y el
resultado es una
materialización del
conocimiento
recolectado, depurado
y organizado conforme
el proceso estuvo en
ejecución.
EL PROCESO

21. Existen mecanismos de evaluación del
proceso de software que permiten a las
organizaciones determinar la “madurez” del
proceso de software. No obstante, la calidad,
el tiempo requerido, la viabilidad a largo
plazo del producto que se construye son los
mejores indicadores de la eficacia del
proceso que se utiliza.

22. Tres aspectos del proceso
1.- Definición del proceso
Un proceso debe estar definido
(documento que especifica actividades y
procedimientos del proceso).
2.- Aprendizaje del proceso
El conocimiento del proceso debe ser
transferido a las personas (agentes) que
lo ejecutarán.
3.- Resultados del proceso
Manifestación de los productos, como
resultado de la ejecución de las
actividades definidas por el proceso.

23. Consideraciones
acerca de los procesos
Los comportamientos, actividades y
tareas que desempeñamos para lograr un
objetivo representan la ejecución del
proceso para alcanzar dicho objetivo.
Un proceso disciplinado se manifestará
en patrones ordenados y consistentes de
comportamiento individual o grupal.
Por tanto, un proceso da forma a las
acciones y reacciones y tomamos frente a
una determinada situación.

24. Proceso internalizado y
proceso institucionalizado
Cuando un proceso es desarrollado
profesional y naturalmente por una
persona, se dice que el proceso esta
“internalizado” por la persona.
En las organizaciones los procesos
son comunes a grupos de personas.
Para obtener disciplina en los
procesos, estos deben ser establecidos
como “institucionalizados” en la
organización.

25. Ingenieria del software
[Ingeniería de software es] el
establecimiento y uso de principios
de ingeniería adecuados para obtener
económicamente software que sea
confiable y trabaje eficientemente en
máquinas reales (Fritz Bauer)
teoria practica
Resolucion
de
problemas
Administracion
y gestion
Pruebas y
control de
calidad
Definición

26. La ingeniería de software no es
ciencia informática.
“Un científico construye con el objetivo de
aprender, un ingeniero aprende con el objetivo de
construir”.
La distinción entre ingeniería y
ciencia en el software es el mismo
que en otras disciplinas
“Los científicos aprenden lo que es verdadero y
cómo extender el conocimiento en su campo”.
“Los ingenieros aprenden lo que es verdadero, lo
que es útil y cómo aplicar conocimiento bién
entendido para resolver problemas prácticos”.

27. Científicos
 Conocimientos enfocados y especializados.
 Reportan básicamente a sus colegas científicos.
 No necesitan licencia.
Ingenieros
 Conocimientos comprobados, efectivos y
confiables de ámbito más general.
 Se necesita un amplio entendimiento de todos
los factores que intervienen en el desarrollo del
producto.
 Responsabilidad con el público.
 Generalmente necesitan licencia para ejercer.

28. Ingenieria del software: tecnologia estratificada
Definicion
según
“La ingenieria de software es la aplicación de
un enfoque sistemático, disciplinado y
cuantificable al desarrollo, operación y
mantenimiento del software; es decir, la
aplicación de la ingeniería al software”.

29. La I.S. es una
tecnología estratificada
Cualquier enfoque de la ingeniería debe estar
sustentado en un compromiso con la calidad.
La gestión de la calidad Total, Sigma Seis y enfoques
similares fomentan una cultura de mejora continua
del proceso, y es esta cultura la que al final conduce
al desarrollo de enfoques muy efectivos para la I.S.

30. El enfoque de calidad soporta a la I.S.
Software Engineering
Ingeniería de Software
enfoque de “calidad”
modelo de proceso
métodos
herramientas

31. MARCO DE TRABAJO PARA EL PROCESO
Un marco de trabajo establece la
base para un proceso de software
completo al identificar un numero
pequeño de actividades del marco
de trabajo aplicables a todos los
proyectos de software, sin importar
su tamaño y complejidad.
Abarca un conjunto de actividades
sombrilla aplicables a lo largo del
proceso del software.

32. Cada actividad dentro del marco de trabajo
contiene un conjunto de acciones de
ingeniería del software; es decir, una serie
de tareas relacionadas que produce un
producto del trabajo en la I.S. (por
ejemplo, el diseño es una acción de la I.S.).
Cada acción la forman tareas de trabajo
individuales que completan alguna parte
del trabajo implicado por la acción.

33. Marco de trabajo del proceso de software
Actividades sombrilla
Marco de trabajo del proceso
Actividad del marco de trabajo #1
Tareas del trabajo
Productos del trabajo
Puntos de aseguramiento
Fundamentos del proyecto
Tareas del trabajo
Productos del trabajo
Puntos de aseguramiento
Fundamentos del proyecto
Accion de la ingenieria de software # 1.k
Accion de la ingenieria de software # 1.1
Conjunto
de tareas
.
Conjunto
de tareas
.
.
Actividad del marco de trabajo #n
Tareas del trabajo
Productos del trabajo
Puntos de aseguramiento
Fundamentos del proyecto
Tareas del trabajo
Productos del trabajo
Puntos de aseguramiento
Fundamentos del proyecto
Accion de la ingenieria de software # n.m
Accion de la ingenieria de software # n.1
Conjunto
de tareas
.
Conjunto
de tareas
.
.

34. Aplicacion del marco
de trabajo en proyectos
Comunicación. Implica una intensa colaboración y
comunicación con los clients.
Planeación. Establece un plan para el trabajo de la
ingeniería del software. Describe las tareas técnicas,
los riesgos probables, etc.
Modelado. Abarca la creación de modelos que permiten
al desarrollador y al cliente entender mejor los
requisitos del software y el diseño.
Construcción. Esta actividad combina la generación del
codigo y la realización de pruebas necesarias para
descubrir errores en el código.
Despliegue. Se entrega al cliente, quién evalua el
producto recibido y proporciona información basada en
su evaluación.

35. Los modelos prescriptivos de proceso se
propusieron originalmente para ordenar el
caos del desarrollo de software.
Estos modelos convencionales han traído
consigo cierta cantidad de estructuras
útiles.
El trabajo de la IS y el producto resultante
aún permanecen “al borde del caos”
MODELOS PRESCRIPTIVOS

36. Los modelos prescriptivos de proceso definen un
conjunto distinto de actividades, acciones, tareas
fundamentos y productos de trabajo que se
requieren para desarrollar software de alta calidad.
Estos modelos son una guía para el trabajo de la IS.

37. Los modelos prescriptivos de proceso
proporcionan estabilidad, control y
organización a una actividad que si no se
controla puede volverse caótica.
El proceso conduce a un equipo de
software a través de un conjunto de
actividades del marco de trabajo que se
organizan en un flujo de proceso, el cual
puede ser lineal, incremental o evolutivo.

38. Cualquier organización de IS debe describir un conjunto
único de actividades dentro del marco de trabajo.
También debe llenar cada actividad del marco de trabajo
con un conjunto de acciones de IS, y definir cada acción
en cuanto a un conjunto de tareas que identifique el
trabajo (y los productos del trabajo) que deben
completarse para alcanzar las metas de desarrollo.
Luego, la organización debe adaptar el modelo de proceso
resultante y ajustarlo a cada proyecto, a las personas que
lo realizarán, y el ambiente en el que se ejecutará el
trabajo. Sin importar el modelo de proceso seleccionado,
los ingenieros de software han elegido de manera
tradicional un marco de trabajo.

39. Se les llama “prescriptivos” porque prescriben un
conjunto de elementos del proceso:
Actividades del marco de trabajo,
Acciones de la IS,
Tareas,
Productos del trabajo,
Aseguramiento de la calidad,
Mecanismos de control del cambio para cada
proyecto.

40. Cada modelo de proceso
prescribe también un “flujo de
trabajo”; esto es, la forma en la
cual los elementos del proceso
se interrelacionan entre sí.

41. Modelo en cascada
Algunas veces llamado el ciclo de vida
clásico, sugiere un enfoque sistemático
secuencial hacia el desarrollo de software.
Se considera 5 etapas:
Construcción
código
prueba
Comunicación
Inicio proyecto
Recopilación req Planeación
estimación
itinerario
seguimiento
Modelado
análisis
diseño
Despliegue
Entrega
Soporte
retroalimentacion

42. El modelo incremental aplica secuencias
lineales de manera escalonada conforme
avanza el tiempo en el calendario. Cada
secuencia lineal produce “incrementos” del
software.
Se debe tener en cuenta que el flujo del
proceso de cualquier incremento puede
incorporar el paradigma de construcción de
prototipos.
El modelo incremental:

43. Al utilizar el modelo incremental, el primer
incremento es un “producto esencial”, se
incorporan requisitos básicos. Este producto
queda en manos del cliente (o se somete a una
evaluación). Como resultado de la evaluación se
desarrolla un plan para el siguiente incremento.
El plan afronta la modificación del producto
esencial afin de satisfacer necesidades del
cliente. Este procesos se repite hasta la entrega
final.

44. Este modelo se enfoca en la entrega de un
producto operacional con cada incremento. Los
primeros incrementos son versiones
incompletas del producto final, pero
proporcionan al usuario la funcionalidad que
necesita y una plataforma para evaluarlo.
El modelo incremental es útil sobre todo
cuando el personal necesario para una
implementación completa no está disponible

45. Combina elementos del modelo en cascada
aplicado en forma iterativa.
Incremento #1
Entrega del 1er.
incremento
Incremento #2
Entrega del 2do.
incremento
Incremento #n
Entrega del n-ésimo
incremento
Tiempo del calendario de proyecto
Funcionalidad
y
caractérísticas
del
Sw

46. El modelo DRA
El Desarrollo Rápido de Aplicaciones es un
modelo de proceso de software incremental que
resalta un ciclo de desarrollo corto. El modelo
DRA es una adaptación a “alta velocidad” del
modelo en cascada en el que se logra el
desarrollo rápido mediante un enfoque de
construcción basado en componentes. Si se
entiende los requisitos y el dominio del proyecto.
El proceso DRA permite crear un sistema
completamente funcional dentro de un periodo
muy corto.

47. Modelado
Modelado del negocio
Modelado de los datos
Modelado del proceso
Modelado
Modelado del negocio
Modelado de los datos
Modelado del proceso
Modelado
Modelado del negocio
Modelado de los datos
Modelado del proceso
construcción
Reutilización componentes
Generación de código
pruebas
construcción
Reutilización componentes
Generación de código
pruebas
construcción
Reutilización componentes
Generación de código
pruebas
despliegue
integración
entrega
retroalimentación
60 – 90 días
planeación
comunicación
Equipo #1
Equipo #2
Equipo #n

48. Modelos de procesos evolutivos
El software, al igual que todos los sistemas
complejos, evolucionan con el tiempo. Los
requisitos de los negocios y productos a
menudo cambian conforme se realiza el
desarrollo; por lo tanto, la ruta lineal que
conduce a un producto final no será real; las
fechas tope del mercado imposibilitan la
conclusión de un producto completo.

49. Por lo que se debe presentar una versión limitada
para liberar la presión competitiva y de negocios;
se tiene claro un conjunto de requisitos del
producto o sistema esencial. Pero todavía se
deben definir los detalles de las extensiones del
producto. Por lo que se necesita un modelo de
proceso que haya sido diseñado de manera
explícita para incluir un producto que evolucione
con el tiempo

50. Construcción de prototipos
Con frecuencia un cliente define un conjunto de objetivos
generales para el software, pero no identifica los
requisitos detallados de entrada, procesamiento o salida.
En otros casos, el responsable del desarrollo de software
está inseguro de la eficacia de un algoritmo, de la
adaptabilidad de un SO.
En estas y en otras situaciones , un paradigma de
construcción de prototipos puede ofrecer el mejor
enfoque

51. Plan rápido
Modelado
Diseño rápido
Construcción
del prototipo
Desarrollo
Entrega y
retroalimentación
Comunicación
Modelo de construcción de Prototipos

52. El modelo en espiral
El modelo en espiral que Boehm propuso
originalmente, es un modelo de proceso de
software evolutivo que conjuga la
naturaleza iterativa de la construcción de
prototipos con los aspectos controlados y
sistemáticos del modelo en cascada.
Proporciona el material para el desarrollo
rápido de versiones incrementales del
software.

53. comunicación
Planeación
construcción
despliegue
modelado
Entrega
retroalimentación
Codigo
construcción
Analisis
diseño
Estimación
Itinerario
Analisis de riesgos
Reingeniería
Mantenimiento
de la Aplicación
Mejora de
la Aplicación
Desarrollo de
la Nueva Aplicación
Desarrollo del
concepto

54. profe@IvanMercado.com