REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN UNIVERSITARIA

UNIVERSIDAD POLITÉCNICA TERRITORIAL DE PUERTO CABELLO
PNF EN INFORMÁTICA, TRAYECTO II, TRIMESTRE I, SECCIÓN 2-70

Docente: Autores:
Ing. Marisela Materano Jeanny Flores, V-30.864.924
José Gudiño, V-29.648.425
Lugilmar Hernández, V-30.241.424
María Méndez, V-30.097.514
Endismar Sambrano, V-31.514.586

Puerto Cabello, 31 de mayo de 2023

 INTRODUCCIÓN

La metodología nos manda, nos abraza, nos permite poner límites. La creación de software
complejo requiere mucho esfuerzo: tecnología, dinero y, lo que es más importante,
personas. Las personas que interactúan entre sí tienen diferentes niveles de conocimiento,
diferentes roles y diferentes intereses. La metodología ofrece un programa de trabajo que
nos permite entender nuestro papel en el proyecto, proporcionando cierta sensación de paz
y seguridad. Sin flujo, no sabemos cómo empezar y cuándo parar.
El método describe las estrategias de encuentro de los proyectos del sistema para los que
define:
 Un conjunto de actividades o tareas consideradas necesarias para la implementación
exitosa de un proyecto.
 Un conjunto de roles que describe cómo se distribuyen las responsabilidades y
actividades entre las personas involucradas en un proyecto.
 Conjunto de entregables o artefactos que resultan del trabajo de cada actividad, ya
sean parte del producto final o elementos intermedios que permiten la comunicación
y coordinación entre diferentes actividades o roles.
 Un ciclo de vida que describe cómo se organizan las diferentes actividades a lo
largo del tiempo.
 Un conjunto de procesos que describen cómo se toman las decisiones, se
distribuyen las actividades entre las personas, se gestionan los riesgos, etc.
El análisis de sistemas es la ciencia encargada del análisis de sistemas grandes y complejos
y la interacción entre esos sistemas. Esta área se encuentra muy relacionada con la
Investigación de operaciones. También se denomina análisis de sistemas a una de las etapas
de construcción de un sistema informático, que consiste en relevar la información actual y
proponer los rasgos generales de la solución futura.
El presente trabajo a continuación, entrega una investigación profunda acerca de la
metodología del diseño de sistemas, dando así, un enfoque y un espacio para la
comprensión de la misma área.
 METODOLOGÍA DE DISEÑO DEL SISTEMA

Los métodos se pueden definir como estrategias, procedimientos y técnicas para dirigir
acciones hacia metas específicas, es decir, consisten en acciones específicas y precisas para
lograr un resultado o meta específica. Es un conjunto de procedimientos que ayudan a
alcanzar un objetivo, es decir, se trata de varios pasos que se siguen hasta llegar a una meta,
por ello se enfatiza que el método se puede aplicar en diferentes áreas de la vida cotidiana y,
no solamente en el conocimiento científico, si bien es cierto que permite
generar conocimiento.
La metodología es un marco que proporciona soporte para métodos. En otras palabras, la
metodología incluye el examen del procedimiento, la actividad realizada por los
investigadores y el análisis de los instrumentos utilizados. La metodología en este sentido es
normativa, es decir, da sentido a los métodos, lo que la hace también descriptiva y
comparativa, analizando los métodos, y es posible conocer las ventajas y desventajas de cada
método individual. Esto significa que la metodología es un campo de estudio con conceptos
relacionados con la investigación académica y científica.
OBJETIVOS Y TIPOS DE METODOLOGÍAS
Objetivos de las metodologías
 Definir actividades a llevar a cabo en un proyecto de S.I.
 Unificar criterios en la organización para el desarrollo de S.I.
 Proporcionar puntos de control y revisión.
Tipos de Metodologías
 Estructurada.
 Evolutiva-Incremental.
 Prototipos.
 Orientada a objetos.

PROCESO DE DESARROLLO DE SOFTWARE

Es el método que utilizamos para construir cualquier tipo de aplicación informática y
especifica las etapas que debe completar el equipo de desarrollo, la disciplina de desarrollo
que debe realizar cada etapa y cómo se organizará el mantenimiento después de la
finalización. desarrollado.
Dadas las aplicaciones de hoy, puedes pensar en juegos, procesadores de texto, desarrollo
de aplicaciones, comprenderás que el proceso de desarrollo puede ser extenso y complejo,
ya que implica crear software, gestionar equipos de desarrollo y múltiples disciplinas a
seguir. Por supuesto, no todas las aplicaciones se crean con la misma complejidad, pero el
hecho es que incluso para proyectos pequeños y medianos, los beneficios que se pueden
obtener a través del proceso de desarrollo de aplicaciones son importantes porque nos
ayudarán a aumentar sus posibilidades de éxito.
A continuación, se presentan las etapas del SDLC para obtener una visión general del
proceso de desarrollo:
1. Planificación y recopilación de requisitos
El cliente describe un problema a resolver como base para cumplir con el resto de los
requisitos del software. Los documentos de requisitos se generan a partir de los datos
obtenidos de los clientes y usuarios (si corresponde) para garantizar que el equipo de
desarrollo comprenda lo que está construyendo. Si está subcontratando un proyecto de
software, este es un paso que no debe omitir.
Pruebas unitarias:
Luego viene la preparación, como la asignación de tareas a los equipos, el establecimiento
de hitos, el establecimiento de fechas de entrega, la obtención de estimaciones de costos, la
realización de análisis de riesgos y el desarrollo de estrategias de mitigación de riesgos.
Este paso implica desarrollar una prueba de concepto y probar y validar la viabilidad
técnica antes del proceso de desarrollo de software.

2. Diseñar
Esta es la segunda fase del ciclo de vida del desarrollo de software e incluye el desarrollo
de la arquitectura, la creación de prototipos y el diseño de la experiencia del usuario. Aquí
hay una descripción general rápida de lo que necesitará en esta etapa:
 Arquitectura de software: Se refiere al proceso de establecer una cadena ordenada
de elementos en un programa de software para el control de calidad, la legibilidad y
la accesibilidad. Se puede pensar en la arquitectura del software como el plano del
equipo de desarrollo.
 Prototipo: El equipo de interfaz de usuario/experiencia de usuario (UI/UX) del
software crea una edición prototipo del programa para verificar su aspecto y el flujo
de los elementos de diseño del software. Permite al equipo y a las partes interesadas
imaginarse el aspecto visual del software.

3. Desarrollar
La siguiente etapa es la fase de codificación, en la que los desarrolladores de software
trabajan para hacer realidad su idea. Los desarrolladores de software escriben KLOC (miles
de líneas de código) en lenguajes de programación con los que están familiarizados. El
objetivo del equipo de desarrollo es aumentar la velocidad de los desarrolladores
manteniendo una alta calidad
El equipo de desarrollo de software puede optar por lanzar el programa de una sola vez,
como se hace en el desarrollo en cascada, o puede dividirlo en partes (segmentos) y
entregarlas por separado (enfoque ágil). Una vez completado el código, el equipo de
desarrollo lo entrega al equipo de pruebas para su evaluación.

4. Pruebas y garantía de calidad

Esta etapa del proceso de desarrollo de la aplicación se ocupa de validar el código escrito
en busca de errores y otras irregularidades. Luego se realizan las pruebas y el equipo de
control de calidad trabaja en conjunto para verificar e informar errores al equipo. Los
equipos de prueba pueden utilizar métodos asistidos o pruebas automatizadas (dependiendo
de sus habilidades y procedimientos establecidos). En este caso, los evaluadores trabajan
con el equipo para garantizar una entrega de software sin problemas.

5. Despliegue
Una vez que el software se crea, prueba, modifica, vuelve a probar y certifica en
condiciones de producción, se implementa en un entorno de producción. Si utiliza el
enfoque ágil de SDLC para el desarrollo y la implementación, puede consultar la
implementación de MVP y otras características. Pero cuando se trata de Waterfall, la
implementación se refiere a llevar un producto completamente funcional al mercado. Si el
usuario encuentra algún problema con el programa, lo devuelve al equipo de software para
su revisión y corrección.

LA COMPLEJIDAD DE LOS SISTEMAS DE SOFTWARE

Podemos hablar de dos vistas de la complejidad de un producto de software: la externa, que

tiene que ver con el problema que resuelve el sistema (el proceso de negocio); y la interna,
que se refiere a la manera como está programada la solución. En la interna podemos
distinguir al menos los siguientes aspectos:
 Su tamaño: Entre más grande sea un producto, mayor será su complejidad. Una
métrica de tamaño (bastante primitiva, pero muy accesible y común) son las líneas
de código (LCs).
 Su estructura.
Según Grady Booch, la complejidad de los sistemas de software se deriva de cuatro
elementos:
 1. La complejidad del dominio del problema.
Los problemas que se intentan resolver son inherentemente complejos, con una gran
cantidad de requisitos que compiten entre sí.
2. La dificultad de gestionar el proceso de desarrollo.
Los desarrolladores de software enfrentan el reto de dar a los usuarios la impresión de
simplicidad, esto es reducir al mínimo la complejidad externa. Este reto les obliga a
incrementar el tamaño de los sistemas, a inventar mecanismos ingeniosos, o a reutilizar
diseños y código ya existentes.
3. La flexibilidad que se puede alcanzar a través del software.
La elaboración de software es una actividad muy laboriosa porque empuja al desarrollador
a construir por sí mismo prácticamente todos los bloques fundamentales sobre los que se
apoyan las abstracciones de más alto nivel. Esto es propiciado, en gran medida, por la
existencia de pocos estándares para el control de calidad.
4. Los problemas de caracterizar el comportamiento de sistemas discretos.
Los comportamientos de la mayoría de los objetos se representan por sistemas analógicos
en los que, a través de funciones contínuas, pequeños cambios en las entradas siempre
producen pequeños cambios en las salidas.
Por el contrario, puesto que el software se ejecuta en computadoras digitales, se tienen
sistemas con un número finito de estados discretos. En sistemas grandes, este número
puede crecer a cantidades enormes. Como no existen herramientas matemáticas para
modelar el comportamiento completo de los grandes sistemas discretos, se debe aceptar la
pérdida de cierto grado de confianza en cuanto a que las salidas sean correctas.

RECURSOS DE SOFTWARE EN SISTEMAS COMPLEJOS

Blanchard define un sistema como una combinación de recursos (como seres humanos,
materiales, equipos, software, instalaciones, datos, etc.) integrados de forma tal que
cumplan una función específica en respuesta a una necesidad designada de un usuario
Desde una perspectiva más amplia, un sistema se considerará como sistema de software
cuando sus recursos software constituyan su elemento básico y la fuente de su
funcionalidad básica. Dicho de otro modo, cuando en el proceso de desarrollo sean los
recursos software los que determinan el proceso general de desarrollo de todo el sistema y
cuando su ejecución pueda realizarse sobre una plataforma hardware genérica. Un sistema
de software Implica una interacción con el contexto al que sirve que constituye el referente
básico de su utilidad. Un sistema de software posee programas ejecutables, pero también
otros tipos de recursos (ficheros de datos, de documentación, etc.).
 Debemos tener claro lo que son recursos software y la definición de programas ya que
estos están inmersos en los sistemas de software. Llamamos recurso software a un
programa o conjunto de programas ejecutables que proporcione algunas de las funciones
requeridas por el sistema, Como definición de programa tenemos que un programa es un
algoritmo codificado junto con unas estructuras de datos. Algunas veces se emplea el
término paquete ejecutable para referirse a un conjunto de programas que se necesitan
mutuamente durante la ejecución del sistema y que deben distribuirse conjuntamente al
usuario final.
La complejidad de un sistema depende no sólo de las múltiples interacciones entre los
recursos de que consta sino también de la forma en la que puede evolucionar en respuesta a
las necesidades del entorno. Pues bien, el control de la complejidad de un sistema depende
generalmente de las funciones dependientes de sus recursos software y de cómo éstas se
adapten al mundo externo
La ingeniería de sistemas de software pretende, justamente, incrementar la seguridad
absoluta de que se han Implementado fielmente los requisitos exigidos por el usuario y de
que el sistema se ejecuta correctamente, esta seguridad debe existir durante el proceso de
desarrollo hasta alcanzar un nivel de confianza similar al existente en otras ingenierías.
Desde el punto de vista del diseñador y operador humano se conjugan, por tanto, dos
propiedades que actúan como una espada de Damocles durante toda su vida útil: la
incertidumbre de lo que realmente harán y la ignorancia en cómo lo consiguen. Reducirlas
y dominarlas ha constituido la directriz básica en la evolución de la Ingeniería Software
durante el último cuarto de siglo.
CARACTERÍSTICAS DE LOS SISTEMAS DE SOFTWARE

Hace referencia a los factores de funcionalidad del software, a la manera en que se

presenta:
 Usabilidad: relacionado a la facilidad de uso del software.
 Corrección: el grado de satisfacción que tenga el usuario con los programas.
 Fiabilidad: nivel de fallas (que por supuesto deben ser nulas o mínimas).
 Integralidad: la calidad del software.
 Eficiencia: el grado de eficacia de los recursos disponibles.
 Seguridad: hace alusión a las medidas de seguridad para proteger los datos del
usuario.

INGENIERÍA DE LOS SISTEMAS DE SOFTWARE

La ingeniería de software es una de las ramas de la informática que se ocupa de la creación
de software confiable y de calidad basado en métodos y técnicas y brinda soporte en la
operación y mantenimiento. El campo de estudio de la ingeniería de software integra las
ciencias de la computación, las ciencias aplicadas y las ciencias fundamentales en las que
se basa la ingeniería. Se citan las definiciones más aceptables formuladas por los siguientes
autores destacados:
 La ingeniería de software es el estudio de los principios y métodos de desarrollo y
mantenimiento de sistemas de software (Zelkovitz, 1978).
 La ingeniería de software es la aplicación práctica del conocimiento científico en el
diseño y construcción de programas de computadora, así como la documentación
relacionada requerida para su desarrollo, operación y mantenimiento. También se le
llama desarrollo de software o producción de software (Bohem, 1976).
 La ingeniería de software involucra la identificación de principios y métodos
técnicos para producir software de manera rentable que sea confiable y funcione en
máquinas reales (Bauer, 1972).
 La ingeniería de software es la aplicación de métodos sistemáticos, disciplinados y
cuantificables para el desarrollo, operación y mantenimiento de software. Glosario
estándar de términos de ingeniería de software.
En 2004 en Los Ángeles, EE. UU. La Oficina de Estadísticas Laborales tiene 760.840
ingenieros de software informático. Sin embargo, el término "ingeniero de software" se usa
comúnmente en un entorno empresarial, y no todos los que desempeñan el papel de
ingeniero de software en realidad tienen un título de ingeniería de una universidad
reconocida.
Algunos autores han argumentado que "desarrollo de software" es un término más
apropiado que "ingeniería de software" para el proceso de creación de software. Personas
como Pete McBreen (autor de Software Craftmanship) argumentan que el término IS
significa rigor y pruebas de procesos y no es adecuado para todo tipo de desarrollo de
software.
Los términos "ingeniería de software" o "ingeniería de software" se usan indistintamente;
aunque es menos común, también se le conoce como "ingeniería de software". [6][7][8] En
América Latina, los términos más utilizados son los dos primeros. El desarrollo de software
es inherentemente un proceso creativo, y la ingeniería de software intenta sistematizar este
proceso utilizando una variedad de métodos que han demostrado empíricamente que son
suficientes para limitar el riesgo de no alcanzar los objetivos.
La ingeniería de software se puede considerar como ingeniería aplicada al software, es
decir, con medios sistemáticos y herramientas preestablecidas, aplicándolos de la manera
más eficiente para lograr los mejores resultados; un objetivo hacia el cual la ingeniería
siempre se esfuerza. No se trata solo de resolver el problema, sino de elegir la solución más
adecuada, teniendo en cuenta diferentes soluciones. La ingeniería de software utiliza
principios y estándares de ingeniería de software para transformarlos en productos
industriales utilizando fundamentos de ingeniería como métodos, técnicas y herramientas
para desarrollar productos innovadores basados en métodos y buenas prácticas.
 Un producto es un medio de intervenir en las funciones de sus usuarios para lograr un
proceso de producción más eficiente y eficaz; hoy en día, los negocios no pueden funcionar
sin software, ya que es un producto ampliamente utilizado; por tanto, el nivel de la empresa
depende de la calidad de su infraestructura tecnológica y de los productos desarrollados u
obtenidos según las necesidades.

CICLO DE VIDA DE UN SOFTWARE

El ciclo de vida del desarrollo del software (también conocido como SDLC o Systems
Development Life Cycle) contempla las fases necesarias para validar el desarrollo del
software y así garantizar que este cumpla los requisitos para la aplicación y verificación de
los procedimientos de desarrollo, asegurándose de que los métodos usados son apropiados.
Su origen radica en que es muy costoso rectificar los posibles errores que se detectan tarde
en la fase de implementación. Utilizando metodologías apropiadas, se podría detectar a
tiempo para que los programadores puedan centrarse en la calidad del software, cumpliendo
los plazos y los costes asociados.
Aunque existen diferentes ciclos de desarrollo de software, la normativa ISO/IEC/IEEE
12207:2017 establece:
“Un marco común para los procesos del ciclo de vida de los programas informáticos, con
una terminología bien definida, a la que pueda remitirse la industria del software. Contiene
procesos, actividades y tareas aplicables durante la adquisición, el suministro, el desarrollo,
el funcionamiento, el mantenimiento o la eliminación de sistemas, productos y servicios
informáticos. Estos procesos del ciclo de vida se llevan a cabo mediante la participación de
los interesados, con el objetivo final de lograr la satisfacción del cliente”.
Las principales etapas que forman el ciclo de vida de desarrollo de software son:

 Planificación
En esta fase se incluyen tareas como la determinación del ámbito del proyecto, un estudio
de viabilidad, análisis de riesgos, costes estimados, asignación de recursos en las distintas
etapas, etc. Son tareas que influyen en el éxito del proyecto, por eso es necesaria una
planificación inicial.

 Análisis
Proceso en el que se trata de descubrir lo que se necesita y cómo llegar a las características
que el sistema debe poseer.

 Diseño
Se estudian las posibles implementaciones que hay que construir y la estructura general del
software. Es una etapa complicada, y si la solución inicial no es la más adecuada, habrá que
redefinirla.
  Implementación
Se trata de elegir las herramientas adecuadas, un entorno de desarrollo que haga más
sencillo el trabajo y el lenguaje de programación óptimo. Esta decisión va a depender del
diseño y el entorno elegido. Es importante tener en cuenta la adquisición de productos
necesarios para que el software funcione.
 Pruebas
Conseguiremos detectar los fallos que se hayan cometido en etapas anteriores, para que no
repercuta en el usuario final. Esta fase del ciclo de vida del software hay que repetirla tantas
veces como sea necesaria, ya que la calidad y estabilidad final del software dependerá de
esta fase.
 Instalación
En esta fase pondremos el software en funcionamiento.

 Uso y mantenimiento
Este es un momento crucial dentro del ciclo de vida de un software.
Dentro del mantenimiento se pueden distinguir tres puntos importantes:
 Correctivo: Eliminar defectos que se van detectando.
 Adaptativo: Adaptarlo a nuevas necesidades.
 Perfectivo: Añadir nuevas funcionalidades.

MODELOS DE DISEÑOS DE SOFTWARE

Son colecciones de técnicas y sistemas organizacionales utilizados para crear software de
computadora. Diferentes enfoques apuntan a estructurar grupos de trabajo para que puedan
construir la funcionalidad del programa de la manera más eficiente. Un modelo de
desarrollo de software proporciona un marco para guiar el desarrollo de sistemas de
información. El ciclo de vida de desarrollo de software (SDLC) describe todos los procesos
de un proyecto de desarrollo de software, desde la planificación hasta el mantenimiento.
Este marco incluye el desarrollo del programa y las herramientas necesarias para ayudar en
el proceso de desarrollo.
Según la tecnología de desarrollo elegida, la reducción de la codificación manual, el
aumento de la reutilización, la prevención de infracciones de seguridad y la reducción de la
necesidad de infraestructura de TI son solo algunos de los objetivos a abordar.
Claramente, comprender este tipo de ciclo de vida del proyecto significa comprender que
una vez que se elige un modelo de desarrollo de software y una metodología de
programación, se deben completar muchos pasos y fases adicionales antes de que se pueda
entregar el producto final: el análisis., diseño, desarrollo, integración y pruebas, adopción,
implementación y mantenimiento.

MODELO CASCADA
Este es un ejemplo de cómo organizar estratégicamente las fases de desarrollo de software
para que la actividad anterior se complete antes de que comience la fase de desarrollo. Una
de sus ventajas es que funciona para clientes que comprenden los amplios usos del
producto, mientras que el equipo de desarrollo tiene una mejor comprensión de cómo
interactúan los clientes con el software y el entorno en el que se llevará a cabo.
Fases del Modelo Cascada:
 Fase de análisis: Planificación, análisis y especificación de los requisitos.
 Fase de diseño: Diseño y especificación del sistema.
 Fase de implementación: Programación y pruebas unitarias.
 Fase de Verificación: Integración de sistemas, pruebas de sistema e integración.
 Fase de implementación: Despliegue de Sistemas
 Fase de mantenimiento: Entrega, mantenimiento y mejora.
¿Cuándo usar el Modelo Cascada?
1. Cuando tienes una idea clara de cómo quieres que sea el resultado final.
2. Cuando los clientes no pueden alterar el alcance de un proyecto una vez que ha
comenzado.
3. Cuando se trata de éxito, el concepto y la definición son cruciales (pero no la
velocidad).

MODELO INCREMENTAL E ITIRERATIVO

El desarrollo de software iterativo e incremental es una técnica de desarrollo de software
basada en un patrón cíclico de lanzamiento y actualización y un aumento constante en la
adición de funciones.
El desarrollo de software iterativo e incremental comienza con la planificación y continúa
a través de ciclos de desarrollo iterativos con comentarios continuos de los usuarios y
adiciones de funciones incrementales, que culminan en la implementación del software al
final de cada ciclo.
Fases del Modelo Incremental e Iterativo:
Los siguientes pasos se pueden utilizar para clasificar el desarrollo iterativo e incremental:
 Fase de Iniciación: La fase de iniciación de un proyecto se ocupa del alcance, las
necesidades y los peligros a un nivel superior.
  Fase de Elaboración: Crea una arquitectura viable que mitiga los riesgos
identificados en la primera fase y cumple con los criterios no funcionales.
 Fase de construcción: Gradualmente completa los componentes de la arquitectura
con código listo para la producción, que se desarrolla mediante el análisis, la
implementación, el diseño y las pruebas de los requisitos funcionales.
 Fase de transición: Entregar el sistema al entorno operativo de producción durante
la fase de transición.
¿Cuándo usar el Modelo Incremental e Iterativo?
El modelo incremental e iterativo se puede utilizar en las siguientes situaciones:
 Se requiere una entrega rápida de la funcionalidad crítica.
 Hay una nueva innovación tecnológica que se puede utilizar para llevar a cabo un
proyecto.
 El grupo de trabajo no está familiarizado con el dominio.
 Hay una corporación que tiene grandes aspiraciones de mejora.

MODELO BASADA EN PROTOTIPOS DESECHABLES

Al crear un software o aplicación, es típico utilizar un modelo prototipo para ofrecer una
versión anterior y funcional que pueda utilizarse como presentación o muestra del proyecto.
La creación de prototipos es una excelente manera de recibir información sobre los
requisitos, la funcionalidad y la operatividad, de modo que el desarrollo final del producto
pueda avanzar de manera más rápida y eficiente.
A modelo prototipo es una aplicación funcional del producto que da una idea de las
características fundamentales del producto o sistema final.
Fases del Modelo Prototipo:
 Análisis de requisitos: El paso inicial del modelo trata de establecer los requisitos
del sistema deseable.
 Diseño: Después de la identificación de los requisitos del sistema deseado, se forma
un diseño conceptual básico.
 Formación de prototipos: Con la ayuda del diseño conceptual básico, se construye
un prototipo de trabajo para el sistema deseado.
 Evaluación inicial: El prototipo es probado por el cliente en este paso para evaluar
funcionalidades y limitaciones.
 Prototipo de refinación: El prototipo se refina aún más, analizando la evaluación
realizada por el cliente.
  Producción: Una vez que se ejecuta el proceso de refinación, se produce el sistema
final para su uso en tiempo real.
¿Cuándo usar el Modelo Prototipo?
 Cuando el requisito del sistema deseado es inequívoco.
 Cuando aún no se han evaluado las funciones básicas del sistema deseado.
 Si es necesario cambiar los requisitos del sistema resultante.
 Mostrar las funcionalidades técnicas del producto deseado mediante la creación de
un prototipo.

MODELO ESPIRAL
El Modelo espiral es un tipo de Modelo de desarrollo de software en el que las actividades
se crean en espiral y se llevan a cabo en el orden en que se eligen en función del análisis de
riesgo. En cada iteración de este modelo, los objetivos o alternativas deben elegirse en
función de las características, que incluyen la experiencia personal, los criterios a satisfacer
y las formas de gestión del sistema.
La forma angular, que representa únicamente el desarrollo del software dentro del
proyecto, y la forma radial, que indica el crecimiento en costo ya que cada iteración tarda
más en terminar.
Fases del Modelo Espiral:
Las fases del modelo espiral son:
 Fase de planificación: El paso inicial es identificar y establecer objetivos y metas a
alcanzar. Luego, como alternativas, presentan las mejores formas potenciales de
satisfacer los objetivos. Todo esto requiere una comunicación continua entre el
cliente y el equipo de gestión del proyecto.
 Fase de análisis de riesgos: Al planificar y finalizar la estrategia de reducción de
riesgos, se identifican los posibles peligros. Cada peligro destacado se somete a un
examen exhaustivo. Se pueden crear prototipos para eliminar la posibilidad de
requisitos ambiguos. Los riesgos se minimizan tomando precauciones.
 Fase de ingeniería: Implica la codificación, prueba e implementación del software.
Tras una evaluación de riesgos, se adopta el modelo de desarrollo. El modelo a
utilizar está determinado por el nivel de riesgo que se ha reconocido para esa fase.
 Fase de evaluación: Valoración del cliente sobre el programa. Se decide si repetir o
no el ciclo. Aquí se está planificando la siguiente fase del proyecto.
¿Cuándo usar el Modelo Espiral?
Las ventajas del modelo en espiral son más evidentes en situaciones en las que:
  Es deseable tener lanzamientos de software frecuentes.
 Se utilizan prototipos.
 La gestión de riesgos y gastos es fundamental.
 En proyectos de riesgo medio-alto y riesgo alto.
 Los criterios de requisitos son ambiguos y difíciles de entender.
 Se están produciendo muchos cambios, y pueden ocurrir en cualquier momento.
 Ya sea por razones económicas o de otro tipo, el compromiso del proyecto a largo
plazo se ve comprometido.

IWEB
Esta metodología consta de seis etapas que manejan un proceso incremental y evolutivo, lo
que la convierte en un modelo eficiente para el desarrollo de sistemas web. Las siguientes
secciones brindan una descripción detallada de cada etapa.
1. Formulación
En la etapa de Formulación se identifican las metas y los objetivos del sistema,
estableciendo de este modo la motivación del desarrollo del sistema, su importancia y los
usuarios potenciales.
2. Planificación
En la etapa de planificación, se estima el costo global del proyecto y se evalúan los riesgos
asociados con el esfuerzo del desarrollo, y se define una planificación del desarrollo muy
detallada para el incremento final de la aplicación. De esta manera la planificación para los
incrementos siguientes es más específica.
3. Análisis
En esta etapa se establecen los requisitos técnicos y de diseño, e identificación de los
elementos de contenido que se van a incorporar. Durante esta etapa se realizan cuatro tipos
de análisis diferentes:
 Análisis del contenido: Se identifica el aspecto completo del contenido que se va a
proporcionar, este contenido incluye datos de texto, gráficos, imágenes, videos y
sonido, utilizando un modelado de datos.
 Análisis de la interacción: Se trata de la descripción detallada de la interacción del
usuario, a través de casos de uso prácticos.
 Análisis funcional: Los casos de uso descritos en el análisis anterior, definen
operaciones y funciones que se aplican al contenido del sistema, las cuales se
detallan.
 Análisis de la configuración: Se realiza una descripción detallada del entorno y de
la infraestructura del sistema.
 4. Ingeniería
En esta etapa se realizan las tareas diseño del contenido y producción, en paralelo con los
diseños arquitectónicos, navegación e interfaz.
 Diseño arquitectónico: Este diseño se realiza en paralelo con el diseño del
contenido, en los cuales se centra en el diseño de la estructura global del sistema, así
como en las configuraciones del diseño y plantillas.
 Diseño de navegación: Se identifica la semántica y la sintaxis de la navegación,
identificando los diferentes perfiles que se establecieron y que navegación tiene
cada uno de ellos.
 Diseño de la interfaz: En este diseño se realizan todos los ajustes para que la
interfaz de usuario sea la ideal, evitando factores como que el usuario abandone el
sitio web, el tamaño del texto, etc.
 Diseño del contenido y de la producción: Son tareas que se llevan a cabo por
personas no técnicas, el propósito de éste, es el de diseñar o adquirir todo el
contenido de texto, gráfico, imágenes y video que se van a utilizar en el sistema.

5. Generación de páginas.
En esta etapa se realiza la construcción haciendo uso de las herramientas para el desarrollo
de aplicaciones web, sistemas y se asocia con el diseño arquitectónico, de navegación y de
interfaz para la elaboración de web dinámicas.
6. Pruebas.
En esta etapa se busca descubrir errores y ayuda a asegurar que la aplicación web
funcionará correctamente en diferentes entornos. Para esto se hace uso de estrategias y
técnicas que hayan sido recomendadas para otros sistemas.
 El modelo del contenido, es una prueba que se realiza para detectar errores
ortográficos.
 El modelo del diseño, es revisado para descubrir errores en la navegación, en este
caso se proponen escenarios para descubrir lo posibles errores.
 Las pruebas de unidad se realizan a cada página para encontrar errores más
específicos.
 Las pruebas de integración, evalúan la estructura que se definió en la arquitectura
que se haya elegido para el sistema.
 Unas pruebas comunes son las de validación, las cuales se basan en casos prácticos
proporcionando escenarios con una probabilidad alta de cubrir todos los errores.
 En las pruebas de compatibilidad y configuración, se definen todas las posibles
plataformas de hardware para los navegadores donde se visualizará el sistema y los
protocolos de comunicación.
  Las pruebas de control y monitorización se aplican a todos los usuarios posibles del
sistema y se evalúan los resultados de su interacción con el sistema.

7. Evaluación del cliente.

En esta etapa es donde se realizan todas las correcciones y cambios que se detectaron en la
etapa de pruebas y se integran al sistema para el siguiente incremento, de tal modo que se
asegure la satisfacción por parte del cliente, según los requerimientos solicitados. Diagrama
del ciclo de vida de la metodología iWeb. Adicional a la evaluación en esta etapa se realiza
la transferencia tecnológica del sistema desarrollado, es decir, se realiza el alojo en
servidores o en los equipos que para ello el cliente considere pertinente.

EL PROCESO UNIFICADO RACIONAL (RUP)

La Proceso Racional Unificado (RUP) es un desarrollo de aplicaciones de software enfoque
que incluye una serie de herramientas para ayudar en la codificación del producto final y
las actividades que lo acompañan. RUP es una metodología orientada a objetos para gestión
de proyectos y desarrollo de software de alta calidad.
El RUP es un conjunto de enfoques ajustables al entorno y exigencias de cada empresa,
más que un sistema con procesos rígidos.
Fases del modelo Rational Unified Process (RUP):
 Comienzo: Se visualiza la idea central.
 Elaboración: Se diseñan los casos de uso y la arquitectura.
 Construcción: Actividades desde el diseño hasta el producto terminado.
 Transición: Seguimiento de actividades para asegurar la satisfacción del cliente.
¿Cuándo usar el modelo RUP?
 Cuando hay un cambio constante en los requisitos.
 Cuando se dispone de información y datos veraces.
 Cuando necesitas ciertas integraciones a lo largo del proceso de desarrollo.

LENGUAJE UNIFICADO DE MODELADO (UML)

El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de

modelado visual común y semántica y sintácticamente rico para la arquitectura, el diseño y
la implementación de sistemas de software complejos, tanto en estructura como en
comportamiento. Es comparable a los planos usados en otros campos y consiste en
diferentes tipos de diagramas. En general, los diagramas UML describen los límites, la
estructura y el comportamiento del sistema y los objetos que contiene.
UML no es un lenguaje de programación, pero existen herramientas que se pueden usar
para generar código en diversos lenguajes usando los diagramas UML. UML guarda una
relación directa con el análisis y el diseño orientados a objetos.

DIAGRAMAS DE CASOS DE USO

Representa una funcionalidad particular de un sistema. Se crea para ilustrar cómo se
relacionan las funcionalidades con sus controladores (actores) internos/externos.
Un caso de uso es una lista de pasos que definen la interacción entre un actor (un humano
que interactúa con el sistema o un sistema externo) y el sistema propiamente dicho. Los
diagramas de casos de uso representan las especificaciones de un caso de uso y modelan las
unidades funcionales de un sistema. Estos diagramas ayudan a los equipos de desarrollo a
comprender los requisitos de su sistema, incluida la función de la interacción humana en el
mismo y las diferencias entre diversos casos de uso. Un diagrama de caso de uso podría
mostrar todos los casos de uso del sistema o solo un grupo de casos de uso con una
funcionalidad similar.
1. Para iniciar un diagrama de casos de uso, agrega una forma ovalada en el centro del
dibujo.
2. Escribe el nombre del caso de uso dentro del óvalo.
3. Representa a los actores con una figura humana cerca del diagrama, luego usa líneas
para modelar las relaciones entre los actores y los casos de uso.

DIAGRAMA DE SECUENCIA
Los diagramas de secuencia, también conocidos como diagramas de eventos o escenarios
de eventos, ilustran cómo los procesos interactúan entre sí mostrando llamadas entre
diferentes objetos en una secuencia. Estos diagramas tienen dos dimensiones: vertical y
horizontal. Las líneas verticales muestran la secuencia de mensajes y llamadas en orden
cronológico y los elementos horizontales muestran instancias de objetos en las que se
transmiten los mensajes.
1. Para crear un diagrama de secuencia, escribe el nombre de la instancia de clase y el
nombre de la clase en un cuadro rectangular.
2. Dibuja líneas entre las instancias de clases para representar al emisor y receptor de
los mensajes.
3. Usa puntas de flecha oscuras para simbolizar mensajes sincrónicos, puntas de flecha
abiertas para mensajes asincrónicos y líneas discontinuas para mensajes de
respuesta.
 DIAGRAMA DE COLABORACIÓN
El Diagrama de Colaboración presenta una alternativa al diagrama de secuencia para
modelar interacciones entre objetos en el sistema. Mientras que el diagrama de secuencia se
centra en la secuencia cronológica del escenario que estamos modelando, el diagrama de
colaboración se centra en estudiar todos los efectos de un objeto dado durante un escenario.
Los objetos se conectan por medio de enlaces, cada enlace representa una instancia de una
asociación entre las clases implicadas. El enlace muestra los mensajes enviados entre los
objetos, el tipo de mensaje (sincrónico, asincrónico, simple, blanking, y 'time-out'), y la
visibilidad de un objeto con respecto a los otros.
Un uso de un diagrama de colaboración es mostrar la implementación de una operación. La
comunicación muestra los parámetros y las variables locales de la operación, así como
asociaciones más permanentes. Cuando se implementa el comportamiento, la secuencia de
los mensajes corresponde a la estructura de llamadas anidadas y el paso de señales del
programa. Es útil marcar los objetos en cuatro grupos: los que existen con la interacción
entera; los creados durante la interacción (restricción {new}); los destruidos durante la
interacción (restricción {destroyed}); y los que se crean y se destruyen durante la
interacción (restricción {transient}).
Aunque las comunicaciones muestran directamente la implementación de una operación,
pueden también mostrar la realización de una clase entera. En este uso, muestran el
contexto necesario para implementar todas las operaciones de una clase. Esto permite que
el modelador vea los roles múltiples que los objetos pueden desempeñar en varias
operaciones.

DIAGRAMA DE ESTADOS
Un diagrama de estado UML (también llamado diagrama de estado, diagrama de transición
de estados o diagrama de máquina de estados) muestra los estados por los que pasa una
máquina de estados finitos, es decir, un modelo de comportamiento que consiste en
acciones y estados o transiciones a otros estados. El diagrama proporciona un estado inicial
y uno final, así como al menos un estado intermedio para cada objeto. El diagrama de
estado permite, de este modo, representar el ciclo de vida completo de cualquier sistema,
subsistema o componentes o clases del mismo, como podrían ser una máquina de café, un
lector de libros electrónicos o un componente tecnológico de un vehículo.
¿Para qué sirve?
Como ya hemos mencionado, el objetivo de los diagramas de estado es describir el
comportamiento de un sistema con la máxima precisión. Entre otras cosas,
esta representación gráfica de los procesos debería dar respuesta a las siguientes preguntas:
 ¿Qué sucede cuando el objeto está en un estado concreto?
  ¿En qué estado debe estar el objeto para cambiar de comportamiento?
 ¿Cuáles son los desencadenantes?
 ¿Qué propiedades debe tener el objeto para poder cambiar de estado?
Por lo tanto, los diagramas de estado UML se utilizan para optimizar cualquier proceso de
desarrollo donde sea útil visualizar los estados del objeto y las condiciones para que se
produzca la transición de un estado a otro. Suelen emplearse, por ejemplo, en el diseño de
sistemas embebidos (en inglés, embedded systems), donde las señales automatizadas y los
procesos en segundo plano deben estar perfectamente coordinados. En este caso, el
diagrama de estado ayuda a los desarrolladores a visualizar todas las funciones de control y
regulación más importantes en un solo esquema.

DIAGRAMA DE ACTIVIDADES
Los diagramas de actividades, junto con los diagramas de casos de uso y los diagramas de
máquinas de estados, se consideran diagramas de comportamiento porque describen lo que
debe suceder en el sistema modelado. Las partes interesadas tienen mucho con lo que lidiar,
por lo que es importante una comunicación clara y concisa. Los diagramas de actividad
ayudan a las personas de las áreas de negocios y desarrollo de una organización a unirse
para comprender los mismos procesos y comportamientos.
Beneficios de los diagramas de actividades
Los diagramas de actividades presentan una serie de beneficios para los usuarios. Considera
crear un diagrama de actividades para:
 Demostrar la lógica de un algoritmo.
 Describir los pasos realizados en un caso de uso UML.
 Ilustrar un proceso de negocios o flujo de trabajo entre los usuarios y el sistema.
 Simplificar y mejorar cualquier proceso clarificando casos de uso complicados.
 Modelar elementos de arquitectura de software, tales como método, función y
operación.
Componentes básicos de un diagrama de actividades
Antes de empezar a crear un diagrama de actividades, debes comprender primero su
composición. Algunos de los componentes más comunes de un diagrama de actividades
incluyen:
 Acción: Un paso en la actividad en el que los usuarios o el software realizan una
tarea dada.
 Nodo de decisión: Una rama condicional en el flujo que se representa con un
diamante. Incluye una sola entrada y dos o más salidas.
 Flujos de control: Otro nombre para los conectores que muestran el flujo entre
pasos en el diagrama.
  Nodo inicial: Simboliza el inicio de la actividad. El nodo inicial se representa con
un círculo negro.
 Nodo terminal: Representa el paso final en la actividad. El nodo terminal se
representa por medio de un círculo negro de contorno blanco.

TIPO DE DEPENDENCIA
Es la Relación (más débil que una asociación) que muestra la relación entre un cliente y el
proveedor de un servicio usado por el cliente.
 Cliente es el objeto que solicita un servicio.
 Servidor es el objeto que provee el servicio solicitado.
Gráficamente, la dependencia se muestra como una línea discontinua con una punta de
flecha que apunta del cliente al proveedor.
Ejemplo
Resolución de una ecuación de segundo grado

Para resolver una ecuación de segundo grado hemos de recurrir a la función sqrt de la clase
Math para calcular una raíz cuadrada.
NOTA: La clase Math es una clase “degenerada” que no tiene estado. Es, simplemente,
una colección de funciones de cálculo matemático.

TIPO DE ASOCIACIÓN
Las asociaciones se utilizan para representar los vínculos familiares y significan la relación estática
entre clases. Conecta estructuralmente dos o más clasificadores y enumera sus atributos,
propiedades y asociaciones. Las asociaciones están representadas por una línea sólida trazada entre
los dos clasificadores.
Las asociaciones se dividen en cuatro tipos: asociación unidireccional, bidireccional, agregación y
composición.
1. Asociación unidireccional:

También conocida como asociación dirigida, este tipo de asociación se refiere a cuando un objeto
contiene otro objeto en su campo. Esta relación significa el flujo de información entre dos
clasificadores. La asociación está representada por una línea continua y una flecha que apunta hacia
el clasificador de contenedores.
2. Asociación bidireccional:

Esta asociación se utiliza cuando dos clasificadores están estrechamente vinculados y pueden
almacenarse entre sí en sus campos. Una línea continua representa la asociación. La asociación
bidireccional es el tipo de asociación más frecuente en los diagramas UML.
3. Agregación:

La agregación es un tipo de asociación más específico y muestra la relación "parte de" en los
diagramas. Sin embargo, este tipo solo puede vincular dos clasificadores y debe tener una
asociación binaria. En los diagramas UML, está representado por una línea sólida y un diamante
hueco cerca de la clase contenedora.
4. Composición:

Este tipo de relación se utiliza para representar la dependencia de los objetos de la entidad focal. El
clasificador focal contiene objetos, pero los objetos contenidos también se eliminan si se elimina la
clase focal. Las relaciones de composición están representadas por una línea sólida y una forma de
diamante relleno dibujada cerca de la clase contenedora.
 GENERALIZACIÓN

En el modelado UML, la generalización se utiliza para representar las relaciones de la clase

principal y la clase secundaria. Se puede ver una "especie de" relación entre los
clasificadores y cómo una entidad se basa en la otra, heredando los atributos, las
operaciones y las relaciones de los padres.
El modelo de padres puede tener muchas clases secundarias y, del mismo modo, una clase
secundaria puede tener varios modelos principales. En un diagrama UML, las
generalizaciones se muestran con una línea sólida, con una flecha vacía que apunta desde la
clase secundaria a la clase principal.

REALIZACIÓN

Es una relación que vincula dos elementos del modelo con un clasificador
realizando/implementando el comportamiento de otro clasificador. La relación de
realización ayuda a comprender cómo afecta la interfaz a la clase de implementación. La
realización está representada por una línea discontinua con una flecha hueca.

SISTEMAS DE TIEMPO REAL

Un sistema de tiempo real es un sistema informático que interacciona con su entorno físico
y responde a los estímulos del entorno dentro de un plazo de tiempo determinado.[ Existen
sistemas de tiempo real crítico (tiempo real duro), en los que los plazos de respuesta deben
respetarse siempre estrictamente y una sola respuesta tardía a un suceso externo puede tener
consecuencias fatales; y sistemas de tiempo real acrítico (tiempo real suave), en los que se
pueden tolerar retrasos ocasionales en la respuesta a un suceso.
Un ejemplo general para los sistemas de tiempo real es el de un robot que necesita tomar
una pieza de una banda sinfín. Si el robot llega tarde, la pieza ya no estará donde debía
recogerla, por tanto, el trabajo se llevó a cabo incorrectamente, aunque el robot haya
llegado al lugar adecuado. Si el robot llega antes de que la pieza llegue, la pieza aún no
estará ahí y el robot puede bloquear su paso.
Para un sistema de tiempo real crítico (tiempo real duro), se tiene como ejemplo el caso del
sistema de refrigeración de una central nuclear, el cual debe de tener respuestas en la menor
cantidad de tiempo posible (preferiblemente de inmediato) y no acepta ningún retraso ni
error en su proceso, pues esto llevaría a una catástrofe nuclear.
 RESTRICCIONES

 Memory lock
En sistemas de tiempo real debe evitarse que las páginas de memoria (en un sistema de
memoria virtual) asociadas a una tarea con restricciones estrictas de tiempo sean enviadas
al disco por falta de memoria para otras tareas (este fenómeno se denomina swapping). Esto
produciría un incremento indeterminado en el cambio de contexto, ya que no puede saberse
a priori si las páginas fueron enviadas a disco o no. Para ello, la mayoría de los sistemas de
tiempo real proveen facilidades para evitar que esto ocurra. Los sistemas más inteligentes
proveen dos formas de trabar en la memoria. La primera hace un lock del proceso completo
en memoria, pero en el caso de que se supere la capacidad de memoria disponible, se
dispone de una segunda opción que permite hacer un lock en memoria solo de las porciones
críticas del proceso.

 Relojes y timers de tiempo real

Como es lógico pensar, este es un punto muy importante en sistemas de tiempo real. Es
fundamental que el sistema provea una base de tiempo adecuada para la sincronización
interna de los procesos presentes. Debe aclararse aquí la diferencia entre reloj y timer. El
primero es simplemente un contador que provee una base de tiempo, y el segundo es un
contador que, llegado a cierto estado, es capaz de notificar que esto ha sucedido. Para la
implementación de un timer es necesario un reloj.
Un sistema de tiempo real debe ser capaz de medir internamente el tiempo con la
resolución y precisión adecuada para el caso de aplicación. Es deseable también que el
sistema sea capaz de reconocer cuándo un timer ha expirado varias veces (timer overrun) y
que sea también capaz de generar una señal standard ante la expiración normal de un timer.
Un aspecto importante es la capacidad del sistema de sincronizar su reloj interno con el
entorno. De la misma manera, en un sistema distribuido, es necesaria una adecuada
sincronización entre los diferentes nodos. Los principales problemas que se presentan son
los drifts debido a la temperatura e incluso la falla de los relojes, problemas que deben ser
subsanados para evitar la falla total del sistema. Uno de los métodos utilizados es el empleo
de una base de tiempo global, a la cual tienen acceso todos los nodos.
Otro método es la implementación de un promedio entre los relojes presentes en el sistema.
Para ello se utilizan algoritmos que prevén los retardos debido a la comunicación y posibles
relojes maliciosos. Uno de los algoritmos más utilizados es Fault tolerant average algorithm
de Ochsenreiter y Kopetz, de 1987 [Buttazzo, 1997], que se encuentra disponible como un
elemento de hardware que puede incluirse en el sistema.
  Entrada/salida en sistemas de tiempo real
Es fundamental que, una vez realizado el procesamiento en tiempo real, la interacción con
los dispositivos externos sea también acotada en tiempo. Es importante que el sistema
operativo disponga de un sistema de entrada/salida sincrónica. Por ejemplo, el sistema de
archivos debe tener acotados los tiempos de respuesta.
Para la transmisión de datos entre el sistema de tiempo real y los diversos sensores y
actuadores que pueden estar presentes en el sistema (incluso para la comunicación de datos
entre distintos nodos de un sistema distribuido) existen diferentes técnicas de buses de
tiempo real, que permiten disponer de sensores inteligentes. éstos no solo transmiten el dato
adquirido, sino que además envían la información acerca del momento en que dicho dato
fue tomado (por ejemplo, Fieldbus).
Dentro de los protocolos de comunicación que disponen de la capacidad de acotar los
tiempos de transmisión pueden mencionarse el protocolo PAR (Positive Acknowledge or
Retransmit), Implicit Flow Control, CSMA/CD (Carrier Sense Multiple Access/Collision
Detection), CAN (Control Area Network), Tokenbus (por ejemplo Profibus), Central
Master, y TDMA-TTP (Time Division Multiple Access –Time Triggered Protocol).

TECNOLOGÍA DE SOFTWARE PARA SISTEMA DE TIEMPO REAL

Para ayudar a las empresas a satisfacer las crecientes demandas de computación en tiempo
real con sistemas en tiempo real confiables y predecibles, Intel proporciona las soluciones,
las tecnologías y los socios para que esto suceda.
Los sistemas de tiempo real se caracterizan por la capacidad de producir los resultados
esperados dentro de un marco de tiempo específico (puntualidad) y de coordinar relojes
independientes para trabajar juntos (sincronización de tiempo).
Los sistemas estrictamente en tiempo real tienen plazos claramente definidos, y si no se
cumple con el tiempo asignado, el sistema fallará. En un sistema flexible en tiempo real, el
sistema sigue funcionando incluso si no se cumple el plazo, pero con una calidad de salida
reducida.
El rendimiento de los sistemas en tiempo real se "mide" frente a dos requisitos: latencia e
inestabilidad computacional. Intel proporciona hardware y software de referencia a nivel de
sistema para crear aplicaciones en tiempo real en las que cada elemento debe funcionar de
manera confiable y predecible durante un período de tiempo específico para cumplir con
los estrictos requisitos en tiempo real.
La necesidad de tener sistemas en tiempo real
El aumento de la conectividad global, la evolución de las demandas de los consumidores
de datos siempre activos y un entorno empresarial siempre activo y habilitado por sensores
están impulsando la creación, la recopilación y el análisis de cantidades exponenciales de
datos. IDC estima que se crearán 79,41 zettabytes de datos para 2025, de los cuales casi el
30%, 2 de ellos requerirá procesamiento en tiempo real utilizando sistemas en tiempo real.
La necesidad de procesamiento en tiempo real es especialmente importante para las
empresas de las industrias de robótica, manufactura, atención médica y alta precisión; como
petróleo, gas y electricidad; que se basa en datos en tiempo real para mejorar
continuamente la seguridad, la eficiencia y la confiabilidad.
Un factor clave para garantizar que las empresas de este tipo de industrias procesen datos
en tiempo real es la capacidad del sistema para priorizar, administrar y ejecutar cargas de
trabajo en tiempo real frente a cargas de trabajo que no son en tiempo real. Por ejemplo, los
fabricantes de automóviles de hoy dependen en gran medida de los robots que trabajan
juntos en las líneas de producción para ensamblar automóviles. Los robots se envían piezas
entre sí, taladran o sueldan, o realizan inspecciones de seguridad; todo esto requiere un alto
grado de precisión y una sincronización cuidadosa. En este caso, un sistema en tiempo real
no solo debe ser capaz de procesar datos en un marco de tiempo predecible, sino también
garantizar que las tareas críticas, como las cargas de trabajo relacionadas con la seguridad,
se completen antes de que se realicen tareas básicas.

BASES DE DATOS
Las bases de datos en los sistemas en tiempo real son componentes clave para administrar
y almacenar datos en aplicaciones que requieren una respuesta en tiempo real. Estas
aplicaciones generalmente se enfocan en el control y monitoreo de procesos, sistemas de
alarma, sistemas de vigilancia, etc. En los sistemas en tiempo real, las bases de datos deben
poder procesar de manera eficiente grandes cantidades de datos y proporcionar un acceso
rápido a la información. Además, debe cumplir con estrictos requisitos de tiempo en los que
los datos deben estar actualizados y disponibles en tiempo real.
Algunas características importantes de las bases de datos en sistemas de tiempo real
incluyen:
1. Alta disponibilidad y confiabilidad: La base de datos debe estar siempre
disponible y asegurar la integridad de los datos. Cualquier interrupción en el sistema
puede ser crítica, por lo que se requiere una infraestructura sólida y redundante.
2. Tiempo de respuesta rápido: Las consultas y actualizaciones deben ser procesadas
rápidamente, dentro de límites de tiempo predefinidos. Esto es fundamental para
garantizar la respuesta en tiempo real del sistema.
3. Escalabilidad: La base de datos debe ser capaz de manejar un aumento en el
volumen de datos y la carga de trabajo sin afectar el rendimiento. Esto implica la
capacidad de escalar horizontal o verticalmente según sea necesario.
4. Gestión eficiente de transacciones: En sistemas de tiempo real, es común tener
múltiples transacciones concurrentes. La base de datos debe manejar eficientemente
estas transacciones para garantizar la consistencia y evitar conflictos.
 5. Modelado de datos adecuado: La estructura de la base de datos debe estar
diseñada de manera óptima para satisfacer las necesidades específicas del sistema
de tiempo real. Esto puede implicar la selección de modelos de datos adecuados,
como bases de datos en memoria o bases de datos en tiempo real especializadas.

SISTEMAS OPERATIVOS
Un sistema operativo de tiempo real (RTOS, por sus siglas en inglés Real-Time Operating
System) es un tipo de sistema operativo diseñado para administrar y controlar dispositivos
o sistemas que requieren respuestas rápidas y predecibles a eventos en tiempo real. A
diferencia de los sistemas operativos de propósito general, que están orientados a
maximizar el rendimiento general del sistema, los RTOS están diseñados para cumplir
estrictas restricciones temporales.
Los sistemas operativos de tiempo real se utilizan en una amplia gama de aplicaciones,
como sistemas de control industrial, sistemas de aviónica, dispositivos médicos,
automóviles, robótica y muchos otros sistemas embebidos. La principal característica de un
RTOS es su capacidad para responder a eventos en tiempo real con una latencia mínima y
una alta precisión. Estos sistemas operativos están diseñados para garantizar que las tareas
críticas se completen dentro de plazos específicos y que los recursos del sistema se asignen
de manera eficiente. Para lograr esto, los RTOS utilizan técnicas como la planificación en
tiempo real, donde las tareas se programan según su prioridad y plazos, y los mecanismos
de interrupción para manejar eventos en tiempo real de forma rápida.
Además, los RTOS suelen ofrecer servicios y características específicas, como la
sincronización y comunicación entre tareas, la gestión de interrupciones, el acceso a
periféricos en tiempo real y la protección de recursos críticos.
En conclusioón, los sistemas operativos de tiempo real son sistemas diseñados para
proporcionar respuestas rápidas y predecibles a eventos en tiempo real, y son ampliamente
utilizados en aplicaciones donde se requiere un control preciso y confiable del tiempo.

LENGUAJES
En un sistema de tiempo real, el lenguaje se refiere a las herramientas y técnicas utilizadas
para programar y desarrollar aplicaciones que deben responder y cumplir con restricciones
de tiempo estrictas. Estas restricciones de tiempo se denominan "requisitos de tiempo real"
y son especialmente críticas en sistemas donde las respuestas deben ser generadas dentro de
límites de tiempo específicos para garantizar un funcionamiento correcto y seguro.
El lenguaje utilizado en un sistema de tiempo real debe permitir una programación
eficiente y determinista, lo que significa que el comportamiento del programa debe ser
predecible y reproducible. Además, el lenguaje debe proporcionar mecanismos para
controlar y garantizar la ejecución oportuna de las tareas en el sistema.
Algunos lenguajes de programación comunes utilizados en sistemas de tiempo real
incluyen:
1. Ada: Ada es un lenguaje de programación desarrollado específicamente para
aplicaciones críticas en tiempo real. Proporciona características para la
concurrencia, el control de tiempo y la gestión de tareas, lo que lo hace adecuado
para sistemas de tiempo real.
2. C/C++: Estos lenguajes son ampliamente utilizados en sistemas embebidos y
aplicaciones en tiempo real. Ofrecen un control cercano del hardware y permiten la
programación de bajo nivel necesaria para sistemas de tiempo real.
3. Java (con extensiones en tiempo real): Java es un lenguaje de programación
popular que también ha sido extendido con características específicas para sistemas
de tiempo real. Estas extensiones agregan funcionalidades para garantizar
comportamiento determinista y controlar la concurrencia en tiempo real.
Es importante destacar que el lenguaje en sí mismo no es suficiente para garantizar el
cumplimiento de los requisitos de tiempo real. El diseño del sistema, la arquitectura y la
implementación también desempeñan un papel crucial en el logro de un comportamiento
predictible y de respuesta rápida en tiempo real.

SISTEMAS CASE PARA SRT

Los sistemas CASE (Computer-Aided Software Engineering) se refieren a un conjunto de
herramientas y métodos que ayudan en el desarrollo de software. Estas herramientas y
métodos automatizan diversas tareas en el proceso de desarrollo, como el análisis de
requisitos, el diseño, la generación de código y las pruebas. En el contexto de los sistemas
de tiempo real, los sistemas CASE se utilizan para facilitar el diseño y desarrollo de
aplicaciones que requieren respuestas en tiempo real, es decir, aplicaciones en las que las
respuestas deben generarse dentro de un plazo determinado y predecible.
Los sistemas CASE en sistemas de tiempo real ofrecen características y funcionalidades
específicas para abordar los desafíos relacionados con los requisitos de tiempo real. Estas
características pueden incluir:
1. Modelado y simulación de tiempo real: Permiten a los desarrolladores modelar y
simular el comportamiento de un sistema en tiempo real antes de implementarlo, lo
que ayuda a garantizar que se cumplan los plazos y requisitos de respuesta en
tiempo real.
2. Análisis de rendimiento en tiempo real: Permiten evaluar y analizar el
rendimiento de una aplicación en términos de cumplimiento de los límites de tiempo
 establecidos. Esto ayuda a identificar posibles cuellos de botella o problemas de
rendimiento que puedan afectar la capacidad de respuesta en tiempo real.
3. Generación de código optimizado para tiempo real: Los sistemas CASE en
sistemas de tiempo real pueden generar automáticamente código optimizado que
cumpla con los requisitos de tiempo real. Esto incluye técnicas de optimización para
minimizar los retardos y mejorar la eficiencia en la ejecución.
4. Herramientas de depuración en tiempo real: Proporcionan capacidades de
depuración específicas para sistemas de tiempo real, lo que permite a los
desarrolladores identificar y solucionar problemas relacionados con el cumplimiento
de los plazos y la respuesta en tiempo real.
En conclusión, los sistemas CASE en sistemas de tiempo real son herramientas y
metodologías que apoyan el desarrollo de aplicaciones que requieren respuestas en tiempo
real. Estas herramientas ayudan a los desarrolladores a modelar, simular, analizar y generar
código optimizado para cumplir con los requisitos de tiempo real y garantizar que los
sistemas funcionen de manera predecible dentro de los plazos establecidos.

DESARROLLO DE SISTEMAS EN TIEMPO REAL

El desarrollo de sistemas en tiempo real se refiere a la creación y diseño de sistemas
informáticos que deben operar y responder a eventos y acciones en un plazo de tiempo
determinado y específico. Estos sistemas están diseñados para procesar y proporcionar
resultados dentro de un límite de tiempo estricto y predefinido.
En contraste con los sistemas convencionales, donde la respuesta del sistema no está sujeta
a restricciones de tiempo estrictas, los sistemas en tiempo real tienen requisitos de tiempo
críticos. Estos sistemas se utilizan en una amplia variedad de industrias y aplicaciones,
como aviónica, automoción, control de procesos industriales, telecomunicaciones, sistemas
de defensa, robótica y muchos otros.
El desarrollo de sistemas en tiempo real presenta desafíos únicos debido a la necesidad de
cumplir con los plazos de tiempo establecidos. Algunos de estos desafíos incluyen:
1. Cumplimiento de restricciones de tiempo: Los sistemas en tiempo real deben
cumplir con estrictas restricciones de tiempo para garantizar una respuesta oportuna.
Esto requiere técnicas de diseño y programación cuidadosas para minimizar la
latencia y garantizar que las operaciones críticas se realicen dentro de los límites
establecidos.
2. Planificación y programación: El desarrollo de sistemas en tiempo real implica
una planificación y programación detalladas para garantizar que las tareas y los
recursos se asignen adecuadamente. Se utilizan algoritmos de planificación
específicos para garantizar que las tareas críticas se ejecuten en el momento
adecuado y se gestionen los conflictos de recursos.
 3. Confiabilidad y tolerancia a fallos: Los sistemas en tiempo real a menudo operan
en entornos críticos donde la fiabilidad y la tolerancia a fallos son fundamentales.
Es necesario implementar mecanismos de detección de errores, recuperación y
redundancia para garantizar que el sistema pueda seguir funcionando correctamente
incluso en situaciones de fallos.
4. Optimización de rendimiento: La optimización del rendimiento es esencial en los
sistemas en tiempo real para cumplir con los plazos establecidos. Esto implica la
optimización del código, el uso eficiente de los recursos del sistema y la
minimización de las operaciones innecesarias o de baja prioridad.
El desarrollo de sistemas en tiempo real requiere un enfoque especializado y un
conocimiento profundo de los requisitos y desafíos asociados. Los desarrolladores deben
tener habilidades en diseño de sistemas, programación de bajo nivel, planificación de tareas
y optimización de rendimiento para crear sistemas confiables y responsivos en el tiempo
requerido.

CALIDAD DEL SOFTWARE

La calidad del software es, según Pressman, la “concordancia con los requisitos
funcionales y de rendimiento, con los estándares de desarrollo y con las características
implícitas que se espera del software desarrollado profesionalmente”
No existe una definición única de calidad, ya que:
 Es un concepto relativo (es una compleja mezcla de factores que varía para las
diferentes aplicaciones y los clientes que las solicitan).
 Es un concepto multidimensional, referido a muchas cualidades.
 Está ligada a restricciones (por ejemplo, el presupuesto).
 Está ligada a compromisos aceptables (por ejemplo, plazos de fabricación).
 No es ni totalmente subjetiva ni objetiva.
Puede resultar transparente cuando está presente y reconocible cuando está ausente.
Actualmente, la calidad del SW debe tenerse en cuenta a dos niveles:
 A nivel de empresa: para conseguir software de calidad, las organizaciones deben
tener una estructura organizativa apropiada para fomentar el trabajo por la calidad
de todas las personas y departamentos de la empresa, además de fomentar procesos
específicos para asegurar la calidad.
 A nivel de proyecto: se trata de llevar a la práctica en las actividades cotidianas las
disposiciones fijadas en el sistema de calidad. Se aplica durante todo el proceso de
ingeniería del software, es decir, en Análisis, Diseño, Codificación y Prueba.
En el resto del apartado vamos a ver los conceptos de calidad a nivel de empresa; en el
resto del tema profundizaremos en la calidad a nivel de proyecto.
 MÉTRICAS ISO 9000
Las normas ISO-9000 son un estándar de calidad para todo tipo de industrias. Contiene una
normativa específica para el desarrollo de software, la ISO-9003. Consiste en una serie de
cláusulas que deben aplicarse en el marco de trabajo, en el ciclo de vida del proyecto y en
las actividades de apoyo al mismo.
La aplicación de las normas ISO en un proyecto ha de demostrarse mediante una
evaluación formal por un organismo competente Las normas ISO tienen sin embargo
ciertos inconvenientes:
 Son estáticas, de escaso valor, lentas y muy caras
 No está plenamente orientado al software.
 En muchos casos se ha adoptado por obligación y para “cubrir el expediente” , lo
que no mejora demasiado la calidad.
 La calidad del software es medible y varía de un sistema a otro o de un programa a
otro. Un software elaborado para el control de naves espaciales debe ser confiable al
nivel de "cero fallas"; un software hecho para ejecutarse una sola vez no requiere el
mismo nivel de calidad; mientras que un producto de software para ser explotado
durante un largo período (10 años o más), necesita ser confiable, mantenible y
flexible para disminuir los costos de mantenimiento y perfeccionamiento durante el
tiempo de explotación.
 La calidad del software puede medirse después de elaborado el producto. Pero esto
puede resultar muy costoso si se detectan problemas deriva dos de imperfecciones
en el diseño, por lo que es imprescindible tener en cuenta tanto la obtención de la
calidad como su control durante todas las etapas del ciclo de vida del software.

CALIDAD DE PROCESO
Se busca analizar las actividades del proceso que más influyen en la calidad del producto.
Se modela el proceso para analizarlo mejor. Se pueden hacer preguntas como:
 ¿Dónde y cuándo se puede hallar un tipo de defecto?
 ¿Cómo hallar los defectos antes?
 ¿Existen actividades alternas que proporcionen mayor calidad?
Algunos modelos basados en proceso Modelos de madurez:
  CMM (Capability Madurity Model) y CMMI (CMM Integrated)
 ISO 15504 SPICE (Software Process Improvement and Capability dEtermination)
 ISO 9000
 NYSE NMX-I-059/02 (Moprosoft y Evalprosoft) Norma Mexicana
Actualmente la responsabilidad de garantizar un software de calidad no es función de una
persona; en esto están comprometidos los ingenieros de análisis y diseño, los gestores y
coordinadores del proyecto, los usuarios, los programadores y todas las personas
involucradas en el desarrollo.
La garantía de calidad en el software no es una certificación impuesta luego de haber
desarrollado un programa. Es un proceso que involucra las siguientes actividades:
1. Aplicación de metodologías de ingeniería de software para conseguir una
especificación y un diseño de alta calidad.
2. Realización de revisiones técnicas formales.
3. Prueba del software.
4. Ajuste a los estándares de la organización.
5. Control de cambios y modificaciones (mantenimiento).
6. Mediciones.
7. Registro e informes
La actividad que nos permite garantizar la calidad es la revisión técnica formal realizada
por el grupo de control de calidad. Los objetivos de dicha revisión son:
1. Descubrir errores en la función, la lógica o la implementación de cualquier
representación del software.
2. Verificar que el software bajo revisión cumpla los requerimientos.
3. Garantizar que el software ha seguido los lineamientos predefinidos.
4. Conseguir un software que sea desarrollado en forma uniforme.

CALIDAD DE PRODUCTO
El modelo de calidad representa la piedra angular en torno a la cual se establece el sistema
para la evaluación de la calidad del producto. En este modelo se determinan las
características de calidad que se van a tener en cuenta a la hora de evaluar las propiedades
de un producto software determinado.
La calidad del producto software se puede interpretar como el grado en que dicho producto
satisface los requisitos de sus usuarios aportando de esta manera un valor. Son
precisamente estos requisitos (funcionalidad, rendimiento, seguridad, mantenibilidad, etc.)
los que se encuentran representados en el modelo de calidad, el cual categoriza la calidad
del producto en características y subcaracterísticas.
El modelo de calidad del producto definido por la ISO/IEC 25010 se encuentra compuesto
por las ocho características de calidad que se muestran en la siguiente figura:
 REFERENCIAS BIBLIOGRÁFICAS

 Álvarez, M. Procesos de desarrollo de software (2022). Página web en línea.

Consultado el día 28/05/23. Disponible en:
https://desarrolloweb.com/articulos/procesos-desarrollo-software
 Carreón, L. Complejidad del software: una métrica importante para la prueba
del software (2022). Página web en línea. Consultado el día 29/05/23. Disponible
en https://sg.com.mx/revista/22/complejidad-del-
software#:~:text=Podemos%20hablar%20de%20dos%20vistas,como%20est%C3%
A1%20programada%20la%20soluci%C3%B3n
 Digital Guide Ionos. Diagrama de estado UML: visualizar secuencias de estados
de objetos (2020). Página web en línea. Consultado el día 30/05/2023. Disponible
en: https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/diagrama-de-
estado-uml/
 Editorial Etecé. Software (2023). Página web en línea. Consultado el día 29/05/23.
Disponible en: https://humanidades.com/software/#ixzz83Fgki9W0
 Hernando, J. Control de Calidad en el Software. Página web en línea. Consultado
el día 29/05/23. Disponible en: https://saludelectronica.com/calidad-del-software/
 Huchin, A. La complejidad de los sistemas de software (2009). Página web en
línea. Consultado el día 29/05/23. Disponible en: http://metodologia-de-
booch.blogspot.com/2009/06/la-complejidad-de-los-sistemas-de.html
 Intelequia. Ciclo de vida del Software: Todo lo que necesitas saber (2020).
Página web en línea. Consultado el 27/05/2023. Disponible en:
https://intelequia.com/blog/post/ciclo-de-vida-del-software-todo-lo-que-necesitas-
saber
 Lucidchart. ¿Qué es el lenguaje unificado de modelado (UML)? Página web en
línea. Consultado el día 30/05/2023. Disponible en:
https://www.lucidchart.com/pages/es/que-es-el-lenguaje-unificado-de-modelado-
uml#:~:text=un%20diagrama%20UML-
 Olmos, H. Diagrama de colaboración. Página web en línea. Consultado el día
30/05/2023. Disponible en:
https://diagramasumlerickolmososati102.weebly.com/diagramas-de-
colaboracioacuten.html
 Sharma, P. Los 9 mejores modelos de desarrollo de software para elegir: fases y
aplicaciones (2022). Página web en línea. Consultado el 27/05/2023. Disponible en:
https://cynoteck.com/es/blog-post/top-software-development-models-to-choose-
from/#4_The_Rational_Unified_Process_RUP
 Solis, V. Tecnologías Metodología iWeb (2016). Página web en línea. Consultado
el día 29/05/2023. Disponible en: http://web-on-
cloud.blogspot.com/2016/05/metodologia-iweb-esta-metodologia.html