Este documento describe los fundamentos, garantías y técnicas en el diseño y desarrollo de software. Explica conceptos clave como abstracción, modularidad, arquitectura, estructuras de datos y diseño orientado a objetos. También cubre garantías de calidad como planificación, compromiso y revisión por pares, así como técnicas de pruebas para garantizar software libre de defectos.

1. Fundamentos, Garantías y Técnicas en el
diseño y desarrollo de software
Elaborado por: Gerardo Valera

2. Contenido
• Fundamento del diseño de Software.
• Fundamento del diseño. Diseño orientado a objeto.
• Garantías de calidad del Software.
• Técnicas de pruebas de software.
• Mantenimiento de software (preventivo, seguridad).
• Fundamentos al requerimiento del diseño: especificaciones,
principios.
• Métodos de análisis de requerimientos.

3. Introducción
Los ingenieros de software son muy importantes para el mundo de la tecnología de hoy, crean software
que utilizamos todos los días, como Microsoft Office, correo electrónico, aplicaciones, juegos o cualquier
cosa que implique el uso de sistemas informáticos o software de sistemas móviles. Actualmente, el
desarrollo de software se ubica como el trabajo número uno en los para las importantes actualizaciones
organizacionales e industriales debido a los altos niveles de tecnología y nuevos avances a nivel
mundial. Aunque la demanda de desarrolladores no es nada nuevo, ha visto un aumento significativo en
los últimos dos años con el advenimiento de tecnologías como inteligencia artificial (AI), el blockchain,
aplicaciones multiplataformas, realidad mixta, aplicaciones web progresivas entre otras.
El diseño de esta tecnología implica mucho tiempo y detalle para los desarrolladores de software,
garantizando sistemas eficientes y que funcionen perfectamente y permita proporcionar servicios de alta
calidad y mejorar la experiencia del cliente. Es por eso que surge la importancia de hacer un estudio
detallado algunos conceptos clave, temas y habilidades relacionados con los fundamentos en el diseño,
requerimientos y especificación, así como también los principios, los fundamento de programación
orientada a objeto, método de análisis de requerimientos, mantenimiento de software, entre otros puntos
que permitirán formular y dar un buen inicio al diseño y desarrollo de software adecuado para un
propósito en un contexto organizativo.

4. Fundamento del diseño de Software.
Es un proceso mediante el cual los requisitos se traducen en una
representación de software. Inicialmente, la representación representa
una vista holística del software.
Diseño de software:
Requisitos
Gestión de
proyecto
Desarrollo
del Sistema
 Análisis
 Desarrollo
 Construcción
 Mantenimiento

5. a) Desde el punto de vista de la gestión de proyectos , el diseño del software se realiza en
dos pasos:
 Diseño preliminar: Se refiere a la transformación de requisitos en arquitectura de datos
y software.
 Diseño detallado: Se centra en los refinamientos de la representación arquitectónica
que conducen a una estructura de datos detallada y representaciones algorítmicas de
software.
b) Desde un punto de vista técnico , el diseño del software implica los siguientes pasos:
 Diseño de datos: Transforma el modelo de dominio de información creado durante el
análisis en estructuras de datos que se requerirán para implementar el software.
 Diseño arquitectónico: define la relación entre los principales componentes
estructurales del programa.
 Diseño de procedimiento: Transforma los componentes estructurales en una descripción
de procedimiento del software.
 Diseño de la interfaz: Establece los mecanismos de disposición e interacción para la
interacción hombre-máquina.

6. Conceptos Baciscos y Fundamentales para el
desarrollo de software
Abstracción: Se refiere a una poderosa herramienta de diseño, que
permite a los diseñadores de software considerar los componentes a
un nivel abstracto, mientras descuidan los detalles de implementación
de los componentes. Se puede utilizar de dos maneras:
 Como Proceso
 Como Entidad
Se refiere a un mecanismo para ocultar
detalles irrelevantes y representar solo las
características esenciales de un elemento
para que uno pueda enfocarse en cosas
importantes a la vez
Como entidad, se refiere a un
modelo o vista de un elemento

7. Abstracción Funcional:
Abstracción de Datos:
Control de Abstracción:
subprogramas parametrizados
Especificación de datos
Efectos deseados
Grupos compuesto por rutilas
visibles y ocultas
conjunto de atributos
subprogramas secuenciales
y manejadores de excepciones
Tipo de Abstracción

8. Modularidad: La modularidad se logra al dividir el software en
componentes con nombre y direcciones únicas, que también se conocen
como módulos.
Ejemplo: Un sistema complejo (programa grande) se divide en un
conjunto de módulos discretos de tal manera que cada módulo se puede
desarrollar independientemente de otros módulos.

9. Arquitectura: Se refiere a la estructura del sistema, que se compone de
varios componentes de un programa / sistema, los atributos (propiedades)
de esos componentes y la relación entre ellos.
Arquitectura del software permite a los ingenieros
de software analizar el diseño del software de
manera eficiente. Además, también les ayuda en la
toma de decisiones y en el manejo de riesgos.

10. Estructura de datos: Las estructuras de datos son estructuras
abstractas organizadas de manera particular que se utilizan para organizar
datos y proporcionar varias operaciones sobre ellos. Diferentes tipos de
estructuras de datos se adaptan a diferentes tipos de aplicaciones, y
algunas están altamente especializadas para tareas específicas.
Ejemplos:  Vectores (matriz o array)
 Lista Enlazada
 Pilas (stack)
 Colas(queue)
 Arboles (Binarios, Finitarios)
 Conjuntos
 Grafos
 Tablas Hash

11. Refactorización: Es una actividad de diseño
importante que reduce la complejidad del diseño
del módulo, manteniendo su comportamiento o
función sin cambios. Es un proceso de
modificación de un sistema de software para
mejorar la estructura interna del diseño sin
cambiar su comportamiento externo.
Concurrencia: Cada sistema debe estar diseñado
para permitir que múltiples procesos se ejecuten
simultáneamente, siempre que sea posible. Por
ejemplo, si el proceso actual está esperando que
ocurra algún evento, el sistema debe ejecutar
algún otro proceso mientras tanto.

12. Características que se deben tomar en cuenta como
fundamento del diseño de Software
Comprensión: Este requiere claridad y declaración de la naturaleza explicita
de la definición de proceso.
Visibilidad: Se refiere a la capacidad de observar la salida de varias
actividades del proceso, de manera que se mida el progreso de proceso.
Confiabilidad: Se refiere a la capacidad del proceso para evadir errores o
detectar errores y manejarlos antes de que estos avancen en el producto.
Robustez: Se refiere a la capacidad del proceso de no detenerse a pesar de
problemas inesperados.
Facilidad de mantenimiento: Se refiere a la cantidad de modificaciones que
pueden hacerse al sistema de software sin producir errores.

13. Facilidad de verificación: Un proceso es verificable si sus propiedades
pueden ser fácilmente verificables.
Rapidez: Se refiere a la agilidad y rapidez del proceso para ser capaz de
entregar un producto final a partir de las especificaciones.
Facilidad de soporte: Se refiere a la posibilidad de que las actividades del
proceso sean soportadas por un conjunto de herramientas automatizadas.
Facilidad de aceptación: Se refiere a la capacidad del proceso a ser aceptado
y usado por el equipo de ingenieros.
Facilidad de adaptación: Se refiere a la capacidad del proceso a ser
modificado para satisfacer las necesidades de cambio en el ambiente de
desarrollo.

14. En el proceso de producción de software se debe tomar en cuenta lo
siguientes principios:
Arquitectura: Asocia la capacidades del sistema especificadas en el
requerimientos con los componentes del sistema que habrían de implantar.
Diseño de código: Comprende algoritmo y estructura de datos; los
componentes son aquí primitivas del lenguaje de programación, tales como
números, caracteres, punteros ve hilos de control.
Diseño ejecutaba: Remite al diseño de código a un nivel de detalles todavía
mas bajo y trata de cuestiones ales como la asignación de memoria, formato
de datos entre otros.

15. Fundamento del diseño. Diseño orientado a objeto
La fase diseño de software es técnicamente, la parte central de la ingeniera
de software, en donde s desarrollan, revisan y se documentan los
refinamientos progresivos de la estructura de datos, de la estructura del
programa y de los detalles procedimentales.
El diseño se divide en:
Diseño de datos
Diseño Arquitectónico
Diseño procedimental:
Transformación de datos estructura
Relaciones entre los principales elementos
Transformación estructural
Descripción procedimental

16. Encapsulación
La encapsulación es un mecanismo que consiste
en organizar datos y métodos de una estructura,
conciliando el modo en que el objeto se
implementa, es decir, evitando el acceso a datos
por cualquier otro medio distinto a los
especificados. Por lo tanto, la encapsulación
garantiza la integridad de los datos que contiene
un objeto.

17. Es tomar un sistema y tener la capacidad de
segmentarlo en diversas partes independientes, que
tengan sentido.
Modularidad
La modularidad se
refiere al concepto de
crear varios módulos
primero y luego vincularlos
y combinarlos para formar
un sistema completo. La
modularidad permite la
reutilización y minimiza la
duplicación.

18. Como acoplamiento entendemos los cambios en
piezas y el grado de repercusión en otros elementos del sistema. Es decir,
tengo una pieza del sistema y la cambio. Inmediatamente eso repercute
a otras piezas del sistema, de modo que a ese grado de repercusión le
denominamos acoplamiento.
Acoplamiento
Existen dos tipos
de acoplamiento
Significa que son en su mayoría
independientes
Sueltos
Apretados En general, acoplamiento apretado
significa que las dos clases a menudo
cambian juntas.

19. Es la forma de organizar los módulos, existiendo jerarquías de todo tipo
y con diversos grados de dependencia, responsabilidad, incumbencia,
composición, entre otros.
Jerarquización
La formación de la jerarquía
elimina el código redundante y
organiza nuestras abstracciones en
algo más fácil de entender
A través de la jerarquía, un sistema puede estar formado por
subsistemas interrelacionados, que pueden tener sus propios subsistemas y
así sucesivamente hasta que se alcanza el nivel más bajo de los
componentes.

20. Mecanografía
Concurrencia
Persistencia Un objeto ocupa un espacio de memoria y existe
durante un período de tiempo determinado
Permite realizar múltiples tareas o procesos
simultáneamente.
Escribir es la aplicación de la noción de que un
objeto es una instancia de una sola clase o tipo
Los dos tipos de mecanografía son:
Tipo fuerte : aquí, la operación en un objeto se verifica en el momento de la
compilación, como en el lenguaje de programación Eiffel.
Escritura débil : aquí, los mensajes pueden enviarse a cualquier clase. La operación
se verifica solo en el momento de la ejecución, como en el lenguaje de
programación Smalltalk

21. Reduce la labor de programación al permitir que se utilicen los
objetos comunes con facilidad. es decir, se puede crear una clase a partir de otra.
Herencia
UML Es una herramienta de modelado que mejora en forma considerable
la calidad del análisis y diseño de sistemas, así como del producto final.
Modelado de caso de uso Describe qué hace un sistema sin describir cómo
lo hace; es decir, es un modelo lógico el sistema.

22. Garantías de calidad del Software
Un cliente que confía en usted para un proyecto, pone una gran
responsabilidad sobre sus hombros. Debe entregar un producto que
cumpla con los estándares de alta calidad y que sea mejor que los sistemas
competitivos que están surgiendo en el mercado. Pero, ¿qué se necesita
para entregar un producto de alta calidad?
En términos simples, se dice que su software es de alta calidad cuando:
• Cumple con los requisitos y satisfacción del cliente.
* Está (cerca de ser) libre de defectos.
* Se entrega según el horario comprometido.
Por lo tanto la calidad de un producto software, es el grado de relación
que tiene el producto para satisfacer las necesidades del usuario.

23. Para eso se presentan diez elementos esenciales que
contribuyen con la entrega de producto de alta calidad:
Planificación: Enumere las actividades involucradas en la tarea y
establezca los distintos hitos que deben lograrse, comprendiendo
claramente cuales son los requisitos del cliente.
Compromiso: En el desarrollo de software, el compromiso es un acuerdo
entre una organización y el cliente, donde la organización se compromete a
cumplir con algunos o todos los requisitos del cliente.
Seguimiento de tareas: Realice un seguimiento de sus tareas de forma
regular. Establecer objetivos específicos diarios / semanales. Se pueden usar
herramientas como Gantt Chart para monitorear el progreso del proyecto y
mantener un seguimiento de los distintos hitos logrados / por lograr.

24. Ser honesto: Ser honesto contigo mismo y con los clientes. Nunca se
sienta tentado a complacer al cliente, proporcionando información falsa. No
trates de barrer las cosas debajo de la alfombra.
Humildad y corajela: Humildad y el coraje son componentes vitales en el
desarrollo de cualquier producto de alta calidad. Debe estar listo para
aceptar sus errores y tener el coraje de aprender y mejorar sobre
ellos. Como "recursos humanos", necesitamos mejorar continuamente.
Trabajo en equipo: Involucra a un grupo de personas, luchando por un
objetivo común, de tal forma que: entregar un producto de alta calidad no
es responsabilidad de una sola persona. Es todo el equipo el responsable de
ello. Si el producto falla, cada miembro del equipo es responsable de ellos.

25. Revisión por pares La revisión: La Revisión por Pares se refiere a la
participación de los miembros del equipo en el desarrollo y evaluación de la
tarea / actividad realizada por un individuo.
 Intercambio de información mejorado
 Detección temprana de defectos
 Revisión plenaria y de calidad
 Revisión a su propio ritmo

26. Intercambio de información mejorado: A través de la revisión por
pares, cada miembro del equipo conoce la tarea realizada por otro
miembro. De esta manera, aunque todos los miembros del equipo pueden
estar trabajando en diferentes fases / módulos, el resultado es que, en
efecto, todos trabajan juntos en todas las fases.
Detección temprana de defectos: Durante el proceso de revisión, un
enfoque seleccionado puede ser identificado como incorrecto o puede llevar
a problemas en una etapa posterior. Por lo tanto, el proceso de revisión por
pares permite capturar defectos en una etapa temprana.

27. Garantía de calidad y control de Calidad: Consiste en verificar que el
producto esté libre de defectos y que cumpla con los requisitos del
cliente. El aseguramiento de la calidad es parte de todo el proceso de
desarrollo de software:
 Preparación de especificaciones de requisitos
 Diseño y escritura de algoritmos
 Codificación y pruebas unitarias
 Pruebas de integración
 Revisiones entre pares, Reuniones
 Documentación

28. Prevenga los defectos y cúbralos pronto: Un proceso de calidad debe
producir un software de casi cero defectos que cumpla con los requisitos del
usuario. Los siguientes puntos deben tenerse en cuenta para prevenir
defectos:
 Evitar introducir nuevos defectos en el código.
 Utilice una lista de verificación.
 El código debe ser simple. El código simple es fácil de mantener.
 El diseño complejo conduce a una mala capacidad de prueba.
 El diseño debe ser central para el usuario.
 Prueba a medida que codificas.
 El cambio de código debe ser compatible con la facilidad de prueba,
depuración y modificación.

29. Responsabilidad del producto: En este contexto, asegúrese de que,
antes del envío, todos los artículos estén correctos y completos según el
acuerdo.

30. Responsabilidades de lanzamiento de software
El Gerente de producto decide cuántas versiones de un producto mantendrá
y respaldará la compañía.
Los programadores utilizan la biblioteca de componentes de software para
controlar todos los cambios, comentar los cambios realizados e indicar los
números de versión.
El Quality Assurance Manager administra la biblioteca de software y lanza
versiones de software que pasan con éxito las pruebas.
El Diseñador de software determina los componentes de software
específicos que conforman la versión final del producto.

31. Técnicas de pruebas de software
 Las técnicas de prueba de software te ayudan a diseñar mejores casos.
 Dado que la prueba exhaustiva no es posible; Las técnicas de prueba
ayudan a reducir la cantidad de casos de prueba que se ejecutarán al
tiempo que aumentan la cobertura de la prueba.
 Ayudan a identificar las condiciones de prueba que de otro modo son
difíciles de reconocer.
A continuación se presentaran 5 técnicas importantes para de prueba de
software:

32. Análisis del valor límite (BVA): Esta
técnica de prueba de software se basa en
el principio de que, si un sistema
funciona bien para estos valores
particulares, funcionará perfectamente
bien con todos los valores que se
encuentren entre los dos valores límite.

33. Pautas para el análisis del valor límite:
 Si una condición de entrada está restringida entre los valores x e y,
entonces los casos de prueba deben diseñarse con valores x e y, así como
los valores que están por encima y por debajo de x e y.
 Si una condición de entrada es un gran número de valores, se debe
desarrollar el caso de prueba que debe ejercer los números mínimo y
máximo. Aquí, los valores por encima y por debajo de los valores mínimo
y máximo también se prueban.
 Aplicar las pautas 1 y 2 a las condiciones de salida. Da una salida que
refleja los valores mínimos y máximos esperados. También prueba los
valores de abajo o arriba.

34. División de Clases de Equivalencia: La partición de clase equivalente le
permite dividir el conjunto de condiciones de prueba en una partición que
debería considerarse la misma. Este método de prueba de software divide el
dominio de entrada de un programa en clases de datos a partir de los cuales
deben diseñarse los casos de prueba.

35. Tabla de decisiones basada en pruebas: Una tabla de decisiones también se
conoce como tabla de causa-efecto. Esta técnica de prueba de software se
utiliza para funciones que responden a una combinación de entradas o
eventos. Por ejemplo, un botón de envío debe estar habilitado si el usuario
ha ingresado todos los campos requeridos.

36. Mantenimiento de software (preventivo, seguridad)
El mantenimiento del software es el proceso de modificación de un
producto de software una vez que se ha entregado al cliente. El objetivo
principal del mantenimiento del software es modificar y actualizar la
aplicación de software después de la entrega para corregir fallas y mejorar
el rendimiento

37. El mantenimiento del software debe realizarse para:
 Corregir las fallas.
 Mejorar el diseño.
 Implementar mejoras.
 Interfaz con otros sistemas.
 Acomode programas para que se puedan utilizar diferentes hardware,
software, características del sistema e instalaciones de
telecomunicaciones.
 Migrar software heredado.
 Retirar el software.

38. Categorías de mantenimiento de software
Mantenimiento correctivo: Permite la corrección de los detalles
presentados mientras el sistema está en uso o para mejorar el
rendimiento del sistema.
Mantenimiento adaptativo: Esto incluye modificaciones y
actualizaciones cuando los clientes necesitan que el producto se
ejecute en nuevas plataformas, en nuevos sistemas operativos o
cuando necesiten que el producto interactúe con un nuevo
hardware y software.

39. Mantenimiento perfecto: Un producto de software necesita mantenimiento
para admitir las nuevas funciones que los usuarios desean o para cambiar
los diferentes tipos de funcionalidades del sistema de acuerdo con las
demandas del cliente.
Mantenimiento preventivo: Este tipo de mantenimiento incluye
modificaciones y actualizaciones para evitar problemas futuros del
software. Los objetivos son atender los problemas, que no son significativos
en este momento pero pueden causar problemas graves en el futuro.

40. Fundamentos al requerimiento del diseño:
especificaciones, principios
Los Requerimientos del diseño, es la Fase en donde, los usuarios y analistas
se reúnen para identificar los objetivos de la aplicación o el sistema, y para
identificar los requerimientos de información que surgen a partir de estos
objetivos.
El análisis de requerimientos facilita al ingeniero de sistemas especificar la
función y comportamiento de los programas, indicar la interfaz con otros
elementos del sistema y establecer las ligaduras de diseño que debe
cumplir el programa.

41. Los requerimientos puedes dividirse en requerimientos funcionales y
requerimientos no funcionales.
Los requerimientos funcionales definen las funciones que el sistema será
capaz de realizar. Describen las transformaciones que el sistema realiza
sobre las entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con características que
de una u otra forma puedan limitar el sistema, como por ejemplo, el
rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad
(robustez del sistema, disponibilidad de equipo), mantenimiento,
seguridad, portabilidad, estándares

42. Características de los requerimientos
Necesario
Conciso:
Consistente
Verificable:
Fácil de leer y entender
Si su omisión provoca una deficiencia en
el sistema a construir
Es consistente si no es contradictorio con otro requerimiento
Cuando tiene una sola interpretación.No ambiguo
Que permita hacer uso de: Interpretación
Análisis
Demostración

43. Los requerimientos de un proyecto de software Permiten:
 Planear el proyecto y los recursos que se usarán en él.
 Especificar el tipo de verificaciones que se habrán de realizar al sistema.
 Planear la estrategia de prueba a la que habrá de ser sometido el sistema.
 Son el fundamento del ciclo de vida del proyecto.
El análisis de requerimientos puede dividirse en cuatro
áreas:
1.- Reconocimiento del problema
2.- Evaluación y síntesis
3.- Especificación
4.- Revisión.

44. Especificación de Requisitos de Software(SRS ) :
Es la actividad en la cual se genera el documento, con el mismo
nombre, que contiene una descripción completa de las necesidades y
funcionalidades del sistema que será desarrollado; describe el alcance
del sistema y la forma en como hará sus funciones, definiendo los
requerimientos funcionales y los no funcionales.
Los clientes y usuarios utilizan la SRS para comparar si lo que se está
proponiendo, coincide con las necesidades de la empresa. Los analistas y
programadores la utilizan para determinar el producto que debe
desarrollarse. El personal de pruebas elaborará las pruebas funcionales y de
sistemas en base a este documento. Para el administrador del proyecto
sirve como referencia y control de la evolución del sistema.

45. Principios para una buena especificación:
1. Separar funcionalidad de implementación.
2. Se necesita un lenguaje de especificación de sistemas orientado al
proceso.
3. Una especificación debe abarcar el sistema del cual el software es una
componente.
4. Una especificación debe abarcar el entorno en el que el sistema opera.
5. Una especificación de sistema debe ser un modelo cognitivo.
6. Una especificación debe ser operacional.
7. La especificación del sistema debe ser tolerante con la incompletitud y
aumentable.
8. Una especificación debe ser localizada y débilmente acoplada.

46. Aspectos a considerar para el desarrollo de
un software
Consideración del proceso para el desarrollo de software
 Se debe evitar problemas a tiempo.
 A demás se debe conocer cómo y cuándo y cuánto diseñar, Cuándo y
cuánto probar, Cuándo y cómo involucrar a los clientes.
Obtención de requisitos, documentación y evaluación
A través de esta fase permite a los diseñadores:
 Qué es lo que realmente quiere el cliente.
 Medir el éxito objetivamente.
 Documentar de manera confiable las expectativas.

47. Diseño para atributos de calidad: Permite conocer:
Como diseñar un sistema para poder escalar a millones de usuarios.
Estrategias para el control de calidad: Incluye:
 La medición, la inspección y el análisis estático y dinámico.
Qué estrategia de control de calidad es la mejor para un sistema
determinado.
 Qué podemos automatizar y cuándo debemos mantener a los humanos
informados.
 Cuántas pruebas y qué tipo de pruebas deberían hacer.
 Qué cualidades son importantes para asegurar más allá de la corrección
funcional.
 Y además podemos evaluar la facilidad de uso, la escalabilidad, la
confiabilidad, el rendimiento y garantizar estáticamente la ausencia de
ciertos problemas de seguridad.

48. Métodos empíricos en ingeniería de software
 Este método es necesario porque a través del mismo podemos medir
los atributos de calidad como el rendimiento, la seguridad y la
confiabilidad. A demás cómo los usuarios interactúan con el sistema.
Gestión de tiempo y equipo: Permite:
 Estimar la duración y los costos de un proyecto.
 Monitorear el progreso y los riesgos para reconocer los problemas de
manera temprana.
 Coordinar a los desarrolladores en un equipo.
 Formar y desarrollar equipos.
 Cómo seleccionar y motivar a los miembros del equipo.
 Cómo lidiar con la dinámica del equipo.

49. Métodos de análisis de requerimientos
Existe un gran número de técnicas para obtener requerimientos. A
continuación describo las más utilizadas:
Entrevistas
Es un intento sistemático de recoger
información de otra persona a través
de una comunicación interpersonal
que se lleva a cabo por medio de una
conversación estructurada. Se deben
tomar en cuenta los siguientes
aspectos: Preparación Formato
Entrevistar al personal
adecuado

50. Desarrollo Conjunto de Aplicaciones ( JAD )
Es una técnica que se utiliza para
promover la cooperación y el trabajo en
equipo entre usuarios y analistas
Consiste en realizar sesiones en las que participan usuarios
expertos del dominio junto a analistas de software. La idea es
aprovechar la dinámica de grupos aplicando un proceso de trabajo
sistemático y organizado, apoyado por elementos visuales de
comunicación y comprensión de soluciones.

51. Desarrollo de Prototipos
Los prototipos de sistema permiten a los usuarios experimentar
para ver cómo éste ayuda a su trabajo. Fomentan el desarrollo de
ideas que desembocan en requerimientos.
 Se identifican las discrepancias entre los
desarrolladores y los usuarios.
 Permite determinar si requerimientos son
inconsistentes y/o están incompletos.
 Requerimientos son inconsistentes y/o
están incompletos.
 Se utiliza como base para escribir la
especificación.

52. Observación:
Por medio de esta técnica el analista
obtiene información de primera mano
sobre la forma en que se efectúan las
actividades.
Con la observación, se puede ver ideas para mejorar procesos o eliminar
actividades innecesarias del nuevo sistema.

53. Estudio de documentación
Varios tipos de documentación, como
manuales y reportes, pueden proporcionar
al analista información valiosa con respecto
a las organizaciones y a sus operaciones.
Dicha documentación (si existe) podría incluir
detalles de la interfaz, manuales de usuario y
manuales de proveedores de software.

54. Cuestionarios
El uso de cuestionarios permite a los
analistas reunir información proveniente de
un grupo grande de personas.
Al igual que con las entrevistas, se debe seleccionar
a los encuestados. El analista debe asegurar que el
conocimiento y experiencia de éstos califiquen para
dar respuestas a las preguntas.

55. Tormenta de ideas ( Brainstorming )
Consiste en reuniones con cuatro a diez personas donde como primer paso
sugieren toda clase de ideas sin juzgar su validez, por muy disparatadas que
parezcan, y después de recopilar todas las ideas se realiza un análisis
detallado de cada propuesta.
Esta técnica se puede utilizar para
identificar un primer conjunto de requisitos
en aquellos casos donde no están muy
claras las necesidades que hay que cubrir, o
cuando se esta creando un sistema que
habilitará un servicio nuevo para la
organización.

56. Puntos de Vista
Los métodos orientados a puntos de vista
(viewpoints) toman en consideración estas
perspectivas diferentes y las utilizan para
estructurar y organizar tanto el proceso de
obtención, como los requerimientos
mismos.
Las etapas principales de este método son
Identificación de puntos de vista
Estructuración de puntos de vista
Documentación de puntos de vista
Trazado del punto de vista del sistema

57. Escenarios
Estos se utilizan para documentar el comportamiento del sistema cuando
se le presentan eventos específicos
Los Casos de Uso son una técnica que se
basa en escenarios para la obtención de
requerimientos. Actualmente se han
convertido en una técnica fundamental que se
utiliza para analizar y describir modelos de
sistemas orientados a objetos.

58. Etnografía
Es una técnica de observación que se puede utilizar para entender los
requerimientos sociales y organizacionales.
La etnografía es especialmente efectiva para descubrir dos tipos de
requerimientos:
 Los requerimientos que se derivan de la forma en la que la gente trabaja
realmente más que de la forma en la que las definiciones de los
procesos establecen que debería trabajar.
 Los requerimientos que se derivan de la cooperación y conocimiento de
las actividades de la gente.

59. Estrategia para la obtención de requerimientos
 Aprender todo lo que se pueda de los documentos, formularios,
informes y archivos existentes.
 De ser posible, se observará el sistema en acción.
 Diseñar y distribuir cuestionarios para aclarar cuestiones que no se
comprenden bien.
 Realizar entrevistas (o sesiones de trabajo en grupo, como JAD).
 Se verifican los requerimientos a través del uso de técnicas como
Entrevistas, Observación y orientados a Puntos de Vista.

60. Conclusión
Al desarrollar software o sistemas informáticos que contemplen el uso tecnológico de la computación,
la definición de requisitos antes de iniciar el desarrollo puede ahorrar tiempo y dinero, ya que define
claramente todo lo que el software debe cumplir y es una base de partida para definir otros elementos de
un producto, como los costos y los horarios, además es importante conocer que no hay reemplazo para
los buenos requisitos, pero cada organización de desarrollo adoptará un enfoque único del proceso basado
en sus necesidades.
Los requisitos deben ser comprensibles para todas las partes interesadas (cliente, propietario del
producto, equipo de desarrollo) y estar libres de ambigüedades (todos los interesados ​​deben entender los
requisitos de la misma manera). Por lo tanto, la principal tarea de los requisitos es garantizar que sean
comprendidos por todos los interesados.
Todos los productos de desarrollo de software, ya sean creados por un equipo pequeño o una gran
corporación, requieren alguna documentación relacionada, y para ellos existe la especificación de
software, esta permite explicar la funcionalidad del producto, unificar la información relacionada con el
proyecto, discutir todas las preguntas importantes que surjan entre las partes interesadas y los
desarrolladores. El objetivo principal de la documentación efectiva es garantizar que los desarrolladores y
las partes interesadas vayan en la misma dirección para lograr los objetivos del proyecto.
Por lo tanto Cuanto más sólidos sean los cimientos y la comprensión del proyecto, más suave resultará
cuando el desarrollo comience a pasar a las fases de Pruebas y Soporte del proyecto.

61. Otro punto importante es el mantenimiento de software. Se plantea, que si bien las aplicaciones de
software no tienen partes móviles que están sujetas a desgaste físico, la mayoría de las veces tienen
dependencias con su entorno de trabajo. Con muy pocas excepciones, como el entorno de trabajo cambia
inevitablemente, los supuestos sobre los que se basa la aplicación se desmoronan. Eventualmente, la
aplicación deja de funcionar o pierde su valor. Para ello existe el mantenimiento correctivo se ocupa de
corregir los errores que se observan cuando el software está en uso y el mantenimiento preventivo implica
implementar cambios para evitar la ocurrencia de errores.
Por ejemplo, si libera un sistema de software y sus usuarios se encuentran con un error, se requiere una
acción de mantenimiento correctivo para solucionarlo. Tenga en cuenta que, si los usuarios nunca fueron
afectados por el error y usted lo resuelve antes de que alguien lo note, la acción de mantenimiento es
preventiva o adaptable. Sin embargo, si incluso un solo usuario podría haber sido afectado, entonces
solucionar el problema es una acción de mantenimiento correctivo.
Respecto al diseño orientado a objeto, Se puede decir con seguridad que el objeto ha sido la fuerza
motriz en la industria de la programación durante mucho tiempo y lo seguirá siendo en el futuro
previsible. La evidencia para apoyar esta declaración es bastante convincente, ya que hoy en día, casi todas
las principales metodologías de desarrollo de software se basan en objetos. Como resultado, prácticamente
todos los lenguajes de programación, lenguajes de script y diseños de aplicaciones están orientados a
objetos o basados ​​en objetos.

62. BIBLIOGRAFÍAS
Chaparro J. (2018). Fundamento de Diseño de software: Departamento de Ingeniería de Sistemas Universidad de
Oriente - Núcleo Monagas – Venezuela. Disponible: https://sites.google.com/a/udo.edu.ve/fundamentos-de-
diseno-de-software/.[consultada: 2019, julio 4].
Turmero I. (2017). Diseño orientado por objeto: Monografias.com. Disponible:
https://www.monografias.com/trabajos108/diseno-orientado-objeto/diseno-orientado-
objeto.shtml.[consultada: 2019, julio 2].
Calero W. (2010). Garantía de calidad de software: Ingeniería d software. Disponible:
http://ingenieraupoliana.blogspot.com/2010/10/garantia-de-calidad-del-software.html.[consultada: 2019, julio
6].
Panel Testin (2015). Software QA: Creación de software inteligente. Disponible:
https://www.panel.es/blog/software-qa-cuales-son-los-tipos-de-pruebas-software/.[consultada: 2019, julio 5].

63. BIBLIOGRAFÍAS
Apiumhub (2017). Técnica de testeo de software y herramientas y herramientas. Disponible:
https://apiumhub.com/es/tech-blog-barcelona/tecnicas-de-testeo-de-software/.[consultada: 2019, julio 7].
Romero G.(2016). ¿Qué es el análisis de requerimiento?: Espacios Business Media. Disponible:
http://www.espacios.media/que-es-un-analisis-de-requerimientos/.[consultada: 2019, julio 6].
Almudena(2017). Que herramientas utilizar para el análisis de requerimientos de usuario: OQOTECH. Disponible:
https://www.oqotech.com/blog/informatizacion-de-procesos/herramientas-analisis-de-requerimientos-de-
usuario/.[consultada: 2019, julio 5].