0

Universidad Andrs Bello

Facultad de Ingeniera
Escuela de informtica
Metodologa de Desarrollo de Software
Taller N2
Integrantes:
Cristbal Briones
Carlos Fernndez
Fabin Snchez
Profesor:
Gustavo Gatica
Ayudantes:
Felipe Reyes
Daniela Ubilla
Fecha:
17 de junio de 2014

1

Ejercicio 1
Metodologa:
Conjunto de procedimientos, tcnicas, herramientas y un soporte documental que ayuda a
los desarrolladores a realizar nuevo software
Tarea: Actividades elementales es que se dividen los procesos.
Procedimiento: Definicin de la forma de ejecutar la tarea
Tcnica: Herramienta utilizada para aplicar un procedimiento. Se puede utilizar una
o varias.
Herramienta: para realizar una tcnica, podemos apoyarnos en las herramientas de
software que automatizan su aplicacin.
Producto: resultado de cada etapa.

La metodologa indica cmo hay que obtener los distintos productos parciales y finales.

Ejemplo Metodologa de Desarrollo de SW
As por ejemplo, pueden incorporarse a ella todas las actividades de control de calidad a lo
largo del ciclo de desarrollo, tambin pueden incorporarse todas aquellas actividades
propias de la gestin del proyecto como la planificacin, el seguimiento y el control del
proyecto, e incluso aquellas actividades propias de la gestin de versiones, los cambios
producidos durante el desarrollo y la migracin de componentes entre diferentes entornos
de construccin, pruebas, y explotacin final. (Areba, Metodologa del anlisis
estructurado de sistemas, 2001, pg. 23)

Modelo de Ciclo de Vida

Es una estructura aplicada al desarrollo de un producto de software. Hay varios modelos a
seguir para el establecimiento de un proceso para el desarrollo de software, cada uno de los
cuales describe un enfoque diferente para diferentes actividades que tienen lugar durante el
proceso.

El ciclo de vida indica que es lo que hay que obtener a lo largo del desarrollo del proyecto
pero no cmo hacerlo.

Ejemplo Modelo de Ciclo de Vida









2


Ejercicio 2
1. RAD - Desarrollo rpido de aplicaciones
1234

La idea principal era continuar el desarrollo de los sistemas de informacin en una
deliberada, estructurada y metdica reiterando cada una de las etapas del ciclo de vida.
Los sistemas de informacin en torno de las actividades resueltas pesadas para el
procesamiento de datos y rutinas de clculo. El desarrollo rpido de aplicaciones o RAD
acrnimo en ingls de (Rapid Application Development) es un proceso de desarrollo de
software, definido por James Martin a principios de la dcada de 1980, consiste en un ciclo
de desarrollo corto basado en tres fases (Requisitos, Diseo y Construccin) con un plazo
de entrega ideal de 60 a 90 das como mximo.

Caractersticas
Bajos Costos: RAD, por lo general, resulta en costos ms bajos. Esto se debe a que forman
pequeos equipos de profesionales quienes utilizan herramientas de la capacidad para
generar los sistemas. Estas herramientas conocidas como CASE (Computer Aided System
Engineering) permite que se aligere el proceso, lo cual ayuda a que los costos aun sean ms
bajos sin sacrificar la calidad del producto. El mtodo RAD utiliza estas herramientas y el
talento humano para cumplir con las metas requeridas rpida y efectivamente.

Enfoque
La metodologa conocida como diseo rpido de aplicaciones (RAD segn sus siglas en
ingls) ha tenido mucho auge recientemente en el mundo de la informtica. Esta
metodologa propone el proceso de desarrollo de software que permite la creacin de estos
en un periodo de tiempo entre 60 a 90 das. RAD es un ciclo de desarrollo diseado para
crear aplicaciones de computadoras de alta calidad.
El desarrollo de aplicaciones enfrenta una transformacin fundamental hace cinco aos un
proyecto para desarrollar una aplicacin tomaba un periodo de entre 18 a 24 meses;
actualmente, con la prctica del modelo RAD toma entre 1 a 3 meses.

1
Kioskea. (Octubre de 2013). kioskea. Recuperado el 27 de Octubre de 2013, de kioskea:
http://es.kioskea.net/contents/227-metodos-rapidos-rad-xp
2
Sommerville, I. (2012). Software Engineering 9. Mxico: Pearson.
3
Pressman, R. (2010). Software Engineering, A Practitioners Approach 7
th
. Mxico: McGraw-Hill.
4
Wordpress. (s.f.). curiosisimos.files.wordpress. Recuperado el 16 de Junio de 2014, de
curiosisimos.files.wordpress:http://curiosisimos.files.wordpress.com/2009/12/modelo-de-
desarrollo-rapido-de-aplicaciones.pdf


3


Ilustracin 1 Figura 1.1: Metodologa RAD


Ilustracin 2 Figura 1.2: Comparacin Metodologa con RAD




4


2. - Se ajusta en parte, ya que no todo es en parte igual al manifiesto gil, por ejemplo
lo que aparece en (agilemanifesto.com, 2001) Estamos descubriendo formas
mejores de desarrollar software tanto por nuestra propia experiencia como ayudando
a terceros. A travs de este trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentacin extensiva
Colaboracin con el cliente sobre negociacin contractual
Respuesta ante el cambio sobre seguir un plan.
Esto es, aunque valoramos los elementos de la derecha, valoramos ms los de la
izquierda.
- Tambin como dice uno de los valores del Manifiesto gil: Software funcionando
por encima de la documentacin: los profesionales relacionados con el desarrollo de
software, aunque no es su fuerte producir documentos, reconocen su importancia, al
igual que reconocen el tiempo y costo de mantener una documentacin completa y
actualizada. En este sentido, las metodologas giles respetan la importancia de la
documentacin como parte del proceso y del resultado de un proyecto de desarrollo
de software, sin embargo, con la misma claridad hacen nfasis en que se deben
producir los documentos estrictamente necesarios; los documentos deben ser cortos
y limitarse a lo fundamental, dando prioridad al contenido sobre la forma de
presentacin. La documentacin, en las metodologas giles procura mecanismos
ms dinmicos y menos costosos como son la comunicacin personal, el trabajo en
equipo, la autodocumentacin y los estndares. (Elicer Herrera Uribe, 2007).

- Ademas del Customer collaboration over contract negotiation (Agile Alliance,
2014), que se refiere a tener una constante colaboracin con el cliente.











5




3. Ventajas y Desventajas de RAD
5

Ventajas Desventajas
Los entregables pueden ser fcilmente
trasladados a otra plataforma.
Costos de herramientas integradas y equipo
necesario (equipo humano con mayor
desarrollo profesional).
El desarrollo se realiza a un nivel de
abstraccin mayor.
Progreso ms difcil de medir.
Visibilidad temprana (el cliente puede
tener un avance de proyecto ms rpido).
Menos eficiente.
Mayor flexibilidad. Menor precisin cientfica.
Menor codificacin manual. Mas fallas (por sndrome de codificacin
mal hecha)
Mayor involucramiento de los usuarios. Prototipos pueden no escalar (actualizables
a futuro).
Posiblemente Menor costo. Funciones reducidas.
Posiblemente Menos fallas. Dependencia en componentes de terceros
funcionabilidad de ms o menos
(reutilizacin de software).
Ciclos de desarrollo ms pequeos. No se obtiene control total del software
debido a sus componentes reutilizables.












5
(2012, 08). Metodologa RAD. Metodologa RAD. Recuperado 06, 2014, de
http://metodologiarad.weebly.com/

6





4. Etapa de planificacin de los requisitos
Esta etapa requiere que usuarios con un vasto conocimiento de los procesos de la compaa
determinen cules sern las funciones del sistema. Debe darse la discusin estructurada
sobre los problemas de la compaa que necesita solucin.
Por lo general esta etapa se completa rpidamente cuando se crean equipos que envuelven
usuarios y ejecutivos con un conocimiento amplio sobre las necesidades de la institucin, la
planificacin de los requisitos se da en modalidad de taller, conocido como la junta de
planificacin de requisitos (JRP por sus siglas en ingles)
Etapa de diseo
Esta consiste de un anlisis detallado de las actividades de la compaa en relacin al
sistema propuesto. Los usuarios participan activamente en talleres bajo la tutela de
profesionales de la informtica. En ellos descomponen funciones y definen entidades
asociadas con el sistema. Una vez se completa el anlisis se crean los diagramas que
definen las alteraciones entre los procesos y la informacin al finalizar el anlisis se traza el
diseo del sistema. Se desarrollan los procedimientos y los esquemas de pantallas los
prototipos de procedimiento crticos se construyen y se repasan y el plan para implementar
el sistema se prepara.
Generacin de aplicaciones
El proceso RAD trabaja para volver a utilizar componentes de programas ya existentes
(cuando es posible) o a crear componentes reutilizables (cuando sea necesario) En todos los
casos se utilizan herramientas automticas para facilitar la construccin del software.
Pruebas de entrega
El proceso RAD enfatiza la reutilizacin de los componentes de los programas ya
comprobados. Esto reduce tiempo de pruebas. Sin embargo, se debe probar todos los
componentes nuevos y ejercitar todas las interfaces a fondo.






7





Tabla comparativa
6
RAD, XP y SCRUM

Caractersticas RAD XP SCRUM
Iteraciones Ms corto que XP y
SCRUM
Cortas: 1 da a 1
mes
Segn los sprints, puede
ser 2 semanas o 1 mes
Miembros de equipo Es el trabajo en
equipo, personal de
negocio (usuarios),
analistas de
procesos y
funcionales
Se requiere de un
usuario como
miembro
Auto-organizados
Documentacin Se produce la
documentacin
necesaria para
facilitar el
desarrollo y
funcionamiento a
futuro
No requiere casi
documentacin
Poca documentacin
Reuniones La activa
participacin de los
usuarios es
imprescindible
Requiere de reuniones
diarias
Cambios dentro de las
iteraciones
Proporcionar ms
facilidad de cambio
durante el proceso
de desarrollo
Los requisitos
pueden cambien en
cualquier momento
Una vez que el sprint
inicia, el cliente no puede
cambiar requisitos hasta
que termine el sprint
Desarrollo de las
iteraciones
Intenta reducir los
riesgos del proyecto
dividindolo en
pequeos segmentos
Se desarrolla en un
orden estricto
El equipo es libre de elegir
las caractersticas que se
desarroll
Papel de un entrenador Incluye el JAD
(joint application
development)

Ciclo de vida de
desarrollo
Se le conoce como
iteracin
Se le conoce como
iteracin
En scrum se llama sprint
Trabaja con gente
experimentada
No sucede esto Los tcnicos debe tener
amplio conocimiento

6
Wordpress. (s.f.). curiosisimos.files.wordpress. Recuperado el 16 de Junio de 2014, de
curiosisimos.files.wordpress: http://curiosisimos.files.wordpress.com/2009/12/modelo-
de-desarrollo-rapido-de-aplicaciones.pdf

8

Costos Alto Alto Bajo
Trabaja en funcin de
jerarquas

Se basa en componentes
Orientado a la calidad
Reutilizacin del cdigo
Aplicable para proyectos
grandes, medianos y
pequeos





































9







Ejercicio 3
En este ejercicio nos enfocaremos en algunos artefactos con los que cuentan las
metodologas agiles y en particular la metodologa RAD.
Artefactos
Las metodologas giles en su mayora tienden a minimizar la cantidad de artefactos
generados en un proyecto. El nfasis est puesto en el cdigo entregado. Sin embargo,
existen muchos artefactos necesarios para propsitos de comunicacin, diseo, gestin sin
los cuales un proyecto no llegara al xito.

Posicionamiento
Situacin actual
El desarrollo del sistema es una innovacin y una herramienta de integracin para personas
con distinto tipo de discapacidad, debido que el actual sistema solo es posible acceder solo
de forma manual a travs de la utilizacin de un mouse y teclado que puede significar un
grado de dificultad para las personas discapacitadas

Stakeholders y usuarios
Stakeholders
Director de Biblioteca
Biblioteclogos
Personas con algn grado de discapacidad

Usuarios
Personas con algn grado de discapacidad fsica sin importar rango etario



10

Caractersticas del Sistema
El sistema debe facilitar el acceso a los fondos disponibles de las instituciones
pertenecientes al a red de bibliotecas publicas
El sistema debe permitir la consulta de obras de la literatura nacional e internacional a
travs de la red

El sistema debe proporcionar un servicio de bsqueda y referencia de informacin que
posibilite la conversin a un formato digital de artculos libros y documentos en general

Requisitos no Funcionales
El sistema debe poseer la capacidad de ampliar o reducir el tamao de letra El sistema debe
permitir el ingreso a los servicios de
Limitaciones del Sistema
Para utilizar el sistema tiene que estar conectado a la red
Solo se puede utilizar el sistema si es un usuario asociado

Lista de riesgos .
Realizaremos una lista con los riesgos que se pueden encontrar en el conjunto de objetivos
especficos (se ha de tomar en cuenta que para este ejercicio de tomaron los riesgos mas
relevantes):
Enunciado;
Considere el siguiente caso de estudio desarrollado por el seor Abel Ponce Surez
(abelponce@bnjm.cu), en el proyecto titulado Proyecto de Biblioteca Digital para usuarios
con discapacidades de la sala Frank Emilio. Biblioteca Nacional Jos Mart, Cuba, y
desarrolle todos los artefactos que propone RAD.
El proyecto considera el desarrollo de una Biblioteca Digital que emplea estndares de
accesibilidad, dirigida a nios, jvenes y adultos con algn tipo de discapacidad fsica y que
permite la consulta de obras de la literatura nacional e internacional a travs de la red, al
mismo tiempo que propicia un servicio de referencia y bsqueda de informacin
especializada que posibilita la conversin a formato digital de artculos, libros y otros
documentos que resultan de inters para nuestros usuarios asociados.
Se hace referencia tambin al hecho de que la Biblioteca Nacional Jos Mart, en su
condicin de depositaria de la memoria histrica de la nacin cubana y de centro rector del
Sistema Nacional de Bibliotecas Pblicas, disea estrategias que facilitan el acceso y uso de
la informacin disponible sin excluir a ningn sector de la poblacin, entre ellas, la
organizacin de cursos, talleres y otras actividades que permiten actualizar a los

11

especialistas encargados del desarrollo de las publicaciones electrnicas de modo tal que se
trabaje hacia la estandarizacin de nuestra web sobre la base de una correcta programacin.
Y tuvo como objetivo general: Facilitar el acceso a la informacin disponible en los fondos
de las instituciones pertenecientes a la Red Nacional de Bibliotecas Pblicas de todos los
usuarios del sistema por igual. Adems, se propusieron un conjunto de objetivos
especcos, destacando:
1) Realizar un inventario de los fondos disponibles en las salas especializadas de las
bibliotecas del sistema y elaborar catlogos de fcil consulta en la red.

Riesgo 1:
Descripcin
el primero de los riesgos que podemos observar es el momento en que se realice el
inventario no se localicen o detallen la totalidad de las salas dentro del sistema
debido a que RAD exige ser veloz (en cuanto a das de desarrollo del software) en el
momento de su implementacin podran quedar fuera datos relevantes en cuanto al
sistema de la biblioteca
Criticidad
De presentarse este problema su criticidad es media.
Probabilidad de Ocurrencia
Baja
Impacto
El monitoreo del sistema debe ser de manera frecuente.
Estrategia de Mitigacin
Realizar una revisin del sistema de manera frecuente (cada dos o tres das).
Plan de Contingencia
Realizar una lista de objetivos alcanzados y una lista de revisin de tareas realizadas
en las que se detalles el resultado de las pruebas realizadas al sistema.
Riego 2:
Descripcin
Al momento de la realizacin de los catlogos la consulta en estos no sea tan fcil o
accesible para el usuario final.
Criticidad
Alta
Probabilidad de Ocurrencia
Media - Alta
Impacto
El monitoreo y las pruebas del sistema deben de ser de manera constante.
Estrategia de Mitigacin

12

Realizar pruebas del sistema con personas con discapacidad (voluntarios).
Plan de Contingencia
Al momento del desarrollo del software se realice con la supervisin de un
especialista en el rea (un mdico que se especialice en discapacidad).


2) Organizar y desarrollar un servicio de referencia y bsqueda de informacin
especializada para personas discapacitadas que posibilite al mismo tiempo la
conversin a formato digital de artculos, libros y documentos en general.

Riesgo:
Descripcin
Al momento de desarrollar la referencia y bsqueda de informacin esta no
posibilite la conversin del artculo en formato digital.
Criticidad
alta
Probabilidad de Ocurrencia
media
Impacto
El monitoreo del sistema debe de ser constante.
Estrategia de Mitigacin
Realizar una serie de pruebas del sistema.
Plan de Contingencia
Realizar una mantencin del sistema cada tres meses a contar de la entrega del
software en estado operativo al cliente.

3) Comenzar de inmediato, en la medida que las posibilidades tcnicas lo permitan, la
digitalizacin de las valiosas colecciones sonoras que actualmente se encuentran
disponibles en discos de vinilo, casetes o cintas de audio en nuestras bibliotecas con
el objetivo de preservarlas y ofertar un mejor servicio en nuestras salas, a la vez que
se pueda hacer extensible a la consulta directa de los asociados en la red.

Riesgo:
Descripcin
Que las colecciones sonoras se encuentren deterioradas, de manera que sea
imposible su conversin a digital.
Criticidad
Alta.
Probabilidad de Ocurrencia
Media Baja.
Impacto

13

Realizar la conversin de manera cuidadosa (todo depende del estado de
conservacin de la coleccin).
Estrategia de Mitigacin
Ejecutar la conversin con las herramientas adecuadas para la tarea.
Plan de Contingencia
Recurrir a un especialista del rubro.
4) Dados los altos costos de los programas destinados a facilitar el uso de las
computadores por personas discapacitadas, realizar con la mayor brevedad posible
estudios de factibilidad para el uso de lectores de pantalla, navegadores parlantes y
otras aplicaciones pertenecientes a la generacin de programas de cdigo abierto o
gratuitos, actualmente disponibles para su descarga en Internet (por ejemplo,
emplear la extensin Fire Vox para el navegador Firefox, o generalizar el empleo
del NVDA en sustitucin del JAWS, entre otras medidas).

Riesgo:
Descripcin
Que el estudio realizado de cmo resultado negativo, ya sea por no encontrar
aplicaciones gratuitas o por los costos que conlleva la utilizacin de lectores y
navegadores.
Criticidad
Alta
Probabilidad de Ocurrencia
Media Baja
Impacto
Tomar como prioridad una nueva bsqueda o estudio en la web.
Estrategia de Mitigacin
Realizar un nuevo estudio.
Plan de Contingencia
Evaluar otras opciones que nos pueda entregar el mercado.

Requerimientos del software .
A continuacin pasaremos a realizar la identificacin de los requerimientos en cada
uno de los pasos dentro del ejercicio:
Requerimientos funcionales
El sistema debe permitir la digitalizacin de material sonoro y que a su vez pueda
ser extendible a la consulta directa de los asociados a la red.
El sistema debe permitir un servicio de referencia y bsqueda de informacin para
personas con discapacidad.
El sistema debe permitir la conversin de artculos como libros y documentos a un
formato digital.
El sistema debe ser accesible (principalmente dirigido a nios y jvenes).

14

El sistema debe permitir consultas de obras de literatura nacional e internacional a
travs de la red.
Requerimientos suplementarios
Requerimientos no funcionales
El sistema de contar con un inventario de salas especializadas, como tambin con
catlogos de fcil consulta de red.
El sistema deber ser elaborado bajo una metodologa acorde con la iniciativa de
accesibilidad para la web (WAI).
El sistema deber poder compartir recursos en formatos de fcil acceso.
Restricciones
Debido a los costos altos de los programas para facilitar el uso de las computadoras
por personas con discapacidad se buscara implementar programas de cdigo abierto
o gratuito.
Actualizaciones de manera paulatina de la programacin y diseos ya existentes.
Reglas del negocio
Organizar convenios de trabajo sobre la creacin de consorcios bibliotecarios, con
centros de informacin y bibliotecas de otros ministerios, as como otras
instituciones encargadas de la atencin a personas con discapacidades fsicas, tanto
nacionales como internacionales.