1 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy ACI491:...

1 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy

ACI491:ACI491:Ingeniería de SoftwareIngeniería de Software

Unidad 5:Introducción a la Ingeniería de

Software


Contenidos

• Importancia del software. • Impacto del software en los productos

y servicios.• Crisis del software: Problemas y

soluciones. • Ciclo de vida del software: paradigmas

y fases genéricas. • Planificación de proyectos de software.


Objetivos específicos

Conocer la importancia que tiene el software al interior de las organizaciones.

Ser capaz de identificar problemas y entregar las soluciones mas optimas para estos.

Identificar cuando es necesario una solución informática (software) y cuando no es necesaria.

Ser capaz de planificar un software, identificando claramente sus ciclo de vida.


Introducción• Hoy en día el software tiene un doble papel: Es un

producto y, al mismo tiempo, el vehículo para entregarlo.

• Como producto, hace entrega de la potencia informática que incorpora el hardware informático o, más ampliamente, una red de computadoras que es accesible por hardware local.

• Si reside dentro de un teléfono celular u opera dentro de una computadora central, el software es un transformador de información, produciendo, gestionando, adquiriendo, modificando, mostrando o transmitiendo información que puede ser tan simple como un solo bit, o tan complejo como una presentación en multimedia.

• Como vehículo utilizado para hacer entrega del producto, el software actúa como la base de control de la computadora (sistemas operativos), la comunicación de información (redes) y la creación y control de otros programas (herramientas de software y entomos).


Preguntas claves

• ¿Por qué lleva tanto tiempo terminar los programas?

• ¿Por qué son tan elevados los costes de desarrollo?

• ¿Por qué no podemos encontrar todos los errores antes de entregar el software a nuestros clientes?

• ¿Por qué nos resulta difícil constatar el progreso conforme se desarrolla el software?


Tipos de software

Una clasificación (Pressman) puede ser:• De sistema• De tiempo real• De gestión• De ingeniería y científico• Empotrado (embedded software)• De computadoras personales• Basado en la Web• De inteligencia artificial


Crisis del software

• Muchos observadores de la industria han caracterizado los problemas asociados con el desarrollo del software como una «crisis».

• Más de unos cuantos libros han recogido el impacto de algunos de los fallos mas importantes que ocurrieron durante la década pasada.

• No obstante, los mayores éxitos conseguidos por la industria del software han llevado a preguntarse si el término (crisis del software) es aún apropiado.

• Robert Glass expone: «Puedo ver en mis ensayos históricos de fallos y en mis informes de excepción, fallos importantes en medio de muchos éxitos, una copa que está [ahora] prácticamente llena.»


Crisis … (2)

• El conjunto de problemas encontrados en el desarrollo del software de computadoras no se limitan al software que “no funciona correctamente”.

• El mal abarca los problemas asociados a cómo desarrollar software, cómo mantener el volumen cada vez mayor de software existente y cómo poder esperar mantenemos al corriente de la demanda creciente de software.

• Vivimos con esta aflicción desde este día - d e hecho, la industria prospera a pesar de ello.

• Y así, las cosas podrán ser mejores si podemos encontrar y aplicar un remedio.


Mitos

• Muchas de las causas de la crisis del software se pueden encontrar en una mitología que surge durante los primeros años del desarrollo del software.

• A diferencia de los mitos antiguos, que a menudo proporcionaban a los hombres lecciones dignas de tener en cuenta, los mitos del software propagaron información errónea y confusión.


Mitos de gestión (1)

• Mito. Tenemos ya un libro que está lleno de estándares y procedimientos para construir software, ¿no le proporciona ya a mi gente todo lo que necesita saber?

• Realidad. Está muy bien que el libro exista, pero: ¿se usa?, ¿conocen los trabajadores su existencia?, ¿refleja las prácticas modernas de desarrollo de software?, ¿es completo?, ¿está 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 más 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 más importantes que el hardware para conseguir buena calidad y productividad, aunque la mayoría de los desarrolladores del software todavía no las utilicen eficazmente.



• Mito. Si fallamos en la planificación, podemos añadir más programadores y adelantar el tiempo perdido (el llamado algunas veces “concepto de la horda Mongol”).

• Realidad. El desarrollo de software no es un proceso mecánico como la fabricación. Añadir gente a un proyecto de software retrasado lo retrasa aún más. Al principio, esta declaración puede parecer un contrasentido. 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 sólo de una manera planificada y bien coordinada.


Mitos del cliente

• Un cliente que solicita una aplicación de software puede ser una persona del despacho de al lado, un grupo técnico de la sala de abajo, el departamento de ventas o una compañía exterior que solicita un software bajo contrato.

• En muchos casos, el cliente cree en los mitos que existen sobre el software, debido a que los gestores y desarrolladores del software hacen muy poco para corregir la mala información.

• Los mitos conducen a que el cliente se cree una falsa expectativa y, finalmente, quede insatisfecho con el que desarrolla el software.


Mitos del cliente (2)

• Mito. Una declaración general de los objetivos es suficiente para comenzar a escribir los programas. Podemos dar los detalles más adelante…

• 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 sólo después de una exhaustiva comunicación entre el cliente y el analista.


Mitos del cliente (3)

• 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 varía según el momento en que se introduzca.

• 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 coste.


Impacto del cambio (1)

Definición Desarrollo Despuésde la entrega


Impacto del cambio (2)

• Cuando los cambios se solicitan durante el diseño del software, el impacto en el coste 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, coste adicional.

• Los cambios en la función, rendimiento, interfaces u otras características, durante la implementación (codificación y prueba) pueden tener un impacto importante sobre el coste.

• 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.


Mitos de los desarrolladores (1)

• Los mitos en los que aún creen muchos desarrolladores se han ido fomentando durante 50 años de cultura informática.Durante los primeros días del desarrollo del software, la programación se veía como un arte. Las viejas formas y actitudes tardan en morir.

• Mito. Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado.

• Realidad. Alguien dijo una vez: “cuanto más pronto se comience a escribir código, más se tardará 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 le 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 en el software.



• Mito. Lo único que se entrega al terminar el proyecto es el programa funcionando.

• Realidad. Un programa que funciona es sólo una parte de una configuración del 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.


Primeras conclusiones

• Muchos profesionales del software reconocen la falacia de los mitos descritos anteriormente.

• Lamentablemente, las actitudes y métodos habituales fomentan una pobre gestión y malas prácticas técnicas, incluso cuando la realidad dicta un método mejor.

• El reconocimiento de las realidades del software es el primer paso hacia la formulación de soluciones prácticas para su desarrollo.


Resumen (1)

• El software se ha convertido en el elemento clave de la evolución de los sistemas y productos informáticos.

• En los pasados 50 años, el software ha pasado de ser una resolución de problemas especializada y una herramienta de análisis de información, a ser una industria por sí misma.

• Pero la temprana cultura e historia de la “programación” ha creado un conjunto de problemas que persisten todavía hoy.


Resumen (2)

• El software se ha convertido en un factor que limita la evolución de los sistemas informáticos.

• El software se compone de programas, datos y documentos.

• Cada uno de estos elementos componen una configuración que se crea como parte del proceso de la ingeniería del software.

• El intento de la Ingeniería del Software es proporcionar un marco de trabajo para construir software con mayor calidad.


Ejercicios (1)

1. El software es la característica que diferencia a muchos productos y sistemas informáticos. Dé ejemplos de dos o tres productos y de, al menos, un sistema en el que el software, no el hardware, sea el elemento diferenciador.

2. En los años cincuenta y sesenta la programación de computadoras era un arte aprendido en un entorno básicamente experimental. ¿Cómo cree Ud. que ha afectado esto a las prácticas de desarrollo del software hoy?

3. Muchos autores han tratado el impacto de la “era de la información”. Dé varios ejemplos (positivos y negativos) que indiquen el impacto del software en nuestra sociedad.

4. Seleccione una aplicación específica e indique: (a) la categoría de la aplicación de software en la que encaje;(b) el contenido de los datos asociados con la aplicación; (c) la información determinada de la aplicación.


Ejercicios (2)

5. A medida que el software se difunde más, los riesgos para el público (debido a programas defectuosos) se convierten en una preocupación cada vez más significativa. Desarrolle un escenario realista del juicio final (distinto a Y2K) en donde el fallo de computadora podría hacer un gran daño (económico o humano).

6. Lea detenidamente el grupo de noticias de Internet comp.risk y prepare un resumen de riesgos para las personas. Alternativa: Software Engineering Notes publicado por la ACM.

7. Escriba un papel que resuma las ventajas recientes en una de las áreas de aplicaciones de software principales. Entre las selecciones potenciales se incluyen: aplicaciones avanzadas basadas en Web, realidad virtual, redes neuronales artificiales, interfaces humanas avanzadas y agentes inteligentes.

8. Los mitos destacados en la presentación se están viniendo abajo lentamente a medida que pasan los años. Pero otros se están haciendo un lugar. Intente añadir un mito o dos mitos “nuevos” a cada categoría.


¿Qué es Ingeniería del Software?

Una vuelta mas…


Según Pressman

• [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 máquinas reales.


Según Sommerville


Según IEEE

• El IEEE [IEE93] ha desarrollado una definición completa:

Ingeniería del software: (1) 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 al software.

(2) El estudio de enfoques como en (1).


¿Qué es?

• Cuando trabaja para construir un producto o un sistema, es importante seguir una serie de pasos predecibles: un mapa de carreteras (roadmap) que le ayude a obtener el resultado oportuno de calidad.

• El mapa de carreteras a seguir es llamado “proceso del software”.


El proceso del software (1)

• Como el software, al igual que el capital, es el conocimiento incorporado, y puesto que el conocimiento está inicialmente disperso, el desarrollo del software implícito, latente e incompleto en gran medida, es un proceso social de aprendizaje.

• El proceso es un diálogo en el que se reúne el conocimiento y se incluye en el software para convertirse en software.


El proceso del software (2)

• El proceso proporciona una interacción entre los usuarios y los diseñadores, entre los usuarios y las herramientas de desarrollo, y entre los diseñadores y las herramientas de desarrollo [tecnología].

• Es un proceso interactivo donde la herramienta de desarrollo se usa como medio de comunicación, con cada iteración del diálogo se obtiene mayor conocimiento de las personas involucradas.


¿Quién lo hace?

• Los ingenieros de software y sus gestores adaptan el proceso a sus necesidades y entonces lo siguen.

• Además las personas que han solicitado el software tienen un papel a desempeñar en el proceso del software.


Importancia

¿Por qué es importante? • Porque proporciona estabilidad, control y

organización a una actividad que puede, si no se controla, volverse caótica.

¿Cuáles son los pasos? • A un nivel detallado, el proceso que

adoptemos depende del software que estamos construyendo.

• Un proceso puede ser apropiado para crear software de un sistema de aviación, mientras que un proceso diferente por completo puede ser adecuado para la creación de un sitio Web.


¿Cuál es el producto obtenido?

• Desde el punto de vista de un ingeniero de software, los productos obtenidos son: – programas, – documentos y – datos

que se producen como consecuencia de las actividades de ingeniería del software definidas por el proceso.


Calidad

¿Cómo puedo estar seguro de que lo he hecho correctamente?

• Hay una cantidad de mecanismos de evaluación del proceso del software que permiten a las organizaciones determinar la “madurez” de su proceso del software.

• Sin embargo, la calidad, oportunidad y viabilidad a largo plazo del producto que está construyendo son los mejores indicadores de la eficiencia del proceso que estamos utilizando.


La Ingeniería del software es un tecnología multicapa (1)• 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 del software.


La Ingeniería del software - tecnología multicapa (2) - proceso• 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 el 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 asegura la calidad y el cambio se gestiona adecuadamente.


La Ingeniería del software - tecnología multicapa (3) - métodos• Los métodos de la ingeniería del software

indican “cómo” 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 gobiernan cada área de la tecnología e incluyen actividades de modelado y otras técnicas descriptivas.


La Ingeniería del software - tecnología multicapa (4) - herramientas• Las herramientas de la Ingeniería del

software proporcionan un enfoque automático o semiautomá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).


Una visión general de la ingeniería del software• La ingeniería es el análisis, diseño,

construcción, verificación y gestión de entidades técnicas (o sociales).

• Con independencia de la entidad a la que se va a aplicar ingeniería, se deben cuestionar y responder las siguientes preguntas:


Preguntas

• ¿Cuál es el problema a resolver?• ¿Cuáles son las características de la entidad

que se utiliza para resolver el problema?• ¿Cómo se realizará la entidad (y la

solución)?• ¿Cómo se construirá la entidad?• ¿Qué enfoque se va a utilizar para no

contemplar los errores que se cometieron en el diseño y en la construcción de la entidad?

• ¿Cómo se apoyará la entidad cuando usuarios soliciten correcciones, adaptaciones y mejoras de la entidad?


Fases – Fase de definición

• El trabajo que se asocia a la ingeniería del software se puede dividir en tres fases genéricas, con independencia del área de aplicación, tamaño o complejidad del proyecto.

• Cada fase se encuentra con una o varias cuestiones de las destacadas anteriormente.

• La fase de definición se centra sobre el qué. Es decir, durante la definición, el que desarrolla el software intenta identificar qué información ha de ser procesada, qué función y rendimiento se desea, qué comportamiento del sistema, qué interfaces van a ser establecidas, qué restricciones de diseño existen, y qué criterios de validación se necesitan para definir un sistema correcto.


Continuación…

• Por tanto, han de identificarse los requisitos clave del sistema y del software.

• Aunque los métodos aplicados durante la fase de definición variarán dependiendo del paradigma de ingeniería del software (o combinación de paradigmas) que se aplique, de alguna manera tendrán lugar tres tareas principales: – ingeniería de sistemas o de información, – planificación del proyecto del software y – análisis de los requisitos.


Fases – fase de desarrollo

• La fase de desarrollo se centra en el cómo. Es decir, durante el desarrollo un ingeniero del software intenta definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la función dentro de una arquitectura de software, cómo han de implementarse los detalles procedimentales, cómo han de caracterizarse interfaces, cómo ha de traducirse el diseño en un lenguaje de programación (o lenguaje no procedimental) y cómo ha de realizarse la prueba.

• Los métodos aplicados durante la fase de desarrollo variarán, aunque las tres tareas específicas técnicas deberían ocurrir siempre: – diseño del software, – generación de código y – prueba del software.


Fases – Mantenimiento (1)

• La fase de mantenimiento se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente.

• Durante la fase de mantenimiento se encuentran cuatro tipos de cambios:

1. Corrección. Incluso llevando a cabo las mejores actividades de garantía de calidad, es muy probable que el cliente descubra los defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos.



2. Adaptación. Con el paso del tiempo, es probable que cambie el entorno original (por ejemplo: CPU, el sistema operativo, las reglas de empresa, las características externas de productos) para el que se desarrolló el software. El mantenimiento adaptativo produce modificación en el software para acomodarlo a los cambios de su entorno externo.

3. Mejora. Conforme se utilice el software, el cliente/ usuario puede descubrir funciones adicionales que van a producir beneficios. El mantenimiento perfectivo lleva al software más allá de sus requisitos funcionales originales.



4. Prevención. El software de computadora se deteriora debido al cambio, y por esto el mantenimiento preventivo también llamado reingeniería del software, se debe conducir a permitir que el software sirva para las necesidades de los usuarios finales. En esencia, el mantenimiento preventivo hace cambios en programas de computadora a fin de que se puedan corregir, adaptar y mejorar más fácilmente.


Actividades protectoras

• Las actividades de protección se aplican a lo largo de todo el proceso del software:– Seguimiento y control del proyecto de

software.– Revisiones técnicas formales.– Garantía de calidad del software.– Gestión de configuración del software.– Preparación y producción de documentos.– Gestión de reutilización.– Mediciones.– Gestión de riesgos


• Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

• En los últimos años, se ha hecho mucho énfasis en la “madurez del proceso”. El Software Engineering Institute (SEI) ha desarrollado un modelo completo que se basa en un conjunto de funciones de ingeniería del software que deberían estar presentes conforme organizaciones alcanzan diferentes niveles de madurez del proceso.

• Para determinar el estado actual de madurez del proceso de una organización, el SEI utiliza un cuestionario de evaluación y un esquema de cinco grados.


• El esquema de grados determina la conformidad con un modelo de capacidad de madurez (Capacity Maturity Model - CMM) que define las actividades clave que se requieren en los diferentes niveles de madurez del proceso.

• El enfoque del SEI proporciona una medida de la efectividad global de las prácticas de ingeniería del software de una compañía y establece cinco niveles de madurez del proceso, que se definen de la forma siguiente:


• Nivel 1: Inicial. El proceso del software se caracteriza según el caso, y ocasionalmente incluso de forma caótica. Se definen pocos procesos, y el éxito depende del esfuerzo individual.

• Representa una situación sin ningún esfuerzo en la garantía de calidad y gestión del proyecto, donde cada equipo del proyecto puede desarrollar software de cualquier forma eligiendo los métodos, estándares y procedimientos a utilizar que podrán variar desde lo mejor hasta lo peor.


• Nivel 2: Repetible. Se establecen los procesos de gestión del proyecto para hacer seguimiento del coste, de la planificación y de la funcionalidad.

• Para repetir éxitos anteriores en proyectos con aplicaciones similares se aplica la disciplina necesaria para el proceso.

• Representa el hecho de que un desarrollador de software ha definido ciertas actividades tales como el informe del esfuerzo y del tiempo empleado, y el informe de las tareas realizadas.


• Nivel 3: Definido. El proceso del software de las actividades de gestión y de ingeniería se documenta, se estandariza y se integra dentro de un proceso de software de toda una organización.

• Todos los proyectos utilizan una versión documentada y aprobada del proceso de la organización para el desarrollo y mantenimiento del software.

• En este nivel se incluyen todas las características definidas para el nivel 2.

• Representa el hecho de que un desarrollador de software ha definido tanto procesos técnicos como de gestión, por ejemplo un estándar para la programación ha sido detallado y se hace cumplir por medio de procedimientos tales como auditorías.

• Este nivel es aquel en el que la mayoría de los desarrolladores de software, pretenden conseguir con estándares como el ISO 9001, y existen pocos casos de desarrolladores de software que superan este nivel.


• Nivel 4: Gestionado. Se recopilan medidas detalladas del proceso del software y de la calidad del producto.

• Mediante la utilización de medidas detalladas, se comprenden y se controlan cuantitativamente tanto los productos como el proceso del software.


• Comprende el concepto de medición y el uso de métricas.


Métricas

• Una métrica es una cantidad insignificante que puede extraerse de algún documento o código dentro de un proyecto de software.

• Un ejemplo de métrica es el número de ramas condicionales en una sección de código de un programa.

• Esta métrica es significativa en el sentido de que proporciona alguna indicación del esfuerzo necesario para probar el código: está directamente relacionado con el número de caminos de prueba dentro del código.


• Una organización del nivel 4 maneja numerosas métricas.

• Estas métricas se utilizan entonces para supervisar y controlar un proyecto de software, por ejemplo:– Una métrica de prueba puede usarse para

determinar cuándo finalizar la prueba de un elemento del código.

– Una métrica de legilibilidad puede usarse para juzgar la legilibilidad de algún documento en lenguaje natural.

– Una métrica de comprensión del programa puede utilizarse para proporcionar algún umbral numérico que los programadores no pueden cruzar.


• Para que estas métricas alcancen este nivel es necesario que todos los componentes del nivel 3 CMM, en castellano MCM (Modelo de Capacidad de Madurez), estén conseguidos, por ejemplo notaciones bien definidas para actividades como la especificación del diseño de requisitos, por lo que estas métricas pueden ser fácilmente extraídas de modo automático.


• Nivel 5: Optimización. Mediante una retroalimentación cuantitativa del proceso, ideas y tecnologías innovadoras se posibilita una mejora del proceso.


• Es el nivel más alto a alcanzar. • Hasta ahora, muy pocos desarrolladores de

software han alcanzado esta fase. • Representa la analogía del software con los

mecanismos de control de calidad que existen en otras industrias de mayor madurez.


• El desarrollador del software en el nivel 5 puede predecir resultados como el número de errores latentes en un producto basado en la medición tomada durante la ejecución de un proyecto.

• Además, dicho desarrollador puede cuantificar el efecto que un proceso nuevo o herramienta de manufacturación ha tenido en un proyecto examinando métricas para ese proyecto y comparándolas con proyectos anteriores que no utilizaron ese proceso o herramienta.


• El SEI ha asociado áreas claves del proceso (ACPs) a cada uno de los niveles de madurez.

• Las ACPs describen esas funciones de la ingeniería del software (por ejemplo: planificación del proyecto de software, gestión de requisitos) que se deben presentar para satisfacer una buena práctica a un nivel en particular.

• Cada ACP se describe identificando las características siguientes:


• Objetivos- los objetivos globales que debe alcanzar la ACP

• Compromisos- requisitos (impuestos en la organización) que se deben cumplir para lograr los objetivos y que proporcionan una prueba del intento por ajustarse a los objetivos.

• Capacidades- aquellos elementos que deben encontrarse (organizacional y técnicamente) para permitir que la organización cumpla los objetivos.


• Actividades- las tareas específicas que se requieren para lograr la función ACP.

• Métodos para supervisar la implementación-la manera en que las actividades son supervisadas conforme se aplican.

• Métodos para verificar la implementación- la forma en que se puede verificar la práctica adecuada para la ACP.


• Se definen dieciocho ACPs (descritas mediante la estructura destacada anteriormente) en el modelo de madurez y se distribuyen en niveles diferentes de madurez del proceso.

• Las ACPs se deberían lograr en cada nivel de madurez de proceso:


Nivel 2 de Madurez del Proceso1. Gestión de configuración del software2. Garantía de calidad del software3. Gestión de subcontratación del

software4. Seguimiento y supervisión del

proyecto del software5. Planificación del proyecto del

software6. Gestión de requisitos


Nivel 3 de Madurez del Proceso7. Revisiones periódicas8. Coordinación entre grupos9. Ingeniería de productos de software10.Gestión de integración del software11.Programa de formación12.Definición del proceso de la

organización13.Enfoque del proceso de la

organización


Nivel 4 de Madurez del Proceso14.Gestión de calidad del software15.Gestión cuantitativa del proceso

Nivel 5 de Madurez del Proceso16.Gestión de cambios del proceso17.Gestión de cambios de tecnología18.Prevención de defectos


• Cada una de las ACPs se definen con un conjunto de prácticas clave que contribuyen a cumplir estos objetivos.

• Las prácticas clave son normas, procedimientos y actividades que deben ocurrir antes de que se haya instituido completamente un área clave de proceso.

• El SEI define a los indicadores clave como “aquellas prácticas clave o componentes de prácticas clave que ofrecen una visión mejor para lograr los objetivos de un área clave de proceso”.

• Las cuestiones de valoración se diseñan para averiguar la existencia (o falta) de un indicador clave.


Modelos del proceso de software• Para resolver los problemas reales de una industria, un

ingeniero del software o un equipo de ingenieros debe incorporar una estrategia de desarrollo que acompañe al proceso, métodos y capas de herramientas descritos y las fases genéricas discutidas.

• Esta estrategia a menudo se llama modelo de proceso o paradigma de ingeniería del software.

• Se selecciona un modelo de proceso para la ingeniería del software según la naturaleza del proyecto y de la aplicación, los métodos y las herramientas a utilizarse, y los controles y entregas que se requieren.

• En un documento intrigante sobre la naturaleza del proceso del software, L.B.S. Raccoon [RAC95] utiliza fractales como base de estudio de la verdadera naturaleza del proceso del software.


• Todo el desarrollo del software se puede caracterizar como bucle de resolución de problemas en el que se encuentran cuatro etapas distintas:

1. “status quo”: “representa el estado actual de sucesos”

2. definición de problemas: identifica el problema específico a resolverse,

3. desarrollo técnico: resuelve el problema a través de la aplicación de alguna tecnología.

4. integración de soluciones: ofrece los resultados (por ejemplo: documentos, programas, datos, nueva función comercial, nuevo producto) a los que solicitan la solución en primer lugar.

• Las fases y los pasos genéricos de ingeniería del software definidos se dividen fácilmente en estas etapas.


Resumen

• La ingeniería del software es una disciplina que integra procesos, métodos y herramientas para el desarrollo del software de computadora.

• Se han propuesto varios modelos de procesos para la ingeniería del software diferentes, cada uno exhibiendo ventajas e inconvenientes pero todos tienen una serie de fases genéricas en común.

• En el resto de este curso se consideran los principios, conceptos y métodos que permiten llevar a cabo el proceso que se llama ingeniería del software.


Fuentes de información

• Sommerville, I. “Ingeniería de Software” 7ma edición.

• Pressman, R. “Ingeniería de Software: Un enfoque práctico” 5ta edición:– cap 1 12p– cap 2 22p

• Kendall, K.E. y Kendall, J.E. “Análisis y diseño de sistemas” 6ta edición.

1 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy ACI491:...

Documents

Transcript of 1 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy ACI491:...