ACI491: Ingenierнa de Software

1
ACI491Ingenierí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.