Tema 1.1 Ingeniería de software

Presentación del tema: "Tema 1.1 Ingeniería de software"— Transcripción de la presentación:

1 Tema 1.1 Ingeniería de software
Luis Fernández Sanz Universidad Europea de Madrid [PRESSMAN, 1997] Roger S. Pressman, Ingeniería del software. Un enfoque práctico. 4ª Ed. McGraw-Hill, 1997. [BAUER, 1993] Fiedrich L. Bauer, “Foreword” en Richard H.Thayer y Andrew D. McGEttrick (eds.), Software Engineering. A European Perspective, IEEE, 1993, p. vi [SOMMERVILLE, 1995] Ian Sommerville, Software Engineering, 5ª Ed., Addison-Wesley, 1995. [IEEE, 1990] IEEE, Computer Dictionary. IEEE std. 610, IEEE, 1990. [Webster, 1983] Webster, Webster’s Encyclopedic Unabridged Dictionary of the English Language, Gramercy Books, 1983. [ACARD, 1986] ACARD (Advisory Council for Applied Research and Development), Software. A vital key to UK competitiveness, Her Majesty’s Stationery Office, 1986 [MCGETTRICK, 1993] Andrew D. McGettrick, “Annotated bibliography on software engineering texts” en Richrad H.Thayer y Andrew D. McGEttrick (eds.), Software Engineering. A European Perspective, IEEE, 1993. [NAUR ET AL., 1976 ] Peter Naur, Brian Randell y J.N.Buxton, Software Engineering. Concepts and techniques. Proceedings of the NATO Conferences, Petrocelli, Nueva York, 1976. [JONES, 1998] T. Capers Jones, Estimating software costs, McGraw-Hill, 1998. [HUMPHREY, 1995] Watts S. Humphrey, A discipline for software engineering, Addison-Wesley, 1995. [HUMPHREY, 1997] Watts S. Humphrey, An introduction to the personal software process, Addison-Wesley, 1997. [SHAW, 1994] Mary Shaw, “prospects for an engineering discipline of software” en Marciniak, Software Engineering Encyclopedia, IEEE, 1994, pp [NORRIS Y RIGBY, 1992] Mark Norris y Peter Rigby, Software Engineering Explained, Wiley and Sons, 1992. Ingeniería de software

2 Impacto de la información
Importancia creciente de los sistemas informáticos económica y socialmente: Dependencia tecnológica de muchos sectores Incorporación en muchos productos y servicios: Gran parte de su coste Gran demanda de software y sistemas Dependencia de gran porcentaje de la economía: Año 2000: 145 billones de pts. economía basada en Internet (766 billones de $). Año 2000: 350 millones de usuarios Internet: media: 29 mail Año 2004: 873 billones de pts.; 376 billones en infraestructura y 496 billones en comercio electrónico Gigi Wang, The Internet Economy, IDC, 2000 (estudio de la consultora IDC: Cifras sobre Internet-driven economy. Ingeniería de software

3 Ingeniería de software
Grandes números Incremento del volumen de información comercial y de gestión cheques diarios en EE.UU. millones de documentos diarios en EE.UU. millones de s diarios Demanda creciente de software: Más grande Más complejo millones de estudio de IDC Ingeniería de software

4 Ingeniería de software
Software demandado Pero: En la mayoría de los casos, sistemas grandes y complejos Meta4: LOC aprox. Windows 95: LOC aprox. UNIX V5: LOC aprox. Sistemas abstractos: Software no tiene forma física (Ley propiedad intelectual RDL 1/1996 art. 95) No restringido por materiales sujetos a leyes físicas ni por procesos de fabricación (SOMMERVILLE, 1995, p.4-5) Dato de Meta4: fuente personal Un montón de datos de aplicaciones en: (Jones, 1998, p. 251) Ingeniería de software

5 Evolución histórica del software
1968 1950 1960 1970 1980 1990 2000 1ª etapa 2ª etapa 3ª etapa 4ª etapa Lotes (batch) Distribución limitada A medida Multiusuario Tiempo real Bases de datos Producto de software Sistemas distribuidos Inteligencia Hardware barato Producto de consumo Redes de ordenadores Orientación a objetos Sistemas personales Paralelismo, sistemas expertos, etc. Complejidad y tamaño crecientes IBM OS360 LOC [PRESSMAN, 1997, pp. 4-5] 1. El software era particular, de andar por casa. No había sistemática y cada programador actuaba de forma artística e individual. Lo importante era el hardware y el software era sólo un añadido, sin existir conciencia de un producto. Existía poca movilidad y la misma persona permanecía en el mismo puesto. El diseño era implícito, en la cabeza del programador. No se daba servicio inmediato al usuario sino que este debía solicitar al CPD algo y esperar al día siguiente a obtenerlo, cuando se había juntado un lote de trabajos iguales para ser procesados con el mismo programa. 2. Aparecen los sistemas multiusuario (tiempo compartido) que permitieron la interacción directa usuario/máquina. El almacenamiento de datos se flexibilizó con el concepto de base de datos y su implementación a partir de finales de los sesenta y principios de los setenta. Ya se distribuían aplicaciones (ej. Sistemas operativos y utilidades) para grandes ordenadores y miniordenadores (que permitieron la extensión a muchas empresa de la informática). Los programas ya tenían decenas o cientos de miles de líneas de código y el mantenimiento se volvía muy complejo ya que muchos programas eran muy personales (sólo los entendía el autor). Surge aquí el concepto de Ingeniería de Software, en 1969. 3. Los sistemas distribuidos y la interconexión de equipos complicó aún más los sistemas. El problema del softwrae se agrava. Con los microprocesadores se incorpora el software a productos de consumo (electrodomésticos, sistemas médicos, etc.) y se produce la explosión de los PC. 4. La interconexión mundial con redes, los entornos cliente/servidor y las potentes máquinas individuales convierten al software en un elemento más valioso que el hardware (ver el caso de Microsoft). Se trata de trabajar con lenguajes 4Gl y con técnicas OO. La IA ha entrado en la práctica. Ingeniería de software

6 Ingeniería de software
Repaso histórico 1967: Comité Científico de la OTAN: “crisis” del software tercera generación de hardware sistemas grandes y/o complejos ineficacia de métodos de desarrollo existentes 1967: F.Bauer propone “ingeniería del software” 1968: Conferencia en Garmisch (RFA) 1969 (Octubre): Conferencia en Roma. Definición Establecimiento y uso de principios de ingeniería robustos Al final de los años sesenta resultaba evidente que existía un desfase entre el mundo del desarrollo de software y la industria del hardware. Ésta última estaba aportando una productividad creciente con mejoras continuas en rendimientos y costes, gracias a la introducción de la tercera generación de ordenadores basados en transistores, circuitos impresos y circuitos integrados. Esta mejora de prestaciones del hardware permitía abordar sistemas grandes y complejos que resultaban imposibles anteriormente. Sin embargo, en el mundo occidental, se veía que el software no seguía el progreso del hardware. Mientras en 1958 las empresas de informática contaban con menos de 50 programadores, ahora tenían El presidente de IBM declaró que el sistema operativo OS/360 requirió uaninversión de 5,000 años/persona e igualaron a los costes de crear una nueva línea de hardware [Naur et al., 1976, p.6]. Los sistemas operativos eran el último grito pero mostraban un inesperada debilidad. Es entonces cuando se aprecia en toda su crudeza la inutilidad dela manera de desarrollar software utilizada hasta entonces para pequeños sistemas y se comienza a trabajar en métodos y procedimientos que mejoren el desarrollo de software. No sirve simplemente con aplicar a mayor escala las técnicas utilizadas en pequeños sistemas para el desarrollo de sistemas grandes y complejos [SOMMERVILLE, 1995, p. 4]. En palabras del propio Friedich L. Bauer [BAUER, 1993], esto se pone oficialmente de manifiesto de manifiesto en una reunión del Comité Científico de la OTAN por el representante de EE.UU., el nobel y físico, Dr. I.I.Rabí. En 1967, se crea un grupo de estudio sobre informática (computer science) para analizar la situación. Se encomienda analizar la situación de toda la informática y hacer una conferencia e, incluso,después, un Instituto de Informática. Bauer es nombrado por el gobierno alemán como representante en este grupo. Parece que el grupo no se centraba en el análisis de la situación sino en discutir todo tipo de prometedores proyectos. Bauer enfadado, indica que el problema viene de que se pelea mucho con el software pero no existe un proceso limpio de fabricación y añade un término mágico y provocativo “ingeniería de software”. Esto choca en el grupo y se convoca una conferencia sobre ingeniería de software en Garmisch (RFA) en Bauer es el secretario y debe crear un programa sobre algo que él ha creado. En la conferencia, E. W.Dijkstra destaca por sus críticas cínicas al mundo del software y por indicar que la corrección depende mucho de la estructura del software y que “probar es una manera muy ineficiente de convencerse de la corrección del software”. Una posterior conferencia en Roma, octubre de 1969, no sólo se habla de la expresión “ingeniería del software” sino que la idea que subyace se adopta con entusiasmo. Dijkstra aporta una frase célebre: “la prueba de software puede usarse para demostrar la presencia de defectos, no su ausencia” [Naur et al., 1976, p. 223]. El instituto de Informática no se crea debido a la resistencia del RU a ser creado en el continente europeo. Ingeniería de software

7 Crisis del software (I)
Planificación y estimación de costes imprecisas Retrasos, sobrecostes, etc. (> 50% proyectos) Baja productividad: 3-6% anual, 12% demanda, hardware dobla en 3 años Baja calidad generalizada: Insatisfacción de usuarios, fallos: Risks to the public Resumen: Chaos Report Ingeniería de software

8 Definición de ingeniería de software
IEEE, 1990: Aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software La aplicación de la ingeniería al software Fritz Bauer, 1969: El establecimiento y uso de principios de ingeniería robustos, para obtener software económico, fiable y que funciona de forma eficiente sobre máquinas reales D.L.Parnas, 1987: Construcción multipersona de software multiversión Definición de [IEEE, 1990, p. 186]: La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software, es decir, la aplicación de la ingeniería al software. Esta expresión también incluye al estudio de los enfoques relativos a lo anterior. La definición original propuesta por Fritz Bauer en la conferencia de 1969 en Roma es la siguiente [PRESSMAN, 1997, p. 17] ** tratar de ver el original **: El establecimiento y uso de principios de ingeniería robustos, orientados a obtener software económico, fiable y que funciona de forma eficiente sobre máquinas reales Otras definiciones insisten en la aplicación de principios científicos [ACARD, 1986] La aplicación de la ingeniería y sus mecanismos, mezclados con la experiencia, al desarrollo de software La aplicación de principios sólidos científicos, matemáticos, de gestión y de ingeniería para la producción de programas correctos (software), a tiempo, en el coste estimado y en un nivel competitivo de rendimiento y precio. ACARD es un grupo que ofrece consejo al gobierno del RU y a organizaciones profesionales. Según se referencia en [MCGETTRICK, 1993] Ingeniería de software

9 Evolución de ingeniería en software
Situación: ciclos de vida, metodología rutinarias, estimación de costes, aseguramiento de calidad Producción estandarizada : algorítmica, estructuras de datos Producción Ciencia Ingeniería profesional Opinión de [Shaw, 1994, p.936]: más que ingeniería de software deberíamos hablar de gestión de software. Figura y opinión de [Shaw, 1994, p.937]. Recordar que la tecnología suele tardar unos 20 años desde que empiezan los trabajos hasta que ayuda rutinariamente en los trabajos diarios. Comercial Ejemplos aislados: construcción compiladores Años ochenta: Metodologías de desarrollo Artesanía Ingeniería de software

10 Disciplina de ingeniería
Ingeniería pública frente a destreza o arte privado Productos: Bien diseñados y planteados Los que terminan funcionando pero tras mucha prueba y corrección Para objetivos de ingeniería de software: Planear, seguir plan, esforzarse por calidad Dominar complejidad: Modelos: simples pero reales División de producto: componentes unipersonales División de proceso: tareas, ciclo de vida [HUMPHREY, 1995, pp. 2-3] Los métodos de desarrollo intuitivos usados hoy son aceptables porque no hay alternativas. La práctica actual sigue siendo más un arte o destreza que una ingeniería. Generalmente cada profesional desarrolla sus propios métodos privados. Algunos profesionales son muy buenos y unos pocos hacen un mal trabajo. La mayoría de los productos terminan funcionando pero después de un gran trabajo de prueba y corrección. Se trata de un proceso impredecible como conjuntos de partículas, donde no se sabe nada de lo que hace cada una sino sólo el comportamiento estadístico del conjunto. Se trata de que los profesionales demuestren su capacidad de seguir el proceso básico marcado más que demostrar creatividad. Después, podrá trabajarse en la creatividad. [HUMPHREY, 1997, p. 3] La disciplina se define como una actividad o ejercicio para desarrollar o mejorar una habilidad, más que una restricción o una obligación. Los deportistas deben practicar en ejercicios antes de pretender ser titulares en el equipo. No se espera que aprendan todo en los partidos más importantes.Los pilotos están muy cualificados antes de su primer vuelo. [HUMPHREY, 1997, p. 1] El trabajo de un ingeniero de software es entregar software de calidad en el precio y plazo acordados. A través de la experiencia, los ingenieros han aprendido a: planear el trabajo, trabajar según el plan y esforzarse por producir productos de calidad. [PRESSMAN, 1997, p. 6] Se trata de adoptar una perspectiva industrial. Superar lo artesanal, la prueba y error, el mundo reservado a “iniciados”. Ingeniería de software

11 Labor de ingeniero de software
Sistemas mayores de lo que abarca una persona Construye un componente, no todo el sistema Otros pueden usar o modificar el componente Obligado a trabajar en equipo Modelos del mundo real en el software Sistemas grandes y complejos: modelos grandes, abstractos y complejos Visibles: uso de documentos (diseño, manuales,…) Crear documentos: igual de ing. de software que programar Meta4 (260 en I+D: 120 en desarrollo) 2 años de proyecto: análisis (4 meses), diseño (4,5), implementación (7,5), integración (6,5) (Schach, 1996, p. 13) Porcentajes de proyectos obtenidos de (Grady, 1994) y otros más antiguos. Perfiles de trabajo: Career-Space Ingeniería de software

12 Ingeniería de software
Trabajo en proyectos (Jones, 1991) Obtenido de tablas de puntos de función multiplicando por 100 LOC/PF Ingeniería de software

13 Ingeniería de software
Áreas tecnológicas Desarrollo de aplicaciones y software Operating systems (PC, Workstations and Consumer Devices) Programming languages (Assembler, C, JAVA, etc.) Embedded Systems (e.g. in Disc-players, TV’s, Game-players) Enterprise IT systems (e.g. Enterprise Resource planning) Internet applications (like E-commerce Administrative and Financial systems Technical systems for machine control and industrial automation Development tools for system and application software Database systems for data-exchange with the applications Network technology in real-time systems and multi-site environm. Software engineering Software components technology Enhance and maintain the application Knowledge of the software technologies on which modern systems are based (e.g. operating systems, programming languages). Able to architect, design and develop individual components or major products. Understands the theories underlying these components.Understand how applications use the services of operating systems and concepts such as processors, working storage, message passing, and transactions processing. Career-space Ingeniería de software

14 Ejemplos de complejidad
LOC = 1Km. Windows 44Km. Sistema de gestión de Red Telefónica 12Km. 10Km. 8Km. Gran sistema de telefonía 6Km. Software de a bordo de la Space Shuttle 4Km. [NORRIS Y RIGBY, 1992, p. 22] Sistema pequeño de telefonía 2Km. Obras completas de Shakespeare Ingeniería de software

15 Categorías de software
[NORRIS y RIGBY, 1992, p. 26] Los límites de manejo de problemas se pueden fijar en: Tamaño: 10 MLOC Componentes: 1000 Tamaño componente: 10 KLOC Diseño: 10 años Recursos humanos: 100 personas Calidad: 1 error/10KLOC Productividad: 50 LOC por día y programador Tasa de reparación: 1 día por defecto por 1KLOC Tasa de defectos: 1 defecto/10KLOC Ingeniería de software

16 Complicación del desarrollo
Sistemas grandes y complejos: Mundo real cambia con frecuencia El software y los modelos deben cambiar La IS también contempla para satisfacer necesidades y requisitos cambiantes IBM: 25% de volatilidad de requisitos Esfuerzo de mantenimiento: > 50% en muchas empresas No basta con que “funcione” el software Facilitar el cambio y el mantenimiento Cumplir con ciertas características Ingeniería de software

17 Ingeniería de software
Construir productos Objetivo de IS: crear productos (de software) IEEE Std. 610: software, datos y documentación Productos: Genéricos (paquetes): venta en mercado abierto Más barato: distribuir coste entre muchas copias A medida (personalizados): cliente concreto Mucho mercado: s.empotrados, controladores IS se aplica a ambos: Genéricos: especificación interna (marketing con estudios de clientes…). Flexible y no obligatorio A medida (contrato): negociar detalles y cambios Ingeniería de software

18 Ingeniería de software
Cifras de España Destacar: Software a medida es mucho mayor que el resto de servicios y prácticamente igual a todo el software que se vende Tipos de software Fuente: SEDISI ( MIB - actividades endógenas Operaciones intermedias y subcontratación en el propio sector SEDISI Ingeniería de software

19 Resumen del enfoque de ingeniería para el software
Complejos: una persona no puede abarcarlos Una persona puede comprender y abarcar todos sus detalles Pueden especificarse y diseñarse de manera informal La especificación y el diseño debe ser formal Debe documentarse adecuada- mente en cada fase y tener una gestión eficaz El efecto de las modificaciones es inmediato Pequeños programas Grandes sistemas Los problemas NO son una simple versión a gran escala Ingeniería de software

20 Características de ingeniería
Permite a personas normales crear sistemas sofisticados que funcionan Diseño rutinario vs originalidad Tratar todos los problemas como nuevos Contraste con química o ingeniería civil Diferencias: rapidez de evolución, estados discretos, mantenimiento Opiniones de [Shaw, 1994, p.931]. Opiniones de [Schach, 1997, p.8]. Aunque se dice que la diferencia entre construir puentes y la informática es sólo cuestión del tiempo que lleva cada tecnología (siglos frente a 50 años), esto no es cierto del todo. El hardware avanza tan rápido que no da tiempo a comprender todas sus implicaciones. Además, el software trata con estados discretos y por lo tanto se exige matemática discreta frente al cálculo o matemática continua de los ingenieros de caminos. Por último, no se pide a un ingeniero que un puente se gire 90º o que se mueva a miles de kilómetros. Sin embargo, sí es habitual que se pida cambiar un sistema batch a uno de tiempo compartido, pasar de una máquina a otra con arquitectura distinta. Es habitual que el 50% de un sistema operativo se cambie cada cinco años, especialmente si se porta a nuevo hardware. Ingeniería de software

21 Ingeniería de software
Definición de IEEE: Programas de ordenador y procedimientos Posiblemente: la documentación asociada y los datos relacionados con la operación del sistema informático Software: de aplicación: satisfacer necesidades de usuario de apoyo: ayuda a desarrollo o mantenimiento de sistemas: facilitar operación de sistema Definición de [IEEE, 1990, p. 185]: Programas de ordenador, procedimientos y, posiblemente, la documentación asociada y los datos relacionados con la operación del sistema informático. Se pueden distinguir como tipos de software en las definiciones de [IEEE, 1990, pp. 20, 195 y 197]: Software de aplicación (application software): software diseñado para satisfacer necesidades específicas de un usuario, por ejemplo, software de navegación aérea, de nóminas o de control de procesos. Software de apoyo (support software): software que ayuda al desarrollo o mantenimiento de de otro software; por ejemplo, compiladores, cargadores u otras utilidades. Software de sistemas (system software): software diseñado para facilitar la operación o el mantenimiento de un sistema informático y de los programas asociados; por ejemplo, sistemas operativos, ensambladores o utilidades. Ingeniería de software

22 Peculiaridad del software
Características diferenciales: Producto lógico, no físico Se desarrolla, no se fabrica en sentido clásico No se degrada con el uso. Reparar no es devolver al estado original. Otros productos: sin errores o rechazados A medida (artesanal), no ensamblado Reutilizable Muy flexible No es posible trasladar sin más las técnicas de otras ingenierías al software [PRESSMAN, 1997, p. 6] (también ideas de las dos ediciones anteriores) El software es un producto lógico o intelectual (las leyes lo reconocen así). No está sometido a leyes físicas que determinan su comportamiento. El software, como producto intelectual, se desarrolla y nose fabrica en sentido clásico. El principal coste (y calidad) reside en su diseño y en la construcción de la primera copia. La replicación no es un problema. Como producto lógico, no se degrada por usarse mucho o por el simple paso del tiempo. Los defectos que aparecen ya estaban en la copia original. *** curvas de fallos *** Eso significa que reparar software no es devolverlo al estado original tras ser desarrollado sino alterar su diseño, porque es erróneo. El mercado del software admite que se entregue un producto incluso con una lista de errores conocidos, algo impensable en otros sectores (por ejemplo, comprar una nevera con errores conocidos). Una gran parte del software se desarrolla a medida para las necesidades de un cliente aunque cada vez existen más paquetes (aunque también requieren adaptación). Se trata de producción artesanal, donde se hace casi todo de nuevo, en vez de ensamblar componentes ya existentes como en otros sectores. Afortunadamente, al ser un producto intelectual se puede reutilizar (aunque todavía quede por llegar a un desarrollo por componentes) y es muy flexible, por lo que se puede cambiar con facilidad. Esto tiene una doble vertiente: buena, retocar o mejorar, y mala, por el descontrol del producto. Ingeniería de software

23 Resumen de aportaciones
Idea de programación estructurada (1968 Dijkstra) Concepto de ciclo de vida (Royce 1970) Metodologías de programación (1974/75) Métodos para diseño modular (1977/78) Métodos para análisis estructurado (1979/85) Métodos híbridos (1985/1992) Métodos Orientados a Objetos y UML (1993/2001) Royce: *** ver original en 11th swengconference *** Ya en 1969 [Naur, 260) Ingeniería de software

24 Ingeniería de software
Algunas referencias R.Pressman, Ingeniería del Software Futuro de la Ingeniería del Software J.Dolado, Profesión de Ingeniero de Software Versión preliminar de SWEBOK Risks to the public Neumann Ingeniería de software

25 Ingeniería de software
Test 1) Ingeniería del software es: a) La disciplina para programar software de gestión b) Un método de análisis y de especificación de requisitos del software c) Un enfoque de desarrollo de software basado en la aplicación de algoritmos formales d) Ninguna de las anteriores 2) Señalar cuáles de las siguientes afirmaciones es coherente con una filosofía de desarrollo basada en ingeniería de software (*): a) Dividir el proyecto en tareas sencillas y el producto en componentes abordables por una sola persona b) Confiar el éxito del desarrollo a la habilidad personal de los buenos programadores c) Coordinación del trabajo en equipo d) Documentar para comunicar a otros miembros del equipo e) Codificar cuanto antes para disminuir el riesgo de retrasos Ingeniería de software

26 Ingeniería de software

27 Principios de ingeniería
“arte o ciencia de hacer práctico el conocimiento de las ciencias puras” Crear soluciones eficaces en coste Aplicar a problemas prácticos Aplicar conocimientos científicos Construir productos Al servicio de las personas Ingeniería, según el [Webster, 1983, p. 473] , es: “el arte o la ciencia de hacer práctica la aplicación de los conocimientos de las ciencias puras (como física, química, biología, etc.)” Incluir RACFN Las distintas definiciones de ingeniería indican unas características comunes [Shaw, 1994, p. 930]: Crear soluciones eficaces en coste (eficiencia): se trata no sólo de resolver problemas sino también hacerlo con un uso económico de todos los recursos, incluido el dinero. Aplicar a problemas prácticos: los que preocupan a los clientes fuera del ámbito de la ingeniería. Aplicar conocimientos científicos: resolver problemas mediante las ciencias, matemáticas y análisis del diseño. Construir productos: se enfatiza la solución que normalmente son productos tangibles. Al servicio de las personas: no sólo debe servir al cliente inmediato sino crear tecnología y experiencia que beneficie a la sociedad. Ingeniería de software

28 Evolución de la ingeniería
Producción Ciencia Ingeniería profesional Virtuosos Intuición y fuerza bruta Progreso fortuito Transmisión casual Uso extravagante Fabricar para usar más que para vender Profesionales formados Análisis y teoría Progreso basado en ciencia Clase de profesionales Permitir nuevas aplicaciones a través de análisis Segmentar mercado Comercial Artesanos cualificados Procedimiento establecido Refinamiento práctico Entrenamiento matemático Análisis de coste y suministro de materiales Fabricar para vender Artesanía Figura de [Shaw, 1994, p.932] Explicación con ejemplos de ingeniería civil y de ingeniería química. Ingeniería de software