https://www.google.com/search?

q=arquitectura+de+software+de+acuerdo+al+patr%C3%B3n+de+dise%C3%B1o&tbm=isch&ved=2ahUKEwi2uKzFmtb5AhWlioQIHUTQDXYQ2-
cCegQIABAA&oq=arquitectura+de+software+de+acuerdo+al+patr%C3%B3n+de+dise%C3%B1o&gs_lcp=CgNpbWcQA1DfDlitY2DtbmgAcAB4AIAB6hiIAaSWAZIBDTMtMS42LTEuMy4wLjWYAQCgAQGqAQtnd3Mtd2l6LWltZ8ABAQ&sclien
t=img&ei=PD0BY7aqOaWVkvQPxKC3sAc&rlz=1C1UEAD_esCO976CO976#imgrc=x44fJccYCRwXrM

La arquitectura de software de acuerdo al patrón de diseño

seleccionado

Sena / Tecnologo / Análisis y desarrollo de software

Profesor : Jorge Augusto Escobar Medina
Código / 2455265 / Proyecto Fase 2 / Analisis
Evidencia de conocimiento: GA4-220501095-AA2-EV05
Alumno : Juan David Calle Correa
Introduccion.

Los patrones de diseño o design patterns, son una solución general, reutilizable y
aplicable a diferentes problemas de diseño de software.
Se trata de plantillas que identifican problemas en el sistema y proporcionan
soluciones apropiadas a problemas generales a los que se han enfrentado los
desarrolladores durante un largo periodo de tiempo, a través de prueba y error.

Concluciones.

Antes se requería completar todo el software antes de realizar pruebas, lo que suponía
encontrarse con problemas.
Para ahorrar tiempo y evitar volver a la etapa de desarrollo una vez que este ha
finalizado, se introdujo una práctica de prueba durante la fase de desarrollo.
Esta práctica se usa para identificar condiciones de error y problemas en el código
que pueden no ser evidentes en ese momento.
En definitiva, los patrones de diseño te ayudan a estar seguro de la validez de tu
código, ya que son soluciones que funcionan y han sido probados por muchísimos
desarrolladores siendo menos propensos a errores.

PÁGINA 1
Tipos de patrones de diseño de sotware:

Los patrones de diseño más utilizados se clasifican en tres categorías principales,

cada patrón de diseño individual conforma un total de 23 patrones de diseño.
Las cuatro categorías principales son:

 Patrones creacionales
 Patrones estructurales
 Patrones de comportamiento

PÁGINA 2
Patrones creacionales:

Los patrones de creación proporcionan diversos mecanismos de creación de objetos,

que aumentan la flexibilidad y la reutilización del código existente de una manera
adecuada a la situación.
Esto le da al programa más flexibilidad para decidir qué objetos deben crearse para
un caso de uso dado.

Estos son los patrones creacionales:

1. Abstract Factory
En este patrón, una interfaz crea conjuntos o familias de objetos relacionados sin
especificar el nombre de la clase.

2. Builder Patterns
Permite producir diferentes tipos y representaciones de un objeto utilizando el mismo
código de construcción.
Se utiliza para la creación etapa por etapa de un objeto complejo combinando objetos
simples.
La creación final de objetos depende de las etapas del proceso creativo, pero es
independiente de otros objetos.

3. Factory Method
Proporciona una interfaz para crear objetos en una superclase, pero permite que las
subclases alteren el tipo de objetos que se crearán.
Proporciona instanciación de objetos implícita a través de interfaces comunes

4. Prototype
Permite copiar objetos existentes sin hacer que su código dependa de sus clases.
Se utiliza para restringir las operaciones de memoria / base de datos manteniendo la
modificación al mínimo utilizando copias de objetos.

5. Singleton
Este patrón de diseño restringe la creación de instancias de una clase a un único
objeto.

PÁGINA 3
Patrones estructurales:

Facilitan soluciones y estándares eficientes con respecto a las composiciones de

clase y las estructuras de objetos.
El concepto de herencia se utiliza para componer interfaces y definir formas de
componer objetos para obtener nuevas funcionalidades.

1. Adapter
Se utiliza para vincular dos interfaces que no son compatibles y utilizan sus
funcionalidades.
El adaptador permite que las clases trabajen juntas de otra manera que no podrían al
ser interfaces incompatibles.

2. Bridge
En este patrón hay una alteración estructural en las clases principales y de
implementador de interfaz sin tener ningún efecto entre ellas.
Estas dos clases pueden desarrollarse de manera independiente y solo se conectan
utilizando una interfaz como puente.

3. Composite
Se usa para agrupar objetos como un solo objeto.
Permite componer objetos en estructuras de árbol y luego trabajar con estas
estructuras como si fueran objetos individuales.

4. Decorator
Este patrón restringe la alteración de la estructura del objeto mientras se le agrega
una nueva funcionalidad.
La clase inicial permanece inalterada mientras que una clase decorator proporciona
capacidades adicionales.

5. Facade
Proporciona una interfaz simplificada para una biblioteca, un marco o cualquier otro
conjunto complejo de clases.

6. Flyweight
El patrón Flyweight se usa para reducir el uso de memoria y mejorar el rendimiento al
reducir la creación de objetos.
El patrón busca objetos similares que ya existen para reutilizarlo en lugar de crear
otros nuevos que sean similares.

7. Proxy
Se utiliza para crear objetos que pueden representar funciones de otras clases u
objetos y la interfaz se utiliza para acceder a estas funcionalidades.

PÁGINA 4
Patrones de comportamiento:

El patrón de comportamiento se ocupa de la comunicación entre objetos de clase.

Se utilizan para detectar la presencia de patrones de comunicación ya presentes y
pueden manipular estos patrones.

Estos patrones de diseño están específicamente relacionados con la comunicación

entre objetos.

1. Chain of responsibility
El patrón de diseño Chain of Responsibility es un patrón de comportamiento que evita
acoplar el emisor de una petición a su receptor dando a más de un objeto la posibilidad
de responder a una petición.

2. Command
Convierte una solicitud en un objeto independiente que contiene toda la información
sobre la solicitud.
Esta transformación permite parametrizar métodos con diferentes solicitudes, retrasar
o poner en cola la ejecución de una solicitud y respaldar operaciones que no se
pueden deshacer.

3. Interpreter
Se utiliza para evaluar el lenguaje o la expresión al crear una interfaz que indique el
contexto para la interpretación.

4. Iterator
Su utilidad es proporcionar acceso secuencial a un número de elementos presentes
dentro de un objeto de colección sin realizar ningún intercambio de información
relevante.

5. Mediator
Este patrón proporciona una comunicación fácil a través de su clase que permite la
comunicación para varias clases.

6. Memento
El patrón Memento permite recorrer elementos de una colección sin exponer su
representación subyacente.

7. Observer
Permite definir un mecanismo de suscripción para notificar a varios objetos sobre
cualquier evento que le suceda al objeto que está siendo observado.

8. State
En el patrón state, el comportamiento de una clase varía con su estado y, por lo tanto,
está representado por el objeto de contexto.

9. Strategy
Permite definir una familia de algoritmos, poner cada uno de ellos en una clase
separada y hacer que sus objetos sean intercambiables.

PÁGINA 5
 10. Template method
Se usa con componentes que tienen similitud donde se puede implementar una
plantilla del código para probar ambos componentes.
El código se puede cambiar con pequeñas modificaciones.

11. Visitor
El propósito de un patrón Visitor es definir una nueva operación sin introducir las
modificaciones a una estructura de objeto existente.

PÁGINA 6
Elaborar la vista de componentes para visualizar el software en fases avanzadas
del ciclo de vida.

Veremos:

Ciclo de vida del software.

Fases y objetivos.
Modelos y características.
Caracterización de la fase de definición de requisitos.
Herramientas para el uso de captura de requisitos que se usan para el desarrollo del
Software.

Ciclo de vida del software:

También conocido como (SDLC o Systems Development Life Cycle), es la estructura

que contiene los procesos, actividades y tareas relacionadas con el desarrollo y
mantenimiento de un producto de software, abarcando la vida completa del sistema,
desde la definición de los requisitos hasta la finalización de su uso.
https://ungoti.com/es/soluciones/desarrollo-de-software/sdlc/

El ciclo de vida permite iniciar una serie de fases mediante las cuales se procede a la
validación y al desarrollo del software garantizando que se cumplan los requisitos para
la aplicación y verificación de los procedimientos del desarrollo como tal.

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 con el objetivo final de lograr la
satisfacción del cliente.

Elementos que integran un ciclo de vida:

Fases, una fase es un conjunto de actividades relacionadas con un objetivo en el

desarrollo del proyecto.
Se construye agrupando tareas que pueden compartir un tramo determinado del
tiempo de vida de un proyecto.

Entregables, son los productos intermedios que generan las fases.

Pueden ser materiales o inmateriales (documentos, software).
Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones
de su adecuación o no a los requisitos funcionales y de condiciones de realización
previamente establecidos.

La metodología para el desarrollo de software es un modo sistemático de realizar,

gestionar y administrar un proyecto para llevarlo a cabo con grandes posibilidades de
éxito.
Esta sistematización indica cómo se divide un proyecto en módulos más pequeños
para normalizar cómo se administra el mismo.
Así, una metodología para el desarrollo de software son los procesos a seguir
sistemáticamente para idear, implementar y mantener un producto de software desde
que surge la necesidad del producto hasta que se cumple el objetivo por el cual fue
creado.
https://intelequia.com/blog/post/2083/ciclo-de-vida-del-software-todo-lo-que-necesitas-saber

PÁGINA 7
Desde un punto de vista conceptual, las actividades son de cinco clases:

 Obtener requisitos, (Planificación)

A través de entrevistas o comunicación con clientes o usuarios, para saber
cuáles son sus expectativas.
En esta primera fase se realiza el planteamiento del problema, se definen
alcances y objetivos del software.
 Analizar requisitos, (Definición de requisitos)
Detectar y corregir las falencias comunicativas, transformando los requisitos
obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser
tratados en el diseño, definir los requisitos que son los que dirigirán el
desarrollo del proyecto.
 Documentar requisitos, (Diseño)
Igual que todas las etapas, los requisitos deben estar debidamente
documentados.
En este, estudiar posibles opciones de implementación para el software que
hay que construir.
 Verificar los requisitos, (Pruebas)
Consiste en comprobar el correcto funcionamiento de un requisito en la
aplicación.
Se busca detectar fallos cometidos en las etapas anteriores para corregirlos.
 Validar los requisitos, (Mantenimiento)
Comprobar que los requisitos implementados se corresponden con lo que
inicialmente se pretendía.

En esta fase se realiza:

Mantenimiento correctivo
Mantenimiento adaptativo
Mantenimiento perfectivo.

http://yuglenisdelcarmen.blogspot.com/p/fases-de-la-ingenieria-de-requisitos.html

PÁGINA 8
Paradigmas de los modelos de ciclo de vida del software:

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren
durante el desarrollo de software e intenta determinar el orden de las etapas
involucradas y los criterios de transición asociados entre estas.

Según la norma 1074 IEEE se define al ciclo de vida del software como:

Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y

el mantenimiento del software.

La ISO/IEC 12207 Information Technology / Software Life Cycle Processes

señala que es:

Un marco de referencia que contiene los procesos, las actividades y las tareas
involucradas en el desarrollo, la explotación y el mantenimiento de un producto de
software, abarcando la vida del sistema desde la definición de los requisitos hasta la
finalización de su uso (2008).

Paradigmas de modelos de ciclo de vida para desarrollar software:

Paradigma tradicional.
Los paradigmas tradicionales se identifican, fundamentalmente, por ser lineales, es
decir se trata de completar cada proceso de principio a fin hasta que quede listo para
avanzar a la segunda fase del ciclo del software.

Paradigma orientado a objetos.

La Programación Orientada a Objetos (POO) es un paradigma de programación, esto
es, un modelo o un estilo de programación que proporciona unas guías acerca de
cómo trabajar con él y que está basado en el concepto de clases y objetos. Este tipo
de programación se emplea para estructurar un programa de software en piezas
simples y reutilizables de planos de código (clases) para crear instancias individuales
de objetos.
https://intelequia.com/blog/post/3072/qu%C3%A9-es-la-programaci%C3%B3n-orientada-a-objetos

Las etapas de desarrollo de software en el paradigma orientado a objetos, se

conforma principalmente por la creación de clases, análisis de requisitos y el diseño.

Paradigma de desarrollo ágil.

En el desarrollo de proyectos en poco tiempo, se simplifican procesos tediosos, se
agilizan las fases del desarrollo y las interacciones se hacen en corto tiempo.
La diferencia con los paradigmas anteriores es que el cliente se ve involucrado en el
proyecto durante el desarrollo de este, así, el cliente sugiere mejoras, propone ideas
y se mantiene al tanto del desarrollo del producto, a diferencia del paradigma
tradicional y el orientado a objetos donde el cliente únicamente está al principio de
este.

PÁGINA 9
Modelos de paradigmas más utilizados:

Modelo en cascada:

Uno de los primeros modelos de ciclo de vida del desarrollo fue establecido por W.
Royce en 1970 y es conocido como el “modelo de cascada” (waterfall model).

En el modelo de ciclo de vida en cascada las fases anteriores funcionarán una detrás
de la otra de manera lineal. De este modo, solo cuando una fase termine se podrá
continuar con la siguiente, y así progresivamente.

https://www.google.com/search?q=Modelo+en+cascada&rlz=1C1UEAD_esCO976CO976&sxsrf=AOaemvLSiVGcjaXx1qUGhxqPjcQvMl9JYg:1640446763807&source=lnms&tbm=isch&sa=X&sqi=2&ved=2ahUKEwjJ-
4O1pP_0AhXir5UCHXumC0MQ_AUoAXoECAIQAw&biw=1139&bih=497&dpr=1.2

Modelo espiral:

Fue diseñado por Boehm en el año 1988 y se basa en una serie de ciclos repetitivos
para ir ganando madurez en el producto final.

El espiral se repite las veces que sea necesario hasta que el cliente o el usuario
obtenga la satisfacción de sus necesidades.
El modelo en espiral es una combinación de los modelos anteriores donde se tiene en
cuenta el riesgo.
De esta forma, se comienza fijando los objetivos y las limitaciones al empezar cada
repetición.
En la etapa siguiente se crean los modelos de prototipo del software, que incluye el
análisis de riesgo.
Posteriormente se usa un modelo estándar para construir el software y finalmente se
prepara el plan de la próxima repetición.
https://intelequia.com/blog/post/2083/ciclo-de-vida-del-software-todo-lo-que-necesitas-saber

https://www.google.com/search?q=modelo+en+espiral&tbm=isch&ved=2ahUKEwjsgLm2pP_0AhVBFt8KHSUmD88Q2-
cCegQIABAA&oq=Modelo+en+&gs_lcp=CgNpbWcQARgCMgcIIxDvAxAnMgUIABCABDIFCAAQgAQyBQgAEIAEMgUIABCABDIFCAAQgAQyBQgAEIAEMgUIABCABDIFCAAQgAQyBAgAEENQjQdYlhFg8CVoAHAAeACAAekBiAHFC
JIBBTAuNy4xmAEAoAEBqgELZ3dzLXdpei1pbWfAAQE&sclient=img&ei=LjvHYeyxLsGs_AalzLz4DA&bih=497&biw=1139&rlz=1C1UEAD_esCO976CO976#imgrc =3Z4bSJL1pmPzQM

PÁGINA 10
Modelo iterativo o por prototipos:

Este modelo consiste en un procedimiento que permite al equipo de desarrollo diseñar

y analizar una aplicación que represente el sistema que será implementado
(McCracken y Jackson, 1982).

Objetivos:

A
Son un medio eficaz para aclarar los requisitos de los usuarios e identificar las
características de un sistema que debe cambiarse o añadirse.

B
Mediante el prototipo se puede verificar la viabilidad del diseño de un sistema.

https://www.google.com/search?q=Modelo+iterativo+o+por+prototipos&rlz=1C1UEAD_esCO976CO976&hl=es-419&sxsrf=AOaemvIhFPGVJ_k0IbpBmVSU4Xn1w-
7vPw:1640448612316&source=lnms&tbm=isch&sa=X&ved=2ahUKEwi-nbymq__0AhUvQzABHTHvC-0Q_AUoAXoECAEQAw&biw=1139&bih=497&dpr=1.2

Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el
riesgo que surge entre las necesidades del usuario y el producto final por malos
entendidos durante la etapa de recogida de requisitos.

PÁGINA 11
Las etapas del modelo iterativo o por prototipos:

1 colecta y refinamiento de los requerimientos y proyecto rápido.

 Análisis.
 Especificación del prototipo.

2 diseño rápido.

3 construcción del prototipo.

4 evaluación del prototipo por el cliente.

5 refinamiento del prototipo.

 Diseño técnico.

 Programación y test.

 Operación y mantenimiento.

6 producto de ingeniería.

(con respecto a los modelos del ciclo de vida del paradigma ágil, estos se caracterizan
por estar basados en etapas del ciclo de vida del software tradicional, pero
combinándolas con algunas técnicas, al respecto se pueden revisar los siguientes)

Modelo Scrum:
Este modelo se basa en el desarrollo incremental, es decir conforme pasen las fases
y la iteración mayor será el tamaño del proyecto que se está desarrollando.
La metodología Scrum es un proceso para llevar a cabo un conjunto de tareas de
forma regular con el objetivo principal de trabajar de manera colaborativa, es decir,
para fomentar el trabajo en equipo.
Con este método de trabajo lo que se pretende es alcanzar el mejor resultado de un
proyecto determinado.
Las prácticas que se aplican con la metodología Scrum se retroalimentan unas con
otras y la integración de las mismas tiene su origen en un estudio de cómo hay que
coordinar a los equipos para ser potencialmente competitivos.
En Scrum se van realizando entregas regulares y parciales del trabajo final, de manera
prioritaria y en función del beneficio que aportan dichas entregas a los receptores del
proyecto.
Por este motivo, es una metodología especialmente indicada para proyectos
complejos, con requisitos cambiantes y en los que la innovación y la flexibilidad son
protagonistas.
https://www.apd.es/metodologia-scrum-que-es/

PÁGINA 12
El Scrum consiste en realizar un análisis de los requerimientos del sistema (Product
Backlog), señalar cuáles serán los objetivos a corto o mediano plazo dentro de un
sprint, o sea, la fase de desarrollo. Posteriorme

https://www.google.com/search?q=Modelo+Scrum&rlz=1C1UEAD_esCO976CO976&sxsrf=AOaemvIuLBO6_BUf98rs99dVS39qBX4YHg:1640467836111& source=lnms&tbm=isch&sa=X&sqi=2&ved=2ahUKEwiUzIv18v_0AhWbAogKH
avwDVMQ_AUoAXoECAEQAw&biw=1139&bih=497&dpr=1.2#imgrc=B0VmLys_mt_RiM

Procesos que utiliza son:

 Product Backlog. (producto reserva)

 Sprint Backlog. (atrasos de pique)
 Sprint Planning Meeting. (reunión de planificación de pique)
 Daily Scrum. (diario)
 Sprint Review. (revisión de pique)
 Sprint Retrospective. (retrospectivo)

Modelo Kanban:

David J. Anderson (reconocido como el líder de pensamiento de la adopción del

Lean/Kanban para el trabajo de conocimiento), formuló el método Kanban como una
aproximación al proceso evolutivo e incremental y al cambio de sistemas para las
organizaciones de trabajo.
El método está enfocado en llevar a cabo las tareas pendientes y los principios más
importantes pueden ser divididos en cuatro principios básicos y seis prácticas.

PÁGINA 13
Mediante la metodología japonesa:

 Define el flujo de trabajo.

 Establecen las fases del ciclo de producción.
 Stop Starting, start finishing. (dejar de empezar) (empezar a terminar)
 Tiene un control.

https://www.google.com/search?q=Modelo+Kanban&tbm=isch&ved=2ahUKEwjF3sO59v_0AhUqSN8KHWrLCS8Q2-
cCegQIABAA&oq=Modelo+Kanban&gs_lcp=CgNpbWcQAzIFCAAQgAQyBQgAEIAEMgYIABAIEB4yBggAEAgQHjIGCAAQCBAeMgQIABAYMgQIABAYMgQIABAYMgQIABAYMgQIABAYOgcIIxDvAxAnOgYIABAHEB46BggAEAUQHK
CCMQ7wMQ6gIQJ1DnCljsyQFgp9cBaANwAHgIgAGfAogBpBSSAQUwLjYuN5gBAKABAaoBC2d3cy13aXotaW1nsAEKwAEB&sclient=img&ei=MJHHYcWGOaqQ_Qbqlqf4Ag&bih=497&biw=1139&rlz=1C1UEAD_esCO976CO976#img
rc=bmNVGBM1R7du-M

Modelo XP o programación extrema:

Es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer
libro sobre este tema: Extreme Programming Explained: Embrace Change (1999).

La metodología XP o Programación Extrema es una metodología ágil y flexible

utilizada para la gestión de proyectos.
Extreme Programming se centra en potenciar las relaciones interpersonales del
equipo de desarrollo como clave del éxito mediante el trabajo en equipo, el
aprendizaje continuo y el buen clima de trabajo.
Esta metodología pone el énfasis en la retroalimentación continua entre cliente y el
equipo de desarrollo y es idónea para proyectos con requisitos imprecisos y muy
cambiantes.
https://www.diegocalvo.es/metodologia-xp-programacion-extrema-metodologia-agil/

https://www.google.com/search?q=Modelo+XP+o+programaci%C3%B3n+extrema&rlz=1C1UEAD_esCO976CO976&hl=es-
419&sxsrf=AOaemvKbfonbSw3tzEgT0wPQ3EjQAPEEqA:1640471411187&source=lnms&tbm=isch&sa=X&ved=2ahUKEwiGkOmdgID1AhV3SjABHROWBUwQ_AUoAXoECAEQAw&biw=1139&bih=497&dpr=1.2#imgrc=3OfLMvA_SFq
usM

PÁGINA 14
Características principales de la programación extrema:

 Tipo de desarrollo iterativo e incremental.

 Pruebas unitarias.
 Trabajo en Equipo.
 Trabajo junto al cliente.
 Corrección de errores.
 Reestructuración del código.
 El código es de todos.
 El código simple es la clave.

Fase de definición de requisitos:

La etapa de análisis en el ciclo de vida del software corresponde al proceso a través

del cual se intenta descubrir qué es lo que realmente se necesita y se llega a una
comprensión adecuada de los requerimientos del sistema.

La inestabilidad de los requerimientos de un sistema es inevitable, pues se estima que

25% de los requerimientos iniciales de un sistema cambian antes de que el sistema
comience a utilizarse.

Las Actividades Y Los Artefactos Que Se Realizan En La Fase De Definición De Requisitos

Fase Actividades Artefactos

Definición del alcance del proyecto.

Identificación del negocio. Modelo del negocio.
Análisis (definición de requisitos) Toma de requerimientos. Análisis y realización de casos de uso.
Estudio de procesos de negocio. Modelo de procesos y actividades de negocio.
Calendarización del proyecto. Cronograma del proyecto.
Diseño propio con énfasis en el ejemplo de plataforma para que me quede todo mucho mas claro para futuro

Requisitos:

Un requisito es una condición o capacidad que necesita el usuario para resolver un

problema o conseguir un objetivo determinado (IEEE, 1990).

Los requisitos del software son la descripción de las características y las

funcionalidades del sistema 'target'. (objetivo)
Los requisitos nos comunican las expectativas de los consumidores de productos
software.
Los requisitos pueden ser obvios o estar ocultos, conocidos o desconocidos,
esperados o inesperados, desde el punto de vista del cliente.
https://www.tutorialspoint.com/es/software_engineering/software_requirements.htm

PÁGINA 15
Importancia de los requisitos:

Los requerimientos o requisitos son la pieza fundamental

en un proyecto de desarrollo de software, ya que marcan el punto de partida para
actividades como la planeación, básicamente en lo que se refiere a las estimaciones
de tiempos y costos,

Así como la definición de recursos necesarios y la elaboración de cronogramas que

será uno de los principales mecanismos de control con los que se contará durante la
etapa de desarrollo.

Además, la especificación de requerimientos es la base que permite verificar si se

alcanzaron o no los objetivos establecidos en el proyecto ya que estos son un reflejo
detallado de las necesidades de los clientes o usuarios del sistema y es contra lo que
se va a estar verificando si se están cumpliendo las metas trazadas.
https://www.google.com/search?q=importancia+de+los+requisitos+de+software&bih=497&biw=1139&rlz=1C1UEAD_esCO976CO976&hl=es-
419&sxsrf=AOaemvJkuCiMaLSjhtEX1p3k6sDZk4RgWg%3A1640529156561&ei=BH3IYZDnIZmKwbkPw5el4Ac&oq=Importancia+de+los+requisitos+sof&gs_lcp=Cgdnd3Mtd2l6EAEYADIGCAAQFhAeOgQIABBHOgcIIxDqAhAnOgoIAB
CABBCHAhAUOgUIABCABDoHCAAQgAQQCjoFCCEQoAFKBAhBGABKBAhGGABQjB1YttgBYO7lAWgBcAN4AIAB7gGIAZoIkgEFMC41LjGYAQCgAQGgAQKwAQrIAQjAAQE&sclient=gws-wiz

las características que los requisitos deben cumplir de acuerdo con Pfleeger
(2002) son:

Necesario:
Si se tiene alguna duda acerca de la necesidad del requerimiento, se puede
preguntar “¿Qué sería lo peor de no incluirlo?”. Si no se encuentra una respuesta o
cualquier consecuencia, entonces es probable que no sea un requerimiento
necesario.

Completo:
Un requerimiento está completo si no necesita ampliar detalles en su redacción, es
decir, si se proporciona la información suficiente para su comprensión.

Consistente:
Un requerimiento es consistente si no es contradictorio con otro requerimiento.

Correcto:
Acuerdo entre dos partes. Contiene una sola idea.

Factible:
El requerimiento deberá de ser totalmente factible y dentro de presupuesto, calendario
y otras restricciones, si se tiene alguna duda de su factibilidad, hay que investigar,
generar pruebas de concepto para saber su complejidad y factibilidad, si aun así el
requerimiento es no factible, hay que revisar la visión del sistema y replantear el
requerimiento.

Modificable:
Los cambios en los requisitos deben hacerse de manera sistemática, y debe tenerse
en cuenta su impacto en otros requisitos.

Priorizado:
Categorizar el requerimiento nos ayuda a saber el grado de necesidad del mismo:
esencial/crítico, deseado, opcional verificable.

PÁGINA 16
Verificable:
Si un requerimiento no se puede comprobar, entonces, ¿cómo se sabe si se cumplió
con él o no? Debe ser posible verificarlo ya sea por inspección, análisis de prueba o
demostración. Cuando se escriba un requerimiento, se deberán determinar los
criterios de aceptación.

Rastreable:
La especificación se debe organizar de tal forma que cada función del sistema se
pueda rastrear hasta su conjunto de requerimientos correspondientes.
Facilita las pruebas y la validación del diseño.

Claro:
Un requerimiento es conciso si es fácil de leer y entender, su redacción debe ser
simple y clara para quienes lo consulten en un futuro.

Clasificación:
 Requerimientos de usuario: Son declaraciones, en lenguaje natural y en
diagramas, de los servicios que se espera que el sistema proporcione y de las
restricciones bajo las cuales debe funcionar.

 Requerimientos de sistema: Estos requerimientos establecen con detalle las

funciones, servicios y restricciones operativas del sistema.
El documento de requerimientos del sistema deberá ser preciso, y definir
exactamente lo que se va a desarrollar.
 Requerimientos funcionales: Son declaraciones de los servicios que debe
proporcionar el sistema, de la manera en que éste debe reaccionar a entradas
particulares.
O también pueden declarar explícitamente lo que el sistema no debe hacer.

Requerimientos no funcionales:
Son restricciones de los servicios o funciones ofrecidos por el sistema.
Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares.
Dentro de estos requerimientos encontramos todo lo referente a fiabilidad, el tiempo
de respuesta y la capacidad de almacenamiento.

funcionales y no funcionales

Funcionales No funcionales

Se debe ingresar cédula, nombre y teléfono de cada cliente. Las consultas deben resolverse en menos de 3 segundos.
Se requiere un listado de clientes por zona. El lenguaje de programación debe ser Java.

Diseño propio con énfasis en la plataforma e igual para que me sirva en futuras labores

PÁGINA 17
Ingeniería de requisitos:

https://www.google.com/search?q=Ingenier%C3%ADa+de+requisitos&rlz=1C1UEAD_esCO976CO976&sxsrf=AOaemvJiAhrFsw-
IKPf8TKNYNH7GXpB4Mg:1640534670636&source=lnms&tbm=isch&sa=X&ved=2ahUKEwj8raPy64H1AhXHTDABHZ4pBoYQ_AUoAXoECAIQAw

Las siguientes son definiciones de ingeniería de requisitos de algunos autores.

 La ingeniería de requisitos es la disciplina para desarrollar una especificación

completa, consistente y no ambigua, la cual servirá como base para acuerdos
comunes entre todas las partes involucradas y en dónde se describen las
funciones que realizará el sistema.
- (Boehm, 1979).

 La ingeniería de requisitos es el proceso de estudiar las necesidades del

usuario para llegar a una definición de requisitos de sistema, hardware o
software.
- (IEEE, 1990).

 La ingeniería de requisitos puede considerarse como un proceso de

descubrimiento y comunicación de las necesidades de clientes y usuarios y la
gestión de los cambios de dichas necesidades.
- (Amador, 2000)

El término IR “ingeniería de requisitos” ha surgido para englobar los procesos de

desarrollo y gestión de requisitos en el ciclo de vida del software, el primer término
(ingeniería) se enfoca en las actividades de obtención, análisis, especificación y
validación de los requisitos que permitirá alcanzar los objetivos del negocio y el
segundo (requisitos) está centrado en la administración de los mismos y tiene como
propósito central la gestión de los cambios y la trazabilidad, de esta forma la IR
proporciona el mecanismo apropiado para:

 Entender lo que el cliente quiere.

 Analizar las necesidades.
 Evaluar la factibilidad.
 Negociar una solución razonable.
 Especificar la solución sin ambigüedades.
 Validar la especificación.
 Administrar los requisitos conforme éstos se transforman en un sistema
operacional.

PÁGINA 18
Etapas de la ingeniería de requisitos:

 Elicitación:
Actividad involucrada en el descubrimiento de los requisitos del sistema. Aquí
los analistas deben trabajar junto con el cliente para descubrir el problema que
el sistema debe resolver, los diferentes servicios que el sistema debe prestar
y las restricciones que se pueden presentar.

Los principales objetivos que se deben alcanzar son los siguientes:

1. Conocer el dominio del problema, de forma tal que los analistas puedan
entenderse con los clientes y usuarios y sean capaces de transmitir
dicho conocimiento al resto del equipo.
2. Descubrir necesidades reales entre clientes y usuarios, haciendo
énfasis en aquellas, que la mayor parte de las veces se asumen y
toman por implícitas.
3. Consensuar los requisitos entre los propios clientes y usuarios hasta
obtener una visión común de los mismos.
 Análisis:
Sobre la base de la obtención realizada previamente, comienza esta fase la
cual tiene como propósito descubrir problemas con los requisitos del sistema
identificados hasta el momento, para ello se basa en los siguientes objetivos:
1. Detectar conflicto en los requisitos que suelen provenir de distintas
fuentes y presentar contradicciones o ambigüedades debido a su
naturaleza informal.
2. Profundizar en el conocimiento del dominio del problema puede facilitar
el proceso de construir un producto útil para clientes y usuarios (Durán,
2000).
3. En esta fase, el analista proporciona un sistema de retroalimentación que
defina el entendimiento conseguido en la etapa de obtención.

 Especificación:
Aquí se documentan los requisitos acordados con el cliente, en un nivel
apropiado de detalle.
En la práctica, esta etapa se realiza conjuntamente con el análisis, por lo que
se puede decir que la especificación es el “pasar en limpio” el análisis realizado
previamente aplicando técnicas y/o estándares de documentación, como la
notación UML (Lenguaje de Modelado Unificado), que es un estándar para el
modelado orientado a objetos, por lo que los casos de uso y la obtención de
requisitos basada en los casos de uso se utilizan cada vez más para la
obtención de requisitos.

 Validación de los requisitos:

Por último, la validación garantiza que los requisitos, una vez analizados y
resueltos los posibles conflictos, correspondan realmente a las necesidades
de clientes y usuarios, para evitar que, a pesar de que el producto final sea
técnicamente correcto, no sea satisfactorio.

La validación puede llevar al analista a reescribir algunas especificaciones de

requisitos y, en otros casos, a obtener nuevos, producto de la aparición de
necesidades que hasta entonces estaban ocultas, para volver a evaluar el análisis
inicial, o para corregir y perfeccionar el conjunto de requisitos documentados.

PÁGINA 19
Elaborar la vista de despliegue del software.

Elegir herramientas necesarias para optimizar los procesos.

PÁGINA 20
Bibliografia
https://profile.es/blog/patrones-de-diseno-de-software/
https://docplayer.es/9392809-Patrones-de-diseno-ejercicios.html
https://www.google.com/search?q=patrones+de+dise%C3%B1o&tbm=isch&hl=es-419&chips=q:patrones+de+dise%C3%B1o,online_chips:arquitectura:LaaYlD-
50mo%3D&sa=X&ved=2ahUKEwjPkpXKntj5AhWPNd8KHXTyBfcQ4lYoAHoECAEQJA&biw=1113&bih=493#imgrc=GJZH9_cpLfKEuM
https://www.google.com/search?q=Elaborar+la+vista+de+despliegue+del+software.&rlz=1C1UEAD_esCO976CO976&sxsrf=ALiCzsZTKtnybkWqxjCrvC1-x3u-
LmgulA:1661298599877&source=lnms&tbm=isch&sa=X&ved=2ahUKEwjEhaXHk975AhXBVTABHdh9CVsQ_AUoAXoECAEQAw&biw=1130&bih=493&dpr=1.21#imgrc=km2u6-Y18v0pTM
https://iveconsultores.com/diagrama-de-flujo/

PÁGINA 21