Informe de Metodologia

Ingeniería de Software
Informe de Metodología
Profesor:
Dr. Narciso Cerpa.
Integrantes:
Yannira Arancibia, Marcos Gutiérrez, Gonzalo Pincheira, Felipe Venegas P.
Jueves, 14 de septiembre del 2007
1
Índice
1. Introducción……………………………………………………………………. 3
1.1. ¿Que es una metodología?
1.2. ¿Que es una metodología ágil?
1.3. Los principales valores de una metodología ágil
2. Explicación del Método de Desarrollo ASD……………………………………5
2.1. Características
2.2. Fases
2.2.1. Especular
2.2.2. Colaborar
2.2.3 Aprender
3. Tecnología………………………………………………………………………..8
3.1. Tecnología del software
3.2. Plataforma
3.2. Lenguaje
3.3. Sistema Operativo
4. Técnicas y herramientas……………………………..…………………………….8
5. Actividades de gestión……………………………..…………………………….10
5.1. Equipos de trabajo
5.1.1. Roles y responsabilidades
5.2. Documentación
5.3. Relaciones
5.3.1. Con el grupo de trabajo
5.3.2. Con el usuario
6. Conclusión…………………………………………………………………………12
7. Referencias…………………………………………………………………………13
8. Glosario…………………………………………………………………………….14
2
1. Introducción
En el siguiente manual explicaremos sobre la metodología á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
metodología es:
1.1. ¿Que es una metodología?
Es la que define como se debe realizar un proyecto de desarrollo de software,
respondiendo a las siguientes preguntas: Quién debe hacer Qué, Cuándo y Cómo
hacerlo.
No existe una metodología de software universal. Estas dependen de las
características y tamaño de cada proyecto de software que se ah de realizar. Siendo las
metodologías ágiles las más usadas en estos últimos tiempos.
1.2. ¿Qué es una metodología ágil?
Es una estrategia de desarrollo de software que promueve prácticas que son
adaptativas en vez de predictivas; centradas en las personas o los equipos, iterativas,
orientadas hacia la funcionalidad y la entrega, de comunicación intensiva y que
requieren implicación directa de cliente. Este tipo de metodología se creo con la
necesidad de agilizar y automatizar los procesos de desarrollo de software. Estas
metodologías proponen simplicidad y velocidad para crear sistemas.
Los principales valores de la metodología á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 demasía 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 más que conseguir una buena
documentación: La regla a seguir es no producir documentos a menos que
sean necesarios de forma inmediata para tomar una decisión importante,
deben ser cortos y centrarse en lo fundamental. En caso de integración de un
nuevo integrante al equipo de trabajo, las herramientas que le van a servir
para ponerse al día son el código y la interacción con el equipo.
c) La colaboración con el cliente más que la negociación de un contrato: Esta
colaboración entre ambos será la que marque la marcha del proyecto y
asegure su éxito.
3
d) Responder a los cambios más que seguir estrictamente un plan: la
planificación 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 más abiertas para unos pocos meses. Mientras más
habilidad tenga el equipo para responder a los cambios del proyecto en el
camino, menos posibilidad de fracaso tendrán en este.
Para saber si su proceso de desarrollo de software es ágil debe cumplir los
siguientes requisitos.
•
•
•
•
Incremental. Entregas pequeñas de software, con ciclos rápidos.
Cooperativo. Cliente y desarrolladores trabajan juntos constantemente con una
cercana comunicación.
Sencillo. El método en sí mismo es simple, fácil de aprender y modificar.
Esta bien documentado y es adaptable. Permite realizar cambios de último
momento).
1.3. Ventaja de las metodologías ágiles
Alguna de las ventajas que tienen las metodologías ágiles son:
a)
b)
c)
d)
e)
f)
g)
h)
Entrega continua y en plazos cortos de software funcional.
Trabajo conjunto entre el cliente y el equipo de desarrollo.
Minimiza los costos frente a cambios.
Importancia de la simplicidad, al eliminar el trabajo innecesario.
Atención continua a la excelencia técnica y al buen diseño.
Mejora continua de los procesos y el equipo de desarrollo.
Evita malentendidos de requerimientos entre el cliente y el equipo.
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 términos básicos de lo que son las metodologías
ágiles, nos enfocaremos en explicar como implementar la metodología ASD en el
desarrollo de un proyecto de software.
4
2. Explicación de la Metodología ASD
La metodología ASD es una metodología ágil y posee ciertas características que la
diferencian de otras como la XP, Scrum o Cristal pero si se quisiera comparar con
alguna de las metodologías ágiles se podría comparar con Scrum ya que tienen unos
cuantos puntos en común sobre la utilización de prácticas para la construcción del
software.
En cuanto a documentación y tecnología ASD no tiene herramientas o técnicas 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 características
propias que posee el grupo de desarrolladores del proyecto.
2.1. Características
Su impulsor es Jim Highsmith. Sus principales características son:
-
Iterativo: Ya que la base de esta metodología 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: Fácil adaptación a cambios repentinos de requerimientos,
ya sean estos implantados por el usuario o el análisis del grupo de trabajo.
2.2. Fases
Las fases en las que se trabaja la metodología ASD son tres: Especular,
Colaborar y Aprender (Especulate, collaborate, learn). Estas fases o Etapas
corresponden al llamado "Ciclo de Vida" con el cuál esta metodología se identifica.
Sabiendo del carácter adaptativo de esta metodología, ASD nos permite tomar
pequeñas "desviaciones" en cada fase en que cada ciclo debe componerse de una mezcla
entre funcionalidades críticas, útiles y opcionales, en donde deben priorizarse las
críticas 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.
5
También se pueden tomar grandes desviaciones las cuales son beneficiosas para
el sistema, ya que se utilizan para la exploración del dominio y la aplicación.
2.2.1. Especular:
Esta fase consiste en realizar una planificación tentativa del proyecto tomando
en cuenta las futuras entregas que se le darán al usuario protipos.
En esta fase se fija un rumbo determinado el cuál será seguido en la parte de desarrollo
y toma mayor énfasis en cada iteración ya que ASD posee la características de usar cada
iteración para APRENDER por lo que en el momento de especular en las futuras
iteraciones esto será de gran importancia ya que trabajaremos en función de esto para
así abordar de una manera mas efectiva y planificada nuestra especulación.
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 especulación, donde se construirá la funcionalidad del proyecto.
Durante cada Iteración el equipo se preocupa de colaborar fuertemente para que de esta
manera se logre liberar la funcionalidad planificada. En esta parte también 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 categoría de metodologías
ágiles.
ASD no propone técnicas ni tareas en la etapa de construcción, lo que hace es
mencionar que todas las prácticas e ideas que se llevan a cabo con el fin de reforzar la
colaboración entre los desarrolladores del proyecto (otro punto que hace referencia al
concepto de metodologías ágiles). La importancia de la colaboración se debe establecer
en la relación entre las personas, las cuales deben estar suficientemente fuertes y claras
para se pueda arreglar cualquier circunstancia compleja que se presente: emergencias*.
6
2.2.3. Aprender:
Esta Fase es la última en cada ciclo y consiste en la revisión de calidad donde se
analizan 4 categorías:
•
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 técnica:
Esto consiste en analizar la calidad del producto revisando el diseño, el código
y las pruebas en función de lograr aprender de los errores y desvíos empleados para
poder resolverlos, y esto implica no poner énfasis en encontrar culpables ya que esto
afectaría las relaciones entre el grupo de trabajo.
Seguido a esto viene la parte práctica de esta etapa en la cual se profundiza
en las exploraciones que se hayan realizado con lo cual podremos modificar ya sea el
diseño del sistema, o los posibles cambios de requerimientos que nos de el cliente.
•
Funcionamiento del equipo de desarrollo y las prácticas que este utiliza:
En esta etapa del aprendizaje se enfatiza la interacción entre las partes, la
dinámica del grupo y las técnicas que se acordaron emplear. Es importante que al final
de cada ciclo de vida (postmortem), se realicen pequeñas reuniones con el fin de
analizar lo aprendido
Antes de realizar una iteración, 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 función de
lo que inicialmente se había planificado, tanto en la parte técnica como en la humana.
En este momento es en donde se detectaran las posibles diferencias que podrían 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 términos no técnicos, sino que de negocios.
7
3. Tecnología
En todo proyecto, si bien la parte de planificación y especulación es importante,
también tenemos la parte de tecnología que es casi la más importante ya que esta
condicionara procesos del desarrollo del sistema. Será la que se llevará a la práctica en
el momento de presentar el producto final y en donde se trabajará en base a los
requerimientos anteriormente capturados al cliente.
3.1. Tecnología del Software
Para ASD la tecnología más usada y más efectiva a la hora de programar y
realizar el proyecto es la orientada a objetos ya que hoy en día ya no se aplica solamente
a los lenguajes de programación, además se viene aplicando en el análisis y diseño con
mucho éxito. Es que para hacer una buena programación orientada a objetos hay que
desarrollar todo el sistema aplicando esta tecnología, de ahí la importancia del análisis y
el diseño orientado a objetos.
En cuanto a la programación, la orientada a objetos (POO) es una de las formas
más populares de programar y viene teniendo gran acogida en el desarrollo de proyectos
de software desde los últimos años. Esto se debe a sus grandes capacidades y ventajas
frente a las antiguas formas de programar.
8
Luego de esta introducción surge la pregunta: ¿Cuáles son las ventajas de un
lenguaje orientado a objetos?
Las ventajas más importantes son las siguientes:
•
•
•
•
•
•
•
•
Fomenta la reutilización y extensión del código.
Permite crear sistemas más complejos.
Relacionar el sistema al mundo real.
Facilita la creación de programas visuales.
Construcción 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 metodología de desarrollo ASD tomando
en cuenta que el agilizar el desarrollo de software y la construcción de prototipos, por
nombrar algunas características, es propio de las metodologías ágiles.
Dentro de la tecnología 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 programación que se
usará para dar solución a los requerimientos del cliente.
3.1.2. Lenguaje
Hay una buena variedad de lenguajes de programación orientados a objetos que
se adaptan perfectamente a las metodologías ágiles .Por nombrar las mas usadas y
conocidas tenemos C++ que es una adaptación de C pero con conceptos de POO,
también 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.
9
4. Técnicas y herramientas
Esta metodología no propone técnicas ni tareas al momento de llevar la
construcción, simplemente ocuparemos las prácticas que sirvan para reforzar el
desarrollo del sistema., siguiendo de esta forma la línea de las metodologías ágiles
respecto a la orientación 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 críticos del desarrollo.
En la fase de la especulación, se recomienda utilizar un Component Breakdown
Structure (CBS) en el cual mediante una grilla u hoja de cálculo se pueda conocer la
funcionalidad que será entregada en cada ciclo desarrollado. Otra técnica que se
recomienda son las sesiones JAD para capturar los requerimientos del software y la
realización de prototipos para descifrar ambigüedades que se presenten en el desarrollo.
Algunas de las técnicas de planificación y de control de actividades más
empleadas en las metodologías de desarrollo son la carta Gantt y el diagrama Pert.
Las herramientas para emplear las técnicas mencionadas tienen que ser las que
mejor se adapten o en las que mejor dominio se tenga.
5. Actividades de gestión
Dentro de las actividades de gestión tenemos la definición del equipo de trabajo,
los roles, responsabilidades, la documentación y la comunicación.
5.1. Equipos de trabajo
El grupo se dividirá en equipo de trabajo, los cuales tendrán designados roles
específicos llevando así determinadas responsabilidades para lograr una eficiente
creación del sistema. Los equipos de trabajo deben ser pequeños, para facilitar la
comunicación, 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 serán:
•
Clientes: Este rol juega un papel muy importante, ya que este será parte activa
del equipo de trabajo, aportando
y funcionalidades al sistema. Además es
esencial para el éxito del mismo, ya que un software que no tiene aceptación
dentro de la organización jamás llegara a ser construido a tiempo, forma y con
consentimiento de los usuarios.
•
Líder del proyecto: Tiene a cargo la planificación del proyecto a lo largo de
todo el ciclo de vida, asigna recursos y delega responsabilidades en los mismos;
fomenta la unión del grupo haciendo actividades destinadas a eliminar roces
dentro de este, además monitorea el progreso del proyecto y establece estrategias
para mitigar los riesgos que puedan presentarse dentro del desarrollo. El líder del
10
proyecto representa la cara visible del equipo de desarrollo, vendría siendo como
un nexo entre cliente y el equipo desarrollo.
•
Programador: Tiene a cargo la codificación de los componentes a desarrollar
en cada iteración, el posee los materiales y lleva a cabo la implementación de los
requerimientos capturados.
•
Desarrolladores: Tiene a cargo la construcción lógica del software y la
continua refinación de la misma en cada iteración. Estará a cargo de la creación
de la interfaz del software.
•
Tester: Tiene a su cargo la generación de pruebas al sistema a partir de los
requerimientos extraídos y analizados. La importancia radica en la necesidad de
construir un software de calidad que cumpla con los requerimientos del usuario.
5.2. Documentación
Si bien es sabido que las metodologías ágiles no tienen mucha ceremonia en
ASD se entregan dos tipos de documentos: En el primero se incluye una visión del
proyecto, una hoja de datos, un perfil de la misión 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 iniciación del proyecto. En el segundo se entrega una
descripción del sistema, esta se entrega al finalizar el proyecto para analizar el software
conjuntamente con el usuario.
5.3. Relaciones
Esta metodología necesita una constante forma de comunicación entre los
desarrolladores y el cliente. Tanto para facilitar al usuario expresar lo que necesita como
para que los diseñadores 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. También al final de cada ciclo se hace
una reunión 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 podría cambiar el rumbo del proyecto.
11
6. Conclusión
La característica, quizás de mayor importancia de la metodología 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 metodología expone esto claramente en la
siguiente frase:
“En ambientes complejos, el seguir un plan al pie de la letra produce el producto que
pretendíamos, pero no es el producto que necesitamos”
Esta metodología de desarrollo nos permite encarar la construcción del software
en forma ágil utilizando las técnicas y herramientas que nos resulten conveniente en
cada caso.
12
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, Martín. The New Methodology, Abril 2003 [en linea]. Sierra Alejandro
[traducción].
Disponible
en
World
Wide
Web:
<
http://www.programacionextrema.org/articulos/newMethodology.es.html>
[consulta:
Domingo 9 de Septiembre 2007].
-
REYNOSO, Carlos. Métodos 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. Diseño de una Metodología Á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 Penadés, Mª Carmen; Metodologías Á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].
13
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.
Análisis de requisitos. (1) Proceso de estudio de las necesidades del usuario para
conseguir una definición 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 concepción 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,
diseño, implementación, prueba, instalación, verificación, validación, operación 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 jerarquía de modelos de estimación de costes que incluye los submodelos: básico, intermedio y detallado.
Codificación. (1) Proceso de descripción de un programa de ordenador en un lenguaje
de programación. (2) Transformación del diseño lógico y demás especificaciones de
diseño en un lenguaje de programación.
Compatibilidad. (1)Preparación de dos o más componentes o sistemas para llevar a
cabo sus funciones mientras comparten el mismo entorno de hardware o software. (2)
Capacidad de dos o más sistemas o componentes para intercambiar información.
Componente. Es un grupo de funcionalidades a ser desarrolladas durante un ciclo
iterativo.
Descripción del sistema. Documento orientado al cliente que describe las
características 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.
También se denomina: ConOps (Conceptof Operation std. IEEE 1362). Requisitos del
sistema (ISO IEC 12207 1995, 5.1.1.2)
Diseño. (1) Proceso de definición de la arquitectura, componentes, interfaces y otras
características de un sistema o de un componente. (2) El resultado de este proceso.
Diseño de arquitectura. (1) Proceso que define una colección de componentes de
software y hardware junto con sus interfaces, para definir el marco de desarrollo de un
sistema. Ver también: diseño funcional.
(2) El resultado del proceso de (1).
Diseño funcional. (1) Proceso de definición de las relaciones de trabajo entre los
componentes de un sistema. (2) El resultado del proceso (1)
14
Emergencia. Es una propiedad de los sistemas adaptativos complejos que crea alguna
propiedad más grande del todo a partir de la interacción 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 términos no técnicos, sino de negocios.
Mantenimiento. (1)Proceso de modificación de un sistema de software o de un
componente, después 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 ingeniería que desarrolla tareas de mantenimiento (1).
Modelo de ciclo de vida. Representación del ciclo de vida del software.
Obtención. (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) Programación orientada por objetos. Método de
implementación 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 jerarquía a través de relaciones de herencia.
PERT. (Program Evaluation and Review Technique) Método para el control de los
tiempos de ejecución de diversas actividades integrantes de proyectos. Fue desarrollado
en 1957 por la armada de los Estados Unidos.
Actualmente se utilizan sus principios en combinación con los del método CPM en lo
que se conoce como PERT/CPM
Prototipo. Versión preliminar de un sistema que sirve de modelo para fases posteriores.
Rapid Application Development. (RAD) Denominación genérica para técnicas y
herramientas de desarrollo de software que permiten el desarrollo rápido de
aplicaciones.
Requisito. (1) Condición o facultad que necesita un usuario para resolver un problema.
(2) Condición o facultad que debe poseer un sistema o un componente de un sistema
para satisfacer una especificación, estándar, condición 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 documentación y datos asociados, necesarios para el funcionamiento
de un sistema.
Software. Los programas de ordenador, procedimientos, y opcionalmente la
documentación y los datos asociados que forman parte de un sistema.
15
16