Ingenieria de Software

TEMA 1
INTRODUCCIÓN A LA
INGENIERÍA DEL SOFTWARE
Dr. José Ignacio Peláez Sánchez

E.T.S.I. Informática de Sistemas. 3er Curso. Año 2004/2005
Visión General
Importancia de la Ingeniería del Software.
z Retraso en la llegada de la Ingeniería del Software

9 23 de febrero de 1984 la revista “Bussiness week software: the
new driving force”.
z Software un factor que marca diferencias.
z Tareas de la Ingeniería del Software.

9 Análisis, Especificación, Planificación, Diseño, Codificación,
Prueba y Mantenimiento.
José Ignacio Peláez Sánchez

Universidad de Málaga 2 de 87
Departamento de Lenguajes y Ciencias de la Computación
Sistemas Basados en Computadora
Definición de sistema. Conjunto de elementos
relacionados entre sí, de manera que todos juntos forman
un todo.
Definición de Sistema Basado en Computadora

(SBC). Conjunto de elementos organizados para llevar a
cabo algún método, procedimiento o control, mediante el
procesamiento de la información.
Elementos de los SBC.

z Software, Hardware, Bases de Datos, Documentación, Gente,
Procedimientos.

Concepto de Software
Definición de Software. Conjunto de instrucciones que
cuando se ejecutan suministan la función y
comportamiento adecuados, un conjunto de estructuras
de datos que facilitan la manipulación adecuada de la
información, y finalmente, los documentos que describen
la operación y uso de los programas.

Evolución del Software
Decada de los 50.
z Orientación por lotes; Distribución limitada; Software a medida.
Desde 1960 hasta mediado de los años 70.

z Multiusuario; Tiempo real; Bases de datos; Producción software.
Desde mitad de los años 70 hasta mitad de los 80.

z Sistemas distribuidos; Inteligencia empotrada; Hardware de bajo
coste; Impacto en el consumidor.
Desde mitad de los años 80 hasta nuestros días.

z Sistemas expertos; Máquinas de I.A; Arquitecturas paralelas.

Evolución y las Mismas Preguntas
Preguntas de las programadores, ya sean programadores
solitarios o grupos de programadores.
z ¿Por qué lleva tanto tiempo terminar los programas?
z ¿Por qué son tan elevados los costes de desarrollo?
z ¿Por qué no podemos encontrar todos los errores antes de
entregar el software a nuestros clientes?
z ¿Por qué nos resulta tan difícil constatar el progreso conforme se
desarrolla el software?.

Caracteristicas del Software
El software es desarrollado y no fabricado en sentido
clásico.
El software no se deteriora en sentido hardware.
No existen piezas de repuesto.
Cada fallo indica un error de diseño o de traducción a
código.
El software se construye a medida y no ensamblando
componentes.

clásico.
código.
componentes.

INCREMENTO DEL
ÍNDICE DE FALLOS
MORTALIDAD INFANTIL POR EFECTOS
LATERALES
CAMBIO
SE ESTROPEA
ÍNDICE DE FALLOS
ÍNDICE DE FALLOS
CURVA REAL
CURVA IDEALIZADA
TIEMPO
TIEMPO
CURVA DE FALLOS HARDWARE CURVAS DE FALLOS REAL E IDEALIZADA DEL SOFTWARE

clásico.
código.
componentes.

Aplicaciones del Software
Sistemas de tiempo real.
Sistemas.
Gestión.
Ingeniería y científico.
Empotrado.
Inteligencia artificial.
Computadores personales.
Basado en Web.

Crisis del Software
La crisis del software es una serie de problemas que
hacen que el software no alcance las expectativas u
objetivos esperados por desarrolladores, gestores,
clientes, etc.
Problemas fundamentales.
z La sofisticación del hardware no esta acompañada de la del
software.
z Demanda creciente.
z Mantenimiento difícil.

Crisis del Software
SOLUCIÓN

Crisis del Software
Problemas de los expertos.
z Planificación y precios imprecisos.
z La productividad de la gente del software no se corresponde con
la demanda.
z La calidad muchas veces no es la adecuada.
Motivos de estos problemas

z No hay tiempo para recoger los datos para el proceso de
desarrollo.
z Falta comunicación con el cliente.
z Calidad cuestionable.
z Dificultad en el mantenimiento.

Crisis del Software
SOLUCIÓN

Mitos del Software
Los mitos del software son frases

hechas que propagan información
errónea y confusa, en lugar de
sabiduría y buen hacer

Mitos de Gestión
Los gestores con responsabilidad en el software, como los
gestores en la mayoría de las disciplinas, están
normalmente bajo la presión de cumplir los presupuestos,
hacer que no se retrase el proyecto y mejorar la calidad.
Un gestor de software se agarra frecuentemente a un

mito del software, aunque tal creeencia sólo disminuya la
presión temporal.

Mitos de Gestión
¿Por qué debemos cambiar nuestra forma de desarrollar
software, si estamos haciendo el mismo tipo de
programación que hace 10 años?
¡Tenemos un libro que esta lleno de estándares y
procedimientos para construir software!
¡Nuestra gente tiene las mejores máquinas para el
desarrollo!
Si fallamos en la planificación, añadimos más
programadores y adelantamos el tiempo perdido. (Horda
Mongoliana).

Mitos del Cliente
Un cliente que solicita un 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
desarrollo del software.

Mitos del Cliente
Una declaración general de los objetivos es suficiente para
comenzar a escribir los programas. Podemos dar los
detalles más adelante.
Los requerimientos cambian continuamente, pero los

cambios pueden acomodarse fácilmente ya que el
software es flexible.
¿Cómo afecta un cambio en las diferentes fases del

desarrollo del software?

Mitos del Cliente
Impacto del Cambio.
60 – 100X
IMPACTO DEL CAMBIO
1,5-6X
1X
DEFINICIÓN DESARROLLO DESPUÉS DE LA ENTREGA

Mitos de los Realizadores
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.

Mitos de los Realizadores
No hay métodos para el análisis, diseño y prueba que
funcionen bien, simplemente me voy al terminal y
comienzo a codificar.
Una vez que hacemos que el programa funcione, nuestro
trabajo ha terminado.
Hasta que no esté el programa terminado no puedo
establecer su calidad.
Lo único que se entrega al terminar el proyecto es el
programa funcionando.
Una vez que el software se está usando, el mantenimiento
es mínimo y puede manejarse sobre la base de hacerlo
como se pueda.

Reflexión sobre los Mitos
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 una mala aplicación de las 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.

Ingeniería del Software
Definición de Ingeniería del Software (IS). La IS es
una disciplina o área de la Informática o Ciencias de la
Computación, que ofrece métodos y técnicas para
desarrollar, mantener y documentar software de calidad
qué, resuelve problemas de todo tipo, se ejecuta en
máquinas reales y satisface las necesidades del cliente.
La IS integra: Métodos, herramientas y procesos para el

desarrollo del software bajo un enfoque de calidad.

Métodos
Los métodos indican cómo construir técnicamente el
software.
Tareas que componen los métodos.

z Planificación; Estimación de proyectos.
z Análisis de requerimientos del software y hardware.
z Diseño de estructuras de datos, Arquitectura de los programas.
z Procedimientos algorítmicos.
z Codificación; Prueba; y Mantenimiento.

Herramientas y Procesos
Las herramietas son un soporte automático o semiautomático para
el proceso y los métodos.
z Microsoft Project (Planificación).
z UML (Modelado).
z RationalRose, visio (Modelado soportan UML).
z Designer 2000.
z Erwin (Bases de datos).
z MAGERIT (Seguridad).
Los procesos son los encargados de integrar los métodos y
herramientas, además de definir la secuencia en la que se aplican los
métodos, las entregas que requieren, los controles de calidad y las
guías para el desarrollo.

Fases Genéricas de la IS
Definición. Tareas que la componen:
z Análisis del sistema.
z Planificación del Proyecto.
z Análisis de requisitos.
QUÉ
Desarrollo. Tareas que la componen:
z Diseño del software.
z Codificación.
z Prueba del Software. CÓMO
Mantenimiento. Tipos de cambios:
z Corrección.
z Adaptación.
z Mejora.
z Prevención o Reingeniería.
TIPO

Preguntas que debe Responder la IS
¿cuál es el problema a resolver?
¿Cuáles son las características de la entidad (solución)
que se utiliza para resolver el problema?
¿Cómo se realizará 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 solución?
¿Cómo se apoyará la solución cuando usuarios soliciten
correcciones, adaptaciones y mejoras de la entidad?.

Proceso del Software
El proceso del software es un marco común para el
proceso que define un pequeño número de actividades del
marco de trabajo que son aplicables a todos los proyectos
con independencia de su tamaño o complejidad.

Proceso del Software
El proceso del software es un marco común para el
proceso que define un pequeño número de actividades del
marco de trabajo que son aplicables a todos los proyectos
con independencia de su tamaño o complejidad.
Marco de trabajo común
Actividades del marco de trabajo
Conjunto de trabajo
Tareas
Hitos, entregas
SQA=Puntos de garantía de calidad
Seguridad

Paradigma de la IS
El modelo de proceso o paradigma de la IS es la
estrategía que comprenden métodos, herramientas y
procesos.
El ingeniero debe seleccionar un modelo de proceso para
ingeniería del software según la naturaleza del proyecto y
de la aplicación, los métodos, las herramientas a utilizar, y
los controles y entregas que se requieren.
Los diferentes paradigmas lo que intentan es ordenar las
actividades en el desarrollo del software, de manera que
no sean llevadas a cabo de manera caótica.

Paradigmas de la IS
Paradigmas.
z Ciclo de vida clásico – Modelo lineal secuencial – Modelo en
cascada.
z Prototipos.
z Modelo DRA (RAD. Rapid Application Development).
z Modelos Evolutivos de Proceso
9 Incremental.
9 Espiral.
9 Espiral WINWIN.
9 Modelo de desarrollo concurrente.
z Modelo basado en componentes.
z Modelo basado en métodos formales.
z Técnicas de cuarta generación.
z Modelos agiles. Programación extrema.
Visión Generalizada de los Paradigmas
Definición
Desarrollo
Mantenimiento

Paradigmas de la IS
Paradigmas.
z Ciclo de vida clásico – Modelo lineal secuencial – Modelo
en cascada.
z Prototipos.
9 Incremental.
9 Espiral.
9 Espiral WINWIN.
Modelo Lineal Secuencial
Enfoque sistemático y secuencial
Ingeniería de Análisis Diseño

Sistemas
Codificación Prueba Mantenimiento

Modelo Lineal Secuencial
Ingeniería de sistemas. Se establecen los requerimientos
de los elementos del sistema y se realiza la asignación.
Análisis de requerimientos. Se establece y documenta el
dominio del software. Se revisa con el cliente.
Diseño. Se traducen los requerimientos en estructuras.
Codificación.
Prueba.
Mantenimiento.

Problemas del Modelo Sec. Lineal
Raramente los proyectos siguen este ciclo de vida.
El cliente pocas veces establece todos los requerimientos

al principio.
El cliente no tiene un producto hasta el final.

Paradigmas de la IS
Paradigmas.
cascada.
z Prototipos.
9 Incremental.
9 Espiral.
9 Espiral WINWIN.
Ciclo de Vida del Prototipado
Recolección de Diseño Rápido Construcción del Prototipo

Requerimientos
Evaluar y Refinar
Producto Construido
los Requerimientos

Modelo de Construcción de Prototipos
¿Por qué se usa este Modelo?
z El cliente no puede especificar todos los requerimientos al

principio.
z Existen dudas de alguna parte del sistema.
z Facilita un modelo al programador.

Tipos de Prototipos
Totales.
Parciales.
z Interfaces.
z Modelos.
z Estructuras de datos.

Problemas del Prototipado
El cliente lo quiere, aunque no es un producto

software
Módulos ineficientes se convierten en partes del

sistema.

Paradigmas de la IS
Paradigmas.
cascada.
z Prototipos.
9 Incremental.
9 Espiral.
9 Espiral WINWIN.
Modelo DRA
El Modelo DRA consiste en un desarrollo rápido de
aplicaciones basado en el modelo lineal secuencial, pero
donde se enfatiza un ciclo de desarrollo extremadamente
corto.
Es una adaptación a alta velocidad del modelo lineal
secuencial, donde se puede aumentar la velocidad
haciendo uso de componentes.
Si se comprenden bien los requisitos y se limita el ámbito
del proyecto, el proceso DRA permite al equipo de
desarrollo crear un sistema completamente funcional,
dentro de periodos cortos de tiempo.

Modelo DRA
EQUIPO Nº 1
EQUIPO Nº 2 EQUIPO Nº 3
MODELADO DE MODELADO DE
MODELADO DE
GESTIÓN GESTIÓN
GESTIÓN
MODELADO DE
MODELADO DE MODELADO DE DATOS
DATOS DATOS
MODELADO DE
MODELADO DE PROCESOS
MODELADO DE PROCESOS
PROCESOS
GENERACIÓN DE
GENERACIÓN DE APLICACIONES
APLICACIONES
GENERACIÓN DE
PRUEBAS Y
APLICACIONES ENTREGA
PRUEBAS Y
ENTREGA
PRUEBAS Y
ENTREGA

Problemas del Modelo DRA
Para proyectos grandes necesitamos de recursos
suficientes para formar los equipos necesarios.
Compromiso de colaboración entre desarrolladores y
clientes.
No todas las aplicaciones son susceptibles de aplicar este
modelo.
Cuando los riesgos técnicos son altos DRA no es
apropiado.
Cuando el grado de interoperatividad con programas ya
existentes es alto, no es apropiado.

Paradigmas de la IS
Paradigmas.
cascada.
z Prototipos.
9 Incremental.
9 Espiral.
9 Espiral WINWIN.
Modelos Anteriores
Modelo Lineal Secuencia. Diseñado para entregar un
producto al final.
Modelo de Construcción de Prototipos. Diseñado para que
los clientes interactúen con los desarrolladores.
Ninguno de los modelos anteriores se tiene en cuenta la
naturaleza evolutiva del software.
“Las empresas son entes vivos que van

evolucionando con el tiempo”

Modelos Evolutivos
Los modelos evolutivos se caracterizan porque permiten a
los ingenieros del software, desarrollar de manera
iterativa, nuevas versiones del software cada vez más
completas.
Los modelos que componen este tipo son:
z Modelo Incremental.
z Modelo en Espiral.
z Modelo en Espiral Victoria-Victoria (WINWIN).
z Modelo de Desarrollo Concurrente.

Paradigmas de la IS
Paradigmas.
cascada.
z Prototipos.
9 Incremental.
9 Espiral.
9 Espiral WINWIN.
z Modelos ágiles. Programación extrema.
Modelo Incremental
El modelo Incremental combina elementos del modelo lineal
secuencial (aplicados repetidamente) con la filosofía interactiva de
construcción de prototipos.
INGENIERÍA DE
SISTEMAS
ENTREGA 1ER
ANÁLISIS DISEÑO CÓDIGO PRUEBA INCREMENTO
INGENIERÍA DE
SISTEMAS
ENTREGA 2ER
INGENIERÍA DE
SISTEMAS
ENTREGA 3ER

Paradigmas de la IS
Paradigmas.
cascada.
z Prototipos.
9 Incremental.
9 Espiral.
9 Espiral WINWIN.
Modelo en Espiral
El Modelo en Espiral, propuesto originalmente por Boehm, es un
modelo de proceso de software evolutivo que conjuga la naturaleza
iterativa de construcción de prototipos con los aspectos controlados y
sistemáticos del modelo lineal secuencial.
Ideal para realizar versiones incrementales de manera rápida.
El software se desarrolla en una serie de versiones incrementales.

Paradigmas de la IS
Paradigmas.
cascada.
z Prototipos.
9 Incremental.
9 Espiral.
9 Espiral WINWIN.
Modelo en Espiral Victoria-Victoria
El modelo en espiral visto anteriormente, dispone de una actividad de
comunicación con el cliente.
Comunicación Ideal. El desarrollador pregunta al cliente y el cliente
facilita suficiente información para continuar.
Comunicación Real. El cliente y el desarrollador entran en un proceso
de negociación, donde el cliente puede ser preguntado para sopesar
la funcionalidad, rendimiento, y otras características.
Las mejores negociaciones se esfuerzan en obtener <<victoria-
victoria>>.
Este modelo definido por Boehm, define un conjunto de actividades
de negociación al principio de cada paso alrededor de la espiral.

Modelo en Espiral Victoria-Victoria

Paradigmas de la IS
Paradigmas.
cascada.
z Prototipos.
9 Incremental.
9 Espiral.
9 Espiral WINWIN.
z Modelos ágiles. Programación extrema.
Modelo de Desarrollo Concurrente
El Modelo de Desarrollo Concurrente dado por Davis y Sitaram, se
puede representar en forma de esquema como una serie de
actividades técnicas importantes, tareas y estados asociados a ellas.
El modelo Concurrente define una serie de acontecimientos que
dispararán transiciones de estado a estado para cada una de las
actividades de la Ingeniería del software.
Este modelo se utiliza a menudo como el paradigma de desarrollo de
aplicaciones cliente/servidor.

Paradigmas de la IS
Paradigmas.
cascada.
z Prototipos.
9 Incremental.
9 Espiral.
9 Espiral WINWIN.
Modelo Basado en Componentes
La tecnología de objetos proporciona el marco de trabajo
técnico para un modelo de proceso basado en
componentes para la IS.
El paradigma orientado a objetos enfatiza en la creación
de clases que encapsulan tanto los datos como los
algoritmos que se utilizan para manejar los datos.
Si se diseñan e implementan las clases correctamente,
podrían ser reutilizables por las diferentes aplicaciones y
arquitecturas de sistemas basados en computadores.

El modelo de desarrollo basado en componentes incorpora
muchas de las características del modelo en espiral.
Es evolutivo por naturaleza y exige un enfoque iterativo
para la creación de software.
Configura aplicaciones desde componentes preparados de
software.
El modelo basado en componentes conduce a la
reutilización del software, proporcionando beneficios a los
ingenieros de software.

La reutilización según estudios:
z Reduce el ciclo de vida en un 70%.
z Reduce el coste del proyecto en un 84%.
z Aumenta la productividad.

Paradigmas de la IS
Paradigmas.
cascada.
z Prototipos.
9 Incremental.
9 Espiral.
9 Espiral WINWIN.
Modelo de Métodos Formales
El Modelo de Métodos Formales comprende un conjunto
de actividades que conducen a la especificación
matemática del software de computadora.
Los métodos formales permiten que un ingeniero de
software especifique, desarrolle y verifique un sistema
basado en computadora aplicando una notación rigurosa y
matemática.
Con este modelo se consigue software libre de errores.
Es difícil de aplicar, por diferentes motivos, pero para
software de alta seguridad es muy adecuado.
También se le conoce como Ingeniería del Software de
Sala Limpia.

Paradigmas de la IS
Paradigmas.
cascada.
z Prototipos.
9 Incremental.
9 Espiral.
9 Espiral WINWIN.
Técnicas de 4ª Generación
El término técnicas de cuarta generación abarca un amplio espectro
de herramientas de software que tienen algo en común: Todas
facilitan al ingeniero del software la especificación de algunas
características del software de alto nivel.
Las herramientas general el código automáticamente en base a las
especificaciones del ingeniero.
Herramientas de 4ª Generación.
z Lenguajes no procedurales para consultas de BD.
z Generación de Informes.
z Manipulación de Datos.
z Definición de pantallas y código.
z Gráficos.
z Hoja de cálculo.

Ciclo de Vida de las Técnicas de 4 Gen.
Recolección de Estrategias de Diseño

Requerimientos
Implementación Producto
usando L4G

Paradigmas de la IS
Paradigmas.
cascada.
z Prototipos.
9 Incremental.
9 Espiral.
9 Espiral WINWIN.
Modelos Ágiles/Programación Extrema
La idea de la Ingeniería de requisitos es conseguir un
cuadro totalmente entendido de los requisitos antes de
empezar a construir el software.
Conseguir la firma del cliente sobre los requisitos y
preparar los procedimientos para limitar los cambios
después de la firma.
El problema surge cuando se intenta añadir un nuevo
requisito porque la estimación del coste es difícil.
¿Por qué es difícil esta tarea? Porque la actividad de
desarrollo del software es una actividad de Diseño.

Procesos Adaptables o Ágiles
Si bien el desarrollo iterativo tiene sentido en los procesos
predictivos, también lo es en los procesos adaptables
porque este tipo de proceso necesita poder tratar con los
cambios.
Este estilo nos lleva a que los planes a largo plazo son
adaptables y los únicos planes adaptables son los que se
hacen a corto plazo.
En un proceso adaptable el cliente tiene mucho control
sobre el proceso de desarrollo, ya que en cada iteración
puede interactuar como alterar la dirección del mismo.
En este tipo de procesos se forma un verdadero equipo
entre los desarrolladores y los clientes.

Se consigue un producto que funciona pronto con los
beneficios que esto conlleva para el cliente, comprende el
sistema y puede introducir mejoras que lo hacen eficaz.
Un proyecto es bueno cuando se ajusta al plan. Sin
embargo un proyecto ágil tiene que obtener mejores
resultados que los que fueron establecidos inicialmente.
El problema de los modelos ágiles es que requieren de un
equipo eficaz de desarrollo, tanto a nivel individual como
de equipo.
En los proyectos tradicionales el personal puede ser
reemplazado, sin embargo en los modelos ágiles esto
varia, los desarrolladores pueden tomar todas las
decisiones.
Los equipos ágiles tienen una gran comunicación tanto los
desarrolladores como los expertos del negocio (cambios
continuos en la tecnología).
La Programación Extrema (XP) comienza con cuatro
valores: Comunicación, Retroalimentación, Simplicidad y
Coraje.
La XP agrupas todas las técnicas y pone todo su énfasis
en realizar pruebas, donde cada programador escribe sus
pruebas conforme desarrolla software.
La XP es un desarrollo evolutivo donde en cada iteración
de consigue un producto final.

Proceso Unificado de Desarrollo del Software
El Proceso Unificado de Desarrollo del Software (PUDS) es

un proceso basado en componentes que ha sido
propuesto por la industria.
El proceso unificado dispone de un Lenguaje de Modelado
Unificado (UML), que es utilizado construir el sistema y las
interfaces que conectarán los componentes.
El PUDS combina un desarrollo incremental e iterativo,
definiendo la función del sistema aplicando un enfoque
basado en escenarios.

Proceso Unificado de Desarrollo del Software
El PUDS se puede decir que es un proceso:

z Dirigido por los casos de uso.
9 Basándose en el modelo de casos de uso y en su análisis los
desarrolladores crean los modelos de diseño e implementación que
llevan a cabo los casos de uso.
z Centrado en la arquitectura.
9 La arquitectura de un sistema software se describe mediante
diferentes vistas del sistema en construcción.
z Iterativo e Incremental.
9 El desarrollo de un proyecto se divide en iteraciones, encargadas de
pequeñas partes del trabajo y que dan como resultado un crecimiento
del producto, incremento. Estas iteraciones se planifican y se prueban
cada vez que terminan.

Proceso Unificado
ENTREGA 1
Prototipo
Exploratorio
ENTREGA 2
Línea Base de la
Arquitectura
ENTREGA 3
Versión Operativa
Inicial
ENTREGA 4
Entrega del
Producto

Métrica 3
La metodología Métrica 3 es un instrumento para la
sistematización de las actividades que dan soporte al ciclo
de vida del software.
Contempla el desarrollo de sistemas de información para
las distintas tecnologías que actualmente conviven.
En la elaboración de Métrica 3 se han tenido en cuenta los
métodos de desarrollo más extendidos, así como los
últimos estándares de ingeniería del software y calidad,
además de referencias especificas en cuanto a seguridad
y gestión de proyectos.

Métrica 3
Cubre el desarrollo estructurado y orientado a objetos.
Facilita los procesos de apoyo y de organización a través
de interfaces: Gestión de proyectos; Gestión de
configuración; Aseguramiento de calidad y seguridad.
La automatización de sus actividades es posible ya que
existe una amplia variedad de herramientas de ayuda al
desarrollo.
Existe una herramienta que adapta Métrica 3 a las
condiciones especificas de cada proyecto, permitiendo el
control y seguimiento desde diferentes perfiles.
Posee un curso de formación. www.map.es/csi

¿Por que una Metodología de Desarrollo?
La utilización de una metodología en el desarrollo de
sistemas permite:
z Disponer de un marco estratégico que permite conseguir los fines
de la organización.
z Dotar a la organización de productos software que satisfagan las

necesidades de los usuarios dando una mayor importancia al
análisis de requisitos.

Metodología de Desarrollo
z Mejorar la productividad de los departamentos de sistemas y
tecnologías de la información y las comunicaciones, permitiendo
una mayor capacidad de adaptación a los cambios y teniendo en
cuenta la reutilización en la medida de lo posible.
z Facilitar la comunicación y entendimiento entre los distintos

participantes en la producción de software a lo largo del ciclo de
vida del proyecto, teniendo en cuenta su papel y responsabilidad,
así como las necesidades de todos y cada uno de ellos.
z Facilitar la operación, mantenimiento y uso de los productos

software obtenidos.

Metodología DUM
DUM es una metodología evolutiva e incremental de desarrollo del
software que ha sido creada en el departamento de Lenguajes y
Ciencias de la Computación de la Universidad de Málaga. Basada en
un enfoque iterativo incremental esta metodología realiza una
especificación exhaustiva de todas las actividades y tareas que se
realizan en las diferentes fases, prestado especial atención por
alcanzar un nivel superior de madurez según el marco CMMI/Carnegie
Mellon.
Las fases en las que se subdivide la metodología DUM son las
siguientes: fase preliminar, fase de Inicio, fase de elaboración, fase
de construcción, fase de transición; y finalmente, una fase de
mantenimiento.

Metodología DUM
Fase Preliminar
z En la Fase Preliminar se llevan a cabo una serie de pasos previos en los

que se sientan las bases que permiten comenzar el proyecto. En esta fase
el cliente proporciona los dos elementos básicos para comenzar un
proyecto: una petición formal del mismo; y una definición del problema al
que debe dar respuesta el Sistema a desarrollar. En base a estos dos
elementos la organización de desarrollo definirá un primer equipo
encargado del inicio del proyecto.

Metodología DUM
Fase de Inicio
z En la Fase de Inicio se determina si el problema planteado tiene solución,
lo cual se hace desde un punto de vista genérico, es decir, no se tienen
en cuenta posibles restricciones relacionadas con el cliente como costes
económicos o plazos de entrega, sólo se tienen en cuenta restricciones
que afecten al problema en sí como pueda ser la legalidad vigente. Si al
final de la Fase de Inicio se determina que el problema tiene solución,
DUM denominará el Sistema a desarrollar un Sistema Realizable. En fases
posteriores se estudiará si el nuevo Sistema puede desarrollarse teniendo
en cuenta las restricciones impuestas por el cliente, esto es lo que DUM
denomina un Sistema Viable.

Metodología DUM
Fase de Elaboración
z En la Fase de Elaboración se determina si es posible desarrollar el
Sistema teniendo en cuenta las restricciones impuestas por el cliente, y se
obtiene un proyecto particular después de aplicarle las restricciones del
cliente al proyecto genérico.
z Puede considerarse que en las Fases de Inicio y Elaboración se realiza un
trabajo en base a objetivos similares pero tratados a distinto nivel. Así, en
la Fase de Inicio se trabaja con un proyecto basado en un problema
genérico y se comprueba que dicho proyecto genérico se puede llevar a
cabo, mientras que en la Fase de Elaboración se trabaja con una versión
particular del proyecto genérico y se comprueba que dicho proyecto
particular se puede llevar a cabo.

Metodología DUM
Fase de Construcción
z Terminada la Fase de Elaboración se cuenta con un especificación
detallada de qué debe hacer el Sistema, de una arquitectura formada por
los elementos del Sistema que guiará cómo cumplirá el Sistema con su
cometido, y de una versión inicial del Sistema en base a su arquitectura
que será la base sobre la que se construirá el resto del Sistema.
z En la Fase de Construcción se completarán las labores de desarrollos
pendientes para los casos de uso no incluidos en la arquitectura del
Sistema de modo que al final de la fase se cuente con una versión
completa del Sistema. Esta versión deberá satisfacer todos los requisitos
indicados por el cliente y los criterios de calidad y seguridad establecidos
por la organización de desarrollo, sin embargo, no será la versión
definitiva del Sistema, será la denominada versión beta del Sistema.

Metodología DUM
Fase de Transición
z Durante la Fase de Transición se realiza la prueba del Sistema con el fin
de adaptar el mismo a un entorno de producción realizándose las
modificaciones que se estimen necesarias. Los usuarios encargados de
probar el sistema (en adelante usuarios beta) recibirán instrucciones
acerca de aquellos aspectos del Sistema en los que deben hacer especial
hincapié y sobre el proceso a seguir para la proposición, estudio y
resolución de propuestas de modificación. A este respecto será necesario
desarrollar la estructura necesaria para facilitar en la medida de lo posible
dicho proceso.

Metodología DUM
Fase de Mantenimiento
z Tras la finalización del proyecto será necesario establecer un acuerdo
respecto al mantenimiento, que puede ser llevado a cabo por la misma
organización de desarrollo o por otra distinta.


Ingenieria de Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingenieria de Software

Cargado por

Copyright:

Formatos disponibles

TEMA 1

Dr. José Ignacio Peláez Sánchez

z Retraso en la llegada de la Ingeniería del Software

z Software un factor que marca diferencias.

z Tareas de la Ingeniería del Software.

José Ignacio Peláez Sánchez

 Definición de Sistema Basado en Computadora

 Elementos de los SBC.

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 Desde 1960 hasta mediado de los años 70.

 Desde mitad de los años 70 hasta mitad de los 80.

 Desde mitad de los años 80 hasta nuestros días.

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

CURVA DE FALLOS HARDWARE CURVAS DE FALLOS REAL E IDEALIZADA DEL SOFTWARE

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

INGENIERÍA DEL SOFTWARE

José Ignacio Peláez Sánchez

 Motivos de estos problemas

José Ignacio Peláez Sánchez

INGENIERÍA DEL SOFTWARE

José Ignacio Peláez Sánchez

Los mitos del software son frases

José Ignacio Peláez Sánchez

 Un gestor de software se agarra frecuentemente a un

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 Los requerimientos cambian continuamente, pero los

 ¿Cómo afecta un cambio en las diferentes fases del

José Ignacio Peláez Sánchez

IMPACTO DEL CAMBIO

DEFINICIÓN DESARROLLO DESPUÉS DE LA ENTREGA

José Ignacio Peláez Sánchez

 Durante los primeros días del desarrollo del software, la

 Las viejas formas y actitudes tardan en morir.

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 La IS integra: Métodos, herramientas y procesos para el

José Ignacio Peláez Sánchez

 Tareas que componen los métodos.

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

Actividades del marco de trabajo

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

Ingeniería de Análisis Diseño

Codificación Prueba Mantenimiento

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 El cliente pocas veces establece todos los requerimientos

 El cliente no tiene un producto hasta el final.

Definición de Sistema Basado en Computadora

Elementos de los SBC.

Desde 1960 hasta mediado de los años 70.

Desde mitad de los años 70 hasta mitad de los 80.

Desde mitad de los años 80 hasta nuestros días.

Motivos de estos problemas

Un gestor de software se agarra frecuentemente a un

Los requerimientos cambian continuamente, pero los

¿Cómo afecta un cambio en las diferentes fases del

Durante los primeros días del desarrollo del software, la

Las viejas formas y actitudes tardan en morir.

La IS integra: Métodos, herramientas y procesos para el

Tareas que componen los métodos.

El cliente pocas veces establece todos los requerimientos

El cliente no tiene un producto hasta el final.

El cliente lo quiere, aunque no es un producto

Módulos ineficientes se convierten en partes del

El Proceso Unificado de Desarrollo del Software (PUDS) es

El PUDS se puede decir que es un proceso: