Ingeniera de Software Resumen 2do parcial terico

CASOS DE USO Proceso de modelado de las funcionalidades del sistema en trminos de los eventos que interactan entre los usuarios y el sistema. Un CU debe representar una funcionalidad concreta del sistema. Su origen es el modelado orientado a objetos de Jacobson. El uso de CU facilita y alienta la participacin de los usuarios. Beneficios: herramienta para capturar requerimientos funcionales descompone el alcance del sistema en piezas manejables medio de comunicacin con los usuarios (lenguaje comn y fcil de entender) permite estimar el alcance del proyecto y el esfuerzo a realizar define una lnea base para la definicin de los planes de prueba define una lnea base para toda la documentacin del sistema proporciona una herramienta para el seguimiento de los requisitos Elementos del CU 1) Diagramas de CU: ilustra las interacciones entre sistema y actores a. Caso de Uso: representa un objetivo (funcionalidad) individual del sistema y describe la secuencia de actividades y de interacciones para alcanzarlo. Para que el CU sea considerado un requerimiento debe estar acompaado de su respectivo escenario b. Actor: inicia una actividad en el sistema i. Representa un papel desempeado por un usuario que interacta (un rol) ii. Puede ser una persona, sistema externo o dispositivo externo que emita un evento (reloj, sensor) c. Relaciones i. Asociacin: relacin entre un actor y un CU en el que interactan entre s ii. Extensin: un CU extiende la funcionalidad de otro CU. Un CU puede tener muchos CU extensiones. Los CU extensiones slo son iniciados por un CU. iii. Uso: reduce la redundancia entre dos o ms CU al combinar pasos comunes de los CU. Deben ser accedidos desde dos o ms CU. iv. Dependencia: relacin entre CU que indica que un CU no puede realizarse hasta que se haya realizado otro. v. Herencia: relacin entre actores donde un actor hereda las funcionalidades de uno o varios actores (user lectura, user registrado, user annimo)

2) Escenario (narracin del CU): describe la interaccin entre el actor y el sistema para realizar la funcionalidad a. La descripcin de los pasos debe contener ms de un paso, para representar la interaccin entre los componentes. b. El uso de condicionales en el curso normal, es limitado a la invocacin de excepciones, ya que este flujo representa la ejecucin del CU sin alteraciones. c. Las pre-condiciones no deben representarse en los cursos alternativos ya que no se sabe si va a ocurrir. Proceso de modelado 1. Identificar a los actores: debern nombrarse con un sustantivo a. Buscar en: 1

Ingeniera de Software Resumen 2do parcial terico

i. Diagrama de contexto que identifique el alcance del sistema ii. Documentacin o manuales existentes iii. Minutas de reunin iv. Documentos de requerimientos b. Responder a: i. Quin o qu proporciona las entradas al sistema? ii. Quin o qu recibe las salidas? iii. Se requieren interfaces con otros sistemas? iv. Quin mantendr la informacin en el sistema? 2. Identificar los CU para los requerimientos a. Principales tareas del actor b. Que informacin necesita el actor c. Que informacin proporciona el actor d. Ver si el sistema necesita informar al actor de cambios o eventos ocurridos e. Ver si el actor necesita informar al sistema de eventos o cambios ocurridos 3. Construir el diagrama 4. Realizar los escenarios HISTORIAS DE USUARIOS Es una representacin de un requisito de software escrito en una o dos frases utilizando el lenguaje comn del usuario. Debe ser breve (no ms que una nota adhesiva). Son una forma rpida de administrar los requisitos de usuarios sin tener que elaborar documentos formales y sin requerir de mucho tiempo para administrarlos. Permiten responder rpidamente a los requisitos cambiantes. Al momento de implementar las historias, los desarrolladores deben tener la posibilidad de discutirlas con los clientes. Se espera que la estimacin de tiempo de cada HU se site entre unas 10 horas y un par de semanas. Si es mayor, indica que es compleja y la HU debe dividirse en varias historias. Debe responder a tres preguntas: 1) Quin se beneficia? 2) Qu se quiere? 3) Cul es el beneficio? Como (rol) quiero (algo) para poder (beneficio) Ej.: -Como usuario registrado quiero loguearme para poder usar la app -Como secretaria quiero poder imprimir un listado de turnos y guardar la informacin de los mismos Caractersticas Independientes unas de otras: de ser necesario, combinar las HU dependientes. Negociables: la discusin con los usuarios debe permitir esclarecer su alcance y ste debe dejarse explcito bajo la forma de pruebas de validacin. Valoradas por los clientes o usuarios: cada HU debe ser importante para ellos mas que para el desarrollador. Estimables: un resultado de la discusin de una HU es la estimacin del tiempo que tomar completarla. Esto permite estimar el tiempo total del proyecto. Pequeas: las historias muy largas son difciles de estimar e imponen restricciones sobre la planificacin de un desarrollo iterativo. Se recomienda consolidar historias muy cortas en una sola historia.

Ingeniera de Software Resumen 2do parcial terico

Verificables: las HU cubren requerimientos funcionales, y por ende son verificables. Cuando sea posible, la verificacin debe automatizarse.

Beneficios Al ser breve, representa requisitos que pueden implementarse rpidamente Necesitan poco mantenimiento Mantienen una relacin cercana con el cliente Permite dividir los proyectos en pequeas entregas Permite estimar fcilmente el esfuerzo de desarrollo Es ideal para proyectos con requisitos voltiles o no muy claros Limitaciones Sin pruebas de validacin pueden quedar abiertas a distintas interpretaciones Se requiere un contacto permanente con el cliente, lo que es difcil y costoso Difcil de escalar a proyectos granes Requiere desarrolladores muy competentes DIAGRAMA DE FLUJO DE DATOS (DFD) Anlisis Estructurado Es una herramienta que permite visualizar un sistema como una red de procesos funcionales, conectados entre s por conductos y almacenamientos de datos. Representa la transformacin de entradas a salidas. Procesos: se representan por crculos o burbujas; son las funciones individuales que ejecuta el sistema. Las funciones transforman entradas en salidas. Flujos: se representan con flechas continuas; son la informacin que los procesos necesitan como entrada o producen como salida. Almacenamientos: se representan con lneas dobles; son los datos permanentes del sistema. Al concretarse el diseo, pasarn a ser la base de datos y archivos. Entidades Externas: muestran productores o consumidores de informacin que residen fuera de los lmites del sistema. Diccionario de Datos: listado organizado de todos los datos pertinentes al sistema. Tiene que tener definidas estructuras, almacenes y flujos de datos. Definicin sin ambigedad de los datos y elementos del sistema Permite revisar consistencia Representa el contenido de la informacin Define el significado de los flujos y almacenes Un dato debe contener tipo, nombre y descripcin Modelo Esencial Debe indicarse lo que el sistema debe hacer para satisfacer los requerimientos del usuario, con una mnima (en lo posible nula) explicacin de cmo lo hace Evitar el detalle de cualquier restriccin o aspecto derivado de la implementacin 3

Ingeniera de Software Resumen 2do parcial terico

Pensar el modelo esencial suponiendo que se dispone de tecnologa perfecta, lo que permite que sobreviva a cambios tecnolgicos

Componentes del Modelo Esencial 1) Modelo ambiental: define las interfaces entre el sistema y el ambiente donde se ejecuta. Es lo primero y ms importante. a. Declaracin de propsitos: en forma breve debe indicarse el objetivo del sistema b. Diagrama de contexto: es un caso especial de DFD donde el sistema se representa en una sola burbuja vinculada con las entidades externas y los almacenes externos c. Lista de acontecimientos: se trata de un listado de eventos a los que el sistema debe responder. i. Flujo (F): llega algn dato al sistema ii. Temporal (T): comienza con la llegada de un momento dado en el tiempo iii. Control (C) 2) Modelo de comportamiento: es la representacin del comportamiento final que el sistema debe tener para manejar con xito el ambiente, dentro de las especificaciones requeridas por el usuario. Un modelo preliminar contiene: a. DFD: diagrama preliminar de flujo de datos del sistema b. DER: diagrama preliminar de entidad-relacin c. DD: primera versin del diccionario de datos d. DTE: un diagrama de transicin de estados El DFD admite refinamiento en niveles ascendente o descendente. El modelo de contexto sera el nivel 0. En un enfoque descendente, cada nivel debe aportar ms informacin y detalles sobre alguna parte definida en el nivel anterior. Anlisis estructurado en tiempo real DIAGRAMA DE FLUJO DE CONTROL (DFC) Responden al mundo real, en un tiempo prefijado. En aplicaciones de tiempo real, el sistema debe controlar la informacin continua en el tiempo, generada por algn proceso del mundo real. La notacin del flujo de datos convencional no hace distinciones entre datos discretos y datos continuos en el tiempo. Para representar el flujo continuo en el tiempo, se usa la flecha de dos cabezas, mientras que el flujo de datos discreto se representa con una flecha de una sola cabeza. DFC Es una ampliacin del DFD, orientada al flujo continuo de informacin. El DFC contiene los mismos procesos que el DFD, pero muestra el flujo de control en lugar de datos. Muchas aplicaciones de software son dependientes del tiempo y procesan mas informacin orientada al control que a los datos. Ward y Mellor introducen: PROCESOS DE CONTROL: se representan con burbujas punteadas; son las funciones que coordinan o sincronizan FLUJOS DE CONTROL: se representan con lneas punteadas; son las seales o interrupciones FLUJOS DE DATOS CONTINUOS: son los datos que ingresan de forma continua ALMACENAMIENTOS DE CONTROL: se representan mediante lneas dobles punteadas; son los datos permanentes del sistema. GoldSmith introduce: Flujo de evento: acarrea informacin en el sistema. No tiene comportamiento, sino que sus caractersticas son definidas por lo que acarrea. Puede ser continuo o discreto, y est determinado por lo que mueve a lo largo del flujo: o Datos o Eventos o Material/Energa Proceso de Control: muestra control sobre los flujos de datos y transforma eventos de entrada en eventos de salida. Almacenes de control: es un deposito de elementos que se guardan para ser usados por uno o ms proceso. Al igual que los flujos, los almacenes no tienen comportamiento. 4

Ingeniera de Software Resumen 2do parcial terico

MODELO DE PROCESO Un proceso se puede pensar a un conjunto ordenado de tareas, una secuencia de pasos para realizar algo. Caractersticas Establece todas las actividades Utiliza recursos, est sujeto a restricciones y genera productos intermedios y finales. Puede estar compuesto por subprocesos. Cada actividad tiene entradas y salidas definidas. Las actividades se organizan en una secuencia. Existen principios que orientan sobre las metas de cada actividad. Las restricciones pueden aplicarse a una actividad, recurso o producto. Modelos de proceso de software: es una representacin abstracta de un proceso del software. - Modelos prescriptivos: prescriben un conjunto de elementos del proceso: actividades del marco de trabajo, acciones de la ingeniera del software, tareas, aseguramiento de la calidad y mecanismos de control. Cada modelo de proceso prescribe tambin un flujo de trabajo, es decir, de qu forma los elementos del proceso se interrelacionan entre s. - Modelos descriptivos: descripcin en la forma en que se realizan en la realidad Ambos modelos deberan ser iguales. Tipos de modelo Modelo en cascada: las etapas se representan cayendo en cascada, y cada etapa se debe completar antes de que comience la siguiente. Es til para diagramar lo que se necesita hacer, y es simple y fcil para explicar. Dificultades: - No existen resultados concretos hasta que todo est terminado. - Las fallas mas triviales se encuentran al comienzo del periodo de prueba y las mas graves al final. - La eliminacin de fallas suele ser extremadamente difcil durante las ultimas etapas de prueba del sistema. - Deriva del mundo del hardware y presenta una visin de manufactura sobre el desarrollo del software. - La necesidad de pruebas aumenta exponencialmente durante las etapas finales. - Congelar una fase es poco realista. - Existen errores, cambios de parecer, cambios en el ambiente.

Modelo en V: demuestra como se relacionan las actividades de prueba con las de anlisis y diseo. Sugiere que la prueba unitaria de integracin tambin sea utilizada para verificar el diseo del programa. La vinculacin entre los lados derecho e izquierdo implica que, si se encuentran problemas durante la verificacin y validacin, entonces el lado izquierda puede ser ejecutado nuevamente para solucionar el problema. 5

Ingeniera de Software Resumen 2do parcial terico

Modelo de Prototipos: un prototipo es un producto parcialmente desarrollado que permite que clientes y desarrolladores examinen algunos aspectos del sistema propuesto, y decidan si ste es adecuado o correcto para el producto terminado. Es una buena alternativa para tratar la incertidumbre, la ambigedad y la volubilidad de los proyectos reales. Para asegurar el xito: - Debe ser un sistema con el que se pueda experimentar. - Debe ser comparativamente barato (< 10%). - Debe desarrollarse rpidamente. - nfasis en la interfaz de usuario. - Equipo de desarrollo reducido. - Herramientas y lenguajes adecuados.

Tipos -

Evolutivos: el objetivo es obtener el sistema a entregar. Permite que todo el sistema o alguna de sus partes se construyan rpidamente para comprender o aclarar aspectos y asegurar que el desarrollador, el usuario y el cliente tengan una comprensin unificada tanto de lo que se necesita como de lo que se propone como solucin. Descartables: no tiene funcionalidad, se utilizan herramientas de modelado.

Desarrollo por fases: se desarrolla el sistema de tal manera que puede ser entregado en piezas. Esto implica que existen dos sistemas funcionando en paralelo: el operacional y el de desarrollo.

Ingeniera de Software Resumen 2do parcial terico

-Incremental: el sistema es particionado en subsistemas de acuerdo con su funcionalidad. Cada entrega agrega un subsistema. -Iterativo: entrega un sistema completo desde el principio y luego aumenta las funcionalidades de cada subsistema con las nuevas versiones.

Modelo Espiral - Combina las actividades de desarrollo con la gestin del riesgo. - Trata de mejorar los ciclos de vida clsicos y prototipos. - Incorpora objetivos de calidad y gestin de riesgos. - Elimina errores y alternativas no atractivas al comienzo. - Permite iteraciones, vuelta atrs y finalizaciones rpidas. - Cada ciclo empieza identificando los objetivos de la porcin correspondiente, las alternativas y las restricciones. - Cada ciclo se completa con una revisin que incluye todo el ciclo anterior y el plan para el siguiente. MTODOS GILES Antes todo se haca a travs de una planificacin minuciosa del proyecto, utilizando mtodos de anlisis y diseo, y procesos de desarrollo de software controlados y rigurosos. Esto funcionaba para grandes sistemas. Sin embargo, en sistemas de negocio pequeos o en sistemas actuales donde todo cambia constantemente, el esfuerzo invertido era muy grande y muchos equipos se resignan a prescindir de las buenas prcticas. De ah nacen las metodologas giles. Una metodologa gil es aquella en la que se da prioridad a las tareas que dan resultados directos y que reducen la burocracia tanto como sea posible, adaptndose adems a los cambios en el proyecto. The Agile Alliance (AA): es una organizacin dedicada a promover los conceptos de desarrollo de software gil. Estos conceptos estn reunidos en el Manifiesto para el Desarrollo de Software gil. Valores: - individuos e interacciones ms que procesos y herramientas - software operante mas que documentaciones completas - colaboracin con el cliente ms que negociaciones contractuales - respuesta al cambio ms que apegarse a una rigurosa planificacin. Principios: - la prioridad es satisfacer al cliente a travs de continuas entregas de software valuable, con el menor intervalo de tiempo posible entre una entrega y la siguiente - los cambios de requerimientos son bienvenidos. La idea es capturar los cambios para que el cliente obtenga ventajas competitivas - usuarios y desarrolladores deben trabajar juntos durante todo el proyecto - construir proyectos alrededor de motivaciones individuales - darles el ambiente y el soporte que ellos necesitan y confiar el trabajo dado - el dialogo cara a cara es la forma ms efectiva de intercambiar informacin entre el equipo de desarrolladores - el software que funciona es la medida clave de progreso - atencin continua a la excelencia y buen diseo aumentan la agilidad - la simplicidad es esencial - las mejores arquitecturas, requerimientos y diseos surgen de la propia organizacin de los equipos 7

Ingeniera de Software Resumen 2do parcial terico

CALIDAD Capacidad de un producto o servicio para servir satisfactoriamente a los propsitos del usuario mediante su utilizacin. Conformidad con los requisitos explcitos e implcitos de un cliente. Ausencia de defectos e imperfecciones. Calidad del software Se define como la concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente. Se puede dividir en calidad del producto obtenido y calidad del proceso de desarrollo, aunque son dependientes entre s. Producto: es de buena calidad si le sirve a quien lo adquiere y si este lo usa para realizar las tareas para las que fue concebido. Proceso: un proceso malo, mal concebido e implementado generar productos de mala calidad. Modelos de calidad: pueden ser utilizados para construir mejores productos y asegurar su calidad. CMM: posee una forma de aplicacin escalonada que permite un enfoque dirigido por niveles de madurez que indican como se desempea una organizacin en base a la madurez en las reas de proceso. Tiene 5 niveles de madurez. CMMI: igual que el CMM pero agrega un nuevo enfoque continuo, que enfoca las actividades de mejora y evaluacin en la capacidad de los diferentes procesos. Tiene 6 niveles de capacidad, que indican qu tan bien se desempea la organizacin en un rea de proceso individual.