1

Ingeniera de Software
Informe de Metodologa













Profesor:
Dr. Narciso Cerpa.

Integrantes:
Yannira Arancibia, Marcos Gutirrez, Gonzalo Pincheira, Felipe Venegas P.







Jueves, 14 de septiembre del 2007
2

ndice

1. Introduccin. 3
1.1. Que es una metodologa?
1.2. Que es una metodologa gil?
1.3. Los principales valores de una metodologa gil

2. Explicacin del Mtodo de Desarrollo ASD5
2.1. Caractersticas
2.2. Fases
2.2.1. Especular
2.2.2. Colaborar
2.2.3 Aprender

3. Tecnologa..8
3.1. Tecnologa del software
3.2. Plataforma
3.2. Lenguaje
3.3. Sistema Operativo

4. Tcnicas y herramientas...8


5. Actividades de gestin...10
5.1. Equipos de trabajo
5.1.1. Roles y responsabilidades
5.2. Documentacin
5.3. Relaciones
5.3.1. Con el grupo de trabajo
5.3.2. Con el usuario

6. Conclusin12

7. Referencias13

8. Glosario.14












3


1. Introduccin

En el siguiente manual explicaremos sobre la metodologa gil ASD (Adaptive
Software Development), como trabajar en ella, las fases de esta, el equipo que se debe
tener para poder trabajar correctamente, entre otras cosas.
Lo primero que debemos saber para poder empezar a trabajar con esta
metodologa es:

1.1. Que es una metodologa?

Es la que define como se debe realizar un proyecto de desarrollo de software,
respondiendo a las siguientes preguntas: Quin debe hacer Qu, Cundo y Cmo
hacerlo.
No existe una metodologa de software universal. Estas dependen de las
caractersticas y tamao de cada proyecto de software que se ah de realizar. Siendo las
metodologas giles las ms usadas en estos ltimos tiempos.

1.2. Qu es una metodologa gil?

Es una estrategia de desarrollo de software que promueve prcticas que son
adaptativas en vez de predictivas; centradas en las personas o los equipos, iterativas,
orientadas hacia la funcionalidad y la entrega, de comunicacin intensiva y que
requieren implicacin directa de cliente. Este tipo de metodologa se creo con la
necesidad de agilizar y automatizar los procesos de desarrollo de software. Estas
metodologas proponen simplicidad y velocidad para crear sistemas.

Los principales valores de la metodologa gil son:

a) Al individuo y las interacciones del equipo de desarrollo sobre el proceso y
las herramientas: La gente es el principal factor de xito de un proyecto
software. No se necesitan grandes desarrolladores sino los que se adapten
bien al trabajo del equipo. Las herramientas son importantes para mejorar el
rendimiento del equipo, pero no en demasa ya que pueden afectar porque
puede afectar negativamente. Una vez que se crea un buen equipo estos
deben crear su entorno en base a sus propias necesidades.

b) Desarrollar software que funciona ms que conseguir una buena
documentacin: La regla a seguir es no producir documentos a menos que
sean necesarios de forma inmediata para tomar una decisin importante,
deben ser cortos y centrarse en lo fundamental. En caso de integracin de un
nuevo integrante al equipo de trabajo, las herramientas que le van a servir
para ponerse al da son el cdigo y la interaccin con el equipo.


c) La colaboracin con el cliente ms que la negociacin de un contrato: Esta
colaboracin entre ambos ser la que marque la marcha del proyecto y
asegure su xito.


4

d) Responder a los cambios ms que seguir estrictamente un plan: la
planificacin no debe ser estricta puesto que hay muchas variables en juego,
debe ser flexible para poder adaptarse a los cambios que puedan surgir. Una
buena estrategia es hacer planificaciones detalladas para unas pocas semanas
y planificaciones mucho ms abiertas para unos pocos meses. Mientras ms
habilidad tenga el equipo para responder a los cambios del proyecto en el
camino, menos posibilidad de fracaso tendrn en este.


Para saber si su proceso de desarrollo de software es gil debe cumplir los
siguientes requisitos.
Incremental. Entregas pequeas de software, con ciclos rpidos.
Cooperativo. Cliente y desarrolladores trabajan juntos constantemente con una
cercana comunicacin.
Sencillo. El mtodo en s mismo es simple, fcil de aprender y modificar.
Esta bien documentado y es adaptable. Permite realizar cambios de ltimo
momento).
1.3. Ventaja de las metodologas giles
Alguna de las ventajas que tienen las metodologas giles son:
a) Entrega continua y en plazos cortos de software funcional.
b) Trabajo conjunto entre el cliente y el equipo de desarrollo.
c) Minimiza los costos frente a cambios.
d) Importancia de la simplicidad, al eliminar el trabajo innecesario.
e) Atencin continua a la excelencia tcnica y al buen diseo.
f) Mejora continua de los procesos y el equipo de desarrollo.
g) Evita malentendidos de requerimientos entre el cliente y el equipo.
h) El equipo de desarrollo no malgasta el tiempo y dinero del cliente
desarrollando soluciones innecesariamente generales y complejas que en
realidad no son un requisito del cliente.
i) Cada componente del producto final ha sido probado y satisface los
requerimientos.
Luego de haber conocido los trminos bsicos de lo que son las metodologas
giles, nos enfocaremos en explicar como implementar la metodologa ASD en el
desarrollo de un proyecto de software.










5

2. Explicacin de la Metodologa ASD

La metodologa ASD es una metodologa gil y posee ciertas caractersticas que la
diferencian de otras como la XP, Scrum o Cristal pero si se quisiera comparar con
alguna de las metodologas giles se podra comparar con Scrum ya que tienen unos
cuantos puntos en comn sobre la utilizacin de prcticas para la construccin del
software.
En cuanto a documentacin y tecnologa ASD no tiene herramientas o tcnicas para
abordar estos puntos por lo que esto debe ser acordado por el grupo de trabajo tomando
en cuenta la agilidad con la que se debe abordar el problema y con las caractersticas
propias que posee el grupo de desarrolladores del proyecto.



2.1. Caractersticas

Su impulsor es Jim Highsmith. Sus principales caractersticas son:

- Iterativo: Ya que la base de esta metodologa se enfoca en un ciclo de vida.

- Orientado en los componentes del software: Definiendo este como un grupo de
funcionalidades a ser desarrolladas durante un ciclo de vida.

- Tolerante a cambios: Fcil adaptacin a cambios repentinos de requerimientos,
ya sean estos implantados por el usuario o el anlisis del grupo de trabajo.

2.2. Fases

Las fases en las que se trabaja la metodologa ASD son tres: Especular,
Colaborar y Aprender (Especulate, collaborate, learn). Estas fases o Etapas
corresponden al llamado "Ciclo de Vida" con el cul esta metodologa se identifica.

Sabiendo del carcter adaptativo de esta metodologa, ASD nos permite tomar
pequeas "desviaciones" en cada fase en que cada ciclo debe componerse de una mezcla
entre funcionalidades crticas, tiles y opcionales, en donde deben priorizarse las
crticas ya que son las que ponen en jaque el proyecto, luego las tiles, que facilitaran el
desarrollo del sistema y por ltimo las opcionales las cuales no son imprescindibles en
el proyecto. Todo esto con tal de prever futuros retrasos en el proyecto.











6

Tambin se pueden tomar grandes desviaciones las cuales son beneficiosas para
el sistema, ya que se utilizan para la exploracin del dominio y la aplicacin.





2.2.1. Especular:

Esta fase consiste en realizar una planificacin tentativa del proyecto tomando
en cuenta las futuras entregas que se le darn al usuario protipos.
En esta fase se fija un rumbo determinado el cul ser seguido en la parte de desarrollo
y toma mayor nfasis en cada iteracin ya que ASD posee la caractersticas de usar cada
iteracin para APRENDER por lo que en el momento de especular en las futuras
iteraciones esto ser de gran importancia ya que trabajaremos en funcin de esto para
as abordar de una manera mas efectiva y planificada nuestra especulacin.


2.2.2. Colaborar:

Esta Fase del llamado ciclo de vida, es en la que se toma el rumbo mencionado
antes, en la etapa de especulacin, donde se construir la funcionalidad del proyecto.
Durante cada Iteracin el equipo se preocupa de colaborar fuertemente para que de esta
manera se logre liberar la funcionalidad planificada. En esta parte tambin es posible
explorar nuevas alternativas pudiendo alterar fuertemente el rumbo del proyecto, pero
esta es una de las razones por las que ASD est dentro de la categora de metodologas
giles.
ASD no propone tcnicas ni tareas en la etapa de construccin, lo que hace es
mencionar que todas las prcticas e ideas que se llevan a cabo con el fin de reforzar la
colaboracin entre los desarrolladores del proyecto (otro punto que hace referencia al
concepto de metodologas giles). La importancia de la colaboracin se debe establecer
en la relacin entre las personas, las cuales deben estar suficientemente fuertes y claras
para se pueda arreglar cualquier circunstancia compleja que se presente: emergencias*.





7

2.2.3. Aprender:

Esta Fase es la ltima en cada ciclo y consiste en la revisin de calidad donde se
analizan 4 categoras:

Calidad del resultado de la desde la perspectiva del cliente:

En esta parte se sugiere, para lograr evaluar la calidad desde el punto de
vista del cliente, utilizar grupos de enfoque hacia el cliente con tal de
recoger nuevos requerimientos o cambios que el cliente pueda requerir.


Calidad del resultado de la desde la perspectiva tcnica:

Esto consiste en analizar la calidad del producto revisando el diseo, el cdigo
y las pruebas en funcin de lograr aprender de los errores y desvos empleados para
poder resolverlos, y esto implica no poner nfasis en encontrar culpables ya que esto
afectara las relaciones entre el grupo de trabajo.
Seguido a esto viene la parte prctica de esta etapa en la cual se profundiza
en las exploraciones que se hayan realizado con lo cual podremos modificar ya sea el
diseo del sistema, o los posibles cambios de requerimientos que nos de el cliente.


Funcionamiento del equipo de desarrollo y las prcticas que este utiliza:

En esta etapa del aprendizaje se enfatiza la interaccin entre las partes, la
dinmica del grupo y las tcnicas que se acordaron emplear. Es importante que al final
de cada ciclo de vida (postmortem), se realicen pequeas reuniones con el fin de
analizar lo aprendido
Antes de realizar una iteracin, se discuten los procesos que favorecen el
desarrollo del proyecto y asimismo descartar los de influencia negativa siendo estos
ltimos, los procesos que puedan haber afectado el trabajo del grupo y los que no son
compatibles con los requerimientos.

Status del proyecto:

Esta ultima etapa, se revisa todo lo efectuado respecto al proyecto en funcin de
lo que inicialmente se haba planificado, tanto en la parte tcnica como en la humana.
En este momento es en donde se detectaran las posibles diferencias que podran cambiar
el rumbo del proyecto.
Una vez que exploramos las 3 fases, se realiza el bucle de aprendizaje (learning
loop), en el cual se realizan revisiones de calidad con presencia del cliente como
experto.
La presencia del cliente se suplementa con sesiones de talleres en el que
programadores y representantes del cliente se encuentran para discutir rasgos del
producto en trminos no tcnicos, sino que de negocios.

8





























3. Tecnologa

En todo proyecto, si bien la parte de planificacin y especulacin es importante,
tambin tenemos la parte de tecnologa que es casi la ms importante ya que esta
condicionara procesos del desarrollo del sistema. Ser la que se llevar a la prctica en
el momento de presentar el producto final y en donde se trabajar en base a los
requerimientos anteriormente capturados al cliente.

3.1. Tecnologa del Software

Para ASD la tecnologa ms usada y ms efectiva a la hora de programar y
realizar el proyecto es la orientada a objetos ya que hoy en da ya no se aplica solamente
a los lenguajes de programacin, adems se viene aplicando en el anlisis y diseo con
mucho xito. Es que para hacer una buena programacin orientada a objetos hay que
desarrollar todo el sistema aplicando esta tecnologa, de ah la importancia del anlisis y
el diseo orientado a objetos.

En cuanto a la programacin, la orientada a objetos (POO) es una de las formas
ms populares de programar y viene teniendo gran acogida en el desarrollo de proyectos
de software desde los ltimos aos. Esto se debe a sus grandes capacidades y ventajas
frente a las antiguas formas de programar.
9

Luego de esta introduccin surge la pregunta: Cules son las ventajas de un
lenguaje orientado a objetos?
Las ventajas ms importantes son las siguientes:
Fomenta la reutilizacin y extensin del cdigo.
Permite crear sistemas ms complejos.
Relacionar el sistema al mundo real.
Facilita la creacin de programas visuales.
Construccin de prototipos
Agiliza el desarrollo de software
Facilita el trabajo en equipo
Facilita el mantenimiento del software
Lo interesante de la POO es que proporciona conceptos y herramientas con las
cuales se modela y representa el mundo real tan fielmente como sea posible y mas
importante aun, se adapta perfectamente a la metodologa de desarrollo ASD tomando
en cuenta que el agilizar el desarrollo de software y la construccin de prototipos, por
nombrar algunas caractersticas, es propio de las metodologas giles.
Dentro de la tecnologa de software distinguimos las siguientes la plataforma, el
lenguaje y el sistema operativo.

3.1.2. Plataforma

Respecto a la plataforma, el grupo de trabajo debe poder elegir la mas adecuada para
satisfacer las necesidades y compatibilizar esto con el lenguaje de programacin que se
usar para dar solucin a los requerimientos del cliente.






3.1.2. Lenguaje
Hay una buena variedad de lenguajes de programacin orientados a objetos que
se adaptan perfectamente a las metodologas giles .Por nombrar las mas usadas y
conocidas tenemos C++ que es una adaptacin de C pero con conceptos de POO,
tambin est JAVA que hereda los conceptos introducidos a C++ y por ultimo tenemos
C# que combina los mejores elementos de C++ y JAVA.


3.1.3. Sistema Operativo

El sistema operativo en donde se ejecutar el proyecto ser el cual el cliente pida
y el grupo de trabajo debe ser capaz de lograr realizarlo y ejecutarlo bajo el SO deseado.


10

4. Tcnicas y herramientas

Esta metodologa no propone tcnicas ni tareas al momento de llevar la
construccin, simplemente ocuparemos las prcticas que sirvan para reforzar el
desarrollo del sistema., siguiendo de esta forma la lnea de las metodologas giles
respecto a la orientacin a componentes. El nfasis se ubica en las relaciones entre las
personas, las cuales deben estar lo suficientemente buenas para lograr sacar lo mejor, si
estamos en momentos crticos del desarrollo.
En la fase de la especulacin, se recomienda utilizar un Component Breakdown
Structure (CBS) en el cual mediante una grilla u hoja de clculo se pueda conocer la
funcionalidad que ser entregada en cada ciclo desarrollado. Otra tcnica que se
recomienda son las sesiones JAD para capturar los requerimientos del software y la
realizacin de prototipos para descifrar ambigedades que se presenten en el desarrollo.
Algunas de las tcnicas de planificacin y de control de actividades ms
empleadas en las metodologas de desarrollo son la carta Gantt y el diagrama Pert.
Las herramientas para emplear las tcnicas mencionadas tienen que ser las que
mejor se adapten o en las que mejor dominio se tenga.




5. Actividades de gestin

Dentro de las actividades de gestin tenemos la definicin del equipo de trabajo,
los roles, responsabilidades, la documentacin y la comunicacin.

5.1. Equipos de trabajo

El grupo se dividir en equipo de trabajo, los cuales tendrn designados roles
especficos llevando as determinadas responsabilidades para lograr una eficiente
creacin del sistema. Los equipos de trabajo deben ser pequeos, para facilitar la
comunicacin, deben estar bien capacitados para no bajar el nivel en general, ya que si
uno de los integrantes no est haciendo bien su labor, se ve reflejado en el trabajo
completo del equipo.

5.1.1. Roles y responsabilidades

Los roles y responsabilidades sern:

Clientes: Este rol juega un papel muy importante, ya que este ser parte activa
del equipo de trabajo, aportando y funcionalidades al sistema. Adems es
esencial para el xito del mismo, ya que un software que no tiene aceptacin
dentro de la organizacin jams llegara a ser construido a tiempo, forma y con
consentimiento de los usuarios.

Lder del proyecto: Tiene a cargo la planificacin del proyecto a lo largo de
todo el ciclo de vida, asigna recursos y delega responsabilidades en los mismos;
fomenta la unin del grupo haciendo actividades destinadas a eliminar roces
dentro de este, adems monitorea el progreso del proyecto y establece estrategias
para mitigar los riesgos que puedan presentarse dentro del desarrollo. El lder del
11

proyecto representa la cara visible del equipo de desarrollo, vendra siendo como
un nexo entre cliente y el equipo desarrollo.

Programador: Tiene a cargo la codificacin de los componentes a desarrollar
en cada iteracin, el posee los materiales y lleva a cabo la implementacin de los
requerimientos capturados.

Desarrolladores: Tiene a cargo la construccin lgica del software y la
continua refinacin de la misma en cada iteracin. Estar a cargo de la creacin
de la interfaz del software.

Tester: Tiene a su cargo la generacin de pruebas al sistema a partir de los
requerimientos extrados y analizados. La importancia radica en la necesidad de
construir un software de calidad que cumpla con los requerimientos del usuario.




5.2. Documentacin

Si bien es sabido que las metodologas giles no tienen mucha ceremonia en
ASD se entregan dos tipos de documentos: En el primero se incluye una visin del
proyecto, una hoja de datos, un perfil de la misin del producto y un esquema de su
requerimiento, este se entrega cuando el equipo tiene una idea general de lo que tratar
el sistema para poder realizar la iniciacin del proyecto. En el segundo se entrega una
descripcin del sistema, esta se entrega al finalizar el proyecto para analizar el software
conjuntamente con el usuario.

5.3. Relaciones

Esta metodologa necesita una constante forma de comunicacin entre los
desarrolladores y el cliente. Tanto para facilitar al usuario expresar lo que necesita como
para que los diseadores puedan plasmar todo lo que les pide el usuario.


5.3.1.Con el grupo de trabajo


Se deben realizar reuniones semanales para estar al tanto en los avances del
proyecto y en lo que se debe realizar para este. Tambin al final de cada ciclo se hace
una reunin para analizar lo aprendido y ver los errores que se cometieron.

5.3.2. Con el usuario

Se tienen reuniones aproximadamente cada dos semanas, para ver si cliente tiene
nuevos requisitos para el proyecto o para aclarar algunos que no se hayan dejado muy
claros, si fuese as todo esto podra cambiar el rumbo del proyecto.



12

6. Conclusin

La caracterstica, quizs de mayor importancia de la metodologa ASD es el
Feedback que plantea en la fase de aprendizaje, el cual nos da la posibilidad de entender
mas respecto al dominio y construir el sistema que satisfaga de mejor manera las
necesidades del cliente. El creador de esta metodologa expone esto claramente en la
siguiente frase:

En ambientes complejos, el seguir un plan al pie de la letra produce el producto que
pretendamos, pero no es el producto que necesitamos

Esta metodologa de desarrollo nos permite encarar la construccin del software
en forma gil utilizando las tcnicas y herramientas que nos resulten conveniente en
cada caso.




































13

7. Referencias

- RIEHLE, Dirk. A Comparison of the Value Systems of Adaptive Software
Development and Extreme Programming: How Methodologies May
Learn from Each Other [en linea].
Disponible en World Wide Web: <http://www.riehle.org/computer-science/research/2000/xp-
2000.html>[consulta: Viernes 7 de Septiembre 2007].

- ABRAHAMSSON, Pekka. Salo, Outi and Ronkainen, Jussi; Agile Software
Development methods, review and analysis [en linea]. Disponible en World Wide Web:
<http://www.vtt.fi/inf/pdf/publications/2002/P478.pdf> [consulta: Viernes 7 de Septiembre
2007].

- FOWLER, Martn. The New Methodology, Abril 2003 [en linea]. Sierra Alejandro
[traduccin]. Disponible en World Wide Web: <
http://www.programacionextrema.org/articulos/newMethodology.es.html> [consulta:
Domingo 9 de Septiembre 2007].

- REYNOSO, Carlos. Mtodos Heterodoxos en Desarrollo de Software, Abril 2004[en
linea]. Disponible en World Wide Web: <
www.sel.unsl.edu.ar/ApuntesMaes/2004/Metodologias%20Agiles.doc > [consulta: Lunes 10
de Septiembre 2007].

- SCHENONE, Marcelo. Diseo de una Metodologa gil de Desarrollo de
Software [en linea]. Disponible en World Wide Web: <
http://www.fi.uba.ar/materias/7500/schenone-tesisdegradoingenieriainformatica.pdf>
[consulta: Sabado 8 de Septiembre 2007].

- CANOS, Jose. Letelier, Patricio and Penads, M Carmen; Metodologas giles en
el Desarrollo de Software [en linea], Disponible en World Wide Web: <
http://www.willydev.net/descargas/prev/TodoAgil.Pdf > [consulta: Sabado 8 de
Septiembre 2007].






















14

8 Glosario

Adaptabilidad. Facilidad con la que un sistema o un componente puede modificarse
para corregir errores, mejorar su rendimiento u otros atributos, o adaptarse a cambios
del entorno.

Anlisis de requisitos. (1) Proceso de estudio de las necesidades del usuario para
conseguir una definicin de los requisitos del sistema o del software.
(2) Proceso de estudiar y desarrollar los requisitos del sistema o del software.

Ciclo de vida. Periodo de tiempo que comienza con la concepcin del producto de
software y termina cuando el producto esta disponible para su uso.
Normalmente, el ciclo de vida del software incluye las fases de concepto, requisitos,
diseo, implementacin, prueba, instalacin, verificacin, validacin, operacin y
mantenimiento y, en ocasiones, retirada. Nota: Esta fases pueden superponerse o
realizarse iterativamente.

COCOMO. (Construvtive Cost Model) Modelo constructivo de costes, desarrollado
por B.W. Boehm a finales de los 70, y expuesto en su libro Software Engineering
Economics. Es una jerarqua de modelos de estimacin de costes que incluye los sub-
modelos: bsico, intermedio y detallado.

Codificacin. (1) Proceso de descripcin de un programa de ordenador en un lenguaje
de programacin. (2) Transformacin del diseo lgico y dems especificaciones de
diseo en un lenguaje de programacin.

Compatibilidad. (1)Preparacin de dos o ms componentes o sistemas para llevar a
cabo sus funciones mientras comparten el mismo entorno de hardware o software. (2)
Capacidad de dos o ms sistemas o componentes para intercambiar informacin.

Componente. Es un grupo de funcionalidades a ser desarrolladas durante un ciclo
iterativo.

Descripcin del sistema. Documento orientado al cliente que describe las
caractersticas del sistema desde el punto de vista del usuario final. El documento se
utiliza para coordinar conjuntamente los objetivos del sistema del usuario, cliente,
desarrollador e intermediarios.
Tambin se denomina: ConOps (Conceptof Operation std. IEEE 1362). Requisitos del
sistema (ISO IEC 12207 1995, 5.1.1.2)

Diseo. (1) Proceso de definicin de la arquitectura, componentes, interfaces y otras
caractersticas de un sistema o de un componente. (2) El resultado de este proceso.

Diseo de arquitectura. (1) Proceso que define una coleccin de componentes de
software y hardware junto con sus interfaces, para definir el marco de desarrollo de un
sistema. Ver tambin: diseo funcional.
(2) El resultado del proceso de (1).

Diseo funcional. (1) Proceso de definicin de las relaciones de trabajo entre los
componentes de un sistema. (2) El resultado del proceso (1)
15

Emergencia. Es una propiedad de los sistemas adaptativos complejos que crea alguna
propiedad ms grande del todo a partir de la interaccin de las partes. Gracias a esta
propiedad los grupos de desarrollo logran sacar lo mejor de s en el borde del caos.

JAD: taller en el que programadores y representantes del cliente se encuentran para
discutir rasgos del producto en trminos no tcnicos, sino de negocios.

Mantenimiento. (1)Proceso de modificacin de un sistema de software o de un
componente, despus de su puesta en funcionamiento para corregir fallos, mejorar el
rendimiento u otros atributos, o adaptarlo a modificaciones del entorno. (2) Proceso
primario del modelo de ingeniera que desarrolla tareas de mantenimiento (1).

Modelo de ciclo de vida. Representacin del ciclo de vida del software.

Obtencin. (aplicado a requisitos). Proceso en el que se implican las partes cliente y
desarrolladora para descubrir, revisar, articular y comprender las necesidades y
limitaciones que el sistema debe ofrecer a los usuarios.

POO (Object-Oriented Programming) Programacin orientada por objetos. Mtodo de
implementacin de los programas que los organiza como grupos cooperativos de
objetos, cada uno de los cuales representa instancias de una clase, que a su vez forman
parte de una jerarqua a travs de relaciones de herencia.

PERT. (Program Evaluation and Review Technique) Mtodo para el control de los
tiempos de ejecucin de diversas actividades integrantes de proyectos. Fue desarrollado
en 1957 por la armada de los Estados Unidos.
Actualmente se utilizan sus principios en combinacin con los del mtodo CPM en lo
que se conoce como PERT/CPM

Prototipo. Versin preliminar de un sistema que sirve de modelo para fases posteriores.

Rapid Application Development. (RAD) Denominacin genrica para tcnicas y
herramientas de desarrollo de software que permiten el desarrollo rpido de
aplicaciones.

Requisito. (1) Condicin o facultad que necesita un usuario para resolver un problema.
(2) Condicin o facultad que debe poseer un sistema o un componente de un sistema
para satisfacer una especificacin, estndar, condicin de contrato u otra formalidad
impuesta documentalmente. (3) Documento que recoge (1) o (2).

Sistema. Conjunto de procesos, hardware, software, instalaciones y personas necesarios
para realizar un trabajo o cumplir un objetivo.

Sistema de software. Conjunto de programas de ordenador, procedimientos y
opcionalmente la documentacin y datos asociados, necesarios para el funcionamiento
de un sistema.

Software. Los programas de ordenador, procedimientos, y opcionalmente la
documentacin y los datos asociados que forman parte de un sistema.

16