1 Ingenieria de Software

MEJORES PRACTICAS DE

DESARROLLO DE SOFTWARE

Semestre – 2014-I

Síntomas de la crisis de software

07/05/2014Prof. Ing. Christian Velásquez2

No son cubiertas las necesidades del negocio.

Requerimientos mal definidos.

Módulos que no se integran.

Difícil de mantener.

Tardío descubrimiento de defectos.

Baja calidad.

Usuario finales insatisfechos.

Bajo desempeño sobre altas cargas.

Esfuerzo no coordinado del equipo.

Liberaciones (Build-and-release issues).

Problemática del desarrollo de Software


MaximizarBeneficios

Retraso en proyectos Oportunidades perdidas Amenazas de la competencia

Conducirel equipo al

éxitoFechas ajustadas Recortes de presupuestos Pocos recursos.

CrearSoftware

de calidadReunionesCambiosRehacer trabajo hecho

Mejores Practicas en Desarrollo de Software


Desarrollo Iterativo

Gestión de Requisitos

Arquitecturas Basadas enComponentes

Modelado Visual (UML)

Verificación Continua de laCalidad

Gestión del Cambio

¿Qué son las Mejores Practicas?

Es un conjunto de principios,métodos y procesos quepermiten mejorar la calidad yproductividad del desarrollo desoftware.









Gestión del Cambio


Cada iteración produce, una versión ejecutable del sistema. Las primeras iteraciones atacan los riesgos mayores.

Se define y robustece la arquitectura de la aplicación en formatemprana.

Cada iteración permite la retroalimentación del usuario.

Se prueba desde el principio, verificando desempeño yescalabilidad.

Entregables bien definidos y delimitados permiten tener metas acorto plazo y no una sola meta a largo plazo.

El progreso se mide mediante la evaluación de las

implementaciones (mediciones reales).07/05/2014Prof. Ing. Christian Velásquez7

Iteración 1 Iteración 2 Iteración… n

Tiempo

DC

I T

RD

CI

T

R RD

CI

T

Los retos del Líder del Proyecto

Dificultad para conocer el estado real de los proyectos

Falta de comunicación con el equipo y poca eficiencia En las juntas de equipo sólo se recopila información y no se resuelven

problemas


Múltiples proyectos, prioridades y procesos.

??

?? ??

Líder del proyecto

Perfil de riesgo de un desarrollo iterativo


Cascada

Iterativo

Riesgo

Niveles de estimados


Variación deN1

+/- 50% o más

N2

Variación de

+/- 30%

N3

Variación de

+/- 10%








Gestión del Cambio

Erase un proyecto

Ejemplo: Diseñar un columpio


Como lo solicito

el cliente

Continuación: Erase un proyecto

Lo que aparece en la definición del problema


Como lo diseño

el arquitecto


Lo que aparece en la especificación


Lo que especifico

el ingeniero.


Lo que aparece en el diseño.


Como lo solicito

compras


Lo que aparece en la implementación.


Como lo construyo


Lo que se entrega al cliente.


Como quedo

parche


Lo que el cliente quería


Lo que realmente

se necesitaba

Continuación: Erase un proyecto…………


el arquitecto el ingeniero compras

Como lo

solicitóel cliente

Como lo diseñó Como lo especificó Como lo solicitó

Como lo construyó Como quedó LO QUE REALMENTE

el contratista finalmente SE NECESITABA

¿Por qué falla un Proyecto?

Entre otros:

1. El usuario no sabe lo que quiere (¿o nosotros no loentendemos?).

2. Requerimientos y especificaciones incompletos.

3. Cambio en los requerimientos y especificaciones.

4. Carencia de participación por parte del usuario.

5. No existe documentación.

6. Falta de una metodología para la gestión de

requisitos.


¿Qué son los requisitos?

Un requisito es una propiedad/característica que debe ser

mostrada por el sistema que se esté construyendo.

Característica que debe incluirse en un sistema.


Gestión de requisitos implica………

Asegurarse de:

Resolver el problema correcto.

Construir el sistema apropiado

Fases de gestión de requisitos:

Identificación.

Organización (estructura y rastreabilidad).

Documentación (especificación).

Validación de requisitos.

Gestión: del cambio en requisitos, de los atributos, de la rastreabilidad.


Técnicas de trabajo con usuarios

Talleres de requerimientos

Entrevistas.

Cuestionarios.

Prototipos.

Juego de roles

Análisis de regulaciones y procesos actuales.

Lluvia de ideas


Compartir los requisitos

Cada uno de los participantes del proyecto requiere teneracceso a los requisitos.


Desarrolladores y diseñadores

Aseguramiento de la Calidad

Req

Analistas Usuarios yClientes

`GerentesLíder de Proyecto

Matriz de rastreabilidad

Muestra las dependencias entre requerimientos









Gestión del Cambio

Evolución típica de una aplicación…


arreglo A790

arreglo A812

nuevo requerimiento

Arquitectura 1.0V 1.2V 1.2a

Resistencia al cambio


arreglo A790

arreglo A812

nuevo requerimiento

ArquitectuV 1.2a

V1.2

a1.0

¿Por qué utilizar arquitecturas de

componentes?

La clave del éxito es crear

arquitecturas:

Duraderas

Flexibles al cambio

Basadas en componentes.

La Arquitectura es el20% del esfuerzo que produce

el 80% más importante


Desarrollar:

• Con Reuso

• Para Reuso

Activos de software reutilizable

Reuso de todo “artefacto” Arquitectura

Casos de Uso, Análisis, Diseño, Implementación y

Pruebas

Modelos de interfaces, modelos de negocio, patrones arquitectónicos, etc.

Reuso de tecnología Proceso y automatización

Proyectos

Guías


Ejemplo: Arquitectura basada en

componentes


productos

Producto Licencia

CRMDatabase

Comprado

Existente

Nuevo

Cliente

Mecanismos de interfaces

Funciones de licenciamiento

Funciones de cliente/

Arquitectura de los Sistemas Corporativos

3-capas


PRESENTACIÓN LÓGICA NEGOCIO INTEGRACIÓN

Interfaces de usuarios

Bases de datos

Transactions procesing monitors

J2EE


EJB

CLIENTE SERVIDOR

JDBC

INTEGRACIÓN

Dispositivo ClienteHTTP

Web ServerHTML,XML,WML

Contenedor Web

JSP

Servicios J2EE

Servicios J2SE

EJB ServerDispositivo Cliente

HTTP

Contenedor de EJB

EJB

Servicios J2EE

Servicios J2SE

HTTP

Dispositivo Cliente

Contenedor deAplicaciónes Cliente

Servicios J2EE

Servicios J2SE PRESENTACIÓN LÓGICA DE NEGOCIO

Aplicación

Cliente

CORBA

Java

Application

Message

Queue

Directory

Services

Contenedor deApplets

Applet

Servicios J2SE

Servelet Mail ServerJavaMail

JNDI

JMS

RMI

RMI








Gestión del Cambio

¿Qué es UML?

UML es el lenguaje

estándar para visualizar, especificar, construir y documentar los artefactos de una

aplicación software


UML: El lenguaje para el desarrollo de

software


UML


Modelado deRequisitos Modelado de

AplicacionesModeladoWeb Modelado

Datosde

Modeladode Negocio

Un único lenguaje para todo el equipo

Diseño y construcción del sistema desde

una herramienta única.


Analista deNegocio

Desarrollador

Arquitecto Diseñador DB

Una Herramienta para todo el equipo.








Gestión del Cambio

Verificación continua de la calidad


Es de 100 a 1000 veces más costoso encontrar y

reparar los problemas del software después del

desarrollo

to

to

to

de

de

de

reparar

perder

perder

oportunidades.

clientesCosto

Concepción Elaboración Construcción Transición

Cos

Cos

Cos

el software.

Causas principales de la baja calidad del

software

Probar Software es muy difícil

Cambios en los requerimientos

Falta de un proceso sistemáticode pruebas.

Mala comunicación entremiembros del equipo.


Cada actividad incluye su verificación


Todo aquello que hagas, no lo habrás terminado hasta

que hayas verificado que hiciste lo que debías de hacer.

EjecuciónActividad

Acción Verificación

Plan de actividades de aseguramiento de la

calidad

Conjunto de actividades que serán ejecutadas paragenerar confianza en que el producto cumplirá con losrequerimientos y el proceso es efectivo.


Producto

Revisiones

Requisitos

Cliente Validaciones

VerificacionesNecesidades

Jerarquía de planes


Plan de Desarrollo

Plan de Aseguramiento de la Calidad

Plan de Pruebas (de software)

Implementación. Probar en cada iteración….


Pruebas Manuales

Re-ejecutar

primeras

pruebas y ...

Tiempo

Build 1

Implementación. Pruebas de regresión


Tiempo

Build 1 Build 2 Build 3, 4, 5, 6, 7, 8 Build 9 Build 10

Pru

eb

as Difícil de forma

manual!

Pruebas Manuales

...las

nuevas

...más

tiempo

pruebas...








Gestión del Cambio

¡Cambiar!

¿Qué es lo primero que se le viene a la mente?


En el desarrollo de software,

¡Los cambios ocurren!RequerimientosModelos

Especificaciones de

integraciónCódigoPruebasCriterios de liberaciónPlataforma de distribuciónErrores

vez!

¡Todo el tiempo!

Factores que dificultan la gestión del

cambio

Complejidad en el entorno del proyecto.

Tamaño del equipo. Interdependencia entre componentes. Distribución geográfica.

Complejidad del sistema de Software.

Tamaño del producto. Complejidad de la arquitectura. Número de plataformas.

Aparición de nuevas tecnologías y requisitos.


El proceso de Cambio: La Solución.


Administración de configuracióny cambios

Órdenes de Trabajo

CalidadPetición de Administracióndelcambios y de

productoarreglo de configuraciónFallas reportadas defectos

Petición de nuevascaracterísticas

Proceso basado en actividades


ffB!u862 sut gNew B

i actBNuens

Tan

1ugNsew w dgedge

9 BBugug

GrraapphhiiccssGUIGUIe

isddgetget BBugug NNees411 NN

oro gMMFix

bb

5522 FFiixx558181an eTTwwrranBButt

New widgetutto Bug 953w Script

New wi Bugt 952wiidget tNew

New w New ScriptMS Windows 2000 New widget

Bug 400New Script N on BugBugs 95

950

New ListBug 396

Bug 9

New DB support Update Doc Bug Fix 196

Bug 951

Bug 396 Bug 952

Controlar los cambios del software


Special Promo

Líder deProyecto

Requerimientos Diseño Desarrollo Pruebas

3. Add Use Case

Document

Requirement

Requirements

1. Defi

2. Define GUI

To

1. Test Promo

2. Verify Bug 467

3. Test GUI applet

Deleteitems

Cancel Order

Special Promo

Test Scripts

To Do ListDo List

ne Promo

hello.c foo.c

Rose models

Code Content

1. Special Promo2. Add copyright

3. Update price

To Do List

4. Fix Bug 671

2. Special Promo

3. Fix Bug 829

To Do List

Orden de Trabajo

Administración de la configuración y

cambios: Mediciones

“¿Los defectos de alto grado se lograron resolver en estebuild?”

“¿Cuáles cambios faltan por resolver?”


Métricas revela el estado del proyecto en cualquier momento .

Lider del proyecto

Gestión del trabajo en paralelo

Líneas de desarrollo y de mantenimiento.

Concurrencia en el desarrollo.

Particularización de

componentes.

Distintas versiones en producción.


Administración de Configuración y Cambios

Permitir, controlar y monitorear cambios para habilitar un

desarrollo iterativo. Controlar todos los artefactos de software - modelos, código,documentos, etc. Administrar todas las versiones, con integración automática alos cambios realizados al software. Establecer espacios de trabajo seguros y aislados para cadadesarrollador. Contar con métricas de estado.


¡ Saber qué está pasando en el equipo y en el proyecto !

Documents

1 Ingenieria de Software