UNIVERSIDAD DEL VALLE SEDE TULU

DESARROLLO DE SOFTWARE I

ING. DIANA LORENA VELANDIA VANEGAS

TALLER N 3

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) Durante el desarrollo de un software, surgen diferentes inconvenientes como describir los
requerimientos, entender las necesidades del cliente e incluso la estimacin de los tiempos de
trabajo teniendo en cuenta la metodologa de desarrollo a utilizar. Entre las etapas del desarrollo,
existe la de recoleccin de informacin, la cual podemos dividir en las siguientes etapas:

Identificar la necesidad: Se analiza de forma precisa cul es el problema a solucionar.

Uso de tcnicas e instrumentos de recoleccin: Esta etapa es el pilar a la hora de recolectar la

informacin, puesto que se sabrn las necesidades puntuales de los clientes, as como tambin
se conocern las fuentes de requisitos y los objetos del contexto. Para esta fase existen
diferentes tcnicas como: Observacin, entrevista (formal e informal), mtodo Delphi (para
adquirir informacin que pueda establecer situaciones futuras) y sesiones de grupo. Por otro
lado los instrumentos que se utilizan son: Encuestas, talleres, lluvias de ideas como parte de las
sesiones de grupo y simulaciones.

Anlisis e informe: Despus de haber recolectado la informacin; esta, en caso de ser posible,
se debe tabular para poder interpretarla de una mejor manera. Adems, a partir de todo el
proceso de recoleccin de informacin, se deben sacar las conclusiones pertinentes respecto a
lo que necesita el cliente.

Profundizando un poco ms en las tcnicas e instrumentos para la recoleccin de informacin,

tenemos:

Observacin: la observacin es una tcnica adecuada cuando se est iniciando la investigacin de

los requerimientos del cliente. Se basa en apreciar la conducta de las personas, la influencia de los
objetos, sucesos o fenmenos que suceden dentro del ambiente de desarrollo de las actividades del
cliente; todo esto de una forma directa y sin hacer especulaciones. La observacin, dependiendo de
cmo se realice, se puede clasificar en:

Estructurada: Se tiene preparado qu y cmo se va observar, as como tambin se tiene

presente el instrumento que se usar para registrar la informacin.

No estructurada: En este caso, el observador toma nota de todos los aspectos que le parezcan
importantes y de los cules podran surgir requerimientos, no se tiene un criterio de observacin
aparente.

Entrevista: es una tcnica de recoleccin informacin donde charlan al menos dos personas frente
a frente. Permite obtener informacin instantnea, as como conocer la percepcin de los diferentes
individuos involucrados. Las personas durante las entrevistas se sienten ms libres para contestar y
el intercambio de informacin es muy fructuoso, puesto que las dudas que surjan se resolvern
durante la misma entrevista. Por otro lado, la entrevista obtiene datos que no se pueden tabular
fcilmente, as que su anlisis depende de la capacidad del equipo de trabajo para comprender al
cliente, as como de que el entrevistador sea hbil. Los tipos de entrevista son:

Entrevista formal: las preguntas a realizar ya se encuentran definidas y sus respectivas se

recogen en un formato diseado para el encuentro. Por lo general, este tipo de entrevista
requiere una preparacin en cada ocasin que vaya a tener lugar; por esta razn, se puede
volver algo compleja, repetitiva y difcil de analizar.

Miguel ngel Askar Rodrguez - 201355842

Danny Fernando Cruz - 201449949
 Entrevista informal: es ms libre que la entrevista informal puesto que no requiere un diseo
previo. Esto, implica que las preguntas consecutivas pueden no estar relacionadas, conllevando
a una gran variedad de temas abordados pero, as mismo, la dificultad para entenderla es ms
elevada. Esta entrevista puede suceder sin ningn tipo de instrumento y puede ser incluso ms
cmoda para el cliente.

Encuesta: La encuesta es un instrumento de recoleccin de informacin que permite obtener

informacin directa de los actores involucrados en el ambiente de la problemtica a solucionar. Esta
se puede desarrollar personalmente, por telfono o incluso, por correo electrnico. Su diseo es
clave para que la informacin sea verdica y til, de acuerdo a este, se clasifica en:

Estructurada: Consiste en un cuestionarios con varias preguntas, las cuales requieren la

seleccin de una sola respuesta.

Semi-estructurada: Sus preguntas son de seleccin mltiple y tambin de respuesta abierta.

Sesin de grupo: sirve para ahonda de forma grupal en los aspectos y detalles del problema a
solucionar, permite establecer hiptesis para la solucin de problemticas. Se divide en:

Coloquio: reunin simple en la cual un grupo limitado de personas hablan de un tema

determinado.

Lluvia de ideas: Cada miembro del grupo involucrado en la sesin hace saber todas las ideas
que tenga, de esta forma se recolectan varias opiniones sobre cmo solucionar el problema y,
despus de un anlisis, escoger la adecuada.

Simulacin o taller: existe una gran variedad para la aplicacin de simulaciones durante la
sesin de grupo. Por lo general, se expone una situacin o se simulan condiciones bajo las que
el software operara, de esta forma se analiza que debera hacer el mismo. En sntesis, permite
el anlisis de los requerimientos bajo las situaciones en que se presentaran verdaderamente.

2)
Qu es un Requerimiento?
R/. Un requerimiento es una necesidad del cliente la cual ya ha sido documentada, Se entiende
tambin como una funcionalidad o una caracterstica que complementa una funcionalidad
necesaria para el proyecto.

Por qu son importantes los requerimientos?

R/. Ya que estos determinan los alcances del proyecto por ende se ven reflejados en tiempo y
dinero.

Cules son los tipos de requerimientos?

Funcionales: Se entiende como un servicio o funcionalidad que da solucin a un problema o
necesidad especfica del cliente. (El sistema debe determinar el nmero mayor entre una lista
de 10 elementos).
Calidad: Son caractersticas que estn dadas por el rea o entorno en el cual se le dar uso al
software. (Se debe complir con la caracteristicas de calidad determinadas por el acuerdo
ISO****).

Miguel ngel Askar Rodrguez - 201355842

Danny Fernando Cruz - 201449949
 No funcionales: Se entienden como restricciones o caractersticas necesarias sobre las funciones
principales que determinan un buen funcionamiento del software, algunos de ellos son de
calidad. (El sistema debe ser seguro, cada usuario para poder ingresar debe contar con un id de
usuario y una contrasea).
Restricciones: Son requerimientos organizacionales o tecnolgicos que pueden determinar o
restringir la forma en cmo el software ser desarrollado (El proyecto ser entregado en n
etapas, entregando en cada una de ella funcionalidades completas acordadas de la siguiente
forma...).
Tcnicos: Pueden ser limitaciones de tipo, sistema operativo sobre el cual debe funcionar o
debe cumplir con los lineamientos de *** ley.

Qu caractersticas debe cumplir un requerimiento para que est bien especificado?

Necesario: Debe ser una necesidad real del cliente y de esta forma evitar gastos adicionales.
No ambiguo: Las descripciones o alcances del mismo deben ser claros y concisos de forma tal
que cualquier lector puede llegar a una misma conclusin al momento de leerlo.
Correcto: Dicho requerimiento debe cumplir a cabalidad la tarea para la cual fue desarrollado y
se debe verificar con la documentacin de alto nivel que no gnero o una persona encargada
de dicha tarea.
Conciso: Se debe usar un lenguaje comprensible y no en uno tcnico para que sea entendible
por los inversores pero aun as hacer claridad en los aspectos importantes.
Consistente: No se deben presentar conflictos entre los diferentes requerimientos ya sea de
forma parcial o total.
Completo: Se deben dar todos los detalles necesarios del requerimiento y no se debe hacer
referencia a fuentes externas.
Alcanzable/Viable: Deben ser realistas teniendo en cuenta los recursos disponibles del
proyecto, tales como tiempo, dinero, infraestructura, entre otros.
Verificable: Debe ser posible determinar de forma completa si el requerimiento fue satisfecho
o no.

Qu significa que un requerimiento debe ser completo?

R/. Se debe cumplir con todas las caractersticas mencionadas en el punto anterior y para que ello
suceda se debe identificar de forma correcta el contexto del proyecto.

Si no cumpliera esta caracterstica en que afectara mi proceso de desarrollo de un sistema?

R/. Al identificar de forma incorrecta el contexto se pueden generar requisitos incompletos y/o
errneos, y dichos errores son difciles de detectar en etapas tempranas del proceso, vindose esto
reflejado en aumento de costos.

Cmo evitar que un requerimiento sea ambiguo?

R/. Usando un lenguaje lo ms natural posible, haciendo nfasis en los detalles ms importantes.

Qu estrategias podemos implementar?

Hacer que los requerimientos seas verificados por varias personas y comparando que todos
lleguen a una misma conclusin.
Haciendo uso de diferentes herramientas tales como diagramas, casos de uso, prototipos,
borradores de interfaces y revisar en detalle cada uno de ellos.

Miguel ngel Askar Rodrguez - 201355842

Danny Fernando Cruz - 201449949
Qu es la educcin de requisitos?
R/. Es el proceso mediante el cual se identifican las fuentes relevante de requisitos, se obtienen los
mismos y se pueden generar requisitos nuevos o innovadores.

Cules son las actividades de educcin de requisitos?

Identificar las fuentes relevantes de requisitos: En esta etapa se identifican las fuentes
potenciales partiendo de las ya conocidas, se incluye cada nueva fuente en una lista, por cada
nueva fuente se verifica si puede generar a su vez una nueva fuente hasta que dicho proceso no
genere resultados, cada stakeholder toma un nmero de puntos relevantes y cada punto
relevante se asigna a las fuentes potenciales de la lista, la lista se ordena de mayor a menor de
acuerdo a la cantidad de puntos relevantes que obtuvo y por ltimo se divide dicha lista el dos,
relevantes y no relevantes.
Educir requisitos existentes: En esta etapa se toman como fuente los Stakeholders, la
documentacin y si es dado el caso sistemas existentes, y partiendo de estas fuentes se verifica
los requisitos existentes.
Desarrollar requisitos nuevos e innovadores: En esta etapa se usan tcnicas y procesos
creativos tales como lluvias de ideas, pensamiento libre, grupos dinmicos, entre otros para as
generar requerimientos nuevos e innovadores.

3)

Cuando se tienen tres o cuatro clientes distintos, pueden surgir los siguientes problemas:

Pueden estar separados por una gran distancia, lo que puede conllevar a una falta de
comunicacin entre ellos. Todo esto generar que cada uno quiera soluciones diferentes o que
tengan ideas distintas del problema que quieren solucionar.
Debido a la variedad entre los clientes, cuando estos sean de distintos departamentos
(mercadeo, contabilidad, etc.) pensarn en las necesidades de acuerdo a su especialidad. Esto
conlleva al surgimiento de una gran cantidad de requisitos que luego habr que analizar para
determinar cul se acomoda a las caractersticas de otro, para que en la negociacin de
requerimientos, todos los clientes y el equipo queden satisfechos con la propuesta de
desarrollo.

Se dice que el modelo de requerimientos representa una fotografa instantnea del sistema en
el tiempo, debido a que con el progreso del desarrollo, el equipo conoce ms del sistema que
est construyendo y los clientes presentes durante todo este proceso, empiezan a expresar de
manera explcita y concisa lo que quieren en el software.

*Falta formato para el desarrollo de los patrones de anlisis.

Miguel ngel Askar Rodrguez - 201355842

Danny Fernando Cruz - 201449949
 INGENIERA DE El cliente tiene una problemtica,
REQUERIMIENTOS pero no la comunica
completamente

El trabajo con varios clientes en distintas

locaciones puede suponer dificultades de
comunicacin, as como una gran variedad
de puntos de vista respecto a cmo
solucionar cada problema

Los miembros del equipo se encargan de

Los ingenieros deben analizar los
requerimientos para garantizar que el
software creado, ser funcional y
solucionar la problemtica del cliente
ahondar en la situacin a travs de siete
funciones de la ingeniera de
requerimientos: Concepcin, indagacin,
elaboracin, negociacin, especificacin,
validacin y administracin.

Se indaga sobre el origen de la Se solicitan miniespecificaciones que

necesidad as como el ambiente servirn como pistas para saber qu
donde se trabajar con el software detalles quiere el cliente en la solucin

Se traducen las necesidades del Se generan los casos de uso

cliente en requerimientos teniendo en cuenta los actores
normales, esperados y involucrados en el software
emocionantes

Se generan los casos de uso Se negocian los requerimientos para que

teniendo en cuenta los actores estos sean ms realistas, pero a su vez, todos
involucrados en el software los involucrados (equipo de desarrollo y
clientes) queden satisfechos

Se valida que los requerimientos permitan INGENIERA DE

construir el sistema correcto y se logre una REQUERIMIENTOS
solucin para el cliente
(Fin del proceso)

Miguel ngel Askar Rodrguez - 201355842

Danny Fernando Cruz - 201449949
4) El sistema dar manejo a dos tipos de usuario (Cliente y Administrador)

CLIENTE:
1. El cliente puede iniciar sesin en el sistema.
2. El cliente podr realizar un pedido y mostrar la informacin del mismo (Se informar al rea de
inventario).
3. El cliente podr devolver un producto, esta accin generar un cambio en el inventario (Este
cambio ser informado al rea de inventario) al igual que en la contabilidad (Este cambio ser
informado al rea de contabilidad).
4. El cliente puede cancelar pedidos.
5. El cliente puede consultar pedidos.
6. El cliente podr preparar informes de ventas.
7. El cliente podr enviar el catlogo.
8. El cliente podr registrar reclamaciones, las cuales se reportan al encargado de atencin al
cliente.

ADMINISTRATIVO:
1. El administrativo podr enviar el pedido, entonces el sistema realizar la solicitud de forma
directa a la empresa de envios, al igual que actualizar el inventario e informar de este cambio
al rea respectiva, tambin se mostrar la informacin del producto.

5) Establecer los casos de uso para un sistema donde se encuentra una persona con un control
remoto de televisor.

Miguel ngel Askar Rodrguez - 201355842

Danny Fernando Cruz - 201449949
6) Realizar el diagrama de casos de uso para un Sistema de Compras por Internet.

Miguel ngel Askar Rodrguez - 201355842

Danny Fernando Cruz - 201449949
 ANEXO TABLA PLANEACIN DE RECOLECCIN DE INFORMACIN

ACTIVIDAD TCNICA JUSTIFICACIN

Identificar las Entrevista Se necesita tener informacin de cul es el problema al cual
fuentes relevantes el cliente desea dar solucin y de esta forma determinar qu
de requisitos funcionalidad requiere el programa para la cerrajera.
Educir requisitos Entrevista Se hablar con el cliente sobre sus necesidades y a travs de
existentes con encuestauna encuesta se definirn detalles y sus gustos personales
para adecuar detalles relacionados con la apariencia y
posible interfaz de aplicacin.
Desarrollar Lluvia de De acuerdo a los requisitos obtenidos, pueden surgir ideas
requisitos nuevos e ideas para requerimientos o caractersticas adicionales y as
innovadores satisfacer con ms eficacia las necesidades del cliente.

Miguel ngel Askar Rodrguez - 201355842

Danny Fernando Cruz - 201449949