CAPITULO I INGENIERA DE SOFTWARE. GENERALIDADES 1.1. QUE ES SOFTWARE .

El software ha sido definida por muchos autores, de entre los que se ha seleccionado los siguientes: Definicin 1 El software es un conjunto de:

Instrucciones.- (Programas de computadora) que cuando se ejecutan proporcionan la funcin deseada. Estructuras de Datos.- que permiten a los programas manipular adecuadamente la informacin. Documentos.- Que describen la operacin y el uso de programas.

Definicin 2 Es el producto de computadora que disean y construyen los Ingenieros de Software, esto abarca:

1.1.1

PROGRAMAS que se ejecutan dentro de una computadora de cualquier tamao y arquitectura. DOCUMENTOS que comprenden formularios virtuales e Impresos. DATOS que combinan nmeros y texto REPRESENTACIONES DE INFORMACIN de audio, vdeo e imgenes. CARACTERISTICAS DEL SOFTWARE

Para poder comprender lo que es el software es importante examinar las caractersticas del software que lo diferencian de otras cosas que el hombre puede construir. Cuando se construye el hardware, el proceso (anlisis, diseo, construccin y pruebas), se traduce finalmente en un producto tangible; sin embargo, el software es lgico en lugar de fsico. Por lo tanto el software tiene caractersticas considerablemente distintas a las del hardware. El software se desarrolla, no se fabrica

Aunque existen similitudes en el proceso de desarrollo de software y la construccin de hardware, pero ambas actividades son fundamentalmente diferentes. En ambas actividades la buena calidad depende del diseo. construccin del hardware y software La siguiente tabla muestra las diferencias en la

TABLA No. I Diferencias en la construccin del hardware y software Hardware Software

Problemas de calidad palpables Calidad

Problemas complejos de
corregir.

Problemas de calidad son fcilmente corregibles

Son impalpables o no
existen. Comunicacin permanente entre todo el equipo de trabajo. Dependen o se encuentran en la Ingeniera

Forma de Trabajo

Cada equipo de personas trabajan en una tarea especfica.

Costos

Fijo

La construccin de Hardware y Software generan un producto, pero con enfoques diferentes. El software no se estropea, se deteriora

INGENIERA DE SOFTWARE I Ing. Jonny Guaia Y.

La Figura No. 1.1 describe para el hardware la proporcin de fallos en funcin al tiempo. Esa relacin, denominada frecuentemente curva de baera, indica que el hardware presenta muchos fallos al principio de su vida (estos fallos son atribuibles normalmente a defectos de fabricacin o del diseo); una vez corregidos estos defectos, la tasa de fallos cae hasta un nivel estacionario, donde permanece un cierto tiempo; sin embargo, conforme pasa el tiempo, el hardware empieza a desgastarse y la tasa de fallos se incrementa. La curva de fallos del software tendra la forma de la Figura No. 1.2. Los errores no detectados harn que falle el programa durante las primeras etapas de su vida; sin embargo una vez que se corrigen, la curva se estabiliza. Hay que considerar adems que durante su vida el software sufre cambios (mantenimiento), conforme se realizan los cambios, es probable que se introduzcan nuevos defectos, haciendo que la curva de fallos tenga picos como se ve en la Figura No.1.3; antes que la curva pueda volver al estado estacionario original, se solicita otro cambio, haciendo que de nuevo se cree un pico. Lentamente el nivel mnimo de fallos comienza a crecer; por lo tanto, el software se va deteriorando debido a los cambios.

ndice de fallos

Mortalidad infantil

Se estropea

Figura No.1.1: Curva de fallos del hardware

Tiempo ndice de Fallos

Contina el mismo ndice hasta la adolescencia

Figura No.1.2: Curva idealizada de fallos del software

Incremento del ndice de fallos Tiempo por efectos del cambio

Curva real

ndice de Fallos

Cambio Curva Ideal

Tiempo
Figura No.1.3: Curva idealizada y real de fallos del software Cuando un componente de Hardware falla, se sustituye por otro Hay Repuesto, cuando falla el software No hay repuestos, una falla en el software implica un error en el diseo o en el programa. Por lo tanto, el mantenimiento del software tiene una complejidad considerablemente mayor que la del mantenimiento del hardware.

INGENIERA DE SOFTWARE I Ing. Jonny Guaia Y.

La mayora del software se construye a la medida

El hardware se consigue por catlogo, mientras que el software se construyen a la medida. A pesar que hoy en da el desarrollo de software se basa en la Reutilizacin de software , esto no permite completamente reconstruir totalmente un software; sin embargo son de gran utilidad. Por ejemplo, las interfaces grficas de usuario de hoy en da se construyen frecuentemente a partir de componentes reutilizables (libreras) que permiten la creacin de mens, ventanas y de una amplia variedad de mecanismos de interaccin 1.1.2 CLASIFICACIN DEL SOFTWARE

Existen varios criterios de clasificacin del software, entre los que podemos destacar: Por Su Aplicatividad o Software de sistemas Software de tiempo real Software de gestin Software de ingeniera y cientfico Software de empotrado Software de computadoras personales Software de basadas en Web Software de inteligencia artificial

o
o o o

o
o o

Por el nivel en la toma de decisiones empresariales o o o Sistemas operacionales sistemas de apoyo a la toma de decisiones sistemas de planeacin estratgica

SOFTWARE DE SISTEMAS.- Es un conjunto de programas que han sido escritos para servir otros programas. Por ejemplo: Compiladores Utilitarios de gestin Editores Componentes de sistemas operativos Controladores para el manejo de perifricos Protocolos de comunicacin

En cualquier caso, el software de sistemas se caracteriza por:

Interacta con el hardware de la computadora Tiene una estructura de datos complejos Mltiples interfaces internas Gestin de procesos compleja

SOFTWARE DE TIEMPO REAL.- Un sistema de tiempo real puede definirse como aquel que controla un ambiente recibiendo datos, procesndolos y devolvindolos con la suficiente rapidez como para influir en dicho ambiente en ese momento. Los sistemas de tiempo real se diferencian de los sistemas en lnea en que Los sistemas en lnea reaccionan en segundos a un requerimiento del usuario, sin que se produzca ningn desastre En los sistemas en tiempo real, la computadora debe reaccionar en milisegundos y a veces en microsegundos a los estmulos que recibe. Por ejemplo: Sistemas de Control de Procesos, Sistemas de vigilancia de pacientes. Si la computadora no responde con la suficiente rapidez, el sistema puede quedar fuera de control. Un sistema en tiempo real tiene los siguiente componentes bsicos: Dispositivos de adquisicin de datos que recibe y da formato a la informacin que recibe del entorno. Monitorizacin: coordina los dems componentes Entradas y salidas que responda al medio

INGENIERA DE SOFTWARE I Ing. Jonny Guaia Y.

Estmulo Ambiente Sistema de Tiempo Real Respuesta

Figura No.1.4: Sistema en tiempo real SOFTWARE DE GESTIN.- El proceso de la informacin empresarial constituye la mayor de las reas de aplicacin del software. Tambin son conocidos como SIG (Sistemas de informacin de gestin), se caracterizan porque acceden a una o ms bases de datos que contienen informacin de la empresa. El software de gestin ayuda a llevar a cabo los detalles del trabajo cotidiano de una organizacin. Estos sistemas tambin se conocen como sistemas de procesamiento de transacciones o sistemas operacionales. Por ejemplo, sistemas de Nmina, Contabilidad, Inventarios, etc. SOFTWARE DE INGENIERA Y CIENTIFICO.Est caracterizada por algoritmos complejos relacionados con el manejo de nmeros. Por ejemplo: aplicaciones de astronoma, vulcanologa, simulaciones, etc. Hoy se han empezado a combinar con los sistemas en tiempo real e incluso con el software de sistemas. SOFTWARE EMPOTRADO.- reside en memoria solo de lectura y se utiliza para controlar productos inteligentes existentes en los mercado de consumo e industriales. El software empotrado puede ejecutar funciones muy limitadas. Por ejemplo: Ej: control de microondas, funciones digitales de un auto, funciones del celular, etc. SOFTWARE DE COMPUTADORAS PERSONALES.- El mercado de computadoras personales se desarroll en las pasadas dos dcadas, algunas de estas aplicaciones son: Procesadores de texto Hojas de clculo Grficos por computadora Multimedia Gestin de Base de Datos Aplicaciones financieras Redes

SOFTWARE DE INTELIGENCIA ARTIFICIAL.- El software de inteligencia artificial (IA) hace uso de algoritmos no numricos para resolver problemas complejos. Dentro de los sistemas de IA podemos destacar: Sistemas expertos o sistemas basados en el conocimiento Reconocimiento de patrones (imgenes, voz, juegos) Redes neuronales artificiales (simula la estructura del cerebro y las funciones de la neurona biolgica ) Robtica

Los ms conocidos son los sistemas expertos que son programas capaces de imitar el desempeo humano en una gran variedad de tareas inteligentes. Los sistemas expertos contienen grandes cantidades de conocimientos que emplean en el desempeo de una tarea dada, tienen la capacidad necesaria para desempearse a nivel de un experto. Por ejemplo: Desempeo de un mdico Desempeo de fsicos Desempeo de administradores, etc.

El sistema experto es un apoyo de alto nivel intelectual para el experto humano. SOFTWARE BASADO EN LA WEB.- Los sistemas basados en el Web hacen posible que una gran cantidad de usuarios dispongan de una gran variedad de contenido y funcionalidad. El software est basado en una arquitectura de Internet. SISTEMA DE APOYO A LA TOMA DE DECISIONES. estos sistemas no toman decisiones por s mismos, sino que ayudan a los administradores a tomar decisiones inteligentes y documentadas acerca de los diversos aspectos de la operacin. Los sistemas de apoyo a las decisiones son pasivos en el sentido que no operan en forma regular, se los utiliza cuando se los necesita. Por ejemplo: sistemas de anlisis estadstico, programas de pronstico de mercados. Los sistemas de apoyo a las decisiones no solo recuperan y exhiben los datos sino que realizan varios tipos de anlisis matemticos y estadsticos de los mismos. Presentan la informacin en una gran cantidad de formas: grficos, tablas, reportes convencionales, etc. SISTEMAS DE PLANEACIN ESTRATGICA. Son utilizadas por los gerentes para evaluar y analizar la misin de la organizacin. Por ejemplo: consejos de la naturaleza del mercado, preferencias de los consumidores, comportamiento de la compaa, etc.

INGENIERA DE SOFTWARE I Ing. Jonny Guaia Y.

Los sistemas de planeacin estratgica no son programas de computadora en s, son complejas combinaciones de actividades y procedimientos, muchas de las cuales las llevan a cabo personas que utilizan informacin obtenida de fuentes externas (estudio del mercado, por ejemplo) y datos internos de los sistemas operacionales de la organizacin y de los sistemas de apoyo a la toma de decisiones. La Figura No. 1.5 representa el nivel de la toma de decisiones en los que se utilizan los distintos tipos de sistemas de esta clasificacin.
Sistemas de Planeacin Estratgica

Administracin estratgica

Sistemas de Apoyo a la toma de decisiones

Planeacin y control operativo

Control Operativo

Sistemas de Gestin

Figura No.1.5: Ubicacin de los sistemas en los niveles de administracin

1.1.3

PROBLEMAS EN EL DESARROLLO DE SOFTWARE

Los problemas del desarrollo del software se pueden caracterizar bajo muchas perspectivas diferentes, entre las que se pueden considerar las siguientes: La planificacin y la estimacin de costos frecuentemente son muy imprecisas. La productividad del software no corresponde con la demanda de sus servicios El software no se construye utilizando las herramientas adecuadas para su desarrollo No se proporciona un adecuado servicio al cliente, ldurante la operacin del sistema. La calidad del software no llega a ser a veces ni aceptable. Una mala definicin inicial, es una de las principales causas del desarrollo baldo de software. Es esencial una descripcin formal y detallada del mbito de la informacin, funciones, rendimiento, interfaces, diseo, criterios de validacin, etc. Los requerimientos del proyecto cambian continuamente, pero el impacto del cambio vara segn el momento en que se produzca.

La Figura No. 1.6 ilustra el impacto de los cambios; si se pone cuidado al dar la definicin inicial, los cambios solicitados al principio pueden adaptarse fcilmente, el cliente puede revisar los requerimientos del software y recomendar las modificaciones con relativamente poco impacto en el costo. Cuando los cambios se solicitan durante el diseo del software, el impacto en el costo crecer rpidamente, los cambios pueden requerir recursos adicionales e importantes modificaciones en el diseo, es decir un costo adicional. Los cambios en la funcin, rendimiento, interfaces u otras caractersticas, durante la implementacin pueden tener un impacto importante sobre el costo. Cuando se solicitan al final de un proyecto, los cambios pueden producir un orden de magnitud ms caro que el mismo cambio pedido al principio.

Costo del Cambio

60100x

Figura No. 1.6. Impacto del cambio

1.5-6x 1x

No existe un nico enfoque para solucionar los problemas del software. Sin embargo, mediante la combinacin de mtodos, herramientas y tcnicas se ha creado una nueva disciplina para el desarrollo del software, llamada Ingeniera del Software.
DEFINICION DESARROLLO MANTENIMIENTO

1.2

INGENIERA DEL SOFTWARE

Varios autores han desarrollado definiciones de la ingeniera de software, de las cuales citaremos las siguientes:

INGENIERA DE SOFTWARE I Ing. Jonny Guaia Y.

Definicin 1: La ingeniera de software es el establecimiento y uso de principios robustos de ingeniera a fin de obtener econmicamente software que sea confiable y funcione eficientemente (Fritz Bauer). Este concepto no dice mucho sobre los aspectos tcnicos de calidad del software; no se enfrenta directamente con la necesidad de la satisfaccin del cliente o de la entrega oportuna del producto. Sin embargo, la definicin de Bauer nos proporciona una lnea de base: Cules son los principios de la ingeniera aplicables al desarrollo del software? Cmo construimos software econmicamente para que sea confiable? Qu se necesita para crear programas que funcionen eficientemente?. stas son algunas preguntas que son resueltas por la ingeniera de software. Definicin 2: Ingeniera de software: (1) La aplicacin de un enfoque sistemtico, disciplinado y cuantificable hacia el desarrollo, operacin y mantenimiento del software; es decir, la aplicacin de ingeniera al software. (2) El estudio de enfoques como en (1). 1.2.1 PROCESO, MTODOS Y HERRAMIENTAS

La Ingeniera de software es una tecnologa multicapa. Como se muestra en la Figura 1.7, el enfoque de la ingeniera del software se apoya sobre un compromiso de calidad.

Herramientas Mtodos Proceso Enfoque de calidad

Figura No. 1.7. Capas de la Ingeniera de Software

PROCESO El fundamento de la ingeniera de software es la capa de proceso. El proceso de la ingeniera de software permite un desarrollo racional y oportuno de la ingeniera de software. La Figura No. 1.8 establece un marco comn del proceso definiendo un pequeo nmero de actividades del marco de trabajo que son aplicables a todos los proyectos del software, independientemente de su tamao o complejidad. Un nmero de conjuntos de tareas, cada uno es una coleccin de tareas, hitos y puntos de garanta de calidad SQA (Software Quality Assurance), permiten que las actividades se adapten a las caractersticas del proyecto del software y a los requisitos del equipo del proyecto.

Marco de trabajo comn del proceso Actividades del marco de trabajo Conjuntos de tareas
tareas Hitos, entregas Puntos SQA

Figura No. 1.8. El proceso del software MTODOS Los mtodos de la ingeniera del software indican cmo construir tcnicamente el software. Incluyen tareas como: planificacin y estimacin de proyectos, anlisis de los requerimientos del software, diseo de procesos, diseo de bases de datos, arquitectura de programas y procedimientos, codificacin, pruebas y mantenimiento. Los mtodos introducen frecuentemente una notacin especial orientada a un lenguaje o grficos.

INGENIERA DE SOFTWARE I Ing. Jonny Guaia Y.

HERRAMIENTAS Las herramientas de la ingeniera de software suministran un soporte automtico o semiautomtico para los mtodos. Hoy existen herramientas para soportar cada uno de los mtodos mencionados anteriormente. Cuando se integran las herramientas de tal forma que la informacin creada por una herramienta pueda ser usada por otra, se establece un sistema para el soporte de desarrollo de software, llamado Ingeniera del Software Asistida por Computadora (CASE: Computer Arded Software Engineering). CASE combina software, hardware y bases de datos sobre ingeniera del software (contiene informacin relevante sobre el anlisis, diseo y codificacin). Dentro de las herramientas que se podran utilizar en el proceso de desarrollo de software tenemos: TABLA No. II Principales herramientas usadas en el desarrollo de software AREA DE APLICACIN Planificacin Diseo de procesos Diseo de base de datos Anlisis y Diseo Orientado a Objetos Especificacin de Requerimientos HERRAMIENTA Ms. Project Process Analyst (Power Designer) Weilan Le Case BPWin Easy ER ERWin Data Arquitect (Power Designer) Rational Rose Visual UML Object Domain Rational Requisite Pro

CAPITULO II CICLO DE VIDA DEL DESARROLLO DE SOFTWARE GENERALIDADES Las organizaciones pequeas tienden a ser relativamente informales; los proyectos de desarrollo de sistemas nacen de conversaciones entre el usuario y el administrador del proyecto (que puede ser a la vez analista, programador, operador, etc) y el procede desde el anlisis hasta la implementacin sin ningn problema. Sin embargo, en las organizaciones ms grandes las cosas se llevan a cabo de una forma mucho ms formal, la comunicacin entre los usuarios, la administracin y el equipo del proyecto suele ser por escrito.

Actualmente, tanto las organizaciones grandes como las pequeas estn adoptando un ciclo de vida uniforme para sus proyectos. Esto a veces se conoce como: Plan del Proyecto, Metodologa del Desarrollo de sistemas, Ciclo de vida del desarrollo de sistemas; Modelos del Proceso de Software, Paradigmas de la Ingeniera de software; que proporciona un procedimiento comn a seguir para desarrollar un sistema informtico que puede orientar a cualquier miembro de la organizacin en el desarrollo de sistemas.

De lo anteriormente expuesto se puede decir que: El ciclo de vida del desarrollo de sistemas, es un proceso por el cual los analistas de sistemas, los ingenieros de software, los programadores y los usuarios finales elaboran sistemas de informacin y aplicaciones informticas. Es una herramienta de gestin de proyectos que planea, ejecuta y controla los proyectos de desarrollo de sistemas.

2.1

PRINCIPIOS GENERALES

Los principios generales que deberan sostener todos los desarrollos de sistemas son los siguientes:

Implicar al usuario Aplicar un mtodo de resolucin de problemas. El mtodo clsico es el siguiente: Identificar el problema (u oportunidad de mejora) Comprender el contexto del problema y las causas y efectos del mismo Definir los requisitos para alcanzar una solucin adecuada Hallar soluciones alternativas Elegir la mejor solucin Disear e implementar la solucin Observar y evaluar el impacto de la solucin Definir fases y actividades Establecer normas para un desarrollo y una documentacin consistentes Justificar los sistemas como inversiones de capital Dividir el sistema si el caso lo amerita Disear sistemas que puedan crecer o cambiar

INGENIERA DE SOFTWARE I Ing. Jonny Guaia Y.

2.2

MODELOS DE PROCESO DE SOFTWARE

En este punto se tratan diferentes modelos de procesos para la ingeniera de software, que se los ha clasificado de la siguiente manera: Modelos Tradicionales o Modelo Genrico o Modelo Secuencial (Cascada o Waterfall) o Modelo de Construccin de Prototipos Modelos Evolutivos o Modelo en Espiral o Modelo Incremental Modelos giles o DRA (Desarrollo Rpido de Aplicaciones RAD Rapid Application Development) o MSF (Microsoft Solutios Framework) o RUP (Rational Unified Process) o XP (Extrem Programming)

Los modelos aqu expuestos, no son todos, pero s los ms difundidos; a continuacin detallaremos los ms importantes. 2.2.1 MODELO GENERICO DE DESARROLLO DE SOFTWARE

El proceso de desarrollo de software tiene tres fases genricas; independientemente del paradigma elegido, del rea de aplicacin, del tamao del proyecto o de la complejidad, estas son: Definicin Desarrollo Mantenimiento.

DEFINICION La fase de definicin se centra sobre el qu. En esta fase se intenta identificar los requisitos claves del sistema y del software: Qu informacin ser procesada Qu funcin y rendimiento se desea Qu interfaces se van a establecer Qu criterios de validacin se necesita

Los pasos a realizarse en esta fase son los siguientes: Anlisis del Sistema: Define el papel de cada elemento del sistema informtico, asignando finalmente al software el papel que va a desempear. Planificacin del proyecto de software: Se analizan riesgos, se asignan recursos, se estiman costos, se definen las tareas y se planifica el trabajo. Anlisis de Requisitos: Obtener informacin ms detallada del mbito de informacin y de funcin del software. DESARROLLO La fase de desarrollo se centra en el cmo, durante esta fase el que desarrolla el software deber determinar: Cmo disear las estructuras de datos y la arquitectura del software Cmo se implementan los detalles procedimentales Cmo se traduce el diseo a un lenguaje de programacin. Cmo se realizan las pruebas

Los pasos que se realizan en esta fase son los siguientes: Diseo del Software: El diseo traduce los requisitos del software a un conjunto de representaciones que describen la estructura de los datos, la arquitectura, el procedimiento algortmico y las caractersticas de la interfaz. Codificacin: Es la traduccin del diseo a un lenguaje de programacin. Prueba del software: Una vez que el software ha sido implementado en un lenguaje de programacin, ste debe ser probado para descubrir los errores que puedan existir en la funcin, en la lgica y en la implementacin.

MANTENIMIENTO

INGENIERA DE SOFTWARE I Ing. Jonny Guaia Y.

La fase de mantenimiento se centra en el cambio que va asociado a la correccin de errores, a las adaptaciones requeridas por la evolucin del entorno del software y las modificaciones debidas a los cambios de los requisitos del cliente dirigidos a reforzar o ampliar el sistema. La fase de mantenimiento vuelve a aplicar los pasos de las fases de definicin y desarrollo, pero en el contexto de un software ya existente. Durante la fase de mantenimiento se encuentran tres tipos de cambios: Correccin: Permite determinar los defectos del software. El mantenimiento correctivo cambia el software para corregir estos defectos. Adaptacin: Con el paso del tiempo es probable que cambie el entorno original para el que se desarroll el software (sistema operativo, perifricos, etc). El mantenimiento adaptativo permite modificar el software para acomodarlo a los cambios de su entorno externo. Mejora: Cuando el cliente propone funciones adicionales que deben ser incorporadas en el software. El mantenimiento perfectivo ampla el software ms all de sus requisitos funcionales originales Prevencin: El software se deteriora debido al cambio, y por esto el mantenimiento preventivo tambin llamado reingeniera de software, en esencia, hace cambios en los programas a fin de que se puedan corregir, adaptar y mejorar ms fcilmente. 2.3.2 MODELO SECUENCIAL

El Modelo Secuencial, llamado tambin Modelo en Cascada o Waterfall, exige un enfoque sistemtico y secuencial del desarrollo del software. Este paradigma abarca las actividades representadas en la Figura No. 2.1
Ingeniera del Sistema Anlisis Diseo Codificacin Prueba

Figura No. 2.1. Modelo Secuencial

Mantenimiento

Ingeniera y Anlisis del Sistema Establecer los requisitos de todos los elementos del sistema Asignar algn subconjunto de estos requisitos al software Este planteamiento del sistema es esencial cuando el software debe interrelacionarse con otros elementos tales como: hardware, personas, bases de datos Abarca los requisitos globales a nivel del sistema con una pequea cantidad de anlisis y de diseo a un nivel superior

Anlisis de los requisitos del software Se centra en la especificacin de requisitos para el software El analista debe comprender, el mbito de la informacin del software, as como la funcin, el rendimiento y las interfaces requeridas. Los requisitos tanto del sistema como del software se revisan con el cliente.

Diseo Se enfoca sobre los siguientes atributos del programa: Estructura de los datos Detalle procedimental Diseo de las interfaces Arquitectura del software

El diseo es una representacin del software, de tal forma que se obtenga la calidad requerida antes de que se inicie la codificacin.

Codificacin La codificacin es la traduccin del diseo a un lenguaje de programacin.

INGENIERA DE SOFTWARE I Ing. Jonny Guaia Y.

Prueba Las pruebas se centran en la lgica interna del software; las pruebas deben asegurar que la entrada definida produzca los resultados que realmente se requieren.

Mantenimiento Ocurren despus que el software se entregue al cliente. Los cambios ocurren debido a: Que se encuentran errores Que el software debe adaptarse a cambios del entorno externo (por ejemplo: uso de un nuevo perifrico) Ampliaciones funcionales o de rendimiento requeridas por el cliente. El mantenimiento aplica cada uno de los pasos del ciclo de vida a un programa existente en vez de a uno nuevo.

PROBLEMAS DEL MODELO Los proyectos reales raramente siguen un flujo secuencial que propone el modelo. problemas en la aplicacin del paradigma. Siempre hay iteraciones y se crean

Normalmente, es difcil para el cliente establecer explcitamente al principio todos los requisitos. El cliente debe tener paciencia, hasta llegar a las etapas finales del desarrollo, no existir una versin operativa del programa.

VENTAJAS Son similares a los pasos genricos aplicables a todos los paradigmas de la ingeniera del software.

2.3.3 CONSTRUCCION DE PROTOTIPOS Un cliente normalmente define un conjunto de objetivos generales para el software, pero no identifica los requerimientos detallados de entrada, proceso o salida y el programador no puede estar seguro de la eficiencia de los programas o de la forma de la correcta interaccin hombre-mquina. En estas situaciones puede ser un mejor mtodo de ingeniera del software la construccin de un prototipo.

La construccin de prototipos es un proceso que facilita al programador la creacin del modelo de software a construir. Los prototipos pueden ser:

Prototipo que describa la interaccin hombre-mquina (entradas y salidas) Prototipo que implementa algunas funciones requeridas por el usuario Un programa existente que ejecute parte o toda la funcin deseada, pero que tenga otras caractersticas que deben ser mejoradas en el nuevo sistema.

La Figura No. 2.2 muestra los pasos a seguir en la aplicacin del paradigma de construccin de prototipos.

Inicio Fin
Recoleccin y Refinamiento de Requisitos

Producto de Ingeniera

Diseo Rpido

Refinamiento del Prototipo

Construccin del Prototipo Evaluacin del Prototipo por el Cliente

Figura No. 2.2. Modelo de Construccin de Prototipos

INGENIERA DE SOFTWARE I Ing. Jonny Guaia Y.

10

La construccin de prototipos comienza con la recoleccin de requisitos, en esta etapa, el tcnico y el cliente se renen y definen los objetivos globales para el software, identifican todos los requisitos conocidos y perfilan las reas en donde ser necesario un mayor definicin. Luego se produce un diseo rpido que se enfoca sobre la presentacin de los aspectos del software visibles al usuario (por ejemplo, mtodos de entrada y formatos de salida). El diseo rpido conduce a la construccin de un prototipo. El prototipo es evaluado por el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. Se produce un proceso interactivo en el que el prototipo es afinado de tal forma que satisfaga las necesidades del cliente. PROBLEMAS DEL MODELO El cliente ve funcionando lo que parece ser una primera versin del software. El ignora que se han obviado muchos aspectos de calidad del software. Cuando se le informa que el producto debe ser reconstruido, el cliente puede solicitar que se apliquen nuevas mejoras, que no estuvieron planificadas al inicio. El cliente y el tcnico deben estar de acuerdo en que el prototipo servir solo como mecanismo de definicin de requisitos, posteriormente debe ser descartado y debe construirse el software real. El tcnico de desarrollo puede utilizar un sistema operativo o un lenguaje de programacin inadecuado para demostrar las capacidades del prototipo; despus de algn tiempo, el tcnico puede haberse familiarizado con esta herramienta y puede llegar a formar parte integral del sistema. Los prototipos suelen pasar las fases de anlisis y diseo con demasiada rapidez. Ello empuja al analista a pasar demasiado rpido a la codificacin, sin haber comprendido bien las necesidades y los problemas.

VENTAJAS 2.3.4 Los usuarios se hacen participantes ms activos en el desarrollo de sistemas El prototipo sirve como mecanismo para identificar los requisitos del software Para hacer un prototipo se usa fragmentos de programas existentes o aplica herramientas que facilitan la rpida generacin de programas. MODELO EN ESPIRAL

El modelo en espiral ha sido desarrollado para cubrir las mejores caractersticas tanto del ciclo de vida clsico como de la creacin de prototipos; aadiendo un nuevo elemento que es el Anlisis de Riesgos. El modelo en espiral define cuatro actividades principales:

Planificacin. Determinacin de objetivos, alternativas y restricciones Anlisis de riesgo. Anlisis de alternativas e identificacin y resolucin de riesgos Ingeniera. Desarrollo del producto de siguiente nivel. Evaluacin del cliente. Valoracin de los resultados de la ingeniera.

Recoleccin de requisitos y planificacin del proyecto iniciales

PLANIFICACION

ANALISIS DE RIESGO

Anlisis de riesgo basado en los requisitos iniciales Anlisis de riego reaccin del cliente basado en la

Planificacin basada en los comentarios del cliente

Decisin de seguir o no

Hacia el sistema final

Prototipo inicial del software Evaluacin del cliente

EVALUACION INGENIERIA DEL CLIENTE Figura No. 2.3. Modelo en Espiral

Prototipo del siguiente nivel Sistema de ingeniera

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. Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones y 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 definir ms el problema y refinar los requisitos. El cliente evala el trabajo de ingeniera y sugiere modificaciones. En base a los comentarios del cliente se produce la siguiente fase de planificacin y de anlisis de riesgo. Si los riesgos son demasiado grandes, se puede dar por terminado el proyecto; Sin embargo en la mayora de los casos se sigue avanzando a travs de la espiral y ese camino lleva a un modelo ms completo del sistema.

INGENIERA DE SOFTWARE I Ing. Jonny Guaia Y.

11

Cada vuelta alrededor de la espiral requiere ingeniera que se puede llevar a cabo mediante el enfoque del ciclo de vida clsico o de la creacin de prototipos PROBLEMAS Requiere de una considerable habilidad para valorar el riesgo, ya que si no se descubre un riesgo importante, pueden surgir problemas.

VENTAJAS El modelo en espiral es actualmente el enfoque ms realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniera de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Permite a quien lo desarrolla aplicar el enfoque de creacin de prototipos en cualquier etapa de la creacin del producto. 2.3.5 Nos ayuda a reducir los riesgos antes de que se conviertan en problemas. MODELO INCREMENTAL

El Modelo incremental combina elementos del modelo secuencial con la filosofa interactiva del la construccin de prototipos. Como muestra la Figura No. 2.4, el modelo incremental aplica secuencias lineales en forma escalonada durante el transcurso del tiempo.

Ingeniera de sistemas de informacin

Incremento 1 Entrega del 1er incremento

Anlisis

Diseo

Cdigo

Pruebas

Incremento 2

Anlisis

Diseo

Cdigo

Pruebas

Entrega del 2do incremento

Incremento 3

Anlisis

Diseo

Cdigo

Pruebas

Entrega del 3er incremento

tiempo

Figura No. 2.4. Modelo Incremental Cada secuencia produce un incremento del software. El primer incremento a menudo es un producto esencial (ncleo), generalmente orientado a la gestin de la base de datos. El cliente utiliza el producto central y como resultado de su utilizacin y/o evaluacin se desarrolla un plan para el incremento siguiente. El plan afronta la modificacin del producto central para implementar 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 se centra en la entrega de un producto operacional con cada incremento, que lo diferencia del modelo de construccin de prototipos.. Este mtodo es til cuando no existe personal disponible para la una implementacin completa. Los primeros incrementos se puede implementar con menos personas; luego se podra incrementar ms personal para el desarrollo de los incrementos siguientes. Los incrementos se pueden plantear para gestionar riesgos tcnicos, por ejemplo, un sistema podra requerir la disponibilidad de hardware nuevo; podra ser posible planificar primeros incrementos de forma que se evite la utilizacin de este hardware y por lo tanto, el proyecto no sufrira retrasos exagerados. 2.3.6 DESARROLLO RPIDO DE APLICACIONES

El Desarrollo Rpido de Aplicaciones (DRA) es una adaptacin a alta velocidad del proceso de desarrollo del software lineal secuencial, que enfatiza un ciclo de desarrollo extremadamente corto. En el modelo DRA se logra un desarrollo rpido utilizando un enfoque de construccin basado en componentes. Si se comprenden bien los requisitos y se limita bien el mbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional dentro de perodos cortos de tiempo ( por ejemplo de 30 a 60 das).

INGENIERA DE SOFTWARE I Ing. Jonny Guaia Y.

12

Equipo No E ipo No qu Eq uipo No

Md o elad d o e G esti n Md o elad d o e D s ato Md o elad d o e P ceso ro s G eraci en n d e A licacio es p n P eb y ru as en treg a

.3

.2

M d la o d o e d e Gs n e ti

. 1

M odelado de G stin e M odelado de D atos M odelado de P roces os

M d la o d oe d e D to a s

M d la o d o e d e P cs s ro e o G n ra i ee c n d e A lic c n s p a io e P ea y ru b s e tre a n g

G enera cin de A aciones plic P bas y rue entrega

De 60 a 9 das 0

Figura No. 2.5. Modelo DRA DRA comprende las siguientes fases: Modelado de Gestin Responde a preguntas como: Qu informacin conduce el proceso de gestin?, Qu informacin se genera?, Quin lo genera? A dnde va la informacin? Quin la procesa?. Modelado de Datos El flujo de informacin definido en la fase de modelado de gestin se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen los atributos de cada uno de los objetos y las relaciones entre estos objetos. Modelado del Proceso En esta fase se implementa las funciones de gestin. Las descripciones del proceso se crean para aadir, modificar, suprimir o recuperar un objeto de datos. Gestin de Aplicaciones En esta fase se asume la utilizacin de tcnicas de cuarta generacin, el proceso DRA vuelve a utilizar componentes de programas ya existentes o crear componentes reutilizables. Se utilizan herramientas CASE para facilitar la construccin del software. Pruebas y entrega El hecho de enfatizar en la reutilizacin de componentes reduce el tiempo de pruebas; sin embargo se deben probar todos los componentes nuevos y las interfases. Las limitaciones de tiempo impuestas por DRA demandan un mbito de escalas, como se muestra en la Figura No. 2.5. Si una aplicacin puede modularse de forma que permita completarse cada una de las funciones principales en menos de tres meses, es un candidato DRA. Cada una de las funciones pueden ser afrontadas por un equipo DRA diferente y ser integradas en un solo conjunto. PROBLEMAS DEL MODELO Para proyectos grandes, DRA requiere recursos humanos suficientes como para crear el nmero correcto de equipos para desarrollar el proyecto. DRA requiere clientes y desarrolladores comprometidos en las rpidas actividades, si no hay compromiso, el proyecto DRA fracasar. Si un sistema no puede modularizarse adecuadamente, ser problemtico aplicar DRA.

DRA no es adecuado cuando los riesgos tcnicos son altos; esto ocurre cuando una nueva aplicacin hace uso de tecnologas nuevas o cuando el nuevo software requiere un alto grado de interoperatividad con sistemas ya existentes 2.3.7 PROCESO UNIFICADO DE RATIONAL

En este punto se resume los elementos del Proceso Unificado de Rational propuesto por Booch; es uno de los enfoques del ciclo de vida que se adapta especialmente bien a UML. Consta de las cuatro fases siguientes:

INGENIERA DE SOFTWARE I Ing. Jonny Guaia Y.

13

FASE Iniciacin Elaboracin Construccin Transicin

OBJETIVO Establecer la planificacin del proyecto Establecer un plan para el proyecto y una arquitectura correcta Desarrollar el sistema Proporcionar el sistema a sus usuarios finales

Las fases de iniciacin y elaboracin incluyen las actividades de diseo del ciclo de vida del desarrollo; la construccin y la transicin constituyen su produccin. Dentro de cada fase hay varias iteraciones. Una iteracin representa un ciclo de desarrollo completo, desde la captura de requisitos en el anlisis hasta la implementacin y pruebas, que produce como resultado la entrega al cliente o la salida al mercado de un proyecto ejecutable. Cada fase e iteracin se centra en disminuir algn riesgo y concluye con un hito bien definido. La revisin de hitos es el momento adecuado para evaluar cmo se estn satisfaciendo los objetivos y si el proyecto necesita ser reestructurado de alguna forma para continuar. Iniciacin. Durante esta fase se establece la planificacin del proyecto y se delimita su alcance. La planificacin del proyecto incluye los criterios de xito, la evaluacin del riesgo, estimaciones de recursos que se necesitarn y un plan de fases que muestre la planificacin de los hitos principales. Durante la iniciacin es frecuente crear un prototipo ejecutable que sirva para probar los conceptos. Al final de la fase de inicio se examinan los objetivos del ciclo de vida del proyecto y se decide si proceder con el desarrollo del sistema. Elaboracin. Los objetivos de esta fase son analizar el dominio del problema, establecer una base arquitectnica slida, desarrollar el plan del proyecto y eliminar los elementos de ms alto riesgo del proyecto. Las decisiones arquitectnicas deben tomarse con una comprensin del sistema global. Esto implica que se deben describir la mayora de los requisitos del sistema. Para verificar la arquitectura, se implementa un sistema que demuestre las distintas posibilidades de la arquitectura y se ejecute los casos de uso significativos. Construccin. Durante la fase de construccin se desarrolla de formas iterativa e incremental un producto completo que est preparado para la transicin hacia los usuarios. Esto implica describir los requisitos restantes y los criterios de aceptacin, refinando el diseo. Completando la implementacin y las pruebas del software. Al final de la fase de construccin se decide si el software, los lugares donde se instalar y los usuarios, estn todos preparados para empezar a funcionar. Transicin. Durante la fase de transicin, el software se despliega en los usuarios. Una vez que el sistema ha sido puesto en manos de los usuarios finales, a menudo aparecen aspectos que requieren un desarrollo adicional para ajustar el sistema, corregir algunos problemas no detectados o finalizar algunas caractersticas que hayan sido propuestas. Esta fase comienza normalmente con una versin beta del sistema que luego ser reemplazada con el sistema de produccin. Al final de la fase de transicin se decide si se han satisfecho los objetivos del ciclo de vida del proyecto, y se determina si se debera empezar otro ciclo de desarrollo. El proceso Unificado de Racional consta de nueve flujos de trabajo:

INGENIERA DE SOFTWARE I Ing. Jonny Guaia Y.

14

FLUJO DE TRABAJO Modelado del negocio Requisitos Anlisis y diseo Implementacin Pruebas Despliegue Gestin de configuraciones Gestin del proyecto Entorno 2.3.8

OBJETIVO Describe la estructura y la dinmica de la organizacin Describe el mtodo basado en casos de uso para extraer los requisitos Describe las diferentes vistas arquitectnicas Tiene en cuenta el desarrollo del software, la prueba de unidades y la integracin Describe los casos de pruebas, los procedimientos y las mtricas para la evaluacin de defectos. Cubre la configuracin del sistema entregable Controla los cambios y mantiene la integridad de los artefactos de un proyecto Describe varias estrategias de trabajo en un proceso iterativo Cubre la infraestructura necesaria para desarrollar el sistema

MICROSOFT SOLUTIONS FRAMEWOK

Microsoft Solutions Framework (MSF) es una serie de conceptos, modelos, disciplinas y prcticas de uso que controlan la planificacin, el desarrollo y la gestin de proyectos tecnolgicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnolgicas. MSF contiene mltiples componentes que pueden ser utilizados individualmente o adoptados como un conjunto integrado. La figura No. 2.4 representa un resumen de estos componentes. Modelos MSF: Es la descripcin esquemtica de la organizacin de equipos y procesos del proyecto: Modelo de Equipo: Este modelo ha sido diseado para mejorar el rendimiento del equipo de desarrollo. Proporciona una estructura flexible para organizar los equipos de un proyecto. Puede ser escalado dependiendo del tamao del proyecto y del equipo de personas disponibles. Modelo de Proceso: Diseado para mejorar el control del proyecto, minimizar el riesgo, y aumentar la calidad acortando el tiempo de entrega. Proporciona una estructura de pautas a seguir en el ciclo de vida del proyecto, describiendo las fases, las actividades, la liberacin de versiones y explicando su relacin con el modelo de equipo
Modelo de Procesos MODELOS Modelo de Equipos

Microsoft Solutions Framework

Administracin del Riesgo Administracin del Proyecto Administracin de Efectividad

DISCIPLINAS

Figura No. 2.4. Modelos y Disciplinas de MSF

Disciplinas MSF: MSF reconoce varias reas no tecnolgicas que son competencias importantes de todos los roles en el Modelo de Equipo de MSF. Son reas que utilizan un conjunto especfico de mtodos, trminos y propuestas, creadas para manejar a las personas, procesos y elementos tecnolgicos que se encuentran en la mayora de los proyectos. Disciplina de Administracin del Riesgo. Define un proceso para identificar y valorar los riesgos en un proyecto, priorizacin de estos riesgos e implementacin de estrategias para combatirlos a lo largo de todo el ciclo de vida de los proyectos. Disciplina de Administracin del Proyecto. Es un rea del conocimiento, habilidades, herramientas y tcnicas usadas para conseguir los objetivos de acuerdo a los parmetros de calidad, costos, planificacin y limitaciones. Disciplina de Administracin de Efectividad. Define a la efectividad como una medida del estado actual versus el estado deseado del conocimiento y habilidades de los miembros de una organizacin. Esta medida es la es la posibilidad real o percibida en algn punto durante el proceso de planeacin, construccin y gestin de la solucin. MODELO DE PROCESO MSF El modelo de procesos de MSF combina los mejores principios de los modelos en cascada y espiral ya que considera la planeacin basada en puntos de revisin o hitos del modelo en cascada y los beneficios de la retroalimientacin y creatividad del modelo en espiral Las cinco fases del modelo de procesos MSF se representa en la Figura No. 2.5 Fase 1: Visin. En esta fase el equipo y el cliente definen los requerimientos del negocio y los objetivos generales del proyecto. La fase culmina con el hito Visin y Alcance aprobados.

INGENIERA DE SOFTWARE I Ing. Jonny Guaia Y.

15

Fase 2: Planeacin. Durante la fase de planeacin el equipo crea un borrador del plan maestro del proyecto, adems de un cronograma del proyecto, escenarios de uso, la especificacin funcional del proyecto y diseo. Esta fase culmina con el hito Plan del proyecto aprobado. Fase 3: Desarrollo. Esta fase involucra una serie de versiones internas del producto, desarrollados por partes para medir su progreso y para asegurarse que todos sus mdulos o partes estn sincronizados y pueden integrarse., adems del desarrollo del cdigo, el equipo implementa la solucin La fase culmina con el hito Alcance completo Figura No. 2.5: Fases y puntos de revisin de MSF Fase 4: Estabilizacin. Esta fase se centra en probar el producto. El proceso de prueba hace nfasis en el uso y el funcionamiento del producto en las condiciones del ambiente real. El equipo se enfoca en la identificacin, priorizacin y resolucin de los problemas para que el producto est listo para el lanzamiento. La fase culmina con el hito Release Readiness aprobado. Fase 5: Implantacin: En esta fase el equipo implanta la tecnologa y los componentes utilizados por la solucin, estabiliza la implantacin, apoya el funcionamiento y la transicin del proyecto, y obtiene la aprobacin final del cliente. La fase termina con el hito Implantacin completa.
E D SE IN FA IS V

Implantacin completa
PL FAS A E N D TA E C I N

Release Readiness aprobado

IM

Visin y alcance aprobados

Alcance completo FASE DE DESARROLLO

Plan del proyecto aprobado

INGENIERA DE SOFTWARE I Ing. Jonny Guaia Y.

F AS P L A E DE NE A CIN

ES DE IN SE AC FA ILIZ B TA

16