UNIVERSIDAD DEL VALLE SEDE TULU

DESARROLLO DE SOFTWARE I
ING. DIANA LORENA VELANDIA VANEGAS
TALLER N 2

MIGUEL NGEL SKAR RODRGUEZ - 201355842

DANNY FERNANDO CRUZ - 201449949

INGENIERIA DE SISTEMAS - 3743

2015
TULU - VALLE

Miguel ngel Askar Rodrguez - 201355842

Danny Fernando Cruz - 201449949

1) Identificar el problema.
El problema de: llevar un registro de las ventas (facturas, cotizaciones y cuentas de cobro) en la
Cerrajera LA 29, as como generar estadsticas a travs de informacin almacenada de los clientes.
Afecta a: Los funcionarios de la Cerrajera LA 29, y a los clientes en general.
En que: Los funcionarios no tienen un anlisis estadstico preciso sobre las ventas realizadas,
tampoco pueden obtener de forma gil informacin de contacto de los clientes y el proceso de
facturacin actual es extenso, lo que implica que los clientes deben esperar alrededor de 15 minutos
por su factura.
Una solucin exitosa es: Crear un sistema que permita:
Almacenar y consultar datos de los clientes.
Almacenar y consultar datos de las facturas.
Generar cotizaciones, facturas y cuentas de cobro usando datos existentes.
Almacenar datos de ventas y generar reportes estadsticos.
2)

ANLISIS DEL CONTEXTO

FUENTES DE REQUISITOS
OBJETOS DEL CONTEXTO
Gerente de la cerrajera
Empleados de la cerrajera
Equipo de desarrollo

Clientes
Productos facturados

3) Recoleccin de informacin.
Identificar la necesidad: Se necesita llevar un registro de las ventas en la Cerrajera LA 29, as
como generar estadsticas a travs de informacin almacenada de los clientes.
Tcnicas e instrumentos de recoleccin: Para identificar los requisitos y las funcionalidades que se
necesitan en el sistema, se recolectar informacin a travs de las siguientes tcnicas:
Entrevista: Se hablar con el cliente (gerente y empleados) para conocer sus necesidades y a
travs de una encuesta, se definirn los detalles que complementarn los requisitos.
Lluvia de ideas: En una reunin entre el equipo de desarrollo y el gerente de la empresa, se
generarn propuestas de cmo abarcar y dar solucin a las necesidades y problemas del cliente.
Todas las ideas que surjan sern tomadas en cuenta para luego juzgar si son vlidas y satisfacen
necesidades reales de la empresa.

Miguel ngel Askar Rodrguez - 201355842

Danny Fernando Cruz - 201449949

Anlisis e informe: Despus de la entrevista y la lluvia de ideas, se lleg a las siguientes conclusiones:
El gerente busca tener acceso a la informacin sobre las ventas de su empresa, esto incluye
anlisis estadstico y datos de los clientes, as como qu objetos han adquirido.
El gerente busca reducir los tiempos requeridos actualmente para generar una nueva factura.
El equipo de trabajo solucionar los problemas de almacenamiento y acceso de informacin a
travs del manejo de bases de datos. Esto permitir siempre tener a la mano la informacin
para hacer anlisis estadsticos, as como tambin obtener informacin de los clientes de forma
eficaz.
4)
N
REQUISITO
1
2
3
4

5
6
7
8
9
10

DESCRIPCIN

TIPO

Ingresar la informacin de un cliente nuevo al sistema

(Nombre, telfono(s), direccin).
Modificar la informacin de un cliente existente (Nombre,
telfono(s), direccin).
Generar un formato base de factura, previamente definido
(sin informacin de cliente y/o detalles de producto).
Crear y almacenar una factura, ya sea en formato PDF o en la
base de datos, usando informacin de un cliente existente y
agregando detalles de producto (cantidad, descripcin y
valor).
Mostrar las facturas generadas en una fecha y/o rango de
fechas.
Mostrar las facturas cuyo monto total se encuentre en un
rango especfico.
Mostrar las facturas de un cliente en particular.
Cambiar el estado de una factura (cotizacin, factura, cuenta
de cobro).
Generar reportes (anlisis estadsticos) con el total de ventas
global en un rango de fechas.
Modificar datos de facturas existentes (fecha, valor e
informacin de productos)

Funcional
Funcional
Funcional
Funcional

Funcional
Funcional
Funcional
Funcional
Funcional
Funcional

5) De acuerdo al problema presentado y sus caractersticas (permite almacenar datos de clientes,

almacenar datos de ventas y generar reportes estadsticos), el sistema de informacin a desarrollar
ser uno de procesamiento transaccional.
6) Ejemplo de Si pero: Al mostrarle al cliente la funcionalidad de generar facturas y guardarlas
en formato PDF, este podra decir Est muy bien y es un excelente formato, pero qu tal si tambin
generamos una en Hoja de clculo por si se necesitan realizar arreglos inmediatos.

Miguel ngel Askar Rodrguez - 201355842

Danny Fernando Cruz - 201449949

Ejemplo de Las ruinas enterradas: El cliente necesita que la aplicacin genere reportes
estadsticos, entonces se empieza con un requisito en el que el software genera una tabla con los
datos de ventas de la empresa. Luego, se descubre que esta necesidad se puede satisfacer tambin
a travs de una grfica estadstica. As se van adicionando requerimientos pues siempre se
encuentra una manera de mejorarlos, es decir que se aprecia este sndrome en toda su expresin.
7)

METODOLOGA

CANTIDAD
DE FASES

VENTAJAS

DESVENTAJAS
Delimita el alcance
del proyecto con el
cliente.
No
funciona
correctamente en
varios equipos.
Pasar de cristal a
otro a mediados
proyecto
no
funciona, ya que
Crystal
no
fue
diseado para ser
ascendente
o
descendente
compatibles.
Un
problema
sencillo lo puede
volver un error
crtico.
Compromiso fuerte.
No todos los tipos de
aplicaciones
son
apropiados
para
DRA.
Para proyectos a
gran
escala
se
necesita un nmero
de equipos para
desarrollar el RAD

Crystal
Methodologies

6 Fases

Apropiada
para
entornos ligeros.
Econmica.
Planificacin ms
entendible para los
clientes.
Permite
realimentacin de
usuarios
fcilmente.
Tamao
de
proyecto.

Desarrollo
rpido
de
aplicaciones
(RAD)

5 Fases

Cascada

5 Fases

Se
comprenden
bien los requisitos
y se limita el
mbito
del
proyecto.
Es fcil dividir al
sistema
en
mdulos.
Se
utiliza
un
enfoque
de
construccin
basado en objetos
reusables.
Es un modelo No conocer si la
sencillo
y solucin es correcta
disciplinado.
hasta estar cerca de
su lanzamiento.

CARACTERSTICAS
DE SISTEMAS
DONDE SE PUEDE
IMPLEMENTAR
Puede
ser
implementado en
cualquier clase de
sistema dada la
flexibilidad
de
esta metodologa
contando
con
variaciones tales
como
Clear,
Yelow,
Orange,
Red.

Se recomienda su
uso en sistemas
de informacin no
muy
complejos
debido
a
su
enfoque de corto
tiempo en el cual
se tienen muy
claros
los
requisitos y se
limita el mbito
del proyecto.
Es adecuada para
sistemas
pequeos debido
a la estructuracin

Miguel ngel Askar Rodrguez - 201355842

Danny Fernando Cruz - 201449949

Est dirigido por los

tipos
de
documentos
y
resultados
que
deben obtenerse al
final de cada etapa.
Este
proceso
conduce a entregar
el
proyecto a
tiempo.
Permite tener bajo
control el proyecto.

DSDM

3 Fases

PSP

---------

La calidad del
producto
es
mejorada a travs
de la participacin
de los usuarios a lo
largo del ciclo de
vida del proyecto y
la
naturaleza
iterativa
del
desarrollo.
DSDM
asegura
desarrollos
rpidos.
Reduce los costos
de proyectos a
travs
de
las
ventajas
mencionadas
anteriormente
Permite
realizar
cambios de forma
fcil.
Permite
la
reutilizacin
de
aplicacin a travs
de los mdulos
existentes.
Te permiten llegar
a acuerdos que t
puedas cumplir.
Mejora
la
productividad de
las personas.
Gua tu trabajo.

Poco tiempo para

corregir fallas
No es frecuente que
el cliente o usuario
final explicite clara y
completamente los
requisitos.
El proceso es lento y
pesado.
El producto final
obtenido puede que
no refleje todos los
requisitos
del
usuario.
Se necesita una alta
participacin de los
usuarios
en
el
desarrollo,
para
evitar
que
los
desarrolladores
asuman
criterios
que no son ciertos.
No
es
una
metodologa
de
desarrollo comn. El
proceso es un tanto
difcil
de
comprender.
Ningn sistema es
realizado
a
la
perfeccin en el
primer intento.

y procesos en
cada una de sus
fases.

Mayor compromiso
y disciplina por parte
del programador.
Debe de llenar toda
la documentacin
requerida
que
incluye sus registros,

Puede
ser
implementada en
cualquier clase de
sistema ya que es
a criterio del
desarrollador y es

Este
tipo
de
metodologa se
puede
implementar en
sistemas grandes
debido
a
su
estructuracin,
flexibilidad
con
posibles cambios,
y manejo de la
informacin
en
todas sus etapas.

Miguel ngel Askar Rodrguez - 201355842

Danny Fernando Cruz - 201449949

TSP

----------

Prototipos

4 Fases

Mejora en los
hbitos
de
programacin.
Se puede lograr
una
deteccin
temprana
de
defectos y riesgos.
Disminucin de los
defectos.
Mejora
en
la
calidad.
Mejoras en costo y
horario.
Mejoras
en
productividad.
Mejoras en calidad.
Manejo adecuado
del desarrollo de
software.

planificacin,
las enfocada a
plantillas
o individuo.
formularios.
Se debe de contar
con
un
buen
conjunto
de
mtricas
y
parmetros
de
calidad.

No modifica el flujo
del ciclo de vida.
Reduce los riesgos
de
construir
productos que no
satisfagan
las
necesidades de los
usuarios.
Reduce costos y
aumenta
la
probabilidad
de
xito.
Este modelo es til
cuando el cliente
conoce
los
objetivos generales
para el software,
pero no identifica
los
requisitos
detallados
de
entrada,
procesamiento y
salida.

El cliente puede
creer que el sistema
ya est listo y pedir
su
entrega
su
entrega rpida.
Crea expectativas
mas all de lo que
realmente
puede
hacer.
Se
dificulta
la
direccin y control
del protocolo de
desarrollo mas que
el contenido clsico.
La presin por
entregar rpido el
producto
compromete
la
calidad
Se
dificulta
mantener
el
entusiasmo
del
cliente despus de
aprobado
el
prototipo
porque
creer
que
se
desperdicia
el

Ingenieros
con
habilidades
especficas (PSP).
Para productos de
software complejos
y demandantes.

un

Puede
ser
implementada en
cualquier clase de
sistema siempre y
cuando el equipo
de trabajo se
encuentre
capacitado en PSP
ya que es un
requisito base.
Este modelo es
til para varios
tipos de sistemas,
yendo desde los
ms
pequeos
hasta los ms
grandes. Debido a
que
permite
adaptar
el
software
a
diferentes
entornos.

Miguel ngel Askar Rodrguez - 201355842

Danny Fernando Cruz - 201449949

tiempo en detalles
insignificantes.
Espiral

4 Fases

Reduce riesgos del

proyecto.
Incorpora objetivos
de calidad
Integra
el
desarrollo con el
mantenimiento.

Genera
mucho
tiempo
en
el
desarrollo
del
sistema.
Modelo costoso.
Requiere
experiencia en la
identificacin
de
riesgos.

Debido
a
la
capacidad
de
regresar
entre
etapas,
este
modelo puede ser
aplicado tanto a
sistemas
pequeos como
grandes.

RUP
(proceso
racional
unificado)

4 Fases

Integra desarrollo
con
mantenimiento.
Est
basado
totalmente
en
mejores prcticas
de la metodologa.
Incorpora
fielmente
el
objetivo de calidad.

Pretende prever y
tener todo el control
de antemano.
Genera
muchos
costos.
No es recomendable
para
proyectos
pequeos.

Esta metodologa
resulta ms eficaz
a la hora de
implementarla
para el desarrollo
de
proyectos
grandes.

Programacin
extrema

4 Fases

Programacin
organizada.
Menor taza de
errores.
Satisfaccin
del
programador.
Solucin de errores
de programas.
Versiones nuevas.
Implementa una
forma de trabajo
donde se adoptan
fcilmente a las
circunstancias.

Es
recomendable
slo en proyectos a
corto plazo.
Altas comisiones en
caso de fallar.
Imposible
prever
todo
antes
de
programar.
En
ocasiones,
demasiado costoso
e innecesario.

Es aplicable a
proyectos
pequeos
y
grandes,
pues
consiste en el uso
dinmico
de
diferentes
metodologas de
desarrollo
de
software.

SCRUM

3 Fases

Flexibilidad en
proceso
y
definiciones de
productos.
Realimentacin
continua con
cliente.
Interaccin
constante.

el Si
no
se
ha
las concretado
una
los fecha de finalizacin
del proyecto, este
puede
seguir
el extendindose.
Si las tareas no se
definen
detalladamente,

Es
una
metodologa que
se puede aplicar
tantos a sistemas
pequeos como a
grandes.

Miguel ngel Askar Rodrguez - 201355842

Danny Fernando Cruz - 201449949

Calidad mejorada.
Cuando
los
proyectos no estn
claramente
definidos, estos se
clarifican.
Interaccin
y
Comunicacin.

estas
pueden
consumir ms de un
sprint.
Los miembros del
equipo
siempre
deben
estar
concentrados y cada
uno es pieza clave en
el desarrollo.
El equipo debe ser
pequeo y tambin
afrontar desarrollos
relativamente
pequeos.
Se requiere bastante
experiencia entre los
miembros
del
equipo.
Los miembros del
equipo deben ser
autnomos para que
las verificaciones no
se vuelvan algo
constante,
pues
estas
pueden
generar estrs.
El equipo debe ser
pequeo y tambin
afrontar desarrollos
relativamente
pequeos.
Se requiere bastante
experiencia entre los
miembros
del
equipo.
Los miembros del
equipo deben ser
autnomos para que
las verificaciones no
se vuelvan algo
constante,
pues
estas
pueden
generar estrs.

Miguel ngel Askar Rodrguez - 201355842

Danny Fernando Cruz - 201449949