Universidad Mariano Gálvez Ingeniería del Software

Presentación del tema: "Universidad Mariano Gálvez Ingeniería del Software"— Transcripción de la presentación:

1 Universidad Mariano Gálvez Ingeniería del Software
Capítulo 1. Introducción

2 Introducción Ingeniero: Persona que profesa o ejerce la Ingenieria .
Ingenieria: Conjunto de conocimientos y tecnicas cuya aplicación permite la utilizacion racional de los materiales y de los recursos, mediante invenciones, construcciones u otras realizaciones provechosas por el hombre. Software: Instrucciones(programas) que cuando se ejecutan proporcionan la funcion y el rendimiento deseados. Estructura de datos que permiten a los programas manipular adecuadamente informacion. Ingeniería del software: Estudio de los principios y metodologias para desarrollo y mantenimiento de sistemas de software.

3 Introducción Ingeniería del software: Es la aplicación practica del conocimiento cientifico en el diseno y construccion de programas de computadora y la documentacion asociada Ingeniería del software: La aplicación de un enfoque sistematico,disciplinado y cuantificable al desarrollo, operación y mantenimiento del software. El software es la maquina que conduce a la toma de decisiones comerciales, sirve de base para la investigacion cientifica moderna y de resolucion de problemas de ingenieria. Es el factor clave que diferencia los productos y servicios Modernos. Software=Competitividad.

4 Introducción Esta inmerso en sistemas de todo tipo: Medicos,Comerciales,Militares,Entretenimientos, Industriales etc. El software es casi ineludible a un mundo moderno. Que es? Es el producto que disenan y construyen los ingenieros de software, programas que se ejecutan dentro de una computadora de cualquier tamano y arquitectura. Porque es importante? Porque afecta muy de cerca de cualquier aspecto de nuestra vida y esta muy extendido en nuestro comercio, cultura y en nuestras actividades cotidianas. Cuales son los Pasos: Construir un Software de computadora es como construir cualquier otro producto satisfactorio, aplicando un proceso que conduce a un resultado de alta calidad que satisface las necesidades de la gente que lo usara.

5 Motivación Es muy simple el esquema que consiste en desarrollar un programa sencillo que resuelve una tarea bien determinada. Lo normal es que se evolucione al desarrollo de un sistema software: integra varios programas, o producto software: programa usado en diferentes aplicaciones/entornos Ambos desarrollos “dan lugar a la Ingeniería del Software”: Programas integrados que pueden trabajar en varios entornos.

6 Motivación (II) Información = Ppal. activo de las empresas
Sólo un ejemplo del importante papel de los SI en las empresas: (a) intervención de Banesto; (b) (EL PAIS, Sábado, 21 de septiembre de 2002) concesión a Banesto de los gestión financiera de los fondos que maneja el Ministerio de Justicia durante cinco años. La administración de estos fondos asciende a millones de euros el primer año. El Ministerio de Justicia advirtió de que la entidad ganadora sería la que mayor remuneración ofreciera. (...) Pero el concurso no sólo era cuestión de precios. Justicia exigió a los bancos un sistema informático especial que se adaptara a sus necesidades. Banesto deberá realizar una inversión adicional para tenerlo listo en enero. Hoy día, con las herramientas disponibles cualquiera puede desarrollar software. En este contexto, ¿cuál puede ser la distinción de los ingenieros de software? Construir software con calidad. Sólo el software construido con principios de ingeniería puede tener sistemáticamente calidad, y se fiable, económico y eficiente. El proceso software debe realizarse de acuerdo con una serie de normas y estándares. Esta asignatura es una introducción a esta relativamente nueva “disciplina de ingeniería”, y debe servir como una guía que introduzca toda la materia de ingeniería del software que se estudia en la carrera. desarrollo de SI  fuertes presiones (calidad, productividad) Artesanal Disciplina de ingeniería Calidad Herramientas Gestión de proyectos

7 Desarrollo del software.
Pero hay una diferencia fundamental: Planos en la industria de la construcción: bien establecidos. “Planos” en la industria del software: todavía no.

8 Desarrollo del software. Comunicación compleja
Esta figura podría resumir buena parte de la esencia de la asignatura: en el desarrollo de software (una entidad “compleja”) se producen problemas de comunicación a varios niveles: entre usuarios y desarrolladores y entre los componentes mismos del equipo de desarrollo. Estudiaremos las técnicas, métodos y herramientas de ingeniería que puedan hacer que estos problemas se minimicen, e incluso que desaparezcan.

9 El Software El Software:
Instrucciones que, cuando se ejecutan, proporcionan la funcionalidad deseada. Estructuras de datos que facilitan a las instrucciones manipular adecuadamente la información. Documentos que describen el desarrollo, uso, instalación y mantenimiento de los programas. Software: "programas de computador, procedimientos, y, posiblemente, la documentación asociada y los datos pertenecientes a las operaciones de un sistema de computación". Incluye: entrenamiento, soporte al consumidor e instalación. Por ejemplo, la página web del producto (soporte al consumidor) formaría parte del software.

10 Características del software
Elemento lógico, no físico. Desarrollado, no ‘fabricado’. No se ‘estropea’, ¡pero se deteriora! (deterioro por ‘cambios’) Mayoritariamente cerrado: usar todo o nada (poco ensamblaje de componentes: reutilización--) Poner una analogía con el Hw. “Elemento lógico”: lo hace más difícil de medir. “No se estropea, se deteriora”: discutir en la pizarra las figuras p. 8-9 (Pressman 98)(Pressman 01): Curva de fallos del Hw. Curva de fallos del Sw. (idealizada y real). Poco ensamblaje de componentes: diferencias con el Hw.

11 Atributos de Calidad del Software
Fiable Capacidad de ofrecer los mismos resultados bajo las mismas condiciones. Eficiente Utilización óptima de los recursos de la máquina. Robusto No poseer un comportamiento catastrófico ante situaciones excepcionales (Tolerante a fallos). Correcto Se ajusta a las especificaciones dadas por el usuario. Portable Capaz de integrarse en entornos distintos con el mismo esfuerzo. Adaptable (extensibilidad) Modificar alguna función sin que afecte a sus actividades. Inteligible Diseño claro, bien estructurado y documentado. No Erróneo No exista diferencia entre los valores reales y los calculados Reutilizable (reusabilidad) Son atributos de calidad externa e interna.

12 Perspectiva histórica del desarrollo de software
Década 50-60: “Software como un añadido”. Desarrollo artesanal, a medida. Lenguajes de bajo nivel. Década 60-70: Software como producto. Década lenguajes y compilación. “Crisis del software”. Década 70-80: Programación estructurada. Ingeniería del Software. Primeros métodos estructurados. Década 80-90: Tecnología de SGBDs, SOs... Nuevos paradigmas de programación y de producción de programas: OO 90’s - actualidad: POO, programación visual Análisis/Diseño OO. “Guerra de los métodos” UML (1997) Tecnología CASE (2ª generación) Métodos ágiles Componentes y reutilización Internet Comercio electrónico Extraído de (Pressman 98): Década 50-60 De la producción artesanal: Continuo cambio del hardware, mientras que el software se considera un añadido. Características: Falta de documentación. Fuerte dependencia del software sobre el hardware. Desarrollo artesanal de los programas. Programas de aplicación concreta. Una sola persona lo desarrolla todo. Lenguaje de programación de bajo nivel (ensamblador) Década 60-70 De los lenguajes de programación y compiladores: Avances en el hardware (reducción del coste de procesamiento). El interés se centra en aplicaciones más complejas y más difíciles de mantener. Se detecta lo que se dio en llamar una “crisis del software”. Causas: Incremento de la complejidad de las aplicaciones. Necesidad de fiabilidad del producto. Falta de adecuación de los lenguajes de programación y ausencia de metodologías para el desarrollo de las aplicaciones. Factores donde se manifiesta la “crisis”: Incremento del coste del software. Falta de calidad del software. Década 70-80: De la Ingeniería del Software: Intento de solución de la crisis del software mediante la programación estructurada/desarrollo estructurado. Mayor potencia expresiva de los lenguajes y TAD Década 80-90 De los nuevos paradigmas: Se impulsan nuevos paradigmas en la producción de programas. Década 90’s - actualidad Hay una auténtica “explosión tecnológica”. Análisis/Diseño OO. “Guerra de los métodos” UML (1997) Tecnología CASE (2ª generación) Métodos ágiles Componentes y reutilización Interoperabilidad (CORBA, .NET...). Internet Comercio electrónico

13 La problemática actual del software
Incapacidad para estimar tiempo, coste y esfuerzo para el desarrollo de un producto software. Falta de calidad del producto software. Avance del hardware y necesidad de aplicaciones más complejas.  Cambio en la relación entre el coste hardware/software. El cambio en la relación entre el coste hardware/software no es un problema en sí, sino más bien una manifestación o un efecto de la situación.

14 Relación coste hw./sw. Cambio en la relación entre el coste hardware/software: Ejemplo: Pensemos en los grandes sistemas desarrollados “a medida”, por un equipo de trabajo contratado para la construcción de un sistema diseñado de acuerdo con las especificaciones de un cliente. El sistema necesitará generalmente una máquina principal para alojar los datos y los programas, cuyo coste en la mayoría de los casos no excede los 30000€. Los terminales para los usuarios suelen ser ordenadores del tipo IBM PC compatibles, con un coste no superior, por unidad, de 1200€. Así, incluyendo impresoras y cableado de comunicaciones, el coste en instalaciones hardware para un proyecto (suponiendo que no se pudiera aprovechar nada del material existente, y que todo deba adquirirse nuevo), puede elevarse a los 90000€ para unos treinta usuarios. Probablemente el equipo encargado de desarrollar los programas que se ejecutarán en esta plataforma, supondrá para la organización un coste muy superior a los €. Todo ello, claro está, en función de la complejidad del sistema a desarrollar.

15 Problemas del software (II)
¿Porqué lleva tanto tiempo terminar los programas? ¿Porqué es tan elevado su coste? ¿Porqué no podemos encontrar todos los errores antes de entregar el software a nuestros clientes? ¿Porqué nos resulta difícil constatar el progreso conforme se desarrolla el sw.? Son preguntas que muchas veces se han hecho y se hacen los directivos o gestores a cargo de proyectos sw.

16 Algunas causas Horda Mongoliana.
Problemas derivados de la intervención de grupos. Problemas de comunicación con los clientes. Poco esfuerzo en el análisis y el diseño. Herramientas comerciales poco adecuadas. Problemas de gestión. Planificaciones optimistas, plantillas poco cualificadas... A veces, el sw debe “solucionar” los problemas del sistema global. Difusión limitada de las nuevas técnicas, métodos y herramientas.

17 Algunas soluciones... ¡No existe bala de plata! 7)
Modelado del negocio métodos de análisis, diseño, prueba... ingeniería de requisitos En su célebre artículo “No Silver Bullet - Essence and Accidents of Software Engineering” (Brooks, F. “No silver bullet”, IEEE Computer, 1987), Brooks examina la disciplina de la ingeniería del software y determina qué avances son realmente prometedores, por dirigirse a la complejidad “esencial” en el desarrollo de software, y cuáles se dirigen a la complejidad “accidental” del mismo. Para Brooks, las aproximaciones realmente prometedoras en ingeniería del software son: · Comprar en lugar de construir (Buy versus build). · Refinamiento de requisitos y prototipado rápido (Requirements refinement and rapid prototyping). · Desarrollo incremental – “hacer crecer” el software, no construirlo (Incremental development - grow, don’t build, software). · Contar con grandes diseñadores (Great designers). Resulta sorprendente observar la validez que tienen estas propuestas quince años después de que Brooks las catalogara como “prometedoras”, y demuestran la gran visión de futuro de este artículo. reutilización Prototipado POO INGENIERÍA DEL SOFTWARE herramientas 4ª gen. lenguajes no procedimentales para consulta a BD’s generadores de pantallas, generadores de código, generadores de informes métodos formales herramientas CASE: editores dirigidos por la sintaxis, entornos integrados de desarrollo, herramientas para la gestión de proyectos, herramientas de prototipado, etc.

18 Objetivos de la Ingeniería del Software
Término que aparece en 1968 La producción de programas debe abordarse como una ingeniería más. (Boehm) La Ingeniería del Software es la aplicación práctica y sistemática del conocimiento científico a: la producción de programas correctos, que se desarrollan a tiempo y dentro de las estimaciones de presupuesto, y a la correspondiente documentación para desarrollarlos, usarlos y mantenerlos. La Ingeniería del Software se fundamenta en técnicas relacionadas con: ciencia de la computación, programación, ingeniería, administración, matemáticas, economía,... Forma parte de la “Ingeniería de Sistemas” El término “Ingeniería del Software” fue acuñado durante la primera conferencia sobre Ingeniería del Software patrocinada por la OTAN, celebrada en Garmisch (Alemania) en octubre de Esta conferencia fue continuada un año más tarde por otra en Roma. Estas sesiones tuvieron como objetivo la discusión sobre los problemas, que se percibían como cada vez mayores, en la tecnología del software, dirección de proyectos y mantenimiento de programas.

19 Más definiciones de ISW
“La ISW es el establecimiento y uso de principios sólidos de ingeniería, orientados a obtener software económico que sea fiable y trabaje de manera eficiente en máquinas reales” (Fritz Bauer). “ISW: (1) La aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, la operación y el mantenimiento del software; es decir, la aplicación de la ingeniería al software; (2) El estudio de enfoques como en (1)” (Glosario Estándar de Términos de Ingeniería del Software de IEEE, 1998). “Una disciplina que comprende todos los aspectos de la producción de software desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste después de que se utiliza” (Sommerville 2002). En la definición de Sommerville, notamos que existen dos aspectos clave: 1.- Se trata de una disciplina de ingeniería: los ingenieros hacen que las cosas funcionen. Aplican teorías, métodos y herramientas donde sea conveniente, pero las utilizan de forma selectiva y siempre tratando de descubrir soluciones a los problemas, aun cuando no existan teorías y métodos aplicables para resolverlos. Los ingenieros también tienen que trabajar con restricciones financieras y organizacionales, por lo que buscan soluciones teniendo en cuenta estas restricciones. 2.- Se tocan todos los aspectos de la producción de software: la ingeniería del software no sólo comprende los procesos técnicos de desarrollo de software, sino también actividades como la administración de proyectos de software y el desarrollo de herramientas, métodos y teorías de apoyo a la producción de software.

20 Situación actual de la ISW
En los últimos 20 años, Los cambios en hardware han sido enormes. Aparentemente, los cambios en software también: P.ej., las grandes infraestructuras –energía, comunicaciones, transporte- descansan sobre sistemas muy complejos y en general muy fiables. P.ej., auge de Internet y aplicaciones relacionadas Se dispone de una enorme variedad de tecnologías (p.ej. J2EE, .NET, EJB, SAP, BPEL4WS, SOAP, CBSE) para construir aplicaciones –como las aplicaciones web- que pueden ser desplegadas mucho más rápidamente que en el pasado. Sin embargo, más allá de las tecnología, si miramos los procesos de ingeniería del software, desgraciadamente muchas cosas permanecen igual.

21 Situación actual de la ISW (II)
El modelo en cascada sigue siendo utilizado por más del 40% de las empresas (IEEE Software, Dic. 2003), a pesar de que sus serios problemas fueron identificados hace 20 años. La prueba es la técnica de validación predominante, a pesar de que otras técnicas, como la inspección de programas, han sido usados más eficientemente desde los años 70. Las herramientas CASE son todavía simplemente editores de diagramas con algunas funcionalidades de chequeo y generación de código. Todavía muchos proyectos terminan tarde, exceden el presupuesto o no entregan el software que esperaban los clientes.

22 Situación actual de la ISW (III)
En muchas áreas sigue sin existir un conjunto de estándares que se use ampliamente. No existen suficientes datos - guía (estadísticas). A diferencia de otras ingenierías, se carece de una base formal. En definitiva, La disciplina no es todavía madura Necesario mayor esfuerzo en educación en ISW

23 Situación actual de la ISW (IV)
Pero hay también aproximaciones prometedoras. Por ejemplo: Se ha establecido UML (Lenguaje Unificado de Modelado) como una notación estándar de análisis y diseño OO. Aparecen métodos ágiles como Extreme Programming. SWEBOK (Guide to the Software Engineering Body of Knowledge) (2001). Algunas universidades han comenzado a ofrecer un título en ingeniería del software. Comités CSAB (Computer Science Accreditation Board) y ABET (Accreditation Board for Engineering and Technology). El CMM (Capability Maturity Model) del SEI (Software Engineering Institute) y la familia de estándares ISO 9000 son usados para valorar la capacidad de una organización de ingeniería del software. En EE UU, el Colegio de Ingenieros Profesionales de Texas (Texas Board of Professionals Engineers) ha comenzado a licenciar ingenieros del software. ACM e IEEE-CS han desarrollado y adoptado conjuntamente un Código de Ética para Profesionales en Ingeniería del Software. La ingeniería del software ha evolucionado enormemente desde que en 1968 se acuñó el término “Ingeniería del Software”. Sin embargo, actualmente la ingeniería del software todavía dista de ser una disciplina madura como lo son otras ingenierías, y no es todavía una profesión reconocida. Algunos indicios de que nos encontramos ante una disciplina con un mayor grado de madurez se presentan en esta transparencia: El proyecto SWEBOK trata de perfilar el conjunto de conocimientos que entrarían dentro del área de influencia de la ingeniería del software, esto es, su cuerpo de conocimiento. La licencia es el permiso gubernamental para que una persona pueda practicar su profesión en una jurisdicción. La certificación, en cambio, es una declaración por parte de una autoridad reconocida de que una persona es competente en un área. Los comités CSAB (Computer Science Accreditation Board) y ABET (Accreditation Board for Engineering and Technology). La acreditación de un programa curricular asegura que éste conforma con un estándar de enseñanza y que la organización educativa dispone de suficientes instalaciones para impartirlo adecuadamente. CSAB está concebido como el comité encargado de la acreditación de currículos universitarios en ingeniería del software, ciencias de la computación y sistemas de información, y recientemente ha pasado a ser parte de ABET.

24 Algunos principios de la ISW
Abstracción Permite parcelar la complejidad. Por ello se olvidan aspectos irrelevantes del sistema y se potencian los fundamentales. Encapsulamiento u Ocultación de la información Esconder todos los detalles que no afecten a otros módulos, definiendo interfaces estrictos que sirvan de interacción entre los distintos modelos. Modularidad Sirve para parcelar la solución en módulos independientes con fuerte cohesión interna. Localización Deben estar agrupados todos aquellos elementos que están afectados por un mismo hecho. Uniformidad Tódos los módulos deben tener una notación similar. Completitud Deben estar desarrollados todos los aspectos del sistema. Validación y Verificación El producto final debe ser fácilmente validable y verificable: ¿Estamos desarrollando el programa correcto? ¿Estamos desarrollando correctamente el programa?

25 Visión general del proceso de ISW
Con independencia del área de aplicación, tamaño o complejidad del proyecto, cualquier sistema se encontrará al menos en una de las siguientes fases genéricas: Definición ~ Análisis (del sistema, del sw.) Desarrollo ~ Diseño, codificación, prueba Mantenimiento. Estas son las fases genéricas de la Ingeniería del Software. Más adelante se presentarán modelos concretos de procesos.

26 Fase de definición ¿Qué debe hacer el sistema?
información que ha de manejar el sistema necesidades de rendimiento restricciones de diseño interfaces del sistema con los usuarios y con otros sistemas criterios de validación Se elaboran los documentos de requisitos del sistema (SyRS) y del software (SRS) En la fase de definición se intenta caracterizar el sistema que se va a construir. Se trata de resolver la pregunta: ¿Qué debe hacer el sistema? Se determina qué información ha de manejar el sistema, qué necesidades de rendimiento existen, las restricciones de diseño, cuáles son las interfaces del sistema con los usuarios así como con otros sistemas, qué criterios de validación indican si el sistema es correcto, etc. Durante esta fase se elabora los documentos de requisitos del sistema y del software (SyRS, System Requirements Specification; y SRS, Software Requirements Specification), que se emplearán para posteriormente validar la corrección de uno y otro. Utilizando alguna técnica y método se llevarán a cabo la ingeniería de sistemas o de información, planificación del proyecto software, y análisis de requisitos.

27 Fase de desarrollo ¿Cómo construir el sistema?
Se diseñan las estructuras de los datos y los programas cómo se caracterizan las interfaces, cómo realizar el paso del diseño al lenguaje de programación, cómo ha de realizarse la prueba, se escriben y documentan los programas, y se prueba el software construido. En la fase de desarrollo se diseñan las estructuras de los datos así como los programas (cómo han de implementarse detalles procedimentales, cómo se caracterizan las interfaces, cómo se debe realizar el paso del diseño al lenguaje de programación, cómo ha de realizarse la prueba, etc.). Se escriben y documentan los programas, y se prueba el software construido. Esta fase toma como punto de partida la documentación generada en la fase previa para considerar los elementos a construir. Siempre se realizará, de una u otra forma: diseño del software, generación de código y prueba del software.

28 Fase de mantenimiento Comienza una vez construido el sistema, cuando se empieza a utilizar. Se centra en el cambio. El software es sometido a reparaciones y modificaciones cada vez que se detecta un fallo o se necesita cubrir una nueva necesidad de los usuarios. En esta fase recae el mayor porcentaje del coste de un sistema. Como hemos visto anteriormente, la fase de mantenimiento comienza una vez construido el sistema, cuando se empieza a utilizar realmente. El software es sometido a una serie de reparaciones y modificaciones cada vez que se detecta un fallo o se necesita cubrir una nueva necesidad de los usuarios. En la fase de mantenimiento es en la que recae el mayor porcentaje del coste de un sistema (que algunos estudios cifran en hasta un 90%).

29 Fase de mantenimiento Un buen sistema no es sólo un conjunto de programas que funcionan. Un buen sistema no es sólo un conjunto de programas que funcionan, sino que es necesario que sea fácil de mantener para adaptarlo a modificaciones, y para poder corregir los posibles errores de programación producidos durante el desarrollo. En este sentido, la documentación del proceso de desarrollo es fundamental, y debe ser suficientemente completa y exhaustiva. Con frecuencia esta documentación tiende a quedar desfasada con respecto a los programas y estructuras de datos del sistema. Para paliar en la medida de lo posible este problema es conveniente hacer uso de una herramienta CASE tanto en el desarrollo del sistema como durante el proceso de mantenimiento. Aunque sin el correcto uso de una metodología, ni la mejor herramienta CASE podrá evitar el fracaso en lo que a la catalogación de la documentación se refiere. Debe ser fácil de mantener Documentación esencial (CASE, Computer Assisted Software Engineering)

30 Tipos de mantenimiento
Correctivo: un programa no realiza correctamente la aplicación para la que ha sido diseñado, y, por tanto, debe ser modificado. Perfectivo: modificaciones a los programas para conseguir mayor adecuación a los requisitos, mayor eficiencia, o simplemente recoger nuevas funcionalidades no expresadas en la fase de definición del sistema.

31 Tipos de mantenimiento (II)
Adaptativo: Adaptar los programas para acomodarlos a los cambios de su entorno externo (modificaciones en la legislación, CPU, SO, las reglas de negocio, etc.) Preventivo: El software se deteriora con los cambios, y este tipo de mantenimiento hace cambios en los programas para que se puedan corregir, adaptar y mejorar más fácilmente (Reingeniería del software). P.ej., considérense los problemas de mantenimiento debidos al cambio de moneda a euros y al problema del año 2000 (Y2K).

32 Visión general del proceso de ISW (II)
El desarrollo de un sistema informático no es totalmente secuencial, sino que en cada una de las fases que hemos visto se pueden detectar problemas que obliguen a modificar algo que se hizo en una fase anterior. La figura contiene un esquema que pretende reflejar esta idea. Los modelos recientes inciden en un desarrollo iterativo e incremental. (en la práctica, nunca es totalmente secuencial) Actualmente, se pretende: ágil, iterativo e incremental

33 Impacto del cambio Coste del cambio 60-100x 1,5-6x 1x Definición
Desarrollo Mantenimiento

34 Responsabilidad ética y profesional en ISW
Está cobrando más interés en los últimos años. Los ingenieros de software tienen responsabilidades frente a la profesión y la sociedad. Su responsabilidad no es exclusivamente técnica. Deben comportarse de forma ética y moralmente responsable si quieren ser respetados como profesionales. Un ingeniero de software no debería comportarse de manera deshonesta o de una forma que perjudique a la profesión.

35 Responsabilidad ética y profesional en ISW (II)
Hay áreas donde el concepto de conducta aceptable no está limitada por la ley sino por la noción más tenue de responsabilidad profesional. Algunas de ellas son: Confidencialidad. Se debería respetar la confidencialidad de la empresa empleadora o de los clientes independientemente de que se haya firmado un contrato formal de confidencialidad. Competencia. El ingeniero de software no debería aceptar conscientemente trabajo que esté fuera de su competencia.

36 Responsabilidad ética y profesional en ISW (III)
Derechos de la propiedad intelectual. El ingeniero de software debería conocer las leyes que gobiernan la propiedad intelectual, como patentes y derechos de autor, y debería proteger la propiedad intelectual de clientes y empleadores. Mal uso del ordenador. El ingeniero de software no debería usar sus conocimientos técnicos para utilizar de forma incorrecta los ordenadores de otras personas. El mal uso va desde lo relativamente trivial (usar el ordenador de la empresa para jugar, p.ej.) hasta lo extremadamente serio (diseminación de virus).

37 Responsabilidad ética y profesional en ISW (IV)
ACM (Association for Computer Machinery) e IEEE (Institute of Electrical and Electronic Engineers) publicaron en 1999 un código conjunto de ética y conducta profesional, que establece los estándares de conducta esperados de sus miembros. Es preciso aceptar dicho código para poder ser miembro de estas organizaciones.  El Octavo Principio establece como obligación el aprendizaje continuo a través de toda la vida profesional.