Documente Academic
Documente Profesional
Documente Cultură
Metodologa de
desarrollo de software
CURSO:
SECCIN:
Junn Per
2016
INTRODUCCIN
Dentro del desarrollo de software y a la altiva necesidad de que los
proyectos lleguen al xito y obtener un producto de gran valor para
nuestros clientes, generan grandes cambios en las metodologas
adoptadas por los equipos para cumplir sus objetivos, puesto que,
unas se adaptan mejor que otras, al contexto del proyecto brindando
mejores ventajas.
Es por eso de la importancia de una metodologa robusta que
ajustada en un equipo cumpla con sus metas, y satisfaga mas all de
las necesidades definidas al inicio del proyecto.
El xito del producto depende en gran parte de la metodologa
escogida por el equipo, ya sea tradicional o gil, donde los equipos
maximicen su potencial, aumenten la calidad del producto con los
recursos y tiempos establecidos.
Una metodologa es un conjunto de procedimientos, tcnicas,
herramientas y un soporte documental que ayuda a los
desarrolladores a realizar un nuevo software. Puede seguir uno o
varios modelos de ciclo de vida, es decir, el ciclo de vida indica qu es
lo que hay que obtener a lo largo del desarrollo del proyecto pero no
cmo hacerlo. La metodologa indica cmo hay que obtener los
distintos productos parciales y finales. Finalmente depender de la
metodologa utilizada los productos del proyecto, por esta razn es
necesario, conoces a fondo cada una de ellas y poder diferenciar
entre una y otra, para de este modo saber elegir la correcta en el
momento de desarrollar un nuevo software, de otra manera el
producto no ser el mejor e incluso puede ser intil
PARADIGMA
1. Definicin
Un paradigma de programacin indica un mtodo de realizar
cmputos y la manera en que se deben estructurar y organizar las
tareas que debe llevar a cabo un programa
Los paradigmas fundamentales estn asociados a determinados
modelos de cmputo.
Tambin se asocian a un determinado estilo de programacin
Los lenguajes de programacin suelen implementar, a menudo de
forma parcial, varios paradigmas.
1.1.
Paradigma
tecnolgica
de
programacin: es
adoptada
por
una
propuesta
una
ncleo
comunidad
central
es
debe
suponer
consecuentemente
un
avance
en
su
momento
de
definicin.
Es
un
estilo
de
programacin empleado.
Un paradigma de programacin est delimitado en el tiempo en
cuanto a aceptacin y uso, porque nuevos paradigmas aportan
nuevas o mejores soluciones que la sustituyen parcial o totalmente.
grandes
desarrollos
tuvieran
problemas
de
fiabilidad,
de
lenguajes
puros
de
este
paradigma
seran
el C, BASIC o Pascal.
2.2. Programacin orientada a objetos: Est basada en el
imperativo, pero encapsula elementos denominados objetos que
incluyen tanto variables como funciones. Est representado por C+
+, C# o Java, entre otros, pero el ms representativo sera
el Smalltalk que est completamente orientado a objetos.
problemas
en
partes
pequeas
para
analizarlos
dirigida
por
eventos:
la programacin
la programacin
Unos
de
los
lgica,
la
primeros
combinacin
lenguajes
lgico-
funcionales
funcional:
basada
en
la
definicin
los
Paradigma
declarativo
Paradigma
imperativo
Orientado
a objetos
Funcion
Lgic
Orientado
al
o
a
METODOLOGA
enventos
Base de
datos
1. Definicin:
Las metodologas son las teoras del aprendizaje que orientan el
mtodo,
entre
ellas, la
teora
constructivista,
conductual,
KAPLAN,
la
metodologa es
el
estudio,
descripcin,
2. Metodologa de Programacin
Una metodologa de programacin es un conjunto o sistema de
mtodos, principios y reglas que permiten enfrentar de manera
sistemtica el desarrollo de un programa que resuelve un
problema
algortmico. Estas
metodologas
generalmente
se
Esquema.
Procesos de entrada
Proceso de datos
Procesos de salida
METODOLOGIA SSADM
flexibilidad
en
herramientas
tcnicas
de
implementacin.
SSADM proporciona un conjunto de procedimientos para llevar a cabo
el anlisis y diseo, pero no cubre aspectos como la planificacin
estratgica ni entra en la construccin del cdigo.
Los aspectos del SSADM son:
nfasis en los usuarios: requisitos y participacin
flexibilidad
en
herramientas
tcnicas
de
implementacion.
El SSADM no cubre aspectos como la planificacin estratgica ni la
construccin del cdigo.
3. Procesos del ciclo de desarrollo DSDM
El ciclo de desarrollo de DSDM est compuesto de 5 fases,
precedidas de un pre-proyecto y un post-proyecto.
Pre-proyecto
Estudio de viabilidad
Estudio de negocio
Iteracin de modelado funcional
Iteracin de diseo y desarrollo
Implementacin
Post-desarrollo
4. Anlisis de sistemas estructurado y mtodo de diseo
(SSADM)
Originalmente lanzada como metodologa es un enfoque de
sistemas para el anlisis y diseo de sistemas de informacin.
SSADM fue producida para la agencia central de informtica y
telecomunicaciones ahora oficina de comercio gubernamental,
un gobierno del Reino Unido la oficina de que se trate con el uso
de la tecnologa en el gobierno, a partir de 1980.
de
el
informacin.
pinculo
se
del
considera
enfoque
que
riguroso
SSADM
en
la
estructurado
de
Yourdon ,
de
Michael
A.
"SSADM"
son marcas
registradas de
la Oficina
METODOLOGA MERISE
Esta metodologa surge en Francia en 1977 a propuesta del Ministerio
de Industria, como un intento de unificar criterios en torno a la
metodologa de desarrollo para los sistemas informticos de la
Administracin Pblica Francesa.
Sus principios generales son:
TRATAMIENT
OS
Modelo
Conceptual
Modelo
Organizacional
DATOS
OPCIN
Modelo
Conceptual
Modelo
Lgico
De gestin
Modelo
Operacional
Modelo
Fsico
De
organizaci
n
Tcnica
Caractersticas.
MTRICA contempla el desarrollo de Sistemas de Informacin para
las distintas tecnologas que actualmente estn conviviendo y los
aspectos de gestin que asegurarn que un Proyecto cumple sus
objetivos en trminos de calidad y coste.
Su punto de partida es la versin anterior de MTRICA de la cual se
ha conservado la adaptabilidad, flexibilidad y sencillez. Se ha tenido
en cuenta la experiencia de los usuarios de las versiones anteriores
para solventar los problemas o deficiencias detectados.
En la elaboracin de MTRICA Versin 3 se han tenido en cuenta los
mtodos de desarrollo ms extendidos, as como los ltimos
estndares de ingeniera del software y calidad, as como referencias
especficas en cuanto a seguridad y gestin de proyectos.
1.3. Estructura:
Procesos principales.
Interfaces.
Planificacin PSI
Desarrollo
Anlisis ASI
Diseo DSI
Construccin CSI
Mantenimiento MSI
1.6. Interfaces:
Aseguramiento de la Calidad
Seguridad
Gestin de Configuracin
Gestin de Proyectos
METODOLOGAS PESADAS
En
esta
leccin
se
abordan
las
metodologas
pesadas
ms
donde
una
gran
organizacin
es
requerida.
Una
de
las
la documentacin,
la
planificacin
y seguimiento
avanzar
en
la
construccin
del
software
de
una
2.1.
la
reutilizacin
de
servicios
que
permitan
crear
ya
que
brindan
mecanismos
independientes
de
la
Tenga
una
definicin
del
contrato
independiente
de
Metodologa RUP
Es un producto del proceso de ingeniera de software que proporciona
un
1. Dimensiones
que
efectivamente
el
producto
implemente
cambios
posteriores
durante
la
construccin
el
mantenimiento.
La arquitectura dentro de RUP se representa en varias vistas.
Todas las vistas juntas forman el llamado modelo 4+1 de la
arquitectura. Segn Kruchten Philippe 1998el cual recibe este
nombre porque lo forman las vistas lgica, de implementacin, de
proceso y de despliegue, ms la de casos de uso que es la que da
cohesin a todas.
pasada
permite
reajustar
los
objetivos
para
las
tantas
iteraciones
hasta
que
se
termine
la
6. Fases
El ciclo de vida del software del RUP se descompone en cuatro
fases secuenciales. En cada extremo de una fase se realiza una
evaluacin para determinar si los objetivos de la fase se han
cumplido. Una vez que la evaluacin obtiene los resultados
deseados, se procede a la siguiente fase.
7. Planeando las fases
El ciclo de vida consiste en una serie de ciclos, cada uno de los
cuales produce una nueva versin del producto, cada ciclo est
compuesto por fases:
1. Concepcin, Inicio o Estudio de oportunidad: Define el mbito
y objetivos del proyecto, adems de la funcionalidad y
capacidades del producto.
el proyecto
considerando
recursos
disponibles.
3. Construccin: El producto se desarrolla a travs de iteraciones
donde cada iteracin involucra tareas de anlisis, diseo e
implementacin Las fases de concepcin y elaboracin slo
dieron una arquitectura bsica que es refinada aqu de manera
incremental conforme se construye (se permiten cambios en la
estructura). Gran parte del trabajo es programacin y pruebas,
se documenta tanto el sistema construido como el manejo del
mismo En esta fase se hace una documentacin junto con el
producto.
4. Transicin: Se libera el producto y se entrega al usuario para
un uso real. Se incluyen tareas de mercadotecnia, empaquetado
atractivo, instalacin, configuracin, entrenamiento, soporte,
mantenimiento, etc.
8. Esfuerzo respecto de los flujos de trabajo o disciplinas
En la imagen posterior del documento se muestra el porcentaje el
esfuerzo que se tiene que realizar por cada una de las disciplinas o
flujos de trabajo, y los dos porcentajes que se muestran de forma
horizontal son para todo el proyecto.
Se puede observar que para la obtencin de requisitos en la fase de
concepcin se empiezan a conseguir, en la fase de elaboracin tiene
su auge, y va declinando en la fase de construccin. Con las dems
sucede algo similar en distintas iteraciones.
9. Disciplinas
Las disciplinas son los flujos del trabajo, los cuales son una
secuencia de pasos para la culminacin de cada disciplina, estas
disciplinas se dividen en dos grupos: las primarias y las de apoyo.
Las primarias son las necesarias para la realizacin de un proyecto
de software, aunque para proyectos no muy grandes se pueden
omitir algunas; entre ellas se tienen: modelado del negocio,
requerimientos, anlisis y diseo, implementacin, pruebas y
Requerimientos
Anlisis y diseo
Implementacin
14.
Pruebas
Verificar
la
integracin),
integracin
verificar
de
que
los
todos
componentes
los
(prueba
requisitos
han
de
sido
Despliegue
Entorno
19.
Actores o roles
Analistas
Desarrolladores
- Arquitecto.
- Revisor de la Arquitectura.
- Diseador de Cpsulas.
- Revisor del Cdigo y Revisor del Diseo.
- Diseador de la Base de Datos.
- Diseador.
- Implementador y un Integrador.
22.
Probadores Profesionales
- Diseador de Pruebas.
- Probador.
23.
Encargados
Otros
- Cualquier trabajador.
- Artista Grfico.
- Stakeholder.
Artefactos
del
negocio:
Capturan
presentan
el
realizadas
las
metodologas
de
pruebas
aplicadas.
6. Despliegue:
Capturan
presentan
la
informacin
de
cambios
configuracin:
Desventajas de la metodologa:
Ventajas de la metodologa:
cmo).
Reutilizacin.
por varios
que
exhaustiva.
4. La colaboracin con el cliente, por encima de la negociacin
contractual.
5. La respuesta al cambio, por encima del seguimiento de un
plan.
Inicialmente, mucha gente asocia metodologas giles con falta de
documentacin
control
sobre
el
proyecto,
pero
esto
es
interpersonales
como
clave
para
el
xito
en
cualquier
metodologa
gil
el
cliente/usuario
del
METODOLOGA SCRUM
1. Qu es?
Scrum es una metodologa gil y flexible para gestionar el
desarrollo de software, cuyo principal objetivo es maximizar el
retorno de la inversin para su empresa (ROI). Se basa en construir
primero la funcionalidad de mayor valor para el cliente y en los
principios de inspeccin continua, adaptacin, auto-gestin e
innovacin.
Esquema:
2. Cundo se utiliza?
Con la metodologa Scrum el cliente se entusiasma y se
compromete con el proyecto dado que lo ve crecer iteracin a
iteracin. Asimismo le permite en cualquier momento realinear el
software con los objetivos de negocio de su empresa, ya que
puede introducir cambios funcionales o de prioridad en el inicio de
cada nueva iteracin sin ningn problema.
Esta metdica de trabajo promueve la innovacin, motivacin y
compromiso del equipo que forma parte del proyecto, por lo que
los profesionales encuentran un mbito propicio para desarrollar
sus capacidades.
3. Beneficios
1. Cumplimento de expectativas: El cliente establece sus
expectativas indicando el valor que le aporta cada requisitohistoria del proyecto, el equipo los estima y con esta
informacin el Product Owner establece su prioridad. De
manera
regular,
en
las
demos
de
Sprint
el Product
productividad: Se
consigue
entre
otras
razones,
fcilmente
para
cuando
se
dispondr
de
una
de
Backlog:
Es
una wish
list
sobre
las
est
compuesto
por
diferentes
features. Por
Scrum
Stand-up
Meeting: Es
una reunin
ayer?,
Qu
voy
hacer
hoy?,
Qu
ayuda
Sprint
Retrospective:
El
equipo revisa
los objetivos
6. Participantes:
Product Owner: Habla por el cliente, y asegura que el equipo
cumpla las expectativas. Es el jefe responsable del proyecto.
Scrum Master: Lidera las reuniones y ayuda al equipo si es que
tienen problemas. Adems, minimiza los obstculos para cumplir el
objetivo del Sprint, es un facilitador pero no es un gestor.
Scrum Team: Son los encargados de desarrollar y cumplir lo que
les asigna el Product Owner.
Cliente: Recibe
el
producto
y puede
influir
en
el
proceso,
Backlog:
Es
una wish
list
sobre
las
est
compuesto
por
diferentes
features. Por
Scrum
Stand-up
Meeting: Es
una reunin
ayer?,
Qu
voy
hacer
hoy?,
Qu
ayuda
Retrospective:
El
equipo revisa
los objetivos
9. Participantes:
a. Product Owner: Habla por el cliente, y asegura que el equipo
jefe
responsable
del
proyecto.
b. Scrum Master: Lidera las reuniones y ayuda al equipo si es
(Extreme
Programing) y Scrum no
se
adaptaban
los
2. Caractersticas
Una de sus caractersticas principales es la vital importancia que
se les da a los desarrolladores que componen el grupo de trabajo,
por lo cual sus puntos de estudio estn destinados a:
Aspecto humano del equipo
Tamao de un equipo
Comunicacin entre los desarrolladores
Polticas a seguir
Espacio fsico de trabajo
3. Rasgos de un equipo Crystal
Una disminucin en el nmero de desarrolladores proporcionar
una mejor comunicacin entre los mismos.
Trabajar en un mismo lugar dar lugar a una disminucin de
gastos por conceptos de comunicacin.
La mejora individual habilitar el paso a la mejora del equipo y
por consecuente al producto final.
4. Metodologas Crystal
el
presupuesto
monetario
imprescindible
el
tener libertades
en cuanto
a la
4. Analista/diseador de negocios
5. Gerente del proyecto
6. Arquitecto de software
7. Diseador lder
8. Programador lder
9. Otros diseadores-programadores
10. Diseador de interfaz de usuario
11. Reuse point
12. Escritor de cdigo
13. Probador
Estos roles estn organizados en equipos denotados como:
equipo de planificacin del sistema, monitoreo del proyecto,
tecnologa, infraestructura, y pruebas externas.
El producto debe estar dotado de documentacin, liberacin
de secuencias, calendarios, reportes de estado del proyecto,
documentacin de la interfaz de usuario, modelo comn de
objetos (diseo de clases, bases de datos etc.), manual de
usuario, cdigo fuente, casos de prueba y cdigo de migracin
en caso de existir.
c. Orange Web:
Esta metodologa tiene como diferencia de la anterior que esta
diseada para proyectos que estn sometidos a cambios
continuos debido a que son usados por el cliente, segn su
creador (2003) esta metodologa se encuentra en prueba, y
presenta alrededor de 50 roles divididos en ejecutivos, gente
de
negocios,
gerentes,
analistas,
programadores,
una
planificacin
ms
transparente
para
los
clientes.
Se definen en cada iteracin cuales son los objetivos de la
siguiente.
Permite tener una muy til realimentacin de los usuarios.
5.2. Desventajas
Delimita el alcance del proyecto con el cliente.
6. Crystal Methodologies vs Metodologas tradicionales
Metodologas
tradicionales
Planificacin
predictiva y
aislada
Diseo flexible y
extensible,
modelos y
documentacin
exhaustiva.
Desarrollo
individual con roles
y
responsabilidades
estrictas.
Actividades de
control orientadas
a los hitos
vs
Anlisis de
requerimientos y
planificacin
Diseo
Codificacin
Pruebas y puesta
en produccin
Metodologas Crystal
Planificacin adaptativa
vista en entregas
frecuentes y
colaboracin del cliente
Diseo simple:
documentacin mnima
enfocada en la
comunicacin
Transferencia de
conocimiento: la
programacin en grupo
propicia el
conocimiento colectivo.
LiderazgoColaboracin:
empoderamiento y auto
organizacin.
METODOLOGA FDD
Es una metodologa gil para el desarrollo de sistemas, basado en
la calidad del software,
que
incluye
un
monitoreo
constante
del proyecto.
FDD fue desarrollado por Jeff De Luca y Peter Coad a mediados de los
aos 90. Esta metodologa se enfoca en iteraciones cortas que
permite entregas tangibles del producto en corto periodo de tiempo
que como mximo son de dos semanas.
Contenido
1. Caractersticas:
No hace nfasis en la obtencin de los requerimientos sino en
como se realizan las fases de diseo y construccin.
Se preocupa por la calidad, por lo que incluye un monitoreo
constante del proyecto.
Ayuda a contrarrestar situaciones como el exceso en el
presupuesto, fallas en el programa o el hecho de entregar
menos de lo deseado.
Propone tener etapas de cierre cada dos semanas.
Se obtienen resultados peridicos y tangibles.
Se basa en un proceso iterativo con iteraciones cortas que
producen un software funcional que el cliente y la direccin de
la empresa pueden ver y monitorear.
Define claramente entregas tangibles y formas de evaluacin
del progreso del proyecto.
2. Procesos
El FDD tiene cinco procesos. Los primeros tres se hacen al principio
del proyecto.
a. Desarrollar un modelo global: Al inicio del desarrollo se
por
rasgo:
Se
selecciona
un
conjunto
de
proyecto.
3. Roles y responsabilidades
El equipo de trabajo est estructurado en jerarquas, siempre debe
haber un jefe de proyecto, y aunque es un proceso considerado
ligero tambin incluye documentacin (la mnima necesaria para
que algn nuevo integrante pueda entender el desarrollo de
inmediato).
4. Director del Proyecto: Lder administrativo y financiero del
Jefe:
Analiza
los
requerimientos.
Disea
el
una
mezcla
de
requerimientos
estos.
del
Poseen
sistema.
el
Pasa
conocimiento
el
conocimiento
de
los
los
Comparacin
mejor
para
proyectos
cortos
equipos
ms
UseCases
UserStories,
por
lo
contrario
FDD
no
define
intermedio,
en
el
sentido
de
que
genera
ms
4. Aprendizaje:
En cada iteracin se revisa:
-
Calidad del
producto
desde
desarrolladores.
-
Funcionalidad desarrollada.
el
punto
de
vista
de
los
Basado en la funcionalidad
Desarrollo iterativo
5. Ventajas:
Se utiliza para poder aprender de los errores e iniciar
nuevamente el ciclo de desarrollo.
Utiliza informacin disponible acerca de todos los cambios para
poder mejorar el comportamiento del Software.
Promulga la colaboracin y la interaccin de personas.
Apunta hacia el Rapid Application Development (RAD), el cual
enfatiza velocidad de desarrollo para crear un producto de alta
calidad, bajo mantenimiento involucrando al usuario lo ms
posible.
6. Desventajas:
Los errores y cambios que no son detectados con anterioridad
afectan la calidad del producto y su costo total.
Ya que esta es una metodologa gil, no permite realizar
procesos que son requeridos en las metodologas tradicionales.
7.2.
7.3.
Modelo Adaptativo
METODOLOGIA XP
1. Qu es XP?
2. Valores de XP
3. Caractersticas
i.
ii.
Pruebas
unitarias continuas,
frecuentemente
repetidas
iv.
v.
Correccin
de
todos
de
aadir
nueva
vii.
viii.
ix.
La
simplicidad
complementarias.
la
comunicacin
Con
ms
son
comunicacin
extraordinariamente
resulta
ms
fcil
Programacin en parejas
6. Fases de la metodologa Xp
Segn Kent Beck
7. Ventajas y desventajas:
7.1.
Ventajas
Programacin organizada.
7.2.
8. Ciclo de la XP
8. Usos y aplicaciones de XP
Extreme programming,
CONCLUSIONES
y brindar
requisitos
metodologas
tradicionales
obligan
al
cliente
tomar
las
BIBLIOGRAFA
Metodologas giles: La ventaja competitiva de estar preparado
para tomar decisiones lo ms tarde
cualquier
momento.
(En
posible y cambiarlas en
lnea),
Disponible
en:
www.spinec.org/wp-content/metodologiasagiles_01.pdf
Metodologas giles en lnea ,Disponible en: http://www.agilespain.com
ICONIX (En lnea), Disponible en:
www.spinec.org/wp-
content/ICONIX.pdf
Extreme Programming Refactored: The Case Against XP, MATT
Stephens and DOUG Rosenberg, Disponible en Formato chm
Introduccin a Iconix en lnea, Disponible en:
http://www.informit.com/articles/article.asp?
p=167902&rl=1