Angel Alfredo Gonzalez Ordua

Angel Alfredo Gonzalez Ordua

Materia ISS
Profesora: FATIMA DEL CARMEN PEREZ QUIONES







Identifica y describe que es un lenguaje descriptor de arquitecturas

Es un lenguaje de programacin utilizado para crear una descripcin de una arquitectura de
software. Esto significa en el caso de la arquitectura tcnica, la arquitectura debe ser
comunicada a los desarrolladores de software un ejemplo el lenguaje ACME ,UML



Elabora una lista de manera tabular al menos 5 lenguajes descriptores de arquitectura incluyendo
sus caracteristicas




Metodos Descripcion Caracteristicas
Modelo en
cascada
tambin llamado
modelo en cascada
(denominado as por la
posicin de las fases en
el desarrollo de esta,
que parecen caer en
cascada por gravedad
hacia las siguientes
fases), es el enfoque
metodolgico que
ordena rigurosamente
las etapas del proceso
para el desarrollo de
software
Anlisis de requisitos.
Diseo del Sistema.
Diseo del Programa.
Codificacin.
Pruebas.
Implantacin.
Mantenimiento


Ventajas

Realiza un buen funcionamiento
en equipos dbiles y productos
maduros, por lo que se requiere
de menos capital y herramientas



Angel Alfredo Gonzalez Ordua
para hacerlo funcionar de manera
ptima.
Es un modelo fcil de
implementar y entender.
Est orientado a documentos.
Es un modelo conocido y
utilizado con frecuencia.
Promueve una metodologa de
trabajo efectiva: Definir antes
que disear, disear antes que
codificar




Desventajas


En la vida real, un proyecto rara
vez sigue una secuencia lineal,
esto crea una mala
implementacin del modelo, lo
cual hace que lo lleve al fracaso.
El proceso de creacin del
software tarda mucho tiempo ya
que debe pasar por el proceso de
prueba y hasta que el software no
est completo no se opera. Esto
es la base para que funcione bien.
Cualquier error de diseo
detectado en la etapa de prueba
conduce necesariamente al
rediseo y nueva programacin
del cdigo afectado, aumentando
los costos del desarrollo.
Una etapa determinada del
proyecto no se puede llevar a
cabo a menos de que se haya
culminado la etapa anterior.




Angel Alfredo Gonzalez Ordua
Modelo de
construccin de
prototipos
pertenece a los modelos
de desarrollo evolutivo.
El prototipo debe ser
construido en poco
tiempo, usando los
programas adecuados y
no se debe utilizar
muchos recursos.
Plan rpido
Modelado, diseo rpido
Construccin del Prototipo
Desarrollo, entrega y
retroalimentacin
Comunicacin
Entrega del desarrollo final
Este modelo es til cuando el cliente
conoce los objetivos generales para el
software, pero no identifica los
requisitos detallados de entrada,
procesamiento o salida.
Tambin ofrece un mejor enfoque
cuando el responsable del desarrollo del
software est inseguro de la eficacia de
un algoritmo, de la adaptabilidad de un
sistema operativo o de la forma que
debera tomar la interaccin humano-
mquina

Modelo
Incremental
El modelo incremental
fue propuesto por
Harlan Mills en el ao
1980. Surgi el
enfoque incremental
de desarrollocomo
una forma de reducir la
repeticin del trabajo
en el proceso de
desarrollo y dar
oportunidad de
retrasar la toma de
decisiones en los
requisitos hasta
adquirirexperiencia
con el sistema
El Modelo Incremental combina
elementos del Modelo Lineal
Secuencial con la filosofa interactiva
de Construccin de Prototipos

En una visin genrica, el proceso
se divide en 4 partes:
Anlisis
Diseo
Cdigo
Prueba

Modelo espiral Las actividades de este
modelo se conforman en
una espiral en la que
cada bucle o iteracin
representa un conjunto
Los Objetivos: qu necesidad
debe cubrir el producto.
Alternativas: las diferentes
formas de conseguir los
objetivos de forma exitosa,


Angel Alfredo Gonzalez Ordua
de actividades. Las
actividades no estn
fijadas a ninguna
prioridad, sino que las
siguientes se eligen en
funcin del anlisis de
riesgo comenzando por
el bucle interior.
desde diferentes puntos de vista
como pueden ser:
1. Caractersticas: experiencia del
personal, requisitos a cumplir,
etc.
2. Formas de gestin del sistema.
3. Riesgo asumido con cada
alternativa.
Desarrollar y Verificar:
Programar y probar el software.
Si el resultado no es el adecuado o se
necesita implementar mejoras o
funcionalidades:
Se planificaran los siguientes
pasos y se comienza un nuevo
ciclo de la espiral. La espiral
tiene una forma de caracola y se
dice que mantiene dos
dimensiones, la radial y la
angular:
1. Angular: Indica el avance del
proyecto del software dentro de
un ciclo.
2. Radial: Indica el aumento del
coste del proyecto, ya que con
cada nueva iteracin se pasa
ms tiempo desarrollando.
Para cada ciclo habr cuatro actividades:
1. Determinar Objetivos.

2. Anlisis del riesgo.
3. Desarrollar y probar.


Angel Alfredo Gonzalez Ordua
4. 'Planificacin.'

Modelo SCRUM Scrum es un modelo de
desarrollo gil
caracterizado por:
Adoptar una
estrategia de
desarrollo
incremental, en
lugar de la
planificacin y
ejecucin
completa del
producto.
Basar la calidad
del resultado
ms en el
conocimiento
tcito de las
personas en
equipos
autoorganizados,
que en la calidad
de los procesos
empleados.
Solapamiento de
las diferentes
fases del
desarrollo, en
lugar de realizar
una tras otra en
un ciclo
secuencial o de
cascada.

Roles Principales
Product Owner
El Product Owner representa la
voz del cliente. Se asegura de
que el equipo Scrum trabaje de
forma adecuada desde la
perspectiva del negocio. El
Product Owner escribe historias
de usuario las prioriza, y las
coloca en el Product Backlog
ScrumMaster (o Facilitador)
El Scrum es facilitado por un
ScrumMaster, cuyo trabajo
primario es eliminar los
obstculos que impiden que el
equipo alcance el objetivo del
sprint. El ScrumMaster no es el
lder del equipo (porque ellos se
auto-organizan), sino que acta
como una proteccin entre el
equipo y cualquier influencia
que le distraiga. El ScrumMaster
se asegura de que el proceso
Scrum se utiliza como es debido.
El ScrumMaster es el que hace
que las reglas se cumplan.
Equipo de desarrollo
El equipo tiene la
responsabilidad de entregar el
producto. Un pequeo equipo
de 3 a 9 personas con las
habilidades transversales
necesarias para realizar el
trabajo (anlisis, diseo,


Angel Alfredo Gonzalez Ordua
desarrollo, pruebas,
documentacin)

Roles Auxiliares
Los roles auxiliares en los "equipos
Scrum" son aquellos que no tienen un rol
formal y no se involucran
frecuentemente en el "proceso Scrum",
sin embargo deben ser tomados en
cuenta. Un aspecto importante de una
aproximacin gil es la prctica de
involucrar en el proceso a los usuarios,
expertos del negocio y otros interesados
(stakeholders). Es importante que esa
gente participe y entregue
retroalimentacin con respecto a la
salida del proceso a fin de revisar y
planear cada sprint.
Stakeholders (Clientes, Proveedores,
Vendedores, etc)
Se refiere a la gente que hace
posible el proyecto y para
quienes el proyecto producir el
beneficio acordado que justifica
su produccin. Slo participan
directamente durante las
revisiones del sprint.
Administradores (Managers)
Es la gente que establece el
ambiente para el desarrollo del
producto.


Programacin
extrema
es una metodologa de
desarrollo de la
ingeniera de software
formulada por Kent
Beck, autor del prim er
libro sobre la materia,
la programacin extrema se
diferencia de las metodologas
tradicionales principalmente en que
pone ms nfasis en la adaptabilidad
que en la previsibilidad. Los


Angel Alfredo Gonzalez Ordua
Extreme Programming
Explained: Embrace
Change (1999). Es el
ms destacado de los
procesos giles de
desarrollo de software
defensores de la programacin
extrema consideran que los cambios
de requisitos sobre la marcha son un
aspecto natural, inevitable e incluso
deseable del desarrollo de
proyectos. Creen que ser capaz de
adaptarse a los cambios de
requisitos en cualquier punto de la
vida del proyecto es una
aproximacin mejor y ms realista
que intentar definir todos los
requisitos al comienzo del proyecto
e invertir esfuerzos despus en
controlar los cambios en los
requisitos

Los valores originales de la
programacin extrema son:
simplicidad, comunicacin,
retroalimentacin (feedback) y
coraje

Desarrollo iterativo e
incremental: pequeas mejoras,
unas tras otras.
Pruebas unitarias continuas,
frecuentemente repetidas y
automatizadas, incluyendo
pruebas de regresin. Se
aconseja escribir el cdigo de la
prueba antes de la codificacin.
Poo ejemplo las herramientas de
prueba JUnit orientada a Java,
DUnit orientada a Delphi, NUnit


Angel Alfredo Gonzalez Ordua
para la plataforma.NET o
PHPUnit para PHP. Estas tres
ltimas inspiradas en JUnit, la
cual, a su vez, se insipir en
SUnit, el primer framework
orientado a realizar tests,
realizado para el lenguaje de
programacin Smalltalk.
Programacin en parejas: se
recomienda que las tareas de
desarrollo se lleven a cabo por
dos personas en un mismo
puesto. La mayor calidad del
cdigo escrito de esta manera -
el cdigo es revisado y discutido
mientras se escribe- es ms
importante que la posible
prdida de productividad
inmediata.
Frecuente integracin del
equipo de programacin con el
cliente o usuario. Se recomienda
que un representante del cliente
trabaje junto al equipo de
desarrollo.
Correccin de todos los errores
antes de aadir nueva
funcionalidad. Hacer entregas
frecuentes.
Refactorizacin del cdigo, es
decir, reescribir ciertas partes
del cdigo para aumentar su
legibilidad y mantenibilidad
pero sin modificar su
comportamiento. Las pruebas
han de garantizar que en la


Angel Alfredo Gonzalez Ordua
refactorizacin no se ha
introducido ningn fallo.
Propiedad del cdigo
compartida: en vez de dividir la
responsabilidad en el desarrollo
de cada mdulo en grupos de
trabajo distintos, este mtodo
promueve el que todo el
personal pueda corregir y
extender cualquier parte del
proyecto. Las frecuentes
pruebas de regresin garantizan
que los posibles errores sern
detectados.
Simplicidad en el cdigo: es la
mejor manera de que las cosas
funcionen. Cuando todo
funcione se podr aadir
funcionalidad si es necesario. La
programacin extrema apuesta
que es ms sencillo hacer algo
simple y tener un poco de
trabajo extra para cambiarlo si
se requiere, que realizar algo
complicado y quizs nunca
utilizarlo.
La simplicidad y la comunicacin son
extraordinariamente complementarias.
Con ms comunicacin resulta ms fcil
identificar qu se debe y qu no se debe
hacer. Cuanto ms simple es el sistema,
menos tendr que comunicar sobre ste,
lo que lleva a una comunicacin ms
completa, especialmente si se puede
reducir el equipo de programadores.



Angel Alfredo Gonzalez Ordua
Proceso unificado
de desarrollo
El Proceso Unificado no
es simplemente un
proceso, sino un marco
de trabajo extensible que
puede ser adaptado a
organizaciones o
proyectos especficos.
De la misma forma, el
Proceso Unificado de
Rational, tambin es un
marco de trabajo
extensible, por lo que
muchas veces resulta
imposible decir si un
refinamiento particular
del proceso ha sido
derivado del Proceso
Unificado o del RUP.
Por dicho motivo, los dos
nombres suelen
utilizarse para referirse a
un mismo concepto.
El nombre Proceso
Unificado se usa para
describir el proceso
genrico que incluye
aquellos elementos que
son comunes a la
mayora de los
refinamientos existentes.
Tambin permite evitar
problemas legales ya que
Proceso Unificado de
Rational o RUP son
marcas registradas por
IBM

Iterativo e Incremental
Dirigido por los casos de uso
Centrado en la arquitectura
Enfocado en los riesgos
Fases

Inicio
Elaboracion
Construccion
Transicion






Angel Alfredo Gonzalez Ordua