TEMA 1: INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE · Ingeniería del Software - 2011/2012 4 !...

TEMA 1: INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE

Profesor: David Granada

Índice 1.1. Introducción 1.2. La complejidad inherente del software 1.3. Algunos principios de la ingeniería del

software 1.4. Algunos aspectos sobre calidad del

software 1.5. El ciclo de vida del software 1.6. Metodologías de desarrollo

2 Ingeniería del Software - 2011/2012

¿Qué es Ingeniería?

Ingeniería del Software - 2011/2012 3

Es el conjunto de conocimientos y técnicas científicas aplicadas a la invención, perfeccionamiento y utilización de la técnica industrial para la resolución u optimización de problemas.

¿Qué es ser Ingeniero?


n  Saber aplicar diseños y soluciones tecnológicas a necesidades sociales, industriales o económicas

n  Saber identificar y comprender los obstáculos más importantes para poder realizar un buen diseño (limitaciones físicas o técnicas, de coste, de flexibilidad, estéticas y comerciales)

n  Saber utilizar el conocimiento de la ciencia y la experiencia apropiada para encontrar las mejores soluciones a los problemas concretos

¿Qué es software?


Es el conjunto de los programas de cómputo, procedimientos, reglas, documentación y datos asociados que forman parte de las operaciones de un sistema de computación.

Extraído del estándar 729 del IEEE


¿Qué es software?

¿Qué es software?

n  Conjunto de programas que proporcionan una función y un rendimiento esperados.

n  Conjunto de estructuras de datos que permiten a los programas manipular adecuadamente la información. (Datos de configuración).

n  Conjunto de documentos que describen el funcionamiento del SI (Documentación).


¿Qué es software? - Características

n  No tiene forma física. ¨ Se desarrolla, no se fabrica. ¨ Los costes del SW son de INGENIERÍA. No de

fabricación.

n  El SW no se rompe, se deteriora. ¨ La complejidad del mantenimiento del SW es

mucho más grande que la del HW. n  Si el HW se rompe se cambia por otro y listo. (Hay

piezas de recambio). n  Si el SW se deteriora, con cada cambio que se realiza

se deteriora aún más. (No hay piezas de recambio).


Productos de Software

n  Productos genéricos : Productos que son producidos por una organización para ser vendidos al mercado.

n  Productos hechos a medida: Sistemas que son desarrollados bajo pedido a un equipo de desarrollo interno o externo a la empresa.


¿Qué es Ingeniería del Software?

“La Ingeniería del Software es la disciplina de ingeniería encargada de todos los aspectos relacionados con la producción de software desde sus etapas más tempranas de la especificación del sistema hasta el mantenimiento del sistema tras su puesta en marcha.”

Ingeniería del Software – Ian Sommerville


¿ Qué es Ingeniería del Software?

n  Disciplina de ingeniería ¨ Los ingenieros de software usan las herramientas,

métodos y teorías para solucionar los problemas que aparecen. Incluso teniendo en cuenta restricciones económicas y de organización.

n  Producción de software (Aspectos) ¨ Planificación de proyectos. ¨ Administración de proyectos software. ¨ Procesos técnicos de desarrollo de software. ¨ Dirección de proyectos.


¿Por qué surge la Ingeniería SW?

n  Para superar la crisis del software y terminar con los mitos del software hasta ahora existentes.

n  Para acabar con las malas prácticas de desarrollo y mantenimiento de software llevadas a cabo por las empresas.

n  Para crear software de calidad. 12 Ingeniería del Software - 2011/2012

Crisis del Software

n  Dificultad en escribir programas libres de defectos, fácilmente comprensibles, y que sean verificables. (Dijkstra – 1968).

n  Causas: ¨  Los proyectos no terminaban en plazo. ¨  Los proyectos no se ajustaban al presupuesto inicial. ¨  Software que no cumplía las especificaciones. ¨  Código inmantenible que dificultaba la gestión y evolución del proyecto.

n  Consecuencias: ¨  Baja calidad del software. ¨  Tiempo y presupuesto excedido. ¨  Confiabilidad cuestionable. ¨  Altos requerimientos del personal para el desarrollo y el mantenimiento.


Mitos del SW – Sobre la gestión

Mito •  “La empresa ya dispone de unos estándares de

trabajo y unos procedimientos de desarrollo establecidos y son conocidos por todos nuestros

empleados”.

Realidad •  Muchas empresas no disponen de estándares ni

procedimientos de trabajo y si los disponen, éstos son incompletos, no utilizan prácticas modernas de desarrollo, no todo el personal los conoce y nadie controla que éstos

se apliquen.



Mito •  “El equipo de trabajo dispone de las más

modernas herramientas de desarrollo y trabaja con las máquinas más potentes”.

Realidad •  No sirve de nada trabajar con las mejores máquinas o utilizar las herramientas más modernas si el equipo no tiene los conocimientos necesarios para utilizarlas

eficazmente (cursos de formación, soporte profesional externo…).



Mito •  “¿Por qué hacer una planificación

exhaustiva? Si cometemos algún error, siempre podemos añadir gente”.

Realidad • Añadir gente nueva en un proyecto que está atrasado, lo hace atrasar aún más. Los nuevos

integrantes deben integrarse, recibir formación y aprender la manera de comunicarse en el grupo.


Mitos del SW – Sobre el cliente

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 inútil en software. Es esencial una descripción

formal y detallada del ámbito de la información. Es necesaria una exhaustiva comunicación entre el cliente

y el analista.


Mitos del SW – Sobre el cliente

Mito •  “Los requisitos del proyecto cambian continuamente,

pero los cambios pueden acomodarse fácilmente ya que el software es flexible”.

Realidad •  Es verdad que los requisitos del software cambian, pero

el impacto del cambio varia según en el momento que se presenten (Definición: Bajo Impacto || Desarrollo: Alto

Impacto || Después de la entrega: Impacto Crítico).


Mitos del Sw – Sobre desarrolladores

Mito •  “No es necesaria ninguna metodología, cuanto

antes empecemos a programar, antes acabaremos”.

Realidad •  Cuando más pronto se comience a escribir código, más se tardará en terminarlo. Entre el 50% y el 70%

de todo el esfuerzo dedicado a un programa se realizará después de que se la haya entregado al

cliente por primera vez.


Mitos del SW – Sobre desarrolladores

Mito •  “Lo único que realmente importa, cuando se

termina un proyecto, es que la aplicación funcione. La documentación nadie la utiliza”.

Realidad •  La documentación es la base de un desarrollo y,

lo que es más importante, proporciona guías para la tarea de mantenimiento del software.


Malas prácticas de desarrollo y mantenimiento

n  Planificación y estimaciones imprecisas: ¨ No se recopilan datos de proyectos pasados.

n  Se invierte más dinero en mantenimiento que en formación de los ingenieros en las nuevas tecnologías de desarrollo.

n  No se documenta lo suficiente.

n  Se pasa directamente a la codificación. 21 Ingeniería del Software - 2011/2012


n  Procesos software improvisados. ¨ No se siguen rigurosamente las especificaciones.

n  No se hace planificación de riesgos. ¨ Se resuelven crisis inmediatas. Se apagan fuegos.

n  Se sacrifica funcionalidad y calidad del producto para cumplir plazos. ¨ No se planifica debidamente.

n  No se realizan pruebas, verificaciones o revisiones del SW.



Síntomas: n  Baja calidad del software desarrollado. Alto

grado de desconfianza e insatisfacción en el cliente.

n  Empresas inmaduras En fase artesanal. ¨ Se exceden en los plazos y presupuestos

previstos. ¨ 90% de los proyectos no consiguen los objetivos

propuestos. ¨ 40% fracasan completamente. ¨ 29% nunca se entregan.


¿Qué propone la IS? – Ser ingenieros

n Artesano Ingeniero

n Para ello se debe: ¨ Aplicar métodos, técnicas y herramientas de

desarrollo. ¨ Adoptar estándares de desarrollo. ¨ Utilizar la experiencia acumulada. ¨ Documentación.


¿Qué propone la IS? – Ser ingenieros

Herramientas

Métodos

Proceso

Un enfoque de calidad

25

Se sustenta en un compromiso de calidad.

Ingeniería del Software - 2011/2012

¿Qué propone la IS? – Estándares

n ¿Qué conseguimos adoptando estándares de desarrollo? ¨  Mejorar el proceso.

n  Reducción de costes. n  Reducción del tiempo de desarrollo. n  Reducción de riesgos.

¨  Mejora de la calidad del producto. ¨  Protección del cliente. ¨  Protección de la organización Aumenta su

competitividad. 26 Ingeniería del Software - 2011/2012

¿Qué es el proceso software?

n  Proceso software es el conjunto de actividades y resultados asociados para producir un producto software: ¨  Especificación software

n  Definir la funcionalidad del software y las restricciones en sus operaciones. ¨  Desarrollo software

n  Se debe producir un software que cumpla su especificación. ¨  Validación software

n  Se debe validar el software para asegurar que haga lo que el cliente desea. ¨  Evolución software

n  El software debe evolucionar para cumplir los cambios en las necesidades del usuario.


2 minutos 5 minutos

¿Qué es un modelo de proceso software?

n  Representación abstracta de un proceso del software.

n  Todos los modelos de proceso del SW se ajustan a las actividades genéricas de especificación, desarrollo, validación y evolución del software pero cada uno aplica una importancia diferente a estas actividades y define un flujo de trabajo que invoca a cada actividad de una manera diferente.

n  Estos modelos ayudan al control y a la coordinación del proyecto.

n  El modelo a utilizar depende del tipo de proyecto.


¿Qué es un modelo de proceso software?

n Tipos de modelos de procesos de SW o Ciclo de vida:

¨ Modelos en Cascada. ¨ Modelo de Prototipos. ¨ Modelo en Espiral. ¨ Otros…


Modelo en Cascada

n  También llamado ciclo de vida básico o modelo lineal-secuencial. n  Divide el proceso de desarrollo en un conjunto de etapas secuenciales. n  Al final de cada fase, el personal de desarrollo y los usuarios revisan el progreso del

proyecto. n  Es el modelo más antiguo y más utilizado. n  Ha sido la base de muchos otros modelos.


Modelo en Cascada

n  Desventajas: ¨  Definir todos los requisitos al inicio del

proceso no es práctico ya que el cliente añade y modifica según le van surgiendo necesidades durante el proceso de desarrollo.

¨  ¡El cliente nunca tiene claro lo que quiere!

¨  El cliente no ve el producto en funcionamiento hasta el final del proceso.

¨  La validación de los requisitos iniciales no se hace hasta el final.

¨  Poca o nula flexibilidad a cambios.


n  Ventajas (¿Cuándo es conveniente usarlo?): ¨  Cuando tenemos proyectos complejos

pero que se entienden y quedan bien definidos desde un comienzo.

¨  Cuando el equipo de desarrollo no está muy cualificado o es aún inexperto porque la estructura de trabajo que propone es muy ordenada y ayuda a minimizar esfuerzo.

¨  Cuando realizamos una migración de software desde un entorno tecnológico obsoleto.

Modelo de Prototipos n  Un prototipo es una versión limitada del producto que permite a las

partes responsables de su creación probarlo en situaciones reales y explorar su uso

n  Con este modelo hay un acercamiento al cliente. Gracias al prototipo, el cliente puede hacerse una idea de cómo está evolucionando el producto y esto ayuda a refinar los requisitos del sistema

n  Con los prototipos definimos de forma clara y concreta qué quiere el cliente à los requisitos del sistema


Modelo de Prototipos


Diseño Técnico

Programación y Prueba

Operación y Mantención

Análisis y

Especificación

Diseño y

Construcción

Evaluación

Modificación

Definición del problema, efectos organizacionales. Estudio de factibilidad. Recolección y refinamiento de requisitos

Diseño detallado. Rediseño del Prototipo y documentación para programación y mantenimiento

Las especificaciones del diseño técnico son implementadas y probadas

Instalación del sistema y modificaciones posteriores

Esp

ecifi

caci

ón d

e re

quis

itos

y P

roto

tipad

o

Investigación Preliminar Diseño básico del Prototipo

Construcción prototipo

Verificación y requerimientos

Modificación del Prototipo

PRODUCTO DE

INGENIERÍA

Modelo de Prototipos

n  Desventajas: ¨  El diseño rápido del prototipo hace que

los desarrolladores utilicen herramientas que faciliten la rápida generación de código, dejando a un lado aspectos de calidad (eficiencia, fiabilidad, mantenibilidad del código, etc.).

¨  Probablemente no se tendrá un código óptimo.

¨  Exige disponer de las herramientas adecuadas.


n  Ventajas (¿Cuándo es conveniente usarlo?): ¨  Se recomienda para clientes que

quieren ver resultados a corto plazo

¨  Cuando el cliente no sabe lo que quiere y los requisitos no están bien definidos desde el principio

¨  Cuando los requisitos evolucionan muy rápidamente.

¨  Para sistemas on-line donde es más importante la parte de la que las funcionalidades del sistema.

¨  Se recomienda utilizar este modelo sólo para la especificación de requisitos. Mejor continuar el desarrollo utilizando otro modelo.

Modelo en Espiral n  Es una combinación de los dos anteriores (Boehm’88) n  Es un modelo evolutivo del desarrollo, formado por un conjunto de vueltas

de espiral ¨  En las primeras vueltas el SW es un modelo en papel, la especificación de un

producto. Aún no funciona. ¨  En las sucesivas vueltas, se desarrolla un prototipo. ¨  En la últimas iteraciones se obtienen versiones completas del producto.

n  Cada ciclo del espiral representa una fase del proyecto software n  4 sectores por ciclo:

¨  Definición de Objetivos ¨  Evaluación y reducción de riesgos ¨  Desarrollo y Validación ¨  Planificación


Modelo en Espiral


PLANIFICACIÓN Determine objetivos

alternativas y restricciones

ANÁLISIS DE RIESGOS Evalúe alternativas,

identifique y resuelva riesgos

Análisis de Riesgos



Análisis de

Riesgos

EVALUACIÓN DEL CLIENTE Planea la

siguiente fase

INGENIERÍA Desarrolla y verifica

el siguiente nivel del producto

Prototipo Operacional Prototipo

3 Prototipo 2 Proto

tipo 1

Plan de requerimientos Plan del ciclo de vida

REVISIÓN

Plan de Desarrollo

Plan de Integración y Prueba

Concepto de Operación

Simulaciones y modelos

Requeri- mientos de

SW Validación de Requerimientos

Diseño V &V

Servicio

Prueba de Aceptación

Prueba de Integración

Prueba de Unidades

Codificación

Diseño Detallado

Diseño del Producto

Modelo en Espiral

n  Desventajas: ¨  Es difícil establecer los hitos para

determinar si podemos pasar a la siguiente vuelta de espiral.

¨  La evaluación de riesgos es una tarea compleja à Se necesitan expertos en evaluación de riesgos.

¨  Es difícil convencer a los clientes que un modelo evolutivo es controlable.

¨  No se aconseja para proyectos que tienen pocos riesgos. Demasiado coste.

¨  En definitiva, no es un modelo muy real ni claro.


n  Ventajas (¿Cuándo es conveniente usarlo?): ¨  Cuando tenemos proyectos complejos,

donde el problema no está muy bien definido y conlleva una serie de riesgos.

¨  Proyectos dinámicos.

¨  Proyectos innovadores y ambiciosos.

Otros modelos de desarrollo n  Métodos formales (síntesis automática del Software) n  Desarrollo orientado a la reutilización (basado en componentes) n  DRA (Desarrollo Rápido de Aplicaciones) n  Espiral WINWIN n  Desarrollo concurrente n  Técnicas de 4ª generación n  Modelos para Desarrollo OO:

¨  Modelo de Agrupamiento ¨  Modelo fuente ¨  Modelo remolino ¨  Modelo Pinball, etc.


¿Qué es CASE?

n CASE - Computer-Aided Software Engineering: Programas de diferentes tipos que se utilizan para ayudar a las actividades del proceso. ¨  Editores gráficos ¨  Generadores de código ¨  Generadores de casos de prueba...


La complejidad del Software



n ¿Por qué es complejo el Software? ¨ Brooks: “La complejidad del software es una

propiedad esencial y no accidental”. n Tres motivos:

¨ La complejidad del dominio del problema. ¨ La dificultad de controlar el proceso de

desarrollo. ¨ Los problemas para caracterizar sistemas

discretos.







discretos.


La complejidad del dominio del problema

n  Los problemas del mundo real son complejos (miles de requisitos compitiendo y quizás contradictorios).

n  Se añaden requerimientos no funcionales: eficiencia, coste, fiabilidad, robustez...

n  Diferente perspectiva del mismo problema entre los usuarios y los desarrolladores.

¡Los requisitos cambian durante el desarrollo! 44 Ingeniería del Software - 2011/2012

La complejidad del dominio del problema

n Ejemplo: ¿Podéis resumir qué pasos hay que dar para solicitar el acceso a la UNIVERSIDAD?

n Ejemplo: ¿Podéis resumir qué pasos hay que dar para solicitar una hipoteca bancaria?







discretos.


La complejidad de controlar el proceso de desarrollo


La complejidad de controlar el proceso de desarrollo

n  Surgen incidencias. ¨ Algunas previstas y otras no.

n  Miles de líneas de código. ¨  Intentar la reutilización.

n  Surgen diferentes versiones del producto.

n  Disminuir la complejidad mediante el “divide y vencerás”. ¨ División en módulos. ¨ Aún así, la creación de muchos módulos puede ser

inmanejable 48 Ingeniería del Software - 2011/2012






discretos.


Los problemas para caracterizar sistemas discretos

n  El software trabaja con sistemas de estados discretos. ¨ Variables. ¨ Flujos de control. ESTADO DEL SISTEMA ¨ Eventos externos.

n  Cada evento externo puede cambiar el estado del sistema, pero ¿Se trata de un estado válido?.

n  Necesidad de pruebas ¨ Complejo, costoso y en ocasiones imposible que

sean exhaustivas. 50 Ingeniería del Software - 2011/2012


n  Ejemplo: Identificar estados (situaciones diferentes) en un reloj digital

n  Ejercicio Un reloj digital tiene una pantalla y dos botones para accionarlo, el botón A y el botón B. El reloj tiene dos modos de operación, visualizar la hora y establecerla. En el modo de visualización aparecen las horas y los minutos separados por dos puntos (:) intermitentes. El modo de establecer la hora tiene dos submodos: poner las horas y poner los minutos. El botón A se utiliza para seleccionar el modo de operación. Cada vez que se aprieta, el modo avanza en secuencia: visualizar la hora, poner hora, poner minutos, visualizar la hora, etc. Dentro de los submodos, el botón B se utiliza para avanzar una hora o un minuto cada vez que se aprieta. Prepare un diagrama de estados del reloj.



n Solución

52

Visualizar Hora Pon Hora Pon

Minutos

A

A A

B / Avanza Hora B / Avanza Minuto


1.Entregar el producto al cliente cuanto antes

n Se debe dedicar esfuerzo en la captura de las necesidades del cliente. Captura de Requisitos.

n  Involucrar al cliente en el proceso de desarrollo. Prototipos.

n Respetar los plazos acordados con el cliente. Quedará satisfecho.


2. Determinar el problema antes de escribir especificaciones

n Elegir la solución que mejor se adapte a las necesidades del cliente.

n Analizar todas las posibles soluciones. Costes, esfuerzo etc.

n No dar soluciones precipitadas. Explorar todas las alternativas.


3. Minimizar la distancia intelectual

n Distancia intelectual (Edsger Dijkstra): “distancia entre el problema del mundo real y la solución computarizada del problema”.

n Cuanto menor sea la distancia intelectual, más mantenible será el software.

n  La estructura del SW debería ser cercana a la estructura del mundo real.


4. Evaluar las alternativas de diseño

n Una vez establecidos los requisitos, ¿Qué arquitecturas o algoritmos elegir?

n Según por el diseño que optemos tendremos: ¨ Unos tiempos de respuesta u otros. ¨ Más portabilidad. ¨ Mayor seguridad.


5. La técnica es más importante que las herramientas

n Un ingeniero software indisciplinado con una potente herramienta se puede convertir en un ingeniero peligroso.

n Antes de seguir una herramienta, se debe comprender y seguir una técnica apropiada.

+ = PELIGRO


6. Hazlo bien antes de hacerlo rápido

n Es más fácil hacer que un programa que funciona bien sea más rápido, que hacer que un programa rápido que funciona mal funcione bien.

n No preocuparse en optimizar en la fase inicial.


7. Inspeccionar el código

n  La inspección de código es mejor que la ejecución.

n  La inspección de código: ¨  Permite descubrir el 82% de los errores. ¨  Consume cerca del 15% de los recursos

disponibles para el desarrollo. ¨  Reduce los costes de desarrollo entre un 25% y

un 30%. ¨ Reduce el tiempo de pruebas entre un 50% y un

90%. 60 Ingeniería del Software - 2011/2012

8. El personal es la clave del éxito n  Con personal cualificado con herramientas

insuficientes se puede llegar al éxito. n  Con personal NO cualificado con las más potentes

herramientas, NO llegamos al éxito. n  Es importante trabajar en equipo. n  Todo el personal debe conocer los estándares de

trabajo. n  Alguien debe controlar la aplicación de estos

estándares. n  Deberá haber una persona

encargada de mantenerlos, adaptarlos y ampliarlos.

n  El equipo debe recibir cursos de formación. 61 Ingeniería del Software - 2011/2012

9. Un diseño sin documentación, NO es un diseño

n  Los ingenieros de SW no competentes suelen decir: “Ya he terminado el diseño, sólo falta la documentación”.

n  ¿Os imagináis a un arquitecto que diga: “el diseño de la nueva casa ya está listo, sólo faltan los planos”?

¿ ?

n  Se debe ir documentando durante todo el proceso de desarrollo.


Otros principios de la Ingeniería del SW

n  10. El código difícil de leer es difícil de mantener. n  11. La encapsulación crea SW fácil de probar y

mantener. “Divide y vencerás”. n  12. No probar tu propio SW. Los desarrolladores

no deben probar el SW que han generado. n  13. La entropía de los sistemas aumenta. Cuanto

más se modifica y crece un sistema SW, más complejo y desorganizado se vuelve.


Algunos aspectos sobre calidad del SW

n Corrección: capacidad del SW de realizar con exactitud sus tareas, tal y como se definen en las especificaciones.

n Robustez: capacidad del SW de reaccionar apropiadamente ante condiciones excepcionales.

n Mantenibilidad: capacidad de modificar el SW para corregir defectos, mejorar el rendimiento, o para adaptarlo a un cambio de especificación.



n Reutilización: capacidad de los elementos del SW de servir para la construcción de otras aplicaciones.

n Compatibilidad: facilidad de combinar los elementos del SW con otros.

n Eficiencia: capacidad del SW de optimizar el consumo de los recursos de hardware.

n Portabilidad: facilidad de transferir el SW a diferentes entornos de HW y SW .



n Facilidad de Uso: facilidad con la cual personas con diferentes formaciones y aptitudes pueden usar el SW.

n Funcionalidad: conjunto de posibilidades que proporciona el SW.

n Economía: que los beneficios del SW sean mayores a la inversión en la adquisición o el desarrollo.

n … 67 Ingeniería del Software - 2011/2012

¿Qué es el Ciclo de Vida del SW?

69

n  Es una sucesión de etapas por las que pasa el software en su desarrollo, desde que se concibe la idea hasta que el software deja de utilizarse.

n  Cada etapa lleva asociada una serie de actividades y tareas que se deben realizar, y una serie de documentos que serán la salida de cada una de estas fases y que servirán de entrada a la fase siguiente.


¿Qué es el Ciclo de Vida del SW?

70

n  Según la norma ISO/IEC Standard 12207:2008: Software life-Cycle processes propuesta por la ISO (International Organization for Standardization):

“Es un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, explotación y mantenimiento de un producto software, abarcando la vida del sistema desde la definición de requisitos hasta que se deja de utilizar”

http://www.iso.org/iso/home.htm


Ciclo de vida y ciclo de desarrollo n Ciclo de vida del software

¨ Adquisición, suministro, desarrollo, explotación y mantenimiento del SW (IEEE 1074). Concepción Retirada

n Ciclo de desarrollo ¨ Análisis, diseño, implementación y pruebas.

Requisitos Entrega


¿Qué es una metodología? n  Es un conjunto de métodos, técnicas, herramientas y un

soporte documental que ayuda a desarrollar software.

n  Una metodología establece un camino para desarrollar software de manera sistemática, proporcionando un estándar de trabajo a la organización.

n  Especifica: ¨  Cómo se debe dividir un proyecto en etapas ¨  Qué tareas hay que realizar en cada etapa ¨  Qué salidas se producen y cuándo ¨  Qué restricciones se aplican ¨  Qué herramientas se utilizan ¨  Cómo se gestiona y controla un proyecto ¨  Definición de responsabilidades ¨  Control de calidad


Metodologías de desarrollo

n  Necesidades a cubrir con las metodologías: ¨ Mejorar aplicaciones ¨ Mejorar proceso de desarrollo ¨ Proceso estándar en la organización

n  Objetivos: ¨ Definir requisitos de forma acertada ¨ Contar con un método sistemático de desarrollo ¨ Construir sistemas en tiempo y coste razonable ¨ Construir sistemas documentados y fáciles de

mantener ¨ Ayudar identificación cambios ¨ Proporcionar sistemas que satisfagan al cliente



n Diferencias conceptuales

¨ Metodología (CÓMO) puede seguir uno o varios modelos de ciclo de vida (QUÉ).

¨ Metodología es un conjunto de métodos. Los métodos a veces se centran en una fase del ciclo de vida.


Metodologías de desarrollo n Evolución histórica de las metodologías de

desarrollo: ¨ Desarrollo convencional (años ‘50) ¨ Desarrollo estructurado (finales ‘60 mediados ‘70) n  SSADM(1981), Metrica v3(2001)

¨ Desarrollo orientado a objetos (años ‘80 y ‘90) n  Proceso Unificado (1999)

¨ Métodos Ágiles (siglo XXI) n  eXtreme Programming (1996), Scrum (2001), etc.


Metodologías de desarrollo n  1. Desarrollo convencional

¨ Antes no existían metodologías (años ‘50) ¨ No se realizaba análisis, sólo programación ¨ Problemática

n Resultados impredecibles n Falta de control sobre el proceso de

desarrollo n Documentación no estándar n Integración nuevo personal desfasadas en

el proceso


n  2. Desarrollo estructurado (años ‘70) ¨ Se establecen métodos de ingeniería ¨ Centrado en las funciones ¨ Programación estructurada ¨ Diseño estructurado: concepto de módulos ¨ Análisis estructurado: especificaciones

funcionales gráficas ¨ Análisis TOP-DOWN



n  3. Desarrollo orientado al objeto ¨ Tiene sus orígenes en la aparición de

lenguajes de programación OO (años ‘80 y ‘90)

¨ Centrado en los objetos del dominio del problema y sus relaciones

¨ Procesos y datos como conjunto ¨ Programación orientada a objeto ¨ Diseño orientado a objeto ¨ Análisis orientado a objeto



n  Metodologías tradicionales (no ágiles) Guiadas por una fuerte planificación durante todo el proceso de desarrollo; donde se realiza una intensa etapa de análisis y diseño antes de la construcción del sistema.

n  Metodologías ágiles Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último momento).

n  Algunas metodologías ágiles: ¨  Extreme Programming. ¨  Scrum. ¨  Familia de Metodologías Crystal. ¨  Feature Driven Development. ¨  Proceso Unificado Rational, una configuración ágil. ¨  Dynamic Systems Development Method. ¨  Adaptive Software Development. ¨  Open Source Software Development.



TEMA 1: INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE

Profesor: David Granada

TEMA 1: INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE · Ingeniería del Software - 2011/2012 4 !...

Documents

Transcript of TEMA 1: INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE · Ingeniería del Software - 2011/2012 4 !...