Nombre unidad:Introduccion a la Ingenieria de software Alumno: Hernn Rivera Melendrz Numero de control: 06060026 Tequila, Jalisco Marzo 26 del

2010

Introduccin de ingeniera de software

Este trmino fue introducido a finales de los 60 a raz de la crisis del software. Esta crisis fue el resultado de la introduccin de la tercera generacin del hardware. El hardware dejo de ser un impedimento para el desarrollo de la informtica; redujo los costos y mejoro la calidad y eficiencia en el software producido La crisis se caracterizo por los siguientes problemas:
y y y

Imprecisin en la planificacin del proyecto y estimacin de los costos. Baja calidad del software. Dificultad de mantenimiento de programas con un diseo poco estructurado, etc.

Por otra parte se exige que el software sea eficaz y barato tanto en el desarrollo como en la compra. Tambin se requiere una serie de caractersticas como fiabilidad, facilidad de mantenimiento y de uso, eficiencia, etc.

Importancia del software

El software est compuesto por un conjunto de instrucciones que un ordenador ejecuta para poder realizar una funcin especfica. Para entender la importancia del software se podran poner varios ejemplos. A finales de los 90 pudimos ver en todo el mundo la preocupacin por parte de empresas y gobiernos por las repercusiones que poda tener el llamado efecto 2000. El ya famoso error informtico era causado por el hecho de que muchos programas almacenaban la parte de la fecha correspondiente al ao usando nicamente dos dgitos, de tal forma, que despus del ao 99 (el 1999) podamos pasar al ao 00 (ao 2000 o ao 1900?) causando todo tipo de errores en el clculo de perodos de tiempo. Los ordenadores de empresas elctricas, centrales nucleares, sistemas de control de aviacin, bancos y, en general, todo el software de uso cotidiano, tuvieron que ser revisados. Finalmente, algunas aplicaciones fueron corregidas, otras ya funcionaban correctamente y no hubo que lamentar ninguna catstrofe, pero hubo miles de predicciones apocalpticas sobre las consecuencias que poda llegar a tener este error. Y as podra haber sido si no se hubiera reparado a tiempo. Cuando los ingenieros de software nos hallamos ante un programa que no da acceso al cdigo fuente es decir, que no es libre nos encontramos que no lo podemos entender, y por tanto que no lo podramos arreglar aunque hubiramos descubierto un error y conociramos su solucin. Es decir, aunque como profesionales tengamos el remedio, nos vemos incapacitados para aplicarlo.

El software tiene un papel muy destacado en la sociedad y es importante garantizar mtodos transparentes en sus diferentes fases de produccin y explotacin. El software libre, al dar acceso al cdigo, es el nico que puede garantizar esta transparencia.

Historia de la ingeniera de software

La Ingeniera del Software, trmino utilizado por primera vez por Fritz Bauer en la primera conferencia sobre desarrollo de software patrocinada por el Comit de Ciencia de la OTAN celebrada en Garmisch, Alemania, en octubre de 1968, puede definirse segn Alan Davis como la aplicacin inteligente de principios probados, tcnicas, lenguajes y herramientas para la creacin y mantenimiento, dentro de un coste razonable, de software que satisfaga las necesidades de los usuarios. El trmino ingeniera del software empez a usarse a finales de la dcada de los sesenta, para expresar el rea de conocimiento que se estaba desarrollando en torno a las problemticas que ofreca el software en ese momento. En esa poca, el crecimiento espectacular de la demanda de sistemas de computacin cada vez ms y ms complejos, asociado a la inmadurez del propio sector informtico (totalmente ligado al electrnico) y a la falta de mtodos y recursos, provoc lo que se llam la crisis del software (en palabras de Edsger Dijkstra) entre los aos 1965 y 1985. Durante esa poca muchos proyectos importantes superaban con creces los presupuestos y fechas estimados, algunos de ellos eran tan crticos (sistemas de control de aeropuertos, equipos para medicina, entre otros) que sus implicaciones iban ms all de las prdidas millonarias que causaban. La crisis del software pas, no tanto por la mejora en la gestin de los proyectos, sino en parte porque no es razonable estar en crisis ms de veinte aos, y en parte porque se estaban haciendo progresos en los procesos de diseo y metodologas. As pues, desde 1985 hasta el presente, han ido apareciendo herramientas, metodologas y tecnologas que se presentaban como la solucin definitiva al problema de la planificacin, previsin de costes y aseguramiento de la calidad en el desarrollo de software. Entre las que se encuentran la programacin estructurada, la programacin orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de programacin ADA, la documentacin, los

estndares, CORBA, los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la solucin a los problemas de la ingeniera del software, la llamada bala de plata (por silver bullet). Y lo que es ms, cada ao surgen nuevas ideas e iniciativas encaminadas a ello.

Crisis
Se fundament en el tiempo de creacin de software, ya que en la creacin del mismo no se obtenan los resultados deseados, adems de un gran costo y poca flexibilidad. Adems, no existen todava herramientas que permitan estimar de una manera exacta, antes de comenzar el proyecto, cul es el esfuerzo que se necesitar para desarrollar un programa. Este hecho provoca que la mayora de las veces no sea posible estimar cunto tiempo llevar un proyecto, ni cunto personal ser necesario. Cuando se fijan plazos normalmente no se cumplen por este hecho. Del mismo modo, en muchas ocasiones el personal asignado a un proyecto se incrementa con la esperanza de disminuir el plazo de ejecucin. Por ltimo, las aplicaciones de hoy en da son programas muy complejos, inabordables por una sola persona. En sus comienzos se valor como causa tambin la inmadurez de la ingeniera de software, aunque todava hoy en da no es posible realizar estimaciones precisas del coste y tiempo que necesitar un proyecto de software. Englob a una serie de sucesos que se venan observando en los proyectos de desarrollo de software:
y y y y y

Los proyectos no terminaban en plazo. Los proyectos no se ajustaban al presupuesto inicial. Baja calidad del software generado. Software que no cumpla las especificaciones. Cdigo inmantenible que dificultaba la gestin y evolucin del proyecto.

Metas
Las metas son y y y Aumento calidad productos Aumento productividad Satisfaccin profesional

Que abarca el trmino Software y y y Programas Documentacin Instalar |

Mitos
Mito: Si fallamos en la planificacin podemos aadir ms programadores y recuperar el tiempo perdido. Realidad: Ley de Brooks: "Agregar gente a un proyecto atrasado, lo atrasa an ms". Razn: Crear software no es una tarea particionable, como dice el Principio de Brooks: "Gestar a un beb tarda 9 meses, no importa cuntas mujeres sean asignadas a la tarea." Mito: Una declaracin general de los objetivos es suficiente para comenzar a escribir los programas; podemos dar los detalles ms adelante. Realidad: Una mala definicin inicial es la principal causa del trabajo esencial una descripcin formal y detallada del mbito de la funciones, rendimiento, interfaces y criterios de validacin. Esto determinarse despus de una exhaustiva comunicacin entre el analista. Ver siguiente mito. en vano. Es informacin, solo puede cliente y el

Mito: Los requisitos del proyecto cambian continuamente pero los cambios pueden acomodarse fcilmente. Realidad: El impacto del cambio vara segn el momento en el que se introduzca: Mito: Una vez que hicimos el programa y funciona, nuestro trabajo ha terminado.

Realidad: Los datos industriales indican que entre el 50% y el 70% de todo el esfuerzo dedicado a un programa se realizar despus de que se le haya entregado al cliente por primera vez. Mito: No hay forma de comprobar la calidad del software hasta que esta corriendo.

Realidad: Hay tcnicas que se pueden aplicar desde el principio. Y ese es el objetivo de la ingeniera de software y del curso.

Paradigma de ingeniera
La ingeniera de software est compuesta por una serie de pasos de abarcan los mtodos, las herramientas y los procedimientos antes mencionados. Estos pasos se denominan frecuentemente paradigmas de la ingeniera de software. La eleccin de un paradigma para la ingeniera de software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicacin, los mtodos, herramientas a usar, los controles y entregas requeridos. Gama de paradigmas de la ingeniera de software:

Modelos de ciclo de vida

Definicin de un Modelo de Ciclo de Vida Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transicin asociadas entre estas etapas. Un modelo de ciclo de vida del software:
y y y y

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.

As, los modelos por una parte suministran una gua para los ingenieros de software con el fin de ordenar las diversas actividades tcnicas en el proyecto, por otra parte suministran un marco para la administracin del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.

Ciclo de vida clsico (cascada).

En Ingeniera de software el desarrollo en cascada, tambin llamado modelo en cascada, es el enfoque metodolgico que ordena rigurosamente las etapas del ciclo de vida del software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la inmediatamente anterior. Un ejemplo de una metodologa de desarrollo en cascada es: 1. 2. 3. 4. 5. 6. 7. Anlisis de requisitos Diseo del Sistema Diseo del Programa Codificacin Pruebas Implantacin Mantenimiento

De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la

metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria, sigue siendo el paradigma ms seguido al da de hoy.

Creacin de prototipos
En Ingeniera de software el desarrollo con prototipacin, tambin llamado modelo de prototipos que pertenece a los modelos de desarrollo evolutivo, se inicia con la definicin de los objetivos globales para el software, luego se identifican los requisitos conocidos y las reas del esquema en donde es necesaria ms definicin. Entonces se plantea con rapidez una iteracin de construccin de prototipos y se presenta el modelado (en forma de un diseo rpido). El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles para el cliente o el usuario final (por ejemplo, la configuracin de la interfaz con el usuario y el formato de los despliegues de salida). El diseo rpido conduce a la construccin de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar. La interaccin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo. Ventajas
y

Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humano-mquina.

Incremental
Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir slo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construccin siempre incrementando subconjuntos de requerimientos del sistema. Tpicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo. Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma especfica de observar el desarrollo

de algn otro incremento. As, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:
y

Construir un sistema pequeo es siempre menos riesgoso que construir un sistema grande. Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si los requerimientos planeados para los niveles subsiguientes son correctos. Si un error importante es realizado, slo la ltima iteracin necesita ser descartada.

Espiral
El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Adems, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos: y y Determinar qu quieres lograr. Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor. Seguir la alternativa seleccionada en el paso 2. Establecer qu tienes terminado.

y y

Observemos un escenario particular. Digamos que en este proyecto, nosotros viajaremos a resolver un conjunto particular de problemas del cliente. Durante el primer viaje alrededor de la espiral, analizamos la situacin y determinamos que los mayores riesgos son la interfaz del usuario. Despus de un cuidadoso anlisis de las formas alternativas de direccionar esto (por ejemplo, construir un sistema y esperar lo mejor, escribir una especificacin de requerimientos y esperar que el cliente lo entienda, y construir un prototipo), determinamos que el mejor curso de accin es construir un prototipo. Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con retroalimentacin til. Ahora, comenzamos el segundo viaje alrededor de la espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos nuevos requerimientos comiencen a aparecer slo despus de que el sistema sea desplegado. Analicemos las rutas alternativas, y decidimos que la mejor aproximacin es construir un incremento del sistema que satisfaga slo los requerimientos mejor entendidos. Hagmoslo ya. Despus del despliegue, el cliente nos provee de retroalimentacin que dir si estamos correctos con esos

requerimientos, pero 50 nuevos requerimientos ahora se originarn en las cabezas de los clientes. Y el tercer viaje alrededor de la espiral comienza. El modelo espiral captura algunos principios bsicos:
y y

Decidir qu problema se quiere resolver antes de viajar a resolverlo. Examinar tus mltiples alternativas de accin y elegir una de las ms convenientes. Evaluar qu tienes hecho y qu tienes que haber aprendido despus de hacer algo. No ser tan ingenuo para pensar que el sistema que ests construyendo ser "EL" sistema que el cliente necesita, y Conocer (comprender) los niveles de riesgo, que tendrs que tolerar.

El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles. y Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo. Si un error importante es realizado, el incremento previo puede ser usado. Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del prximo incremento.

y y

Tcnica de cuarta generacin

El termino de tcnicas de cuarta generacin (T4G) Abarca un amplio espectro de herramientas de software que tienen algo en comn: todas facilitan al ingeniero del software la especificacin de algunas caractersticas del software a alto nivel. Luego, la herramienta genera automticamente el cdigo fuente basndose en la especificacin del tcnico. Cada vez parece ms evidente que cuanto mayor sea el nivel en la que se especifique el software, mas rpido se podr conseguir el programa. El paradigma T4G para la ingeniera del software se orienta hacia la posibilidad de especificar el software o notaciones graficas que describan el problema que hay que resolver en trminos que los entienda el cliente. Herramientas de T4G

Actualmente, un entorno para el desarrollo de el software que soporte el paradigma T4G puede incluir todas o algunas de las siguientes herramientas: y y y y y y y Lenguajes no proced mentales de consulta a bases de datos. Generacin de informes. Manejo de datos. Interaccin y definicin de pantallas. Generacin de cdigos. Capacidades grficas de alto nivel. Capacidades de hoja de clculo.

Las tcnicas de la cuarta generacin ya se han convertido en una parte de suma importancia para el desarrollo del software. Cuando se combinan con enfoques de ensamblaje de componentes, el paradigma de la cuarta generacin se puede convertir en el enfoque dominante hacia el desarrollo del software. Consejo Aunque se usen T4G se debe hacer anlisis, diseo y pruebas (sino mala calidad, mantenimiento pobre, baja aceptacin por el cliente).

Combinacin de prototipos.

Biografas
http://www.mitecnologico.com/Main/HistoriaIngenieriaSoftware http://es.wikipedia.org/wiki/Crisis_del_software http://eclases.tripod.com/id11.html http://148.202.148.5/cursos/cc321/fundamentos/unidad1/tema1_2.htm http://www.monografias.com/trabajos5/inso/inso.shtml#intro http://html.rincondelvago.com/el-ciclo-de-vida-del-software.html http://es.wikipedia.org/wiki/Desarrollo_en_cascada http://es.wikipedia.org/wiki/Modelo_de_prototipos