INTRODUCCION A LA INGENIERÍA DE SOFTWARE

Presentación del tema: "INTRODUCCION A LA INGENIERÍA DE SOFTWARE"— Transcripción de la presentación:

1 INTRODUCCION A LA INGENIERÍA DE SOFTWARE
UNIDAD II.

2 CONTENIDO 2.1. Definición de Ingeniería de Software 2.2. Historia de la Ingeniería de Software 2.3. Características del Software 2.4. Mitos del Software 2.5. Capas de la Ingeniería de Software 2.6. El proceso de Software 2.7. Software de alta calidad 2.8. Factores de calidad y productividad

3 …Típica apariencia del estudiante promedio cuando le preguntan acerca de Ingeniería de Software…

4 Introducción El término de Ingeniería de Software fue introducido a finales de los 60 a raíz de la crisis del  software. Esta crisis fue el resultado de la introducción de la tercera generación del hardware. El hardware dejo de ser un impedimento para el desarrollo de la informática; redujo los costos y mejoro la calidad y eficiencia en el software producido

5 Introducción (continuación)
La crisis se caracterizo por los siguientes problemas: Imprecisión en la planificación del proyecto y estimación de los costos. Baja calidad del software. Dificultad de mantenimiento de programas con un diseño poco estructurado, etc. Por otra parte se exige que el software sea eficaz y barato tanto en el desarrollo como en la compra. También se requiere una serie de características como fiabilidad, facilidad de mantenimiento y de uso, eficiencia, etc.

6 2.1. DEFINICIÓN DE IS Fritz Bauer, 1969: Más que una disciplina o una parte del conocimiento, La Ingeniería es un verbo, una palabra de acción, un modo de enfocar el problema. La Ingeniería del Software es el establecimiento y uso de principios robustos de la ingeniería a fin de obtener económicamente software que sea fiable y que funcione eficientemente sobre maquinas reales.

7 DEFINICIÓN DE IS Bohem, 1976: Ingeniería del Software es la aplicación practica del conocimiento científico en el diseño y construcción de programas de computadora y la documentación necesaria requerida para desarrollar, operar (funcionar) y mantenerlos. Mills, 1980: La Ingeniería de Software tiene como uno de sus principales objetivos la producción de programas que cumplan las especificaciones, y que se demuestren correctos, producidos en el plazo y costo adecuado

8 DEFINICIÓN DE IS Meyer, 1988: La Ingeniería de Software es la producción de software de calidad. IEEE 1993: La Ingeniería de Software es la aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del software; es decir, la aplicación de Ingeniería de Software.

9 RESUMIENDO… La ingeniería de software es una aplicación práctica del conocimiento científico para proveer metodologías y técnicas que ayuden a desarrollar sistemas de software a tiempo, y a su vez que aseguren que el desarrollador cumpla con las expectativas de calidad y permanezca dentro del presupuesto.

10 2.2. HISTORIA DE LA ING DE SW Ingeniería del Software, es el término utilizado 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, previamente había sido utilizado por el holandés Edsger Dijkstra en su obra The Humble Programmer. Puede definirse según Alan Davis como "la aplicación inteligente de principios probados, técnicas, lenguajes y herramientas para la creación y mantenimiento, dentro de un coste razonable, de software que satisfaga las necesidades de los usuarios". Historia de la ingeniería de software El término ingeniería del software empezó a usarse a finales de la década de los sesenta, para expresar el área de conocimiento que se estaba desarrollando en torno a las problemáticas que ofrecía el software en ese momento. En esa época, el crecimiento espectacular de la demanda de sistemas de computación cada vez más y más complejos, asociado a la inmadurez del propio sector informático (totalmente ligado al electrónico) y a la falta de métodos y recursos, provocó lo que se llamó la crisis del software (en palabras de Edsger Dijkstra) entre los años 1965 y 1985. Durante esa época muchos proyectos importantes superaban con creces los presupuestos y fechas estimados, algunos de ellos eran tan críticos (sistemas de control de aeropuertos, equipos para medicina, entre otros) que sus implicaciones iban más allá de las pérdidas millonarias que causaban. La crisis del software pasó, no tanto por la mejora en la gestión de los proyectos, sino en parte porque no es razonable estar en crisis más de veinte años, y en parte porque se estaban haciendo progresos en los procesos de diseño y metodologías. Así pues, desde 1985 hasta el presente, han ido apareciendo herramientas, metodologías y tecnologías que se presentaban como la solución definitiva al problema de la planificación, previsión de costes y aseguramiento de la calidad en el desarrollo de software. Entre las que se encuentran la programación estructurada, la programación orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de programación ADA, la documentación, los estándares, CORBA, los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la solución a los problemas de la ingeniería del software, la llamada “bala de plata” (por silver bullet). Y lo que es más, cada año surgen nuevas ideas e iniciativas encaminadas a ello. En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de software, argumentando que si se probaba formalmente que los desarrollos hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas de la ingeniería.

11 Historia de la ing de sw (continuación)
Su origen se debió a que el entorno de desarrollo de sistemas software adolecía de: Retrasos considerables en la planificación Poca productividad Elevadas cargas de mantenimiento Demandas cada vez más desfasadas frente a las ofertas Baja calidad y fiabilidad del producto Dependencia de los realizadores Historia de la ingeniería de software El término ingeniería del software empezó a usarse a finales de la década de los sesenta, para expresar el área de conocimiento que se estaba desarrollando en torno a las problemáticas que ofrecía el software en ese momento. En esa época, el crecimiento espectacular de la demanda de sistemas de computación cada vez más y más complejos, asociado a la inmadurez del propio sector informático (totalmente ligado al electrónico) y a la falta de métodos y recursos, provocó lo que se llamó la crisis del software (en palabras de Edsger Dijkstra) entre los años 1965 y 1985. Durante esa época muchos proyectos importantes superaban con creces los presupuestos y fechas estimados, algunos de ellos eran tan críticos (sistemas de control de aeropuertos, equipos para medicina, entre otros) que sus implicaciones iban más allá de las pérdidas millonarias que causaban. La crisis del software pasó, no tanto por la mejora en la gestión de los proyectos, sino en parte porque no es razonable estar en crisis más de veinte años, y en parte porque se estaban haciendo progresos en los procesos de diseño y metodologías. Así pues, desde 1985 hasta el presente, han ido apareciendo herramientas, metodologías y tecnologías que se presentaban como la solución definitiva al problema de la planificación, previsión de costes y aseguramiento de la calidad en el desarrollo de software. Entre las que se encuentran la programación estructurada, la programación orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de programación ADA, la documentación, los estándares, CORBA, los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la solución a los problemas de la ingeniería del software, la llamada “bala de plata” (por silver bullet). Y lo que es más, cada año surgen nuevas ideas e iniciativas encaminadas a ello. En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de software, argumentando que si se probaba formalmente que los desarrollos hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas de la ingeniería.

12 Historia de la ing de sw (continuación)
Esto es lo que se ha denominado habitualmente "crisis del software", que históricamente se generó en los siguientes pasos: - Primera Fase. Los albores ( ) Programar no es una tarea diferenciada del diseño de una máquina Uso de lenguaje máquina y ensamblador. - Segunda Fase. El florecimiento ( ) Aparecen multitud de lenguajes Se pensaba que era posible hacer casi todo. Historia de la ingeniería de software El término ingeniería del software empezó a usarse a finales de la década de los sesenta, para expresar el área de conocimiento que se estaba desarrollando en torno a las problemáticas que ofrecía el software en ese momento. En esa época, el crecimiento espectacular de la demanda de sistemas de computación cada vez más y más complejos, asociado a la inmadurez del propio sector informático (totalmente ligado al electrónico) y a la falta de métodos y recursos, provocó lo que se llamó la crisis del software (en palabras de Edsger Dijkstra) entre los años 1965 y 1985. Durante esa época muchos proyectos importantes superaban con creces los presupuestos y fechas estimados, algunos de ellos eran tan críticos (sistemas de control de aeropuertos, equipos para medicina, entre otros) que sus implicaciones iban más allá de las pérdidas millonarias que causaban. La crisis del software pasó, no tanto por la mejora en la gestión de los proyectos, sino en parte porque no es razonable estar en crisis más de veinte años, y en parte porque se estaban haciendo progresos en los procesos de diseño y metodologías. Así pues, desde 1985 hasta el presente, han ido apareciendo herramientas, metodologías y tecnologías que se presentaban como la solución definitiva al problema de la planificación, previsión de costes y aseguramiento de la calidad en el desarrollo de software. Entre las que se encuentran la programación estructurada, la programación orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de programación ADA, la documentación, los estándares, CORBA, los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la solución a los problemas de la ingeniería del software, la llamada “bala de plata” (por silver bullet). Y lo que es más, cada año surgen nuevas ideas e iniciativas encaminadas a ello. En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de software, argumentando que si se probaba formalmente que los desarrollos hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas de la ingeniería.

13 Historia de la ing de sw (continuación)
- Tercera Fase. La crisis ( ) Desarrollo inacabable de grandes programas Ineficiencia, errores, coste impredecible Nada es posible. - Cuarta Fase. Innovación conceptual ( ) Fundamentos de programación Verificación de programas Metodologías de diseño. - Quinta Fase. El diseño es el problema (1980-?) Entornos de programación Especificación formal Programación automática. Historia de la ingeniería de software El término ingeniería del software empezó a usarse a finales de la década de los sesenta, para expresar el área de conocimiento que se estaba desarrollando en torno a las problemáticas que ofrecía el software en ese momento. En esa época, el crecimiento espectacular de la demanda de sistemas de computación cada vez más y más complejos, asociado a la inmadurez del propio sector informático (totalmente ligado al electrónico) y a la falta de métodos y recursos, provocó lo que se llamó la crisis del software (en palabras de Edsger Dijkstra) entre los años 1965 y 1985. Durante esa época muchos proyectos importantes superaban con creces los presupuestos y fechas estimados, algunos de ellos eran tan críticos (sistemas de control de aeropuertos, equipos para medicina, entre otros) que sus implicaciones iban más allá de las pérdidas millonarias que causaban. La crisis del software pasó, no tanto por la mejora en la gestión de los proyectos, sino en parte porque no es razonable estar en crisis más de veinte años, y en parte porque se estaban haciendo progresos en los procesos de diseño y metodologías. Así pues, desde 1985 hasta el presente, han ido apareciendo herramientas, metodologías y tecnologías que se presentaban como la solución definitiva al problema de la planificación, previsión de costes y aseguramiento de la calidad en el desarrollo de software. Entre las que se encuentran la programación estructurada, la programación orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de programación ADA, la documentación, los estándares, CORBA, los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la solución a los problemas de la ingeniería del software, la llamada “bala de plata” (por silver bullet). Y lo que es más, cada año surgen nuevas ideas e iniciativas encaminadas a ello. En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de software, argumentando que si se probaba formalmente que los desarrollos hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas de la ingeniería.

14 Historia de la ing de sw (continuación)
¿Cómo se define crisis? La palabra crisis se define en el diccionario como "un punto decisivo en el curso de algo; momento, etapa, o evento decisivo o crucial". Sin embargo para el software no ha habido ningún punto crucial, sólo una lenta evolución. La crisis en la industria del software permanece durante muchos años, lo cual parece una contradicción para el término. Lo que si se podría decir es que hay un problema crónico en el desarrollo de software. Que ha venido originado por una falta de: Formalismo y metodología Herramientas de soporte Administración eficaz Historia de la ingeniería de software El término ingeniería del software empezó a usarse a finales de la década de los sesenta, para expresar el área de conocimiento que se estaba desarrollando en torno a las problemáticas que ofrecía el software en ese momento. En esa época, el crecimiento espectacular de la demanda de sistemas de computación cada vez más y más complejos, asociado a la inmadurez del propio sector informático (totalmente ligado al electrónico) y a la falta de métodos y recursos, provocó lo que se llamó la crisis del software (en palabras de Edsger Dijkstra) entre los años 1965 y 1985. Durante esa época muchos proyectos importantes superaban con creces los presupuestos y fechas estimados, algunos de ellos eran tan críticos (sistemas de control de aeropuertos, equipos para medicina, entre otros) que sus implicaciones iban más allá de las pérdidas millonarias que causaban. La crisis del software pasó, no tanto por la mejora en la gestión de los proyectos, sino en parte porque no es razonable estar en crisis más de veinte años, y en parte porque se estaban haciendo progresos en los procesos de diseño y metodologías. Así pues, desde 1985 hasta el presente, han ido apareciendo herramientas, metodologías y tecnologías que se presentaban como la solución definitiva al problema de la planificación, previsión de costes y aseguramiento de la calidad en el desarrollo de software. Entre las que se encuentran la programación estructurada, la programación orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de programación ADA, la documentación, los estándares, CORBA, los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la solución a los problemas de la ingeniería del software, la llamada “bala de plata” (por silver bullet). Y lo que es más, cada año surgen nuevas ideas e iniciativas encaminadas a ello. En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de software, argumentando que si se probaba formalmente que los desarrollos hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas de la ingeniería.

15 Historia de la ing de sw (continuación)
Actualmente está surgiendo una gran expectativa ante la evolución de la Ingeniería del Software, al ir apareciendo nuevos métodos y herramientas formales que van a permitir en el futuro un planteamiento de ingeniería en el proceso de elaboración de software. Dicho planteamiento permitirá dar respuesta a los problemas de: - Administración - Calidad - Productividad - Fácil mantenimiento Este último es uno de los grandes problemas, pues puede llegar a suponer un importe superior al 60% del total del coste del software. Historia de la ingeniería de software El término ingeniería del software empezó a usarse a finales de la década de los sesenta, para expresar el área de conocimiento que se estaba desarrollando en torno a las problemáticas que ofrecía el software en ese momento. En esa época, el crecimiento espectacular de la demanda de sistemas de computación cada vez más y más complejos, asociado a la inmadurez del propio sector informático (totalmente ligado al electrónico) y a la falta de métodos y recursos, provocó lo que se llamó la crisis del software (en palabras de Edsger Dijkstra) entre los años 1965 y 1985. Durante esa época muchos proyectos importantes superaban con creces los presupuestos y fechas estimados, algunos de ellos eran tan críticos (sistemas de control de aeropuertos, equipos para medicina, entre otros) que sus implicaciones iban más allá de las pérdidas millonarias que causaban. La crisis del software pasó, no tanto por la mejora en la gestión de los proyectos, sino en parte porque no es razonable estar en crisis más de veinte años, y en parte porque se estaban haciendo progresos en los procesos de diseño y metodologías. Así pues, desde 1985 hasta el presente, han ido apareciendo herramientas, metodologías y tecnologías que se presentaban como la solución definitiva al problema de la planificación, previsión de costes y aseguramiento de la calidad en el desarrollo de software. Entre las que se encuentran la programación estructurada, la programación orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de programación ADA, la documentación, los estándares, CORBA, los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la solución a los problemas de la ingeniería del software, la llamada “bala de plata” (por silver bullet). Y lo que es más, cada año surgen nuevas ideas e iniciativas encaminadas a ello. En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de software, argumentando que si se probaba formalmente que los desarrollos hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas de la ingeniería.

16 Porque se crea la Ingeniería de Software??
La ingeniería de software se crea debido a las siguientes características: El producto debe ser confiable y realizar sólo las tareas especificadas en los requerimientos.  El producto debe ser robusto. Esto quiere decir que el software se comporta de manera razonable, incluso en circunstancias no anticipadas desde el principio.  El producto de software debe ser lo más reutilizable posible, de manera tal que pueda ser incorporado en otro producto de software si se requiere.  El producto de software debe ser eficiente en el uso de los recursos del sistema. Se requiere desarrollar el software en una manera que lo haga evolutivo, de forma tal que se pueda agregar funcionalidad adicional sin efectos perjudiciales.  El producto de software debe cumplir con los requerimientos de rendimiento especificados, es decir, debe cumplir algunas de las restricciones relacionadas al rendimiento. El producto de software tendrá mayor valor si es portable, es decir que puede trabajar bajo diferentes plataformas de software y ambientes (hardware, sistemas operativos, etc.). El producto de software debe ser utilizable, es decir, el aprendizaje de su uso debe ser los suficientemente sencillo por parte de personas no especialistas.

17 2.3. CARACTERÍSTICAS DEL SOFTWARE
El software se desarrolla o construye; no se fabrica. Aunque existen similitudes entre el desarrollo del software y la construcción del hardware, ambas actividades son fundamentalmente diferentes. En ambas actividades la buena calidad se adquiere mediante un buen diseño, pero la fase de construcción del hardware puede introducir problemas de calidad que no existen (o son fácilmente corregibles) en el software. Ambas actividades dependen de las personas, pero la relación entre las personas dedicadas y el trabajo realizado es completamente diferente para el software. Ambas actividades requieren la construcción de un “producto” pero los enfoques son diferentes. Los costos del software se concentran en la ingeniería. Esto significa que los proyectos de sw no se pueden manejar como si fueran proyectos de fabricación. El software es un elemento del sistema que es lógico, en lugar de físico. Por lo tanto el software tiene características considerablemente distintas a las del hardware: El software se desarrolla no se fabrica Aunque existen similitudes entre el desarrollo del software y la construcción del hardware, ambas actividades son fundamentalmente diferentes. En ambas actividades la buena calidad se adquiere mediante un buen diseño, pero la fase de construcción del hardware puede introducir problemas de calidad que no existen (o son fácilmente corregibles) en el software. Ambas actividades dependen de las personas, pero la relación entre las personas dedicadas y el trabajo realizado es completamente diferente para el software. Ambas actividades requieren la construcción de un producto pero los enfoques son diferentes. Los costos del software se encuentran en la ingeniería. Esto significa que los proyectos de software no se pueden gestionar como si fueran proyectos de fabricación. El software no se estropea La figura 2.1 describe, para el hardware, la proporción de fallos como una función del tiempo. Esa relación, denominada frecuentemente curva de bañera, indica que el hardware exhibe relativamente muchos fallos al principio de su vida (estos fallos son atribuibles normalmente a defectos del diseño o de la fabricación); una vez corregidos los defectos, la tasa de fallos cae hasta un nivel estacionario (bastante bajo, con un poco de optimismo) donde permanece durante un cierto periodo de tiempo. Sin embargo, conforme pasa el tiempo, el hardware empieza a desgastarse y la tasa de fallos se incrementa.

18 2.3. CARACTERÍSTICAS DEL SOFTWARE
El software no se desgasta Tiempo Se estropea Índice de Fallos Mortalidad Infantil Curva de Bañera Pressman Roger S. Ingeniería del software, Ed. Mc Graw Hill, 5ª ed El software no se estropea  La sig. Figura describe, para el hardware, la proporción de fallos como una función del tiempo. Esa relación, denominada frecuentemente curva de bañera, indica que el hardware exhibe relativamente muchos fallos al principio de su vida (estos fallos son atribuibles normalmente a defectos del diseño o de la fabricación); una vez corregidos los defectos, la tasa de fallos cae hasta un nivel estacionario (bastante bajo, con un poco de optimismo) donde permanece durante un cierto periodo de tiempo. Sin embargo, conforme pasa el tiempo, la tasa de fallos se eleva de nuevo conforme a los componentes del hardware sufren los efectos acumulativos del polvo, la vibración, el abuso, las temperaturas extremas y muchos otros males ambientales. Expresado en forma más simple, el hardware comienza a desgastarse y la tasa de fallos se incrementa. El software es inmune a los males ambientales que desgastan el hardware. Por lo tanto, la curva de la tasa de fallas para el software debería tener la forma de “la curva ideal” que se muestra en la sig. Diapositiva.

19 Curva de fallos para el Software
Tiempo Incremento del índice de fallos por efectos de laterales Índice de fallos Cambio Curva real Pressman Roger S. Ingeniería del software, Ed. Mc Graw Hill, 6ª ed

20 2.3. CARACTERÍSTICAS DEL SOFTWARE
Aunque la industria tiene una tendencia hacia la construcción por componentes, la mayoría del software aún se construye a la medida. En el mundo del hardware, la reutilización de componentes es una parte natural del proceso de ingeniería. En el mundo del software es el inicio.

21 2.4. MITOS DEL SOFTWARE Mitos de los administradores
En la actualidad, la mayoría de los profesionales reconocidos en la ingeniería del software identifican los mitos en su real dimensión: actitudes equivocadas que han causado problemas serios a los administradores y al personal técnico por igual. Sin embargo, las antiguas actitudes y viejos hábitos son difíciles de modificar, por lo que aún subsisten creencias falsas sobre el software. En la actualidad, la mayoría de los profesionales reconocidos en la ingeniería del software identifican los mitos en su real dimensión: actitudes equivocadas que han causado problemas serios a los administradores y al personal técnico por igual. Sin embargo, las antiguas actitudes y viejos hábitos son difíciles de modificar, por lo que aún subsisten creencias falsas sobre el software. Mitos de los administradores Mitos de los Clientes Mitos de los Desarrolladores

22 Mitos de los administradores
Mito 1. Ya se tiene un libro lleno de estándares y procedimientos para la construcción de software. ¿Esto proporcionará a mi gente todo el conocimiento necesario? Mito 2. Si se está atrasado en el itinerario es posible contratar más programadores para así terminar a tiempo. Mito 3. Si decido subcontratar el proyecto de software a un tercero, puedo relajarme y dejar que esa compañía lo construya. Mitos de los administradores. Los administradores con responsabilidades sobre el sw, al igual que sus pares en la mayoría de las disciplinas, a menudo están bajo presión por mantener los presupuestos, evitar que los itinerarios se extiendan y mejorar la calidad. De la misma forma que una persona a punto de ahogarse se aferra a un tronco, con frecuencia el administrador del software se aferra a un mito si siente que esta creencia reducirá la presión (aun en forma temporal). Mito. Tenemos ya un libro que esta lleno de estándares y procedimientos para construir software, ¿no le proporciona ya a mi gente todo lo que necesita saber? Realidad. Esta muy bien que el libro exista, pero ¿se usa?, ¿conocen los trabajadores su existencia?, ¿refleja las practicas modernas de desarrollo de software?, ¿es completo?, ¿esta diseñado para mejorar el tiempo de entrega mientras mantiene un enfoque de calidad? En muchos casos, la respuesta a todas estas preguntas es “no”. Mito. Mi gente dispone de las herramientas de desarrollo de software mas avanzadas, después de todo, les compramos las computadoras más modernas. Realidad. Se necesita mucho más que el último modelo de computadora grande o de PC. Para hacer desarrollo de software de gran calidad. Las herramientas de Ingeniería del Software Asistida por Computadora (CASE) son mas importantes que el hardware para conseguir buena calidad y productividad, aunque la mayoría de los desarrolladores del software todavía no las utilice eficazmente. Mito. Si fallamos en la planificación, se puede añadir mas programadores y adelantar el tiempo perdido (el llamado algunas veces “concepto de la horda Mongoliana”). Realidad. El desarrollo de software no es un proceso mecánico como la fabricación. En palabras de Brooks: “añadir gente a un proyecto de software retrasado lo retrasara aun mas”. Al principio, esta declaración puede parecer una confusión. Sin embargo, cuando se añaden nuevas personas, la necesidad de aprender y comunicarse con el equipo puede y hace que se reduzca la cantidad de tiempo gastado en el desarrollo productivo. Puede añadirse gente, pero solo de una manera planificada y bien coordinada. Mito 3. Si decido subcontratar el proyecto de software a un tercero, puedo relajarme y dejar que esa compañía lo construya.

23 Mitos de los Clientes Mito 1. Un enunciado general de los objetivos es suficiente para comenzar a escribir programas; los detalles se pueden afinar después. Mito 2. Los requerimientos del proyecto cambian de manera continua, pero el cambio puede ajustarse con facilidad porque el software es flexible. El cliente que solicita un software de computadora puede ser la persona del escritorio de al lado, un grupo técnico en el piso de abajo, el departamento de ventas o de mercadotecnia, o una compañía externa que ha solicitado el software bajo contrato. En muchos casos, el cliente cree en mitos acerca del software porque los profesionales y administradores del software hacen muy poco para corregir la desinformación. Los mitos conducen a expectativas falsas (del cliente) y en definitiva a la insatisfacción con el desarrollador. Mito. Una declaración general de los objetivos es suficiente para comenzar a escribir los programas. Realidad. Una mala definición inicial es la principal causa del trabajo baldío en software. Es esencial una descripción formal y detallada del ámbito de la información, funciones, comportamiento, rendimiento, interfaces, ligaduras del diseño y criterios de validación. Estas características pueden determinarse solo después de una exhaustiva comunicación ente el cliente y el desarrollador. Mito. Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente, ya que el software es flexible. Realidad. Es verdad que los requisitos del software cambian, pero el impacto del cambio varia según el momento en que se introduce. La figura 2.3 ilustra el impacto de los cambios. Si se pone cuidado al dar la definición inicial, los cambios solicitados al principio pueden acomodarse fácilmente. El cliente puede revisar los requisitos y recomendar las modificaciones con relativamente poco impacto en el costo. Cuando los cambios se solicitan durante el diseño del software, el impacto en el costo crece rápidamente. Ya se han acordado los recursos a utilizar y se ha establecido un marco de trabajo del diseño. Los cambios pueden producir trastornos que requieran recursos adicionales e importantes modificaciones del diseño; es decir, costo adicional. Los cambios en la función, rendimiento, interfaz u otras características, durante la implementación (codificación y prueba) pueden tener un impacto importante sobre el costo. Cuando se solicitan al final de un proyecto, los cambios pueden producir un orden de magnitud más caro que el mismo cambio pedido al principio.

24 Mitos de los Desarrolladores
Mito 1. Una vez que el programa ha sido escrito y puesto a funcionar, el trabajo está terminado. Mito 2. Mientras el programa no se esté ejecutando, no existe forma de evaluar su calidad. Mito 3. El único producto del trabajo que puede entregarse para tener un proyecto exitoso es el programa en funcionamiento. Mito 4. La Ing de Sw obligará a emprender la creación de una documentación voluminosa e innecesaria y de manera invariable tornará más lento el proceso. Los mitos que aún subsisten entre los desarrolladores del software han permanecido a través de 50 años de cultura de programación. Durante los primeros años del software, la programación era vista como una forma de arte; por ello, las viejas formas y actitudes son difíciles de eliminar. Mito. Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado. Realidad. Alguien dijo una vez: “cuanto mas pronto se comiencen a escribir código, mas se tardara en terminarlo”. Los datos industriales indican que entre el 60 y el 80 por ciento de todo el esfuerzo dedicado a un programa se realizará después de que se haya entregado al cliente por primera vez. Mito. Hasta que no tengo el programa “ejecutándose”, realmente no tengo forma de comprobar su calidad. Realidad. Desde el principio del proyecto se puede aplicar uno de los mecanismos más efectivos para garantizar la calidad del software: la revisión técnica formal. La revisión del software es un filtro de calidad que se ha comprobado que es más efectivo que la prueba, para encontrar ciertas clases de defectos del software. Mito. Lo único que se entrega al terminar el proyecto es el programa funcionando. Realidad. Un programa que funciona es solo una parte de una configuración de software que incluye muchos elementos. La documentación proporciona el fundamento para un buen desarrollo y, lo que es más importante, proporciona guías para la tarea de mantenimiento del software. Mito. La Ing de Sw obligará a emprender la creación de una documentación voluminosa e innecesaria y de manera invariable tornará más lento el proceso.

25 2.5. CAPAS DEL SOFTWARE La Ingeniería del Software es una tecnología estratificada, y debe estar sustentada en un compromiso con la calidad.

26 Capa del Proceso Herramientas Métodos Proceso Un enfoque de calidad El fundamento de la Ingeniería del Software es la capa de proceso. El proceso de la Ingeniería del Software es la unión que mantiene juntas las capas de tecnología y que permite un desarrollo racional y oportuno de la Ingeniería de Software. El proceso define un marco de trabajo para un conjunto de áreas clave de proceso (ACPs) que se deben establecer para la entrega efectiva de la tecnología de la ingeniería del software. Las áreas claves del proceso forman la base del control de gestión de proyectos del software y establecen contexto en el que se aplican los métodos técnicos, se obtienen productos del trabajo (modelos, documentos, datos, informes, formularios, etc.), se establecen hitos, se segura la calidad y el cambio se gestiona adecuadamente. Las áreas claves del Proceso forman la base del control de gestión de proyectos del software y establecen contexto en el que se aplican los métodos técnicos, se obtienen productos del trabajo (modelos, documentos, datos, informes, formularios, etc.), se establecen hitos, se segura la calidad y el cambio se gestiona adecuadamente.

27 Capa de los Métodos Herramientas Métodos Proceso Un enfoque de calidad Los métodos de la Ingeniería del Software indican “como” construir técnicamente el software. Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. Los métodos de la Ingeniería del Software dependen de un conjunto de principios básicos que cuidan cada área de la tecnología incluyen actividades de modelado y otras técnicas descriptivas. Los métodos de la Ingeniería del Software indican “como” construir técnicamente el software. Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento.

28 Capa de Herramientas Herramientas Métodos Proceso
Un enfoque de calidad Las herramientas de la Ingeniería de Software proporcionan un enfoque automático o semi-automático para el proceso y para los métodos. Cuando se integran herramientas para que la información creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado Ingeniería del Software Asistida por Computadora (CASE). Las herramientas de la Ingeniería de Software proporcionan un enfoque automático o semi-automático para el proceso y para los métodos. Cuando se integran herramientas para que la información creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado Ingeniería del Software Asistida por Computadora (CASE).

29 2.6. EL PROCESO DEL SOFTWARE
Deseos Necesidades Especificaciones Software El proceso de desarrollo de software Un proceso de software se establece un marco común del proceso definiendo un pequeño numero de actividades del marco de trabajo que son aplicables a todos los proyectos del software, con independencia de su tamaño o complejidad. Un numero de un conjuntos de tareas (cada conjunto es una colección de tareas de Ingeniería de Software, hitos de proyectos, producto de trabajo, y puntos de garantía de calidad) que permiten que las actividades del marco de trabajo se adapten a las características del proyecto del software y a los requisitos del equipo del proyecto. Finalmente, las actividades de protección (como garantía del software, gestión de configuración del software y medición) abarcan el modelo de procesos. Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

30 2.6. EL PROCESO DEL SOFTWARE
Un proceso de software establece un marco común del proceso definiendo un pequeño numero de actividades del marco de trabajo que son aplicables a todos los proyectos del software, con independencia de su tamaño o complejidad. Un proceso de software establece un marco común del proceso definiendo un pequeño numero de actividades del marco de trabajo que son aplicables a todos los proyectos del software, con independencia de su tamaño o complejidad. Un numero de un conjuntos de tareas (cada conjunto es una colección de tareas de Ingeniería de Software, hitos de proyectos, producto de trabajo, y puntos de garantía de calidad) que permiten que las actividades del marco de trabajo se adapten a las características del proyecto del software y a los requisitos del equipo del proyecto. Finalmente, las actividades de protección (como garantía del software, gestión de configuración del software y medición) abarcan el modelo de procesos. Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

31 Marco común del Proceso de Software
Marco de Trabajo Común del Proceso Actividades de Protección Actividades del Marco de Trabajo Conjunto de Tareas Tareas Hitos, entregas Puntos SQA Pressman Roger S. Ingeniería del software, Ed. Mc Graw Hill, 6ª ed Un proceso de software establece un marco común del proceso definiendo un pequeño numero de actividades del marco de trabajo que son aplicables a todos los proyectos del software, con independencia de su tamaño o complejidad. Un numero de un conjuntos de tareas (cada conjunto es una colección de tareas de Ingeniería de Software, hitos de proyectos, producto de trabajo, y puntos de garantía de calidad) que permiten que las actividades del marco de trabajo se adapten a las características del proyecto del software y a los requisitos del equipo del proyecto. Finalmente, las actividades de protección (como garantía del software, gestión de configuración del software y medición) abarcan el modelo de procesos. Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso. “Un proceso define quién está haciendo qué, cuando y cómo lograr cierta meta” Ivar Jacobson, Grady Booch y James Rumbaugh

32 Modelo de Capacidad de Madurez
Investigaciones realizadas por los alumnos

33 2.7. SOFTWARE DE ALTA CALIDAD
¿Qué es calidad? El grado en que un sistema, componente, o proceso cumple con los requerimientos especificados, y las necesidades y/o expectativas del cliente o usuario.

34 Otras definiciones de CALIDAD
ISO 9000: “Calidad: grado en el que un conjunto de características inherentes cumple con los requisitos” Real Academia de la Lengua Española: “Propiedad o conjunto de propiedades inherentes a una cosa que permiten apreciarla como igual, mejor o peor que las restantes de su especie” Philip Crosby: ”Calidad es cumplimiento de requisitos” Armand V. Feigenbaum: “Satisfacción de las expectativas del cliente”. Genichi Taguchi: “Calidad es la menor pérdida posible para la sociedad”. William Edwards Deming: “Calidad es satisfacción del cliente”. Walter A. Shewhart: ”La calidad como resultado de la interacción de dos dimensiones: dimensión subjetiva (lo que el cliente quiere) y dimensión objetiva (lo que se ofrece). .

35 2.7. SOFTWARE DE ALTA CALIDAD
¿Qué es calidad de software? Pressman (2002) se refiere a la calidad del software como “La concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente”. La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad. [11] La calidad del software se puede medir, varía de un sistema a otro o de un programa a otro. Un software elaborado para el control de naves espaciales debe ser confiable al nivel de "cero fallas"; un software hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de software para ser explotado durante un largo período (10 años o más), necesita ser confiable, mantenible y flexible para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de explotación.

36 Las definiciones anteriores resaltan tres puntos importantes:
Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad. Existe un conjunto de requisitos implícitos que a menudo no se mencionan. Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software queda en entredicho.

37 Control de Calidad El control de calidad es una serie de inspecciones, revisiones y pruebas utilizadas a lo largo del proceso del software para asegurar que cada producto cumpla con los requisitos que le han sido asignados.

38 Garantía de Calidad La garantía de calidad consiste en la auditoria y las funciones de información de la gestión. El objetivo de la garantía de calidad es proporcionar la gestión para informar de los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo una visión más profunda y segura de que la calidad del producto esta cumpliendo sus objetivos.

39 $ $ Costos de Calidad El costo de la calidad incluye todos los costos acarreados en la búsqueda de la calidad o en búsqueda de las actividades relacionadas en la obtención de la calidad. El costo de calidad se puede dividir en: Costos de prevención Costos de evaluación Costos de fallos. El costo de la calidad incluye todos los costos acarreados en la búsqueda de la calidad o en búsqueda de las actividades relacionadas en la obtención de la calidad. Se realizan estudios sobre el costo de calidad para proporcionar una línea base del costo actual de calidad, para identificar oportunidades de reducir este costo, y para proporcionar una base normalizada de comparación. La base de normalización siempre tiene un precio. Una vez que se han normalizado los costos de calidad sobre un precio base, tenemos los datos necesarios para evaluar el lugar donde hay oportunidades de mejorar los procesos. Es mas, se puede evaluar como afectan los cambios en términos de dinero.

40 Costos de Prevención En el costo de prevención se incluye:
Planificación de calidad, Revisiones de técnicas formales, Equipo de pruebas, Formación.

41 Costos de Evaluación En el costo de evaluación se incluyen actividades para tener una visión mas profunda de la condición del producto la primera vez a través de cada proceso. Algunos ejemplos de costos de evaluación: Inspección en el proceso y entre procesos, Calibrado y mantenimiento del equipo, Pruebas. En el costo de evaluación se incluyen actividades para tener una visión mas profunda de la condición del producto la primera vez a través de cada proceso. A continuación se incluyen algunos ejemplos de costos de evaluación: Inspección en el proceso y entre procesos, Calibrado y mantenimiento del equipo, Pruebas.

42 Costos de Fallo Los costos de fallo son los costos que desaparecerían si no surgieran defectos antes del envió de un producto a los clientes. Estos costos se pueden subdividir en costos de fallo interno y costos de fallo externo. Los internos se producen cuando se detecta un error en el producto antes de su envió. Entre estos se incluyen: Revisión, Reparación, Análisis de las modalidades de fallos. Los costos de fallo son los costos que desaparecerían si no surgieran defectos antes del envió de un producto a los clientes. Estos costos se pueden subdividir en costos de fallo interno y costos de fallo externo. Los internos se producen cuando se detecta un error en el producto antes de su envió. Entre estos se incluyen: Revisión, Reparación, Análisis de las modalidades de fallos. Los costos de fallo externo son los que se asocian a los defectos encontrados una vez enviado el producto al cliente. A continuación se incluyen algunos ejemplos de costos de fallo externo: Resolución de quejas, Devolución y sustitución de productos, Soporte de línea de ayuda, Trabajo de garantía.

43 Continuación… Los costos de fallo externo son los que se asocian a los defectos encontrados una vez enviado el producto al cliente. Algunos ejemplos de costos de fallo externo: Resolución de quejas, Devolución y sustitución de productos, Soporte de línea de ayuda, Trabajo de garantía.

44

45 2.8. FACTORES DE CALIDAD Y PRODUCTIVIDAD (McCall)
Los factores que afectan la calidad del software se pueden categorizar en dos amplios grupos: Factores que se pueden medir directamente (por ejemplo, defectos por punto de función) y Factores que se pueden medir solo indirectamente (por ejemplo, facilidad de uso o de mantenimiento). Los factores que afectan la calidad del software se pueden categorizar en dos amplios grupos: Factores que se pueden medir directamente (por ejemplo, defectos por punto de función) y Factores que se pueden medir solo indirectamente (por ejemplo, facilidad de uso o de mantenimiento). En todos los casos debe aparecer la medición. Debemos comparar el software (documentos, programas, datos) con una referencia y llegar a una conclusión sobre la calidad. McCall y sus colegas propusieron una útil clasificación de factores que afectan a la calidad del software. Estos factores de calidad del software se concentran en tres aspectos importantes de un producto de software: sus características operativas, su capacidad de cambios y su adaptabilidad a nuevos entornos.

46 2.8. FACTORES DE CALIDAD Y PRODUCTIVIDAD (McCall)
Facilidad de Mantenimiento Flexibilidad Facilidad de Prueba Transición del Producto Revisión del Producto Operación del Producto Portabilidad Reusabilidad Interoperatividad Corrección Fiabilidad Usabilidad Integridad Eficiencia

47 Factores de calidad de McCall
Corrección. Hasta dónde satisface un programa su especificación y logra los objetivos propuestos por el cliente. ¿Hace lo que quiero?. Dicho de otra forma, es la capacidad de los productos de software para realizar con exactitud sus tareas, tal y como se definen en las especificaciones. La corrección es la cualidad principal. Si un sistema no hace lo que se supone que debe hacer, poco importan el resto de consideraciones que hagamos sobre él si es rápido, si tiene una bonita interfaz de usuario, etc.

48 Factores de calidad de McCall
Fiabilidad. Hasta donde se puede esperar que un programa lleve a cabo su función con la exactitud requerida. ¿Lo hace de forma fiable todo el tiempo?. Eficiencia. Es la capacidad de un sistema de software para exigir la menor cantidad posible de recursos hardware, tales como tiempo del procesador, espacio ocupando memoria interna y externa o ancho de banda utilizado en los dispositivos de comunicación. ¿Se ejecutara en mi hardware lo mejor que pueda?

49 Factores de calidad de McCall
Integridad. Es la capacidad de los sistemas software de proteger sus diversos componentes (programas, datos, etc.) contra modificaciones y accesos no autorizados. Hasta donde se puede controlar el acceso al software o a los datos por personas no autorizadas. ¿Es Seguro? Usabilidad (facilidad de manejo). Es la facilidad con la cual personas con diferentes formaciones y aptitudes pueden aprender a usar los productos de software y aplicarlos a la resolución de problemas. También cubre la facilidad de instalación, de operación y de supervisión.

50 Factores de calidad de McCall
Facilidad de mantenimiento. El esfuerzo necesario para localizar y arreglar un error en un programa. ¿Puedo corregirlo. Flexibilidad. El esfuerzo es necesario para modificar un programa que ya esta en funcionamiento. ¿Puedo cambiarlo?. Facilidad de prueba. El esfuerzo necesario para probar un programa y asegurarse de que realiza correctamente su función. ¿Puedo probarlo?.

51 Factores de calidad de McCall
Portabilidad. Es la facilidad de transferir los productos software a diferentes entornos hardware y software. Reusabilidad (capacidad de reutilización). Es la capacidad de los elementos de software de servir para la construcción de muchas aplicaciones diferentes. Interoperatividad. El esfuerzo necesario para acoplar un sistema con otro. Interoperatividad es la facilidad de combinar unos elementos de software con otros. ¿Podré hacerlo interactuar con otro sistema?.