Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
PROYECTOS INFORMTICOS
Gua para el estudiante
CONTENIDO
PRESENTACIN
GUA METODOLGICA
UNIDAD UNO
CICLO DE VIDA DEL SOFTWARE
ETAPAS DEL CICLO DE VIDA DEL SOFTWARE
MODELOS DEL CICLO DE VIDA DEL SOFTWARE
Modelo en cascada
Modelo en Espiral
Modelo Incremental
Modelo Evolutivo
Modelo Concurrente
METODOLOGAS
Metodologa CMMI
Metodologa ISO
Metodologa SCRUM
TCNICAS DE RECOLECCION DE DATOS
Introspeccin
Entrevista Abierta
Cuestionario
Grupos de Discusin
Tormenta de Ideas
Entrevistas
Observacin
FICHA PARA ENTREVISTAS
ESPECIFICACION DE REQUERIMIENTOS
FORMATO IEEE830 REQUERIMIENTOS
UNIDAD DOS
UML
DIAGRAMAS DE CASO DE USO
DIAGRAMAS DE SECUENCIA
HERRAMIENTAS CASE
MODELO ENTIDAD RELACION
CRONOGRAMAS
BIBLIOGRAFIA
5
6
10
11
14
15
16
18
20
21
22
23
25
25
26
27
28
30
30
31
32
33
33
37
47
51
52
55
59
60
61
63
2
Unidad
Uno
Logros de Competencia
Indicador de Logro
Evidencia de
Conocimiento
Conocimiento
Producto
reflejados
los
requerimientos
que
normalmente
se
trata
de
primera;
sern
necesarias
sucesivas
contactos
todo
lo
que
quiere
externos
que
supongan
Anlisis:
Es
elementos
necesario
intervienen
determinar
en
el
qu
sistema
en
el
funcionalidades,
tiempo,
...
que
detalle
van
de
sus
dar
una
Llegado
este
punto
se
con
los
requisitos
expresados
as
como
otras
de
mayor
operaciones
contempladas
para
el
producto).
fases.
de desarrollo de software.
As, los modelos por una parte suministran una gua para los
desarrolladores de software con el fin de ordenar las diversas actividades
tcnicas en el proyecto, por otra parte suministran un marco para la
administracin del desarrollo y el mantenimiento, en el sentido en que
permiten estimar recursos, definir puntos de control intermedios, monitorear
el avance, etc.
10
Es un modelo base para los dems modelos. Fue definido por Royce y se
trata principalmente de que se debe completar un paso correctamente sin
ningn error para pasar al siguiente.
Caractersticas del modelo cascada
Este modelo muestra de una forma bsica el desarrollo de software, y
representa en fases separadas procesos fundamentales.
Dice que se debe probar el software despus de construirlo y antes de
operarlo. Cada fase tiene como salida documentacin.
Fases del Modelo Cascada
Las fases son:
Ingeniera y Anlisis del Sistema: establece requisitos de los
elementos del sistema.
Anlisis de los requisitos del software: identifica las funciones del
software, el rendimiento, sus interfaces y la informacin.
11
presupuesto o
13
VENTAJAS
El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida
del software de computadora.
Como el software evoluciona a medida que progresa el proceso, el
desarrollador y el cliente comprenden y reaccionan mejor ante riesgos
en cada uno de los niveles evolutivos.
El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de
construccin de prototipos en cualquier etapa de evolucin del producto.
El modelo en espiral demanda una consideracin directa de los riesgos
tcnicos
en
todas
adecuadamente
las
debe
etapas
reducir
del
los
proyecto
riesgos
antes
si
de
se
aplica
que
se
conviertan en problemas
DESVENTAJAS
Resulta difcil convencer a grandes clientes de que el enfoque evolutivo
es controlable.
Debido a su elevada complejidad no se aconseja utilizarlo en pequeos
sistemas.
Genera mucho tiempo en el desarrollo de sistemas.
14
15
evolutivo)
construye
una
serie
de
grandes
16
los
desarrolladores.
Basada
en
esta
MODELO CONCURRENTE
2.
Elevar la productividad.
3.
Aumentar la flexibilidad.
4.
5.
6.
Ventajas
Excelente para proyectos en los que se conforman grupos de trabajo
independientes.
Proporciona una imagen exacta del estado actual de un proyecto.
Desventajas
Si
no
se
dan
las
condiciones
sealadas
no
es
aplicable.
2. METODOLOGAS
18
19
Soluciones:
Compromiso asegurado
Automatizar lo ms posible las actividades de control y gestin de los
de
implementacin
Problemtica:
ponerlos en prctica
Requiere un mnimo de cantidad de personal (no menos de 10
personas en la prctica)
Fuerte inversin econmica
METODOLOGIA ISO: Las series de ISO 9000 son un grupo de 5
individuales,
pero
relacionadas,
estndares
internacionales
de
para
la
aplicacin
para
el
desarrollo,
implementacin
mantenimiento de software.
Beneficios de la Norma:
Mejor documentacin de los sistemas
Cambio cultural positivo
Incremento en la eficiencia y productividad
Mayor percepcin de calidad
Se ampla la satisfaccin del cliente
Se reducen las auditoras de calidad de los clientes
Agiliza el tiempo de desarrollo de un sistema.
ISO 12207
Esta norma esta orientada a los procesos de ciclo de vida del software
de la organizacin ISO.
Establece un proceso de ciclo de vida para el software que incluye
procesos y actividades que se aplican desde la definicin de requisitos,
pasando por la adquisicin y configuracin de los servicios del sistema,
hasta la finalizacin de su uso.
METODOLOGIA SCRUM: Esta metodologa se basa en una filosofa del
desarrollo gil de software. Lo interesante es que si un integrante del
equipo se cae se viene abajo todo el equipo as que deben de estar
coordinados para que todos vayan a la misma velocidad.
Esta metodologa est basada entre muchas bajo estas premisas:
21
a)
b)
c)
INTROSPECCIN:
La introspeccin es el medio ms obvio y comnmente usado para
entender los requerimientos de un sistema. Consiste en estudiar el
ambiente del usuario para posteriormente tratar de imaginar qu es lo que
me gustara que hiciera el sistema si yo estuviera a cargo de hacer el
trabajo con su ayuda.
Esta tcnica es til pero hay que considerar que la experiencia de un
analista de sistemas es muy diferente que la experiencia de los usuarios
potenciales del software y por lo tanto es difcil que las conclusiones del
analista reflejen la experiencia de las personas que hacen la tarea da con
da.
23
ENTREVISTA ABIERTA
que
fuentes
son
las
mas
adecuadas
para
24
proporcionrmelos.
conviene.
Una de las principales consideraciones a tomar en cuenta en una
entrevista es lograr que la predisposicin del entrevistador no influya en el
resultado de la narrativa capturada. Como proveedores de soluciones,
estamos acostumbrados a identificar soluciones al mismo tiempo que
escuchamos problemas, cuando hacemos esto, tendemos a influenciar
las respuestas del entrevistado, provocando una mala comprensin del
problema o una reduccin en el grado de libertad de la solucin.
Una entrevista debe considerar preguntas libres de contexto (Gausse and
Weinberg, 1989), es decir, preguntas que no influencien las respuestas de
los entrevistados hacia las respuestas que queremos or. Por ejemplo:
Quines son los usuarios del sistema?
Qu problemas tienen actualmente?
Cules son sus necesidades respecto a la solucin?
Algunos consejos que pueden ayudarnos durante una entrevista:
No hagas preguntas donde se suponga de antemano que la gente puede
describir actividades complejas.
En general la gente puede hacer muchas cosas que no puede describir.
Cuando necesites entender una actividad compleja separa la pregunta en
varias partes o utiliza otra tcnica como la investigacin de campo.
Haz preguntas abiertas que le permitan al usuario extenderse en sus
respuestas y a ti comprender mejor su problemtica.
No hagas preguntas que influencien la respuesta del entrevistado: Usted
necesita una pantalla para realizar esta tarea, verdad?
No hagas preguntas para controlar la conversacin: Podemos regresar a
la pregunta anterior?
No hagas preguntas que se respondan as mismas: 50 elementos en
esta lista son suficientes, verdad?
Evita preguntas que empiecen con Por qu?. Habitualmente estas
preguntas ponen al entrevistado a la defensiva porque aparentan
cuestionar la manera en que hace su trabajo.
25
No
esperes
respuestas
sencillas.
Cuando
las
obtengas
sigue
CUESTIONARIO
Consisten en una serie de preguntas que el entrevistador hace de manera
secuencial o que se entregan al entrevistado para que l mismo conteste.
Los cuestionarios tienen la deficiencia de que no utilizan los elementos de
interaccin de la entrevista, por lo tanto se corre el riesgo de que, dado
que la persona a la que se entrevista tiene diferente historia y por lo tanto
diferentes conocimientos y categoras para clasificar los conceptos,
algunas preguntas se malinterpreten o resulten irrelevantes y fuera de
contexto.
GRUPOS DE DISCUCIN
TORMENTA DE IDEAS
La Tormenta de Ideas consiste en listar todas las ideas sobre un tema que
se le ocurren a un auditorio determinado y posteriormente filtrarlas,
desarrollarlas y priorizarlas.
Una sesin de este tipo comienza con la aclaracin del objetivo. El
objetivo es muy importante porque permite mantener en foco la sesin,
sin embargo no debe de ser limitante para la creatividad de las ideas
expresadas, es ms las ideas ms descabelladas pueden resultar en
soluciones innovadoras. Los participantes deben de aportar ideas sin
interrupcin y tantas como sea posible, para lograr esto, el moderador
debe crear un ambiente en el que la creatividad y la apertura de mente
27
ENTREVISTA:
abiertas.
28
OBSERVACIN
Entrevistado(s):
Fecha de la Entrevista:
Lugar de la Entrevista:
Documentos
Relacionados:
NOMBRE DE LA PERSONA(S)
FECHA
LUGAR
Propuesta del Proyecto > Pblico
objetivo y beneficios
Glosario de trminos
NOTA
1.
Antes de la entrevista
Decida que objetivos desea cumplir
2.
3.
4.
5.
6.
Durante
la entrevista
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
Despus de la entrevista
1.
2.
3.
4.
2.
Cliente o Clientes:
Participantes
Grupos afectados
Acepciones
Riesgos
Glosario
No ambiguo
Glosario si es necesario
PERSONAL
Sin duda el elemento ms valioso en el desarrollo de proyectos
Quines participan en un proyecto de software?
Programadores
Lder de proyecto
Arquitectos de software
Usuarios
Analistas/Diseadores
Clientes
Ingenieros de requerimientos
Ingenieros de proceso
Ingenieros de pruebas
Cules son las caractersticas deseables de un lder de proyecto?
Motivador
Organizado
Innovador
Solucionador de Problemas
Cmo se organiza el equipo de trabajo?
Centralizado Controlado (CC): El jefe del equipo se encarga de la
resolucin de problemas a alto nivel y la coordinacin interna del equipo.
La comunicacin entre el jefe y los miembros del equipo es vertical.
Descentralizado Controlado (DC): Un jefe definido que coordina tareas
especficas y jefes secundarios con responsabilidades sobre subtareas.
La resolucin de problemas es una actividad del grupo, la comunicacin
es horizontal y vertical.
36
RIESGOS
El
riesgo
siempre
implica
dos
caractersticas:
37
no
deseadas
prdidas.
tcnicos
identifican
problemas
potenciales
de
diseo,
Interno
de
X.Y.Z
Formas Anexas:
Documentos
Relacionados:
Propuesta de proyecto
Conjunto de caractersticas
LIGAS A OTROS ESTNDARES
39
RELEVANTES
LIGAS A OTROS DOCUMENTOS
Impacto del proceso: Especificacin de Requerimientos de Software
(SRS) define de forma precisa el producto de software que se va a
construir. Las decisiones hechas escribiendo la SRS estn basados en
informacin de los documentos de la propuesta del proyecto y
requerimientos del usuario. El conjunto de requerimientos de SRS
deben ser satisfechos en el diseo del sistema. La SRS es verificada y
validada por la actividades marcadas en el plan de QA.
Introduccin
TAREAS: Proveer un breve resumen de esta entrega del producto. Puede
copiar el texto de la propuesta del proyecto, pegarla aqu, y resumirlo.
PRRAFO
PRRAFO
Para ms informacin, vea la propuesta del proyecto.
Casos de Uso
RESUMEN DE UN PRRAFO
Detalles:
Los actores son descritos en el documento de requerimientos del
usuario.
El conjunto de casos de uso use case suite enumera los casos de uso
en una forma organizada.
Requerimientos Funcionales
RESUMEN DE UN PRRAFO
Detalles:
El conjunto de caractersticas enumera todas las caractersticas en una
forma organizada.
Requerimientos No-Funcionales
TAREAS: Describa los requerimientos no funcionales para esta entrega.
Abajo se pueden ver algunos ejemplos.
Cules son los requerimientos de usabilidad?
Nuestro principal criterio para hacer el sistema usable es la dificultad de
realizar cada caso de uso de alta frecuencia. La dificultad depende de el
nmero de pasos, el conocimiento que el usuario debe tener en cada
paso, las decisiones que el usuario debe realizar en cada paso, y la
mecnica de cada paso (por ejemplo, escribir el ttulo de un libro de forma
exacta es difcil, hacer click en una lista es fcil).
La interfaz del usuario deber ser tan familiar como sea posible a los
usuarios que han usado otras aplicaciones web y aplicaciones de
escritorio en Windows. Por ejemplo, seguiremos las guas de la UI para
nombrar los menus, botones y las cajas de dilogo siempre que sea
posible.
Cul es la confiabilidad y los requerimientos de ltimo minuto?
PRRAFO
PRRAFO
Detalles:
DETALLE
DETALLE
40
DETALLE
Cules son los requerimientos de precaucin?
PRRAFO
PRRAFO
Detalles:
DETALLE
DETALLE
DETALLE
Cules son los requerimientos de seguridad?
El acceso ser controlado con nombres de usuario y contraseas.
Solo los usuarios con derechos de administrador podrn accesar las
funciones administrativas, los usuarios normales no podrn.
Detalles:
Las contraseas debern tener de 4 a 14 caracteres de longitud
No utilizaremos comunicaciones encriptadas (SSL) para este sitio
DETALLE
Cules son los requerimientos de desempeo y escalabilidad?
PRRAFO
PRRAFO
Detalles:
DETALLE
DETALLE
DETALLE
Cules son los requerimientos de mantenimiento y actualizacin?
La capacidad de mantenimiento es nuestra habilidad para realizar cambios
al producto en el tiempo. Necesitamos una capacidad de mantenimiento
fuerte para retener a nuestros primeros clientes. Resolveremos esto
anticipando varios tipos de cambios y documentando cuidadosamente
nuestro diseo y nuestra implementacin.
La capacidad de actualizacin es nuestra habilidad para entregar nuevas
versiones del producto a bajo costo a los clientes con un mnimo de tiempo
de descarga o disrupcin. Una caracterstica clave para apoyar este
objetivo es la descarga automtica de parches o actualizaciones y
actualizaciones del equipo del usuario final. Tambin debemos utilizar
formatos para archivos de datos que incluyan suficientes meta-datos para
permitirnos trasformar con seguridad la informacin existente del usuario
durante una actualizacin.
Detalles:
DETALLE
DETALLE
DETALLE
Cules son los requerimientos de soportabilidad y operabilidad?
La soportabilidad es nuestra habilidad de proveer soporte tcnico eficiente
y a buen precio. Nuestro objetivo es limitar nuestros costos de soporte a
solo 5% de las tarifas de licenciamiento anual. Las caractersticas de
actualizacin automtica del producto no ayudar a entregar fcilmente
parches a los usuarios finales. La gua del usuario y el sitio web del
producto incluyen una gua de resolucin de problemas y una lista de
informacin que debe tener a la mano antes de contactar a soporte
tcnico.
41
El sistema deber almacenar todos los datos en una base de datos SQL
estndar, donde pueda ser accesado por otros programas.
El sistema podr almacenar todos los datos en un archivo XML, usando
una DTD estndar.
El sistema deber leer y escribir archivos .XYZ vlidos para ser usados
por OTRA APLICACIN
[Mes de ao]
43
Revisin
Autor
Verificado
calidad.
[Fecha]
[Rev]
[Descripcion]
[Firma o sello]
dep.
42
Contenido
FICHA DEL DOCUMENTO
CONTENIDO
1 INTRODUCCIN
1.1
Propsito
1.2
Alcance
1.3
Personal involucrado
1.4
Definiciones, acrnimos y abreviaturas
1.5
Referencias
1.6
Resumen
2 DESCRIPCIN GENERAL
2.1
Perspectiva del producto
2.2
Funcionalidad del producto
2.3
Caractersticas de los usuarios
2.4
Restricciones
2.5
Suposiciones y dependencias
2.6
Evolucin previsible del sistema
3 REQUISITOS ESPECFICOS
3.1
Requisitos comunes de los interfaces
3.1.1 Interfaces de usuario
3.1.2 Interfaces de hardware
3.1.3 Interfaces de software
3.1.4 Interfaces de comunicacin
3.2
Requisitos funcionales
3.2.1 Requisito funcional 1
3.2.2 Requisito funcional 2
3.2.3 Requisito funcional 3
3.2.4 Requisito funcional n
3.3
Requisitos no funcionales
3.3.1 Requisitos de rendimiento
3.3.2 Seguridad
3.3.3 Fiabilidad
3.3.4 Disponibilidad
3.3.5 Mantenibilidad
3.3.6 Portabilidad
3.4
Otros requisitos
4 APNDICES
3
4
6
6
6
6
6
6
6
7
7
7
7
7
7
7
7
8
8
8
8
8
8
9
9
9
9
9
9
9
9
9
10
10
10
10
43
Introduccin
[Inserte aqu el texto]
La introduccin de la Especificacin de requisitos de software (SRS) debe
proporcionar una vista general de la SRS. Debe incluir el objetivo, el alcance,
las definiciones y acrnimos, las referencias, y la vista general del SRS.
Propsito
[Inserte aqu el texto]
Propsito del documento
Audiencia a la que va dirigido
Alcance
[Inserte aqu el texto]
Identificacin del producto(s) a desarrollar mediante un nombre
Consistencia con definiciones similares de documentos de mayor nivel
(ej. Descripcin del sistema) que puedan existir
Personal involucrado
Nombre
[Inserte aqu el texto]
Rol
[Inserte aqu el texto]
Categora
[Inserte aqu el texto]
profesional
Responsabilidades
[Inserte aqu el texto]
Informacin
de [Inserte aqu el texto]
contacto
Aprobacin
[Inserte aqu el texto]
Relacin de personas involucradas en el desarrollo del sistema, con
informacin de contacto.
Esta informacin es til para que el gestor del proyecto pueda localizar a
todos los participantes y recabar la informacin necesaria para la obtencin
de requisitos, validaciones de seguimiento, etc.
Definiciones, acrnimos y abreviaturas
[Inserte aqu el texto]
Definicin de todos los trminos, abreviaturas y acrnimos necesarios para
interpretar apropiadamente este documento. En ella se pueden indicar
referencias a uno o ms apndices, o a otros documentos.
Referencias
Fech
Referencia
Titulo
Ruta
a
Autor
[Ref.]
[Ttulo]
[Ruta]
[Fecha] [Autor]
Relacin completa de todos los documentos relacionados en la
especificacin de requisitos de software, identificando de cada documento
el titulo, referencia (si procede), fecha y organizacin que lo proporciona.
Resumen
[Inserte aqu el texto]
44
45
Debe contener una lista detallada y completa de los requisitos que debe
cumplir el sistema a desarrollar. El nivel de detalle de los requisitos debe ser el
suficiente para que el equipo de desarrollo pueda disear un sistema que
satisfaga los requisitos y los encargados de las pruebas puedan determinar si
stos se satisfacen.
Los requisitos se dispondrn en forma de listas numeradas para su
identificacin, seguimiento, trazabilidad y validacin (ej. RF 10, RF 10.1, RF
10.2,...).
Para cada requisito debe completarse la siguiente tabla:
Nmero de requisito
[Inserte aqu el texto]
Nombre de requisito
[Inserte aqu el texto]
Tipo
Requisito
Restriccin
Fuente del requisito
[Inserte aqu el texto]
Prioridad del requisito
Alta/Esencial
Media/Deseado
Baja/
Opcional
Interfaces de comunicacin
[Inserte aqu el texto]
Describir los requisitos del interfaces de comunicacin si hay
comunicaciones con otros sistemas y cuales son las protocolos de
comunicacin.
Requisitos funcionales
[Inserte aqu el texto]
Definicin de acciones fundamentales que debe realizar el software al recibir
informacin, procesarla y producir resultados.
En ellas se incluye:
Comprobacin de validez de las entradas
Secuencia exacta de operaciones
Respuesta a situaciones anormales (desbordamientos, comunicaciones,
recuperacin de errores)
Parmetros
Generacin de salidas
Relaciones entre entradas y salidas (secuencias de entradas y salidas,
formulas para la conversin de informacin)
Especificacin de los requisitos lgicos para la informacin que ser
almacenada en base de datos (tipo de informacin, requerido)
Las requisitos funcionales pueden ser divididos en sub-secciones.
Requisito funcional 1
Requisito funcional 2
Requisito funcional 3
Requisito funcional n
Requisitos no funcionales
Requisitos de rendimiento
[Inserte aqu el texto]
Especificacin de los requisitos relacionados con la carga que se espera
tenga que soportar el sistema. Por ejemplo, el nmero de terminales, el
nmero esperado de usuarios simultneamente conectados, nmero de
transacciones por segundo que deber soportar el sistema, etc.
Todos estos requisitos deben ser mesurables. Por ejemplo, indicando el
95% de las transacciones deben realizarse en menos de 1 segundo, en
lugar de los operadores no deben esperar a que se complete la
transaccin.
Seguridad
[Inserte aqu el texto]
Especificacin de elementos que protegern al software de accesos, usos y
sabotajes maliciosos, as como de modificaciones o destrucciones maliciosas
o accidentales. Los requisitos pueden especificar:
48
49