Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% encontró este documento útil (0 votos)
28 vistas10 páginas

HOJA1

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1/ 10

HOJA1:

El desarrollo de software, es una de las reas de la tecnologa a donde


muchos ingenieros y licenciados en informtica suelen acercarse.
gracias a este trmino, es que se han ido creando los mtodos del ciclo del
software, que no son otra cosa ms que metodologas que indican distintos
pasos a seguir para el desarrollo de un producto.
Proceso Bsico del Ciclo de Vida de un Sistema:

cascada para el proceso de desarrollo de un sistema, con el cul veremos a


ciencia cierta el proceso bsico, del cual muchos modelos ms se empezarn a
desarrollar.
Planificacin. El primer punto importante en el ciclo de vida de software, es
analizar brevemente los requerimientos que el cliente pide para la elaboracin
del sistema que necesita. Esta etapa requiere se cierto conocimiento para
poder entender la idea que el cliente propone, adems de que regularmente
debes tomar nota con cada uno de los puntos importantes que se te solicitan
Implementacin. Una vez que hemos platicado con el cliente y tenemos lo
que es un anlisis de requerimientos, necesidades y funcionalidades por parte
de una aceptacin en ambas partes, entonces procedemos con lo que es el
ciclo de vida de desarrollo de software. Para este punto, existen una infinidad
de metodologas de desarrollo de software Liebe
Pruebas. Una vez que el sistema se va desarrollando, es importante para el
ciclo de vida del desarrollo del software, que se realicen ciertas pruebas
conforme se vaya avanzando. La idea es que no se termine el desarrollo para
poder hacer pruebas, si no que mucho antes, durante el proceso de creacin,
estas ya se puedan ir ejecutando.
Documentacin. Muchas metodologas de lo que es el ciclo de vida software,
van creando documentacin, conforme se va avanzando en el desarrollo del
sistema.
Despliegue. Ya casi llegando a lo que son las ltimas etapas del desarrollo de
software, nos encontramos con el Despliegue. Este no es otra cosa, ms que el
momento en que el sistema ya est terminado y ha sido aprobado para que se
elabore el producto final.
Mantenimiento. La ltima de las fases del desarrollo de software, es el
mantenimiento. Que creas, que nunca ms veras al software que hicieron,
terminaron y distribuyeron. Pues claro que, si lo volveras a ver, pues es
momento de darle mantenimiento.
Paradigmas de los Modelos del Ciclo de Vida del Software

Si bien, nos queda claro que no todos tenemos las mismas ideas y no todos
pensamos de la misma manera, afortunadamente ya existen modelos
preestablecidos bajo los cuales podemos elaborar nuestro proyecto. Es por eso
que a continuacin les mostrar cuales son algunos de los paradigmas de los
Modelos del ciclo de vida de desarrollo de sistemas
Paradigma Tradicional. Existen algunas metodologas del ciclo de vida de
desarrollo de sistemas, que se manejan a la antigua, a estas tambin se le
conocen como paradigmas tradicionales. Si bien, es verdad que las
metodologas actuales estn basadas con fundamentos de lo que fueron los
paradigmas tradicionales, hoy en da ya hemos evolucionado, sin embargo, los
paradigmas tradicionales ah se mantienen.
Paradigma Orientado a Objetos. Una de las genialidades ms exquisitas, es
el desarrollo de software mediante programacin orientada a objetos. Con esta
forma del ciclo de vida de los sistemas,
Paradigma de Desarrollo gil. Los modelos de ciclo de vida giles, son de
los ms utilizados hoy en da. El objetivo de este paradigma, es el desarrollo de
proyectos en poco tiempo. Para lo cual, se hace una eliminacin de procesos
tediosos, se agilizan las fases de desarrollo, las iteraciones se hacen en un
corto periodo de tiempo, los riesgos se desechan y se evitan para no tener que
lidiar con ellos.11

Ciclo de Vida del Software en las distintas Metodologas:


Modelo del Ciclo de Vida de un Software:
Modelo en Cascada
Esta metodologa es lineal y consta de algunas fases que hay que seguir y
completar para poder avanzar a la fase siguiente. No es precisamente la mejor
metodologa, pero si se utiliza de forma correcta los resultados pueden ser muy
buenos
una metodologa lineal en cascada y si no se completa cada una de las
fases al 100%, no es posible avanzar a la fase que sigue, as es como
funciona y se debe seguir al pie de la letra, por muy exagerado que esta
parezca.
Modelo en el Espiral
El modelo de ciclo de vida en espiral, consiste en realizar diversas iteraciones,
pasando por cada una de sus fases una y otra vez. A diferencia de la modelo
cascada que no tiene vuelta atrs, en el modelo en espiral se pueden hacer las
iteraciones que se consideren necesarias
Entre las principales ventajas de desarrollar un proyecto con el modelo espiral, es que
los riesgos se van disminuyendo conforme avanzan los ciclos o iteraciones, de hecho, no
puedes avanzar a un ciclo nuevo, si no se ha dado solucin a todos los riesgos latentes.
Modelo XP o Programacin extrema
A diferencia del resto de las metodologas del mundo, habidas y por haber, esta
es adaptable de acuerdo a las necesidades y requerimientos que se tengan
que implementar, con la ventaja de que podemos hacer uso de cualquier
modelo anterior para el desarrollo y de inmediato salirnos y programar otras
cosas, es muy solapador y permite mucha ms libertad en el equipo de trabajo
que el resto de los modelos.
Adems, si queras una diferencia an mayor, en la metodologa de
programacin extrema, el cliente se encuentra involucrado en el proceso de
desarrollo, lo que hace que al final el producto pueda estar terminado en un
menor tiempo, pues evitamos muchas prdidas de tiempo, elaborando cosas
que no son y que en la revisin al cliente no le agradarn, ac el cliente va
viendo lo que se va desarrollando y tiene la libertad de proponer cambios,
ideas, requerimientos o actualizaciones sin ningn problema.
METODOLOGIA RUP

Concepto:
Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de modelado UML,
constituye la metodologa estndar ms utilizada para el anlisis, implementacin y
documentacin de sistemas orientados a objetos.
El RUP es un conjunto de metodologas adaptables al contexto y necesidades de cada
organiza

En esta metodologa lo que se pretende es el desarrollo de un software, en el cual se aplicara


el PSP y el CMMI en todas sus fases, que estn en la realizacin de los procesos

Hoja 2 de RUP:

Incluye artefactos (que son los productos tangibles del proceso como, por ejemplo, el modelo
de casos de uso, el cdigo fuente, etc.) y roles (papel que desempea una persona en un
determinado momento, una persona puede desempear distintos roles a lo largo del proceso).

El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado
ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas
en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en
nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en las
distintas actividades

Fases del ciclo de vida del RUP:


1. Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del proyecto con
los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin muy
general de la arquitectura de software y producir el plan de las fases y el de iteraciones
posteriores.

2. Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso que


permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la
especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema,
se disea la solucin preliminar.

3. Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del sistema,


para ello se deben clarificar los requerimientos pendientes, administrar los cambios de acuerdo
a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.

4. Fase de Cierre: El propsito de esta fase es asegurar que el software est disponible para
los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin,
capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el
producto cumpla con las especificaciones entregadas por las personas involucradas en el
proyecto.
Principios de desarrollo de RUP

Determina las etapas a realizar durante el proyecto de creacin del software.

Ingeniera o modelado del negocio: Analizar y entender las necesidades del negocio
para el cual se est desarrollando el software.

Requisitos: Proveer una base para estimar los costos y tiempo de desarrollo del
sistema.

Anlisis y diseo: Trasladar los requisitos analizados anteriormente a un sistema


automatizado y desarrollar una arquitectura para el sistema.

Implementacin: Crear software que se ajuste a la arquitectura diseada y que tenga


el comportamiento deseado.

Pruebas: Asegurarse de que el comportamiento requerido es correcto y que todo lo


solicitado est presente.

Despliegue: Producir distribuciones del producto y distribuirlo a los usuarios.

Disciplina de soporte RUP


Determina la documentacin que es necesaria realizar durante el proyecto.

Configuracin y administracin del cambio: Guardar todas las versiones del


proyecto.

Administracin del proyecto: Administrar los horarios y recursos que se deben de


emplear.

Ambiente: Administrar el ambiente de desarrollo del software.

Distribucin: Hacer todo lo necesario para la salida del proyecto.

Elementos del RUP

Actividades: Procesos que se han de realizar en cada etapa/iteracin.


Trabajadores: Personas involucradas en cada actividad del proyecto.

Artefactos: Herramientas empleadas para el desarrollo del proyecto. Puede ser un


documento, un modelo, un elemento del modelo.

PROGRAMACIN EXTREMA (EXTREME PROGRAMMING, XP)


Concepto:
Los principios y prcticas son de sentido comn pero llevadas al extremo, de
ah proviene su nombre. Kent Beck, el padre de XP, describe la filosofa de XP
en [2] sin cubrir los detalles tcnicos y de implantacin de las prcticas.
Posteriormente, otras publicaciones de experiencias se han encargado de
dicha tarea.
Las Historias de Usuario:
El tratamiento de las historias de usuario es muy dinmico y flexible, en
cualquier momento historias de usuario pueden romperse, reemplazarse por
otras ms especficas o generales, aadirse nuevas o ser modificadas. Cada
historia de usuario es lo suficientemente comprensible y delimitada para que
los programadores puedan implementarla en unas semanas
ROLES DE XP:

Aunque en otras fuentes de informacin aparecen algunas


variaciones y extensiones de roles XP, en este apartado
describiremos los roles de acuerdo con la propuesta original de
Beck.

Programador

El programador escribe las pruebas unitarias y produce el cdigo


del sistema. Debe existir una comunicacin y coordinacin
adecuada entre los programadores y otros miembros del equipo.

Cliente

El cliente escribe las historias de usuario y las pruebas funcionales


para validar su implementacin. Adems, asigna la prioridad a las
historias de usuario y decide cules se implementan en cada
iteracin centrndose en aportar mayor valor al negocio. El cliente
es slo uno dentro del proyecto, pero puede corresponder a un
interlocutor que est representando a varias personas que se
vern afectadas por el sistema.

Encargado de pruebas (Tester)


El encargado de pruebas ayuda al cliente a escribir las pruebas
funcionales. Ejecuta las pruebas regularmente, difunde los
resultados en el equipo y es responsable de las herramientas de
soporte para pruebas.

Encargado de seguimiento (Tracker)

El encargado de seguimiento proporciona realimentacin al equipo


en el proceso XP. Su responsabilidad es verificar el grado de
acierto entre las estimaciones realizadas y el tiempo real dedicado,
comunicando los resultados para mejorar futuras estimaciones.
Tambin realiza el seguimiento del progreso de cada iteracin y
evala si los objetivos son alcanzables con las restricciones de
tiempo y recursos presentes. Determina cundo es necesario
realizar algn cambio para lograr los objetivos de cada iteracin.

Entrenador (Coach)

Es responsable del proceso global. Es necesario que conozca a


fondo el proceso XP para proveer guas a los miembros del equipo
de forma que se apliquen las prcticas XP y se siga el proceso
correctamente.

Consultor

Es un miembro externo del equipo con un conocimiento especfico


en algn tema necesario para el proyecto. Gua al equipo para
resolver un problema especfico.

. PROCESO XP

Un proyecto XP tiene xito cuando el cliente selecciona el valor de


negocio a implementar basado en la habilidad del equipo para
medir la funcionalidad que puede entregar a travs del tiempo. El
ciclo de desarrollo consiste (a grandes rasgos) en los siguientes
pasos [12]:

CICLO DE VIDA XP:

Fase I: Exploracin

En esta fase, los clientes plantean a grandes rasgos las historias


de usuario que son de inters para la primera entrega del producto.
Al mismo tiempo el equipo de desarrollo se familiariza con las
herramientas, tecnologas y prcticas que se utilizarn en el
proyecto. Se prueba la tecnologa y se exploran las posibilidades
de la arquitectura del sistema construyendo un prototipo. La fase
de exploracin toma de pocas semanas a pocos meses,
dependiendo del tamao y familiaridad que tengan los
programadores con la tecnologa.

Fase II: Planificacin de la Entrega

Se toman acuerdos sobre el contenido de la primera entrega y se


determina un cronograma en conjunto con el cliente. Una entrega
debera obtenerse en no ms de tres meses. Esta fase dura unos
pocos das.

Fase III: Iteraciones

Esta fase incluye varias iteraciones sobre el sistema antes de ser


entregado. El Plan de Entrega est compuesto por iteraciones de
no ms de tres semanas. En la primera iteracin se puede intentar
establecer una arquitectura del sistema que pueda ser utilizada
durante el resto del proyecto. Esto se logra escogiendo las historias
que fuercen la creacin de esta arquitectura, sin embargo, esto no
siempre es posible ya que es el cliente quien decide qu historias
se implementarn en cada iteracin (para maximizar el valor de
negocio).

Fase IV: Produccin

La fase de produccin requiere de pruebas adicionales y revisiones


de rendimiento antes de que el sistema sea trasladado al entorno
del cliente. Al mismo tiempo, se deben tomar decisiones sobre la
inclusin de nuevas caractersticas a la versin actual, debido a
cambios durante esta fase.

Es posible que se rebaje el tiempo que toma cada iteracin, de tres


a una semana. Las ideas que han sido propuestas y las
sugerencias son documentadas para su posterior implementacin
(por ejemplo, durante la fase de mantenimiento).

Fase V: Mantenimiento

Mientras la primera versin se encuentra en produccin, el


proyecto XP debe mantener el sistema en funcionamiento al mismo
tiempo que desarrolla nuevas iteraciones. Para realizar esto se
requiere de tareas de soporte para el cliente. De esta forma, la
velocidad de desarrollo puede bajar despus de la puesta del
sistema en produccin. La fase de mantenimiento puede requerir
nuevo personal dentro del equipo y cambios en su estructura.
Fase VI: Muerte del Proyecto

Es cuando el cliente no tiene ms historias para ser incluidas en el


sistema. Esto requiere que se satisfagan las necesidades del
cliente en otros aspectos como rendimiento y confiabilidad del
sistema. Se genera la documentacin final del sistema y no se
realizan ms cambios en la arquitectura. La muerte del proyecto
tambin ocurre cuando el sistema no genera los beneficios
esperados por el cliente o cuando no hay presupuesto para
mantenerlo.

DIAGRAMA DE SECUENCIA:

1. INTRODUCCIN

El lenguaje unificado de modelado UML Se utiliza para definir un sistema, mediante el uso de
objetos que forman parte de l as como, las relaciones estticas o dinmicas que existen entre
ellos.

Dentro de los diagramas de comportamiento en UML que permiten enfatizar las interacciones
entre los objetos se encuentran los diagramas de secuencias, este describe el comportamiento
del sistema y las operaciones que se realizan representando los objetos y los mensajes que se
intercambian, ya que en un sistema real y funcional los objetos interactan entre s, y tales
iteraciones suceden con el tiempo que se asigna, es decir que el diagrama de secuencias de
UML es una mecnica de interaccin en base a los tiempos.

2. OBJETIVO

Conocer sobre los diagramas de secuencia en UML, sus caractersticas, funcionamiento y


elementos que los componen.

3. MARCO TERICO
3.1. Diagrama de Secuencias

Un diagrama de secuencias muestra la interaccin de un conjunto de objetos de una aplicacin


a travs del tiempo, en el cual se indicarn los mdulos o clases que formaran parte del
programa y las llamadas que se hacen cada uno de ellos para realizar una tarea determinada,
por esta razn permite observar la perspectiva cronolgica de las interacciones. Es importante
recordar que el diagrama de secuencias se realiza a partir de la descripcin de un caso de uso.

También podría gustarte