11
Angel Alfredo Gonzalez Orduña Angel Alfredo Gonzalez Orduña Materia ISS Profesora: FATIMA DEL CARMEN PEREZ QUIÑONES Identifica y describe que es un lenguaje descriptor de arquitecturas Es un lenguaje de programación utilizado para crear una descripción de una arquitectura de software. Esto significa en el caso de la arquitectura técnica, 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 también llamado modelo en cascada (denominado así por la posición de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases), es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software Análisis de requisitos. Diseño del Sistema. Diseño del Programa. Codificación. Pruebas. Implantación. Mantenimiento Ventajas Realiza un buen funcionamiento en equipos débiles y productos maduros, por lo que se requiere de menos capital y herramientas

IIS_U1_A2_ANGO

Embed Size (px)

DESCRIPTION

adad

Citation preview

Page 1: IIS_U1_A2_ANGO

Angel Alfredo Gonzalez Orduña

Angel Alfredo Gonzalez Orduña

Materia ISS

Profesora: FATIMA DEL CARMEN PEREZ QUIÑONES

Identifica y describe que es un lenguaje descriptor de arquitecturas

Es un lenguaje de programación utilizado para crear una descripción de una arquitectura de software. Esto significa en el caso de la arquitectura técnica, 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

también llamado modelo en cascada (denominado así por la posición de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases), es el enfoque metodológico que ordena rigurosamente las etapas del proceso

para el desarrollo de

software

Análisis de requisitos.

Diseño del Sistema.

Diseño del Programa.

Codificación.

Pruebas.

Implantación.

Mantenimiento

Ventajas

Realiza un buen funcionamiento

en equipos débiles y productos

maduros, por lo que se requiere

de menos capital y herramientas

Page 2: IIS_U1_A2_ANGO

Angel Alfredo Gonzalez Orduña

para hacerlo funcionar de manera

óptima.

Es un modelo fácil de

implementar y entender.

Está orientado a documentos.

Es un modelo conocido y

utilizado con frecuencia.

Promueve una metodología de

trabajo efectiva: Definir antes

que diseñar, diseñar antes que

codificar

Desventajas

En la vida real, un proyecto rara

vez sigue una secuencia lineal,

esto crea una mala

implementación del modelo, lo

cual hace que lo lleve al fracaso.

El proceso de creación 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 diseño

detectado en la etapa de prueba

conduce necesariamente al

rediseño y nueva programación

del código 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.

Page 3: IIS_U1_A2_ANGO

Angel Alfredo Gonzalez Orduña

Modelo de

construcción 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 rápido Modelado, diseño rápido Construcción del Prototipo Desarrollo, entrega y

retroalimentación Comunicación 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.

También 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

debería tomar la interacción humano-

máquina

Modelo

Incremental El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollocomo una forma de reducir la repetición 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 filosofía interactiva de Construcción de Prototipos En una visión genérica, el proceso se divide en 4 partes:

Análisis

Diseño

Código

Prueba

Modelo espiral Las actividades de este modelo se conforman en una espiral en la que cada bucle o iteración representa un conjunto

Los Objetivos: qué necesidad debe cubrir el producto.

Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa,

Page 4: IIS_U1_A2_ANGO

Angel Alfredo Gonzalez Orduña

de actividades. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo comenzando por el bucle interior.

desde diferentes puntos de vista como pueden ser:

1. Características: experiencia del personal, requisitos a cumplir, etc.

2. Formas de gestión 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 iteración se pasa más tiempo desarrollando.

Para cada ciclo habrá cuatro actividades:

1. Determinar Objetivos.

2. Análisis del riesgo.

3. Desarrollar y probar.

Page 5: IIS_U1_A2_ANGO

Angel Alfredo Gonzalez Orduña

4. 'Planificación.'

Modelo SCRUM Scrum es un modelo de

desarrollo ágil

caracterizado por:

Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto.

Basar la calidad del resultado más en el conocimiento tácito 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

obstáculos que impiden que el

equipo alcance el objetivo del

sprint. El ScrumMaster no es el

líder del equipo (porque ellos se

auto-organizan), sino que actúa

como una protección 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 pequeño equipo

de 3 a 9 personas con las

habilidades transversales

necesarias para realizar el

trabajo (análisis, diseño,

Page 6: IIS_U1_A2_ANGO

Angel Alfredo Gonzalez Orduña

desarrollo, pruebas,

documentación)

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

aproximación ágil es la práctica de

involucrar en el proceso a los usuarios,

expertos del negocio y otros interesados

(stakeholders). Es importante que esa

gente participe y entregue

retroalimentación 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 producción. Sólo participan

directamente durante las

revisiones del sprint.

Administradores (Managers)

Es la gente que establece el

ambiente para el desarrollo del

producto.

Programación extrema

es una metodología de

desarrollo de la

ingeniería de software

formulada por Kent

Beck, autor del prim er

libro sobre la materia,

la programación extrema se

diferencia de las metodologías

tradicionales principalmente en que

pone más énfasis en la adaptabilidad

que en la previsibilidad. Los

Page 7: IIS_U1_A2_ANGO

Angel Alfredo Gonzalez Orduña

Extreme Programming

Explained: Embrace

Change (1999). Es el

más destacado de los

procesos ágiles de

desarrollo de software

defensores de la programación

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

aproximación mejor y más realista

que intentar definir todos los

requisitos al comienzo del proyecto

e invertir esfuerzos después en

controlar los cambios en los

requisitos

Los valores originales de la

programación extrema son:

simplicidad, comunicación,

retroalimentación (feedback) y

coraje

Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.

Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Poo ejemplo las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit

Page 8: IIS_U1_A2_ANGO

Angel Alfredo Gonzalez Orduña

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 programación Smalltalk.

Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. La mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.

Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.

Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.

Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la

Page 9: IIS_U1_A2_ANGO

Angel Alfredo Gonzalez Orduña

refactorización no se ha introducido ningún fallo.

Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.

Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

La simplicidad y la comunicación son

extraordinariamente complementarias.

Con más comunicación resulta más fácil

identificar qué se debe y qué no se debe

hacer. Cuanto más simple es el sistema,

menos tendrá que comunicar sobre éste,

lo que lleva a una comunicación más

completa, especialmente si se puede

reducir el equipo de programadores.

Page 10: IIS_U1_A2_ANGO

Angel Alfredo Gonzalez Orduña

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 específicos.

De la misma forma, el

Proceso Unificado de

Rational, también 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

genérico que incluye

aquellos elementos que

son comunes a la

mayoría de los

refinamientos existentes.

También 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

Page 11: IIS_U1_A2_ANGO

Angel Alfredo Gonzalez Orduña