T0003629
T0003629
T0003629
1
DEFINICION DE METODOLOGIA DE DESARROLLO DE SOFWARE Y
DOCUMENTACION DE PROCESOS EN IPSOFT S.A
DIRECTORA
MARY ELIZABETH RAMIREZ
INGENIERA DE SISTEMAS
2
Nota de Aceptación:
3
AGRADECIMIENTOS
4
CONTENIDO
Pág.
RESUMEN 10
INTRODUCCION 11
1. METODOLOGÍAS DE SOFTWARE EXISTENTES 13
1.1 PROGRAMACION EXTREMA 14
1.1.1 Definición 14
1.1.2 Características 14
1.1.3 Roles 15
1.1.4 Procesos 15
1.1.5 Practicas 16
1.1.6 Valores 18
1.1.7 Principios 18
1.2 PROCESO UNIFICADO RACIONAL 19
1.2.1 Definición 19
1.2.2 Características 19
1.2.3 Practicas 19
1.2.4 Roles 20
1.2.5 Fases 21
1.2.6 Procesos Generales 24
2. PROCESOS DE SOFTWARE 26
2.1 REQUERIMIENTOS 26
2.1.1 Descripción general del proceso de requerimientos 28
2.1.2 Entradas 29
2.1.3 Salidas 29
2.1.4 Productos Internos 30
2.1.5 Referencia Bibliográficas 31
2.1.6 Roles Involucrados 31
2.1.7 Actividades 31
2.1.8 Verificaciones y/o validaciones 35
2.2 ANÁLISIS Y DISEÑO 38
2.2.1 Descripción general del proceso de análisis y diseño 38
2.2.2 Entradas 38
2.2.3 Salidas 38
2.2.4 Productos Internos 40
2.2.5 Referencia Bibliográficas 40
2.2.6 Roles Involucrados 41
2.2.7 Actividades 42
2.2.8 Verificaciones y/o validaciones 45
5
2.3 CONSTRUCCIÓN 48
2.3.1 Descripción general del proceso de construcción 48
2.3.2 Entradas 49
2.3.3 Salidas 50
2.3.4 Productos Internos 50
2.3.5 Referencia Bibliográficas 50
2.3.6 Roles Involucrados 50
2.3.7 Actividades 51
2.3.8 Verificaciones y/o validaciones 52
2.4 PRUEBAS 54
2.4.1 Descripción general del proceso de análisis y diseño 54
2.4.2 Entradas 54
2.4.3 Salidas 55
2.4.4 Productos Internos 55
2.4.5 Referencia Bibliográficas 55
2.4.6 Roles Involucrados 56
2.4.7 Actividades 57
2.4.8 Verificaciones y/o validaciones 59
3. CONCLUSIONES 61
4. RECOMENDACIONES 63
BIBLIOGRAFIA 64
ANEXOS 65
6
LISTA DE TABLAS
Pag.
7
LISTA DE FIGURAS
Pag.
8
LISTA DE ANEXOS
Pag.
9
RESUMEN
8
INTRODUCCION
Cuando los proyectos que se van a desarrollar son de mayor envergadura, ahí si
toma sentido el basarse en una metodología de desarrollo, y se empieza a buscar
cual sería la más apropiada para el caso. Lo cierto es que muchas veces no se
encuentra la más adecuada y se termina por realizar la que se ajusta a las
necesidades de la empresa.
9
Conforme aumenta la complejidad y el tamaño del proyecto, la coordinación se
dificulta debido al incremento en la comunicación entre los ingenieros de software,
administradores y clientes (Fairley, 1985; Kraut y Streeter, 1995).
10
1. METODOLOGIAS DE SOFTWARE EXISTENTES
11
realmente funciona muy bien si el sistema es pequeño, pero conforme el sistema
crece llega a ser cada vez más difícil agregar nuevos aspectos al mismo.
A principios de la década del ’90, surgió un enfoque que fue bastante
revolucionario para su momento ya que iba en contra de la creencia de que
mediante procesos altamente definidos se iba a lograr obtener software en tiempo,
costo y con la requerida calidad.
1. PROGRAMACIÓN EXTREMA
12
o Publica pronto versiones que implementan parte de los requisitos.
o Es adecuado para proyectos pequeños y medianos.
o También es adecuado para proyectos con alto riesgo.
o Su ciclo de vida es iterativo e incremental.
13
que tienen para él. En este momento ya es posible definir unos hitos y unas fechas
aproximadas para ellos.
14
desarrollo. Una metáfora es una metáfora compartida que describe las funciones
del sistema.
Diseño Simple: Se debe diseñar la solución más simple para que el sistema
funcionar y ser implementada en un momento determinado del proyecto.
Pruebas (Testing): La producción de código esta dirigida por las pruebas unitarias.
Estas son establecidas por el cliente antes de escribirse el código y son
ejecutadas constantemente antes de las modificaciones del sistema.
15
En la Figura 1. Observe que con el enfoque tradicional a medida que el desarrollo
del proyecto avanza los costos van aumentando cada vez más, en comparación
con la XP que su aumento es poco.
Coraje: El sistema código y pruebas comunica claramente todo lo que necesita ser
comunicado en el instante mismo del desarrollo, esto significa que corren todas las
pruebas y que el código fuente revela su intención.
16
1.2 PROCESO UNIFICADO RACIONAL (RUP)
Manejo de requerimientos:
17
Utiliza arquitectura basada en componentes:
o Bloques de construcción:
• Ocultan detalles.
• Permiten la comunicación en el equipo de desarrollo.
• Permiten analizar la consistencia.
• entre las componentes.
• entre diseño e implementación
o RUP indica como controlar, rastrear y monitorear los cambios dentro del
proceso iterativo de desarrollo.
1.2.4 Roles RUP Propone los siguientes roles para abarcar las fases de
desarrollo, los roles son: administrador de base de datos, líder del proyecto,
analistas, diseñador/desarrollador, Tester, administrador de configuración,
ingeniero de desempeño o pruebas.
18
Figura 3. Fases, Procesos e iteraciones del RUP
Fase de Inicio
Se identifican todas las entidades externas con las que se trata (actores) y se
define la interacción a un alto nivel de abstracción:
o Criterios de éxito
o Identificación de riesgos
o Estimación de recursos necesarios
o Plan de las fases incluyendo hitos
19
o Características principales
o Restricciones
o Modelo inicial de casos de uso (10% a 20 % listos).
o Glosario.
Caso de negocio:
o Contexto
o Criterios de éxito
o Pronóstico financiero
o Identificación inicial de riesgos.
o Plan de proyecto.
o Uno o más prototipos.
Fase de elaboración
En cuanto al producto:
20
o Descripción de la arquitectura del Software.
o Un prototipo ejecutable de la arquitectura.
o Lista revisada de riesgos y del caso de negocio.
o Plan de desarrollo para el resto del proyecto.
o Un manual de usuario preliminar.
Fase de construcción
En cuanto al producto:
Fase de transición
21
• Pruebas Beta para validar el producto con las expectativas del
cliente
• Ejecución paralela con sistemas antiguos
• Conversión de datos
• Entrenamiento de usuarios
• Distribuir el producto
Requerimientos
Los desarrolladores y clientes deben acordar qué es lo que el sistema debe hacer
relevar requerimientos, documentar funcionalidad y restricciones, documentar
decisiones, identificar actores, identificar casos de uso (describen la funcionalidad)
y los requerimientos no funcionales se incluyen en una especificación
complementaria.
Análisis y Diseño
Desarrollo
22
Implementación
Prueba
23
2. PROCESOS DE SOFTWARE
2.1 REQUERIMIENTOS
24
Las entrevistas son esenciales porque en ellas se identifica procesos,
requerimientos y casos de uso que son importantes para un proyecto de desarrollo
de software, y además es la técnica de levantamiento de información mas utilizada
y con la que se interactúa con el cliente. Para las entrevistas es encuentros con
cada cliente para identificar los procesos, requerimientos y casos de uso
fundamentales en el desarrollo del proyecto. En el primer encuentro con el cliente
se identificaran los procesos(claves) del proyecto y algunos requerimientos y
casos de uso que afectaran de manera directa o indirecta el desarrollo del
proyecto, en los siguientes dos encuentros con el cliente se enfocara en recolectar
los requerimientos y casos de uso de manera detallada.
Un acta de entrevista es buena idea cuando termina una entrevista, pero es mejor
fusionarla en la guía de entrevista porque será un formato adicional a la entrevista,
dando como solución, agregar 3 campos tales como, resumen, pendientes y
resultados, donde el resumen pondría ser requerimientos, procesos o casos de
uso que se identificaron en la entrevista, pendientes son actividades que se deben
hacer para un mejor entendimiento de los que se va a realizar y resultados son
aspectos que se obtienen durante el desarrollo de la entrevista.
25
A continuación se presentara la documentación del proceso de requerimientos
realizado en IPSOFT - S.A:
26
O6 Detallar los casos de uso centrales.
O7 Validar el detalle de casos de uso centrales y los
requerimientos que no tienen asociado detalle de
caso de uso.
Responsabilidad Responsable:
y Autoridad • Analista(s).
Autoridad:
• Director de Desarrollo.
Procesos Solicitudes de Desarrollo
Relacionados Análisis y Diseño
2.1.2 Entradas
2.1.3 Salidas
27
identificador del proceso al cual pertenece,
número del caso de uso que lo cubre, fuente
(Numero del documento de levantamiento de
información que se utilizo para obtener el
requerimiento) y una descripción del
requerimiento.
28
Observación de Observar el(los) proceso(s) central(es) para tener
Procesos un mayor entendimiento del proceso.
2.1.7 Actividades
29
A2. Realizar Entrevista(O1)
Analista A.2.1 Definir la guía de entrevista y/o escoger una
guía estándar.(Ver Anexo G)
A.2.2 Realizar la ejecución de la entrevista.
Nota: La grabación de la entrevista es opcional, si
hay grabación el casette deberá ser marcado con
el número respectivo de la entrevista.
A.2.3 Realizar el formato diligenciado de la
entrevista.
A3. Realizar Revisión de documentos(O1)
Analista A.3.1 Leer los documentos que ayuden al
entendimiento del proyecto.
A.3.2 Realizar el documento de revisión de
documentos para el entendimiento del proyecto.
A4. Realizar observaciones de los procesos(O1)
Analista A.4.1 Identificar los procesos que se requieren
observar.
A.4.2 Realizar el documento de observación de los
procesos que sean relevantes para el desarrollo
del proyecto.
A5. Realizar la Especificación de Procesos(O2)
Analista A.5.1 Identificar los procesos que componen el
proyecto e identificar los procesos claves.
Nota: Para identificar los procesos claves se
escribirán en negrilla.
A6. Realizar Detalle de Procesos(O3)
Analista A.6.2 Elaborar el detalle de los procesos claves del
proyecto.(Ver Anexo B, Anexo E)
Nota: El detalle de proceso debe ser de lo que se
quiere conseguir.
A7. Validación de Procesos
Usuario Lider A.7.1 Se validan los detalles de proceso.
A.7.2. Se revisa cada detalle de proceso.
Analista A.7.3 Si la validación de los procesos es
satisfactoria continúa con la actividad A8.
Director de Desarrollo A.7.4 De lo contrario, volver a la actividad A5 y
revisar y/o modificar los procesos.
A8. Realizar la Especificación de Requerimientos(O4)
Analista A.8.1 Definir la lista de requerimientos e identificar
los requerimientos de cada proceso.
A.8.2 De los procesos claves identificar los
requerimientos centrales. (Ver Anexo C, Anexo F)
30
prioridad se escribirán en negrilla.
31
modelos de redacción tampoco son una camisa de
fuerza, pero son una guía que nos puede ser muy
útil.
32
aceptable, robusto.
o Para reducir malas interpretaciones omita
palabras como: Máximo, mínimo, optimizable.
33
Software(SRS)
Analista A.12.1 Determinar si el SRS se va a diligenciar o
modificar.
A.12.2 Diligenciar el documento de Especificación
de Requerimientos del Software (SRS).
34
Figura 4. Diagrama de actividades del proceso de requerimientos
35
2.2 ANÁLISIS Y DISEÑO
36
el modelo de negocio.
37
Relacionados Construcción y Mantenimiento
Pruebas
2.2.2 Entradas
2.2.3 Salidas
38
software, al conjunto de requerimientos y
casos de uso definidos y los diagramas de
secuencia por cada caso de uso.
Modelo de El Modelo de Datos contiene:
Datos
• Modelo Entidad Relación (MER)
(entidades, atributos y relaciones).
39
software, elaboración de diagramas UML y Modelo
Entidad Relación.
Director de Desarrollo Conocimiento general de los proyectos y experiencia
en dirección, planeación y desarrollo de software.
2.2.7 Actividades
Modular
Claro
Simple
Mantenible
Verificable
Portable
Confiable
Exacto
Seguro
Escalable
Utilizable
(Ver Anexo H)
40
y ajústelo al modelo de negocio:
A.2.2.1 Ajuste el diagrama de paquetes.
A.2.2.2 Ajuste el diagrama de despliegue.
A.2.2.3 Ajuste el diagrama de componentes.
A.2.3 De lo contrario, debe realizar el documento de
arquitectura de software:
A.2.2.1 Realizar y/o modificar el diagrama de
paquetes.
A.2.2.2 Realizar y/o modificar el diagrama de
despliegue.
A.2.2.3 Realizar y/o modificar el diagrama de
componentes.
A.2.4 Anexar el nuevo documento de arquitectura
generado al pool de arquitecturas de software y
renombrarlo como un Anexo Técnico del proceso.
A3. Verificar el Diseño de Arquitectura de Software(O8)
Analista A.3.1 Verificar el documento de Arquitectura del
software. (Ver1)
A.3.2 Realizar y/o modificar Documento de
Verificación y Validación de acuerdo al listado de
criterios definidos.
Si la verificación es satisfactoria se realiza A4,
de lo contrario vuelve a A2.
A4. Validar el Diseño de Arquitectura de Software(O8)
Director de Desarrollo A.4.1 Validar el documento de Arquitectura software.
(Val1)
A.4.2 Realizar y/o modificar Documento de
Verificación y Validación de acuerdo al listado de
criterios definidos.
Si la validación es satisfactoria se realiza A5,
de lo contrario vuelve a A2.
A5. Realizar y/o modificar el Diseño Detallado(O5)
Analista A.5.1 Realizar y/o modificar el diagrama de clases
detallado a partir del diagrama de clases del modelo
de negocio y la arquitectura de software definida.
A.5.2 Realizar y/o modificar los diagramas de
secuencia basado en el diagrama de clases detallado
para identificar los objetos que interactúan entre ellos
por cada detalle de caso de uso.
A.5.2.1 Ajustar el diagrama de clases
detallado basado en los diagramas de
secuencia.
A.5.3 Definir si se necesita archivos de configuración
o de interfase.
41
A.5.3.1 Realizar y/o modificar el diseño de los
archivos de configuración o de interfase
definidos.
42
atributos) en el cual se realizara el Triggrer o
Procedimientos Almacenados.
A.8.5.3 Realizar y/o modificar Trigqers
basados en los elementos identificados
anteriormente.
A.8.5.4 Realizar y/o modificar procedimientos
almacenados basados en los elementos
identificados anteriormente.
43
negocio.
A9(Ver2) Documento de Analista Verificar que el documento
Diseño diseño detallado cubre todo el
Detallado conjunto de requerimientos y
casos de uso definidos.
A10(Val2) Documento de Director de Validar que el documento
Diseño Desarrollo diseño detallado cumple con
Detallado todo el conjunto de
requerimientos y casos de uso
definidos.
A3(Ver3) Modelo de Analista Verificar el Modelo de datos
Datos cubre todo el conjunto de
requerimientos y casos de uso
definidos, y el modelo de
negocio.
A4(Val3) Modelo de Director de Validar que el MER cumple con
Datos Desarrollo todo el conjunto de
requerimientos y casos de uso
definidos, y el modelo de
negocio.
44
Figura 5. Diagrama de actividades del proceso de análisis y diseño
45
2.3 CONSTRUCCIÓN
46
desarrollo.
o Pruebas unitarias: realizar y aplicar pruebas
unitarias a los componentes de software
desarrollados y/o modificados.
o Documentación técnica: se realiza la
documentación correspondiente a cada
componente de software.
o Sistema de Control de Versiones (CVS):
Entregar los componentes desarrollados y/o
modificados al CVS.
o Reporte de actividades: Reportar las
actividades realizadas.
Objetivos O1
Revisar el ambiente de trabajo para la aplicación.
O2
Revisar el Plan de Desarrollo para la distribución
del trabajo.
O3 Realizar y/o modificar la base de datos.
O4 Construir y/ o modificar componentes de software.
O5 Realizar y aplicar pruebas unitarias.
O6 Realizar y/o modificar documentación técnica.
O7 Actualizar los componentes de software en el CVS.
O8 Reportar las actividades realizadas.
O9 Actualizar las actividades en el Plan de Desarrollo.
Responsabilidad Responsable:
y Autoridad • Analista Programador.
Autoridad:
• Director de Desarrollo.
Procesos Requerimientos
Relacionados Análisis y Diseño
Pruebas
2.3.2 Entradas
Administración de Recursos
SRS(Casos de Uso y Requerimientos) Proceso de Requerimientos
Arquitectura de Software Proceso de Análisis y Diseño
Diseño Detallado
MRD
47
2.3.3 Salidas
48
Director de Desarrollo Conocimiento general de los proyectos y
experiencia en dirección, planeación y desarrollo de
software.
Tester Conocimiento y experiencia en la elaboración y
ejecución en pruebas de software.
2.3.7 Actividades
49
unitarias.
50
Figura 6. Diagrama de actividades del proceso de construcción
51
2.4 PRUEBAS
52
Relacionados Análisis y Diseño
Construcción
2.4.2 Entradas
2.4.3 Salidas
o El enfoque
o Los recursos
o El esquema de actividades de prueba
53
o Los elementos a probar
o Las características
o Las actividades de prueba
o El personal responsable
o Los riesgos asociados
54
2.4.7 Actividades
55
• Hasta que todas las clases de
equivalencia hayan sido cubiertas por
(incorporadas a) casos de prueba, se
tratará de escribir un caso que cubra
tantas clases válidas no incorporadas
como sea posible.
• Hasta que todas las clases de
equivalencia no válidas hayan sido
cubiertas por casos de prueba, escribir un
caso para una única clase no válida sin
cubrir.
56
procedimiento de prueba.
57
Figura 7. Diagrama de actividades del proceso de Pruebas
58
3. CONCLUSIONES
59
de la pruebas para el software. Se probó el proceso de requerimientos dando
como resultado un proceso exitoso.
60
4. RECOMENDACIONES
61
BIBLIOGRAFIA
Modelo de Procesos para la industria del Software [en línea]. México: Moprosoft,
2003. [consultado 15 julio, 2005]. Disponible en internet:
http://www.lania.mx/biblioteca/manuales/moprosoft/V%201.1%20DocumentoBase.pdf
La Nueva Metodología [en línea]. New York: Martín Fowler, 1999. [consultado 3
Mayo, 2005]. Disponible en Internet: http://www.martinfowler.com
62
ANEXO A. Formato guía de entrevista
G
GUUÍÍA
AEEN
NTTR
REEV
VIIS
STTA
A
DD MM AAAA
No FECHA
CLIENTE
PROYECTO
ENTREVISTADO(S)
PERFIL
ENTREVISTADOR(ES)
OBJETIVOS GENERALES
OBJETIVOS ESPECIFICOS
GUIA ENTREVISTA
RESUMEN
PENDIENTES
RESULTADO
63
ANEXO B. Formato guía de entrevista
D
DEETTA
ALLLLE
EDDE
EPPR
ROOC
CEES
SOOS
S
Descripción General del Proceso
DD MM AAAA
No FECHA
Cliente
Proyecto
Proceso
Objetivo General
Objetivos
Específicos
Responsabilidad
y Autoridad
Procesos
Relacionados
Entradas
Nombre Fuente
Salidas
Nombre Descripción Destino
Roles Involucrados
Rol Cargo y/o Profesión
Actividades
Rol Descripción
64
ANEXO C. Formato de especificación de requerimientos
ESPECIFICACIÓN DE REQUERIMIENTOS
DD MM AAAA
No FECHA
CLIENTE
PROYECTO
65
ANEXO D. Instructivo de Guía de Entrevista
G
GUUÍÍA
AEEN
NTTR
REEV
VIIS
STTA
A
Para realizar el documento de entrevista se plantea la siguiente información:
CAMPO DESCRIPCIÓN
No. Identificador de la guía de entrevista.
FECHA Fecha de diligenciamiento del documento en formato
(dd/mm/aaaa)
CLIENTE Nombre del cliente.
PROYECTO Nombre del proyecto.
OBJETIVO GENERAL Define el propósito para la cual se va a realizar la
entrevista.
OBJETIVOS Definen los ítems para cumplir con el objetivo general.
ESPECÍFICOS
GUÍA DE ENTREVISTA • Si se va a realizar la primera entrevista, se debe
elegir la guía de entrevista estándar.
• Para realizar una guía de entrevista, se debe
realizar de la siguiente manera:
o Plantear el objetivo general.
o Plantear los objetivos específicos de
acuerdo al objetivo general.
o Formular las preguntas para lograr los
objetivos específicos.
A partir de los objetivos específicos se realiza
la preguntas necesarias para abarcar el
objetivo general de la entrevista, por lo general
se debe realizar al menos una pregunta por
cada objetivo especifico.
ENTREVISTADO(S) Nombre(s) de la persona(s) entrevistada(s).
PERFIL Perfil de la persona entrevistada.
ENTREVISTADOR(ES) Nombre(s) de la persona(s) que realiza(n) la
entrevista.
FECHA Fecha en que se realiza la entrevista.
RESUMEN Descripción de Procesos, requerimientos o casos de
uso que se detectaron en la información recolectada
de la entrevista.
PENDIENTES Descripción de actividades que quedaron pendientes
por realizar.
RESULTADO Observaciones acerca de la información recolectada
de la entrevista.
66
ANEXO E. Instructivo del detalle de procesos
D
DEETTA
ALLLLE
EDDE
EPPR
ROOC
CEES
SOOS
S
Descripción General del Proceso
No Identificador del proceso (el identificador esta definido por
DPROXXX, donde XXX es un número consecutivo, el
identificador debe existir en la Lista de Procesos )
FECHA Fecha de diligenciamiento del documento en formato
(dd/mm/aaaa)
Cliente Nombre del Cliente.
Proyecto Nombre del Proyecto.
Proceso Nombre del Proceso.
Objetivo General Objetivos generales medibles y resultados esperados de la
implantación del proceso
Objetivos Objetivos específicos cuya finalidad es asegurar el
Específicos cumplimiento del propósito. Los objetivos se identifican
como O1,O2, etc.
Responsabilidad Responsabilidad: es el rol principal por la ejecución del
y Autoridad proceso.
Autoridad: es el rol responsable por validar la ejecución del
proceso y el cumplimiento del propósito.
Procesos Nombre de los Procesos Relacionados, entre paréntesis se
Relacionados especifica el identificador del proceso.
Entradas
Nombre Fuente
Nombre del producto o recurso Referencia al origen del producto
o recurso.
Salidas
Nombre Descripción Destino
Nombre del producto o Descripción de las Referencia al
recurso características del producto destinatario del
o recurso. producto o recurso.
Roles Involucrados
Rol Cargo y/o Profesión
Nombre del Rol Cargo y/o profesión del rol que ejecuta el proceso.
67
Actividades
Rol Descripción
A1. Nombre de la actividad(O1,O2, etc)
Nombre del rol A.1.1 Descripción de la tarea1
A.1.2 Descripción de la tarea2
A2. Nombre de la actividad(O1,O2, etc)
Nombre del rol A.2.1 Descripción de la tarea1
A.2.2 Descripción de la tarea2
Descripción
Elemento
Actividad a realizar en un proceso. En
su nombre se agrega la identificación de
la actividad que representa.
68
Flujo de información. Indican a partir de
qué actividad se genera un producto, y
en algunos casos su destino.
Comentarios
69
Inicio del proceso
70
ANEXO F. Instructivo especificación de requerimientos
E
ESSP
PEEC
CIIFFIIC
CAAC
CIIO
ONND
DEER
REEQ
QUUE
ERRIIM
MIIE
ENNTTO
OSS
CAMPO DESCRIPCION
No Identificación de la especificación de requerimientos.
FECHA Fecha de diligenciamiento del documento en formato
(dd/mm/aaaa)
CLIENTE Nombre del Cliente.
PROYECTO Nombre del Proyecto.
RQ Identificador del requerimiento (el identificador esta definido
por RQXXX, donde XXX es un número consecutivo).
PR Identificador del proceso.
DESCRIPCIÓN Descripción del Requerimiento.
REEM POR Identificador del requerimiento por el cual se va reemplazar.
FUENTE Identificador del documento de levantamiento de información
o un producto del proceso, que se utilizo para obtener el
requerimiento.
CU Identificador del caso de uso al que pertenece el
requerimiento.
Tips para elaborar unos buenos requerimientos, estas son reglas sencillas pero
importantes para una correcta especificación de requerimientos.
71
4. Pon atención en las conjunciones "y" "o", al usar estas conjunciones
podríamos estar hablando de mas de un requerimiento.
72
ANEXO G. Template de la guía de entrevista
G
GUUÍÍA
AEEN
NTTR
REEV
VIIS
STTA
A
DD MM AAAA
No FECHA
CLIENTE
PROYECTO
ENTREVISTADO(S)
PERFIL
ENTREVISTADOR(ES)
OBJETIVOS GENERALES
OBJETIVOS ESPECIFICOS
GUIA ENTREVISTA
73
8. ¿Qué información (documentos, formatos, datos, etc.) ingresa a este
proceso?
9. ¿Cuántas personas intervienen en este proceso?
10. ¿Qué información produce este proceso?
11. ¿Cuáles son los problemas que actualmente se presentan?
12. ¿Por qué cree que se le presentan estos problemas?
13. ¿Ha pensado en alguna forma de solucionarlos?
74
ANEXO H. Template de Arquitectura de Software
ARTQUITECTURA DE SOFTWARE
DD MM AAAA
ID ID_POOL FECHA
CLIENTE
PROYECTO
AUTOR
DIAGRAMA DE DESPLIEGUE
ARCHIVO UBICACION
75
DIAGRAMA DE PAQUETES
ARCHIVO UBICACION
76
DIAGRAMA DE COMPONENTES
ARCHIVO UBICACION
77
ANEXO I. PAPER
1. INTRODUCCIÓN
Dentro del ámbito de la ingeniería de software (y la funciones, y por cada función determinar un tiempo
informática en general), se ha observado que para aproximado de desarrollo.
cualquier empresa en el campo de software se requiere
definir, documentar e implantar una metodología de Cuando los proyectos que se van a desarrollar son de
desarrollo de software y los procesos que la componen mayor envergadura, ahí si toma sentido el basarse en
adaptados al contexto de la empresa, para obtener una una metodología de desarrollo robusta, y se empieza a
distribución general en los proyectos de software por buscar cual sería la más apropiada para el caso. Lo
medio de políticas, procedimientos, actividades, etc. cierto es difícil encontrar una metodología que se
Pero esto, no es suficiente para guiar y mantener un ajuste al contexto de la empresa.
producto de software, buscando por medio de la
documentación de los procesos de desarrollo de
El Grupo de Investigación de Ingeniería de Software
software, se utilicen las prácticas que ofrece la
de la Universidad Autónoma de Occidente, ofreció su
ingeniera de software para alcanzar sus objetivos.
apoyo, en la modalidad de pasantía, para elaborar la
propuesta cuyo tema es el desarrollo de la metodología
de software en IPSOFT S.A. La metodología es
Sin embargo, muchas veces no se toma en cuenta el diseñada bajo el contexto propio de trabajo en IPSOFT
utilizar una metodología adecuada, sobre todo cuando S.A.
se trata de proyectos pequeños de dos o tres meses. Lo
que se hace con este tipo de proyectos es separar La metodología de desarrollo de software contempla el
rápidamente el aplicativo en procesos, cada proceso en conjunto de procedimientos, herramientas,
78
documentación y aspectos que ayuden a utilizar las Beck, para llamar la atención. También se debe a la
buenas prácticas para el desarrollo del software, cuyo habilidad de Kent Beck de atraer a las personas a este
objetivo es construir mejores aplicaciones, procesos de acercamiento, y tomar un papel principal en él, sin
desarrollo, donde se identifiquen entradas, salidas(o embargo, la popularidad de XP se ha vuelto un
productos internos) para cada uno, de forma que se problema, pues ha acaparado la atención fuera de las
pueda planificar y controlar el producto. Una buena otras metodologías y sus valiosas ideas. (Fowler,
metodología se compone de actividades, tareas y 2003).
procedimientos, productos, técnicas y herramientas de
software que permite llevar un proceso formal en la La metodología XP tiene como propósito que el cliente
elaboración de un software. sea parte inicial del desarrollo de software redactando
los requerimientos a su manera, estos requerimientos
2. METODOLOGIAS DE DESARROLLO DE en la metodología XP se denominan Historias de
SOFTWARE Usuario.
3.1 Requerimientos
El proceso de pruebas básicamente está compuesto por 3 El tipo de desarrollos en general es creación de
las siguientes fases: software a la medida del cliente, y hay numerosas
opiniones que relatan el éxito de una metodología
1 Técnicas de diseño de casos de prueba: se utilizan en este ámbito. Queda por ver si es posible aplicar
para obtener una confianza aceptable en que se estas ideas también en procesos de desarrollo muy
detectarán los defectos existentes. diferentes, como el software libre.
1.1 Pruebas de Aceptación: Se realiza los
casos de prueba que el cliente requiere en 4 RUP contempla más rigurosidad en cuanto al
el software. desarrollo de software y permite establecer los
1.2 Pruebas Funcionales o de caja negra: Se requerimientos y casos de uso de manera iterativa,
identifican las clases de equivalencia y se aunque algunas personas utilizan el RUP con el
crean los casos de prueba modelo cascada, pero la ahora existe UP ágil,
correspondientes. donde se produce código y se hacen pruebas,
2 Diseño de Pruebas contemplando procesos generales y procesos de
2.1 Plan de Pruebas: Se enfoca en detallar el soporte que otras metodologías agiles no lo
modelo de prueba para los componentes aplican.
de software.
2.2 Especificación de los casos de prueba: 5 Para la empresa adaptarse a los procesos
Define uno de los casos de prueba desarrollados va a llevar tiempo y capacitación
identificado por una especificación del para las personas que conforman el equipo de
diseño de las pruebas. desarrollo, y se necesitara el apoyo de los altos
2.3 Especificación de los procedimientos de directivos para realizarlo.
prueba: Especifica los pasos para la
ejecución de un conjunto de casos de 6 En el proceso de requerimientos este proceso es
prueba o, más generalmente, los pasos fundamental porque aquí se produce la
utilizados para analizar un elemento información necesaria para comenzar el desarrollo
software con el propósito de evaluar un de software, en esta etapa evaluamos de la mejor
conjunto de características del mismo. manera la captura de los requerimientos haciendo
posible la trazabilidad de este proceso, y
3 Ejecución de las pruebas comprobamos que es la etapa fundamental para la
3.1 Histórico de Pruebas: Documenta todos empresa ya que de eso depende que su
los hechos relevantes ocurridos durante la construcción sea lo mejor realizada posible. Los
ejecución de las pruebas. casos de uso forman parten especial porque
3.2 Informe resumen: Resume los resultados determinan el procedimiento que se va a construir,
de las actividades de prueba (las reseñadas y las pruebas para el software.
en el propio informe) y aporta una
evaluación del software, basada en dichos 7 La validación del proceso de requerimientos que
resultados. determinada por validar cada caso de uso y
requerimiento que el cliente solicitó, esta
4. CONCLUSIONES validación se realizará por medio de la firma del
cliente y la fecha.
1 Las metodologías de software son fundamentales
en una empresa de desarrollo de software 8 Evaluando las métricas para el proceso de
permitiendo definir reglas, procedimientos, requerimientos arrojo como resultado un proceso
actividades, tareas, y herramientas de software, adaptable para el contexto de la empresa, aunque
para cada etapa de desarrollo de nuevos proyectos, con pequeñas fallas en los campos de los formatos
y además permite que las personas trabajen mejor e instructivos que no fueron utililes, pero sin
y sea propende de errores. mayor importancia.
2 No es fácil aplicar una nueva metodología en un 9 Análisis y Diseño es uno de los procesos que no
equipo de desarrollo ya que obliga a aprender una se realizaban en la empresa, por este motivo el
equipo de desarrollo le tomara tiempo adaptarse a
los nuevos procedimientos que se deben realizar The Capability Maturity Model Integration, CMMISM
cuando se este desarrollo un nuevo aplicativo. for Systems Engineering and Software Engineering
Para este proceso se involucraron diagramas que (CMMI-SE/SW, V1.1) CMMI, Product Team,
permiten tener una interpretacion grafica de las December 2001.
características del software, posicionando como su
principal fuente el modelo de datos. IEEE STD 830 1998, IEEE Recommended Practice for
Software Requirements Specifications.
8. Construcción es el proceso que se considera más
adaptable a las necesidades actuales, debido a que Modelo de Procesos para la industria del Software,
se centra los componentes de software, la base de Moprosoft v1.1, Mayo 2003.
datos, y a la implantación de herramientas de
software que ayudan a gestionar el proceso. Modelo IDEAL
http://www.sei.org
9. El proceso de pruebas se encuentra es su estado de
mejora y debe realizarse un estudio mas Martin Fowler
exhaustivo de este proceso. http://www.martinfowler.com
Doctor
Jaime Campo Rodríguez
Director Programa de Ingeniería Informática
UAO.
Considerando lo anterior, ratifico que este proyecto ha sido revisado y aprobado por
cumplir con los estándares de un proyecto de opción de grado.
Atentamente,
------------------------------------------
Mary Elizabeth Ramirez
Directora Académica del Proyecto
Teléfono: 3188000 ext. 11359
85
Santiago de Cali, 27 de Enero de 2006
Doctor
Jaime Campo Rodríguez
Director Programa de Ingeniería Informática
UAO.
Cordialmente,
------------------------------------------
Gustavo Adolfo Rojas
Subgerente
Teléfono: 6603000 ext. 132