Unidad 4 Análisis y Modelado del proyecto de software.

4.1. Técnicas de recopilación de Información.

¿Qué es la recolección de datos?

Se refiere al uso de una gran variedad de técnicas que son utilizadas

para recopilar datos pertinentes, con la finalidad de buscar información que será
útil para la evaluación y para abordar las preguntas de evaluación que se han
identificado. Cabe señalar que las técnicas de recolección de datos dependerán de
la pregunta de evaluación que guíe la investigación, para fines didácticos aquí se
presentan divididas en cuantitativas y cualitativas, pero al llevar a cabo la
evaluación casi siempre estas técnicas se utilizan indistintamente.

¿Qué técnicas existen para recolectar datos?

Se dispone de una gran variedad de técnicas, tanto cuantitativas como cualitativas.

Cada técnica tiene ventajas y desventajas.

La cuestión más importante relacionada a la recopilación de datos es seleccionar la

técnica adecuada que nos proporcione la información o evidencia que sirva para
responder las preguntas que tiene el evaluador.

¿Cuántas técnicas debo de usar? Generalmente, se utilizan dos o tres

para complementar el trabajo de cada una y ayudar a asegurar una evaluación
completa.

¿De dónde se recolecta la información?

La fuente de información que se seleccione dependerá sobre lo que está

disponible y lo que conteste a las preguntas de evaluación con mayor
eficacia.

Fuentes Primarias: Se obtiene información por contacto directo con el sujeto

de estudio; por medio de observación, cuestionarios, entrevistas.

Fuentes Secundarias: El dato no es tomado directamente, sino que se

aprovechan aquellos previamente recogidos por otras personas.

Información obtenida desde documentos, archivos documentales, datos,

estadísticos. Lo ideal sería reunir más de una fuente de datos

Recolectar datos implica elaborar un plan detallado de procedimientos que

nos conduzcan a reunir los datos con un propósito específico. El objetivo es
obtener evidencia confiable, auténtica y creíble que se utilice en la
evaluación.

Algunas preguntas que pueden servir de guía para llevar a cabo esta tarea
son:

1. El propósito de la evaluación

 ¿Cuáles es el tipo de datos que nos permite responder las preguntas

de evaluación?
 ¿Qué técnica es más apropiada para el propósito y las preguntas de
evaluación que se quieren contestar

2. Fuentes de información

 ¿En donde se localizan estas fuentes?

 ¿Qué información ya está disponible?
 ¿Qué técnica es apropiada para la edad, la alfabetización, nivel socio-
económico de los participantes?

3. Los recursos disponibles (tiempo, dinero, voluntarios, experiencia)

 ¿Qué técnica es más factible para realizar con los recursos que tengo?
 ¿Cuál es mi experiencia como evaluador con las técnicas?
 ¿Cuánto tiempo se tiene?
 ¿Cuánto dinero se puede gastar en la recopilación de datos?
 ¿Se necesita de apoyo profesional para utilizar una técnica?
4. El grado de intrusividad

 ¿La técnica trastornará al objeto de evaluación o será vista como

intrusiva?

5. Tipo de información

 ¿Se desea información representativa o se quiere un análisis profundo

de las historias y experiencias de las personas o programas
particulares?

6. Las ventajas y desventajas de cada técnica

 ¿Cuáles son los puntos fortalezas y debilidades de cada una de las

técnicas?

4.2. Estudio de viabilidad.

DEFINICION DE VIABILIDAD
Según el diccionario de la Real Academia Española Viabilidad: “cualidad de
viable”, Viable: “Que, por sus circunstancias, tiene probabilidades de
poderse llevar a cabo”.

ESTUDIO DE VIABILIDAD
Es el análisis que intenta predecir el eventual éxito o fracaso de un
proyecto de tal manera que cumpla con su objetivo. Para lograr esto parte
de datos empíricos a los que accede a través de diversos tipos de
investigaciones.

Está relacionada con principios de calidad, eficiencia y pertinencia de un

proyecto en términos de los elementos conceptuales que lo componen, la
información utilizada, la coherencia de los planteamientos y el mayor
acercamiento a la realidad a la que se refiere el proyecto.
Los análisis de viabilidad se desarrollan en el ámbito gubernamental o
corporativo. Se trata de un recurso útil antes del inicio de una obra o del
 lanzamiento de un nuevo producto. De este modo, se minimiza el margen de
error.

DETERMINACIÓN DE LA VIABILIDAD EN UN PROYECTO

Las mejoras pueden ser de muchos tipos:
· Aceleración de un proceso.
· Eliminar pasos innecesarios o duplicados.
· Reducción en la captura de información mediante la modificación de
formularios y pantallas de despliegue, etc.

CUADRICULA DE IMPACTO DE VIABILIDAD (CIV)

· Se utiliza para evaluar el impacto de las mejoras al sistema existente.
· Puede aumentar la ganancia de los impactos sobre los objetivos
corporativos

VIABILIDAD DE UN PROYECTO
· El estudio de la viabilidad evalúa tres criterios: operacional, técnico y
económico, del proyecto propuesto.
· Hay tres tipos de viabilidad:

o Viabilidad técnica.
Evalúa si los recursos técnicos actuales son suficientes para el nuevo
sistema, si ellos no lo están pueden ser actualizados para proveer el nivel
necesario de tecnología necesario para el nuevo sistema.

o Viabilidad económica.
La viabilidad económica determina si el tiempo y el dinero están disponibles
para desarrollar el sistema. Incluye la compra de: equipo nuevo, hardware y
software.
o Viabilidad operacional
Determina si los recursos humanos están disponibles: para operar el
sistema una vez que este sea instalado.
Los usuarios que no desean un nuevo sistema, pueden impedir que llegue a
ser operacionalmente viable.

4.2 Requerimientos funcionales y no funcionales.

Análisis y diseño: La mayoría de proyectos de software son complejos, y la
estrategia primaria para superar la complejidad, es la descomposición
(divide y vencerás).La estrategia es dividir el problema en unidades más
pequeñas que sean manejables. Un enfoque tradicional para realizar esto fue
el análisis y diseño estructurados, donde se trata de descomponer el
problema en funciones o procesos. Este método origina una división
jerárquica de procesos constituidos por sub-procesos.

Otra forma de realizar la descomposición, es usando un esquema de análisis

y diseño orientado a objetos. En este esquema, se busca descomponer el
problema en objetos, y no en funciones.

Algunas de las tareas a realizarse en la etapa de análisis son las siguientes:

1. Definir los requerimientos.

2. Definir los casos esenciales de uso.

3. Crear y perfeccionar los diagramas de casos de uso.

4. Crear y perfeccionar el modelo conceptual.

5. Crear y perfeccionar el glosario.

6. Definir los diagramas de secuencia de los sistemas.

7. Definir los contratos de operaciones.

Algunas de las tareas a realizarse en la etapa de diseño son las siguientes:

1. Definir los casos reales de uso.

2. Definir los reportes, la interfaz de usuario y la secuencia de las pantallas.

3. Perfeccionar la arquitectura del sistema.

4. Definir los diagramas de interacción.

5. Definir los diagramas de diseño de clases.

6. Definir el esquema de la base de datos.

Los requerimientos son una descripción de las necesidades o deseos de un

producto. La meta principal en esta etapa es identificar y documentar lo que
en realidad se necesita, en una forma en que pueda fácilmente ser
transmitido al cliente y al equipo de desarrollo. Se recomienda aquí definir
al menos los siguientes puntos:

• Panorama general

• Metas

• Funciones del sistema

• Atributos del sistema.

a) Panorama general: Este proyecto tiene por objeto crear un sistema de

terminal para el punto de venta que se utilizará en las ventas al menudeo.

b) Metas: En términos generales, la meta es una mayor automatización del

pago en las cajas registradoras, y dar soporte a servicios más rápidos, más
baratos y mejores.

c) Funciones del sistema: Las funciones del sistema son lo que éste deberá
de hacer. Hay que identificar estas funciones y listarlas en grupos lógicos.
Para verificar que X es en verdad una función del sistema, la siguiente frase
deberá tener sentido: “El sistema deberá hacer X”. Por ejemplo: “el sistema
deberá autorizar pagos a crédito”. Las funciones pueden clasificarse en tres
categorías: evidentes, ocultas y superfluas. Las evidentes deben realizarse,
y el usuario debe saber que se han realizado. Las ocultas también deben
realizarse, y puede que no sean visibles para el usuario. Muchas de estas
funciones se omiten (erróneamente) durante el proceso de obtención de
requerimientos. Las superfluas son opcionales, y su inclusión no repercute
significativamente en el costo ni en otras funciones.

d) Atributos del sistema Los atributos del sistema son cualidades no

funcionales que a menudo se confunden con las funciones: facilidad de uso,
tolerancia a fallas, tiempo de respuesta, metáfora de interfaz, plataformas.
Por ejemplo: tiempo de respuesta = (psicológicamente correcto) metáfora
de interfaz = (gráfico, colorido, basado en formularios)

Los requerimientos caen en dos categorías, funcionales y no funcionales.

Requerimiento funcional: Un requerimiento funcional especifica una acción

que deberá ser capaz de desempeñar el producto deseado. Los
requerimientos regularmente se expresan en términos de entradas y
salidas: dada una entrada específica, el requerimiento funcional estipula cuál
debe ser la salida.

Requerimiento No Funcional: Un requerimiento no funcional especifica

propiedades del producto deseado en sí, como restricciones de la
plataforma (“el producto de software debe ejecutarse en Linux”), tiempo de
respuesta (“en promedio, las consultas del Tipo 3B deberán responderse
dentro de 2.5 segundos”), o confiabilidad (“el producto de software debe
ejecutarse en 99.95% del tiempo”).

4.4. Arquitectura del sistema basada en UML: Diagramas de Comportamiento

y de funcionalidad.
El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh
se unió a la compañía Rational fundada por Booch (dos reputados
investigadores en el área de metodología del software). El objetivo de amb
os era unificar dos métodos que habían desarrollado: el método Booch y el
OMT (Object Modelling Tool). El primer borrador apareció en octubre de
1995. En esa misma época otro reputado investigador, Jacobson, se unió a
Rational y se incluyeron ideas suyas. Estas tres personas son conocidas
como los "tres amigos". Además, este lenguaje se abrió a la colaboración de
otras empresas para que aportaran sus ideas. Todas estas colaboraciones
condujeron a la definición de la primera versión de UML.

Qué es UML?

UML es el primer método en publicar un meta-modelo en su propia

notación, incluyendo la notación para la mayoría de la información de
requisitos, análisis y diseño. Se trata pues de un meta-modelo auto-
referencial (cualquier lenguaje de modelado de propósito general debería
ser capaz de modelarse a sí mismo).

UML es un lenguaje estándar que sirve para escribir los planos del
software, puede utilizarse para visualizar, especificar, construir y
documentar todos los artefactos que componen un sistema con gran
cantidad de software. UML puede usarse para modelar desde sistemas de
información hasta aplicaciones distribuidas basadas en Web, pasando por
sistemas empotrados de tiempo real.

UML es solamente un lenguaje por lo que es sólo una parte de un método de

desarrollo software, es independiente del proceso aunque para que sea
optimo debe usarse en un proceso dirigido por casos de uso, centrado en la
arquitectura, iterativo e incremental.

UML es un lenguaje por que proporciona un vocabulario y las reglas para

utilizarlo, además es un lenguaje de modelado lo que significa que el
vocabulario y las reglas se utilizan para la representación conceptual
y física del sistema.

UML es un lenguaje que nos ayuda a interpretar grandes sistemas mediante

gráficos o mediante texto obteniendo modelos explícitos que ayudan a la
comunicación durante el desarrollo ya que al ser estándar, los modelos
podrán ser interpretados por personas que no participaron en su diseño (e
incluso por herramientas) sin ninguna ambigüedad. En este contexto, UML
sirve para especificar, modelos concretos, no ambiguos y completos.

Debido a su estandarización y su definición completa no ambigua, y aunque

no sea un lenguaje de programación, UML se puede conectar de manera
directa a lenguajes de programación como Java, C++ o Visual Basic, esta
correspondencia permite lo que se denomina como ingeniería directa
(obtener el código fuente partiendo de los modelos) pero además es posible
reconstruir un modelo en UML partiendo de la implementación, o sea, la
ingeniería inversa.

UML proporciona la capacidad de modelar actividades de planificación de

proyectos y de sus versiones, expresar requisitos y las pruebas sobre el
sistema, representar todos sus detalles así como la propia arquitectura.
Mediante estas capacidades se obtiene una documentación que es válida
durante todo el ciclo de vida de un proyecto.

El lenguaje UML se compone de tres elementos básicos, los bloques de

construcción, las reglas y algunos mecanismos comunes. Estos elementos
interaccionan entre sí para dar a UML el carácter de completitud y no-
ambigüedad que antes comentábamos.
Los bloques de construcción se dividen en tres partes:

*Elementos: que son las abstracciones de primer nivel.

*Relaciones: que unen a los elementos entre sí.

*Diagramas: que son agrupaciones de elementos.

Diagramas
Los diagramas se utilizan para representar diferentes perspectivas de un
sistema de forma que un diagrama es una proyección del mismo. UML
proporciona un amplio conjunto de diagramas que normalmente se usan en
pequeños subconjuntos para poder representar las cinco vistas principales
de la arquitectura de un sistema.
Diagramas de Clases
Muestran un conjunto de clases, interfaces y colaboraciones, así como sus
relaciones. Estos diagramas son los más comunes en el modelado de
sistemas orientados a objetos y cubren la vista de diseño estática o la vista
de procesos estática (sí incluyen clases activas).
Diagrama de Clases

Diagramas de Objetos
Muestran un conjunto de objetos y sus relaciones, son
como fotos instantáneas de los diagramas de clases y cubren la vista de
diseño estática o la vista de procesos estática desde la perspectiva de casos
reales o prototípicos.
Objetos Análogo al diagrama de
clases, muestra un conjunto
de objetos y sus relaciones,
pero a modo de vista
instantánea de instancias de
una clase en el tiempo.

Diagramas de Casos de Usos

Muestran un conjunto de casos de uso y actores (tipo especial de clases) y
sus relaciones. Cubren la vista estática de los casos de uso y son
especialmente importantes para el modelado y organización del
comportamiento.

Casos de Muestra un conjunto de casos de

Uso uso, los actores implicados y
sus relaciones. Son diagramas
fundamentales en el modelado y
organización del sistema.

Diagramas de Secuencia y de Colaboración

Tanto los diagramas de secuencia como los diagramas de colaboración son
un tipo de diagramas de interacción. Constan de un conjunto de objetos y
sus relaciones, incluyendo los mensajes que se pueden enviar unos objetos
a otros. Cubren la vista dinámica del sistema. Los diagramas de secuencia
enfatizan el ordenamiento temporal de los mensajes mientras que los
diagramas de colaboración muestran la organización estructural de los
objetos que envían y reciben mensajes. Los diagramas de secuencia se
pueden convertir en diagramas de colaboración sin perdida de información,
lo mismo ocurren en sentido opuesto.

Secuencia Son diagramas de interacción,

muestran un conjunto de objetos
y sus relaciones, así como los
mensajes que se intercambian
entre ellos. Cubren la vista
dinámica del sistema. El
 diagrama de secuencia resalta la
Colaboración
ordenación temporal de los
mensajes, mientras que el de
colaboración resalta la
organización estructural de los
objetos, ambos siendo
equivalentes o isomorfos. En el
diagrama de colaboración de la
figura de la izquierda, se puede
ver que los elementos gráficos
no son cajas rectangulares,
como cabría esperar, y en su
lugar encontramos sus
versiones adornadas. Estas
versiones tienen como finalidad
evidenciar un rol específico del
objeto siendo modelado. En la
figura encontramos de izquierda
a derecha y de arriba abajo un
Actor, una Interfaz, un Control
(modela un comportamiento) y
una Instancia (modela un objeto
de dato).

Diagramas de Estados
Muestran una maquina de estados compuesta por estados, transiciones,
eventos y actividades. Estos diagramas cubren la vista dinámica de un
sistema y son muy importantes a la hora de modelar el comportamiento de
una interfaz, clase o colaboración.

Estados Muestra una máquina de

estados, con sus estados,
transiciones, eventos y
actividades. Cubren la vista
dinámica de un sistema. Modelan
comportamientos reactivos en
base a eventos.

Diagramas de Actividades
Son un tipo especial de diagramas de estados que se centra en mostrar el
flujo de actividades dentro de un sistema. Los diagramas de actividades
cubren la parte dinámica de un sistema y se utilizan para modelar el
funcionamiento de un sistema resaltando el flujo de control entre objetos.

Actividades Tipo especial de diagrama de

estados que muestra el flujo
de actividades dentro de un
sistema.

Diagramas de Componentes
Muestra la organización y las dependencias entre un conjunto de
componentes. Cubren la vista de la implementación estática y se relacionan
con los diagramas de clases ya que en un componente suele tener una o
más clases, interfaces o colaboraciones

Diagramas de Despliegue
Representan la configuración de los nodos de procesamiento en tiempo de
ejecución y los componentes que residen en ellos. Muestran la vista de
despliegue estática de una arquitectura y se relacionan con los componentes
ya que, por lo común, los nodos contienen uno o más componentes.