Clase DSW 3S

DESARROLLO
DE
SOFTWARE
2
La importancia de la informacin como recurso
estratgico que ayuda a generar ventajas competitivas
para las empresas, se tiende a construir sistemas
cada vez ms grandes y complejos donde intervienen
equipos de trabajo formados por numerosas personas
con distintas funciones y roles.
Lleva a definir mecanismos que nos ayuden a
administrar esos grandes proyectos: programar las
actividades en tiempo y forma, coordinar las
actividades de cada integrante del equipo y entre
ellos, y ofrecer criterios para permitir un control y
medicin de estas actividades.
Desarrollo de Software
3
Un alto porcentaje de los sistemas fracasan por no
contar con un adecuado proceso de desarrollo, o por
su utilizacin inapropiada. Muchos desarrolladores se
equivocan porque piensan que el desarrollo de
software comienza con la programacin en un
lenguaje determinado, y ah caen en una de las
causantes ms importantes de fracaso del sistema.
Sea cual fuese el tamao del sistema, es necesario
que siempre nos apoyemos en un proceso de anlisis
y diseo como el que vemos a lo largo de la materia.
4
Cuando una empresa se plantea la construccin de un
nuevo software aparecen en la cabeza del lder del
proyecto distintas consideraciones a tener en cuenta
que sern crticas, pues de stas depender el xito o
el fracaso del proyecto de desarrollo:
Construir un software que cumpla con los requisitos
previos planteados.
Construir un software que haga correctamente lo que se
pidi.
Lograr un software que pueda adaptarse a los continuos
cambios de toda organizacin actual.
Cumplir con los tiempos pactados de finalizacin del
proyecto.
Respetar los costos estimados en principio.
5
No tener esto en mente desde un principio y no darle
la importancia que merece nos puede ocasionar
innumerables conflictos en las distintas etapas del
desarrollo.
Cules son las causas que habitualmente
generan este tipo de conflictos?
No hay tiempo de recoger datos histricos.
Los proyectos se llevan a cabo con descripciones
vagas y con poca comunicacin con los usuarios
finales. De esta forma no se recogen realmente las
necesidades de los mismos.
6
Muchas veces slo se analizan las necesidades de
los usuarios finales, cayendo as en sus vicios, y
de esta forma nos desviamos del objetivo final de
lograr un software que cumpla con las necesidades
de la organizacin.
Hay escaso tiempo y recursos dedicados a analizar
los requerimientos y necesidades, y a documentar
las mismas para utilizarlas como gua a lo largo de
todo el proceso de desarrollo del software.
No se utiliza una metodologa de desarrollo
adecuada que nos permita lograr una aplicacin
que en el futuro sea adaptable a los cambios y
nuevas necesidades organizacionales.
7
Hay veces que para adaptarse a los tiempos que se
exigen para la entrega de una solucin no se utiliza
ninguna metodologa de desarrollo y se arranca
directamente con la programacin de la aplicacin.
Existe la dificultad que afrontan los desarrolladores
para coordinar las mltiples cadenas de trabajo de un
gran proyecto de software.
La solucin de software obtenida posee una calidad
cuestionable, funciona sin importar si lo hace de la
mejor manera, y no posee una definicin de
estndares de calidad, lo cual nos lleva a un software
difcil de mantener.
8
El desarrollo del Software es la aplicacin de principios
cientficos al diseo, construccin y mantenimiento del
software.
Cules son los principios cientficos en los que se basa
la ingeniera del software?
De no existir los principios cientficos la actividad de
desarrollar software estara ms cerca a la artesana que
a la ingeniera, puesto que lo artesanal es en general
algo nico y su utilidad depende de la habilidad del
artesano.
9
En qu ciencia se basa la actividad de construir
software?
La necesidad de dar respuesta a esta pregunta se
relaciona con que se pretende producir software como
producto industrial.
Necesidad: producir software como objeto ingenieril, con
caractersticas finales de confiabilidad y de
reproducibilidad de los procedimientos utilizados para el
desarrollo. Se pretende la existencia de un proceso de
desarrollo de software que nos permita cubrir la
necesidad planteada.
10
Qu es el ciclo de vida?
El trmino ciclo de vida se refiere a la idea de que un
producto de software es el resultado de un proceso de
desarrollo que se divide en fases.
Podemos definir el trmino ciclo de vida como la
actividad de producir y mantener Sistemas
Informticos.
11
Sus funciones son las siguientes:
1- Establecer un orden en el que se:
especifica
realiza un prototipo
disea
implementa
prueba
mantiene
2- Determinar los criterios para pasar de una fase a otra.
12
El ciclo de vida est de acuerdo con la metodologa
que se utilice. Hay metodologas en donde el ciclo de
vida tiene un comienzo, se pasa por las distintas
etapas antes mencionadas y llega a un fin.
En otras metodologas el ciclo de vida esta formado
por diversas iteraciones, cada una recorre todas las
etapas y se van logrando versiones intermedias del
producto. Luego se sigue con otra iteracin que pasa
nuevamente por todas las etapas y se sigue as
avanzando hasta que se logra el producto completo
finalizado. En la definicin del plan del proyecto el
modelo de ciclo de vida seleccionado influye en el
xito del proyecto como cualquier otra decisin de
planificacin que se tome.
13
El modelo de ciclo de vida puede orientar su
proyecto y ayudarlo a asegurar que cada paso se
acerca ms a la consecucin del objetivo.
Dependiendo del ciclo de vida que se seleccione
se puede:
Aumentar la velocidad del desarrollo
Mejorar la calidad
Mejorar el control
Mejorar el seguimiento del proyecto
Minimizar gastos
Minimizar riesgos
Mejorar las relaciones con el cliente
14
Aspectos del proceso de desarrollo
Para llevar a cabo un proceso de desarrollo
necesitamos:
Modelo de proceso (ciclo de vida)
Orden de las fases en el desarrollo de software
Criterios de transicin entre las fases
Metodologa de software
La navegacin se hace a travs de cada fase
Notacin de software
Representacin de elementos utilizados en cada fase
Taxonoma de modelos de proceso
Enfoque secuencial
Nunca retorna a un paso completado.
Slo prctico para proyectos muy pequeos, no
crticos.
15
Enfoque iterativo
Puede retornar a cualquier paso ya completado para
introducir un cambio, propagando su efecto hacia
delante a lo largo del ciclo de vida.
La mayora de los modelos de ciclo de vida son
iterativos.
Mecanismo recursivo
Todo el enfoque puede ser reaplicado a los productos
finales.
Todos los enfoques recursivos del ciclo de vida son
iterativos, pero no todos los enfoques iterativos son
recursivos.
Metodologa de software
Anlisis y diseo estructurados
Descomposicin funcional.
Orientado a flujos de datos.
16
Modelo orientado a datos
Originado en la comunidad de bases de datos.
Se concentra en la informacin.
Orientacin a objetos
Sita el dominio de un problema y su solucin lgica
dentro de la perspectiva de los objetos (cosas, conceptos o
entidades).
Notaciones de software
Diagrama de flujo de datos
Muestra relaciones funcionales.
Grficos cuyos nodos son procesos y las lneas son flujos
de datos.
17
Diagrama de estado
Muestra aspectos dinmicos.
Grficos cuyos nodos son estados y sus lneas son
transiciones entre ellos causando eventos.
Diagramas de entidad-relacin
Muestra la estructura esttica de los componentes de
sistema y sus relaciones.
Grficos cuyos nodos son entidades y sus lneas son
relaciones entre ellas.
Diagrama de objetos
Grficos cuyos nodos son clases de objetos y sus arcos
son relaciones entre las clases.
Diagrama de clases
Indica las caractersticas relevantes de una clase singular.
18
Cascada
Sirve de base para otros modelos.
Es una secuencia ordenada de pasos en la cual se
realiza una revisin al finalizar cada etapa para
determinar si se pasa a la siguiente.
Si no est listo permanece en la etapa actual hasta
que est completa.
El producto final de los trabajos que se pasan de una
etapa a otra son documentos.
Esta es una de las metodologas ms tradicionales y
utilizadas
Es la mejor forma de empezar a entender un sistema
a partir de los servicios o funciones que ofrece a su
entorno, independientemente de los objetos que
interactan dentro del sistema para proveerlos.
Modelos de Procesos de Software
(Ciclo de vida SW)
19
Cascada
Es bueno cuando:
Se tiene definicin estable del producto
El proyecto de anlisis es relativamente pequeo.
Desventajas
Dificultad de especificar claramente los requerimientos al
comienzo del proyecto, por lo cual generalmente se debe
volver atrs
Genera pocos signos visibles de progreso hasta el final
Los usuarios no pueden ir viendo el avance real del
proyecto, recin cuando ste est terminado pueden ver el
proyecto funcionando, lo cual puede generar a esa altura
disconformismos que son muy difciles de corregir,
La vuelta atrs es posible pero complicada de realizar
debido a que debemos cambiar muchas cosas para lograrla.
(Ciclo de vida SW)
20
Cascada
(Ciclo de vida SW)
Concepto del SW
Anlisis de
Requerimiento
Diseo Global
Diseo Detallado
Prueba del Sistema
Codificacin y
Depuracin
21
Incremental
Modelo se basa en realizar entregas frecuentes de
software operativo a los clientes.
Al realizar entregas semanales, quincenales o mensuales
del producto, la comunicacin es ms efectiva, se reduce el
riesgo dividiendo el proyecto en una serie de sub-proyectos
ms pequeos aumentando la visibilidad del progreso,
proporcionando mdulos terminados y operativos de un
sistema grande antes de tener operativo el sistema
completo.
Tenemos una mayor capacidad para hacer modificaciones
a mitad de camino porque el sistema est listo para ser
entregado muchas veces durante el desarrollo.
(Ciclo de vida SW)
22
Incremental
Cada incremento pas por las distintas fases del desarrollo
de software, con lo cual en las primeras etapas podemos
hacer un anlisis y mitigacin de riesgos mucho ms
efectiva que en un ciclo en cascada, ya que no tenemos
que esperar hasta las fases finales para encontrar, por
ejemplo, un problema de implementacin que requerira
que hagamos gran cantidad de modificaciones sobre lo que
ya hemos realizado.
Al ir avanzando de esta forma vamos primero armando el
esqueleto de la aplicacin y poco a poco lo vamos
rellenando hasta lograr una solucin completa.
(Ciclo de vida SW)
23
Espiral
Modelo que divide el proyecto en sub-proyectos ms
pequeos o mini proyectos, cada uno de los cuales se
enfoca en controlar uno o ms riesgos determinados.
Es un modelo centrado en los riesgos, los que comprenden
riesgos en los requerimientos, en la tecnologa, en la
arquitectura, etc..
Es un modelo ideal cuando:
Existe poca identificacin de los requerimientos.
Hay riesgos importantes que deben ser tenidos en cuenta
desde el principio, ya que podran poner en peligro el
proyecto, tales como tecnologa poco conocida u obsoleta,
polticas no lineadas con los objetivos de la organizacin, etc..
(Ciclo de vida SW)
24
Espiral
Modelo presenta inconvenientes que deben ser
manejados:
Necesita una planificacin adecuada.
Se necesita tiempo considerable para la gestin del
proyecto.
Requiere suficiente preparacin de los recursos humanos
para la gestin, ya que su implementacin no es sencilla.
(Ciclo de vida SW)
25
Espiral
El trabajo se inicia con la identificacin y anlisis de los
riesgos y luego se crea un plan para controlarlos.
Una vez hecho esto se avanza a la prxima iteracin.
El hito que permite el paso a la siguiente iteracin es el
manejo de los riesgos en un nivel que se considere
aceptable para el proyecto.
Las primeras iteraciones son las menos costosas, a
medida que nos alejamos del centro de la espiral los
costos aumentan y los riegos disminuyen, es decir, que
mientras ms tiempo y dinero se invierta en el desarrollo
del proyecto, mayor cantidad de riesgos estarn
controlados.
(Ciclo de vida SW)
26
Espiral
Cada iteracin implica realizar los siguientes pasos:
Definir objetivos, alternativas y lmites.
Identificar y controlar riesgos.
Evaluar alternativas.
Realizar las entregas de la iteracin.
Planificar la prxima iteracin.
Fijar el enfoque de la siguiente iteracin.
(Ciclo de vida SW)
27
Espiral
(Ciclo de vida SW)
28
Prototipo evolutivo
Este modelo comienza por desarrollar los aspectos visibles del
sistema, se presenta el prototipo al cliente, se logra el acuerdo
con el mismo y contina el desarrollo.
Es til cuando:
no es posible definir con claridad los requerimientos debido a que
cambian reiteradamente o no existe acuerdo con los usuarios.
el proyecto debe mostrar rpidamente y al poco tiempo signos
visibles de avance.
se estima que se debern realizar modificaciones importantes en la
mitad del camino de desarrollo del proyecto.
Presenta inconvenientes tales como:
no se conoce el tiempo que tomar terminar el producto.
no se sabe cuntas iteraciones se debern realizar.
no est ligado a una planificacin rigurosa.
(Ciclo de vida SW)
29
Prototipo evolutivo
(Ciclo de vida SW)
30
Definicin de RAD
Proceso de desarrollo de software que permite
construir sistemas utilizables en poco tiempo,
normalmente de 60 a 90 das, frecuentemente
con algunas concesiones.
Principios tras la definicin
En ciertas situaciones, una solucin utilizable al
80% puede producirse en el 20% de tiempo que
se hubiera requerido para la solucin completa.
En ciertas situaciones, los requisitos de negocio
de un sistema pueden satisfacerse aun cuando
algunos de sus requisitos operacionales no se
satisfagan.
En ciertas situaciones, la aceptabilidad de un
sistema puede determinarse en base a un
conjunto mnimo de requisitos consensados en
lugar de la totalidad de los requisitos.
32
Problemas atendidos por RAD
Con los mtodos convencionales pasa un gran
lapso de tiempo antes de que el cliente vea
resultados.
Con los mtodos convencionales el desarrollo
llega a tardar tanto que para cuando el sistema
est listo para utilizarse los procesos del cliente
han cambiado radicalmente.
Con los mtodos convencionales no hay nada
hasta que el 100% del proceso de desarrollo se
ha realizado, entonces se entrega el 100% del
software.
33
Por qu usar RAD?
Malas razones
Prevenir presupuestos rebasados (RAD necesita
un equipo disciplinado en manejo de costos).
Prevenir incumplimiento de fechas (RAD necesita
un equipo disciplinado en manejo de tiempo).
Buenas razones
Convergir tempranamente en un diseo aceptable
para el cliente y posible para los desarrolladores.
Limitar la exposicin del proyecto a las fuerzas de
cambio.
Ahorrar tiempo de desarrollo, posiblemente a
expensas de dinero o de calidad del producto.
34
Calendario vs Presupuesto vs Calidad
Las concesiones determinan el ritmo de
desarrollo.
Negociar algo que no sea el calendario de
trabajo.
Una o ms metas pueden ser inalcanzables.
35
desarrollo
Desarrollo eficiente: equilibra calendario,
presupuesto y calidad.
Calendario: ms rpido que el promedio
Presupuesto: cuesta menos que el promedio
Calidad: mejor calidad que el promedio
RAD razonable: inclina la balanza hacia el tiempo
ms corto.
Calendario: mucho ms rpido que el promedio
Presupuesto: cuesta poco menos que el promedio
Calidad: calidad poco mejor que el promedio
36
desarrollo
RAD a fondo: "programar a lo bestia".
Calendario: ms corto posible
Presupuesto: cuesta ms que el promedio
Calidad: menor calidad que el promedio
37
Negociar algo que no sea el programa de
trabajo
RAD tiene una buena posibilidad de xito si el
cliente est dispuesto a negociar precio o calidad.
RAD tiene una mejor posibilidad de xito si el
cliente est dispuesto a negociar precio y calidad.
Negociar la calidad no significa una mayor tasa
de fallas sino un producto con menos funciones o
menos eficiente.
38
Una o ms metas pueden ser inalcanzables
El menor nmero posible de fallas: los
desarrolladores pueden no tener la posibilidad de
corregir fallas en algunos componentes de
terceros.
Nivel ms alto de satisfaccin del cliente: algunos
requisitos secundarios pueden ser sacrificados
en aras del calendario.
El menor costo de desarrollo: comprar
herramientas y componentes puede ser ms caro
que desarrollarlos.
39
Caractersticas de RAD
Equipos Hbridos
Herramientas Especializadas
"Timeboxing"
Prototipos Iterativos y Evolucionarios.
40
Equipos Hbridos
Equipos compuestos por alrededor de seis
personas, incluyendo desarrolladores y usuarios
de tiempo completo del sistema as como
aquellas personas involucradas con los
requisitos.
Los desarrolladores de RAD deben ser
"renacentistas": analistas, diseadores y
programadores en uno.
41
Herramientas Especializadas
Desarrollo "visual"
Creacin de prototipos falsos (simulacin pura)
Creacin de prototipos funcionales
Mltiples lenguajes
Calendario grupal
Herramientas colaborativas y de trabajo en
equipo
Componentes reusables
Interfaces estndares (API)
Control de versiones
42
"Timeboxing
Las funciones secundarias son eliminadas como
sea necesario para cumplir con el calendario.
43
Prototipos Iterativos y Evolucionarios
Reunin JAD (Joint Application Development):
Se reunen los usuarios finales y los desarrolladores.
Lluvia de ideas para obtener un borrador inicial de los
requisitos.
Iterar hasta acabar:
Los desarrolladores construyen y depuran el prototipo
basado en los requisitos actuales.
Los diseadores revisan el prototipo.
Los clientes prueban el prototipo, depuran los requisitos.
Los clientes y desarrolladores se reunen para revisar
juntos el producto, refinar los requisitos y generar
solicitudes de cambios.
44
Prototipos Iterativos y Evolucionarios
Los cambios para los que no hay tiempo no se realizan.
Los requisitos secundarios se eliminan si es necesario
para cumplir el calendario.
Notas:
Cada iteracin dura entre un da y tres semanas.
Reuniones de 2 horas con facilitador que mantiene
enfocado al grupo.
45
El Facilitador
Mantiene al grupo enfocado: Tiene claras las
metas sobre la informacin que se necesita
recabar.
Prepara una agenda de asuntos antes de la
reunin.
Asegura que la discusin adecuada cubra cada
asunto.
Asegura que todos participen.
Escribe un reporte al final de la reunin.
46
Restricciones Importantes
El "ajuste a un propsito de negocios" tiene que ser
el criterio de aceptacin de los entregables.
Todas las areas que pueden afectar los requisitos
debe estar involucradas a lo largo del proceso.
Clientes, desarrolladores y gerencia deben aceptar
entregables informales:
Prototipos en papel en lugar de sistemas a gran escala.
Notas de las reuniones con usuarios en lugar de
documentos de requisitos formales.
Notas de las reuniones de los diseadores en lugar de
documentos de diseo formales.
Principio: crear el mnimo de documentacin necesaria
para facilitar el desarrollo futuro y el mantenimiento.
47
Restricciones Importantes
El equipo de desarrollo tiene que poder tomar
decisiones tradicionalmente dejadas a la gerencia.
La escala de tiempo de punta a punta tiene que ser
de seis meses o menos.
La iteracin debe usarse de manera que se
converja a una solucin de negocio aceptable.
Los prototipos tienen que incorporar rpidamente
los requisitos en evolucin, en tiempo real, y lograr
consenso pronto.
48
RAD tiende a funcionar cuando:
La aplicacin funcionar de manera independiente.
Se pueden usar mayormente bibliotecas existentes.
Desempeo no crtico.
Distribucin limitada, interna o vertical.
Alcance del proyecto limitado.
Confiabilidad no crtica.
El sistema puede dividirse en muchos mdulos
independientes.
49
RAD tiende a funcionar cuando:
El producto est dirigido a un mercado altamente
especializado.
El proyecto cuenta con fuertes limitantes de tiempos
parciales (timeboxes).
La tecnologa requerida tiene ms de un ao en el
mercado
50
RAD tiende a fallar cuando:
La aplicacin debe interoperar con sistemas
existentes.
Existen pocos componentes reutilizables.
Alto desempeo crtico.
El desarrollo no puede aprovechar herramientas de
alto nivel.
Distribucin amplia, horizontal o masiva.
RAD se convierta en QADAD (Quick And Dirty
Application Development).
51
RAD tiende a fallar cuando:
Mtodos RAD para desarrollar sistemas operativos
(confiabilidad demasiado alta) o juegos (desempeo
demasiado alto).
Riesgos tcnicos de tecnologa de punta.
El producto pone en riesgo la misin o la vida.
El producto no puede ser modularizado.
52
Ventajas de RAD
Comprar puede ahorrar dinero en comparacin con
construir.
Los entregables pueden ser facilmente trasladados a
otra plataforma.
El desarrollo se realiza a un nivel de abstraccin
mayor.
Visibilidad temprana.
Mayor flexibilidad.
53
Ventajas de RAD
Menor codificacin manual.
Mayor involucramiento de los usuarios.
Posiblemente menos fallas.
Posiblemente menor costo.
Ciclos de desarrollo ms pequeos.
Interfaz grfica estndar.
54
Desventajas de RAD
Comprar puede ser ms caro que construir.
Costo de herramientas integradas y equipo
necesario.
Progreso ms difcil de medir.
Menos eficiente.
Menor precisin cientfica.
Riesgo de revertirse a las prcticas sin control de
antao.
Ms fallas (por sndrome de "codificar a lo bestia").
55
Desventajas de RAD
Prototipos pueden no escalar, un problema
maysculo.
Funciones reducidas (por "timeboxing").
Dependencia en componentes de terceros:
funcionalidad de ms o de menos, problemas
legales.
Requisitos que no convergen.
56
Resumen
"Con el fin de asegurar gran interaccin, los proyectos
se disean con calendarios fijos y se sacrifica la
funcionalidad si es necesario. Esto permite que el
equipo de desarrollo se enfoque en las piezas de
funcionalidad que tienen el mayor valor de negocio y
en entregar dicha funcionalidad rpidamente. Los
cambios son frecuentemente la razn de los retrasos
en el desarrollo de una aplicacin. En los largos
procesos lineales de desarrollo, los cambios en los
requisitos funcionales o en el alcance del proyecto,
particularmente cuando gran cantidad de tiempo se ha
invertido en la planeacin, diseo, desarrollo
57
Resumen
y pruebas, provocan que se pierdan meses de trabajo
y se incurra en grandes gastos por rediseo y
redesarrollo. RAD ataca la infiltracin de cambios de
alcance y requisitos al limitar la exposicin del
proyecto al cambio, acortando el ciclo de desarrollo y
limitando el costo de los cambios al incorporarlos
desde el inicio, antes de que grandes inversiones se
hayan hecho en desarrollo y pruebas."
58
FIN Unidad

Clase DSW 3S

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Clase DSW 3S

Uploaded by

Copyright:

Available Formats

DESARROLLO

You might also like