Sistemas de Informacin

Ingeniera y Desarrollo de Sistemas de Informacin Desarrollo de Software

Ing. Rubn A. More Valencia rmorev77@gmail.com

Sistema

Qu es un sistema?
Conjunto de dos o ms elementos interrelacionados entre s que trabajan para lograr un objetivo comn La cualidad esencial de un sistema est dada por la interdependencia de las partes que lo integran y el orden que subyace a tal interdependencia. La conducta de cada elemento tiene un efecto sobre la conducta del todo. La conducta de los elementos y sus efectos sobre el todo son interdependientes. Los subgrupos de elementos tienen efecto sobre la conducta del todo

Sistemas abiertos y Cerrados

Abiertos Intercambian informacin, materiales y energa con su ambiente

Se ajustan a los cambios del medio ambiente para preservarse

Tienden hacia la homeostasis, que es el proceso de adaptacin del sistema al medio ambiente. Cerrados No interactan con el medio ambiente. Tienden hacia la entropa, que consiste en el proceso de desgaste y acaba totalmente con el sistema.

El conocimiento

Tres tipos de conocimiento principales: Artstico Interpretacin de la realidad y sus consecuencias Depende de la subjetividad del observador Cientfico Se basa en axiomas Utiliza algn motor de inferencia lgico Intenta demostrar una hiptesis Tcnico

Es el tipo de conocimiento que generan las actividades de ingeniera

No se basa en inferencias ni en interpretaciones Se evala en funcin de parmetros especficos

Que parmetros?

Refinamiento NO significa Prueba y Error, sino depurar constantemente

El modelo debe acercarse a la realidad.

El modelo debe evitar los detalles innecesarios Mtodo La actividad de ingeniera debe ser altamente metdica

Se debe poder reproducir los pasos seguidos

Formalizar la comunicacin ayuda Es necesario asegurar un camino eficaz Enfoque Sistmico Permite simplificar la visin de algunos problemas Tiene que ver con la sinergia de los participantes No siempre es el enfoque adecuado, pero vale en Diseo de Sistemas.

Qu es el software?

Programas informticos y documentacin asociada tales como requerimientos, modelos de diseo y manuales de usuario Los productos de software deben ser desarrollados para un cliente especfico o bien para el mercado general. Los productos de software deben ser
- Genricos - desarrollados para ser vendidos a una amplia gama de clientes. P.ej: software para PC como Excel o Word. - Personalizados (cliente) - desarrollado para un nico cliente de acuerdo con su especificacin

El nuevo software puede ser creado mediante el desarrollo de nuevos programas, configurando sistemas de software genrico o reutilizando software existente.

Qu es la ingeniera de software?

La ingeniera de software es una disciplina de la ingeniera que comprende todos los aspectos de la produccin de software.

Los ingenieros de software deben adoptar un enfoque sistemtico y organizado en su trabajo y utilizar herramientas y tcnicas apropiadas dependiendo del problema que se va a resolver, de la restriccin del desarrollo y de los recursos disponibles

Sistema de Software

Desde una perspectiva amplia, un sistema se considerar como sistema de software cuando sus recursos software constituyan su elemento bsico y la fuente de su funcionalidad bsica. Dicho de otro modo, cuando en el proceso de desarrollo sean los recursos software los que determinan el proceso general de desarrollo de todo el sistema y cuando su ejecucin pueda realizarse sobre una plataforma hardware genrico.

Una perspectiva histrica

Centrndonos en la ingeniera de sistemas de software, su consolidacin ha sufrido una evolucin en etapas en paralelo con la propia evolucin de la programacin. Destacamos cuatro etapas: La programacin como base del desarrollo (1955-1965). nfasis absoluto en la tarea de escribir el cdigo en un lenguaje de programacin. Alrededor de los nuevos lenguajes de alto nivel, los programadores se alejan de la estructura de los ordenadores y comienzan a acercarse a la complejidad de las aplicaciones de usuario. La gnesis (1965-1975). Ligada a la crisis de la programacin se plantea la necesidad de controlar el proceso de desarrollo. Se definen modelos de ciclo de vida como una referencia en la que enmarcar las actividades requeridas. El concepto de ciclo de vida en cascada surge de la necesidad del Departamento de Defensa de EE.UU.. de disponer de una documentacin normalizada para todas las etapas del desarrollo y poder controlar en base a ella a los suministradores de productos software.

Una perspectiva histrica

La consolidacin (1975-1985). El control de las actividades de desarrollo debera permitir gestionar el proceso. Durante esta etapa aparecen mtricas para estimar a priori el coste o el tamao del sistema; se difunde el uso de mtodos de desarrollo. Con ello, el programador se convierte en analista, diseador o gestor. Se vislumbra la idea de ingeniero (software). Hacia una ingeniera (1985-Actual). Aceptando una consolidacin de las tecnologas de software, la mejora viene de la mano de un mejor conocimiento de los procesos con el fin de incrementar la calidad de los productos. Aparece una gestin sofisticada del proceso de desarrollo ligada al control de riesgos y a la madurez de los procesos.

Caractersticas relevantes de un sistema de software

Con el fin de clasificar a los sistemas de software seleccionamos un conjunto de caractersticas relevantes de los sistemas de software complejos. No queremos con ello decir que estas caractersticas sean fundamentales en todos los sistemas de software; probablemente, para algunos de ellos constituyan un elemento bsico en su desarrollo y mantenimiento, y para otros no lo sean.

Las caractersticas consideradas son las siguientes:

Caractersticas relevantes de un sistema de software

Tamao. Que el tamao condiciona el desarrollo de un sistema es algo que intuitivamente todos podemos suponer. Ms difcil es acotar el concepto de tamao y caracterizar en funcin de l los sistemas actuales. La primera decisin reside en determinar a qu se aplica el concepto de tamao. Durante mucho tiempo (y an hoy) este concepto se aplica al cdigo fuente (escrito en un lenguaje de programacin utilizado por el implementador). Se han empleado diversas medidas basadas en contar las lneas de cdigo fuente para estimar costes de desarrollo (esfuerzo requerido). El tamao final del sistema de software ha sido tambin empleado para conocer los requisitos sobre la infraestructura de ejecucin y/o comunicacin y, por comparacin con otros sistemas, aspectos de prestaciones en tiempos de ejecucin.

Caractersticas relevantes de un sistema de software

Vida til. An hoy da, muchos sistemas crticos en la Banca, Defensa, etc. fueron concebidos en una poca en la que muchas de las tcnicas actuales no existan o no eran ampliamente utilizadas. Es comn encontrarse con sistemas con ms de 25 aos de vida til. Obviamente, en ese periodo han sufrido un sinfn de modificaciones, adiciones y sustituciones de funciones... pero ah siguen. Que los sistemas tengan larga vida hace que un porcentaje apreciable del esfuerzo y costes se desplacen desde las fases de desarrollo a las de mantenimiento o evolucin del mismo. El concepto de evolucin no debe entenderse como algo negativo. Por el contrario, es un elemento bsico para asegurar su utilidad futura. Como consecuencia, la evolucin debe considerarse desde el principio del desarrollo. Tngase presente que no es sencillo controlar la evolucin de un sistema de software que no ha sido diseado para ello.

Caractersticas relevantes de un sistema de software

Informacin manipulada. Todo sistema de software necesita manipular informacin durante su ejecucin; por informacin entendemos datos, texto, imgenes, etc. Que deban ser procesadas o transmitidas. En alguno de ellos, no obstante, el volumen de informacin necesario obliga a que la atencin en el desarrollo se centre en su captura, almacenamiento estructurado, procesamiento y actualizacin. Los sistemas complejos requieren que su arquitectura interna refleje la estructura de estos datos y los procedimientos de gestin de los mismos. La gestin de la informacin no slo implica que un mdulo (parte del sistema) los mantenga sino que puede ser compartida entre varios, estar replicada y/o distribuida en varios emplazamientos dnde el sistema se ejecuta y casi siempre requiere de paquetes software especializado.

Caractersticas relevantes de un sistema de software

Estructura interna. Un sistema de software posee una estructura interna en el que las funciones a realizar se agrupan en mdulos u objetos con cierta interaccin entre ellos. Los sistemas de software complejos suelen estar compuestos por mdulos que operan concurrentemente entre s y, en muchos casos, sus mdulos se ejecutan en lugares geogrficamente distantes. Gran parte de los lenguajes de programacin clsicos (estructurados) poseen un conjunto de construcciones cuya finalidad es determinar el orden de ejecucin de las instrucciones. Todos ellos comparten la idea de que en cada momento slo se ejecuta una instruccin. Esta restriccin se ha trasladado a las tcnicas de diseo limitando el modelado.

La utilidad de un sistema de software

La utilidad es visible al usuario que lo adquiere o encarga, los parmetros tcnicos slo lo son al diseador an en el caso de que hayan surgido como respuesta a necesidades expresadas por el usuario. En funcin de su utilidad, distinguimos tres tipos de sistemas de software: Software de base. Es todo aquel sistema de software que proporciona una plataforma de ejecucin (como un sistema operativo o una interfaz de usuario o un compilador) para que otros programas puedan desarrollarse o ejecutarse. Su utilidad no est ligada directamente a una aplicacin definida por un usuario sino a otro programa. Suelen formar parte de la infraestructura de ejecucin. Un ejemplo tpico es el sistema operativo.

La utilidad de un sistema de software

Software de aplicacin. Responde a una necesidad de un usuario en un determinado contexto que se resuelve mediante un paquete de aplicacin. El usuario interacciona directamente con el software de aplicacin del que obtiene el servicio deseado. Se distingue entre software de aplicacin horizontal cuando responde a necesidades genricas manifestadas por multitud de usuarios (por ejemplo, un procesador de textos) y software de aplicacin vertical cuando la necesidad responde a un tipo de usuario concreto o a un mercado sectorial restringido (por ejemplo, un sistema de gestin de hospitales).

La utilidad de un sistema de software

Software empotrado. Hasta ahora hemos considerado el sistema de software ejecutndose potencialmente sobre una mquina genrica. En muchos casos no es posible aislar el sistema de la mquina sobre la que se ejecuta. De hecho, no hay interaccin externa sino que se realiza sobre un hardware en el que est empotrado o embebido. El sistema de software considerado forma parte de un sistema de software/hardware mayor sobre el que acta. No hay interaccin con el exterior. Un ejemplo de software empotrado lo tenemos en los sistemas de control automtico de vuelo disponibles en muchas aeronaves.

Modelos de desarrollo de software

Un ingeniero civil supervisando la construccin de un edificio para asegurar que sea estable y de acuerdo a los requerimientos de los clientes. Un ingeniero o varios ingenieros escribiendo procedimientos de diversa complejidad para desarrollar sistemas de software (sw) El software de gran envergadura requiere de mtodos, procedimientos y herramientas Metodologas inapropiadas incrementan costos y el consumo extra de tiempo.

Modelos y Abstraccin

Modelo. Es una abstraccin de algo que se extrae de la realidad Enfatiza las caractersticas mas interesantes Omite los detalles no esenciales. Abstraccin. Es una capacidad humana Es un examen selectivo de ciertos detalles de un problema Puede haber muchas abstracciones para una misma cosa. Para obtener una abstraccin es imprescindible un objetivo Todas las abstracciones son incompletas e imprecisas

Nos permiten limitar el universo a estudiar

Por que modelamos?

Para probar entidades fsicas inmanejables

Para comunicarnos Para visualizar una idea y depurarla Para reducir la complejidad y los costos

Pruebas y comunicacin

Pruebas Muchas veces es imposible construir algo para probar

Con un modelo es mas factible controlar las pruebas

Se pueden realizar pruebas tantas veces como se quiera Comunicacion Los modelos permiten utilizar un lenguaje comn Formalizan la comunicacin entre pares o entre niveles de una organizacin Sirven como documentacin de las ideas

Visualizacin y Reduccin de Costos

Visualizacin Los modelos permiten corregir defectos antes de construir el producto

Es posible descubrir detalles que se pasaron por alto en el planteo orginal de la idea.
Reduccin de Costos Los modelos son mas baratos de construir Se pueden desechar sin problemas Son mas simples que el producto final

Proceso de Software

Proceso: Serie de operaciones usadas en la creacin de un producto.

Proceso de Software: Conjunto de tareas que tienen que ser realizadas para producir un producto de software de alta calidad (Desarrollo de software). Proceso de Software: Proceso que se sigue para construir un producto de software desde la concepcin de una idea, hasta la entrega y el retiro final del sistema.

Qu es un proceso de software?

Un conjunto de actividades cuya meta es el desarrollo o evolucin del software.

Las actividades fundamentales en todos los procesos de software son:

- Especificacin - lo que el sistema debe hacer y las restricciones de su desarrollo. - Desarrollo- produccin del sistema de software - Validacin comprobar que el software es lo que el cliente requiere - Evolucin cambiar el software en respuesta a las peticiones de cambio

Modelos de Desarrollo de Software

Actividades en el proceso de desarrollo de software.

Anlisis de Requerimientos
Especificacin Diseo Programacin Integracin y Gestin de Configuraciones Validacin y Verificacin Prototipaje

Las actividades en el proceso de desarrollo de software

se relacionan segn determinados: modelos

se desarrollan aplicando un:

mtodo El mtodo se fundamenta en: principios El mtodo puede ser soportado por: herramientas

Actividades usuales

Acerca de las actividades

Se describen en forma independiente, indicando datos, rol y resultados Utiliza y produce documentos (Artefactos)

Se relacionan e interactan de diferentes maneras conformando distintos procesos de desarrollo de software (modelos)
De acuerdo al modelo una actividad puede jugar un rol preponderante o incluso pudiera no existir

Modelos de desarrollo

Define la estructura de un proceso de desarrollo racional y controlable No existe un modelo universal

Los modelos no son rgidos

Son una gua respecto al orden en que deben adelantarse las actividades Se basa en el reconocimiento que el software tiene un ciclo de vida.

Ciclo de Vida del Software

Es un modelo de las actividades que se llevan a cabo durante la construccin de software

Sirve como gua para planificar las actividades a llevar a cabo en un proyecto
Facilitan el monitoreo del proyecto Describe las fases principales de desarrollo de software.

Ayuda a administrar el progreso del desarrollo

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

Ciclo de vida del software

Ciclo de vida del software

Obsolescencia del producto

Modelos de desarrollo

Secuencial Lineal Cascada (clsico)

RAD (Desarrollo Rpido de Aplicacin)

Evolutivo Incrementa ...... Espiral Basado en reutilizacin Basado en transformaciones

Ciclo de vida en Cascada

Conocido como modelo secuencial lineal Encadenamiento secuencial de las actividades

Cada etapa produce documentos que son la entrada a la siguiente

Para desarrollar una etapa debe concluirse la anterior El modificado La idea bsica es que la salida de cada etapa es la entrada de la etapa siguiente Cada etapa puede tener subetapas Hay tareas comunes en todas las etapas (documentacin, verificacin)

Puede ser modificado.

Ciclo de vida en Cascada

Requerimientos

Diseo

Codificacin y Test Unitario Integracin Operacin y Mantenimiento

Ciclo de vida en Cascada

Los proyectos raramente siguen el flujo secuencial que el modelo propone. A menudo es difcil para el cliente poder especificar todos los requerimientos explcitamente. Una versin funcional del sistema no estar disponible hasta tarde en la duracin del desarrollo.

Modelo de Desarrollo Rpido de Aplicacin - RAD

RAD: Rapid Application Development.

Modelo secuencial lineal con tiempos cortos de desarrollo

Varios equipos participando en el desarrollo Cada equipo maneja una parte del sistema Uso de herramientas de pruebas automatizadas En cada etapa de liberacin, los productos parciales son integrados, probados y liberados

Modelo de Desarrollo Rpido de Aplicacin - RAD

Desventajas: Para ciclos de desarrollo extremadamente cortos:

Requerimientos bien entendidos y alcance de proyecto restringido.

Se requiere mltiples desarrolladores. Compromiso de desarrolladores y clientes para un tiempo de entrega corto. No adecuado para sistemas que no puedan ser mantenidos adecuadamente. No se enfoca en detalles minuciosos.

Modelo Espiral

Boehm incluy el anlisis de riesgos en los modelos, combinando el modelo Cascada con el Prototipado. El modelo Espiral enfatiza la administracin y el tratamiento de riesgos Utiliza el modelo Cascada para cada etapa Conducido por el riesgo. Intenta eliminar errores en las fases tempranas.

La reevaluacin despus de cada fase permite cambiar enfoques

La focalizacin en los objetivos y limitaciones ayuda a asegurar la calidad.

Modelo Espiral

Planificacin

Anlisis de Riesgos

Comunicacin con el Cliente Ingeniera

Evaluacin del Cliente

Construccin

Ciclo de Vida de Requerimientos

Los requerimientos pueden cambiar El Prototipado es una buena idea

La idea es capturar por retroalimentacin los requerimientos, usando prototipos

No deben utilizarse los prototipos como producto final

Prototipado

Requ.

Evaluacin

Diseo

Prototipo

Prod. Final

Ciclo de Vida de Requerimientos

El prototipo trata de minimizar los cambios en los requerimientos, mientras que el diseo modular (incremental, en funcionalidades) trata de minimizar el impacto de los cambios en los requerimientos.

Modelo Basado en reutilizacin

Modelo Basado en reutilizacin

Ventajas: Incremento en la fiabilidad.

Reduccin en el riesgo
Utilizacin efectiva de especialistas Conformidad con los estndares Desarrollo acelerado, quizs 70% como indican algunos estudios. Desventajas: Falta de apoyo de las herramientas Sndrome de aqu no se ha inventado Costo de encontrar, entender y adaptar componentes reutilizables

Seleccin del ciclo de vida y Perfiles para el proyecto

Todos los modelos con compatibles entre s Normalmente se realizan ajustes que dependen del proyecto Hay criterios que permiten definir el perfil de un proyecto, y seleccionar luego el ciclo de vida adecuado. Madurez de la aplicacin con respecto a los requerimientos Complejidad del problema y de la solucin. Utilidad de la funcionalidad rpida Frecuencias y magnitudes esperadas de cambios de requerimientos. Financiamiento disponible, y su perfil como una funcin del tiempo.

Acceso de los desarrolladores a los usuarios.

Certeza de requerimientos conocidos.

Algunos criterios ms

Tolerancia a los riesgos. Planes y presupuestos crticos

Grado de lentitud de construccin dentro de los planes y presupuestos

Combinacin de ciclos de vida El software es evolutivo, no tiene sentido encerrarse en un nico modelo Los modelos de ciclo de vida son complementarios, no excluyentes La naturaleza del proyecto debe dictar el mtodo a elegir.

Qu es CASE (Ingeniera de software asistida por computadora)?

Sistemas de software que estn destinados a proporcionar soporte automtico para las actividades de proceso de software. Los sistemas CASE se utilizan frecuentemente como apoyo del mtodo. CASE de alto nivel
- Herramientas de apoyo a las actividades de proceso iniciales de requerimientos y diseo.

CASE de bajo nivel

- Herramientas para apoyar actividades posteriores como la programacin, depuracin y prueba.

Enterprise Architect Herramienta a utilizar

Proceso Unificado de Desarrollo de Software

Proceso Unificado de Desarrollo de Software

Necesidad en el desarrollo de software

Establecer una gua para ordenar las actividades de un equipo Dirigir las tareas de cada desarrollador por separado y del equipo como un todo Ofrecer criterios para el control y medicin de la calidad de los productos y actividades del proyecto Especificar los artefactos a desarrollar

Seis mejores Prcticas

1.Desarrollo Iterativo 2.Administrar Requerimientos

3.Usar Arquitecturas basadas en Componentes

4.Modelado Visual (UML) 5.Verificar Continuamente la Calidad 6.Administrar el Cambio

Qu es el Proceso Unificado?

Define: Quin est haciendo,

Qu es lo que est haciendo,

Cundo debe hacerlo, y Cmo obtener un cierto objetivo.
trabajadores artefactos fases del proceso encadenamiento de actividades

Iterativo e incremental

Permite desarrollar un sistema a travs de refinamientos sucesivos e incorporacin de nuevas funcionalidades, creando una solucin efectiva, en mltiples iteraciones. Alto nivel de reuso Aprendizaje del grupo del proyecto durante el desarrollo del software Adaptacin a requerimientos cambiantes

Mitigacin de los riesgos y realizacin de las pruebas en etapas tempranas del desarrollo del software.

Basado en Casos de Usos

Casos de Uso? Permiten una representacin grfica adecuada de las funcionalidades requeridas por usuarios, clientes. Guan el proceso de desarrollo del software...

Centrado en la Arquitectura

Qu es la Arquitectura de un Sistema? La descripcin del Sistema a travs de vistas utilizando diagramas y modelos Proyeccin de la organizacin y estructura de un sistema enfocndose en aspectos particulares Con qu notacin?

Centrado en la Arquitectura

Por qu es importante? Permite una comunicacin efectiva entre las personas involucradas (diseador, desarrollador). Promueve el reuso del software. Permite la prueba individual e integracin gradual de los componentes. Permite crear sistemas flexibles y tolerantes a cambios.

Estructura Esttica

Fases del Ciclo de Vida

Ciclo de vida

Fases e Iteraciones

Una iteracin es una secuencia de actividades con un plan establecido y criterio de evaluacin, la cual resulta en una versin del producto.

Iteraciones y Disciplinas

Algunos Artefactos

Iteraciones y Disciplinas

Iteraciones y Disciplinas

INGENIERA DE REQUERIMIENTOS

INGENIERA DE REQUERIMIENTOS*

Entender los requerimientos de una solucin basada en software es una de las tareas mas difciles para un(a) Ing. de software. Como otras actividades de Ing. de Sw, sta debe adaptarse a las necesidades del proceso, proyecto, producto y gente que hace el software. La Ing. de Requerimientos provee de un mecanismo apropiado para entender que quiere el consumidor, analizar sus necesidades, valorar la factibilidad de construccin, negociar una solucin razonable, especificar de manera no ambigua una solucin, validar la especificacin y administrar los requerimientos conforme se transforman. *Referencia: captulo 7 libro de texto (Pressman 2005)

Qu es un requerimiento?

Es una caracterstica que un sistema debe tener para cubrir alguna de las necesidades que lo motivan Las necesidades que motivan un sistema son generalmente complejas e involucran a mucha gente, o a otros sistemas

Tipos de requerimientos

Requerimientos Funcionales. Requerimientos NO Funcionales

Requerimientos del Proceso

Requerimientos Funcionales

Expresan la funcionalidad necesaria para cubrir la necesidad Establecen el funcionamiento del sistema sobre la base de los problemas que ste debera resolver Tambin son conocidos como capacidades del sistema

Requerimientos NO funcionales

Actan restringiendo la solucin a un problema Limitan la forma en que sern implementados los requerimientos funcionales Deben ser cuantificables, y pueden categorizarse

Categorizacin

Portabilidad Confiabilidad

Etapa de Desarrollo

Eficiencia
Ingeniera Humana

Verificabilidad Etapa de Mantenimiento Entendimiento

Modificabilidad

Requerimientos del Proceso

Actan sobre el proceso que se lleva a cabo para desarrollar la solucin Pueden ser impuestos por la organizacin, por los clientes, por terceras partes o por el mercado Tambin son conocidos como parmetros del proceso

Cmo es un requerimiento?

Claros Completos

No ambiguos
Validables Cuantificables

Para tener en cuenta

Los requerimientos de un sistema son tpicamente una compleja combinacin de requerimientos de diversas personas en diferentes niveles de la organizacin, y del ambiente en que el sistema funcionar

Tareas de la Ing. de Requerimientos

- Iniciacin (Inception) - Obtencin (Elicitation) - Elaboracin - Negociacin - Especificacin - Validacin (Validation) - Administracin

Algunas de estas funciones pueden ocurrir en paralelo y ajustarse a las necesidades del proyecto

Iniciacin

Como se empieza un proyecto? Algunas veces inicia por conversaciones informales, otras de manera mas formal; normalmente como resultado de una necesidad importante En esta parte, los ingenieros de software realizan preguntas libres de contexto (generales), para establecer un entendimiento bsico del problema, determinar las personas que quieren una solucin, la naturaleza de la solucin, y la efectividad de las colaboraciones y comunicaciones preeliminares que se generan entre el consumidor y el desarrollador

Obtencin de Requerimientos

Se refiere a definir formalmente los requerimientos de la solucin. Es difcil porque como ya se ha visto:

- Hay problemas de definicin de alcances

- Hay problemas de entendimiento entre los involucrados - Hay problemas de volatilidad (los requerimientos cambian con el tiempo)

Elaboracin

Esta actividad expande y refina la informacin obtenida en la tarea de iniciacin

Se enfoca en realizar modelos tcnicos refinados de las funciones del software, caractersticas y limitantes.
Es bsicamente una funcin de modelado. Se conduce a travs de la definicin de escenarios del usuario que describen la interaccin del usuario final con el sistema Se define el dominio del problema desde varios puntos de vista: informacin, funciones y comportamiento

Negociacin

Los usuarios y consumidores normalmente piden mas de lo que se puede hacer con los recursos con que se cuenta.

Casi siempre diferentes involucrados (stakeholders) piden cosas diferentes, por lo que hay que conciliar intereses a travs de negociaciones. Hay varias maneras para negociar, y depende de la cultura de la organizacin y tamao del proyecto

Especificacin

Especificacin significa diferentes cosas para diferentes personas en el rea de Ing. de software.

Este es el producto de trabajo final de la ingeniera de requerimientos.

Sirve como base para actividades subsecuentes.

Describe la funcin y desempeo de un sistema y las restriccin que tiene.

Hay muchas tcnicas para escribir especificaciones: diagramas, narraciones en prosa, modelos matemticos, dibujos, etc.

Validacin

El producto generado por la ingeniera de requerimientos debe ser evaluado en trminos de congruencia y calidad. Se debe asegurar que la especificacin concuerda con las expectativas del usuario y que no es ambigua. Deben detectarse y corregirse errores, omisiones e inconsistencias con respecto a los estndares establecidos en el proyecto. El mecanismo comn de validacin es la revisin tcnica formal.

Administracin de requerimientos

Actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requerimientos y cambios que ocurren en ellos a travs de todo el proceso de desarrollo. La administracin empieza con la identificacin de cada requerimiento. Posteriormente se generan tablas que permitirn darles seguimiento. Algunas de stas son: - Tablas de caractersticas

- Tablas de fuentes
- Tablas de dependencias - Tablas de subsistemas - Tablas de interfaces

Descripcin detallada de las Tareas de la Ing. de Requerimientos

- Iniciacin (Inception)
- Obtencin (Elicitation) - Elaboracin - Negociacin

- Especificacin
- Validacin (Validation) - Administracin

Pasos del proceso de Iniciacin.

1. Identificacin de involucrados (Stakeholders). 2. Reconocimiento de diferentes puntos de vista. 3. Desarrollo de un ambiente colaborativo. Implica identificar puntos en comn, reas de conflicto e inconsistencias. 4. Aplicacin de preguntas inciales.

Algunas preguntas Iniciales tpicas

Primeras
Quin est detrs de la requisicin de este trabajo? Quin usar la solucin ? Cual es el beneficio econmico de una solucin exitosa? Hay otras fuentes para obtener la solucin buscada que se necesitarn? Qu sera una buena salida para generar una solucin eficiente? Que problemas aparecern con esta solucin? Podra describirme el medio ambiente en que la solucin funcionar? Qu aspectos de desempeo o limitaciones afectan la solucin?

Siguientes:
-

Algunas preguntas tpicas (2)

Siguientes:

- Es Usted la persona correcta a preguntarle? Son sus respuestas oficiales? - Considera mis preguntas relevantes al problema que Usted tiene? - Le estoy preguntando demasiado? - Puede alguien mas darme informacin adicional ?

Caractersticas de un(a) buen(a) Ing. de Requerimientos

Habilidad para captar conceptos abstractos sintetizndolos y

reorganizndolos en divisiones lgicas.

Habilidad para obtener hechos importantes de situaciones confusas. Habilidad para entender el medio ambiente.

Habilidad para comunicarse bien en forma verbal y escrita.

Habilidad para "ver el bosque a travs de las hojas".

Generacin de las Necesidades del Cliente

Herramientas para obtener informacin de las necesidades del Cliente:

- Cuestionarios
- Entrevistas - Estudio de campo
- Revisin de documentos en la base de datos de conocimiento de la organizacin

- Autoaprendizaje

Cuestionarios
Los cuestionarios son tiles especialmente cuando hay una gran cantidad de usuarios finales.

El diseo de un cuestionario requiere de tiempo y dedicacin, ya que un cuestionario deficiente produce frustracin y prdida de inters en el usuario. El cuestionario debe ser fcil de procesar En caso de que el cuestionario no se aplique a todos los usuarios, se debe seleccionar correctamente al grupo que realice el cuestionario.

Entrevistas

La entrevista es una herramienta muy til para obtener informacin.

Se puede llevar a cabo en cualquier nivel dentro de la organizacin, desde el presidente hasta el obrero en la lnea de ensamble.
La entrevista debe prepararse adecuadamente.

Consejos para Realizar una Entrevista

1) Preparacin de la entrevista: a) b) Buscar el apoyo del gerente de departamento o jefe donde se llevar a cabo la entrevista. Preparar la entrevista para un tiempo determinado, y drselo a conocer al entrevistado. Identificar de antemano la posicin del entrevistado en la organizacin, sus responsabilidades y actividades. Acordar de antemano la hora y el lugar de la entrevista. Evitar las interrupciones. Preparar el contenido de la entrevista: temas, preguntas etc.

c)
d) e)

Consejos Para Realizar Una Entrevista

(continuacin)
2) Conduciendo la entrevista: a) b) c) d) e) f) g) h) i) j) Presentarse al entrevistado y presentar al proyecto en el que se trabaja. Asegurarse de se entendieron correctamente las responsabilidades del entrevistado. Realizar preguntas de la forma: "tengo entendido que... ". Estudiar el mtodo de decisin del entrevistado. Evitar palabras tcnicas o rebuscadas. Darse una idea del "sentimiento" del entrevistado con respecto al sistema. Escuchar al entrevistado. Preguntar al entrevistado sobre algunas ideas propias que pudieron olvidarse. Al final de la entrevista resumir las conclusiones y escribir una bitcora. No tomar demasiadas notas. Grabar la entrevista la mayora de las veces resulta anti-productivo.

Algunos Problemas Durante las Entrevistas

- Respuestas falsas por temor a admitir ignorancia
- El usuario tiende a decir lo que el entrevistador quiere or - Boicoteo de informacin - Actitud cerrada hacia cambios - Pesimismo total - Desvo del objetivo fundamental hacia otros problemas de la organizacin

Tareas de la Ing. de Requerimientos

- Iniciacin (Inception)

- Obtencin (Elicitation)
- Elaboracin - Negociacin

- Especificacin
- Validacin (Validation) - Administracin

Continuando con el anlisis...

Segn [Larman 99] las principales actividades asociadas al anlisis son:

- Definir los casos de uso - Definir el modelo conceptual - Definir los diagramas de colaboracin

- Definir diagramas de diseo de clases

Obtencin de Requerimientos

Incluye juntas colaborativas de definicin, despliegue de funciones y descripcin de escenarios Los productos que genera son: - Una declaracin de necesidades y factibilidades - Una declaracin delimitada del alcance del sistema o producto - Una lista de consumidores, usuarios y otros involucrados (stakeholders) que participaron en la definicin del documento - Una descripcin del medio ambiente tcnico del sistema - Una lista de requerimientos, de preferencia organizados por funcin, y las restricciones de dominio que los afectan - Un conjunto de escenarios de uso que dan idea del uso del producto en diferentes condiciones operativas - Prototipos desarrollados

Desarrollo de casos de uso

Un caso de uso describe el comportamiento del sistema en condiciones diferentes, as como la respuesta del sistema a las requisiciones de uno o mas stakeholders El primer paso es definir por escrito los actores que estarn involucrados en el sistema. Los actores son personas o dispositivos que usan el producto dentro de un contexto o funcin. Representan los roles de las personas o dispositivos De manera formal un actor es cualquier cosa que se comunica con el sistema o producto y que es externa a ste. Cada actor puede tener uno o mas objetivos cuando usa el sistema. Se pueden identificar actores primarios, aquellos que interactan directamente con el sistema, y secundarios, aquellos que de alguna manera dan soporte al sistema, a fin de que lo primarios puedan realizar su trabajo

Desarrollo de casos de uso (2)

Una vez que se han identificado los actores, lo siguiente es desarrollar el caso de uso. Jacobson sugiere hacer las siguientes preguntas:
- Quienes son los actores primarios y secundarios? - Cuales son las metas de los actores? - Que precondiciones deben existir antes de que la historia empiece? - Que tareas principales son realizadas por el actor? - Que excepciones se pueden considerar con respecto a la descripcin de la historia?

Desarrollo de casos de uso (2)

- Que variaciones en las interacciones del actor son posibles?

- Qu sistemas de informacin adquirir, producir o cambiar el actor?

- El actor tendr que informar al sistema acerca de cambios en el medio ambiente externo? - Que informacin desea el usuario del sistema? - Desea el actor ser informado acera de cambios inesperados?

Smbolos usados en los Diagrama de Casos de Uso de UML

Caso de Uso

Ejemplo de un Diagrama de Casos de Uso1

1.

Sistema de control de registro para maquinas tragamonedas. Alvarez, V. et al.Otoo 04

Informacin principal a Incluir en la descripcin de un escenario

Nombre del caso de uso Actor principal Objetivo Pre-condiciones Iniciador del caso de uso Descripcin del Escenario Excepciones Prioridades Disponibilidad Frecuencia de Uso Canales de comunicacin con actores Canales con actores secundarios Puntos an no resueltos

Cada ovalo en el diagrama de casos de uso debe ser descrito detalladamente, a travs de un escenario.