Ingeniera de Requisitos y Anlisis

Conceptos giles 1. Software IEEE 1990, define el software como un programa de computadora, procedimientos y posiblemente datos y documentacin relativos a la operacin de un sistema de computacin. 2. Metodologa gil En 2001, Kent Beck y otros 16 notables desarrolladores, escritores y consultores firmaron el Manifiesto para el desarrollo gil de Software, el cual estableca: A los individuos y sus interacciones sobre los procesos y las herramientas. Al software en funcionamiento sobre la documentacin extensa. A la colaboracin del cliente sobre la negociacin del contrato. A la respuesta al cambio sobre el seguimiento de un plan. La ingeniera de software gil combina una filosofa y un conjunto de directrices de desarrollo. La filosofa busca la satisfaccin del cliente y la entrega temprana de software incremental; equipos de proyectos pequeos y con una alta motivacin; mtodos informales; un mnimo de productos de trabajo de la ingeniera de software y una simplicidad general del desarrollo. Las directrices de desarrollo resaltan la entrega sobre el anlisis y el diseo (aunque estas actividades no se
Unidad No. 1: Conceptos giles. Ing. Karina Fuenmayor V., 2013
1

descartan) y la comunicacin activa y contina entre los desarrolladores y los clientes. Pressman (2008) Las metodologas giles incluyen al cliente en las reuniones de seguimiento, y establecen una forma de trabajo en la que la comunicacin fluida garantiza que si se produce un cambio total o parcial en los requisitos el equipo de desarrollo ser capaz de adaptar la aplicacin en un tiempo razonable. Brito (2009)

Interesante!

Es importante destacar que el desarrollo gil de software no es slo un nico conjunto de reglas a seguir para tener xito. Metodologas giles comprenden conceptos de liderazgo, procesos ligeros de gestin de proyectos, buenas prcticas de ingeniera, tcnicas de desarrollo, as como herramientas de apoyo. Se ocupan de toda la

empresa en todos los niveles y en todas las disciplinas.

Un enfoque gil crece y evoluciona con el tiempo mezclando y combinando las ideas aportadas por los practicantes.

Esto se resume en un conjunto de verdades importantes Crecer y evolucionar: Un proyecto gil no recoger un proceso formal y lo ejecutar. El proceso real se forma a cabo mientras que los equipos desarrollen prcticas y aprendan de las experiencias que se estn realizando. El enfoque de desarrollo est sujeto a la misma necesidad de cambio y la mejora constante como el cdigo desarrollado en s. Cuando los procesos de desarrollo avancen de lo primitivo a la perfeccin, se puede entender que se avanza hacia una complejidad notable. Sin embargo, si un proceso de desarrollo tiende a ser demasiado complejo, morir por su propio peso. Por lo tanto, un objetivo claro es evolucionar hacia la simplicidad. Mezclar y combinar: La agilidad es un conjunto de pensamientos, de los cuales los proyectos individuales pueden combinar su aplicacin concreta en un proceso de desarrollo gil. El camino del equipo de trabajo es una composicin de las prcticas, en lugar de aplicar un (todo de una sola talla nica) proceso genrico. El proceso resultante ser adaptado a las necesidades y el contexto de un equipo, incluso dentro de una misma organizacin, diferentes equipos puede adoptar diferentes prcticas. Profesionales: Las metodologas giles estn fuertemente influenciados por los profesionales del equipo, quienes difunden sus ideas en su entorno de trabajo diario. Esto es bastante diferente a los procesos de desarrollo clsicas que son definidos por especialistas y se introducen dentro de una organizacin en un enfoque de arriba hacia abajo. Sin embargo, manejar el enfoque de desarrollo de la parte inferior le ayudar a evitar las lagunas en los procesos definidos, y refleja lo que los equipos estn haciendo. La mayora de ellos promueve el desarrollo en pequeos incrementos iterativos y tienen un fuerte enfoque en el trabajo en equipo. El plan y el diseo del proyecto se describen slo a un nivel alto, mientras que la iteracin actual se detalla ms adelante. Los equipos estn descentralizadas como auto-organizados y recorren la funcionalidad del proyecto de extremo a extremo. Estn equipadas con la autoridad necesaria para alcanzar sus objetivos, en lugar de ser microadministrados, detenidamente seguidos o inspeccionados de forma permanente. En un entorno gil de trabajo producir y probar es la mejor forma de medir el progreso.

Unidad No. 1: Conceptos giles. Ing. Karina Fuenmayor V., 2013

3. UML (Unified Model Language) Es un lenguaje visual que puede ser usado en el desarrollo de sistemas de software. Es un lenguaje de especificacin. No se trata de un lenguaje humano ni tampoco un lenguaje de programacin, sin embargo como los otros, tiene sus propias reglas que determinan como debe ser usado. UML consiste en un grupo de elementos y reglas que determina como pueden combinarse estos elementos. Muchos de estos son grficos y consisten en lneas, rectngulos, valos y otras formas y varios de estos elementos grficos son etiquetados con palabras que proveen de informacin adicional. Sin embargo, los elementos grficos de UML son solamente una representacin grfica de cualquier cosa que se modele. Bennett (2005)

Se define como un lenguaje que permite especificar, visualizar, construir y documentar los artefactos de los sistemas de software. Es un sistema notacional destinado a los sistemas de modelado que utilizan conceptos orientado a objetos.
El uso de UML en el desarrollo de sistemas orientado a objetos gan importancia cuando Booch, Rumbaugh y Jacobson presentaron un lenguaje para el modelado visual que podra considerarse como un estndar para el desarrollo de sistemas. 4. Requerimiento o Requisito La definicin que aparece en IEEE 1990, es la siguiente: a) una condicin o capacidad que un usuario necesita para resolver un problema o lograr un objetivo. (b) una condicin o capacidad que debe tener un sistema o un componente de un sistema para satisfacer un contrato, una norma, una especificacin u otro documento formal. (c) Una representacin en forma de documento de una condicin o capacidad como las expresadas en (a) o en (b). Otra posible definicin es la planteada por Goguen 1994, un requisito es una propiedad que un sistema debera tener para tener xito en el entorno en el que se usar. Sin embargo, a pesar de esta aparente simplicidad del concepto, es frecuente encontrar el trmino requisito calificado con adjetivos que pueden resultar confusos en un primer momento: de sistema, hardware, software, de usuario, de cliente, funcional, no funcional, etc.
Unidad No. 1: Conceptos giles. Ing. Karina Fuenmayor V., 2013
3

Para Rodrguez y otros, 2007, se trata de las especificaciones tcnicas y de uso que debe cumplir el proyecto y, por lo tanto, varan de uno a otro. Normalmente profundizan en los anlisis realizados en las fases anteriores, son ms detallados y pretender ser definitivos. Pueden tener naturaleza contractual ya que se plasman en peticiones de propuestas a los proveedores y en anexos de los contratos. 5. Patrn de diseo de software En la ingeniera de software, un patrn de diseo es una solucin reutilizable general a un problema que ocurre comnmente en un contexto determinado en el diseo de software. Un patrn de diseo no es un diseo de acabado que se puede transformar directamente en la fuente o cdigo de mquina. Es una descripcin o una plantilla para resolver un problema que se puede utilizar en muchas situaciones diferentes. Los patrones formalizan las mejores prcticas que el programador debe implementar por s mismos en el desarrollo de una aplicacin.

Los patrones de diseo orientado a objetos suelen mostrar las relaciones e interacciones entre clases u objetos, sin especificar las clases de aplicaciones finales o los objetos que estn involucrados. (Wikipedia, 2013)
6. Arquitectura del software En el campo de la Ingeniera de software, el concepto de arquitectura ha sido fundamental como estrategia para enfrentar la complejidad del desarrollo de soluciones informticas y establecer acuerdos de diseo de alto nivel para ellas. (Kazman 2003). En una arquitectura de software confluyen tres elementos fundamentales: (a) Los modelos que definen la estructura, topologa y dinmica del sistema, (b) la trazabilidad correspondencia de dichos modelos con los requisitos o necesidades establecidas en el contexto que va a operar la solucin software y (c) las reglas, principios y justificaciones que rigen la arquitectura y que sustentan las decisiones que se tomaron.
Unidad No. 1: Conceptos giles. Ing. Karina Fuenmayor V., 2013
4

La arquitectura de software es fundamental a la hora de garantizar que la solucin cumpla con los criterios de calidad establecidos en los requisitos. Dichos criterios de calidad han sido caracterizados y estandarizados en propuestas como la ISO 9126, la cual establece una taxonoma de caractersticas y subcaractersticas, que debe poseer un

producto software. La importancia de la arquitectura radicar en que sus diferentes elementos busquen garantizar el cumplimiento de las caractersticas tanto en la funcionalidad que el sistema debe ofrecer como en los requerimientos de calidad que debe satisfacer. Zea (2007)
7. Prototipo Un prototipo es un software provisional construido con herramientas y tcnicas que dan prioridad a la rapidez y a la facilidad de modificacin antes que a la eficiencia en el funcionamiento que slo tiene que servir para que los usuarios puedan ver como sera el contenido o apariencia de los resultados de algunas de las funciones del futuro software. Un prototipo sirve para que los usuarios puedan confirmar que lo que se les muestra efectivamente, es lo que necesitan o bien lo pueden pedir por comparacin y entonces se prepara una nueva versin del prototipo considerando las indicaciones de los usuarios y se les muestra otra vez. En el momento en que el prototipo ha permitido concretar y confirmar los requisitos, se puede comenzar un desarrollo segn los parmetros, criterios y estructura de alguna metodologa. Campderrich (2003) El uso de prototipos es una estrategia que puede aplicarse en casi todas las actividades del proceso de software. El propsito de los prototipos es obtener
Unidad No. 1: Conceptos giles. Ing. Karina Fuenmayor V., 2013
5

rpidamente la informacin necesaria para ayudar en la toma de decisiones. Los siguientes son algunos tipos de prototipos: Prototipos de requisitos: permite que los usuarios perciban la funcionalidad del producto final a travs del diseo de interfaces o pantallas del sistema. El objetivo es ayudar a aclarar los requisitos y solicitar nuevas ideas. Prototipos de anlisis: hace posible generar rpidamente una arquitectura general que considere las caractersticas principales del sistema de acuerdo a la especificacin de requisitos. Prototipos de diseo: Estos prototipos permiten explorar y comprender la arquitectura particular del sistema, para poder evaluar aspectos como cuellos de botella (rendimiento y uso de la memoria) o inconsistencias en el diseo.

Prototipos verticales: ayuda a comprender parte de un problema y desarrollar su solucin completa. Esto se hace generalmente cuando los conceptos bsicos no estn bien comprendidos, por ejemplo el seguimiento de cierta metodologa.

Prototipos de factibilidad: demuestra si es posible lograr ciertos objetivos del proyecto, por ejemplo, aplicar una arquitectura particular, conectarse a una base de datos bajo ciertas restricciones de rendimiento, aprender a programar en un lenguaje en un tiempo determinado o predecir costos de desarrollo de un proyecto.

Un prototipo no es un producto de calidad que deba mantenerse a largo plazo. Por el contrario, los prototipos son creados y probados rpidamente, para luego ser desechados. Sin embargo, es comn que por presiones de tiempo, se trate de enviar un prototipo al mercado como si fuera el producto final. En general, siempre existir un conflicto entre el desarrollo rpido y un producto de calidad. Las siguientes dos listas muestran algunas consideraciones para el xito o fracaso con prototipos:

Unidad No. 1: Conceptos giles. Ing. Karina Fuenmayor V., 2013

Los prototipos tienen xito cuando: Se tiene claro el propsito del prototipo y se usa de manera adecuada Se comprende la tecnologa a utilizarse y su relacin con el proceso de prototipos. Se integra un grupo de tcnicos apropiado para hacer el prototipo: lder de proyecto, documentador, elaborador de prototipos de requisitos y anlisis y elaborador de prototipos de diseo. Se evala al grupo y las entregas finales. Se involucra a tiempo en el proceso a los usuarios finales. Se est dispuesto a repetir el proceso de prototipos para comprender mejor la arquitectura bsica. Se establecen criterios de evaluacin apropiados al comienzo de cada etapa de prototipos y basarse firmemente en estos criterios para su terminacin. Se construyen prototipos basados en una biblioteca de cdigo reusable, controlada por el bibliotecario asignado. Los prototipos fallan cuando: No se entiende que es un prototipo y como debe usarse. No se comprende el proceso lo suficientemente bien como para organizar al grupo correctamente.

 No se sabe hasta cundo dejar de evolucionar el prototipo y comenzar de cero, extendiendo demasiado el proceso. No se sabe hasta cundo continuar para tratar de lograr los criterios de evaluacin deseados, terminando prematuramente el proceso. No se utilizan ambientes o herramientas de apoyo adecuadas para el desarrollo particular. Se cree que un prototipo razonable es un producto aceptable. Los prototipos nunca terminan. Weitzenfeld, (2005)
8. Objeto Un objeto es una cosa, una entidad, algo que t puedes tomar, algo que t puedes imaginar que tiene su propia identidad. Algunos objetos cobran vida, otros no. Ejemplos del mundo real: carro, una persona, una casa, una tabla, un perro. Todos los objetos tienen atributos: por ejemplo, un carro tiene un fabricante, un modelo, un color y un precio; un perro tiene un pedigree, una edad, un color. Los objetos tambin tiene comportamiento: un carro puede moverse desde un lugar hacia otro y un perro puede ladrar. O'Docherty (2005) 9. Interface IEEE 1990 define las interfaces a) una frontera comn a travs de la cual se transmite la informacin, b) Un componente de hardware o software que conecta dos o ms de otros componentes con el fin de pasar informacin de una a la otra,
Unidad No. 1: Conceptos giles. Ing. Karina Fuenmayor V., 2013
7

c) conectar dos o ms componentes para el propsito de pasar informacin de una a la otra, d) para servir como elemento de conexin. 10. Ingeniera de software Es una disciplina de ingeniera que comprende todos los aspectos de la produccin de software. Comprende las formas prcticas para desarrollar y entregar un software til. La ingeniera de software se concentra en el desarrollo de productos de software que se venden a un cliente. Existen dos tipos de productos de software: Productos genricos: son sistemas aislados producidos por una organizacin de desarrollo y que se venden al mercado abierto a cualquier cliente que le sea posible comprarlos. Ejemplo: las aplicaciones como editores de texto, paquetes de dibujo.

Productos personalizados (o hechos a la medida): son sistemas requeridos por un cliente en particular. Un ingeniero de software desarrolla especialmente el producto para ese cliente. Una diferencia importante entre estos tipos de software es que, en los productos genricos, la organizacin que desarrolla el software controla su especificacin. La especificacin de los productos personalizados, por lo general es desarrollada y controlada por la organizacin que compra el software. (Sommerville, 2005)

Objetivo principal de la Ingeniera de software: construir una solucin de software eficiente que satisfaga las necesidades requeridas por un cliente.

Objetivos especficos de la Ingeniera de software: (a) Proveer los estndares y modelos, que faciliten la comunicacin, tanto para clientes como para especialistas en la elaboracin de un proyecto de software, tales como herramientas visuales y grficas, tales como herramientas CASE, mtodos y metodologas que marquen una secuencia en los procedimiento. (b) Proveer mtodos, herramientas y procedimientos para la construccin eficiente del software, (c) Proveer parmetros y criterios de evaluacin de la calidad del software, estndares y normas tales como ISO. Corts (2005)

Unidad No. 1: Conceptos giles. Ing. Karina Fuenmayor V., 2013