CICLO DE VIDA DEL SOFTWARETodo proyecto de ingeniera tiene fines ligados a la obtencin de un producto, proceso o servicio que es necesario generar a travs de diversas actividades. Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestin del proyecto. Al conjunto de las fases empleadas se le denomina ciclo de vida.Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupacin temporal de tareas impone requisitos temporales correspondientes a la asignacin de recursos (humanos, financieros o materiales).Fases de un proyecto de Software Ingeniera de Requisitos o Requerimientos Anlisis Diseo Desarrollo Construccin Pruebas Implementacin MantenimientoModelos de Ciclo de VidaUn modelo de ciclo de vida de software es una visin de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las fases involucradas y los criterios de transicin asociadas entre estas fases.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.

Ingeniera de RequisitosLa Ingeniera de Requisitos, es una accin de la Ingeniera del Software que comienza con durante la actividad de comunicacin y contina en la actividad del modelado. La ingeniera de Requisitos tiende un puente hacia el diseo y el Desarrollo. La Ingeniera de Requisitos proporciona el mecanismo apropiado para entender lo que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solucin razonable, especificar la solucin sin ambigedades, validad la especificacin y administrar los requisitos conforme stos se transforman en un sistema operacional. Tareas: Inicio. Obtencin. Elaboracin. Negociacin. Especificacin. Validacin. Gestin de Requisitos.Realizacin de una conversacin informalAplicar los siguientes pasos: Identificar a los interesados. Reconocimiento de diferentes puntos de vista. Trabajo con respecto a la colaboracin. Formulacin de las Primeras Preguntas.Preguntas libres de contexto Quin est detrs de la solicitud de este trabajo? Quin usar la solucin? Cul ser el beneficio econmico de una solucin exitosa? Existe otra fuente para la solucin requerida?Preguntas para la comprensin del problema Cmo podra caracterizarse un buen resultado generado por una solucin exitosa? Cules problemas debera atacar esta solucin? Podra describir o mostrar el ambiente de negocios en el que se utilizar la solucin? Los aspectos especiales del desempeo o las restricciones afectarn a la forma en que se busque la solucin?Preguntas para la efectividad de la comunicacin Mis preguntas son relevantes para su problema? Estoy haciendo demasiadas preguntas? Alguien ms puede proporciona informacin adicional? Debera preguntarle alguna otra cosa?ObtencinEn esta funcin se requiere obtener los objetivos para el sistema, que es lo que debe lograr, de que forma el producto satisface las necesidades del negocio y por ltimo cmo se utilizar el sistema. Aplicar los siguientes pasos: Recopilacin conjunta de Requisitos. Despliegue de la funcin de la calidad (QFD). Producto de Trabajo de la Obtencin.RECOPILACIN CONJUNTA DE REQUISITOSAlgunas de las directrices bsicas para llevar a cabo una reunin conjunta de recopilacin de requisitos son: Las reuniones las dirige alguno de los asistentes. Se establecen reglas para la preparacin y la participacin. Se sugiere una agenda que sea tan formal como para cubrir todos los puntos importantes, pero tan informal como para estimular el flujo de ideas. Un moderador controla la reunin. Se utiliza un mecanismo de definicin (tablero electrnico, hojas, foro virtual, entre otros). La meta es identificar el problema, proponer elementos de solucin, negociar diferentes enfoques y especificar un conjunto de requisitos de solucin preliminares en una atmsfera que conduzca al cumplimiento de la meta.DESPLIEGUE DE LA FUNCIN DE CALIDAD (QFD)Es una tcnica que traduce las necesidades del cliente en requisitos tcnicos para el software. Se identifican tres tipos de requisitos: Requisitos Normales. Reflejan los objetivos y metas establecidos para un sistema durante las reuniones con el cliente. Si estos requisitos estn presentes, el cliente estar satisfecho. Algunos ejemplos podran ser los tipos de grficos en la pantalla, las funciones especficas del sistema, y los niveles de rendimiento solicitados. Requisitos esperados. Estn implcitos en el sistema y pueden parecer tan obvios que el cliente no los establece de manera explcita. Algunos ejemplos son la facilidad de la interaccin humano/mquina, correccin y confiabilidad operacional general y la facilidad de la instalacin del software.Requisitos estimulantes. Reflejan las caractersticas que van ms all de las expectativas del cliente y que prueban ser muy satisfactorias cuando estn presentes. Por ejemplo aadir caractersticas especiales.PRODUCTOS DE TRABAJO DE OBTENCIN Un enunciado de necesidad y factibilidad. Un enunciado limitado al mbito del sistema. Lista de participantes en la Obtencin de Requisitos. Una descripcin del ambiente tcnico del sistema. Una lista de requisitos (funciones) y las restricciones de dominio aplicables a cada uno. Un conjunto de escenarios de uso con respecto a la utilizacin del sistema. Cualquier prototipo desarrollado para definir de mejor forma los requisitos.ElaboracinLa Elaboracin es una accin del Modelado del Anlisis y se compone de una serie de tareas de modelado y refinamiento de escenarios del usuario que describen la forma en que el usuario final interactuar con el sistema, actividades y clases. NegociacinEl cliente y el desarrollador entran en un proceso de negociacin, en el cual se le debe pedir al cliente un balance de la funcionalidad, el rendimiento y otras caractersticas del sistema frente al costo y el tiempo de entrega. El objetivo de la negociacin es desarrollar un plan de proyecto que satisfaga las necesidades del cliente al mismo tiempo que refleja las restricciones de tiempo, recurso humano y presupuesto a las que est sometido el equipo de software.ValidacinAl crear cada elemento del Modelo de Anlisis, ste se examina para conocer su consistencia, sus omisiones y ambigedades. A los requisitos que representa el modelo, el cliente les da jerarqua y se agrupan en paquetes de requisitos que se implementan como incrementos de software y se le entregan. Una Revisin del Modelo de Anlisis se enfoca en las siguientes preguntas:Cada requisito es consistente con el objetivo general del sistema/producto?Todos los requisitos han sido especificados con el grado apropiado de abstraccin?El requisito es necesario en realidad o representa una caracterstica agregada irrelevante para el objetivo del sistema?Cada requisito est limitado y no es ambiguo? Algunos requisitos entran en conflicto con otros?El modelo de requisitos refleja de manera apropiada la informacin, la funcin y el comportamiento del sistema que ser construido?Gestin de requisitosEs un conjunto de actividades que ayudan al equipo del proyecto a identificar, controlar y rastrear los requisitos y los cambios a stos en cualquier momento mientras se desarrolla el proyecto.

Grfica de GanttMtodo Utilizado para la planeacin de proyectos. Planeacin y control de actividades, para lograr los objetivos y los tiempos necesarios para realizarlas. Procedimiento para elaboracin de la Planeacin Identificar y determinar las actividades comprendidas. Ordenar cronolgicamente la realizacin de las actividades. Interrelacionar las actividades, es decir, determinar que actividad debe realizarse antes de otra, que actividades se dan simultneamente, y por ltimo, que actividades deben efectuarse posteriormente. Asignar a cada actividad la unidad de tiempo de su duracin.

Nmero de Actividad Actividad Comienzo Fin Predecesora

1 A 03/10/2007 05/10/2007 Ninguna

2 B 03/10/2007 09/10/2007 Ninguna

3 C 08/10/2007 11/10/2007 A

4 D 12/10/2007 19/10/2007 B,C

5 E 22/10/2007 25/10/2007 D

Ruta Crtica (CPM)Determinar el tiempo ptimo para realizar un proyecto mediante la determinacin de las actividades que pueden realizarse simultneamente, los mrgenes de holgura y las actividades crticas. Elementos:a) Actividadesb) Fechas de Terminacinc) Tiempos de duracin de las actividadesd) Interdependencias entre las actividadese) Secuencia de las actividades

Actividad TPI TUT TUI TPT H

A 0 3 0 3 0

B 0 5 0 5 0

C 5 7 3 7 0

D 7 13 13 13 0

E 13 17 13 17 0

CASO DE USOSe puede completar la descripcin definiendo cules son las precondiciones y postcondiciones del sistema, es decir, qu condiciones deben cumplirse para que se realice un caso de uso y cules son aquellas condiciones que se cumplen posteriormente al caso de uso.Una excepcin se utiliza para describir funcionalidades indeseadas o excepcionales de un paso a causa de una condicin no cumplida.Tambin se pueden enumerar los diferentes escenarios del caso de uso o subflujos si los tuviese y dar una breve descripcin de ellos. Los escenarios son los distintos caminos por los que puede evolucionar un caso de uso, dependiendo de las condiciones que se van dando en su realizacin.Elementos del Caso de UsoActores. Un actor es algo o alguien que se encuentra fuera del sistema y que interacta con l. En general, los actores sern los usuarios del sistema y los sistemas externos al que se est desarrollando. Si se habla de usuarios, un actor es el papel que puede llevar a cabo en cuanto a su forma de interactuar con el sistema, es decir, un nico actor puede representar a muchos usuarios diferentes y de la misma forma, un usuario puede actuar como actores diferentes.

Casos de uso. Un caso de uso representa el comportamiento que ofrece el sistema de informacin desde el punto de vista del usuario. Tpicamente ser un conjunto de transacciones ejecutadas entre el sistema y los actores. Para facilitar la comprensin de los casos de uso del sistema de informacin en el anlisis, es posible agruparlos en paquetes segn funcionalidades semejantes o relacionadas.

Paquete.- El objetivo de estos diagramas es obtener una visin ms clara del sistema de informacin orientado a objetos, organizndolo en subsistemas, agrupando los elementos del anlisis, diseo o construccin y detallando las relaciones de dependencia entre ellos.

Relacin de casos de usoLa relacin entre un actor y un caso de uso es una relacin de comunicacin, que indica que un actor interviene en el caso de uso. Normalmente, el actor aporta informacin para la realizacin de un caso de uso o recibe informacin como resultado de la realizacin del mismo, por ello, esta relacin puede ser unidireccional o bidireccional, aunque generalmente se muestra como bidireccional, ya que no es necesario especificar en detalle estas relaciones.La relacin entre casos de uso es una relacin unidireccional. Esta relacin puede presentar uno de los dos siguientes tipos: usa o include y extiende.Relacin INCLUDE o UsaLa asociacin de dependencia estereotipada con o se emplea para evitar describir el mismo flujo de eventos repetidas veces, aportando un mecanismo de factorizacin que permite ubicar comportamiento comn en un nico caso de uso aparte que ser compartido por todos aquellos casos de uso en los que originalmente se encontraba expresada la porcin de pasos comn. Semnticamente se debe interpretar que el caso de uso base "incluye" la funcionalidad expresada en el caso de uso comn (por esa razn la flecha de la asociacin de dependencia apunta al caso de uso comn, puesto que el caso de uso base "depende" del aqul porque necesita su funcionalidad para poder completarse).Por ejemplo, si los casos de uso A y B presentan una parte comn, sta se puede sacar a un tercer caso de uso C. Entonces, habr una relacin usa del caso de uso A al C y otra del B al C.

Relacin ExtendCuando una condicin en el curso normal de un caso de uso "A" implica la ejecucin de un conjunto de pasos que se llevan a cabo en forma excepcional o que corresponden al tratamiento de un error, estos pasos excepcionales se deben agrupar y modelar como un nuevo caso de uso, caso de uso "B". De esta manera, el caso de uso base "A" ser extendido por el caso de uso excepcional "B".Entre los casos de uso "A" y "B" existir una asociacin de dependencia estereotipada como , lo que significa que la funcionalidad del caso de uso "B" "extiende" la funcionalidad del caso de uso "A" en tanto y en cuanto en el caso de uso "A" se cumpla la condicin que implica la ejecucin del caso de uso "B". Y la asociacin de dependencia debe apuntar al camino base (contrariamente a lo que sucede en la asociacin de inclusin) debido a que el caso de uso "B" depende de que se cumpla con una condicin en "A" para poder llevarse a cabo.

Cmo se puede observar, la funcionalidad que estamos modelando con una asociacin de extensin podra modelarse perfectamente tambin como un subflujo, por lo que se ha decidido establecer las siguientes reglas prcticas:Un subflujo es, conceptualmente, diferente a una excepcin, por lo que su tratamiento debera ser diferente: los subflujos son parte del camino base y las excepciones son tales, como su nombre lo indica.La funcionalidad de las excepciones debera tratarse como un caso de uso que extiende al caso de uso base, pero en algunas oportunidades esta funcionalidad excepcional es tan pequea (en cuanto al nmero de pasos) que no sera conveniente, desde un punto de vista meramente prctico, destinar un caso de uso entero a esa pequea porcin de funcionalidad, describindose, entonces, en la seccin destinada a los subfujos dentro del documento que contiene la descripcin del caso de uso base.Este criterio prctico ser adoptado siempre que la excepcin cuente con ms de 10 pasos o que la excepcin posea nuevas excepciones.Es importante aclarar que las condiciones anteriores no representan una regla absoluta y automtica ya que si el subflujo cumple con una o dos de las condiciones anteriores y el subflujo no puede considerarse, por el nivel de abstraccin y criterio personal, un nuevo caso de uso extendido, puede dejarse como subflujo. Identificacin de casos de usoCules son las principales tareas o funciones que sern realizadas por el actor?Cul es el sistema de informacin que el actor adquiere, produce o cambia?Qu actor informar al sistema de los cambios en el entorno externo?Qu informacin necesita el actor sobre el sistema?

Flujo de datosEl diagrama de flujo de datos (DFD) permite al ingeniero del software desarrollar los modelos del mbito de informacin y del mbito funcional al mismo tiempo. A medida que se refina el DFD en mayores niveles de detalle, el analista lleva a cabo implcitamente una descomposicin funcional del sistema. Al mismo tiempo, el refinamiento del DFD produce un refinamiento de los datos a medida que se mueven a travs de los procesos que componen la aplicacin.Diagrama de ActividadesUn diagrama de actividades muestra el flujo secuencial de las actividades. El diagrama de actividades es utilizado tpicamente para describir las actividades realizadas en una operacin (mtodos), aunque puede tambin ser utilizado para describir procesos (casos de uso).Elementos y Notacin de los diagramas de actividadesEstado de Actividad.- Una actividad es la especificacin de una secuencia parametrizada de comportamiento. Una actividad se representa con un rectngulo con las puntas redondeadas adjuntando todas las acciones, flujos de control y otros elementos que constituyen la actividad.