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.

Planificacin
Anlisis de riesgo Anlisis de riesgo Anlisis de riesgo Prototipo 3 Revisin AR Prototipo 2 Prototipo 1
Plan de requisitos, Plan de ciclo de vida Plan de desarrollo Concepto de operacin Requisitos

Anlisis de Riesgos

Prototipo Operativo

Simulaciones, Modelos, Estndares

de Software Validacin de requisitos Diseo del producto de software

Diseo detallado

Plan de prueba e Integracin

Codificacin Verificacin y validacin de diseo Prueba de Unidad Prueba de Integracin Prueba de aceptacin

Evaluacin del Cliente

Implementacin

Ingeniera

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.

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