SENA

CENTRO INDUSTRIAL DE MANTENIMIENTO Y MANUFACTURA

REGIONAL BOYACÁ.

Técnico en PROGRAMACIÓN DE APLICACIONES PARA DISPOSITIVOS

MÓVILES (2455338)

EVIDENCIA GA1-220501092-AA1-EV01.
Documento informe de fuentes

Presentado a instructor: NANCY JOHANA PATIÑO RUIZ

Presentado por: GRUPO 6

Integrantes: Hawer Gómez

Nicolle Mercado
Luis Montaño

Febrero 20 de 2022
 INTRODUCCIÓN

los conceptos básicos sobre la ingeniería de requisitos, sus fases técnicas y las
herramientas necesarias para la gestión y especificación de los requisitos es
fundamental junto con la recolección de datos que es también indispensable al
momento de desarrollar los sistemas de información, a través de este trabajo
encontraremos el proceso que se debe seguir para tal fin, así como las técnicas e
instrumentos que se pueden utilizar.

En ese sentido, los analistas utilizan una variedad de métodos para recopilar los
datos sobre una situación existente, como entrevistas, cuestionarios, inspección
de registros (revisión en el sitio) y observación. Cada uno tiene ventajas y
desventajas; es por ello que, por lo general, se utilizan dos o tres
simultáneamente, para complementar el trabajo y asegurar una investigación
completa.
 ÍNDICE

1 ciclo de la vida de software…………………………………………………………1

1.2 Las fases………………………………………………………………..1

1.2.1 Planificación……………………………………………………………..1

1.2.2 Análisis………………………………………………………………………….1

1.2.3 Diseño……………………………………………………………………………1

1.2.4 Pruebas…………………………………………………………………………1

1.2.5 Mantenimiento……………………………………………………………1

1.3 Paradigmas de los modelos de ciclo de vida del software…………………..1

1.3.1 Modelo de Cascada…………………………………………………………1

1.3.2 Modelo Espiral…………………………………………………………….2

1.3.3 Modelo Scrum……………………………………………………………..2

1.3.4 Modelo Kanban……………………………………………………………2

2. Fase de definición de requisitos………………………………………………3

3. Requisitos…………………………………………………………………….3

3.1 Requerimientos funcionales…………………………………………………3

3.2 Requerimientos no funcionales………………………………………………4

4. Ingeniería de Requisitos………………………………………………………4

4.1 Etapas de la ingeniería de requisitos…………………………………………4

4.1.2 Elicitación de requisitos……………………………………………………5

4.1.2.1 Planeación……………………………………………………………….5

4.1.2.2 Los stakeholders………………………………………………………..6

4.1.2.3 técnicas e instrumentos para elicitar requisitos ………………………..6

4.1.2.3.1 Entrevista………………………………………………………………6

4.1.2.3.2. Encuesta……………………………………………………………….7

4.1.2.3.3. Observación…………………………………………………………….8

4.1.2.3.4. Sesiones grupales………………………………………………………8

4.1.3 Análisis………………………………………………………………………9

4.1.4 Especificación……………………………………………………………….9

4.1.5 Validación……………………………………………………………………9
1. CICLO DE VIDA DEL SOFTWARE
También conocido como (SDLC o Systems Development Life Cycle), es el proceso
que se sigue para construir y hacer evolucionar un determinado software.

Integran un ciclo de vida las fases y los Entregables.

1.2 LAS FASES

Las fases del modelo de ciclo del software son: planificación, análisis, diseño,
implementación, pruebas y mantenimiento.

1.2.1 PLANIFICACIÓN: En esta fase se realiza el planteamiento del problema, se

definen los alcances y los objetivos del software.

1.2.2 ANÁLISIS: Es donde se definen los requisitos qué dirigirán el desarrollo del
proyecto de software.

1.2.3 DISEÑO: Aquí se estudian las posibles opciones de implementación para el

Software que hay que construir, es la estructura en sí mismo de acuerdo con los
requisitos que solicité el cliente.

1.2.4 PRUEBAS: En esta fase se busca detectar fallos cometidos en las etapas
anteriores para corregirlos.

1.2.5 MANTENIMIENTO: En esta fase tenemos el mantenimiento correctivo, el

adaptativo y el perfectivo. El objetivo es asegurar que el uso del proyecto que se
pretendía se mantenga estable.

1.3 PARADIGMAS DE LOS MODELOS DE CICLO DE VIDA DEL SOFTWARE

Para proporcionar una metodología común entre el cliente y la empresa, se utilizan

los modelos de ciclos de vida o paradigmas del desarrollo del software.

Entre ellos encontramos el paradigma tradicional, el paradigma orientado a objetos

y el paradigma de desarrollo ágil. Veamos algunos ejemplos de los modelos de
estos paradigmas.

1.3.1 MODELO DE CASCADA

Pertenece a los modelos del paradigma tradicional es uno de los primeros

modelos del ciclo de vida del desarrollo consiste en que cada una de las
actividades genera entradas para el proceso subsiguiente y así sucesivamente
esto debe suponer que una actividad debe terminarse para poder continuar con la
siguiente
1.3.2 MODELO ESPIRAL

Es también otro modelo del paradigma tradicional se basa en una serie de ciclos
repetitivos para ir ganando madurez en el producto final hasta que el cliente o el
usuario obtengan la satisfacción de sus necesidades

1.3.3 MODELO SCRUM

Este modelo se basa en el desarrollo incremental conforme pasan las fases mayor
será el tamaño del proyecto que se está desarrollando utiliza varios procesos
dónde se realiza un análisis de los requerimientos del sistema y se señala cuáles
son los objetivos a corto o mediano plazo.

Cómo ventajas tienen que se puede regular las expectativas del usuario se
pueden tener resultados anticipados es flexible y se adapta a cualquier contexto
área o sector y Los problemas son gestionados en el mismo momento de su
aparición.

1.3.4 MODELO KANBAN

Pertenece al paradigma de desarrollo ágil. El modelo está enfocado a llevar a
cabo tareas pendientes y se pueden dividir en principios básicos y prácticas. Se
crea un tablero con etiquetas dónde se selecciona cada una de las fases de su
desarrollo, y se clasifican de acuerdo con los equipos de trabajo dónde se le
asigna el objetivo corto a mediano y largo plazo.

Nota. Adaptada de Anderson.

Figura 5. Modelo ágil Kanban.

2 FASE DE DEFINICIÓN DE REQUISITOS

En la primera fase del ciclo de vida del Software también llamada fase de análisis,
aquí se recopila, Se examina y se fórmula los requisitos del cliente y la verificación
restricciones.

Tabla 1/ Actividades y artefactos de la fase de definición de requisitos

Fase Actividades Artefactos

Análisis (definición de Definición del alcance del

requisitos). proyecto.

Identificación del negocio. Modelo del negocio.

Toma de requerimientos. Análisis y realización de casos

de uso.

Estudio de procesos de Modelo de procesos y

negocio. actividades de negocio.

Calendarización del Cronograma del proyecto.

proyecto.

3. 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 cobran importancia dentro del ciclo de vida del software, ya que
establecen el alcance del trabajo y definen estrategias de desarrollo riesgos y
toma de decisiones.
También indican al equipo del proyecto qué es lo que requiere el usuario, en si las
necesidades del negocio y el éxito o fracaso de un proyecto, se debe a la calidad
de los requisitos.

En la siguiente clasificación se observa la que se da a los requerimientos del

sistema, la cual se encuentra dividida con base en lo que se va a describir, las
clasificaciones son:

3.1 REQUERIMIENTO FUNCIONALES

Son declaraciones de los servicios que debe proporcionar el sistema, de la

manera en que este debe reaccionar a entradas particulares; o también pueden
declarar explícitamente lo que el sistema no debe hacer.

3.2 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 se encuentra todo lo referente a la fiabilidad, el tiempo de
respuesta y la capacidad de almacenamiento.

Ejemplos de requisitos funcionales y no funcionales:

Tabla 2/ Requisitos.

Funcionales No funcionales

Se debe ingresar cédula, nombre y Las consultas deben resolverse en menos de

teléfono 3 segundos.

de cada cliente.

Se requiere un listado de clientes El lenguaje de programación debe ser Java.

por zona.

4. INGENIERÍA DE REQUISITOS

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
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.

4.1 ETAPAS DE LA INGENIERÍA DE REQUISITOS

4.1.2 ELICITACIÓN DE REQUISITOS

La elicitación de requisitos es el primer paso que se debe llevar a cabo en un el

proceso de ingeniería de requisitos, lo que se busca es utilizar técnicas que
permitan recopilar información con el objetivo de:
- Conocer el dominio del problema para poder comunicarse con clientes y
usuarios y entender sus necesidades.
- Conocer el sistema actual (manual o informatizado) y sus aspectos
positivos y negativos.
- Identificar las necesidades, tanto explícitas como implícitas, de clientes y
usuarios y sus expectativas sobre el sistema a desarrollar

4.1.2.1 PLANEACIÓN

Lo que se busca en la planeación es detectar las tareas a realizar para así saber
cual es el proceso que se debe llevar a cabo en la actividad de elicitación de la
fase de ingeniería de requisitos del desarrollo de software, como lo son:

a) Identificar las fuentes de requerimiento:

En cada proyecto de desarrollo de software se encuentran conjuntos de fuentes de
requisitos con lo que tanto el usuario y experto logran obtener información idónea
y detallada acerca de los problemas y necesidades del usuario.
Incluso los sistemas y procesos que encontramos también se consideran fuentes
de requisitos, al igual que, la documentación y especificaciones de requisitos
anteriores para poder obtener la información necesaria acerca de la organización y
su entorno.
Estas fuentes de requerimientos, se pueden clasificar en:

Fuentes primarias
Aportan material de primera mano (es protagonista o testigo de los hechos), estas
fuentes contienen información original, que ha sido publicada por primera vez y
que no ha sido filtrada, interpretada o evaluada por nadie más.

Fuentes secundarias
Toman y reproducen la información que le aportó una fuente primaria. Son las que
contienen información primaria, sintetizada y reorganizada y están especialmente
diseñadas para facilitar y maximizar el acceso a las fuentes primarias o a sus
contenidos. Parten de datos pre elaborados, como pueden ser datos obtenidos de
anuarios estadísticos, internet, medios de comunicación, bases de datos
procesadas con otros fines, artículos y documentos relacionados con un tema,
libros, tesis, informes oficiales, etc.

Fuentes terciarias
Son guías físicas o virtuales que contienen información sobre las fuentes
secundarias. Forman parte de la colección de referencia de una biblioteca; facilitan
el control y acceso a toda la gama de repertorios de referencia, como las guías de
obras de referencia, o a un solo tipo, como las bibliografías.

Las fuentes de información pueden ser de forma oral o escrita o bien sea de otra
forma, ejemplo de esto pueden ser las grabaciones audiovisuales y auditivas,
libros, artículos, testimonios, relatos, las grabaciones, las fotografías, las
filmaciones, e.t.c

B. Identificar interesados del producto.

Son grupos o individuos que están interesados en el producto de software que se
está desarrollando y necesitarán estar informados acerca del progreso, conflictos,
cambios y prioridades del proceso de desarrollo del producto.

4.1.2.2 LOS STAKEHOLDERS

Se dividen en dos grupos:

Primarios
Son aquellas personas indispensables para el correcto funcionamiento de la
organización, y tienen una relación económica directa con la empresa. Estos
pueden ser sus socios, clientes y accionistas
Secundarios
Son los entes que no participan directamente de la compañía, pero también son
afectados por sus resultados. En este círculo se encuentran los competidores, el
mercado y las personas en general.

Al identificar interesados del producto podemos encontrar a:

Líder de proyecto / Administrador de proyecto / Gerente de proyecto.

Analista / Ingeniero de requisitos.
Ingeniero de sistemas / Arquitecto.
Programador / Desarrollador / Ingeniero de software.
Probador / Asegurador de la calidad.
Administrador de bases de datos

4.1.2.3 TÉCNICAS E INSTRUMENTOS PARA ELICITAR REQUISITOS

Estas técnicas se pueden llevar a cabo en cualquiera de las diferentes fases de la
ingeniería de requisitos, las técnicas que podemos utilizar son:

4.1.2.3.1 ENTREVISTA
“La entrevista es una forma 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.” - (Braude, 2003)
La entrevista tiene 3 fases que son: primero, la preparación que es donde se va a
planificar la entrevista como por ejemplo definiendo con anterioridad el objetivo y
el contenido de la misma, el lugar la hora, etc. Segundo, realizar la entrevista
utilizando la apertura y desarrollo de la preparación y, tercero, el análisis consiste
en leer las notas, pasarlas en limpio, reorganizar la información, contrastarlas con
otras entrevistas o fuentes de información, evaluar cómo ha ido la entrevista. En
estas entrevistas, el equipo de la ingeniería de requerimientos hace preguntas
sobre el sistema que utilizan y sobre el sistema a desarrollar. Los requerimientos
provienen de las respuestas a estas preguntas.

Las entrevistas se pueden clasificar en:

A) Entrevista estructurada
Las preguntas se deciden previamente de acuerdo con la información que se
quiere obtener,
Ejemplo de estas preguntas son:
1. ¿Cuál es el tiempo estimado para el desarrollo del proyecto?
2. ¿Cuál es el presupuesto estimado para el desarrollo del proyecto?
3. ¿Tiene definida alguna metodología para el desarrollo del proyecto?
4. ¿Tiene establecida la o las tecnologías en las que desea sea desarrollado el
proyecto?
5. ¿Se cuenta con el apoyo de las instancias administrativas y financieras de la
universidad?
6. ¿Cuál es el medio de comunicación que piensa es más asertivo con los
estudiantes de
especialización, maestría y doctorado?
7. ¿Cree necesaria la implementación de otro medio de comunicación destinado
únicamente a los estudiantes de postgrado?
8. ¿Cuál tipo de información cree necesaria y obligatoria para los estudiantes de
postgrado?
9. ¿Cuánto tiempo dedicaría a la administración de información para el nuevo
medio de
comunicación a la semana?
10. ¿Quién o quiénes deberían ser los encargados de agregar la información al
nuevo medio
de comunicación?

b) Entrevista semiestructurada
Esta presenta un grado mayor de flexibilidad que la estructurada, debido a que
parten de preguntas planeadas, que pueden ajustarse a los entrevistados. Su
ventaja es la posibilidad de adaptarse a los sujetos con enormes posibilidades
para motivar al interlocutor, aclarar términos, identificar ambigüedades y reducir
formalismos

c) Entrevista no estructurada
Son conversaciones mantenidas con un fin que es obtener información, pero sin
planificar previamente las preguntas como tal

4.1.2.3.2. ENCUESTA

“Los cuestionarios son herramientas ampliamente utilizadas para recoger datos de

sondeos y pueden ser administradas sin la presencia del investigador”- (Cohen,
2011, p. 377
Son cuestionarios en los que las preguntas son hechos u opiniones además de
utilizar preguntas abiertas que son en donde las respuestas de deja a elección del
participante, y las preguntas cerradas que son en donde la respuesta ya está
predeterminada para que el participante escoja
Por lo general las respuestas más utilizadas son en escala en donde se les da el
nivel de importancia a cada una o también se puede valorar una categoría
indicando si es “bueno” o “malo”, “importante” o “poco importante” o valorar
opiniones, indicando por ejemplo “estoy de acuerdo” o “estoy en desacuerdo”
Ejemplo:
4.1.2.3.3. OBSERVACIÓN
Esta permite la obtención de datos para emprender una investigación de tipo
cualitativo, no desde el punto de vista de lo que los sujetos dicen, sino que es la
evidencia directa de lo que ve y percibe el investigador en un escenario de primera
mano (Denscombe, 2010).
La observación puede ser:
a) pasiva: es donde el observador sólo se limita a escuchar y ver, sin hacer
preguntas, solo tomando notas
b) activa: es en donde el observador puede llegar a obtener una conversación con
el usuario

4.1.2.3.4. SESIONES GRUPALES

Es un proceso por el cual se llevan a cabo reuniones en grupo altamente
estructuradas que convocan, en una misma sala, a los usuarios de un sistema, los
propietarios del sistema y a los analistas durante un amplio periodo de tiempo. Los
objetivos de esta técnica son esencialmente los mismos que los de las entrevistas,
con la salvedad de necesitar más analistas para llevarlos a cabo.

Existen 3 técnicas que se pueden utilizar durante las sesiones grupales, estas
son:

-LLUVIA DE IDEAS: Es una actividad que se hace en equipo y consiste en que

cada uno genere opiniones e ideas o sugerencias que ayuden en un tema
determinado.

- SESIONES JAD: El proceso JAD consiste en un taller donde los trabajadores del
conocimiento y los especialistas en tecnologías de información se reúnen para
determinar lo necesario del negocio para el sistema.

- MÉTODO DELPHI: es cuando se selecciona a un grupo de expertos para

realizarle preguntas puntuales sobre ciertos temas y se estructura en cuatro fases
que son:

-Fase uno. Formulación del problema: se define el campo de investigación.

-Fase dos. Elección de expertos: el experto se elige según su preparación y su
capacidad de proyección.
-Fase tres. Elaboración de cuestionarios: las preguntas deben hacerse de acuerdo
con la temática que se quiere obtener.
-Fase cuatro. Desarrollo y explotación de resultados: el cuestionario se entrega a
los expertos para ser contestado por ellos
4.1.3 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:

• Detectar conflicto en los requisitos que suelen provenir de distintas fuentes

y presentar contradicciones o ambigüedades debido a su naturaleza
informal.
• Profundizar en el conocimiento del dominio del problema puede facilitar el
proceso de construir un producto útil para clientes y usuarios (Durán, 2000).

4.1.4 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.

4.1.5 VALIDACIÓN

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 satisfactor.