3.3.

1 Actividad de apropiación técnicas de levantamiento

de información.
1) ¿Qué es el ciclo de vida de un software y cuáles son las
etapas?

El ciclo de vida es el conjunto de fases por las que pasa el sistema que se está
desarrollando desde que nace la idea inicial hasta que el software es retirado
o remplazado (muere). También se denomina a veces paradigma.
Entre las funciones que debe tener un ciclo de vida se pueden destacar:
• Determinar el orden de las fases del proceso de software.
• Establecer los criterios de transición para pasar de una fase a la siguiente.
• Definir las entradas y salidas de cada fase.
• Describir los estados por los que pasa el producto.
• Describir las actividades a realizar para transformar el producto.
• Definir un esquema que sirve como base para planificar, organizar,
coordinar, desarrollar…
Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas
por tareas que se pueden planificar. Según el modelo de ciclo de vida, la
sucesión de fases puede ampliarse con bucles de realimentación, de manera
que lo que conceptualmente se considera una misma fase se pueda ejecutar
más de una vez a lo largo de un proyecto, recibiendo en cada pasada de
ejecución aportaciones a los resultados intermedios que se van produciendo
(realimentación).
• Fases: una fase es un conjunto de actividades relacionadas con un objetivo
en el desarrollo del proyecto. Se construye agrupando tareas (actividades
elementales) que pueden compartir un tramo determinado del tiempo de
vida de un proyecto. La agrupación temporal de tareas impone requisitos
temporales correspondientes a la asignación de recursos (humanos,
financieros o materiales).
• 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.
Las actividades genéricas del ciclo de vida del desarrollo del software son:
• Especificación: lo que el sistema debería hacer y sus restricciones de
desarrollo.
• Desarrollo: producción del sistema software.
• Validación: comprobar que el sistema es lo que el cliente quiere.
• Evolución: cambiar el software en respuesta a las demandas de cambio.

2) ¿Qué es alcance de proyecto y para qué sirve?

Comprende los procesos necesarios para asegurar que el proyecto incluya
todo el trabajo requerido, y sólo el trabajo requerido. Encuentra la forma
correcta de definir el alcance en un proyecto de software desde el inicio para
ahorrarte problemas futuros.
En definitiva, si no está incluido en el alcance, no existe.
Es esencial tener una buena identificación del trabajo necesario para
entregar el producto del proyecto. Además, se debe realizar la traducción de
los objetivos a entregables, que es aquello físico que el proyecto de
desarrollo de apps, diseño web o desarrollo de software en general, debe
contener.
Un buen alcance, además, debe ser la base para desarrollar el cronograma, el
presupuesto app o presupuesto web y los recursos del proyecto. La
definición de estos es básica y en el alcance deben de aparecer.
Debe, por supuesto, incluir las actividades de gestión que se suceden dentro
del proyecto.
¿Quién participa en definición alcance proyecto software?
¿Quién participa en la elaboración del alcance? Debe participar el equipo del
proyecto y los interesados (stakeholders) que tengan ideas adicionales
expresadas en los puntos anteriores.
Un buen alcance es crítico para el éxito del proyecto. Y se construye sobre la
base de los principales entregables, riesgos, asunciones y restricciones
documentadas en el proceso de iniciación del proyecto.
Del alcance, se derivan tres documentos fundamentales en el desarrollo de
software:

Scope Statement
WBS (Work Breakdown Structure – EDT)
Diccionario del EDT (o WBS)
Una vez determinado el alcance, ya podemos proceder a realizar un
presupuesto app o un presupuesto web con la garantía que estará bien
establecido el alcance del proyecto

Scope Statement
¿Qué es el Scope Statement? Pues es aquel documento que declara el
alcance del proyecto. Y está compuesto por un conjunto de elementos que
resumimos en este listado:

El Project Chárter
Project Owner, Sponsor y los diferentes Stakeholders que están involucrados,
aunque sea mínimamente
Qué intenta resolver el proyecto
Cuáles son las metas y objetivos del proyecto
Los requisitos del proyecto
Los entregables
Aquellas metas u objetivos que quedan fuera del alcance (lo que no entra)
Los milestones
La estimación de los costes
El WBS (Work Breakdown Structure)
Es el desglose de los trabajos y entregables que se deben suceder dentro del
proyecto
Diccionario del EDT (o WBS)
El diccionario del EDT del proyecto de desarrollo de software consiste en la
descripción concreta y extensa de cada componente de la EDT (o WBS).
Digamos que es un documento que detalla a éste.
Cuáles son los diferentes apartados que podemos encontrar en el
diccionario:
Objetivo del paquete de trabajo: Para que se elabora el paquete
Descripción del paquete: Que contiene
Descripción del trabajo a realizar: Cómo lo vamos a elaborar, que actividades
tendrá
Asignación de responsabilidades: Quienes intervienen y su rol
Fechas programadas (inicio, fin, hitos)
Criterios de aceptación: Quién y cómo se dará por válido
Los supuestos: Situaciones que debemos tomar como verdaderas, válidas,
reales o ciertas
Los riesgos: Previsión de que impactará en el proyecto en la triple restricción
(Tiempo, Coste, Alcance)
Los recursos asignados y los costes vinculados: Recursos de personal,
material o costes vinculados al paquete de trabajo
 3) Defina con sus propias palabras que es el levantamiento de
información y los métodos que existen.
Levantamiento de información

Es un proceso mediante el cual el analista recopila datos e información de la

situación actual de un sistema, con el propósito de identificar problemas y
oportunidades de mejora. Se lleva a cabo mediante el uso de instrumentos y
técnicas como:
* Entrevista: consiste en una conversación dirigida con un propósito
especifico y se basa en un formato de preguntas y respuestas para conocer
aspectos como las metas de la organización, metas personales,
procedimientos formales e informales, sus sentimientos, su opinión, entre
otros aspectos que se deben mencionar en una entrevista. Esta puede ser
de tipo estructurada en el cual se lleva preparado un conjunto de preguntas;
es como una especie de interrogatorio o de tipo no estructurada en el cual
se utilizan preguntas abiertas dejando al entrevistado mayor margen de
libertad para expresarse.
* La encuesta o cuestionario: es una técnica de recopilación de cantidades
masivas de datos e información sobre las opiniones, conductas, actitudes y
características de quienes se encuentran involucrados con un sistema, se
basa en un formulario.
* Inspecciones: Consiste en revisar (previo permiso de las instancias
correspondientes) otras fuentes de información como:
* Reportes periodísticos (memorando y cuentas)
* Reporte de auditoria
* Recortes de prensa
* Récord de cantidad
* Sugerencias de los empleados
* Quejas de usuarios y clientes
* Organigramas (reales y aparentes)
* Estructuras de control
* Archivos y manuales
* Simulación: es una técnica de re levantamiento de información dinámica y
consiste en hacer circular un documento en un procedimiento y observar
cada uno de los pasos y procesos a los cuales está sometido, esto sirve para
contrastar con la información relevada por métodos estadísticos
* Técnicas Audio-Visuales: se utilizan en casos muy especiales, se pueden
utilizar películas, videos o cualquier método que permita grabar el proceso
para luego someterlo a un análisis detallado, puede ser utilizado también
para analizar movimiento de almacenes, puestos de despacho de mercancías,
taquillas de atención al público, departamento de procesamiento de datos,
entre otros.

4) Definir que es un sistema de información y modulo en un

sistema de información.
En programación, un módulo es una porción de un programa de ordenador.
De las varias tareas que debe realizar un programa para cumplir con su
función u objetivos, un módulo realizará, comúnmente, una de dichas tareas
(o varias, en algún caso).
En general (no necesariamente relacionado con la programación), un módulo
recibe como entrada la salida que haya proporcionado otro módulo o los
datos de entrada al sistema (programa) si se trata del módulo principal de
éste; y proporcionará una salida que, a su vez, podrá ser utilizada como
entrada de otro módulo o bien contribuirá directamente a la salida final del
sistema (programa), si se retorna al módulo principal.
Particularmente, en el caso de la programación, los módulos suelen estar (no
necesariamente) organizados jerárquicamente en niveles, de forma que hay
un módulo principal que realiza las llamadas oportunas a los módulos de
nivel inferior.
Cuando un módulo es convocado, recibe como entrada los datos
proporcionados por otro del mismo o superior nivel, el que ha hecho la
llamada; luego realiza su tarea. A su vez este módulo convocado puede
llamar a otro u otros módulos de nivel inferior si fuera necesario; cuando
ellos finalizan sus tareas, devuelven la salida pertinente al módulo inmediato
llamador, en secuencia reversa. Finalmente se continúa con la ejecución del
módulo principal.
Características de un módulo
Cada uno de los módulos de un programa idealmente debería cumplir las
siguientes características:
Tamaño relativamente pequeño. - Esto facilita aislar el impacto que pueda
tener la realización de un cambio en el programa, bien para corregir un error,
o bien por rediseño del algoritmo correspondiente.
Independencia modular. - Cuanto más independientes son los módulos entre
sí, más fácil y flexiblemente se trabajará con ellos. Esto implica que para
desarrollar un módulo no es necesario conocer detalles internos de otros
módulos. Como consecuencia de la independencia modular, un módulo
cumplirá:
Características de caja negra; es decir, abstracción
Aislamiento de los detalles mediante encapsulamiento
La independencia modular mejora el rendimiento humano, pudiendo
realizarse programación en equipo y desarrollar módulos paralelamente.
También contribuye a la reutilización de software.

5) Definir y mencionar que es requerimiento funcional y no

funcional, mencione un sencillo ejemplo.
El desarrollo de software es una de esas actividades donde tenemos nombres
y categorías para todo. A veces eso es redundante e inútil, pero a veces hay
conceptos que son muy buenos para conocer y diferenciar. Un ejemplo de
ello es la diferencia entre requisitos funcionales (RF) y no funcionales (RNF). Y
dado que los requisitos del sistema de software se clasifican (entre otras
cosas) de esta manera, se deben considerar las siguientes técnicas para una
correcta identificación.
Requerimientos Funcionales
Los requisitos funcionales son declaraciones de los servicios que prestará el
sistema, en la forma en que reaccionará a determinados insumos. Cuando
hablamos de las entradas, no necesariamente hablamos sólo de las entradas
de los usuarios. Pueden ser interacciones con otros sistemas, respuestas
automáticas, procesos predefinidos. En algunos casos, los requisitos
funcionales de los sistemas también establecen explícitamente lo que el
sistema no debe hacer. Es importante recordar esto: un RF puede ser
también una declaración negativa. Siempre y cuando el resultado de su
comportamiento sea una respuesta funcional al usuario o a otro sistema, es
correcto. Y más aún, no sólo es correcto, sino que es necesario definirlo. La
especificación de los requisitos funcionales de un sistema debe ser completa
y coherente. Completar significa que todos los servicios solicitados por el
usuario y/u otro sistema están definidos. La coherencia significa que los
requisitos no tienen una definición contradictoria.

Requisitos no funcionales
Se trata de requisitos que no se refieren directamente a las funciones
específicas suministradas por el sistema (características de usuario), sino a las
propiedades del sistema: rendimiento, seguridad, disponibilidad. En palabras
más sencillas, no hablan de “lo que” hace el sistema, sino de “cómo” lo hace.
Alternativamente, definen restricciones del sistema tales como la capacidad
de los dispositivos de entrada/salida y la representación de los datos
utilizados en la interfaz del sistema.
Los requisitos no funcionales se originan en la necesidad del usuario, debido
a restricciones presupuestarias, políticas organizacionales, la necesidad de
interoperabilidad con otros sistemas de software o hardware, o factores
externos tales como regulaciones de seguridad, políticas de privacidad, entre
otros.

6) Diseñe un cuadro comparativo que contenga ventajas y

desventajas de los diferentes métodos de recolección de
información.
 7) Cual es el proceso a seguir al momento de realizar un
estudio del levantamiento de información.
Una etapa fundamental en proyectos de ingeniería de software, es la
identificación y documentación de los requerimientos del futuro sistema al
comienzo del proyecto, pues en numerosas ocasiones se ha demostrado que
es cuando pueden prevenirse errores que puedan significar el fracaso del
proyecto.
En la Ingeniería de requisitos, el levantamiento de requerimientos se refiere
a la identificación y documentación de los requerimientos de un sistema, a
partir de los usuarios, clientes o interesados (Stakeholders). A la práctica
también se le conoce como Recopilación de requerimientos.
Técnicas para obtener requerimientos de software

1. - Análisis de documentación
Consiste en obtener la información sobre los requerimientos funcionales y
requerimientos no funcionales de software a partir de documentos que ya
están elaborados.
Es útil cuando los expertos en la materia no están disponibles para ser
entrevistados o ya no forman parte de la organización.
Utiliza la documentación que sea relevante al requerimiento que se está
levantando.
Ejemplos de documentación: Planes de negocio, actas de constitución de
proyecto, reglas de negocio, contratos, definiciones de alcance,
memorándums, correos electrónicos, documentos de entrenamiento, entre
otros.

2.- Observación
Consiste en estudiar el entorno de trabajo de los usuarios, clientes e
interesados de proyecto (Stakeholders).
Es una técnica útil cuando se está documentando la situación actual de
procesos de negocio.
Puede ser de dos tipos, pasiva o activa.
En observación pasiva, el observador no hace preguntas, limitándose solo a
tomar notas y a no interferir en el desempeño normal de las operaciones.
En observación activa, el observador puede conversar con el usuario.

3.- Entrevistas
Se realizan con los usuarios o interesados clave.
Direccionan al usuario hacia aspectos específicos del requerimiento a
levantar.
Son útiles para obtener y documentar información detallada sobre los
requerimientos y sus niveles de granularidad.
Pueden ser entrevistas formales o informales.
Una clave es mantenerse enfocado en los objetivos de la entrevista.
Las preguntas abiertas son útiles para identificar información faltante.
Las preguntas cerradas son útiles para confirmar y validar información.
El éxito de las entrevistas depende del grado de conocimiento del
entrevistador y entrevistado, disposición del entrevistado de suministrar
información, buena documentación de la discusión y en definitiva de una
buena relación entre las partes.

4.- Encuestas o cuestionarios

Es una técnica útil para recopilar eficientemente los requerimientos de
muchas personas.
La clave para el éxito es que tengan un propósito y audiencia claramente
definida, establecer fechas topes para llenar la encuesta, con preguntas
claras y concisas.
Deben enfocarse en los objetivos de negocio que se necesitan identificar.
Pueden apoyarse con entrevistas de seguimiento con usuarios individuales.
Pueden contener tanto preguntas cerradas como preguntas abiertas.

5.- Mesas de trabajo (Workshops)

Es una técnica efectiva para obtener información rápidamente de varias
personas.
Es recomendable tener una agenda predefinida y preseleccionar a los
participantes, siguiendo buenas prácticas para reuniones efectivas.
Se puede utilizar un facilitador neutral y un transcriptor (que no sea el mismo
facilitador).
Se puede utilizar un material común sobre el cual enfocar la atención y
conversar, por ejemplo, una presentación con un desglose del proceso que se
está estudiando o un flujograma.
Se pueden combinar con otras técnicas como pueden ser las entrevistas y
cuestionarios.

6.- Tormenta de ideas

Es una sesión de trabajo estructurada orientada para obtener la mayor
cantidad de ideas posibles.
Es recomendable limitarlas en el tiempo, utilizar ayudas visuales y designar
un facilitador.
Las reglas son importantes, por ejemplo, los criterios para evaluar ideas y
asignarles un puntaje, no permitir las críticas a las ideas y limitar el tiempo de
discusión.
En una primera fase, se deben identificar la mayor cantidad de ideas, para
luego evaluarlas. Todas las ideas deben ser consideradas y deben limitarse
que una idea se le ahogue o critique antes de tener tiempo de desarrollarla.

7.- Historia del usuario

Las historias de usuario, son una aproximación simple al levantamiento de
requerimientos de software, en la cual la conversación pasa a ser más
importante que la formalización de requerimientos escritos.
Es recomendable que sean escritas por el mismo cliente o interesado (con
apoyo del facilitador si es necesario), con énfasis en las funcionalidades que
el sistema deberá realizar.
Al redactar una historia de usuario deben tenerse en cuenta describir el Rol,
la funcionalidad y el resultado esperado de la aplicación en una frase corta.
Las historias de usuario son una de las técnicas más difundidas para levantar
requerimientos de software en metodologías ágiles.

Que le sigue al levantamiento de requerimientos

Toda la información obtenida durante el levantamiento de requerimientos
puede ser incluida en una matriz de trazabilidad de requerimientos y en una
especificación de requerimientos de software.
Al levantamiento de requerimientos le sigue el análisis de los mismos, por
medio de técnicas como la descomposición funcional, modelado de procesos,
casos de uso, inspecciones y prototipos. Estas técnicas serán sujeto de un
próximo artículo.