ACI491: Ingenierнa de Software - PowerPoint PPT Presentation

Loading...

PPT – ACI491: Ingenierнa de Software PowerPoint presentation | free to download - id: 3cccb6-YzE5Y



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

ACI491: Ingenierнa de Software

Description:

ACI491: Ingenier a de Software Unidad 5: Introducci n a la Ingenier a de Software Contenidos Importancia del software. Impacto del software en los productos y ... – PowerPoint PPT presentation

Number of Views:33
Avg rating:3.0/5.0
Slides: 74
Provided by: nuestroNe
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: ACI491: Ingenierнa de Software


1
ACI491 Ingeniería de Software
  • Unidad 5
  • Introducción a la Ingeniería de Software

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

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

4
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).

5
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?

6
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

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

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

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

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

11
Mitos de gestión (2)
  • 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.

12
Mitos de gestión (3)
  • 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.

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

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

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

16
Impacto del cambio (1)
Definición Desarrollo
Después de la entrega
17
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.

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

19
Mitos de los desarrolladores (2)
  • 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.

20
Mitos de los desarrolladores (3)
  • 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.

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

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

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

24
Ejercicios (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.
  • 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?
  • 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.
  • 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.

25
Ejercicios (2)
  • 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).
  • 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.
  • 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.
  • 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.

26
Qué es Ingeniería del Software?
  • Una vuelta mas

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

28
Según Sommerville
29
(No Transcript)
30
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).

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

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

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

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

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

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

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

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

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

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

41
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).

42
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

43
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?

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

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

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

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

48
Fases Mantenimiento (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.
  • 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.

49
Fases Mantenimiento (3)
  • 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.

50
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

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

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

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

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

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

56
  • 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.
  • En este nivel se incluyen todas las
    características definidas para el nivel 3.
  • Comprende el concepto de medición y el uso de
    métricas.

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

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

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

60
  • Nivel 5 Optimización. Mediante una
    retroalimentación cuantitativa del proceso, ideas
    y tecnologías innovadoras se posibilita una
    mejora del proceso.
  • En este nivel se incluyen todas las
    características definidas para el nivel 4.
  • 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.

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

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

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

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

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

66
  • Nivel 2 de Madurez del Proceso
  • Gestión de configuración del software
  • Garantía de calidad del software
  • Gestión de subcontratación del software
  • Seguimiento y supervisión del proyecto del
    software
  • Planificación del proyecto del software
  • Gestión de requisitos

67
  • Nivel 3 de Madurez del Proceso
  • Revisiones periódicas
  • Coordinación entre grupos
  • Ingeniería de productos de software
  • Gestión de integración del software
  • Programa de formación
  • Definición del proceso de la organización
  • Enfoque del proceso de la organización

68
  • Nivel 4 de Madurez del Proceso
  • Gestión de calidad del software
  • Gestión cuantitativa del proceso
  • Nivel 5 de Madurez del Proceso
  • Gestión de cambios del proceso
  • Gestión de cambios de tecnología
  • Prevención de defectos

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

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

71
  • Todo el desarrollo del software se puede
    caracterizar como bucle de resolución de
    problemas en el que se encuentran cuatro etapas
    distintas
  • status quo representa el estado actual de
    sucesos
  • definición de problemas identifica el problema
    específico a resolverse,
  • desarrollo técnico resuelve el problema a través
    de la aplicación de alguna tecnología.
  • 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.

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

73
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.
About PowerShow.com