e-Business Essentials SE100

1
Universidad de Los Lagos
Curso Ingeniería de SoftwareINFT.1
Profesor Hermón Alfaro F. Hermon.alfaro_at_tm-mas.
com
2
Objetivos

• Descripción de las actividades técnicas e
  ingenieriles que se llevan a cabo en el ciclo de
  vida de un producto software
• Descripción de los problemas, principios, métodos
  y tecnologías asociadas con la Ingeniería del
  Software
• Presentación de la importancia de los requisitos
  en el ciclo de vida del software
• Introducción a las técnicas básicas de
  elicitación, documentación, especificación y
  prototipado de los requisitos de un sistema
  software
• Introducción a los métodos de análisis/diseño
  estructurado, y los métodos de análisis/diseño
  orientado a objetos
• Estudio y comprensión de los fundamentos del
  diseño de sistemas software
• Aplicar de forma práctica los conceptos teóricos
  sobre el desarrollo estructurado y orientado a
  objetos

3
Motivación
4

• La Ingeniería del Software dentro del currículo
  de los ingenieros en informática aporta la
  primera aproximación a la práctica real del
  desarrollo de software
• Proyectos realizados por equipos de desarrollo
• Programación a gran escala (programming in large)
• Obtención (elicitación) de los requisitos
• Modelos de ciclo de vida
• Gestión de la configuración
• Calidad del software
• Mantenimiento

5
Ingeniería? de Software
6
Ingeniería vs Métodos Tradicionales
7
Grandes Problemas Históricos

• Retraso respecto al potencial de hardware
• Insatisfacción de la demanda
• Bajo cumplimiento de compromisos costos,
  plazos
• Baja calidad y satisfacción de clientes/usuarios
• Mantención de sistemas legados

8
Percepciones de la Disciplina

• Ineficiencia Altos costos
• Baja confiabilidad
• Escasa ingeniería

9
Crisis del Software

• Origina la disciplina Ingeniería de Software en
  los 60s
• Síntomas típicos
• funcionalidad incorrecta
• costos y plazos excedidos
• insatisfacción de clientes y usuarios
• poca o nula visibilidad de lo que ocurre

10
Crisis del Software

• Algunas causas potenciales
• carácter lógico del software
• formación profesional (o falta de)
• entrenamiento y actualización
• resistencia al cambio
• Solución potencial
• incorporar enfoque ingenieril en la forma de un
  proceso de software

11
Crisis del Software

• Algunos mitos bastantes arraigados también
• estándares y procedimientos bastan
• tecnología de punta basta
• más gente para ponerse al día
• programación inmediata
• fácil acomodo de los cambios
• programación fin del trabajo
• calidad sólo del ejecutable
• código es el único producto

12
Ingeniería de Software

• Establecimiento y uso de principios con
  caracteres de ingeniería apropiados para
  obtener, eficientemente, software
  confiable, que opere eficaz y eficientemente en
  máquinas reales
• Concepto se acuñó en 1968, en Conferencia de la
  OTAN en Alemania , con la intención de
• que mediante el uso de filosofías y paradigmas de
  disciplinas ingenieriles establecidas se
• resolviera la denominada crisis del software

13
Ingeniería de Software

• Objetivos
• maximizar calidad
• maximizar productividad
• minimizar riesgos

14
Ingeniería de Software

• Implicancias
• mejores técnicas de control de calidad
• mejores herramientas y métodos
• Todo en la forma de proceso de software adecuado
  al tipo de problema que se resuelve y que
  permitan gestionar de mejor manera los
  principales riesgos relevantes para todos los
  stakeholders (involucrados o afectados)

15

• Proceso de Software Para Gestionar Riesgos

16
Proceso de Software
Operación
Desarrollo de software
Análisis
Diseño
Construcción y Pruebas Unitarias
Pruebas
Mantención
Procesos de apoyo Gestión de proyectos, Gestión
de Configuración, Gestión de Requerimientos,
Gestión de la Calidad, .
17
Riesgos de Software

• Categorías - Top 10
• Métricas inadecuadas
• Medición inadecuada
• Presión excesiva de tiempo
• Malas prácticas de gestión
• Estimación imprecisa de costos
• Síndrome del silver bullet
• Requerimientos Baja calidad
• Baja productividad
• Cancelación de proyectos

18
Proceso de Software

• Proveer un producto o un servicio, siempre
  consiste en seguir una secuencia de pasos, para
  llevar a cabo un conjunto de tareas
• Las tareas se ejecutan usualmente en el mismo
  orden todas las veces
• Un proceso es una serie de pasos que involucran
  actividades, restricciones y recursos, que
  producen una salida esperada, de algún tipo.
• Un proceso involucra usualmente un conjunto de
  herramientas y técnicas.

19
Proceso de Software

• Es importante, pues impone consistencia y
  estructura al conjunto de actividades
• Es más que un procedimiento, es un conjunto
  organizado de éstos.
• La estructura del proceso guía la acción,
  permitiendo examinar, entender, controlar y
  mejorar las actividades comprendidas por éste.
• También es importante pues permite capturar y
  transmitir la experiencia, a proyectos futuros
• Cada proceso puede ser descrito por una
  combinación de diferentes medios.

20
Un poco de Historia

• El modelo usado era de codificar-corregir
• Escribir el código.
• Revisar y eliminar los errores o mejorar/aumentar
  la funcionalidad.
• A medida que el hardware aumentó sus capacidades
  y disminuyó sus costos, se amplió el ámbito de
  las aplicaciones y se masificó el uso de
  computadores.
• Se incursionó en áreas donde los problemas no
  eran tan bien acotados (ej. administrativos) y
  el desarrollo se tornó más complejo.

21
Un poco de Historia

• Aparece un problema aún mayor había que
  mantener los sistemas.
• Esto escapó de las manos de los usuarios-
  programadores, quienes ya no pudieron controlar
  el proceso, pues sólo dominaban su especialidad,
  no el desarrollo de software.
• Se incorporan tópicos organizacionales y
  psicológicos, así como también la demanda por
  mayor calidad y confiabilidad.

22
Un poco de Historia

• Además, ahora el desarrollo se convierte en una
  actividad de grupo, lo cual demanda planificar,
  organizar y estructurar el trabajo en torno a
  proyectos.
• La comunicación entre humanos (usuario-
  desarrollador y desarrollador-desarrollador) se
  convierte en un problema.
• Se hace necesario definir un Proceso

23
Un poco de Historia

• El proceso a la antigua, como caja negra.

24
Modelos de Proceso de Software

• En la Ingeniería de Software se describen muchos
  Modelos de Proceso.
• Unos son prescriptivos establecen la forma en
  que debería progresar el proceso de software.
• Otros son descriptivos dicen la forma en que el
  proceso de software progresa en la realidad.

25
Algunos Modelos deProceso de Software

• Modelo en Cascada.
• Modelo en V.
• Modelo de Prototipación.
• Modelo en Espiral.
• RUP Métodos Ágiles.

26
Modelo en Cascada

• Es el más antiguo.
• Debe completarse un estado antes de comenzar el
  siguiente.
• Es útil para que el desarrollador visualice lo
  que va a hacer.
• Su principal problema es que no refleja la
  realidad..

27
Modelo en Cascada
28
Modelo en Cascada

• Análisis de Requerimientos
• Se centra e intensifica especialmente en el
  software
• El ingeniero de software debe comprender el
  ámbito de la información del software, así como
  la función, el rendimiento y las interfaces
  requeridas
• Diseño (sistema y programa)
• Se enfoca en cuatro atributos la estructura de
  los datos, la arquitectura del software, el
  detalle procedimental y la caracterización de la
  interfaz
• El proceso de diseño traduce los requisitos en
  una representación del software con la calidad
  requerida antes de que comience la codificación
• Codificación
• El diseño debe traducirse en una forma legible
  para la maquina. Si el diseño se realiza de una
  manera detallada la codificación puede realizarse
  automáticamente

29
Modelo en Cascada

• Prueba (unitario, integración, sistema,
  aceptación)
• una vez que se ha generado el código comienza la
  prueba del programa.
• La prueba se centra en la lógica interna del
  software, y en las funciones externas, realizando
  pruebas que aseguren que la entrada definida
  produce los resultados requeridos
• Mantenimiento
• el software sufrirá cambios después de que se
  entrega al cliente, los cambios ocurrirán debido
  a que hayan encontrado errores, a que el software
  deba adaptarse a cambios del entorno externo
  (sistema operativo o dispositivos periféricos), o
  debido a que el cliente requiera ampliaciones
  funcionales o del rendimiento

30
Modelo V
31
Modelo V

• La primera mitad es similar al Modelo en Cascada,
  y la otra mitad tiene como finalidad hacer
  pruebas e integración asociado a cada una de las
  etapas de la mitad anterior.
• Se puede identificar una ventaja principal con
  respecto al Modelo Cascada más simple, y se
  refiere a que este modelo involucra chequeos de
  cada una de las etapas del modelo de cascada.

32
Modelo de Prototipación

• Permite la construcción rápida del sistema (o
  parte de éste).
• Usuario y desarrollador tienen una visión común.
• Se reduce el riesgo y lo incierto del desarrollo

33
Modelo en Espiral

• Se combinan las actividades de desarrollo con
  Análisis de Riesgo.
• El modelo es de tipo iterativo
• Planificación ? Análisis de Riesgo ? Ingeniería ?
  Evaluación ? Planificación ?
• ..En cada iteración, se evalúan las diferentes
  alternativas y se elige una.
• Los gestores del proyecto intentan eliminar o
  minimizar el riesgo.

34
Modelo en Espiral
35
RUP Rational Unified Process

• Su objetivo es asegurar la producción de software
  de calidad dentro de plazos y presupuestos
  predecibles.
• Dirigido por casos de uso, centrado en la
  arquitectura, iterativo (mini-proyectos) e
  incremental (versiones)
• Cada ciclo de vida del software abarca 4 fases en
  el siguiente orden concepción/planificación,
  elaboración, construcción y transición
• La esencia de RUP es la iteración, y cada
  iteración resulta en un entregable
  preferentemente ejecutable

36
RUP Rational Unified Process
37
Mapa Conceptual de RUP
38
Fases de RUP Inception (Inicio)

• Se establece la oportunidad y alcance el
  proyecto.
• Se identifican todas las entidades externas con
  las que se trata (actores) y se define la
  interacción a un alto nivel de abstracción
• Identificar todos los casos de uso
• Describir algunos en detalle
• La oportunidad del negocio incluye
• Criterios de éxito
• Identificación de riesgos
• Estimación de recursos necesarios
• Plan de las fases incluyendo hitos

39
Fases de RUP Inception (Inicio)
Productos

• Un documento de visión general
• Requerimientos generales del proyecto
• Características principales
• Restricciones
• Modelo inicial de casos de uso (10 a 20
  listos).
• Glosario.

• Caso de negocio
• Contexto
• Criterios de éxito
• Pronóstico financiero
• Identificación inicial de riesgos.
• Plan de proyecto.
• Uno o más prototipos.

40
Fases de RUP Inception (Inicio)
Hito
Objetivos del Ciclo de Vida
Inicio
Elaboración
Construcción
Transición

• Las partes interesadas deben acordar el alcance y
  la estimación de tiempo y costo.
• Comprensión de los requerimientos plasmados en
  casos de uso.

41
Fases de RUP Elaboración

• Objetivos
• Analizar el dominio del problema
• Establecer una arquitectura base sólida
• Desarrollar un plan de proyecto
• Eliminar los elementos de mayor riesgo para el
  desarrollo exitoso del proyecto
• Visión de una milla de amplitud y una pulgada de
  profundidad porque las decisiones de
  arquitectura requieren una visión global del
  sistema.

42
Fases de RUP Elaboración
Productos

• Es la parte más crítica del proceso
• Al final toda la ingeniería dura está hecha
• Se puede decidir si vale la pena seguir adelante
• A partir de aquí la arquitectura, los
  requerimientos y los planes de desarrollo son
  estables.

• Ya hay menos riesgos y se puede planificar el
  resto del proyecto con menor incertidumbre.
• Se construye una arquitectura ejecutable que
  contemple
• Los casos de uso críticos
• Los riesgos identificados

43
Fases de RUP Elaboración
Productos

• Modelo de casos de uso (80 completo) con
  descripciones detalladas.
• Otros requerimientos no funcio-nales o no
  asociados a casos de uso.
• Descripción de la Arquitectura del Software.

• Un prototipo ejecutable de la arquitectura.
• Lista revisada de riesgos y del caso de negocio.
• Plan de desarrollo para el resto del proyecto.
• Un manual de usuario preliminar.

44
Fases de RUP Elaboración
Hito
Arquitectura de Ciclo de Vida
Inicio
Elaboración
Construcción
Transición

• Condiciones de éxito de la elaboración
• Es estable la visión del producto?
• Es estable la arquitectura?
• Las pruebas de ejecución demuestran que los
  riesgos han sido abordados y resueltos?
• Es el plan del proyecto algo realista?
• Están de acuerdo con el plan todas las personas
  involucradas?

45
Fases de RUP Construcción

• En esta fase todas las componentes restantes se
  desarrollan e incorporan al producto.
• Todo es probado en profundidad.
• El énfasis está en la producción eficiente y no
  ya en la creación intelectual.
• Puede hacerse construcción en paralelo, pero esto
  exige una planificación detallada y una
  arquitectura muy estable.

46
Fases de RUP Construcción
Productos

• El producto de software integrado y corriendo en
  la plataforma adecuada.
• Manuales de usuario.
• Una descripción del release actual.

47
Fases de RUP Construcción
Hito
Capacidad Operacional
Inicio
Elaboración
Construcción
Transición

• Se obtiene un producto Beta que debe decidirse si
  puede ponerse en ejecución sin mayores riesgos.
• Condiciones de éxito
• El producto está maduro y estable para
  instalarlo en el ambiente del cliente?
• Están los interesados listos para recibirlo?

48
Fases de RUP Transición

• El objetivo es traspasar el software desarrollado
  a la comunidad de usuarios.
• Una vez instalado surgirán nuevos elementos que
  implicarán nuevos desarrollos (ciclos).
• Incluye
• Pruebas Beta para validar el producto con las
  expectativas del cliente
• Ejecución paralela con sistemas antiguos
• Conversión de datos
• Entrenamiento de usuarios
• Distribuir el producto

49
Fases de RUP Transición
Objetivos

• Obtener autosuficiencia de parte de los usuarios.
• Concordancia en los logros del producto de parte
  de las personas involucradas.
• Lograr el concenso cuanto antes para liberar el
  producto al mercado.

Inicio
Elaboración
Construcción
Transición
Producto
50
Métodos Ágiles

• Interés creciente en los métodos ágiles
  (inicialmente llamados ligeros, lightweight) en
  los últimos años
• enfrentamiento de requerimientos cambiantes
• tiempos de desarrollo escasos
• clientes y usuarios cada vez más exigentes
• Caracterizados alternativamente como
• antídoto a la burocracia (métodos planificados,
  pesados)

51
Métodos Ágiles

• Algunas características de los métodos ágiles
• Documentación mínima
• Ciclos iterativos breves
• Reacción rápida ante los cambios
• Estrecha relación con el cliente
• Diseño simple
• Satisfacción de necesidades inmediatas
• Foco en las personas
• Organización libre
• Procesos adaptables, no predictivos

52
Métodos Ágiles

• El proceso de Desarrollo XP
• Fase inicial de captura de requerimientos es
  eliminada
• El ciclo de desarrollo de XP se divide en
  liberaciones cada una de las cuales es medida en
  historias de usuario
• Historia de usuario unidad funcional en un
  proyecto XP, debe ser entendible tanto para el
  cliente como para los desarrolladores,
  verificable y pequeña

53
Métodos Ágiles

• El proceso de desarrollo XP
• Fase de Exploración
• Fase de Planificación
• Fase de Iteraciones y Entregas
• Fase de Producción
• Fase de Mantenimiento
• Fase de Muerte

54
Métodos Ágiles
55
Principales Métodos Ágiles

• Extreme Programming, XP
• Scrum
• Crystal Family
• Feature-Driven Design
• Adaptive Software Development
• DSDM
• Otros

56
Agilidad vs. Proceso

• Ultimamente, distintos trabajos han investigado
  la relación entre modelos de proceso y métodos
  ágiles, observando lo siguiente
• CMM/CMMI y XP pueden complementarse (foco en
  aspectos de gestión vs. técnicos)
• Métodos ágiles calzan con la esencia del
  mejoramiento de procesos bajo una interpretación
  menos literal (que CMMI, por ejemplo)
• Métodos ágiles apuntan a gestión de proyectos, no
  a gestión de procesos

57
Bibliografía

• Pressman Roger. Ingeniería del Software.
  Tercera
• Software Engineering Theory and Practice (2nd
  Ed.) Shari Pfleeger, Prentice Hall (2001), Cap.
  12
• The Software-Research Crisis. Robert L. Glass,
  IEEE Software, Noviembre 1994
• Using Risk to Balance Agile and Plan-Driven
  Methods Barry Boehm, Richard Turner, IEEE
  Computer, Junio 2003
• Agile Alliance http//www.agilealliance.com/
• What is extreme programming? http//www.xprogrammi
  ng.com/

58
Anexos
59
Arquitectura de Sistemas Computacionales
Ingeniería de Software
Estructuración de los Procesos
Estructuración de las Comuni caciones
Ingeniería de las comunicaciones
Estructuración de los Datos
Ingeniería de la Información
60
Arquitectura de Sistemas Computacionales
Datos
Función
Comunicaciones
.
Nivel Conceptual
.
.
.
(Esquema del Negocio)
Nivel Lógico
(S.I.A)
Nivel Físico
(Implementa ción Compu tacional)
61
(No Transcript)