2014

Universidad Tecnolgica de Coahuila. Rodrigo Reyes Cerecero

PORTAFOLIO DE EVIDENCIAS INGENIERA DEL SOFTWARE La ingeniera de software es una disciplina formada por un conjunto de mtodos, herramientas y tcnicas que se utilizan en el desarrollo de los programas informticos (software). Esta disciplina trasciende la actividad de programacin, que es el pilar fundamental a la hora de crear una aplicacin... La ingeniera de software es una disciplina formada por un conjunto de mtodos, herramientas y tcnicas que se utilizan en el desarrollo de los programas informticos (software). Esta disciplina trasciende la actividad de programacin, que es el pilar fundamental a la hora de crear una aplicacin...

INGENIERA DE SOFTWARE. .................................................................................. 0

CICLO DE VIDA DEL SOFTWARE. .......................................................................... 2

Modelo Cascada ................................................................................................................ 3

Ingeniera y Anlisis del Sistema .......................................................................................................... 4

Anlisis de los requisitos del software ................................................................................................. 4

Diseo ....................................................................................................................................................... 4

Codificacin ............................................................................................................................................. 4

Prueba ...................................................................................................................................................... 5

Mantenimiento ......................................................................................................................................... 5

Modelo Espiral .................................................................................................................. 6

Planificacin. ............................................................................................................................................ 7

Anlisis de riesgo. ................................................................................................................................... 8

Ingeniera. ................................................................................................................................................ 8

Evaluacin del cliente. ............................................................................................................................ 8

Modelo Incremental .......................................................................................................... 9

Proceso de Desarrollo Unificado .................................................................................. 11

El Proceso Unificado es dirigido por casos de uso .......................................................................... 12

El Proceso Unificado est centrado en la arquitectura ................................................................... 13

El Proceso Unificado es Iterativo e Incremental............................................................................... 14

DIAGRAMA UML ...................................................................................................... 16 Vistas: ..................................................................................................................................................... 17

Diagramas: ............................................................................................................................................. 18

Smbolos o Elementos de modelo: ..................................................................................................... 18

Reglas o Mecanismos generales: ...................................................................................................... 18

FASES DEL DESARROLLO DE UN SISTEMA ............................................................. 18

Anlisis de Requerimientos ................................................................................................................. 19

Anlisis ................................................................................................................................................... 19

Diseo ..................................................................................................................................................... 19

Programacin ........................................................................................................................................ 20

Pruebas .................................................................................................................................................. 20

CASOS DE USO (UC) ...................................................................................................... 20

Necesidades de informacin ............................................................................................................... 20

Actor ........................................................................................................................................................ 21

Categoras de Actores ..................................................................................................................... 21

Actores y Escenarios ............................................................................................................................ 22

Escenarios: Instancias de un Caso de Uso .................................................................................. 22

Relaciones entre Actores y Casos de Uso ........................................................................................ 23

Implementacin de relaciones ........................................................................................................ 24

Construccin de Casos de Uso .......................................................................................................... 24

Reglas de Implementacin de un Caso de Uso ........................................................................... 25

Transicin hacia los Objetos ............................................................................................................... 26

Descomposicin hacia objetos ....................................................................................................... 26

INGENIERA DE REQUERIMIENTOS ..................................................................... 27

Tcnicas de obtencin de requerimientos .................................................................. 28

Entrevistas ............................................................................................................................................. 29

Reuniones .............................................................................................................................................. 31

Cuestionarios Es un conjunto de preguntas que deben ser contestadas por escrito por una

determinada poblacin, generalmente esta poblacin es amplia. Segn el contenido de los

cuestionarios podemos clasificarlos en los siguientes tipos: ......................................................... 31

Abiertos: ............................................................................................................................................. 31

Cerrados: ........................................................................................................................................... 31

Mixtos: ................................................................................................................................................ 32

Desarrollo conjunto de aplicaciones (JAD) ................................................................................. 34

Joint Requirements Planning (JRP) ................................................................................................... 35

Moderador ................................................................................................................................. 35

Promotor .................................................................................................................................... 35

Director de proyecto ................................................................................................................ 35

Consultores ............................................................................................................................... 35

Especialista en modelizacin ................................................................................................. 35

Usuarios de alto nivel .............................................................................................................. 35

Brainstorming ......................................................................................................................................... 36

Phillips 66 ............................................................................................................................................... 37

PASOS PARA LA OBTENCIN DE REQUERIMIENTOS. ............................................ 37

ESPECIFICACIN DE REQUERIMIENTOS ................................................................... 39

Una buena ERS debe ser: ................................................................................................................... 39

Tipos de requisitos ................................................................................................................................ 40

3. Requisitos Funcionales: .......................................................................................................... 40

4. Requisitos no funcionales: ...................................................................................................... 41

INGENIERA DE SOFTWARE.

La ingeniera de software es una disciplina formada por un conjunto de mtodos,

herramientas y tcnicas que se utilizan en el desarrollo de los programas

informticos (software). Esta disciplina trasciende la actividad de programacin,

que es el pilar fundamental a la hora de crear una aplicacin. El ingeniero de

software se encarga de toda la gestin del proyecto para que ste se pueda

desarrollar en un plazo determinado y con el presupuesto previsto.

La ingeniera de software, por lo tanto, incluye el anlisis previo de la situacin, el

diseo del proyecto, el desarrollo del software, las pruebas necesarias para

confirmar su correcto funcionamiento y la implementacin del sistema. Cabe

destacar que el proceso de desarrollo de software implica lo que se conoce como

ciclo de vida del software, que est formado por cuatro etapas: concepcin,

elaboracin, construccin y transicin.

La concepcin fija el alcance del proyecto y desarrolla el modelo de negocio; la

elaboracin define el plan del proyecto, detalla las caractersticas y fundamenta la

arquitectura; la construccin es el desarrollo del producto; y la transicin es la

transferencia del producto terminado a los usuarios.

Una vez que se completa este ciclo, entra en juego el mantenimiento del software.

Se trata de una fase de esta ingeniera donde se solucionan los errores

descubiertos (muchas veces advertidos por los propios usuarios) y se incorporan

actualizaciones para hacer frente a los nuevos requisitos. El proceso de

mantenimiento incorpora adems nuevos desarrollos, para permitir que el software

pueda cumplir con una mayor cantidad de tareas.

Un campo directamente relacionado con la ingeniera de software es la

arquitectura de sistemas, que consiste en determinar y esquematizar la estructura

general del proyecto, diagramando su esqueleto con un grado relativamente alto

de especificidad y sealando los distintos componentes que sern necesarios para

llevar a cabo el desarrollo, tales como aplicaciones complementarias y bases de

datos. Se trata de un punto fundamental del proceso, y es muchas veces la clave

del xito de un producto informtico.

Los avances tecnolgicos y su repercusin en la vida social han afectado

inevitablemente el proceso de desarrollo de software por diversos motivos, como

ser el acceso indiscriminado de los usuarios a cierta informacin que hasta hace

un par de dcadas desconoca por completo y que no pueden comprender, dado

que no poseen el grado de conocimiento tcnico necesario. Un consumidor bien

informado es un consumidor al que no se puede timar, ya que sabe lo que

necesita y tiene la capacidad de analizar las diferentes ofertas del mercado,

comparando las propuestas y prestaciones de los productos; sin embargo, un

consumidor mal informado es como un nio caprichoso que llora, grita y patalea

sin parar.

La primera de todas las etapas del trabajo que realizan los ingenieros de software

consiste en estudiar minuciosamente las caractersticas que se creen necesarias

para el programa a desarrollar, y es ste el punto en el cual deben encontrar un

equilibrio (cada vez ms difcil de alcanzar) entre las demandas excesivas de los

malos consumidores y las posibilidades de la compaa. El tiempo es dinero, y las

empresas del mundo informtico lo saben muy bien.

Cada funcin de un programa, cada rasgo que lo vuelva ms cmodo, ms

inteligente, ms accesible, se traduce en una cantidad determinada de tiempo, que

a su vez acarrea los sueldos de todas las personas involucradas en su desarrollo.

Pero adems del costo de produccin necesario para realizar cada una de las

piezas de un programa, la ingeniera de software debe decidir cules de ellas

tienen sentido, son coherentes con el resto y son necesarias para comunicar

claramente la esencia y los objetivos de la aplicacin

CICLO DE VIDA DEL SOFTWARE.

Un modelo de ciclo de vida define el estado de las fases a travs de las cuales se

mueve un proyecto de desarrollo de software. Un modelo de ciclo de vida de

software es una vista de las actividades que ocurren durante el desarrollo de

software, intenta determinar el orden de las etapas involucradas y los criterios de

transicin asociadas entre estas etapas.

Un modelo de ciclo de vida del software:

Describe las fases principales de desarrollo de software.

Define las fases primarias esperadas de ser ejecutadas durante esas fases.

Ayuda a administrar el progreso del desarrollo, y

Provee un espacio de trabajo para la definicin de un detallado proceso de

desarrollo de software.

As, los modelos por una parte suministran una gua para los ingenieros de

software con el fin de ordenar las diversas actividades tcnicas en el proyecto, por

otra parte suministran un marco para la administracin del desarrollo y el

mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de

control intermedios, monitorear el avance, etc.

Modelo Cascada

Este es el ms bsico de todos los modelos, y sirve como bloque de construccin

para los dems modelos de ciclo de vida. La visin del modelo cascada del

desarrollo de software es muy simple; dice que el desarrollo de software puede ser

a travs de una secuencia simple de fases. Cada fase tiene un conjunto de metas

bien definidas, y las actividades dentro de una fase contribuyen a la satisfaccin

de metas de esa fase o quizs a una subsecuencia de metas de la fase. Las

flechas muestran el flujo de informacin entre las fases. La flecha de avance

muestra el flujo normal. Las flechas hacia atrs representan la retroalimentacin.

El modelo de ciclo de vida cascada, captura algunos principios bsicos:

Planear un proyecto antes de embarcarse en l.

Definir el comportamiento externo deseado del sistema antes de disear su

arquitectura interna.

Documentar los resultados de cada actividad.

Disear un sistema antes de codificarlo.

Testear un sistema despus de construirlo.

Una de las contribuciones ms importantes del modelo cascada es para los

administradores, posibilitndoles avanzar en el desarrollo, aunque en una

escala muy bruta.

Ingeniera y Anlisis

del Sistema

Anlisis de los

Requisitos

Diseo

Codificacin

Prueba

Mantenimiento

Ingeniera y Anlisis del Sistema

Debido a que el software es siempre parte de un sistema mayor, el trabajo

comienza estableciendo los requisitos de todos los elementos del sistema y luego

asignando algn subconjunto de estos requisitos al software.

Anlisis de los requisitos del software

Anlisis: Se analizan las necesidades de los usuarios finales del software para

determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada

SRD (Documento de Especificacin de Requisitos), que contiene la especificacin

completa de lo que debe hacer el sistema sin entrar en detalles internos (debe

comprender el mbito de la informacin del software, as como la funcin, el

rendimiento y las interfaces requeridas).

Diseo

El diseo del software se enfoca en cuatro atributos distintos del programa: la

estructura de los datos, la arquitectura del software, el detalle procedimental y la

caracterizacin de la interfaz. El proceso de diseo traduce los requisitos en una

representacin del software con la calidad requerida antes de que comience la

codificacin. Como resultado surge el SDD (Documento de Diseo del Software),

que contiene la descripcin de la estructura global del sistema y la especificacin

de lo que debe hacer cada una de sus partes, as como la manera en que se

combinan unas con otras.

Codificacin

Es la fase de programacin. Aqu se desarrolla el cdigo fuente, el diseo debe

traducirse en una forma legible para la mquina, haciendo uso de prototipos as

como pruebas y ensayos para corregir errores. El paso de codificacin realiza esta

tarea. Si el diseo se realiza de una manera detallada la codificacin puede

realizarse mecnicamente.

Prueba

Una vez que se ha generado el cdigo comienza la prueba del programa. La

prueba se centra en la lgica interna del software, y en las funciones externas,

realizando pruebas que aseguren que la entrada definida produce los resultados

que realmente se requieren. Se comprueba que funciona correctamente antes de

ser puesto en explotacin.

Mantenimiento

El software sufrir cambios despus de que se entrega al cliente. Los cambios

ocurrirn cuando se hayan encontrado errores, esto en lugar de que el software

deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos

perifricos), o debido a que el cliente requiera ampliaciones funcionales o del

rendimiento.

Modelo Espiral

El modelo espiral de los procesos software es un modelo del ciclo de meta-vida.

En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno

completa un esfuerzo de desarrollo, otro comienza. Adems, en cada desarrollo

ejecutado, puedes seguir estos cuatros pasos:

Determinar qu quieres lograr.

Determinar las rutas alternativas que puedes tomar para lograr estas metas.

Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.

Seguir la alternativa seleccionada en el paso 2.

Establecer qu tienes terminado.

La dimensin radial en la figura refleja costos acumulativos incurridos en el

proyecto. Observemos un escenario particular. Digamos que en este proyecto,

nosotros viajaremos a resolver un conjunto particular de problemas del cliente.

Durante el primer viaje alrededor de la espiral, analizamos la situacin y

determinamos que los mayores riesgos son la interfaz del usuario.

Despus de un cuidadoso anlisis de las formas alternativas de direccionar esto

(por ejemplo, construir un sistema y esperar lo mejor, escribir una especificacin

de requerimientos y esperar que el cliente lo entienda, y construir un prototipo),

determinamos que el mejor curso de accin es construir un prototipo.

Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con

retroalimentacin til. Ahora, comenzamos el segundo viaje alrededor de la

espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos

nuevos requerimientos comiencen a aparecer slo despus de que el sistema sea

desplegado. Analicemos las rutas alternativas, y decidimos que la mejor

aproximacin es construir un incremento del sistema que satisfaga slo los

requerimientos mejor entendidos.

Despus del despliegue, el cliente nos provee de retroalimentacin que dir si

estamos correctos con esos requerimientos, pero 50 nuevos requerimientos ahora

se originarn en las cabezas de los clientes. Y el tercer viaje alrededor de la

espiral comienza.

El modelo representado mediante la espiral define cuatro actividades principales,

tambin llamadas regiones de tareas o sectores:

Planificacin. Durante la primera vuelta alrededor de la espiral se definen los

objetivos, las alternativas y las restricciones, se analizan e identifican los riesgos.

Si el anlisis de riesgo indica que hay una incertidumbre en los requisitos, se

puede usar la creacin de prototipos en el cuadrante de ingeniera para dar

asistencia tanto al encargado de desarrollo como al cliente.

Prototipo 1

Prototipo 2

Prototipo 3

Prototipo

Operativo Anlisis de

riesgo

Anlisis de

riesgo

Anlisis de

riesgo

AR

Evaluacin del

Cliente

Planificacin

Ingeniera

Anlisis de

Riesgos

Plan de

requisitos,

Plan de

ciclo de vida

Plan de

desarrollo

Plan de

prueba e

Integracin

Concepto de

operacin

Simulaciones, Modelos, Estndares

Validacin

de

requisitos

Requisitos

de Software

Verificacin

y validacin

de diseo

Diseo del

producto de

software

Implementacin

Prueba de aceptacin

Prueba de Integracin

Prueba de Unidad

Codificacin

Revisin

Diseo detallado

Anlisis de riesgo. El proyecto se revisa y se toma la decisin de si se debe

continuar con un ciclo posterior de la espiral. Si se decide continuar, se desarrollan

los planes para la siguiente fase del proyecto.

Ingeniera. En este sector se desarrolla y se valida. Despus de la evaluacin de

riesgos, se elige un modelo para el desarrollo del sistema.

Evaluacin del cliente. El cliente evala el trabajo de ingeniera (cuadrante de

evaluacin de cliente) y sugiere modificaciones. Sobre la base de los comentarios

del cliente se produce la siguiente fase de planificacin y de anlisis de riesgo. En

cada bucle alrededor de la espiral, la culminacin del anlisis de riesgo resulta en

una decisin de "seguir o no seguir.

Con cada iteracin alrededor de la espiral (comenzando en el centro y siguiendo

hacia el exterior), se construyen sucesivas versiones del software, cada vez ms

completas y, al final, el propio sistema operacional.

El paradigma del modelo en espiral para la Ingeniera de Software es actualmente

el enfoque ms realista para el desarrollo de software y de sistemas a gran escala.

Utiliza un enfoque evolutivo, permitiendo al desarrollador y al cliente entender y

reaccionar a los riesgos en cada nivel. Utiliza la creacin de prototipos como un

mecanismo de reduccin de riesgo, pero, lo que es ms importante permite a

quien lo desarrolla aplicar el enfoque de creacin de prototipos en cualquier etapa

de la evolucin de prototipos.

El modelo espiral no es una alternativa del modelo cascada, ellos son

completamente compatibles.

Modelo Incremental

Los riesgos asociados con el desarrollo de sistemas largos y complejos son

enormes. Una forma de reducir los riesgos es construir slo una parte del sistema,

reservando otros aspectos para niveles posteriores. El desarrollo incremental es el

proceso de construccin siempre incrementando subconjuntos de requerimientos

del sistema. Tpicamente, un documento de requerimientos es escrito al capturar

todos los requerimientos para el sistema completo.

Note que el desarrollo incremental es 100% compatible con el modelo cascada. El

desarrollo incremental no demanda una forma especfica de observar el desarrollo

de algn otro incremento. As, el modelo cascada puede ser usado para

administrar cada esfuerzo de desarrollo, como se muestra en la figura.

El modelo de desarrollo incremental provee algunos beneficios significativos para

los proyectos:

Construir un sistema pequeo es siempre menos riesgoso que construir un

sistema grande.

Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si

los requerimientos planeados para los niveles subsiguientes son correctos.

Si un error importante es realizado, slo la ltima iteracin necesita ser

descartada.

Reduciendo el tiempo de desarrollo de un sistema (en este caso en

incremento del sistema) decrecen las probabilidades que esos

requerimientos de usuarios puedan cambiar durante el desarrollo.

Si un error importante es realizado, el incremento previo puede ser usado.

Los errores de desarrollo realizados en un incremento, pueden ser

arreglados antes del comienzo del prximo incremento.

Cuando se utiliza un modelo incremental, el primer incremento a menudo es un

producto esencial. Es decir, se afrontan requisitos bsicos, pero muchas funciones

suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza

el producto central (o sufre la revisin detalla). Como un resultado de utilizacin

y/o de evaluacin, se desarrolla un plan para el incremento siguiente. El plan

afronta la modificacin del producto central a fin de cumplir mejor las necesidades

del cliente y la entrega de funciones, y caractersticas adicionales. Este proceso se

repite siguiendo la entrega de cada incremento. Hasta que se elabore el producto

completo.

El modelo de proceso incremental, como la construccin de prototipos y otros

enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la

construccin de prototipos, el modelo incremental se centra en la entrega de un

producto operacional con cada incremento. Los primero incrementos son

versiones incompletas del producto final, pero proporcionan al usuario la

funcionalidad que precisa y tambin una plataforma para la evaluacin.

El desarrollo incremental es particularmente til cuando el personal no esta

disponible para una implementacin completa en la fecha lmite que se haya

establecido para el proyecto. Los primeros incrementos se pueden implementar

con menos personas.

Este modelo constituyo un avance sobre el modelo en cascada pero tambin

presenta problemas. Aunque permite el cambio continuo de requisitos, aun existe

el problema de determinar si los requisitos propuestos son validos. Los errores en

los requisitos se presentan tarde y su correccin resulta tan costosa como en el

modelo en cascada.

Proceso de Desarrollo Unificado

El Proceso Unificado es un proceso de software genrico que puede ser utilizado

para una gran cantidad de tipos de sistemas de software, para diferentes reas de

aplicacin, diferentes tipos de organizaciones, diferentes niveles de competencia y

diferentes tamaos de proyectos.

Provee un enfoque disciplinado en la asignacin de tareas y responsabilidades

dentro de una organizacin de desarrollo. Su meta es asegurar la produccin de

software de muy alta calidad que satisfaga las necesidades de los usuarios finales,

dentro de un calendario y presupuesto predecible.

El Proceso Unificado tiene dos dimensiones:

Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo

de vida del proceso a lo largo de su desenvolvimiento

Un eje vertical que representa las disciplinas, las cuales agrupan

actividades de una manera lgica de acuerdo a su naturaleza.

La primera dimensin representa el aspecto dinmico del proceso conforme se va

desarrollando, se expresa en trminos de fases, iteraciones e hitos.

La segunda dimensin representa el aspecto esttico del proceso: cmo es

descrito en trminos de componentes del proceso, disciplinas, actividades, flujos

de trabajo, artefactos y roles.

El Proceso Unificado se basa en componentes, lo que significa que el sistema en

construccin est hecho de componentes de software interconectados por medio

de interfaces bien definidas. El Proceso Unificado usa el Lenguaje de Modelado

Unificado (UML) en la preparacin de todos los planos del sistema. De hecho,

UML es una parte integral del Proceso Unificado, fueron desarrollados a la par.

Los aspectos distintivos del Proceso Unificado estn capturados en tres conceptos

clave: dirigido por casos de uso, centrado en la arquitectura, iterativo e

incremental. Esto es lo que hace nico al Proceso Unificado.

El Proceso Unificado es dirigido por casos de uso

Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para

construir un sistema exitoso se debe conocer qu es lo que quieren y necesitan

los usuarios prospectos. El trmino usuario se refiere no solamente a los usuarios

humanos, sino a otros sistemas, en este contexto, el trmino usuario representa

algo o alguien que interacta con el sistema por desarrollar. Un caso de uso es

una pieza en la funcionalidad del sistema que le da al usuario un resultado de

valor, los casos de uso capturan los requerimientos funcionales.

Todos los casos de uso juntos constituyen el modelo de casos de uso el cual

describe la funcionalidad completa del sistema. Este modelo reemplaza la

tradicional especificacin funcional del sistema. Una especificacin funcional

tradicional se concentra en responder la pregunta: Qu se supone que el sistema

debe hacer? La estrategia de casos de uso puede ser definida agregando tres

palabras al final de la pregunta: por cada usuario? Estas tres palabras tienen una

implicacin importante, nos fuerzan a pensar en trminos del valor a los usuarios y

no solamente en trminos de las funciones que sera bueno que tuviera. Sin

embargo, los casos de uso no son solamente una herramienta para especificar los

requerimientos del sistema, tambin dirigen su diseo, implementacin y pruebas,

esto es, dirigen el proceso de desarrollo.

An y cuando los casos de uso dirigen el proceso, no son elegidos de manera

aislada. Son desarrollados a la par con la arquitectura del sistema, esto es, los

casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema

influencia la eleccin de los casos de uso, por lo tanto, la arquitectura del sistema

y los casos de uso maduran conforme avanza el ciclo de vida.

El Proceso Unificado est centrado en la arquitectura

El papel del arquitecto de sistemas es similar en naturaleza al papel que el

arquitecto desempea en la construccin de edificios. El edificio se mira desde

diferentes puntos de vista: estructura, servicios, plomera, electricidad, etc. Esto le

permite al constructor ver una radiografa completa antes de empezar a construir.

Similarmente, la arquitectura en un sistema de software es descrita como

diferentes vistas del sistema que est siendo construido.

El concepto de arquitectura de software involucra los aspectos estticos y

dinmicos ms significativos del sistema. La arquitectura surge de las necesidades

de la empresa, tal y como las interpretan los usuarios y otros stakeholders, y tal y

como estn reflejadas en los casos de uso. Sin embargo, tambin est

influenciada por muchos otros factores, tales como la plataforma de software en la

que se ejecutar, la disponiblidad de componentes reutilizables, consideraciones

de instalacin, sistemas legados, requerimientos no funcionales (ej. desempeo,

confiabilidad).

La arquitectura es la vista del diseo completo con las caractersticas ms

importantes hechas ms visibles y dejando los detalles de lado. Ya que lo

importante depende en parte del criterio, el cual a su vez viene con la experiencia,

el valor de la arquitectura depende del personal asignado a esta tarea. Sin

embargo, el proceso ayuda al arquitecto a enfocarse en las metas correctas, tales

como claridad, flexibilidad en los cambios futuros y reuso.

Cmo se relacionan los casos de uso con la arquitectura? Cada producto tiene

funcin y forma. Uno slo de los dos no es suficiente, estas dos fuerzas deben

estar balanceadas para obtener un producto exitoso, en este caso funcin

corresponde a los casos de uso y forma a la arquitectura, existe la necesidad de

intercalar entre casos de uso y arquitectura.

Es un problema del huevo y la gallina. Por una parte, los casos de uso deben,

cuando son realizados, acomodarse en la arquitectura. Por otra parte, la

arquitectura debe proveer espacio para la realizacin de todos los casos de uso,

hoy y en el futuro. En la realidad, ambos arquitectura y casos de uso deben

evolucionar en paralelo.

El Proceso Unificado es Iterativo e Incremental

Desarrollar un producto de software comercial es una tarea enorme que puede

continuar por varios meses o aos. Es prctico dividir el trabajo en pequeos

pedazos o mini-proyectos. Cada mini-proyecto es una iteracin que finaliza en un

incremento. Las iteraciones se refieren a pasos en el flujo de trabajo, los

incrementos se refieren a crecimiento en el producto. Para ser ms efectivo, las

iteraciones deben estar controladas, esto es, deben ser seleccionadas y llevadas a

cabo de una manera planeada.

Los desarrolladores basan su seleccin de qu van a implementar en una iteracin

en dos factores. Primero, la iteracin trata con un grupo de casos de uso que en

conjunto extienden la usabilidad del producto. Segundo, la iteracin trata con los

riesgos ms importantes. Las iteraciones sucesivas construyen los artefactos del

desarrollo a partir del estado en el que fueron dejados en la iteracin anterior.

En cada iteracin, los desarrolladores identifican y especifican los casos de uso

relevantes, crean el diseo usando la arquitectura como gua, implementan el

diseo en componentes y verifican que los componentes satisfacen los casos de

uso. Si una iteracin cumple sus metas y usualmente lo hace el desarrollo

contina con la siguiente iteracin. Cuando la iteracin no cumple con sus metas,

los desarrolladores deben revisar sus decisiones previas y probar un nuevo

enfoque.

Una iteracin es un bucle de desarrollo completo, es una secuencia de actividades

con un plan establecido y criterios de evaluacin. Acaba en la edicin de un

producto ejecutable, subconjunto del producto final bajo desarrollo.

Se suele hablar de ciclos de vida en los que se realizan varios recorridos por todas

las fases. Cada recorrido por las fases se denomina Iteracin en el proyecto en la

que se realizan varios tipos de trabajo (denominados flujos). Cada iteracin parte

de la anterior incrementado (crece el producto) o revisando la funcionalidad

implementada. Los desarrolladores basan la seleccin de lo que implementarn en

cada iteracin en dos cosas: el conjunto de casos de uso que amplan la

funcionalidad, y en los riesgos ms importantes que deben mitigarse. Las

iteraciones deben estar controladas. Esto significa que deben seleccionarse y

ejecutarse de una forma planificada.

Los beneficios de este enfoque iterativo son:

La iteracin controlada reduce el riesgo a los costos de un solo incremento.

Reduce el riesgo de retrasos en el calendario atacando los riesgos ms

importantes primero.

Acelera el desarrollo. Los trabajadores trabajan de manera ms eficiente al

obtener resultados a corto plazo.

Tiene un enfoque ms realista al reconocer que los requisitos no pueden

definirse completamente al principio.

DIAGRAMA UML

EL LENGUAJE UNIFICADO DE MODELADO (UML)

En todas las disciplinas de la Ingeniera se hace evidente la importancia de los

modelos ya que describen el aspecto y la conducta de "algo". Ese "algo" puede

existir, estar en un estado de desarrollo o estar, todava, en un estado de

planeacin. Es en este momento cuando los diseadores del modelo deben

investigar los requerimientos del producto terminado y dichos requerimientos

pueden incluir reas tales como funcionalidad, performance y confiabilidad.

Adems, a menudo, el modelo es dividido en un nmero de vistas, cada una de

las cuales describe un aspecto especfico del producto o sistema en construccin.

El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones

de pequeo tamao se obtienen beneficios de modelado, sin embargo es un

hecho que entre ms grande y ms complejo es el sistema, ms importante es el

papel de que juega el modelado por una simple razn: "El hombre hace modelos

de sistemas complejos porque no puede entenderlos en su totalidad".

Los principales beneficios de UML son:

Mejores tiempos totales de desarrollo (de 50 % o ms).

Modelar sistemas (y no slo de software) utilizando conceptos orientados a

objetos.

Establecer conceptos y artefactos ejecutables.

Encaminar el desarrollo del escalamiento en sistemas complejos de misin

crtica.

Crear un lenguaje de modelado utilizado tanto por humanos como por

mquinas.

Mejor soporte a la planeacin y al control de proyectos.

Alta reutilizacin y minimizacin de costos.

UML es un lenguaje para hacer modelos y es independiente de los mtodos de

anlisis y diseo. Existen diferencias importantes entre un mtodo y un lenguaje

de modelado. Un mtodo es una manera explcita de estructurar el pensamiento y

las acciones de cada individuo. Adems, el mtodo le dice al usuario qu hacer,

cmo hacerlo, cundo hacerlo y por qu hacerlo; mientras que el lenguaje de

modelado carece de estas instrucciones. Los mtodos contienen modelos y esos

modelos son utilizados para describir algo y comunicar los resultados del uso del

mtodo.

Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado

consiste de vistas, diagramas, elementos de modelo (los smbolos utilizados en los

modelos) y un conjunto de mecanismos generales o reglas que indican cmo

utilizar los elementos. Las reglas son sintcticas, semnticas y pragmticas.

Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista

no es una grfica, pero s una abstraccin que consiste en un nmero de

diagramas y todos esos diagramas juntos muestran una "fotografa" completa del

sistema. Las vistas tambin ligan el lenguaje de modelado a los mtodos o

procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son:

Vista Casos de Uso: Una vista que muestra la funcionalidad del sistema

como la perciben los actores externos.

Vista Lgica: Muestra cmo se disea la funcionalidad dentro del sistema,

en trminos de la estructura esttica y la conducta dinmica del sistema.

Vista de Componentes: Muestra la organizacin de los componentes de

cdigo.

Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los

problemas con la comunicacin y sincronizacin que estn presentes en un

sistema concurrente.

Vista de Distribucin: muestra la distribucin del sistema en la arquitectura

fsica con computadoras y dispositivos llamados nodos.

Diagramas: Los diagramas son las grficas que describen el contenido de una

vista. UML tiene nueve tipos de diagramas que son utilizados en combinacin para

proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de

objetos, de estados, de secuencia, de colaboracin, de actividad, de componentes

y de distribucin.

Smbolos o Elementos de modelo: Los conceptos utilizados en los diagramas

son los elementos de modelo que representan conceptos comunes orientados a

objetos, tales como clases, objetos y mensajes, y las relaciones entre estos

conceptos incluyendo la asociacin, dependencia y generalizacin. Un elemento

de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el

mismo significado y simbologa.

Reglas o Mecanismos generales: Proveen comentarios extras, informacin o

semntica acerca del elemento de modelo; adems proveen mecanismos de

extensin para adaptar o extender UML a un mtodo o proceso especfico,

organizacin o usuario.

FASES DEL DESARROLLO DE UN SISTEMA

Las fases del desarrollo de sistemas que soporta UML son: Anlisis de

requerimientos, Anlisis, Diseo, Programacin y Pruebas.

Anlisis de Requerimientos

UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente.

A travs del modelado de casos de uso, los actores externos que tienen inters en

el sistema son modelados con la funcionalidad que ellos requieren del sistema (los

casos de uso). Los actores y los casos de uso son modelados con relaciones y

tienen asociaciones entre ellos o stas son divididas en jerarquas. Los actores y

casos de uso son descritos en un diagrama use-case. Cada use-case es descrito

en texto y especifica los requerimientos del cliente: lo que l (o ella) espera del

sistema sin considerar la funcionalidad que se implementar. Un anlisis de

requerimientos puede ser realizado tambin para procesos de negocios, no

solamente para sistemas de software.

Anlisis

La fase de anlisis abarca las abstracciones primarias (clases y objetos) y

mecanismos que estn presentes en el dominio del problema. Las clases que se

modelan son identificadas, con sus relaciones y descritas en un diagrama de

clases. Las colaboraciones entre las clases para ejecutar los casos de uso

tambin se consideran en esta fase a travs de los modelos dinmicos en UML.

Es importante notar que slo se consideran clases que estn en el dominio del

problema (conceptos del mundo real) y todava no se consideran clases que

definen detalles y soluciones en el sistema de software, tales como clases para

interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.

Diseo

En la fase de diseo, el resultado del anlisis es expandido a una solucin tcnica.

Se agregan nuevas clases que proveen de la infraestructura tcnica: interfaces de

usuario, manejo de bases de datos para almacenar objetos en una base de datos,

comunicaciones con otros sistemas, etc. Las clases de dominio del problema del

anlisis son agregadas en esta fase. El diseo resulta en especificaciones

detalladas para la fase de programacin.

Programacin

En esta fase las clases del diseo son convertidas a cdigo en un lenguaje de

programacin orientado a objetos. Cuando se crean los modelos de anlisis y

diseo en UML, lo ms aconsejable es trasladar mentalmente esos modelos a

cdigo.

Pruebas

Normalmente, un sistema es tratado en pruebas de unidades, pruebas de

integracin, pruebas de sistema, pruebas de aceptacin, etc. Las pruebas de

unidades se realizan a clases individuales o a un grupo de clases y son

tpicamente ejecutadas por el programador. Las pruebas de integracin integran

componentes y clases en orden para verificar que se ejecutan como se especific.

Las pruebas de sistema ven al sistema como una "caja negra" y validan que el

sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de

aceptacin conducidas por el cliente verifican que el sistema satisface los

requerimientos y son similares a las pruebas de sistema.

CASOS DE USO (UC)

Describen bajo la forma de acciones y reacciones el comportamiento de un

sistema desde el punto de vista de un usuario, permiten definir los lmites del

sistema y las relaciones entre el sistema y el entorno, es una manera especfica

de utilizar un sistema. Es la imagen de una funcionalidad del sistema,

desencadenada en respuesta a la estimulacin de un actor externo.

Necesidades de informacin

Las necesidades se expresan a menudo de manera no estructurada, sin fuerte

coherencia, frecuentemente, las necesidades se contradicen, se cometen olvidos,

subsisten imprecisiones y el anlisis del sistema parte sobre una mala base, los

casos de uso reubican la expresin de las necesidades sobre los usuarios,

partiendo del punto de vista muy simple que dice que un sistema se construye

ante todo para sus usuarios. La terminologa empleada en la redaccin de los

Casos de Uso es la empleada por los usuarios en su quehacer cotidiano, de modo

que la expresin de las necesidades se facilita en gran medida.

Modelo de Casos de Uso

Comprende los actores, el sistema y los propios casos de uso, el conjunto de

funcionalidades de un sistema se determina examinando las necesidades

funcionales de cada actor, expresadas en forma de familias de interacciones con

el caso de uso.

Actor

Representa un papel o rol interpretado por una persona o una cosa que interacta

con un sistema, los actores se determinan observando los usuarios directos del

sistema, los responsables de su uso o de su mantenimiento, as como los otros

sistemas que interactan con el sistema en cuestin, la misma persona puede

interpretar el rol de varios actores, y varias personas pueden interpretar el mismo

papel y actuar, como el mismo actor.

Categoras de Actores

Primarios: agrupa a todo aquello que utiliza las funciones principales del sistema

para satisfacer un requerimiento.

Secundarios: agrupa a todo aquello de lo que el sistema se vale para atender los

requerimientos de los actores principales.

Tipos actores:

Personas

Dispositivos

Otros Sistemas

Actores y Escenarios

Se describen actor por actor, en trminos de escenarios, mostrando la informacin

intercambiada y las acciones en la manera de utilizar el sistema, un caso de uso

agrupa una familia de escenarios de uso segn un criterio funcional. Describen

interacciones entre los actores y el sistema sin entrar en detalles de cada

escenario.

Escenarios: Instancias de un Caso de Uso

Los casos de uso deben ser vistos como clases cuyas instancias son los

escenarios. cada vez que un actor interacta con el sistema un caso de uso

instancia un escenario; este escenario corresponde al flujo de mensajes

intercambiados por los objetos durante la interaccin particular que corresponde al

escenario.

Qu es un Escenario de Caso de Uso?

Es una descripcin de una situacin del negocio que puede ser visualizada por los

usuarios de un sistema, es decir un escenario es una secuencia de interacciones

ocurriendo bajo ciertas condiciones para lograr el objetivo del actor primario, y

teniendo un particular resultado con respecto a este objetivo.

Relaciones entre Actores y Casos de Uso

De Comunicacin: La participacin del actor se seala por una flecha entre

el actor y el caso de uso. El sentido de la flecha indica el iniciador de la

interaccin.

De Inclusin: Entre casos de uso, significa que una instancia del caso de

uso fuente comprende tambin el comportamiento descrito por el caso de

uso destino.

De extensin: Entre casos de uso, significa que el caso de uso fuente

extiende el comportamiento del caso de uso destino.

Implementacin de relaciones

Construccin de Casos de Uso

Un UC debe ser ante todo simple, inteligible, descrito de manera clara y concisa.

La descripcin de la interaccin se concentra sobre lo que debe hacerse en el UC,

no sobre la manera de cmo hacerlo, el nmero de actores que interactan con el

UC es limitado, y por regla general, hay un solo actor por UC.

En la construccin de los UC hay que preguntarse:

Cules son las tareas del actor?

Qu informaciones debe el actor crear, guardar, modificar, destruir o

simplemente leer?

El actor, Deber informar al sistema. de los cambios externos?

El sistema, Deber informar al actor de las condiciones internas?

Reglas de Implementacin de un Caso de Uso

La descripcin de un UC comprende los elementos siguientes.

Inicio: el evento que inicia el UC; debe expresarse con la frase El UC

empieza cuando X se produce.

Fin: el evento que causa la parada del UC; debe expresarse con la frase

Cuando Y se produce, el UC ha terminado.

Interaccin con el actor: describe claramente lo que el actor desea le

proporcione el sistema.

Intercambio informacin: expresa en lenguaje natural la forma de la

interaccin entre el sistema y los actores en forma de parmetros.

Cronologa y origen de la informacin: describe cuando el sistema necesita

informacin interna o externa y cuando las almacena.

Las repeticiones de comportamiento: que pueden describirse por medio de

pseudocdigo.

Opcionalidad: expresan las opciones para algunas de las acciones dentro

de un escenario.

Transicin hacia los Objetos

El paso hacia la aproximacin a objetos se efecta asociando una colaboracin

entre objetos a cada escenario instancia de un UC, los escenarios, se representan

por diagramas de interaccin entre objetos.

Descomposicin hacia objetos

INGENIERA DE REQUERIMIENTOS

En la actualidad, son muchos los procesos de desarrollo de software que existen.

Con el pasar de los aos, la Ingeniera de Software ha introducido y popularizado

una serie de estndares para medir y certificar la calidad, tanto del sistema a

desarrollar, como del proceso de desarrollo en s. Se han publicado muchos libros

y artculos relacionados con este tema, con el modelado de procesos del negocio

y la reingeniera.

Un nmero creciente de herramientas automatizadas han surgido para ayudar a

definir y aplicar un proceso de desarrollo de software efectivo. Hoy en da la

economa global depende ms de sistemas automatizados que en pocas

pasadas; esto ha llevado a los equipos de desarrollo a enfrentarse con una nueva

dcada de procesos y estndares de calidad.

Sin embargo, cmo explicamos la alta incidencia de fallos en los proyectos de

software? Por qu existen tantos proyectos de software vctimas de retrasos,

presupuestos sobregirados y con problemas de calidad? Cmo podemos tener

una produccin o una economa de calidad, cuando nuestras actividades diarias

dependen de la calidad del sistema? Tal vez suene ilgico pero, a pesar de los

avances que ha dado la tecnologa, an existen procesos de produccin

informales, parciales y en algunos casos no confiables.

La Ingeniera de Requerimientos cumple un papel primordial en el proceso de

produccin de software, ya que enfoca un rea fundamental: la definicin de lo

que se desea producir. Su principal tarea consiste en la generacin de

especificaciones correctas que describan con claridad, sin ambigedades, en

forma consistente y compacta, el comportamiento del sistema; de esta manera, se

pretende minimizar los problemas relacionados al desarrollo de sistemas.

La razn principal para escoger este tema se fundament en la gran cantidad de

proyectos de software que no llegan a cumplir sus objetivos. En nuestro pas

somos partcipes de este problema a diario, en donde se ha vuelto comn la

compra de sistemas extranjeros, para luego "personalizarlos" supuestamente a la

medida de las empresas.

El reemplazo de plataformas y tecnologas obsoletas, la compra de sistemas

completamente nuevos, las modificaciones de todos o de casi todos los programas

que forman un sistema, entre otras razones, llevan a desarrollar proyectos en

calendarios sumamente ajustados y en algunos casos irreales; esto ocasiona que

se omitan muchos pasos importantes en el ciclo de vida de desarrollo, entre estos,

la definicin de los requerimientos.

Tcnicas de obtencin de requerimientos

El descubrimiento de requerimientos es el proceso de recoger informacin sobre el

sistema propuesto y extraer los requerimientos del usuario. Las fuentes de

informacin durante la fase del descubrimiento de requerimientos incluyen la

documentacin, los stakeholders del sistema y la especificacin de sistemas

similares.

Entre los stakeholders podemos encontrar desde los usuarios finales del sistema

hasta los gerentes, adems de los stakeholders del sistema, ya hemos visto que

los requerimientos pueden venir del dominio de la aplicacin y de otros sistemas

que interactan con el sistema a especificar.

Todos estos se deben considerar durante el proceso de obtencin de

requerimientos. Estas fuentes de requerimientos se pueden representar como

puntos de vista del sistema, donde cada uno presenta un subconjunto de

requerimientos para el sistema.

Entrevistas

Las entrevistas formales o informales con los stakeholders del sistema son parte

de la mayora de los procesos de la ingeniera de requerimientos. En estas

entrevistas, el equipo de la ingeniera de requerimientos hace preguntas a los

stakeholders sobre el sistema que utilizan y sobre el sistema a desarrollar. Los

requerimientos provienen de las respuestas a estas preguntas. Las entrevistas

pueden ser de dos tipos: Las respuestas a algunas preguntas pueden conducir a

otras cuestiones que se discuten de una forma menos estructurada. Las

discusiones completamente abiertas raramente salen bien; la mayora de las

entrevistas requieren algunas preguntas para empezar y para mantener la

entrevista centrada en el sistema a desarrollar.

Las entrevistas sirven para obtener una comprensin general de lo que hacen los

stakeholders, como podran interactuar con el sistema y las dificultades a las que

se enfrentan con los sistemas actuales. A la gente le gusta hablar sobre su trabajo

y normalmente se alegran de verse implicados en las entrevistas. Sin embargo, no

son de tanta utilidad para la comprensin de los requerimientos del dominio de la

aplicacin.

Es difcil obtener conocimiento del dominio durante las entrevistas debido a dos

razones:

1. Todos los especialistas de la aplicacin utilizan terminologa y lenguaje

especifica de un dominio. Es imposible para ellos discutir requerimientos del

dominio sin utilizar esta terminologa. Normalmente la utilizan de un modo

preciso y sutil, por lo que es fcil que la malinterpreten los ingenieros de

requerimientos.

2. Cierto conocimiento del dominio es tan familiar para los stakeholders que lo

encuentran difcil de explicar o piensan que es tan bsico que no merece la

pena mencionarlo.

Las entrevistas no son una tcnica eficaz para obtener conocimiento sobre los

requerimientos y restricciones organizacionales debido a que existen sutiles

poderes e influencias entre los stakeholders en la organizacin. Las estructuras

organizacionales publicadas rara vez se corresponden con la realidad de la toma

de decisiones en una organizacin, pero los entrevistados pueden no desear

revelar la estructura real en vez de la terica a un desconocido. En general, la

mayora de la gente es reacia a discutir cuestiones polticas y organizacionales

que pueden influir en los requerimientos.

Los entrevistadores eficaces tienen dos caractersticas:

1. No tienen prejuicios, evitan ideas preconcebidas sobre los requerimientos y

estn dispuestos a escuchar. Si el stakeholder propone requerimientos

sorprendentes, estn dispuestos a cambiar su opinin del sistema.

2. Instan al entrevistado a empezar las discusiones con una pregunta, una

propuesta de requerimientos o sugiriendo trabajar juntos en un prototipo del

sistema. Decir a la gente dime lo que quieres es improbable que cause

informacin de utilidad. La mayora de la gente encuentra mucho mas fcil hablar

en un contexto definido en vez de en trminos generales.

La informacin de la entrevistas complementa otras informaciones sobre el

sistema de los documentos, observaciones de los usuarios, etc. Algunas veces,

aparte de la informacin de los documentos, las entrevistas pueden ser la tcnica

fuente de informacin sobre los requerimientos del sistema. Sin embargo, las

entrevistas por si mismas tienden a omitir informacin esencial, por lo que

deberan ser usadas al lado de otras tcnicas de obtencin de requerimientos.

Reuniones

Las reuniones tienen como objetivo, obtener informacin que se encuentra

repartida entre varias personas, tomar decisiones estratgicas, tcticas u

operativas, transmitir ideas sobre un determinado tema, analizar nuevas

necesidades de informacin, comunicar los resultados obtenidos como

consecuencia de un estudio.

Las directrices bsicas de una reunin son:

Preparar y convocar la reunin (orden del da).

Realizar la reunin.

Consolidar el resultado de la reunin.

Elaborar el acta de reunin.

Cuestionarios

Es un conjunto de preguntas que deben ser contestadas por escrito por una

determinada poblacin, generalmente esta poblacin es amplia. Segn el

contenido de los cuestionarios podemos clasificarlos en los siguientes tipos:

Abiertos: Las respuestas no estn delimitadas, esto permite mayor libertad de

expresin.

Cerrados: Se fuerza a respuestas concretas. Un mismo tipo de pregunta puede

formularse para obtener diferente rango de respuestas:

Eleccin exclusiva (respuestas del tipo si/no). Por ejemplo: Cree que

existen muchos circuitos integrados defectuosos?

Escala cualitativa (acuerdo/desacuerdo). Por ejemplo: Existen muchos

circuitos integrados defectuosos. Las posibles respuestas son: de acuerdo,

totalmente de acuerdo, no estoy seguro, en desacuerdo, totalmente en

desacuerdo.

Cantidad, es decir, la pregunta requiere como respuesta una determinada

cantidad. Por ejemplo: De cada 100 circuitos integrados cuntos son

defectuosos?

Rango o escala cuantitativa, donde la respuesta es un rango de valores.

Por ejemplo: De cada 100 circuitos integrados son defectuosos (05, 610,

>50, etc.)

Seleccin de respuestas limitadas. Por ejemplo: Las causas ms frecuentes

de circuitos integrados defectuosos son: a) Fallo en la impresin de la pista.

b) Fallo en la conexin de las patillas. c) Fallo en el encapsulado de

plstico.

Mixtos: una combinacin de los anteriores Los buenos cuestionarios no solo se

escriben sino que se disean. Una buena elaboracin acompaada de una prueba

previa, tanto del formato como de las preguntas, son la base de una recopilacin

de datos significativa a travs del cuestionario.

Puntos que ayudarn en la formulacin de un cuestionario:

1. Determinar qu datos necesitan recabarse y qu personas son las ms

calificadas para proporcionarlos. Si hay otros grupos que pueden proporcionar

datos variantes y mayor visin tambin se identificarn.

2. Seleccionar el tipo de cuestionario a utilizar (abierto, cerrado o mixto).

3. Desarrollar un grupo de preguntas para incluirlas en el cuestionario. Las

preguntas extras que son intencionalmente redundantes, pueden ser tiles al

asegurar respuestas consistentes por parte de quien responda.

4. Examinar el cuestionario para encontrarle fallos y defectos, como:

a) Interrogantes innecesarias.

b) Preguntas que pueden ser mal interpretadas debido a su enfoque o

forma de escritura.

c) Preguntas que el sujeto posiblemente no pueda responder, dado que

desconoce la respuesta.

d) Preguntas que estn escritas de forma que se escoger la respuesta

preferida.

e) Preguntas que se interpretarn de forma diferente dependiendo del

marco de referencia de cada entrevistado.

f) Preguntas que no proporcionan opciones adecuadas de respuesta.

g) Un ordenamiento no adecuado de las preguntas o respuestas.

5. Probar previamente el cuestionario en un grupo pequeo de personas, para

detectar otros problemas posibles. As no solamente se describen los problemas

en cuanto a su escritura, espaciado, ortografa, y mtodos de registro de

respuestas, sino tambin proporciona una indicacin del tipo de respuestas que se

recopilarn en un grupo mayor. Si existen muchas respuestas inesperadas, se

captarn durante la prueba previa. Hay que asegurar que la muestra de prueba

sea comparable al grupo mayor que recibir el cuestionario.

6. Analizar las respuestas del grupo de prueba para asegurar que el anlisis de los

datos que se busca puede llevarse a cabo con el tipo de datos recopilados. Si

estos datos no revelan algo que los analistas no reconocen y no necesitan

verificar, el cuestionario puede no ser necesario en su forma actual.

7. Realizar cambios finales de edicin, correcciones de mecanografa y ajustes en

la forma; entonces imprimir el cuestionario en una forma limpia y legible.

8. Distribuir el cuestionario. Cuando sea posible, anotar el nombre de cada

persona.

Desarrollo conjunto de aplicaciones (JAD)

Tcnica que se utiliza para promover la cooperacin 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

dinmica de grupos aplicando un proceso de trabajo sistemtico y organizado,

apoyado por elementos visuales de comunicacin y comprensin de soluciones.

Las razones que sirven de base a JAD son las siguientes:

Las entrevistas requieren mucho tiempo, no solo en prepararlas y hacerlas

sino tambin en redactar un conjunto de requisitos coherente a partir de

opiniones diferentes de los distintos entrevistados.

Es ms difcil apreciar posibles errores en la especificacin de requisitos, ya

que slo el analista revisa el documento. En el JAD todo el grupo puede

actuar como revisor y detectar defectos.

El JAD propugna una participacin ms profunda de los usuarios en el

proyecto, hasta tal punto que los usuarios que participan adquieren un

cierto sentido de propiedad en el sistema que se construye.

El JAD no se utiliza demasiado, debido a que requiere una mayor

organizacin que las entrevistas y porque el ambiente o los mtodos de

trabajo convencionales en las empresas no facilitan este tipo de actividades

(falta de tiempo, dificultad de coordinacin de tanta gente, dificultad para

convencer a la direccin, etc.).

No obstante las empresas que han implantado este mtodo han informado de

importantes ahorros de tiempo en el desarrollo de software, as como de una

mayor satisfaccin de los usuarios con los sistemas construidos.

Joint Requirements Planning (JRP)

Las caractersticas de las sesiones JRP y JAD son comunes en cuanto a la

dinmica del desarrollo de las sesiones y la obtencin de los modelos con el

soporte de herramientas, la diferencia radica en los productos de salida y en los

perfiles de los participantes, en JRP son del nivel ms alto en la organizacin en

cuanto a visin global del negocio y capacidad de decisin.

Perfiles implicados:

Moderador, debe tener una gran capacidad de relacin, habilidades de

negociacin y de gestin de dinmica de grupos, as como un alto nivel de

conocimiento de los procesos de la organizacin.

Promotor, persona que ha impulsado el Plan de Sistemas de Informacin y

tiene un compromiso econmico.

Director de proyecto, responsable de que el proyecto llegue a buen fin.

Consultores, responsable de traducir los requisitos especificados por el

usuario en informacin estructurada, de tal forma, que los usuarios puedan

entender y discutir los resultados.

Especialista en modelizacin, responsable de la elaboracin de los

modelos en el transcurso de la sesin.

Usuarios de alto nivel, responsables de definir los procesos de la

organizacin y los sistemas de informacin afectados as como las

prioridades para su implantacin a largo o medio plazo en la organizacin.

Brainstorming

Su objetivo consiste en desarrollar y ejercitar la imaginacin creador, la cual se

entiende por la capacidad de establecer nuevas relaciones entre hechos, o

integrarlo de una manera distinta. El director del grupo precisa el problema por

tratarse, explica el procedimiento y las normas mnimas que han de seguirse

dentro del clima informal bsico.

Las ideas que se expongan no deben ser censuradas ni criticadas directa o

indirectamente. Debe evitarse todo tipo de manifestaciones que coarten o puedan

inhibir la espontaneidad. Los miembros exponen su punto de vista sin

restricciones. Terminado el plazo previsto, se pasa a considerar ahora con

sentido crtico y en un plano de realidad la viabilidad o practicidad de las

propuestas ms valiosas. El director del grupo hace un resumen y junto con los

miembros extrae las conclusiones.

Formular el objetivo.

Anotar rpidamente cualquier idea que pase por la cabeza.

No escribir las frases enteras.

No evaluar las ideas.

No ordenar las ideas.

Preferir cantidad a calidad.

Dos cabezas son mejor que una.

Incluir ideas salvajes (que podran llevar a ideas tiles).

Generar ideas por asociacin.

Combinar ideas existentes para obtener ideas nuevas.

Modificar ideas existentes para obtener ideas nuevas.

Asociar ideas usando conexiones y proximidad.

Clasificar ideas por colores.

Mantener todas las ideas a la vista y parar cuando no surjan ms ideas.

Al da siguiente (no el mismo da) el grupo se tendra que volver a encontrar.

Primero, se tendran que compartir las ideas pensadas desde la sesin anterior.

Despus, el grupo tendra que evaluar cada una de las ideas y desarrollar las que

prometan ms para poderlas llevar a la prctica. Las ideas salvajes se convierten

en prcticas o utilizadas para sugerir soluciones realistas. El nfasis hay que

ponerlo en el anlisis y en temas del mundo real.

La evaluacin no se hace el mismo da que la sesin de brainstorming. Esto hace

que la sesin de ideas sea ms libre (sin el temor de la evaluacin inmediata) y

permite un tiempo de incubacin de ms ideas y un tiempo para pensar sobre las

ideas que han surgido.

Phillips 66

Consiste en dividir cualquier grupo en otros ms pequeos, de 4 a 6 integrantes,

con el propsito de discutir o analizar un problema o tema, cada grupo busca una

solucin particular y se hace una puesta en comn, se rotan los grupos.

PASOS PARA LA OBTENCIN DE REQUERIMIENTOS.

1. Aprender todo lo que se pueda de los documentos, formularios, informes y

archivos existentes. Es sorprendente lo que se puede aprender de un

sistema sin necesidad de quitarle tiempo a la gente.

2. De ser posible, se observar el sistema en accin. No se plantearn

preguntas. Tan slo se observar y se tomarn notas o dibujos. Conviene

asegurarse de que las personas observadas saben que no se les est

evaluando. En caso contrario, harn su trabajo de manera ms eficaz que lo

normal.

3. Disear y distribuir cuestionarios para aclarar cuestiones que no se

comprenden bien. Ser tambin buen momento para solicitar opiniones sobre

los problemas y las limitaciones. Los cuestionarios requieren que los usuarios

inviertan una parte de su tiempo. Pero son ellos los que pueden elegir cundo

les viene mejor hacerlo.

4. Realizar entrevistas (o sesiones de trabajo en grupo, como JAD). Como ya

se ha recogido una base de requerimientos iniciales en los pasos anteriores, se

pueden utilizar las entrevistas para verificar y aclarar las cuestiones y los

problemas de mayor dificultad. En este punto se pueden llegar a aplicar

algunas de las otras tcnicas cmo Escenarios, Tormenta de ideas, Puntos de

Vista, ETHICS y Desarrollo de Prototipos.

5. Se verifican los requerimientos a travs del uso de tcnicas como

Entrevistas, Observacin y orientados a Puntos de Vista.

ESPECIFICACIN DE REQUERIMIENTOS

La especificacin de requisitos de software (ERS) es una descripcin completa del

comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos

de uso que describe todas las interacciones que tendrn los usuarios con el

software. Los casos de uso tambin son conocidos como requisitos funcionales.

Adems de los casos de uso, la ERS tambin contiene requisitos no funcionales (o

complementarios). Los requisitos no funcionales son requisitos que imponen

restricciones en el diseo o la implementacin, como, por ejemplo, restricciones en

el diseo o estndares de calidad.

Est dirigida tanto al cliente como al equipo de desarrollo. El lenguaje utilizado

para su redaccin debe ser informal, de forma que sea fcilmente comprensible

para todas las partes involucradas en el desarrollo.

Prcticas recomendadas para una buena ERS, las caractersticas de una buena

ERS son definidas por el estndar IEEE 830-1998.

Una buena ERS debe ser:

Completa. Todos los requerimientos deben estar reflejados en ella y todas

las referencias deben estar definidas.

Consistente. Debe ser coherente con los propios requerimientos y tambin

con otros documentos de especificacin.

Inequvoca. La redaccin debe ser clara de modo que no se pueda mal

interpretar.

Correcta. El software debe cumplir con los requisitos de la especificacin.

Trazable. Se refiere a la posibilidad de verificar la historia, ubicacin o

aplicacin de un tem a travs de su identificacin almacenada y

documentada.

Priorizable. Los requisitos deben poder organizarse jerrquicamente segn

su relevancia para el negocio y clasificndolos en esenciales, condicionales

y opcionales.

Modificable. Aunque todo requerimiento es modificable, se refiere a que

debe ser fcilmente modificable.

Verificable. Debe existir un mtodo finito sin costo para poder probarlo.

Tipos de requisitos

Existen varios tipos de requisitos como lo son:

1. Requisitos de Usuarios: Necesidades que los usuarios expresan

verbalmente

2. Requisitos del Sistema: Son los componentes que el sistema debe tener

para realizar determinadas tareas

3. Requisitos Funcionales: Servicios que el sistema debe proporcionar

Un requisito funcional define una funcin del sistema de software o sus

componentes. Una funcin es descrita como un conjunto de entradas,

comportamientos y salidas. Los requerimientos funcionales pueden ser: clculos,

detalles tcnicos, manipulacin de datos y otras funcionalidades especficas que

se supone, un sistema debe cumplir. Los requerimientos de comportamiento para

cada requerimiento funcional se muestran en los casos de uso. Son

complementados por los requisitos no funcionales, que se enfocan en cambio en

el diseo o la implementacin.

Como se define en la ingeniera de requisitos, los requisitos funcionales

establecen los comportamientos del sistema, tpicamente, un analista de requisitos

genera requisitos funcionales luego de diagramar los casos de uso. Sin embargo,

esto puede tener excepciones, ya que el desarrollo de software es un proceso

iterativo y algunos requisitos son previos al diseo de los casos de uso. Ambos

elementos (casos de uso y requisitos) se complementan en un proceso

bidireccional.

Un requisito funcional tpico contiene un nombre y un nmero de serie nico y un

resumen. Esta informacin se utiliza para ayudar al lector a entender por qu el

requisito es necesario, y para seguir al mismo durante el desarrollo del producto.

El ncleo del requisito es la descripcin del comportamiento requerido, que debe

ser clara y concisa. Este comportamiento puede provenir de reglas

organizacionales o del negocio, o ser descubiertas por interaccin con usuarios,

inversores y otros expertos en la organizacin.

4. Requisitos no funcionales: Restricciones que afectan al sistema

Un requisito no funcional o atributo de calidad es, en la ingeniera de sistemas y la

ingeniera de software, un requisito que especifica criterios que pueden usarse

para juzgar la operacin de un sistema en lugar de sus comportamientos

especficos, ya que stos corresponden a los requisitos funcionales. Por tanto, se

refieren a todos los requisitos que ni describen informacin a guardar, ni funciones

a realizar.

Algunos ejemplos de requisitos no funcionales tpicos son los siguientes:

Rendimiento, disponibilidad, seguridad, accesibilidad, usabilidad, estabilidad,

portabilidad, costo, operatividad, interoperabilidad, escalabilidad, concurrencia,

mantenibilidad, interfaz