Procesos para la Ingeniería de Software - uv.mx · PUDS (Proceso Unificado de Desarrollo de...

Facultad de Estadística e Informática

Procesos para la Ingeniería de SoftwarePERIODO FEBRERO-JULIO 2018


AgendaRepaso

Unidad I. Introducción◦ Conceptos

◦ Elementos Básicos

◦ Niveles

◦ Medición

◦ Introducción al PSP◦ ¿Qué es PSP?

◦ Niveles

◦ Registro de tiempos

Unidad II. Modelado de procesos de negocio◦ Notación de Erickson Penker

Unidad III. Modelos de procesos de desarrollo de software◦ Cascada

◦ Espiral

◦ Prototipos

◦ Evolutivo

◦ Incremental

◦ PUDS (Proceso Unificado de Desarrollo de Software)


AgendaRepaso

Unidad I. Introducción◦ Conceptos

◦ Elementos Básicos

◦ Niveles

◦ Medición

◦ Introducción al PSP◦ ¿Qué es PSP?

◦ Niveles

◦ Registro de tiempos


Unidad I. IntroducciónSoftware. Conjunto de programas, documentos asociados y la configuración de datos que se necesitan para hacer que estos programas funcionen de manera correcta (Sommerville).

Proceso. Un proceso define: quién hace qué, cuándo y cómo para alcanzar el objetivo. (Jacobson).

Conjunto de actividades, acciones y tareas que se ejecutan cuando va a crearse un producto del trabajo.


Unidad I. IntroducciónProceso. Conjunto de prácticas relacionadas entre sí, llevadas a cabo a través de roles y por elementos automatizados, que utilizando recursos y a partir de insumos producen un satisfactor de negocio para el cliente.

En IS el proceso no es una prescripción rígida de cómo elaborar software,

es un enfoque adaptable.


Unidad I. Introducción▪ Definiciones de calidad

“Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente”. [R.S.Pressman]

“Grado con el que un sistema, componente o proceso cumple los requisitos especificados y las necesidades del cliente o usuario” [IEEE 610-1990]


Unidad I. Introducción

▪ Definiciones de calidad

“Conjunto de propiedades o características de un producto o servicio que le confieren aptitud para satisfacer unas necesidades expresadas o implícitas”. [ISO 8402]



▪ En resumen. Calidad…

Consiste en las características del producto que satisfacen las necesidades de los clientes y les proporciona por tanto satisfacción con el producto.

Si cuidamos el proceso Calidad en el producto



▪Más conceptos…

Actividad. Busca lograr un objetivo amplio (comunicación entre participantes) y se desarrolla sin importar el dominio de la aplicación, tamaño del proyecto, complejidad del esfuerzo.

Acción. Conjunto de tareas que producen un producto importante de trabajo (modelo del diseño de la arquitectura).



Tarea. Se centra en un objetivo pequeño pero bien definido (prueba unitaria) que produce un resultado tangible.

Incremento de software. Subconjunto de características y funcionalidad generales del sistema. Conforme se produce cada incremento, el software se hace más y más completo.

Iteración. Acto de repetir un proceso con el objetivo de alcanzar una meta deseada, objetivo o resultado, los resultados de una iteración se utilizan como punto de partida para la siguiente iteración.



Modelo. Resultado del modelado, esquema que representa un sistema o realidad compleja que se elabora para facilitar su comprensión y el estudio de su comportamiento.

Medida. Proporciona un indicio cuantitativo de la extensión, cantidad, dimensión, capacidad o tamaño de algún atributo del producto o proceso.



Medición. Acto de determinar la medida, ocurre como resultado de la recolección de uno o más puntos de datos.

Métrica. Según la IEEE, la métrica la define como medida cuantitativa del grado en el que un sistema, componente o proceso posee un atributo determinado.

Indicador. Es una métrica o combinación de métricas que proporcionan comprensión acerca del proceso de software, el proyecto de software o el producto en si.


Unidad I. IntroducciónVerificación. Conjunto de tareas que garantizan que el software implementa correctamente una función específica. ¿Construimos el software correctamente?

Validación. Conjunto diferente de tareas que aseguran que el software que se construye sigue los requerimientos del cliente. ¿Construimos el producto correcto?

Estándar. Que sirve como modelo, norma, patrón o referencia.


Proceso de Producción de SoftwareESTRUCTURA DEL PROCESO DE SOFTWARE


Introducción

▪El proceso que se lleva a cabo para construir, entregar y mantener un producto de software, desde la concepción de una idea hasta la entrega, y el retiro del sistema es llamado Proceso de Producción de Software


Introducción▪Objetivo de los procesos de producción de software:

Satisfacer las expectativas del cliente entregando productos de calidad en tiempo y con un presupuesto determinado.

Realizando productos rentables, de confianza, previsibles y eficientes.


Introducción▪Beneficios de un proceso de producción de software bien definido


Introducción▪Definiendo un modelo de proceso de producción de software obtenemos los beneficios de los procesos estandarizados, sin embargo recordemos que:▪ El proceso de producción de software es en gran medida una

actividad intelectual difícil de automatizar.

▪ El software es caracterizado por ser altamente inestable: los requerimientos cambian continuamente y como consecuencia, los productos son evolucionables.


Estructura del proceso de software

Actividades Estructurales

Actividades Sombrilla

CO

MU

NIC

AC

IÓN

PLA

NEA

CIÓ

N

MO

DEL

AD

O

CO

NST

RU

CC

IÓN

DES

PLI

EGU

E

-Seguimiento y control-Administración del riesgo-Administración de la reutilización-Administración de la configuración del soft.


Estructura del proceso de software▪Actividades sombrilla:▪ Seguimiento y Control del proyecto de software.

▪ Administración del riesgo.

▪ Administración de la reutilización.

▪ Preparación y producción del producto del trabajo.

▪ Administración de la configuración del software.

▪ Medición.

▪ Revisiones técnicas.

▪ Aseguramiento de la calidad.


▪Actividades estructurales:▪Comunicación

▪Planeación

▪Modelado

▪Construcción

▪Despliegue



Estructura del proceso de software▪Actividades sombrilla:

1. Seguimiento y Control del proyecto de software.


Estructura del proceso de software“El seguimiento es el proceso sistemático en virtud del cual se recopila y se analiza información con el objeto de comparar los avances logrados en función de los planes formulados y corroborar el cumplimento de las normas establecidas.

Ayuda a identificar tendencias y patrones, a adaptar las estrategias y a fundamentar las decisiones relativas a la gestión del proyecto o programa.”


Estructura del proceso de software▪¿Qué se requiere para llevar a cabo un seguimiento del avance de

equipo de desarrollo de software?

Una calendarización adecuada, que debe considerar los siguientes puntos:i. Todas las tareas deben aparecer en la red.ii. El esfuerzo y la calendarización deben ser asignados de manera inteligente a cada

tarea.iii. Las interdependencias entre tareas deben ser indicadas de manera adecuada.iv. Deben asignarse los recursos para el trabajo que se va a realizar.v. Deben establecerse hitos espaciados de modo que pueda darse seguimiento al

progreso.vi. Debe permitir identificar las tareas cruciales dentro de la red para monitorear su

progreso y ser capaces de reconocer demoras inmediatamente.



▪El seguimiento puede lograrse en varias formas diferentes:

▪Realizar reuniones periódicas del estado del proyecto, en las que

cada miembro del equipo reporte avances y problemas.

▪Determinar si los hitos formales del proyecto se lograron en la fecha

prevista.

▪Comparar la fecha de inicio real con la fecha de inicio planeada para

cada tarea de proyecto mencionada en la tabla de recursos.



▪El seguimiento puede lograrse en varias formas diferentes:

▪Reunirse informalmente con los profesionales para obtener su

valoración subjetiva del avance a la fecha y los problemas en el

horizonte

▪Usar análisis de valor ganado para valorar cuantitativamente el

avance



2. Administración del riesgo.


Estructura del proceso de software¿Que son los riesgos?

Se puede concebir un riesgo como una probabilidad de que una circunstancia adversa ocurra.

Los riesgos son una amenaza para el proyecto, para el software que se está desarrollando y para la organización.


Estructura del proceso de softwareCategorías de riesgos

1. Riesgos del proyecto. Éstos afectan la calendarización o los recursos del proyecto. Un ejemplo podría ser la pérdida de un diseñador experimentado.

2. Riesgos del producto. Éstos afectan a la calidad o al rendimiento del software que se está desarrollando. Un ejemplo podría ser que el rendimiento en un componente que hemos comprado sea menor que el esperado.

3. Riesgos del negocio. Estos afectan a la organización que desarrolla o suministra el software. Por ejemplo, que un competidor introduzca un nuevo producto es un riesgo de negocio.


Estructura del proceso de softwarePlanes de contingencia.

1. identificación de riesgos. Identificar los posibles riesgos para el proyecto, el producto y los negocios.

2. Análisis de riesgos. Valorar las probabilidades y consecuencias de estos riesgos.

3. Planificación de riesgos. Crear planes para abordar los riesgos, ya sea para evitarlos o minimizar sus efectos en el proyecto.

4. Supervisión de riesgos. Valorar los riesgos de forma constante y revisar los planes para la mitigación de riesgos tan pronto como la información de los riesgos esté disponible.



3. Administración de la reutilización.



3. Administración de la reutilización.

Define criterios para volver a usar el producto (o componentes) y establece mecanismos para obtener componentes reutilizables.


Estructura del proceso de software▪Beneficios de la reutilización:

oIncremento de la confiabilidad

oReducción del riesgo del proceso

oUso efectivo de especialistas

oCumplimiento de estándares

oDesarrollo acelerado



4. Preparación y producción del producto del trabajo.

Agrupa las actividades requeridas para crear los productos necesarios del trabajo tales como: modelos, documentos, registros, formatos, y listas.



5. Administración de la configuración del software.



▪El arte de coordinar el desarrollo de software para

minimizar [...] la confusión se llama administración de la

configuración, que es el arte de identificar, organizar y

controlar las modificaciones que se hacen al software que

construirá un equipo de programación. La meta es

maximizar la productividad al minimizar los errores.

Babich [Bab86]



▪¿Cuándo surge la confusión?

▪Los cambios no se analizan antes de que se realicen.

▪Los cambios no se registran antes de que se implanten.

▪Los cambios no se reportan a quienes tienen necesidad de

conocerlos

▪ Los cambios no se controlan en forma que mejore la calidad y se

reduzca el error.


Estructura del proceso de software▪La administración de la configuración del software (ACS) es una actividad sombrilla.

1) Identificar el cambio

2) Controlar el cambio

3) Garantizar que el cambio se implementó de manera adecuada y

4) Reportar los cambios a otros que puedan estar interesados.



“Es muy fácil que un torrente de cambios

descontrolados convierta en caos un proyecto de

software bien estructurado”



▪¿Qué es la configuración del software?

▪Son los ítems que comprenden toda la información producida como parte

del proceso de software.

▪Un Item de Configuración del Software (ICS) es todo o parte de un

producto de trabajo (por ejemplo, un documento, toda una suite de

casos de prueba o un componente de programa nominado).



6. Medición.



EstimaciónCalendariza-ción

Análisis de

riesgos

Planificación de

gestión de la calidad

Planificación de

gestión del

cambio

Planificación de Procesos de Software



¿En qué consiste la Estimación?



▪ ¿Cuánto esfuerzo se requiere

para completar una actividad?

▪¿Cuánto tiempo de calendario se

necesita para completar una

actividad?

▪¿Cuál es el costo total de una

actividad?



▪ ESTIMACIÓN

Intento por determinar cuánto dinero, esfuerzo,

recursos y tiempo tomará construir un sistema o

producto específico basado en software



▪Algunas estimaciones se realizan antes de la

planeación detallada:

▪ Cálculo del presupuesto del proyecto

▪ Establecimiento de costo de software para un cliente

Una vez iniciado el proyecto, los gestores deben actualizar

las estimaciones de tiempo y costo.



7. Revisiones técnicas.


Estructura del proceso de software▪Las revisiones del software son un “filtro” para el proceso del

software.

▪Se aplican en varios puntos durante la ingeniería de software y

sirven para descubrir errores y defectos a fin de poder eliminarlos.

▪Errar es humano.

▪Algunas personas son buenas para detectar errores propios, sin

embargo algunos pasan desapercibidos con más facilidad para

quien los comete que para otras personas.



▪Una revisión es una forma de utilizar la diversidad de un grupo

para:

1. Resaltar las mejoras necesarias en el producto que elaboró una

sola persona o equipo;

2. Confirme aquellas partes de un producto en las que no se desea o

no se necesita hacer una mejora.

Las revisiones técnicas son el mecanismo más eficaz para detectar los errores en una etapa temprana del proceso de software.


Estructura del proceso de software▪¿Quién hace la revisión?

Los ingenieros de software realizan una revisión técnica, también

llamada revisión de pares, con sus colegas.



▪Revisión Técnica Formal (RTF)

▪¿Qué es?

Es una actividad del control de calidad del software

realizada por ingenieros de software (y otras personas).


Estructura del proceso de software▪Revisión Técnica Formal (RTF)

▪¿Objetivos?

1. Descubrir y eliminar los errores en funcionamiento, lógica o

implementación de cualquier representación del software, antes de que se

propaguen a la siguiente actividad.

2. Verificar que el software que se revisa cumple sus requerimientos

3. Garantizar que el software está representado de acuerdo con estándares

predefinidos

4. Obtener software desarrollado de manera uniforme



8. Aseguramiento de la calidad.



▪Aseguramiento de la calidad del software

Algunos desarrolladores de software todavía creen que la calidad del

software es algo por lo que hay que empezar a preocuparse una vez

generado el código.



▪¿Cómo se determina que un sistema tiene mala

calidad?

o Sólo se requiere de tres a cuatro defectos por cada 1, 000 líneas de código para

que un programa tenga mal desempeño.

o La mayoría de los programadores cometen un error en cada 10 líneas de código

que escriben.

La corrección de los errores cuesta a los vendedores de software al menos la mitad de sus presupuestos de desarrollo durante las pruebas.



▪Costos de la calidad

▪El costo promedio por corregir un defecto durante la codificación es

aproximadamente de US$977 por error.

▪El promedio del costo por corregir el mismo error si se descubre

durante las pruebas del sistema es de US$7, 136.

▪Según Cigital: una aplicación grande contiene 200 errores

(200 × US$977) = US$195 400


Estructura del proceso de software¿Cuáles son los pasos para lograr software de alta calidad? oUsar procesos y prácticas probados de la ingeniería de software, administrar bien el proyecto

oRealizar un control de calidad exhaustivo

oContar con infraestructura de aseguramiento de la calidad.


Estructura del proceso de software▪Aseguramiento de la calidad del software

▪Es una actividad sombrilla. Incluye:

▪ 1) Un proceso de Aseguramiento de la calidad del software (ACS),

▪ 2) Tareas específicas de aseguramiento y control de la calidad (incluidas revisiones técnicas y una estrategia de pruebas relacionadas entre sí)

▪ 3) Prácticas eficaces de ingeniería de software (métodos y herramientas)

▪ 4) Control de todos los productos del trabajo de software y de los cambios que sufren

▪ 5) Un procedimiento para garantizar el cumplimiento de los estándares del desarrollo de software (cuando sea aplicable)

▪ 6) Mecanismos de medición y reporte.



▪ Elementos:

▪ Estándares.

▪ Revisiones y auditorías

▪ Pruebas.

▪ Colección y análisis de los errores.

▪ Administración del cambio.

▪ Educación/Capacitación.

▪ Administración de los proveedores.

▪ Administración de la seguridad.

▪ Seguridad.

▪ Administración de riesgos



▪Tareas:

▪Dos entidades diferentes ayudan a asegurar la calidad: los ingenieros de software que hacen el trabajo técnico y un grupo de ACS.

▪ El grupo ACS tiene la responsabilidad de planear, supervisar, registrar, analizar y hacer reportes acerca de la calidad.

▪ Los ingenieros de software abordan la calidad (y ejecutan actividades para controlarla), aplicando métodos y medidas técnicas sólidos, realizando revisiones técnicas y haciendo pruebas de software bien planeadas.


Estructura del proceso de software▪Aseguramiento de la calidad del software. El grupo ACS:

1. Prepara el plan de ACS para un proyecto.

2. Participa en el desarrollo de la descripción del software del proyecto.

3. Revisa las actividades de la ingeniería de software a fin de verificar el cumplimiento mediante el proceso definido para el software.

4. Audita los productos del trabajo de software designados para verificar que se cumpla con aquellos definidos como parte del proceso de software.

5. Registra toda falta de cumplimiento y la reporta a la alta dirección.

Coordina el control y administración del cambio y ayuda a recabar y analizar métricas para el software.



▪El plan ACS incluye:

▪Las evaluaciones que se van a realizar

▪Las auditorías y revisiones por efectuar

▪Los estándares aplicables al proyecto

▪Los procedimientos para reportar y dar seguimiento a los errores

▪Los productos del trabajo que genera el grupo de ACS y la retroalimentación que se dará al equipo del software.



¿Cuál es el producto final?

▪Software que satisface las necesidades del consumidor, con

un desempeño apropiado y confiable, y que agrega valor

para todos los que lo utilizan.



Actividades Estructurales


CO

MU

NIC

AC

IÓN

PLA

NEA

CIÓ

N

MO

DEL

AD

O

CO

NST

RU

CC

IÓN

DES

PLI

EGU

E

-Seguimiento y control-Administración del riesgo-Administración de la reutilización-Administración de la configuración del soft.



▪Comunicación

Es importante antes de cualquier trabajo técnico comunicarse y colaborar con el cliente y los demás participantes. ¿Finalidad? Entender el objetivo del proyecto y reunir los requerimientos

¿Para qué? Para definir las características y funciones del software.


Estructura del proceso de software▪Planeación. “Mapa” o guía de un equipo de trabajo llamado plan del proyecto de software.

Define las tareas, riesgos probables, recursos, productos que se obtienen y establece la programación de las actividades.


Estructura del proceso de softwareModelado. “Bosquejo” que se realiza para entender mejor el panorama del general de un proyecto, se puede ir refinando con más y más detalles con el propósito de comprender mejor el problema y cómo se resolverá.

El modelado muestra: Cómo se verá arquitectónicamente el proyecto Cómo se ajustan o ubican las partes que lo constituyen Sus características En IS los modelos sirven para entender los requerimientos del software y elaborar el diseño del mismo


Estructura del proceso de softwareConstrucción. Generar código y pruebas para descubrir posibles errores.


Estructura del proceso de softwareDespliegue. Entrega del producto al cliente para su evaluación y retroalimentación.


Mejoramiento del Proceso de Software


Mejoramiento del Proceso de SoftwareMejoramiento del Proceso de Software (MPS) implica

Primero, que los elementos de un proceso de software efectivo pueden definirse en forma efectiva;

Segundo, que un enfoque organizacional existente sobre el desarrollo del software puede valorarse en contraste con dichos elementos;

Tercero, que es posible definir una estrategia de mejoramiento significativa



La estrategia MPS transforma el enfoque existente sobre el desarrollo del software

en algo que es más enfocado, más repetible y más confiable


Mejoramiento del Proceso de SoftwareExisten marcos conceptuales MPS que definen:

1) Un conjunto de características que deben presentarse si quiere lograrse un proceso de software efectivo,

2) Un método para valorar si dichas características están presentes,

3) Un mecanismo para resumir los resultados de cualquier valoración y

4) Una estrategia para auxiliar a una organización de software a implementar aquellas características del proceso que sean débiles o que hagan falta.


Mejoramiento del Proceso de SoftwareBeneficios del uso de una estrategia MPS:

❖ Reducción en los “problemas” del software que cuestan tiempo y dinero.

❖ Reducción del número de defectos que se entregan a los usuarios finales,

❖ Reducción de la cantidad de repetición de proceso debida a problemas de calidad

❖ Reducción de los costos asociados con el mantenimiento y el soporte del software

❖ Reducción de los costos indirectos que ocurren cuando el software se entrega tarde.



Un marco conceptual MPS valora la “madurez” del proceso de una organización y proporciona un indicio cualitativo de su nivel de madurez.



Elementos de unmarco conceptualMPSFuente: Pressman 2002



Marco conceptual MPS

Modelo de Madurez

Indicadores de calidad del proceso

Calidad del producto

Medida global de la calidad del proceso

Proporcionar un indicio global de la “madurez del proceso” quemuestra una organización de software, es decir, un indicio de la calidad del proceso de software, el grado en el que los profesionales entienden y aplican el proceso, y el estado general de la práctica de ingeniería del software.



Un indicio de la calidad del proceso de software, el grado en el que los profesionales entienden y aplican el proceso, y el estado general de la práctica de ingeniería del software.

Modelo de madurez

Indicio global de la “madurez del proceso” que muestra una organización de software



Esto se logra usando algún tipo de escala ordinal.

Por ejemplo, el Modelo de madurez de capacidad del Software Engineering Institutesugiere cinco niveles de madurez [Sch96] y soporta 2 caminos de mejora:


Mejoramiento del Proceso de SoftwareUn camino permite a las organizaciones mejorar de forma incremental los procesos que corresponden a un área o áreas de proceso individual seleccionada por la organización.

El otro camino permite a las organizaciones mejorar un conjunto de procesos relacionados, tratando de forma incremental conjuntos sucesivos de áreas de proceso.



Para la representación continua, se utiliza el término “nivel de capacidad” y se enfoca en la capacidad del área de proceso cuando se mide por niveles de capacidad.

Para la representación por etapas, se utiliza el término “nivel de madurez” y se enfoca en la madurez de la organización cuando se mide por niveles de madurez.



Niveles de madurez [Sch96]


Mejoramiento del Proceso de SoftwareNivel 5, optimizado. La organización tiene sistemas de realimentación cuantitativa para identificar las debilidades del proceso y fortalecer esos puntos de manera proactiva.

Los equipos de proyecto analizan defectos para determinar sus causas; los procesos de software se evalúan y actualizan para evitar que recurran tipos conocidos de defectos.


Mejoramiento del Proceso de SoftwareNivel 4, gestionado cuantitativamente. Métricas de proceso de software y de calidad de producto detalladas establecen el cimiento de evaluación cuantitativa.

Las variaciones significativas en el desempeño del proceso pueden distinguirse del ruido aleatorio, y pueden predecirse las tendencias en las cualidades del proceso y el producto.


Mejoramiento del Proceso de SoftwareNivel 3, definido. Los procesos para administración e ingeniería se documentan, estandarizan e integran en un proceso de software estándar para la organización.

Todos los proyectos usan una versión aprobada y a la medida del proceso de software estándar de la organización para desarrollo de software.


Mejoramiento del Proceso de SoftwareNivel 2, gestionado/repetible. Se establecen procesos de administración de proyecto básicos para rastrear costo, calendario y funcionalidad.

La planificación y administración de nuevos productos se basa en la experiencia con proyectos similares.


Mejoramiento del Proceso de SoftwareNivel 1, inicial. Pocos procesos definidos, y el éxito depende más del esfuerzo heroico individual que de seguir un proceso y usar un esfuerzo sinérgico de equipo.


Mejoramiento del Proceso de SoftwareMuchas organizaciones muestran niveles de “inmadurez de proceso”.

Schorsch [Sch06] sugiere cuatro niveles de inmadurez que se encuentran frecuentemente en el mundo real de las organizaciones de desarrollo del software:


Mejoramiento del Proceso de SoftwareNivel 0, negligente.

Fracaso para permitir que tenga éxito un proceso de desarrollo exitoso. Todos los problemas se perciben como problemas técnicos.


Mejoramiento del Proceso de SoftwareNivel 1, obstructivo.

Se imponen procesos contraproducentes. Los procesos se definen rígidamente y se adhieren a la forma que subrayan. Abundan las ceremonias rituales.

La administración colectiva impide la asignación de responsabilidad.


Mejoramiento del Proceso de SoftwareNivel 2, despreciador.

No se preocupa por la buena ingeniería de software institucionalizada. Hay desunión completa entre actividades de desarrollo de software y actividades de mejoramiento del proceso de software y falta completa de programas de capacitación.


Mejoramiento del Proceso de SoftwareNivel 3, socavación.

Desprecio total por la propia organización, descrédito consciente de los esfuerzos de mejoramiento del proceso de software de los pares de la organización.

Recompensa al fracaso y al pobre desempeño.


Medición/Estimación


Estimación

EstimaciónCalendariza-ción

Análisis de

riesgos

Planificación de

gestión de la calidad

Planificación de

gestión del

cambio

Planificación de Procesos de Software


¿En qué consiste la Estimación?


Estimación

▪ ¿Cuánto esfuerzo se requiere

para completar una actividad?

▪¿Cuánto tiempo de calendario se

necesita para completar una

actividad?

▪¿Cuál es el costo total de una

actividad?


Estimación

▪ ESTIMACIÓN

Intento por determinar cuánto dinero, esfuerzo,

recursos y tiempo tomará construir un sistema o

producto específico basado en software


Estimación

Estimación y Planeación


Estimación

▪Algunas estimaciones se realizan antes de la

planeación detallada:

▪ Cálculo del presupuesto del proyecto

▪ Establecimiento de costo de software para un cliente

Una vez iniciado el proyecto, los gestores deben actualizar

las estimaciones de tiempo y costo.


1.3 Vista general de la administración de un proyecto en forma de proceso .

Estimación de costos

•Costos de hardware y software, incluyendo mantenimiento.

•Costos de viajes y capacitación.

•Costos de esfuerzo (pagos).


1.3 Vista general de la administración de un proyecto en forma de proceso .

Estimación de costos• Costos de esfuerzo (pagos).

o Costos de proveer, aclimatar, iluminar oficinas.

o Costos del personal de apoyo: administrativos, técnicos, limpieza, etc.

o Costos de redes y comunicaciones.

o Costos de recursos centralizados, bibliotecas, espacios recreativos, etc.

o Costos de seguridad social, pensiones, prestaciones.


Estimación

▪Número de errores descubiertos dentro de un solo componente de software

Medida

Un indicio cuantitativo de la extensión, cantidad, dimensión,

capacidad o tamaño de algún atributo de un producto o

proceso

▪Medida, Medición y Métrica


Estimación


Medición

Es el acto de determinar una medida

▪Revisiones de componente y pruebas de unidad se

investigan para recolectar medidas del número de errores

de cada uno.


Estimación


Métrica

Una medida cuantitativa del grado en el que un sistema,

componente o proceso posee un atributo determinado

▪El número promedio de errores que se encuentran por revisión o el

número promedio de errores que se encuentran por unidad de prueba


Estimación

¿Cuál es la métrica que proporcionará una medida

que abarque la complejidad del software?


Estimación

El Proceso de Medición de Software


Estimación

▪Pasos:

Descripción del ámbito del problema

Descompone en un conjunto de problemas más pequeños

Cada uno de éstos se estima, usando como guías datos históricos y experiencia

Complejidad(Valoraciones

cuantitativas / subjetivas


Estimación

▪¿Cuál es el resultado?

Tabla simple que delinea las tareas que se van a realizar, las

funciones por implementar y el costo, esfuerzo y tiempo involucrados

para cada tarea.


Estimación▪¿Cómo asegurar que se realiza la estimación correcta?

▪Experiencia

▪Enfoque sistemático

▪Generación de estimaciones usando datos históricos sólidos

▪Creación de puntos de datos de estimación con al menos dos métodos diferentes

▪Calendario realista y continuamente se adapta conforme el proyecto avanza.


Estimación

▪Estimaciones de productividad

✓Se basan en medir algunos de los atributos del

software y dividir el resultado entre el esfuerzo total

requerido para el desarrollo.


Estimación

Existen dos tipos de medidas utilizadas:

▪Medidas relacionadas con el tamaño.

▪Medidas relacionadas con la función.


Estimación


✓Líneas de código fuente entregadas.

✓Instrucciones en código objeto.

✓Páginas de la documentación del sistema.


Estimación

▪Medidas relacionadas con la función.

✓Funcionalidad total del software entregado.

✓ Esta funcionalidad se expresa de acuerdo a la

cantidad de funcionalidad útil entregada en x tiempo.

✓Las medidas más conocidas son: Puntos de función

y Puntos de objeto.


Estimación


Líneas de código fuente entregadas.


Estimación

▪Medidas de productividad relacionadas con el tamaño.

Líneas de código fuente por programador/mes.

1) Se calcula contando el número total de líneas de código fuente que

entrega.

2) Se divide entre el tiempo total de programadores/mes requerido para

completar el proyecto.

3) Incluye el tiempo requerido para el análisis, diseño, codificación, pruebas y

documentación.


Estimación▪Líneas de código fuente por programador/mes.

o El enfoque se desarrolló para FORTRAN, ensamblador o COBOL.

o La programación se llevaba a cabo mediante cintas perforadas, una instrucción en cada tarjeta.

¿Será lo mismo para C++ o Java?

o ¿Qué se cuenta? Instrucciones ejecutables o Manejo de información o toda línea que no se encuentre en blanco.


Estimación

5,000 líneas /7 meses

1,500 líneas /5 meses


Estimación

▪Aparentemente, los costos de desarrollo en un

lenguaje de alto nivel son menores y se producen en

menos tiempo.

▪Una alternativa es utilizar una medida de la

funcionalidad del producto, la más conocida es la de

Puntos de función.


Estimación

▪Medidas de estimación de productividad de acuerdo

a la funcionalidad del producto.

o Puntos de función.


Estimación▪Medida por puntos de función. Valores del dominio de información:

oEntradas externas (EE) y salidas externas (SE).

oConsultas externas (CE).

oArchivos lógicos internos (ALI).

oArchivos de interfaz externos (AIE).


3. Estimación. Cálculo de los Factores de ajuste de valor (FAV)

1. ¿El sistema requiere respaldo y recuperación confiables?

2. ¿Se requieren comunicaciones de datos especializadas para transferir información hacia o desde la aplicación?

3. ¿Existen funciones de procesamiento distribuidas?

4. ¿El desempeño es crucial?

5. ¿El sistema correrá en un entorno operativo existente enormemente utilizado?

6. ¿El sistema requiere entrada de datos en línea?


7. ¿La entrada de datos en línea requiere que la transacción de entrada se construya sobre múltiples pantallas u operaciones?

8. ¿Los ALI se actualizan en línea?

9. ¿Las entradas, salidas, archivos o consultas son complejos?

10. ¿El procesamiento interno es complejo?



11. ¿El código se diseña para ser reutilizable?

12. ¿La conversión y la instalación se incluyen en el diseño?

13. ¿El sistema se diseña para instalaciones múltiples en diferentes organizaciones?

14. ¿La aplicación se diseña para facilitar el cambio y su uso por parte del usuario?



Personal Software Process (PSP)



▪ Conjunto de prácticas que ayuda a los profesionales

del software a mejorar su rendimiento en el proceso

de desarrollo del mismo.

▪Por lo que está enfocado al desarrollo individual y

fomenta la mejora personal.



El Proceso Personal de Software (En Inglés, Personal

Software Process o PSP) es un proceso individual cuyo

objetivo es ayudar a los ingenieros en software a medir y

mejorar su productividad personal



¿Cuándo se desarrolló?

▪Desarrollado por Watts Humphrey en 1995 y lo

describe en su libro “A discipline for Software

Engineering” en 1997.



▪Se puede aplicar en muchas partes del proceso de

desarrollo de software:

a) En el análisis.

b) En el desarrollo.

c) En las pruebas, etcétera.



▪ Si un desarrollador de software se rige por el

Proceso Personal de Software puede llevar a cabo:

a) Mejores estimaciones.

b) Mejor planificación y seguimiento.

c) Evitar compromisos que nunca cumplen.

d) Compromiso personal hacia la calidad.

e) Mejoramiento continuo.


Personal Software Process (PSP)▪ Principios:

1) Cada ingeniero es diferente, para ser más efectivos, deben planear su trabajo y basar sus planes en sus propios datos personales.

2) Para mejorar su rendimiento de forma constante, los ingenieros deben usar individualmente procesos medibles y bien definidos.

3) Para producir productos de calidad, los ingenieros deben sentirse personalmente responsables por la calidad de sus productos. Los productos superiores no son construidos por equivocación, los ingenieros deben esforzarse por hacer un trabajo de calidad.

4) Cuesta menos encontrar y arreglar defectos en etapas tempranas del proceso.

5) Es más eficiente prevenir defectos que encontrarlos y arreglarlos.

6) La manera correcta de realizar un trabajo es siempre la más rápida y barata.



▪ Las fases del PSP son:

PSP 0

Proceso

PSP 1

Estimación del tamaño

PSP 2

Revisión del código

Revisión del diseño

PSP 3

Desarrollo cíclico


Fuente: http://www.unipamplona.edu.co/unipamplona/portalIG/home_40/recursos/03_v13_18/revista_16/27102011/01.pdf

Niveles de Mejoramiento PSP


Evolución del PSP detallado

Fuente: http://www.sei.cmu.edu/reports/00tr022.pdf



▪ Fases

Medición Personal (PSP0)

Planificación Personal (PSP1)

Calidad Personal (PSP2)

Proceso Personal Cíclico (PSP3)



Filosofía

▪Para cumplir con los requerimientos del cliente se

requiere:i. Determinar de que forma se va a resolver el problema.

ii. Resolverlo.

iii. Estar seguro de que se solucionó de la forma correcta.

iv. Arreglar los problemas que se han encontrado.

v. Entregar el resultado final.



▪Esto se logra con:

Un buen plan y buenos formatos para

registrar la información provenientede la implementación del mismo


El proceso PSP 0 [HUMPHREY; 95]

Fuente:http://www.sei.cmu.edu/reports/00tr022.pdf


Estructura conceptual del proceso PSP

Fuente:Procesos de software_introduccion


SCRIPTS O FORMATOS DE PSP0



▪Formato de registro de tiempo. Registran su tiempo en

cada proceso

▪Formato de registro de defectos. Registran los datos de

los defectos que se encuentran durante todo el proceso

de desarrollo.

▪Resumen del plan del proyecto. Miden el tamaño del

programa, e incorpora datos históricos.



▪ PSP 0 - Personal Software Process 0

▪ Formato del registro de tiempo

▪Registrar el tiempo empleado en cada fase del proyecto.

▪El tiempo debe ser registrado en minutos. Con el formato HH:MM,

:MM

▪Las secciones que lo conforman son: Encabezado, fecha, inicio,

término, tiempo de interrupción, tiempo delta, fase y comentarios.


Formato del registro de tiempo




▪ Encabezado: Nombre del desarrollador, la fecha actual, el nombre del

supervisor o instructor y el número que le corresponde al programa que se está

desarrollando.

• Fecha.- Fecha en la que se realiza la tarea.

• Inicio.- La hora cuando se comienza a trabajar en el proyecto. HH:MM, :MM

• Término.- La hora cuando se deja de trabajar en el proyecto. HH:MM, :MM


Personal Software Process (PSP)▪ PSP 0 - Personal Software Process 0

• Tiempo de interrupción.- Se registran todas las interrupciones que se llevaron a cabo

durante el proyecto, es decir, el tiempo que no se emplea en trabajar en el proyecto.

• Tiempo delta.- Es el tiempo que se obtiene de la resta del tiempo empleado en el

proyecto menos el tiempo de interrupción.

• Fase.- Aquí se introduce el nombre de la fase en la que se trabaja, puede variar, no

tiene que ser la misma que en la que se está trabajando desde un principio.

• Comentarios.- Se tiene que procurar hacer todo tipo de comentarios útiles que

puedan recordar ciertas circunstancias.




▪ Formato de registro de defectos

▪Fuente de datos que nos ayudará a estimar de mejor

manera posible el tiempo del proyecto

▪Ayudará a evitar errores que se cometen con frecuencia.

▪Promueve la mejora continua en cada proyecto.




Tipos de defectos10 Documentación 60 Chequeo

20 Sintaxis 70 Datos

30 Construcción / Empaquetado 80 Función

40 Asignación 90 Sistema

50 Interfaz 100 Ambiente



▪ Formato de registro de defectosTipos de defectos10 Documentación Documentos, comentarios, mensajes no entendibles o

erróneos.

20 Sintaxis Defecto usualmente detectado por el compilador.

30 Construcción / Paquetes Errores en el control de versiones o en la gestión de cambios o librerías.

40 Asignación Errores en las llamadas a procedimientos. Operadores erróneos, expresiones erróneas, objetos asignados erróneamente, duplicidad de asignaciones, etc.




Tipos de defectos50 Interfaz Diseño o uso erróneo de la interfaz.

60 Chequeo Manejo de errores erróneo, inadecuado u omitido

70 Datos Estructura, contenido.

80 Función Defectos más allá de una declaración en algoritmos o funcionalidad (Lógica, punteros, bucles, recursión)




Tipos de defectos90 Sistema Problema con la red, el hardware o similar.

100 Ambiente Defecto en el ambiente de desarrollo o un sistema soporte (compiladores u otras herramientas)


Formato de

registro de

defectos




• Fecha.- Se introduce la fecha cuando se encuentra el defecto.

• Número.- Se introduce de manera secuencial el número de defecto

encontrado en cada programa.

• Tipo.- Se refiere al tipo de defecto que viene en la tabla adjunta al

formato, el tipo de defecto va desde 10 hasta 100 en intervalos de 10

en 10.




• Encontrado.- Nombre de la fase cuando se encontró el defecto.

• Removido.- Nombre de la fase cuando se removió el defecto encontrado.

• Tiempo de compostura.- Es el tiempo que tomó reparar el defecto

encontrado.

• Defecto arreglado.- Este campo quiere decir si se encontró algún defecto

extra mientras se reparaba el defecto detectado primero, en caso de no

haber ninguno, se introduce una X.




▪ Formato Resumen del Plan del Proyecto ▪Reúne las estimaciones y los datos reales del proyecto.

▪El objetivo es que al final se realicen las comparaciones necesarios.

▪Otro objetivo es tener un histórico de todos los proyectos realizados.


Formato

Resumen del Plan

del Proyecto


Personal Software Process (PSP)▪ Formato Resumen del Plan del Proyecto

▪Área de Tiempo en la fase.

• Plan.- Es el tiempo estimado que se empleará para desarrollar el proyecto completo.

• Actual.- Es el tiempo real, en minutos, que se emplea en cada una de las fases de desarrollo.

• A la fecha.- La suma del tiempo actual con el tiempo del último programa desarrollado.

• A la fecha %.- Es el porcentaje del tiempo que se emplea en cada fase de desarrollo.



▪Área de Defectos encontrados.

• Actual.- Número de defectos reales encontrados en cada fase de desarrollo.

• A la fecha.- Suma de los valores de los campos Actual (Defectos encontrados)

con el campo del último proyecto programado.

• A la fecha %.- Porcentaje de defectos encontrados a la fecha en cada fase de

desarrollo.



▪Área de Defectos removidos.

• Actual.- Indica el número de defectos removidos en cada etapa.

• A la fecha.- Es la suma del valor que se encuentra en el campo de Actual

(Defectos removidos) con el valor del último programa desarrollado.

• A la fecha %.- Porcentaje de defectos removidos del campo A la fecha y que se

aplica para cada fase de desarrollo.


AgendaRepaso

Unidad II. Modelado de procesos de negocio◦ Notación de Erickson Penker

Ver https://www.uv.mx/personal/ermeneses/files/2018/02/Clase6-Erickson-Penker.pdf

https://www.uv.mx/personal/ermeneses/files/2018/02/Clase6-Erickson-Penker.pdf


AgendaRepaso

Unidad III. Modelos de procesos de desarrollo de software◦ Cascada

◦ Evolutivo

▪ Espiral

▪ Prototipos

◦ Incremental

◦ PUDS (Proceso Unificado de Desarrollo de Software)


Modelos de procesos de desarrollo de software

▪ Proceso de software

Se define proceso del software como una estructura para las actividades, acciones y tareas que se requieren a fin de construir software de alta calidad.


Modelos de procesos de desarrollo de software¿Por qué es importante?

Porque da estabilidad, control y organización a una actividad que puede volverse caótica si se descontrola.

Sin embargo, un enfoque moderno de ingeniería de software debe ser “ágil”.


Modelos de procesos de desarrollo de software¿Por qué es importante?

Debe incluir sólo aquellas actividades, controles y productos del trabajo que sean apropiados para el equipo del proyecto y para el producto que se busca obtener.



▪ Proceso de software

Se define proceso del software como una estructura para las actividades, acciones y tareas que se requieren a fin de construir software de alta calidad.



▪ Cada una de las actividades, acciones y tareas se

encuentra dentro de una estructura o modelo que

define su relación tanto con el proceso como entre sí.



▪Modelo general de

proceso



▪ La estructura general para la ingeniería de software

define cinco actividades estructurales:

comunicación, planeación, modelado, construcción y

despliegue.



Actividades EstructuralesC

OM

UN

ICA

CIÓ

NP

LAN

EAC

IÓN

MO

DEL

AD

O

CO

NST

RU

CC

IÓN

DES

PLI

EGU

E




▪ Flujo del proceso de las actividades estructurales



Por qué se crearon los Modelos de

Proceso



▪ Los modelos de proceso fueron propuestos

originalmente para poner orden en el caos del

desarrollo de software.

▪ Otorgan cierta estructura útil al trabajo de

ingeniería de software y constituyen un mapa

razonablemente eficaz para los equipos de software.


Modelos de procesos de desarrollo de software▪ Los Modelos de proceso prescriben un conjunto de elementos del proceso:

▪ Actividades estructurales

▪ Acciones de ingeniería de software,

▪ Tareas,

▪ Productos del trabajo,

▪ Aseguramiento de la calidad y

▪Mecanismos de control del cambio para cada proyecto.

▪Cada modelo del proceso también prescribe un flujo del proceso (también llamado flujo de

trabajo) (la manera en la que los elementos del proceso se relacionan entre sí)



▪ Todos los modelos del proceso del software pueden

incluir las actividades estructurales generales

descritas anteriormente, pero cada una pone distinto

énfasis en ellas y define en forma diferente el flujo de

proceso que invoca cada actividad estructural (así

como acciones y tareas de ingeniería de software).



Modelos de procesos de desarrollo de

software existentes


Modelo en cascada



▪Modelo en cascada o ciclo de vida clásico


Modelos de procesos de desarrollo de softwareModelo en cascada o ciclo de vida clásico

▪Enfoque sistemático y secuencial.

▪ Comienza con la especificación de los requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado



Modelo en cascada o ciclo de vida clásico

▪Los requerimientos para cierto problema se

comprenden bien.

▪El trabajo desde la comunicación hasta el despliegue

fluye en forma razonablemente lineal.Adaptaciones o mejoras bien definidas a un sistema ya

existente




▪ Variante del modelo en cascada “Modelo en V”

▪ Acciones de aseguramiento de la calidad




Modelo en V




Problemas:

1. Es raro que los proyectos reales sigan el flujo secuencial

propuesto por el modelo. Aunque el modelo lineal acepta

repeticiones, lo hace en forma indirecta. Como resultado,

los cambios generan confusión conforme el equipo del

proyecto avanza.


Modelos de procesos de desarrollo de softwareModelo en cascada o ciclo de vida clásico

Problemas:

2. Es difícil para el cliente enunciar en forma explícita todos los requerimientos.

El modelo en cascada necesita que se haga y tiene dificultades para aceptar la incertidumbre natural que existe al principio de muchos proyectos.




Problemas:

3. El cliente debe tener paciencia. No se dispondrá de una

versión funcional del(de los) programa(s) hasta que el

proyecto esté muy avanzado. Un error grande sería

desastroso si se detectara hasta revisar el programa en

funcionamiento.




La naturaleza lineal del ciclo de vida clásico llega a

“estados de bloqueo” en los que ciertos miembros del

equipo de proyecto deben esperar a otros a fin de

terminar tareas interdependientes




El trabajo de software es acelerado y está sujeto a una

corriente sin fin de cambios (en las características,

funciones y contenido de información).


Modelo incremental



Modelos de proceso incremental




▪Modelo de proceso diseñado para producir el

software en incrementos.




▪Requerimientos iniciales del software

razonablemente bien definidos, pero el alcance

general del esfuerzo de desarrollo imposibilita un

proceso lineal.




▪ Necesidad imperiosa de dar rápidamente cierta

funcionalidad limitada de software a los usuarios y

aumentarla en las entregas posteriores de software.


Modelos de procesos de desarrollo de softwareModelos de proceso incremental

▪El primer incremento es el producto fundamental.

▪Se abordan los requerimientos básicos, pero no se proporcionan muchas características suplementarias (algunas conocidas y otras no).

▪El cliente usa el producto fundamental (o lo somete a una evaluación detallada).




▪Como resultado del uso y/o evaluación se desarrolla un plan para el incremento que sigue.

▪El plan incluye la modificación del producto fundamental para cumplir mejor las necesidades del cliente, así como la entrega de características adicionales y más funcionalidad.

▪Este proceso se repite después de entregar cada incremento, hasta terminar el producto final.




▪ En cada incremento se entrega un producto que ya

opera.

▪ Útil en particular cuando no se dispone de personal

para la implementación completa del proyecto en el

plazo establecido por el negocio.


Modelo evolutivo



Modelos de proceso evolutivos

Modelo de proceso diseñado explícitamente

para adaptarse a un producto que evoluciona

con el tiempo.




Los sistemas complejos evolucionan

Es frecuente que los requerimientos del negocio y del

producto cambien conforme avanza el desarrollo.




▪ Plazos apretados

▪Se comprende bien el conjunto de requerimientos o

el producto básico

▪ Los detalles del producto o extensiones del sistema

aún están por definirse.




oLos modelos evolutivos son iterativos.

❖Prototipo

❖Espiral


Modelo evolutivo. Prototipo




Prototipo

✓El cliente define un conjunto de objetivos generales.

✓No identifica los requerimientos detallados para las

funciones y características.




Prototipo

✓El desarrollador no está seguro de la eficiencia de

un algoritmo, la adaptabilidad de un sistema

operativo o de la interacción humano-computadora.




Prototipo

El modelado se centra en la representación de aquellos aspectos del software que serán visibles para los usuarios finales




Prototipo

El ideal es que el prototipo sirva como mecanismo

para identificar los requerimientos del software.




Prototipo

¿Qué hacer con el prototipo cuando ya sirvió para el

propósito descrito?




Prototipo

Brooks: En la mayoría de proyectos es raro que el primer sistema elaborado sea utilizable.

Muy lento, muy grande, difícil de usar o todo a la vez.

No hay más alternativa que comenzar de nuevo.




Prototipo. Problemas

✓Los participantes ven lo que parece ser una versión

funcional del software, pero no se consideró la calidad, la

facilidad de mantenimiento, por la prisa. Los usuarios

exigen el prototipo como producto funcional.




Prototipo. Problemas

✓Se toman decisiones que inicialmente son las adecuadas

(con el fin de lograr el prototipo rápidamente): Lenguaje

de programación conocido, algoritmo ineficiente. Esta

elección formará parte del sistema final.




Prototipo. Paradigma exitoso si…

✓Se definen desde el principio las reglas del juego.

El prototipo sirve como el mecanismo para definir los requerimientos. Después se descartará (al menos en parte) y se hará la ingeniería del software real con la mirada puesta en la calidad.


Modelo evolutivoESPIRAL


Modelos de procesos de desarrollo de softwareModelos de proceso evolutivos. Espiral.

▪ Propuesto en primer lugar por Barry Boehm.

▪ Es un modelo con la naturaleza iterativa de hacer prototipos y los aspectos controlados y sistémicos del modelo de cascada.

▪Representa el proceso de desarrollo de software como una espiral.



Modelos de proceso evolutivos. Espiral.

Consideración explícita del riesgo.



Modelos de proceso evolutivos. Prototipos.

▪ d




1. Definición de objetivos. • Definen los objetivos específicos. • Identifica las restricciones del proceso y el

producto. • Se traza un plan detallado de gestión. • Se identifican los riesgos del proyecto.

Dependiendo de los riesgos se planean las estrategias.



Modelos de proceso evolutivos. Espiral

2. Evaluación y reducción del riesgo. • Análisis detallado de cada riesgo.• Plan para reducir los riesgos. P.e. Si existe

el riesgo de tener requerimientos inapropiados, se puede resolver desarrollando un prototipo del sistema.




3. Desarrollo y validación.• Se elige un modelo para el desarrollo del

sistema.• Si existen riesgos en la interfaz de usuario

se elige la construcción de prototipo.• Si existe riesgo de integración entre

subsistemas, se podría elegir el modelo en cascada.




4. Planificación.• El proyecto es revisado.• Se decide si continuar con otro ciclo en la

espiral.• Si se decide continuar se desarrollan

planes para la siguiente fase.


Un ciclo en espiral empieza con la elaboración de los

objetivos, como el rendimiento y la

funcionalidad. Se enumeran formas alternativas de

alcanzar estos objetivos y sus restricciones.

Cada alternativa se evalúa contra cada objetivo y se identifican las fuentes de

riesgo.

El siguiente paso es resolver el riesgo mediante

actividades como detallar más el análisis, la

construcción de prototipos y la simulación.

Una vez que se han analizado los riesgos se lleva

a cabo cierto desarrollo, seguido de una actividad de

planificación para la siguiente fase.




PUDS (Proceso Unificado de Desarrollo de Software)PROCESO RACIONAL UNIFICADO (PRU)



PUDS (Proceso Unificado de Desarrollo de Software)

Ivar Jacobson, Grady Booch y James Rumbaugh en su libro

Unified Process, analizan la necesidad de un proceso del

software “impulsado por el caso de uso, centrado en la

arquitectura, iterativo e incremental”.




▪El proceso unificado es un intento por obtener los

mejores rasgos y características de los modelos

tradicionales del proceso del software,

implementando los mejores principios del desarrollo

ágil.




▪Reconoce la importancia de la comunicación con el

cliente y los métodos directos para describir su punto

de vista respecto de un sistema (el caso de uso)




▪Hace énfasis en la importancia de la arquitectura

del software

▪Ayuda a que el arquitecto se centre en las metas

correctas: que sea comprensible, permita cambios

futuros y la reutilización




▪Sugiere un flujo del proceso iterativo e incremental




▪Historia.

▪Al principio de la década de 1990, James Rumbaugh

[Rum91], Grady Booch [Boo94] e Ivar Jacobson

[Jac92] comenzaron a trabajar en un “método

unificado”




▪Historia.

▪El resultado fue UML, lenguaje de modelado

unificado: Una notación robusta para el modelado y

desarrollo de sistemas orientados a objetos.




▪Historia.

▪UML brinda la tecnología necesaria para apoyar la

práctica de la ingeniería de software orientada a objetos,

pero no da la estructura del proceso que guíe a los

equipos del proyecto cuando aplican la tecnología




▪Historia:

▪En los siguientes años, Jacobson, Rumbaugh y Booch

desarrollaron el proceso unificado, estructura para la

ingeniería de software orientado a objetos que utiliza

UML.




▪Historia.

▪El proceso unificado (PU) y UML se usan en proyectos de

toda clase orientados a objetos. Y el modelo iterativo e

incremental puede y debe adaptarse para que satisfaga

necesidades específicas del proyecto.



PUDS (Proceso Unificado de Desarrollo de Software).

Fases




Fases✓Comunicación con el cliente y planeación.

✓Identifica los requerimientos del negocio.

✓Propone una arquitectura aproximada para el sistema y se desarrolla un plan para la naturaleza iterativa e incremental del proyecto en cuestión.




Fases

✓Los requerimientos fundamentales del negocio se describen por medio de un conjunto de casos de uso preliminares (detallan las características y funciones ).

✓La arquitectura son subsistemas principales con funciones y características




Fases

La planeación:

✓Identifica los recursos.

✓Evalúa los riesgos principales.

✓Define un programa de actividades.




Fases

La elaboración:

✓Mejora y amplía los casos de uso preliminares .

✓Aumenta la representación de la arquitectura para incluir cinco puntos de vista distintos del software:




Fases

La elaboración:

✓Los modelos del caso de uso, de requerimientos, del diseño, de la implementación y del despliegue

✓Al terminar la fase se revisa el plan.




Fases

La Construcción:

✓Se utiliza el modelo de arquitectura como entrada para desarrollar o adquirir los componentes del software que harán que cada caso de uso sea operativo para los usuarios finales.




Fases

La Construcción:

✓Se completan los modelos de requerimientos y diseño, para la versión final del incremento.

✓Se implementan en código fuente todas las características y funciones.




Fases

La Construcción:

✓Se implementan los componentes, se diseñan y efectúan pruebas unitarias.

✓Integración (ensamble de componentes y pruebas de integración.




Fases

La Construcción:

✓Se emplean casos de uso para obtener un grupo de pruebas de aceptación que se ejecutan antes de comenzar la siguiente fase del PU.




FasesLa Transición:

✓Entrega y retroalimentación.

✓Pruebas beta con usuarios finales.

✓Se generan manuales de usuario, guías de solución de problemas, etc.

✓Resultado: Producto utilizable que se lanza.




FasesLa Producción:

✓Producción=Despliegue.

✓Se vigila el uso que se da al software

✓Se da apoyo al ambiente de operación (infraestructura)

✓Reporte de defectos y solicitudes de cambio para su evaluación.




▪Es posible que al mismo tiempo que se llevan a cabo las

fases de construcción, transición y producción, comience

el trabajo sobre el siguiente incremento del software.

▪Esto significa que las cinco fases del PU no ocurren en

secuencia sino que concurren en forma escalonada.


Modelos de procesos de desarrollo de softwarePUDS (Proceso Unificado de Desarrollo de Software)


Gracias por su atención

Procesos para la Ingeniería de Software - uv.mx · PUDS (Proceso Unificado de Desarrollo de...

Documents

Transcript of Procesos para la Ingeniería de Software - uv.mx · PUDS (Proceso Unificado de Desarrollo de...