SEP

DGEST

INSTITUTO TECNOLGICO DE PINOTEPA

Nombre del Proyecto

LECTOR DE HUELLA DIGITAL

Nombre de la Carrera
ING. SISTEMAS COMPUTACIONALES

Nombre del Alumno

Mara Elizabeth Snchez Hernndez
Irma Elena merino Ruiz
Nmero de control
14730197
14730149

Lugar y Fecha
Pinotepa Nal. Oax. a 09 de Diciembre de 2016.

ESTRUCTURA DEL CONTENIDO DEL PROYECTO

1. NOMBRE DEL PROYECTO

Lector de huella digital.

2. OBJETIVO DEL PROYECTO (General y Especficos)

Objetivo general:
Disear y desarrollar de una base de datos con informacin sobre los usuarios e imgenes
de sus huellas dactilares.
Objetivos especficos:
-

Diseo de algoritmos de proceso para mejorar la calidad de imagen y la extraccin

de las huellas dactilares.
Dar servicio para el funcionamiento del lector de huella tctil.

3. JUSTIFICACIN
Al analizar la huella dactilar como mtodo de identificacin se puede establecer la
importancia que se ha dado dentro del sector de la seguridad, empresarial y en la correcta
administracin de justicia, evitando suplantaciones e infiltraciones que traen como
consecuencia fuga de informacin y perdida recursos tangibles e intangibles.
Los requerimientos primordiales de los sistemas informticos que desempean tareas
importantes son los mecanismos de seguridad adecuados a las dependencias que se intenta
proteger; el conjunto de tales mecanismos ha de incluir al menos un sistema que permita
identificar a las entidades (elementos activos del sistema, generalmente usuarios) que
intentan acceder a los objetos (la empresa en s), mediante un proceso de identificacin
dactilar.
Los sistemas que habitualmente utilizan los humanos para identificar a una persona,
como el aspecto fsico o la forma de hablar, son demasiado complejos para una
computadora; el objetivo de los sistemas de identificacin de usuarios no suele ser
identificar a una persona, sino autenticar que esa persona es quien dice ser realmente.

4. FUNDAMENTO TEORICO
UNIDAD 1: FUNDAMENTOS DE INGENIERA DE SOFTWARE.
1.1 Conceptos Bsicos
La ingeniera de software es una disciplina formada por un conjunto de mtodos,
herramientas y tcnicas que se utilizan en el desarrollo de los programas informticos
(software).
Esta disciplina trasciende la actividad de programacin, que es la actividad principal a la
hora de crear un software. El ingeniero de software se encarga de toda la gestin del
proyecto para que ste se pueda desarrollar en un plazo determinado y con el presupuesto
previsto.
La ingeniera de software, por lo tanto, incluye el anlisis previo de la situacin, el diseo
del proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto
funcionamiento y la implementacin del sistema.
Los Ingenieros de Software deben:

Adoptar un enfoque sistemtico para llevar a cabo su trabajo.

Utilizar las herramientas y tcnicas apropiadas para resolver el problema
planteado, de acuerdo a las restricciones de desarrollo y a los recursos
disponibles.

1.2 Fases De la Ingeniera de Software

Anlisis de requisitos
Extraer los requisitos de un producto de software es la primera etapa para crearlo.
Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se
requiere de habilidad y experiencia en la ingeniera de software para reconocer requisitos
incompletos, ambiguos o contradictorios. El resultado del anlisis de requisitos con el
cliente se plasma en el documento ERS, Especificacin de Requerimientos del Sistema,
cuya estructura puede venir definida por varios estndares, tales como CMM-I. Asimismo,
se define un diagrama de Entidad/Relacin, en el que se plasman las principales entidades
que participarn en el desarrollo del software. La captura, anlisis y especificacin de
requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran
medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de
trabajo para estos fines. Aunque aun no est formalizada, ya se habla de la Ingeniera de
Requisitos.
Diseo y arquitectura
Se refiere a determinar cmo funcionar de forma general sin entrar en detalles. Consiste
en incorporar consideraciones de la implementacin tecnolgica, como el hardware, la
red, etc. Se definen los Casos de Uso para cubrir las funciones que realizar el sistema, y
se transforman las entidades definidas en el anlisis de requisitos en clases de diseo,
obteniendo un modelo cercano a la programacin orientada a objetos.

Programacin
Reducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera de
software, pero no es necesariamente la porcin ms larga. La complejidad y la duracin
de esta etapa est ntimamente ligada al o a los lenguajes de programacin utilizados.
Pruebas
Consiste en comprobar que el software realice correctamente las tareas indicadas en la
especificacin. Una tcnica de prueba es probar por separado cada mdulo del software, y
luego probarlo de forma integral, para as llegar al objetivo. Se considera una buena
prctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la
program, idealmente un rea de pruebas; sin perjuicio de lo anterior el programador debe
hacer sus propias pruebas. En general hay dos grandes formas de organizar un rea de
pruebas, la primera es que est compuesta por personal inexperto y que desconozca el
tema de pruebas, de esta forma se evala que la documentacin entregada sea de calidad,
que los procesos descritos son tan claros que cualquiera puede entenderlos y el software
hace las cosas tal y como estn descritas. El segundo enfoque es tener un rea de pruebas
conformada por programadores con experiencia, personas que saben sin mayores
indicaciones en qu condiciones puede fallar una aplicacin y que pueden poner atencin
en detalles que personal inexperto no considerara.
Documentacin
Todo lo concerniente a la documentacin del propio desarrollo del software y de la
gestin del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de
usuario, manuales tcnicos, etc.; todo con el propsito de eventuales correcciones,
usabilidad, mantenimiento futuro y ampliaciones al sistema.
Mantenimiento
Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos.
Esto puede llevar ms tiempo incluso que el desarrollo inicial del software. Alrededor de
2/3 de toda la ingeniera de software tiene que ver con dar mantenimiento. Una pequea
parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en
extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda
la ingeniera civil, arquitectura y trabajo de construccin es dar mantenimiento.
1.3 Metodologas De Desarrollo De Software (Clsicas, Agiles y Otras Filosofas)
Qu es una Metodologa?
En el desarrollo de software, una metodologa hace cierto nfasis al entorno en el cul se
plantea y estructura el desarrollo de un sistema. Como lo mencion al principio, existen
una gran cantidad de metodologas de la programacin que se han utilizado desde los
tiempos atrs y que con el paso del tiempo han ido evolucionando. Esto se debe
principalmente a que no todos los sistemas de la informacin, son compatibles con todas
las metodologas, pues el ciclo de vida del software puede ser variable. Por esta razn, es
importante que dependiendo del tipo de software que se vaya a desarrollar, se identifique
la metodologa para el diseo de software idnea.
En qu consisten las Metodologas de Desarrollo de Software?
Una Metodologa de desarrollo de software, consiste principalmente en hacer uso de
diversas herramientas, tcnicas, mtodos y modelos para el desarrollo. Regularmente este
tipo de metodologa, tienen la necesidad de venir documentadas, para que los

programadores que estarn dentro de la planeacin del proyecto, comprendan

perfectamente la metodologa y en algunos casos el ciclo de vida del software que se
pretende seguir.
Aunque actualmente existen mucha variedad en metodologas de programacin. La
realidad es que todas estn basadas en ciertos enfoques generalistas que se crearon hace
muchos aos, algunos tipos de metodologas de desarrollo de software que se utilizaron e
inventaron al principio de nuestra era tecnolgica y son las que veremos a continuacin.
Cules son modelos del Ciclo de vida del Software tradicionales?
Como les mencion hace un momento, regularmente, cada metodologa de desarrollo de
software, tiene un enfoque bien marcado, estos enfoques no son para nada nuevos y se
siguen utilizando para la planeacin y desarrollo de software an en nuestros tiempos, as
que vamos a ver cules son cada uno de ellos y aprenderemos cmo funcionan.
Metodologa en cascada
El modelo de desarrollo de Software en cascada, es una metodologa de la
programacin muy antigua. Si bien su creador nunca lo menciona como metodologa en
cascada, el funcionamiento y lineamiento de los procesos de la planeacin, son
exactamente iguales. Bsicamente, el estilo del modelo en cascada, es que no podrs
avanzar a la siguiente fase, si la anterior no se encuentra totalmente terminada, pues no
tiene por qu haber vuelta atrs. Vamos a ver cules son las fases de desarrollo de
software del modelo en cascada, para que te puedas dar una idea.
1. Anlisis de Requisitos. El primer nivel del modelo cascada, es el anlisis de
requisitos. Bsicamente lo que se documenta aqu, son los objetivos de lo que el software
debe hacer al terminar el desarrollo, sin entrar en detalles de la parte interna, los cuales se
vern durante el proceso. Sin embargo es importante sealar que una vez avanzado el paso
de anlisis, no puede haber vuelta atrs, pues la metodologa para el diseo de
software con la cual se trabaja no lo permitir.
2. Diseo del Sistema. Todo lo que conlleva el armado de un diseo para el sistema que
vayas a utilizar, es lo que continua despus del anlisis de requisitos. Aqu se elaborar lo
que es la estructura del sistema y se determinarn las especificaciones para cada una de las
partes del sistema que se planea desarrollar. Siendo del mismo modo, una fase a la cual ya
no se podr volver despus de haber bajado al nivel 3.
3. Diseo del Programa. En este punto, an no ingresamos a lo que es la escritura de
cdigo, sin embargo ya se realizan los algoritmos que se van a utilizar en la programacin.
Si bien recuerdas, un algoritmo no necesariamente es cdigo, simplemente tomas una hoja
de papel y escribes el algoritmo que vas a utilizar. Esto es precisamente lo que se realiza
en el paso nmero 3.
4. Codificacin. Seguramente como programador, esta es la parte que estabas esperando,
pues ahora es momento de empezar a escribir todo el cdigo que ser necesario para el
desarrollo del software. Para este punto, la velocidad y el tiempo que se requiera,
depender mucho del lenguaje de programacin que vayas a utilizar. Pues algunos
lenguajes de programacin permiten utilizar componente, bibliotecas e incluso algunas
funciones para reutilizar cdigo, las cuales podrn acelerar el proceso de codificacin en
gran manera.
5. Ejecucin de Pruebas. La codificacin ha terminado y ahora es momento de verificar
que nuestro sistema es realmente funciona, antes de que el cliente empiece a utilizarlo.

Este es precisamente el objetivo de la fase 5 de pruebas. Aqu es recomendable que

intentes mover lo ms que se pueda tu software, con el objetivo de daarlo
intencionalmente, de este modo, si supera las pruebas de dao realizadas por t, entonces
estar listo para el usuario final.
6. Verificacin. Despus de haber realizado una gran cantidad de pruebas en la Fase 5,
debemos migrar a la verificacin. Esta fase consiste en la ejecucin del Software por parte
del usuario final. Si la fase cinco se realiz correcta y profundamente, el software no
tendr ningn tipo de problema y el usuario final quedar satisfecho con el resultado.
7. Mantenimiento. Seguramente te has dado cuenta, de que las aplicaciones o el software
actual, constantemente se est actualizando. Esto se debe principalmente a que se le da
mantenimiento al software, se solucionan errores, se quitan algunos bugs, se aaden
funcionalidades, todo despus de que el usuario final ya lo ha probado y utilizado en su
fase final. Esta es posiblemente una de las fases ms tediosas del modelo de desarrollo de
software, pues debes estar atento a los comentarios de los usuarios, para ver qu cosas son
las que no funcionan correctamente y a las cuales hay que darles mantenimiento
Cules son los Principios bsicos del modelo de cascada?
Como puedes ver, el proceso de desarrollo de software con el modelo de cascada es
bastante complejo. Sin embargo uno de sus principios es que cada una de las fases
elaboradas, se encuentre documentada perfectamente, de este modo, si el desarrollo queda
suspendido en alguna fase, cualquier usuario que quiera continuar con el proyecto lo
podr hacer leyendo la documentacin.
As tambin, es muy comn encontrar metodologas para el desarrollo de software en
cascada con fechas de objetivos, tiempos o presupuestos para determinadas fases.
Aprovechando el hecho de que una vez que avanzaste de fase, es muy poco recomendable
el volver atrs, aunque regularmente se tiene un cierto nivel de tolerancia, pero lo correcto
en la utilizacin del modelo de cascada, es que no puedas ir atrs a realizar
modificaciones de ningn tipo.
Mtodo de Prototipos
Esta metodologa de la programacin todava sigue siendo la favorita de muchos. Consiste
bsicamente en que en base a los requerimientos y necesidades que tiene el cliente, se
realiza de forma rpida un prototipo, este no vendr completo ni mucho menos terminado,
pero si permitir contar con las bases necesarias para que cualquier programador pueda
seguir trabajando en el hasta llegar al cdigo final.
Por si no lo sabes an, un prototipo es una versin no terminada del producto que se le
entregar al cliente o usuario final. Esto nos genera cierta ventaja en el desarrollo de
productos similares con funciones distintas, por ejemplo. Supongamos que vas a
desarrollar un proyecto para 3 clientes distintos, ambos con una estructura idntica pero
con funcionalidades muy distintas, entonces lo que hacemos es crear un prototipo base y
entorno al mostrarlo a nuestros clientes para que de ah se empiecen a desarrollar las
dems funciones.
Mejor vamos a ver cules son las etapas de desarrollo de software por las cuales tendrs
que pasar, en caso de utilizar la metodologa de prototipos.

1. Planeacin. A diferencia de otras metodologas, la planeacin debe ser muy rpida, en

esta fase no puedes demorarte mucho, pues recuerda que solamente ser un prototipo por
el momento.
2. Modelado. Nuevamente, una fase que deber ser suficientemente rpida como para que
nos quite nada de tiempo. Hacer el modelado ser simple y te sigo recordando que
solamente es un prototipo, al menos por ahora.
3. Elaboracin del Prototipo. Ya que contamos con la planeacin de lo que vamos a
realizar y el modelado rpido, entonces es momento de elaborar el prototipo. Para esta
instancia, ya no te dir que lo debes hacer rpido, puesto que te tomar el tiempo que
tenga sea necesario elaborarlo, recuerda que este ya se muestra al cliente, as que ya es
una fase importante.
4. Desarrollo. Posterior a contar con el prototipo elaborado y mostrado al cliente, es
momento de comenzar el desarrollo. Este te tomar una gran cantidad de tiempo,
dependiendo del tamao del proyecto y el lenguaje de programacin que se vaya a
utilizar.
5. Entrega y Retroalimentacin. Una de las cosas con las que cuenta el modelo de
prototipos, es que una vez entregado el proyecto, debemos darle al cliente cierta
retroalimentacin sobre cmo utilizarlo y ciertamente es una fase que se encuentra dentro
de las etapas de desarrollo de software esta metodologa.
6. Comunicacin con el Cliente. Es importante que una vez entregado el proyecto,
tengamos cierta comunicacin con el cliente, bsicamente para que nos indique si el
proyecto es correcto o si desea agregarle ciertas funciones, nuestra metodologa lo
permite. Si fuera en modo cascada, entonces sera algo realmente imposible de hacer.
7. Entrega del Producto Final. Por ltimo, solamente quedar entregar el sistema
elaborado mediante esta metodologa. Aqu tendrs la ventaja de que el cdigo es
reutilizable, para que as con el prototipo ya puedas simplemente empezar de nuevo y con
una buena base de cdigo que te acelerar el proceso.
Cules son los Principios Bsicos del mtodo de prototipos?
Por supuesto, te habrs dado cuenta de que el modelo de prototipos puede llegar a ser un
poco ms tedioso, aunque todo depender del mbito en que lo utilices. Sin embargo uno
de sus principios bsicos que seguramente habrs notado, es que con el mtodo de
prototipos el proyecto se va dividiendo en partes cada vez ms pequeas, para evitar el
peligro ante los riesgos frente a los que estamos expuestos.
Adems, otros de sus principios bsicos fundamentales, es que con la metodologa de
prototipos, el cliente final se involucra mucho ms en el proyecto que con otras
metodologas, haciendo de esta forma que el producto final llegue rpidamente aunque
con un poco ms de presin en el proceso. La ventaja es que conforme se van haciendo
prototipos pequeos, poco a poco se va llegando al producto final. Incluso en algn
determinado momento podrs llegar a crear un prototipo que con solo ajustar ciertos
detalles, se podra convertir en el producto que el usuario quiere.
Modelo Incremental o Iterativo y Creciente
El modelo Incremental, es una metodologa de la programacin muy utilizada hoy en da,
pues su comodidad de desarrollo permite que te obtenga un producto final mucho ms
completo y exitoso. Se trata especialmente de la combinacin de los modelos lineal e
iterativo o bien, modelo de cascada y prototipos. Bsicamente consiste en completar
varias iteraciones de lo que es el modelo de cascada, pero sin completar ninguna,

haciendo iteraciones lo que se hace es crear una evolucin en el producto, permitiendo

que se agreguen nuevas especificaciones, funcionalidades, opciones, funciones y lo que el
usuario requiera despus de cada iteracin.
En pocas palabras, el Modelo Incremental repite el modelo de cascada una y otra vez,
pero con pequeas modificaciones o actualizaciones que se le puedan ir agregando al
sistema. De este modo el usuario final se ve sumamente sumergido en el desarrollo y
puedes proporcionarle un resultado ptimo.
Fases del Modelo Incremental
El modelo iterativo o incremental, cuenta con algunas fases de desarrollo de software que
realmente no tienen mucha complejidad, vamos a verlas:
1. Inicializacin. Como en todo modelo de desarrollo, debe haber una inicializacin, aqu
se puede hablar de dar una idea, de tener algunos requisitos que se buscan en el proyecto y
ciertas especificaciones que se pueden manejar. No es necesario que se haga una lista total
de requerimientos pues recordemos que el proyecto se basa en iteraciones, as que el
proyecto puede ir evolucionando poco a poco.
2. Periodos de Iteracin. Durante el desarrollo del proyecto, es cuando damos inicio a las
iteraciones. La primera iteracin se realiza con las caractersticas iniciales, bsicamente al
final de la primera iteracin, queda un pequeo prototipo de lo que ser el proyecto, pero
se puede volver a inicializar la iteracin y realizar modificaciones en los procesos, como
el anlisis y las especificaciones o funciones que el usuario final requiere para su sistema.
El nmero de iteraciones que se realicen son ilimitadas y depender tanto del
desarrollador como del usuario final. Si nuestro objetivo es que el cliente o la persona que
necesita el trabajo queden completamente satisfecha, entonces nos veremos en la
necesidad de hacer la cantidad de iteraciones que se requieran al final del da.
3. Lista de Control. Es importante que conforme se vaya realizando cada iteracin, se
vaya llevando un control del mismo en una lista. Como si fuera un programa que recibe
actualizaciones constantemente. Cada una de las actualizaciones o iteraciones deber ser
documentada y de ser posible, guardada en sus respectivas versiones, para que sea
sencillo volver atrs, en caso de que una iteracin no sea exitosa o el usuario ya no la
requiera.
Cules son los principios bsicos del Modelo Incremental?
Es importante definir los siguientes principios fundamentales, pues nos permiten saber
con claridad por donde va la idea de la metodologa.
La idea de un modelo incremental, es utilizar una serie de mini modelos de desarrollo de
software en cascada, segmentando requerimientos y permitiendo que el usuario vaya de la
mano con el proyecto durante la realizacin.
Bsicamente las fases de cada iteracin, son las mismas que se manejan en el modelo de
cascada, aunque tambin se pueden agregar algunas, pero su objetivo es completar cada
fase de la iteracin, para que esta se vaya complementando poco a poco y no se genere un
desarrollo tedioso y cansado que puede alargar la duracin del proyecto en demasa.
Debes saber, que cada iteracin te generar un prototipo cada vez ms evolucionado, estos
debers guardarlos por si en determinado momento deseas volver atrs, pues a diferencia
del modelo de cascada, podemos retroceder cuando se requiera y los prototipos se pueden
volver a utilizar una y otra vez, pues el cdigo fuente es reutilizable.

Modelo en Espiral
El modelo en espiral, fue utilizado y diseado por primera vez por Barry Boehm en 1986.
Se trata nuevamente de una combinacin entre el modelo lineal o de cascada y el modelo
iterativo o basado en prototipos, sin embargo a este sistema lo que debemos aadirle es la
gestin de riesgos, algo que en los modelos anteriores ni siquiera se menciona.
Este modelo, consiste en ciertas fases que se van realizando en modo de espiral, utilizando
procesos de la misma forma en que se utilizan en el modelo de cascada, sin embargo aqu
estos no son obligatorios y no llevan precisamente el orden establecido. Bsicamente se
trata de un modelo evolutivo, que conforme avancen los ciclos, ir incrementando el nivel
de cdigo fuente desarrollada, un incremento en la gestin de riesgos y por supuesto un
incremento en los tiempos de ejecucin y planificacin del sistema, esto es lo que tiene el
modelo en espiral.
Para que tengas una idea ms clara, el modelo en espiral es principalmente utilizado para
el desarrollo de grandes proyectos como la creacin de un sistema operativo. Sin embargo
necesitas de ciertos requisitos, como el hecho de contar con personal completamente
capacitado para las funciones que se requieran. Mejor veamos cuales son las fases o tareas
dentro del modelo de espiral.
1. Determinar Objetivo. Es importante que siempre consideres una planeacin inicial,
esta solo se realizar unas ves. Sin embargo el proceso de determinar objetivos se har
constantemente durante cada iteracin que se vaya realizando con el modelo espiral. Esto
se debe a que poco a poco se ir incrementando ms el tamao del manual de usuario, los
requisitos, las especificaciones e incluso las restricciones. Todo esto entra en lo que es la
tarea de objetivos y con cada vuelta en el espiral entraremos a esta tarea, la cual como
todas las dems, es fundamental.
2. Anlisis de Riesgo. Una etapa donde incluso una lluvia de ideas podra ayudar, el
anlisis de riesgos. Aqu debers tener en cuenta todo aquello que pueda daar a tu
proyecto, ya sea que se trate de ciertas amenazas o de posibles daos que se puedan
ocasionar, teniendo adems un Plan B por as decirlo, para que en caso de que ocurra algo
inesperado, tener a la mano la solucin para continuar con el proyecto. En esta fase del
modelo espiral, podemos agregar lo que son la creacin de prototipos, pues siempre es
bueno tener un respaldo de nuestro cdigo, se esta forma en caso de que algo malo
suceda, volvemos a la versin anterior. As que cada vez que vayamos a ingresar a la fase
de pruebas e implementacin, ser necesario contar con un prototipo que nos respalde.
3. Desarrollar, Validar y Probar. Bsicamente en esta fase, la forma en que se estar
desarrollando el proyecto, depender del anlisis de riesgos, pues siempre se va a ir
desarrollando el proyecto enfocndose en los riesgos que podemos evitar en nuestro
software, es decir, si la situacin de riesgo ms obvia se encuentra en la interfaz del
usuario, entonces hay que trabajar con prototipos para este enfoque, creando evoluciones
proporcionales, para ir evitando ese tipo de riesgos. Esto no significa que ignoremos el
resto del proyecto o del desarrollo, sin embargo el modelo en espiral si acomoda un poco
ms las prioridades al momento, independientemente de todo lo dems. Por lo que
siempre en cada vuelta o iteracin que se le de al modelo de espiral, tu avance siempre
depender del anlisis de riesgo, hasta que este sea mnimo y el desarrollo pueda
continuar de forma normal.
4. Planificacin. Antes de proceder a realizar otra iteracin o vuelta al espiral, debemos
prestar atencin a lo que sucedi en la vuelta anterior. Debemos analizar detalladamente si
los riesgos encontrados ya tuvieron solucin, lo cual debe ser lo ideal, puesto que ahora

habra que analizar ms especificaciones y ms requisitos del sistema para continuar con
el desarrollo. Bsicamente la fase de planificacin, nos servir para determinar el avance
de nuestro proyecto e indicar hacia dnde vamos a dirigirnos en la prxima iteracin.
Cules son los Principios bsicos del modelo en Espiral?
Est claro que el modelo en espiral, es sumamente distinto a los dems. Encontramos por
fuera cuatro fases bien organizadas, las cules siempre deben llevar ese orden que se
estipula desde el principio. Una determinacin de objetivos, un anlisis de riesgos, el
desarrollo y las pruebas, junto con la planificacin, la cual depender de los resultados de
la iteracin para saber cmo se actuar en la siguiente vuelta al espiral.
Bsicamente, en el modelo de espiral, toda la atencin est enfocada hacia el anlisis de
riesgos, pues el objetivo primario ser reducir los riesgos que se vayan generando, de otra
forma el sistema no llegar a ser seguro jams.
Algo muy importante que debes ver en el modelo de espiral, es que los interesados deben
estar involucrados prcticamente en cada vuelta que se d al espiral, para crear lo que son
los requisitos antes de realizar una vuelta ms y al final en la fase de planificacin, se
determinan los logros obtenidos, el avance y lo que se esperar de una siguiente vuelta.
RAD: Desarrollo Rpido de Aplicaciones (Rapid Application Development)
A diferencia de otras metodologas para el desarrollo de software, la metodologa RAD o
desarrollo rpido de aplicaciones, no cuenta con una serie de fases ordenadas por as
decirlo. Aunque si est basada en lo que es el modelo de cascada y la creacin de
prototipos, sin embargo el proceso es muy independiente a contar con ciertas fases
estipuladas como los modelos que hemos visto anteriormente. As que vamos a ver los
principios del modelo RAD.
Cules son los principios bsicos del Modelo RAD?
De los mismos modos que modelos anteriores, el Modelo RAD, est basado en el uso de
las iteraciones y principalmente en el manejo de prototipos. Sin embargo a diferencia del
resto, la metodologa RAD hace uso de las Herramientas CASE, las cuales permitirn
acelerar el proceso considerablemente.
Del mismo modo que el modelo espiral y el de prototipos, RAD se subdivide en pequeas
secciones, las cuales se irn optimizando y de esta forma se ir avanzando mucho ms
rpido que con grandes segmentos que pueden volverse difciles dentro de un proceso
acelerado como lo est este modelo.
Una de las ventajas del RAD, es que el enfoque y las prioridades van hacia la fase de
desarrollo, a diferencia de modelos como el espiral, que se enfoca en que los riesgos al
momento sean mucho menores. Ac con el RAD, se hace lo contrario, si hay riesgos
reducimos los requerimientos para reducir los riesgos, no como en el espiral, que entre
ms riesgos, ms requisitos aportamos para que se incremente. Ac la idea es reducir
tiempos y no riesgos, o si, tal vez tambin, pero la reduccin de riesgos es totalmente
inversa al modelo espiral.
Por supuesto, como en todos los modelos, vas a requerir de ciertos factores
documentados, de preferencia todo lo que se pueda, para que en caso de que alguien ms
venga a continuar con este proyecto, tenga a la mano toda la informacin que necesita y
con unas cuentas lecturas pueda empezar a desarrollar lo que se haba quedado pendiente
en un determinado momento.

Cul es tu metodologa tradicional preferida?

Si bien hemos visto mtodos muy diversos, informacin muy variada y ciclos de
desarrollo de software con distintos enfoques. La realidad es que al final t siempre
decidirs como trabajar y con qu tipo de metodologa te sentiras ms a gusto.
Obviamente depende de muchos factores, principalmente del tamao del proyecto, pues
modelos como el espiral, son especialmente para proyectos grandes y modelos como el
RAD, son enfocados en proyectos pequeos, sin tanto requisito pero manejando siempre
cierto nivel de calidad, el cual siempre debes considerar.
A continuacin, analizaremos lo que son las metodologas giles de desarrollo de software
ms importantes, las cules a diferencia de las metodologas tradicionales, funcionan ms
como una combinacin de estas para lograr un objetivo. Su finalidad siempre ser el crear
software de una forma ms rpida de lo que se vena logrando con las metodologas de
antao. As que vamos a ver un poco de informacin referente a lo que son las
metodologas giles, como funcionan y que se necesita para implementarlas.
Metodologas giles
Con el paso del tiempo, estaba claro que las metodologas tradicionales, simplemente no
se iban a acoplar con las nuevas tecnologas, los nuevos lenguajes y sobretodo los
programadores modernos. Es por eso que desde principios del Siglo, se han desarrollado
lo que son las metodologas giles. Una metodologa gil, consiste principalmente en
trabajar con menos documentacin de la que, como vimos, las metodologas tradicionales
utilizan en todo momento.
Existen una gran cantidad de metodologas giles de desarrollo de software y todas las
vamos a ver a continuacin. Sin embargo antes hay que comprender en que consiste
detenidamente la metodologa gil, para lo cual contamos con el manifiesto gil. Un
documento en el cul se resume la filosofa de este enfoque de desarrollo, as seguramente
despus de leer esos puntos, nos quedar an ms clara la idea de hacia donde se pretende
llegar y principalmente Cmo se pretende llegar a los objetivos.
Manifiesto gil
Al Individuo y las Interaciones del Equipo. Una de las cosas que sabemos muy bien,
es que las personas son quienes consiguen los xitos dentro de un proyecto de software.
Sin embargo tambin est claro que si el equipo de trabajo falla, entonces todo se viene
abajo y el enfoque que habia de xito se convierte en incertidumbre. A diferencia de si el
equipo funciona perfectamente, se tienen ms cerca los objetivos, aun cuando no exista
una lista de procesos establecida como se haca con las metodologas de antao.
Con este primer valor del desarrollo gil, se pretender hacer ver, que en realidad no
importa que el equipo de trabajo no sean las personas ms brillantes del sector. Con que
sean personas que saben hacer bien el trabajo que se les asignar es ms que suficiente.
En este caso, las herramientas aunque son importantes para incrementar el rendimiento,
tambin es cierto que si hay herramientas de ms y que no sirven de nada en un principio,
lo mejor es dejarlas de lado o estas nos quitarn valioso tiempo que no tendremos.
Bsicamente el enfoque, es que no se intente crear un entorno de trabajo desde un
principio, tratando de que los desarrolladores se adapten a ese entorno que nosotros
deseamos, pues este tipo de proyectos suelen tardar mucho tiempo en desarrollarse,
algunos incluso jams terminan y se quedan estancados. El enfoque del desarrollo
gil nos dice, que es mejor formar primero un buen equipo de trabajo y posteriormente

entre ellos vayan creando su propio entorno. Este proceso ayudar mucho ms a la
metodologa gil y por supuesto, la adaptacin ser un proceso fugaz.
Software funcional en lugar de demasiada documentacin. Crear documentacin, es
una de las actividades que con las metodologas tradicionales, absorban una gran
cantidad de tiempo. Si nos acercamos a analizaras las metodologas de antao,
descubriremos que en cada una de ellas, realizar la documentacin era una parte vital. Sin
embargo en las metodologas giles, esto ha cambiado, pues existe una regla que dice de
las siguientes forma: No producir documentacin, al menos que sean sumamente
necesarios al momento para tomar una decisin. Por lo que adems se extienda hacia el
enfoque de que la documentacin debe ser corta y breve, nada sumamente extenso que
requiera de una gran cantidad de tiempo de lectura.
Te preguntars y entonces, cuando un nuevo programador o desarrollador sea colocado en
un puesto dentro del proyecto, como sabr hacia donde ir y el enfoque que se est
llevando a cabo. Para lo cual el manifiesto gil nos dice que, existen dos elementos
fundamentales para que un nuevo miembro del equipo se ponga al da. El primero es el
cdigo fuente, pues suponiendo que es una persona conocedora, sabr hacia dnde va el
curso del proyecto con tan solo leer el cdigo. La segunda es que la interaccin con el
equipo de trabajo, ser el complemento ideal para que se acople al proyecto. De este
modo nos olvidamos de la extensa documentacin para un software que al final del da
debe estar totalmente funcional.
Colaboracin con el Cliente en lugar de hacer Contrato. Una de las cosas
importantes dentro de las metodologas giles. Es que cambia el modo en que se
trabajaba con el cliente anteriormente. Y es que en las metodologas de antao, el trabajo
consista en tener una reunin previa con el cliente para analizar los requerimientos del
sistema, aqu se analizaban las limitaciones del proyecto y se establecan los costos. Lo
que generaba cierta barrera de bloqueo entre las posibilidades de desarrollar algo
funcional para otras cosas o solo para el objetivo establecido en la reunin. Esto al final
poda ser desastroso y dificultar la llegada al xito por parte del proyecto.
Sin embargo, ahora en el manifiesto gil, se propone que exista una interaccin constante
entre el cliente y el equipo de desarrolladores. La idea es que el cliente vaya viendo cmo
va el sistema y analice nuevas funcionalidades o objetivos, ya que estos no tienen por qu
plantearse desde el principio, si el desarrollo nos puede llevar a una infinidad de
posibilidades. De esta forma el cliente al final queda totalmente satisfecho con el producto
final y habremos llegado al xito trabajando todos en equipo de forma simultnea.
Posibilidad de Hacer cambios de planes a medio proyecto. Suena ms o menos a lo
que vimos en el punto anterior, pues bsicamente la idea es evitar lo que es la planeacin
extensa y empezar a crear cdigo que permita expansin. Recordemos que con las
metodologas tradicionales, se acostumbraba a enlistar los requisitos del sistema y el
desarrollo iba enfocado solamente a eso, lo cual ya no permita que a medio desarrollo
hubiera cambios, pues era un cdigo poco moldeable y si se requeran nuevas cosas, en
algunas metodologas lo idea era volver a empezar.
La idea en las metodologas giles, es que durante el desarrollo del software, si el cliente
tiene la idea de incrementar sus objetivos, especificaciones o requerimientos, lo pueda
hacer sin ningn problema. Pues bsicamente el sistema debe ser flexible para todo lo que
pueda surgir en el proceso. De esta forma, no solamente llegaremos al xito, si no que el
cliente quedar totalmente satisfecho con el trabajo desarrollado, pues no tuvo que
conformarse con lo primero que se le vino a la mente, si no que se actualiz con las ideas
que en la marcha fueron surgiendo.

Cules son las Principales Metodologas giles?

Algo que debes saber antes de dar paso a la descripcin de cada una de las metodologas
de la programacin giles, es que aunque entre sus creadores crearon lo que fue el
manifiesto gil, la realidad es que cada una de las metodologas cuenta con su propia
personalidad y caractersticas nicas, que la diferencian de las dems. Por eso a
continuacin, veremos cada una de las metodologas giles ms populares, para que
tengas un conocimiento ms slido de lo que son y hacia dnde van cada una de ellas.
Metodologa Scrum
Para que tengas una idea rpida, para que un proyecto ingrese al marco de lo que es
el modelo Scrum, debe contar con las siguientes caractersticas:
Desarrollo Incremental. Una metodologa gil sin desarrollo incremental, no puede ser
considerada Scrum. Con incremental hago nfasis a olvidarnos de la planeacin y de la
ejecucin de las lneas sin salirnos de lo pre establecido, pues con una metodologa
Scrum, el desarrollo se ir incrementando poco a poco, sin importar el orden en el cual se
lleven a cabo los procesos.
Calidad de las personas. Bsicamente la calidad de un producto, no ser analizada en
base a la calidad de cada uno de los procesos llevados a cabo. Al contrario, la calidad
depender de las personas, la auto organizacin y el conocimiento de los equipos de
trabajo.
Adis al Secuencial y Cascada. Aqu en el modelo Scrum, hay algo a lo que se le
denomina, solapamiento. Esto consiste en que no importa en qu proceso te encuentres, si
un proceso necesita ser trabajado, vuelves a l para realizar lo que tienes que hacer, a
diferencia de las metodologas cascada o secuencial, donde no haba vuelta atrs. Ac
afortunadamente no hay ningn problema con eso y la ventaja es que se ahorran tiempos.
La comunicacin es Fundamental. Una de las cosas que se realizan, son los equipos de
trabajo, sin embargo ac la ventaja que tendrs es que podrs estar en constante
comunicacin con los otros equipos de trabajo, nadie est envuelto en su propia burbuja y
toda la informacin que se maneje o lleve a cabo, ser comunicada sin problema.
Cmo funcionan los Procesos Scrum?
La metodologa Scrum, es bastante amigable y fomenta lo que es el trabajo en equipo en
todo momento, con la finalidad de conseguir los objetivos de una forma rpida.
1.4 Importancia De Las Herramientas Case En La Ingeniera De Software
Ingeniera Informtica Software Asistida es una aplicacin que est dirigida a la mejora de
cualquier equipo de cmputo. El proceso es un paso de calidad dirigidos hacia la
improvisacin de las caractersticas de diseo e instalacin para el desarrollo de software.
Cada vez que un nuevo sistema est instalado, la aplicacin integra una serie de tareas
relacionadas y diferentes. El proceso tiene que ser eficientemente organizado y es por esta
razn que las herramientas CASE se desarrollan. Con la ayuda de CASE, el proceso de
instalacin se pueden automatizar y coordinada dentro del ciclo de vida del sistema
elaborado y aprobado.

Las herramientas CASE son en gran medida la comercializacin y entenderse como:

1. La investigacin, anlisis y diseo, o Front-End CASO
2. Implementacin e instalacin, o de fondo CASO
Herramientas CASE se desarrollan por las razones siguientes:
* Aumento de la velocidad durante el desarrollo del sistema.
* Ms rpido de instalacin.
* Anlisis de Mejora y desarrollo de diseo.
* Reduccin de la codificacin y el tiempo de prueba.
* Transferencia eficiente de informacin entre herramientas.
* El uso ptimo de la informacin disponible.
* Crear y manipular la documentacin.
* Enriquecer las tcnicas grficas y flujo de datos.
El uso de herramientas CASE permite al programador para procesar diagramas e
improvisar proyectos diseos de software de gestin. La aplicacin hace posible el acceso
a los diccionarios de datos y paquetes especializados. Con caractersticas mejoradas, es
posible editar y actualizar mltiples versiones de diseo de agregar calidad a la versin
aprobada. El uso oportuno de las potentes herramientas de desarrollo para completar y
actualizar los documentos del ciclo es de gran ayuda en las comprobaciones de errores y
la generacin de casos de prueba. Herramientas CASE han pasado de las aplicaciones que
el anlisis de la documentacin de ayuda en el equipo para interfaces de usuario
inteligentes que son reutilizables.
La disminucin en el factor de costo relacionado con el hardware dedicado ha sido
compensada con el consiguiente aumento en el costo del software. El software de mano
de obra intensiva necesita ser constantemente desarrollado para su uso ptimo. El ms
mnimo error puede resultar en una consecuencia costosa para la empresa o usuario
particular. Herramientas CASE resolver problemas relacionados con el desarrollo y el
mantenimiento de la aplicacin aprobada. No slo altera el marco de tiempo para cada
fase, sino que tambin ayudar a difundir el factor de costos involucrados. Las
herramientas estn en gran medida con inversin de ingenieros de software especializados
para un mejor anlisis y diseo.
El cdigo se genera automticamente implicados, lo que resulta en la reduccin de tiempo
y dramtica en el costo involucrado en el mantenimiento. El repositorio centralizado est
facultado con todos los detalles de los componentes dentro del sistema. De este modo
adecuado y una vez ms, la generacin oportuna de los diseos y cdigos. Herramientas
CASE garantizar la coherencia y la conformidad con las actualizaciones, mientras que el
desarrollo de estaciones de trabajo interactivas para mejorar un negocio en Internet. Ellos
no slo acelerar el desarrollo, sino tambin generar el espacio y las posibilidades de
replicacin de precisin del proceso. Con el costo reducido, mantenimiento y la
productividad ms rentable y prctico.
Es muy importante cuando se selecciona una herramienta CASE para buscar las siguientes
caractersticas cualitativas:
* Fcil de entender las especificaciones de casos de la herramienta.
* La asignacin correcta de tiempo y recursos posibles en el entorno de desarrollo
garantizado.

* La coordinacin entre los detalles de la herramienta y los requisitos de la infraestructura

de la organizacin.
* Nivel garantizado de upgradation de la tecnologa de la informacin dentro de los
departamentos.
* Compatibilidad entre personalidades de aplicacin de las herramientas y la experiencia
relativa.
Las herramientas CASE estn diseados para mejorar y actualizar el equipo informtico
aprobado y aplicado. Esto es muy importante en lo que respecta a la dependencia de un
entorno informtico para empresas y / o actividades personales. Es una parte importante
de las diversas estrategias de crecimiento empresarial.
UNIDAD 2: EL MODELO DEL NEGOCIO.
2.1 Definicin
El modelo de negocio es una representacin simplificada de la lgica del negocio, es
decir, es la descripcin de la forma como cada negocio ofrece sus productos o servicios a
los clientes, como llega a estos, su relacin con ellos y cmo la empresa gana dinero.
Son tambin llamados diseos de negocios o diseos empresariales y es el mecanismo por
el cual una empresa describe cmo busca generar ingresos y beneficios, por lo que se
debe tener en cuenta: cmo selecciona los clientes; cmo define y diferencia sus ofertas
del producto; cmo crea utilidad para sus clientes; cmo consigue y mantiene sus clientes;
cmo sale al mercado con publicidad y distribucin; definicin de las principales tareas;
configuracin de los recursos y por ultimo cmo conseguir el beneficio.
2.2. Componentes
Fabricante
Cada modelo incluye la entidad que ofrece un producto o servicio. En la mayora de los
modelos, la propia empresa llena esta posicin y es el productor del producto. A veces,
por ejemplo, la empresa entrega el producto en lugar de fabricarlo. Esa empresa, entonces,
es la productora del sistema.
Proposicin de oferta o de valor
La propuesta de valor es el valor percibido que tus productos proporcionan como la
solucin al problema o necesidad del consumidor. Por lo general se trata de un producto
fsico, pero los servicios, productos digitales, ideas y propiedad intelectual son todas
propuestas de valor. A menudo, las empresas ofrecern un producto y un servicio
relacionado juntos, como un automvil y su mantenimiento.
Segmento del mercado objetivo
El mercado objetivo es el grupo de consumidores de tu plan para ofrecer el valor de tu
producto. Ya que los diferentes mercados utilizan los productos iguales o similares,
agregar varios segmentos puede aumentar la ganancia potencial para tu empresa.
Canal de distribucin o de movimiento
Hacer llegar tu producto a su mercado objetivo, desde la publicidad hasta la venta, es el
canal de distribucin o movimiento. Esto establece los medios por los que tu negocio se
relaciona con tus clientes.
Relacin del consumidor
La forma en que estableces las relaciones con tus diferentes segmentos de clientes es tu
relacin de consumo. Define cmo ganas su confianza y ofreces tu producto. El
reconocimiento de la marca se inscribe en esta rea, como servicio al cliente.

Configuracin de valor o de recursos

La manera de utilizar las actividades, el personal y los recursos necesarios para producir
el producto son tu valor y la configuracin de recursos o la cadena de valor. Esta
configuracin es la base de tus estructuras de costos e ingresos.
Competencia subyacente
Los conocimientos bsicos, habilidades, capacidades y conocimientos necesarios para
producir tu producto son de tu competencia. Inicialmente, descansa en el propietarioinnovador y en el equipo que lo rodea para llevar el producto al mercado.
Compaeros de la red o de afiliacin
La red de socios representa acuerdos entre tu empresa y otras empresas necesarias para
producir y comercializar tu producto. Incluyen proveedores de materiales y piezas, puntos
de venta, transportistas, agencias de publicidad y medios de comunicacin. Comercializar
el valor de tu producto depende de tu colaboracin.
Estructuras de costo
Los gastos necesarios para fabricar un producto o servicio es la estructura de costos. Esto
incluye los costos fijos como arrendamientos o pagos de la hipoteca y los costos variables,
como investigacin y desarrollo, comercializacin, transporte y nmina. La proporcin de
costes fijos a costes variables representa la estructura de costos.
Va de ingresos
Las formas que una empresa hace ingresos son tus fuentes de ingresos. De manera ms
frecuente se trata de ingresos por ventas. Sin embargo, puede hacer referencia a la
mercanca vendida y devoluciones de valor aadido de los consumidores, socios o
terceros como marketing viral o social no solicitado.
2.3 Estndares
Lenguaje de modelado IDEF0
IDEF0 constituye una tcnica de modelacin grfica, especializada en la representacin
de las relaciones e interdependencias existentes entre los diferentes procesos.
Su principal caracterstica consiste en su capacidad para diferenciar entre tres tipos
posibles de relacin entre procesos:
a. relaciones que establecen las guas que debe tener en cuenta el proceso.
b. relaciones que aportan los recursos necesarios para llevar a cabo el proceso.
c. relaciones de encadenamiento lineal entre procesos (entrada salida).

Cadena de proceso guiada por eventos. Event-driven Process Chain (EPC)

EPC es modelo dinmico que representa juntos los recursos del negocio como son los
sistemas, la organizacin, datos e informacin y los organiza para brindar una secuencia
de tareas o actividades (el proceso) que aaden valor al negocio. [Davis, 2001]
Esencialmente hay cuatro tipos de objetos usados en EPC:
Eventos
Funciones
Reglas
Recursos (Datos, organizacin, sistemas)
La filosofa bsica en este tipo de modelos es representar una secuencia evento-funcinevento-funcin-evento, especificando para cada funcin las reglas y recursos que
intervienen.

Lenguaje de Modelado Unificado (UML)

Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema de
software. UML ofrece un estndar para describir un plano del sistema (modelo),
incluyendo aspectos conceptuales tales como procesos de negocios y funciones del
sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas
de bases de datos y componentes de software reutilizables. [Enciclopedia Online
Wikipedia, 2008c]
Es importante resaltar que UML es un lenguaje para especificar y no para describir
mtodos o procesos. Se utiliza para definir un sistema de software, para detallar los
artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en
el que est descrito el modelo. Se puede aplicar en una gran variedad de formas para dar
soporte a una metodologa de desarrollo de software, pero no especifica en s mismo qu
metodologa o proceso usar.
Notacin para la Modelacin de Procesos de Negocio. (BPMN)
BPMN es una notacin para el modelado de procesos de negocios desarrollada por la
BPMI una organizacin incluye compaas como: Intalio, SAP, Sun, y Versata, siendo una
agrupacin que tiene dentro de sus objetivos principales el crear una notacin estndar
para el modelado de procesos de negocio. Provee una notacin grfica para expresar los
procesos de negocio en un diagrama de procesos de negocio.
Tiene como objetivo principal servir como soporte para la gestin por procesos, como una
notacin que pueda ser entendida fcilmente desde los analistas que crean los bocetos
iniciales del proceso, los desarrolladores tcnicos responsables de implementar la
tecnologa que ejecutar estos procesos, hasta las personas que los ejecutan y aquellas que
llevaran a cabo el monitoreo y supervisin de los procesos. En otras palabras esta
notacin crea un enlace entre las etapas de diseo e implementacin.
A pesar de ser intuitiva para todos los usuarios de negocio es capaz de representar
semnticas de procesos complejos. Otro objetivo es asegurar que los lenguajes XML
diseados para la ejecucin de procesos de negocio puedan ser visualizados con una
notacin comn, dentro de estos lenguajes encontramos por ejemplo BPEL4WS, que es
un lenguaje de ejecucin de procesos de negocios para servicios web. [White, 2003]
Dentro de todos estos lenguajes y notaciones el ms integrador es BPMN, para su
construccin sus creadores, los miembros del grupo de trabajo para la notacin de BPMI,
revisaron y analizaron diferentes notaciones existentes tomando de ellas las mejores ideas
consolidndolas en una notacin estndar. Entre las notaciones y metodologas revisadas
estn: Diagrama de Actividad de UML, IDEF, ebXML BPSS, Diagrama ADF, RosettaNet,
LOVeM y EPCs entre otras.

2.4 Diagramas

UNIDAD 3: INGENIERIA DE REQUISITOS.

3.1 Caractersticas De los Requisitos
Es importante no perder de vista que un requerimiento debe ser:
Especificado por escrito: Como todo contrato o acuerdo entre dos partes.
Posible de probar o verificar. Si un requerimiento no se puede comprobar, entonces
cmo se sabe si se cumpli con l o no?
Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser
simple y clara para aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento est completo si no necesita ampliar detalles en su
redaccin, es decir, si se proporciona la informacin suficiente para su comprensin.
Consistente: Un requerimiento es consistente si no es contradictorio con otro
requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El
lenguaje usado en su definicin, no debe causar confusiones al lector.
3.2 Tipos de requerimientos (Funcionales, No Funcionales)
Los requerimientos de software pueden dividirse en 2 categoras: requerimientos
funcionales y requerimientos no funcionales.
Requerimientos funcionales. Son los que definen las funciones que el sistema ser
capaz de realizar, describen las transformaciones que el sistema realiza sobre las entradas
para producir salidas.

Requerimientos no funcionales. Requerimientos no funcionales tienen que ver con

caractersticas que de una u otra forma puedan limitar el sistema, como por ejemplo, el
rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estndares, etc.

3.3 Tareas Y Tcnicas De la Ingeniera De Requisitos

Tareas de la ingeniera de requisitos
Extraccin: Esta fase representa el comienzo de cada ciclo. Extraccin es el nombre
comnmente dado a las actividades involucradas en el descubrimiento de los requisitos
del sistema.
Anlisis: Sobre la base de la extraccin realizada previamente, comienza esta fase en la
cual se enfoca en descubrir problemas con los requisitos del sistema identificados hasta el
momento.
Especificacin: En esta fase se documentan los requisitos acordados con el cliente, en un
nivel apropiado de detalle.
Validacin: La validacin es la etapa final de la IR. Su objetivo es, ratificar los requisitos,
es decir, verificar todos los requisitos que aparecen en el documento especificado para
asegurarse que representan una descripcin, por lo menos, aceptable del sistema que se
debe implementar. Esto implica verificar que los requisitos sean consistentes y que estn
completos.
Tcnicas de la ingeniera de requisitos.
Entrevistas y Cuestionarios. Las entrevistas y cuestionarios se emplean para reunir
informacin proveniente de personas o de grupos.
Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en
una serie de preguntas relacionadas con varios aspectos de un sistema.
Por lo comn, los encuestados son usuarios de los sistemas existentes o usuarios en
potencia del sistema propuesto. En algunos casos, son gerentes o empleados que
proporcionan datos para el sistema propuesto o que sern afectados por l. El xito de esta
tcnica, depende de la habilidad del entrevistador y de su preparacin para la misma.
Sistemas Existentes. Esta tcnica consiste en analizar distintos sistemas ya desarrollados
que estn relacionados con el sistema a ser construido. Por un lado, podemos analizar las
interfaces de usuario, observando el tipo de informacin que se maneja y cmo es
manejada, por otro lado tambin es til analizar las distintas
Salidas que los sistemas producen (listados, consultas, etc.), porque siempre pueden surgir
nuevas ideas sobre la base de estas.
Lluvia de ideas Este es un modelo que se usa para generar ideas. La intencin en su
aplicacin es la de generar la mxima cantidad posible de requerimientos para el sistema.
No hay que detenerse en pensar si la idea eso no del todo utilizable. La intencin de este
ejercicio es generar, en una primera instancia, muchas ideas.

Prototipos Durante la actividad de extraccin de requerimientos, puede ocurrir que

algunos requerimientos no estn demasiado claros o que no se est muy seguro de haber
entendido correctamente los requerimientos obtenidos hasta el momento, todo lo cual
puede llevar a un desarrollo no eficaz del sistema final.
Entonces, para validar los requerimientos hallados, se construyen prototipos. Los
prototipos son simulaciones del posible producto, que luego son utilizados por el usuario
final, permitindonos conseguir una importante retroalimentacin en cuanto a si el sistema
diseado con base a los requerimientos recolectados le permite al usuario realizar su
trabajo de manera eficiente y efectiva. El desarrollo del prototipo comienza con la captura
de requerimientos. Desarrolladores y clientes se
Renen y definen los objetivos globales del software, identifican todos los requerimientos
que son conocidos, y sealan reas en las que ser necesaria la profundizacin en las
definiciones. Luego de esto, tiene lugar un diseo rpido. El diseo rpido se centra en
una representacin de aquellos aspectos del software que sern visibles al usuario (por
ejemplo, entradas y formatos de las salidas). El diseo rpido lleva a la construccin de un
prototipo.
Casos de Uso Los casos de uso son una tcnica para especificar el comportamiento de un
sistema. Un caso de uso es una secuencia de transacciones que son desarrolladas por un
Sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los
diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento
de un sistema mediante su interaccin con los usuarios y/o otros sistemas
Los casos de uso permiten entonces describir la posible secuencia de interacciones entre
el sistema y uno o ms actores, en respuesta a un estmulo inicial proveniente de un actor,
es una descripcin de un conjunto de escenarios, cada uno de ellos comenzado con un
evento inicial desde un actor hacia el sistema.
3.4 Obtencin De Requerimientos (Tcnicas De Recopilacin De
Representacin De Requisitos)

Informacin

El proceso de obtencin de requisitos, cuya finalidad es llevar a la luz los requisitos, no

solo es un proceso tcnico, sino tambin un proceso social que envuelve a diferentes
personas, lo que conlleva dificultades aadidas a su realizacin.
Tcnicas Para la Obtencin de Requerimientos
Existe un gran nmero de tcnicas para obtener requerimientos. A continuacin describo
las ms utilizadas. Hay que aclarar que ninguna de estas tcnicas es suficiente por s sola
y que es recomendable combinarlas para obtener requerimientos completos.
Entrevistas
La entrevista es de gran utilidad para obtener informacin cualitativa como opiniones, o
descripciones subjetivas de actividades. Es una tcnica muy utilizada, y requiere una
mayor preparacin y experiencia por parte del analista. La entrevista se puede definir
como un intento sistemtico de recoger informacin de otra persona a travs de una
comunicacin interpersonal que se lleva a cabo por medio de una conversacin
estructurada. Debe quedar claro que no basta con hacer preguntas para obtener toda la
informacin necesaria. Es muy importante la forma en que se plantea la conversacin y la
relacin que se establece en la entrevista.

Estos son algunos de los aspectos ms importantes a tener en cuenta al realizar

entrevistas:
Preparacin. Es necesario documentarse e investigar la situacin de la organizacin
analizando los documentos disponibles, de tal forma que la entrevista se enfoque en
aquellos aspectos que estn solamente en la mente del entrevistado y que no son
accesibles por otros medios como la observacin o el anlisis de documentos.
Entrevistar al personal adecuado. La mayora de los analistas adoptan un enfoque topdon, comenzando a entrevistar a directivos para que brinden un panorama general de
hacia donde deberan ir las cosas, y terminando por hablar con los empleados que aportan
detalles importantes de la operacin.
Duracin. Una entrevista debera durar a lo sumo un par de horas.
Formato. Se recomienda utilizar preguntas abiertas, donde los entrevistados puedan
elaborar y dar detalles, ms all de simplemente responder si o no.
Desarrollo Conjunto de Aplicaciones (JAD)
Es una tcnica que se utiliza para promover la cooperacin y el trabajo en equipo entre
usuarios y analistas. Consiste en realizar sesiones en las que participan usuarios expertos
del dominio junto a analistas de software. La idea es aprovechar la dinmica de grupos
aplicando un proceso de trabajo sistemtico y organizado, apoyado por elementos visuales
de comunicacin y comprensin de soluciones.
Las razones que sirven de base a JAD son las siguientes:
Las entrevistas requieren mucho tiempo, no solo en prepararlas y hacerlas sino tambin en
redactar un conjunto de requisitos coherente a partir de opiniones diferentes de los
distintos entrevistados.
Es ms difcil apreciar posibles errores en la especificacin de requisitos, ya que slo el
analista revisa el documento. En el JAD todo el grupo puede actuar como revisor y
detectar defectos.
El JAD propugna una participacin ms profunda de los usuarios en el proyecto, hasta tal
punto que los usuarios que participan adquieren un cierto sentido de propiedad en el
sistema que se construye.
El JAD no se utiliza demasiado, debido a que requiere una mayor organizacin que las
entrevistas y porque el ambiente o los mtodos de trabajo convencionales en las empresas
no facilitan este tipo de actividades (falta de tiempo, dificultad de coordinacin de tanta
gente, dificultad para convencer a la direccin, etc.). No obstante las empresas que han
implantado este mtodo han informado de importantes ahorros de tiempo en el desarrollo
de software, as como de una mayor satisfaccin de los usuarios con los sistemas
construidos.
Desarrollo de Prototipos
Los prototipos suelen consistir en versiones reducidas, demos o conjuntos de pantallas
(que no son totalmente operativos) de la aplicacin pedida. Esta tcnica es
particularmente til cuando:
El rea de la aplicacin no est bien definida (posiblemente por ser algo muy novedoso).
El costo del rechazo de la aplicacin por los usuarios es muy alto.
Es necesario evaluar previamente el impacto del sistema en los usuarios y en la
organizacin.
Los prototipos de sistema permiten a los usuarios experimentar para ver cmo ste ayuda
a su trabajo. Fomentan el desarrollo de ideas que desembocan en requerimientos. Adems

1.
2.
3.
4.

de permitir a los usuarios mejorar las especificaciones de requerimientos, el desarrollo de

un prototipo tiene otras ventajas:
Al demostrar las funciones del sistema se identifican las discrepancias entre los
desarrolladores y los usuarios.
Durante el desarrollo del prototipo, el personal del desarrollo de software puede darse
cuenta de que los requerimientos son inconsistentes y/o estn incompletos.
Aunque limitado, se dispone rpidamente de un sistema que funciona y demuestra la
factibilidad y usabilidad de la aplicacin a administrar.
El prototipo se utiliza como base para escribir la especificacin para la produccin.
En general, el uso de esta tcnica es un medio que permite solventar objeciones del
usuario del tipo: No s exactamente lo que quiero, pero lo sabr cuando lo vea. Por lo
general, la construccin de prototipos incrementa los costos en las etapas iniciales de un
proyecto, pero esto se recupera en etapas posteriores gracias al mejor entendimiento de los
requerimientos por parte de los desarrolladores. En algunos casos tambin se utiliza como
un medio para formalizar la aceptacin previa del cliente de los requisitos del proyecto.
Observacin
Por medio de esta tcnica el analista obtiene informacin de primera mano sobre la forma
en que se efectan las actividades. Este mtodo permite observar la forma en que se llevan
a cabo los procesos y, por otro, verificar que realmente se sigan todos los pasos
especificados. Como sabemos, en muchos casos los procesos son una cosa en papel y otra
muy diferente en la prctica. Los observadores experimentados saben qu buscar y cmo
evaluar la relevancia de lo que observan.
Estudio de documentacin
Varios tipos de documentacin, como manuales y reportes, pueden proporcionar al
analista informacin valiosa con respecto a las organizaciones y a sus operaciones. La
documentacin difcilmente refleja la forma en que realmente se desarrollan las
actividades, o donde se encuentra el poder de la toma de decisiones. Sin embargo, puede
ser de gran importancia para introducir al analista al dominio de operacin y el
vocabulario que utiliza.
Cuestionarios
El uso de cuestionarios permite a los analistas reunir informacin proveniente de un grupo
grande de personas. El empleo de formatos estandarizados para las preguntas puede
proporcionar datos ms confiables que otras tcnicas; por otra parte, su amplia
distribucin asegura el anonimato de los encuestados, situacin que puede conducir a
respuestas ms honestas.
El inconveniente es que la respuesta puede ser limitada, ya que es posible que no tenga
mucha importancia para los encuestados llenar el cuestionario. Es recomendable
conseguir apoyo de la alta direccin para solicitar a las personas de la organizacin que
contesten el cuestionario.
Al igual que con las entrevistas, se debe seleccionar a los encuestados. El analista debe
asegurar que el conocimiento y experiencia de stos califiquen para dar respuestas a las
preguntas.
Tormenta de ideas (Brainstorming)
Consiste en reuniones con cuatro a diez personas donde como primer paso sugieren toda
clase de ideas sin juzgar su validez por muy disparatadas que parezcan, y despus de
recopilar todas las ideas se realiza un anlisis detallado de cada propuesta. Esta tcnica se
puede utilizar para identificar un primer conjunto de requisitos en aquellos casos donde no

1.
2.
3.
4.

1.
2.
3.
4.

estn muy claras las necesidades que hay que cubrir, o cuando se est creando un sistema
que habilitar un servicio nuevo para la organizacin.
ETHICS (Implementacin Efectiva de Sistemas Informticos desde los puntos de vista
Humano y Tcnico)
Constituye un mtodo bastante evolucionado para fomentar la participacin de los
usuarios en los proyectos. Creado por E. Mumford en 1979, coordina la perspectiva social
de los sistemas con su implementacin tcnica. Un sistema no tiene xito si no se ajusta a
los factores sociales y organizacionales que rigen a la empresa. Se busca la satisfaccin de
los empleados en el trabajo a travs de estudios integrales. Los requisitos tcnicos del
sistema sern los necesarios para mejorar la situacin de los empleados (y, por lo tanto, su
productividad) en funcin de dichos anlisis.
Puntos de Vista
Cualquier sistema de software no trivial debe satisfacer las necesidades de un grupo
diverso de interesados (stakeholders). Cada uno de estos puede tener intereses diferentes
en el sistema de software, y por lo tanto sus necesidades pueden generar requerimientos
que tengan conflicto entre s, o incluso se contradigan.
Los mtodos orientados a puntos de vista (viewpoints) toman en consideracin estas
perspectivas diferentes y las utilizan para estructurar y organizar tanto el proceso de
obtencin, como los requerimientos mismos. Uno de estos mtodos es el mtodo VORD
(Definicin de Requerimientos Orientado a Puntos de Vista), el cual provee un marco de
trabajo orientado para la obtencin y documentacin de requerimientos. Las etapas
principales de este mtodo son:
Identificacin de puntos de vista, que implica descubrir los que reciben los servicios del
sistema e identificar los servicios especficos que se suministran a cada punto de vista.
Estructuracin de puntos de vista, que comprende agrupar los relacionados en una
jerarqua. Los servicios comunes se ubican en los niveles altos de la jerarqua y se
heredan los puntos de vista de bajo nivel.
Documentacin de puntos de vista, que comprende refinar la descripcin de stos y los
servicios identificados.
Trazado del punto de vista del sistema, que comprende identificar los objetos en un diseo
orientado a objetos utilizando la informacin del servicio encapsulado en los puntos de
vista.
Escenarios
Estos se utilizan para documentar el comportamiento del sistema cuando se le presentan
eventos especficos. Cada evento de interaccin distinto, o la seleccin de un servicio del
sistema, se documentan como un escenario de eventos distinto. Los escenarios de eventos
incluyen una descripcin del flujo de datos y las acciones del sistema, y documenta las
excepciones que puedan surgir.
Las convenciones para los diagramas utilizados en los escenarios de eventos son:
Los datos proporcionados desde un punto de vista o proporcionados a ste se representan
como elipses.
Las entradas y salidas de la informacin de control se ubican en la parte superior de cada
recuadro.
Las salidas de datos se ubican a la derecha de cada recuadro. Si no estn encerradas,
significa que pertenecen al sistema.
Las excepciones se muestran en la parte inferior del recuadro. Si existen varias
excepciones posibles, stas se encierran en un recuadro.

5. El nombre del siguiente evento esperado despus de completar el escenario se muestra en

un recuadro sombreado.
Los Casos de Uso son una tcnica que se basa en escenarios para la obtencin de
requerimientos. Actualmente se han convertido en una tcnica fundamental que se utiliza
para analizar y describir modelos de sistemas orientados a objetos. En su forma ms
simple, un caso de uso identifica a los actores involucrados en una interaccin y nombra
al tipo de sta.
Etnografa
Los sistemas de software no existen de forma aislada; se utilizan en un contexto social y
organizacional, y los requerimientos de sistemas de software se derivan y se restringen
acorde a ese contexto. Satisfacer esos requerimientos sociales y organizacionales es
crtico para el xito del sistema. Una razn de por qu muchos sistemas de software se
entregan pero nunca se utilizan es porque no se toma en cuenta la importancia de este tipo
de requerimientos.
La etnografa es una tcnica de observacin que se puede utilizar para entender los
requerimientos sociales y organizacionales. Un analista se sumerge por s solo en el
entorno laboral donde el sistema se utilizar. El trabajo diario se observa y se hacen notas
de las tareas reales en las que los participantes estn involucrados. La etnografa es
especialmente efectiva para descubrir dos tipos de requerimientos:
1. Los requerimientos que se derivan de la forma en la que la gente trabaja realmente ms
que de la forma en la que las definiciones de los procesos establecen que debera trabajar.
2. Los requerimientos que se derivan de la cooperacin y conocimiento de las actividades de
la gente.
Los estudios etnogrficos pueden revelar los detalles de los procesos crticos que otras
tcnicas de obtencin de requerimientos a menudo olvidan. Sin embargo, puesto que se
centran en el usuario final, este enfoque no es apropiado para descubrir los requerimientos
organizacionales o del dominio. La etnografa tampoco est diseada para identificar
nuevas propiedades a agregar al sistema. Por lo tanto, la etnografa no es un enfoque
completo para la obtencin de requerimientos y debe utilizarse en conjunto con otras
tcnicas, como el anlisis de casos de uso.
Estrategia para la obtencin de requerimientos
Hemos descrito un nmero considerable de tcnicas para la obtencin de requerimientos.
A continuacin sugiero una estrategia de cmo aplicar estas tcnicas dentro de un proceso
ordenado y que aproveche al mximo cada tcnica. Esto evitar que los analistas con poca
experiencia caigamos en un error muy comn, que es el de pasar demasiado pronto a las
entrevistas, lo cual es un desperdicio de tiempo.
Los pasos de la estrategia sugerida son:
1. Aprender todo lo que se pueda de los documentos, formularios, informes y archivos
existentes. Es sorprendente lo que se puede aprender de un sistema sin necesidad de
quitarle tiempo a la gente.
2. De ser posible, se observar el sistema en accin. No se plantearn preguntas. Tan slo se
observar y se tomarn notas o dibujos. Conviene asegurarse de que las personas
observadas saben que no se les est evaluando. En caso contrario, harn su trabajo de
manera ms eficaz que lo normal.
3. Disear y distribuir cuestionarios para aclarar cuestiones que no se comprenden bien. Ser
tambin buen momento para solicitar opiniones sobre los problemas y las limitaciones.
Los cuestionarios requieren que los usuarios inviertan una parte de su tiempo. Pero son
ellos los que pueden elegir cundo les viene mejor hacerlo.

4. Realizar entrevistas (o sesiones de trabajo en grupo, como JAD). Como ya se ha recogido

una base de requerimientos iniciales en los pasos anteriores, se pueden utilizar las
entrevistas para verificar y aclarar las cuestiones y los problemas de mayor dificultad. En
este punto se pueden llegar a aplicar algunas de las otras tcnicas cmo Escenarios,
Tormenta de ideas, Puntos de Vista, ETHICS y Desarrollo de Prototipos.
5. Se verifican los requerimientos a travs del uso de tcnicas como Entrevistas,
Observacin y orientados a Puntos de Vista.
Esta estrategia no es intocable. Aunque habra que desarrollar una estrategia de
investigacin de hechos para todas las fases pertinentes del desarrollo de sistemas, cada
proyecto tiene sus propias particularidades. A veces, la observacin o los cuestionarios
pueden no ser apropiados. Pero debera mantenerse la idea de recabar siempre todos los
hechos que sea posible antes de concertar entrevistas.
3.5 Herramientas Case Para La Ingeniera De Requerimientos
Las herramientas para la gestin de requisitos de software se limitaban a editores de texto,
los cuales hacan de esta tarea una labor tediosa y confusa. Actualmente, se cuenta con
mltiples opciones, como las que se mencionan a continuacin:
IRQA 43
Herramienta CASE de Ingeniera de Requisitos, diseada para soportar las actividades
realizadas en el proceso de especificacin de sistemas. sta facilita y formaliza la
comunicacin entre el cliente, el proveedor y los distintos miembros del equipo de
desarrollo.
Facilita la captura, organizacin y anlisis de las condiciones, as como la especificacin
de la solucin mediante el apoyo metodolgico adaptable a cada cliente.
RETO
Esta herramienta propone un modelo de requisitos para capturar los aspectos funcionales
del sistema; bsicamente, mediante tres tcnicas complementarias entre s: la definicin
de la Misin del Sistema, la construccin del rbol de Refinamiento de Funciones y el
desarrollo del Modelo de Casos de Uso.
Adems, se introduce un Proceso de Anlisis que permite traducir el Modelo de
Requisitos en el Modelo Conceptual, manteniendo la trazabilidad entre ambos y
propiciando una representacin de la informacin en el segundo prototipo.
CONTROLA
Herramienta de apoyo al proceso de ingeniera de software en pequeas empresas. Se cre
gracias a la expansin que tuvo el mercado y a la generacin de grandes y pequeas
empresas, las cuales requieren un instrumento para el desarrollo de sus proyectos.
Ofrece recursos importantes tales como: Administracin de requisitos, administracin de
casos de uso, administracin de casos de prueba y error, planeamiento de liberaciones,
administracin de implementaciones, control de dependencia entre Implementaciones,
matriz de rastreabilidad y rastreabilidad de los requisitos.

OSRMT (Open Source Requirements Management Tool)

Herramienta libre para la gestin de requisitos, cuyas principales caractersticas son:
trabaja en arquitectura cliente/servidor, desarrollada bajo Java; la versin 1.3 trae un
mdulo para manejar la trazabilidad y lo introduce para el control de cambios; as mismo,
genera la documentacin de los requisitos tratados.
JEREMIA
Se trata exclusivamente de una aplicacin cliente exclusivamente, lo cual no permite la
posibilidad de trabajar en equipo. sta, ayuda durante el desarrollo del sistema,
especialmente en el seguimiento de cambios de los requisitos a lo largo del ciclo de vida.
Con JEREMIA es posible captar las necesidades, analizarlas y clasificarlas. Implementa
un mdulo orientado a la generacin de la documentacin posible de exportar en formato
DocBook XML, la cual junto con los requisitos, se almacena en una base de datos en
MySQL.
RAMBUTAN
Esta herramienta est basada en XML, realmente consta de un conjunto de aplicaciones
para el usuario final, ayudando a los analistas de sistemas en la recopilacin y
categorizacin de hechos en un documento de especificacin de requisitos. Lo curioso es
que tiene un cliente para palm (PDA), el cual se utiliza para recopilar los hechos en el
lugar donde est ubicado el cliente mientras que la aplicacin de escritorio recibe la
informacin, edita y perfecciona.
Ambas aplicaciones permiten al usuario introducir, modificar y visualizar los datos que
componen un documento de especificacin de requisitos. Comparada con otras
herramientas de gestin de requisitos, Rambutan ofrece las siguientes ventajas
competitivas: Aplicacin cliente para palm (PDAclass), portabilidad entre plataformas, es
independiente de cualquier metodologa de especificacin de requisitos, y permite
distribucin libre.
Existen otras herramientas en estudios para la gestin de requisitos. A continuacin se
mencionan, algunas de las incluidas en el estudio comparativo presentado por El Consejo
Internacional sobre la
Ingeniera de Sistemas (INCOSE)7: CaliberRM, REM,
SMART TRACE, SoftREQ, Analyst Real Team System.
3.6 Especificacin De Requerimientos De Software
La especificacin de requisitos de software (ERS) es una descripcin completa del
comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso
que describe todas las interacciones que tendrn los usuarios con el software. Los casos de
uso tambin son conocidos como requisitos funcionales. Adems de los casos de uso, la
ERS tambin contiene requisitos no funcionales (o complementarios). Los requisitos no
funcionales son requisitos que imponen restricciones en el diseo o la implementacin,
como, por ejemplo, restricciones en el diseo o estndares de calidad.
Est dirigida tanto al cliente como al equipo de desarrollo. El lenguaje utilizado para su
redaccin debe ser informal, de forma que sea fcilmente comprensible para todas las
partes involucradas en el desarrollo.

1.
2.
3.
4.

Prcticas recomendadas para una buena ERS.

Las caractersticas de una buena ERS son definidas por el estndar IEEE 830-1998. Una
buena ERS debe ser:
Completa. Todos los requerimientos deben estar reflejados en ella y todas las referencias
deben estar definidas.
Consistente. Debe ser coherente con los propios requerimientos y tambin con otros
documentos de especificacin.
Inequvoca. La redaccin debe ser clara de modo que no se pueda mal interpretar.
Correcta. El software debe cumplir con los requisitos de la especificacin.
Trazable. Se refiere a la posibilidad de verificar la historia, ubicacin o aplicacin de un
tem a travs de su identificacin almacenada y documentada.
Priorizable. Los requisitos deben poder organizarse jerrquicamente segn su relevancia
para el negocio y clasificndolos en esenciales, condicionales y opcionales.
Modificable. Aunque todo requerimiento es modificable, se refiere a que debe ser
fcilmente modificable.
Verificable. Debe existir un mtodo finito sin costo para poder probarlo.
Tipos de requisitos
Existen varios tipos de requisitos como lo son:
Requisitos de Usuarios: Necesidades que los usuarios expresan verbalmente
Requisitos del Sistema: Son los componentes que el sistema debe tener para realizar
determinadas tareas
Requisitos Funcionales: Servicios que el sistema debe proporcionar
Requisitos no funcionales: Restricciones que afectaran al sistema

UNIDAD 4: MODELO DE ANALISIS

4.1 Clases
Las clases son declaraciones o abstracciones de objetos, lo que significa, que una clase es
la definicin de un objeto. Cuando se programa un objeto y se definen sus caractersticas
y
funcionalidades,
realmente
se
programa
una
clase.
Una clase es un contenedor de uno o ms datos (variables o propiedad miembro) junto a
las operaciones de manipulacin de dichos datos (funciones/mtodos). Las clases pueden
definirse como estructuras (struct), uniones (union) o clases (class) pudiendo existir
diferencias entre cada una de las definiciones segn el lenguaje. Adems las clases son
agrupaciones de objetos que describen su comportamiento clases. Las clases son lo ms
simple de Java. Todo en Java forma parte de una clase, es una clase o describe cmo
funciona una clase.
El conocimiento de las clases es fundamental para poder entender los programas Java.
Todas las acciones de los programas Java se colocan dentro del bloque de una clase o un
objeto. Todos los mtodos se definen dentro del bloque de la clase, Java no soporta
funciones o variables globales. Esto puede despistar a los programadores de C++, que
pueden definir mtodos fuera del bloque de la clase, pero esta posibilidad es ms un
intento de no separarse mucho y ser compatible con C, que un buen diseo orientado a

objetos. As pues, el esqueleto de cualquier aplicacin Java se basa en la definicin de una

clase.
Todos los datos bsicos, como los enteros, se deben declarar en las clases antes de hacer
uso de ellos. En C la unidad fundamental son los ficheros con cdigo fuente, en Java son
las clases. De hecho son pocas las sentencias que se pueden colocar fuera del bloque de
una clase. La palabra clave import (equivalente al #include) puede colocarse al principio
de un fichero, fuera del bloque de la clase. Sin embargo, el compilador reemplazar esa
sentencia con el contenido del fichero que se indique, que consistir, como es de suponer,
en ms clases.
4.2 Objetos
El objetivo del Anlisis Orientado a Objetos (AOO) es desarrollar un modelo que describa
el software de computadora necesario para satisfacer los requisitos definidos por el
cliente. El modelo de anlisis contiene el funcionamiento y el comportamiento de los
elementos del modelo de objetos.
Nadie tiene muy claro por qu el Anlisis Orientado a Objetos ha tardado tanto tiempo en
ser aplicado a pesar de que maneja conceptos que aprendimos en la guardera como
objeto, clase, miembro etc. No existe un acuerdo sobre los conceptos que sirven de base
para el AOO, aunque se repiten a menudo un nmero de ideas clave.
El propsito es definir todas las clases, atributos, operaciones y relaciones de
comportamiento asociado entre ellos que sean relevantes al problema que se va a resolver.
Para realizar dicho anlisis se deben ejecutar las siguientes tareas:
-Identificar los escenarios o casos de uso.
-Identificar las clases,
-Definir sus atributos y mtodos.
-Especificar la jerarqua entre las clases.
-Representar las relaciones entre los diferentes objetos del sistema.
-Modelar el comportamiento de cada objeto.
-Repetir iterativamente las tareas anteriores hasta completar el modelo.

4.3 Modelo De Requerimientos.

Elementos del modelo de requerimientos
Hay muchas formas diferentes de concebir los requerimientos para un sistema basado en
computadora. Algunos profesionales del software afirman que es mejor seleccionar un
modo de representacin (por ejemplo, el caso de uso) y aplicarlo hasta excluir a todos los
dems. Otros piensan que es ms benfico usar cierto nmero de modos de representacin
distintos para ilustrar el modelo de requerimientos. Los elementos especficos del modelo
de requerimientos estn determinados por el mtodo de anlisis del modelado que se use.
No obstante, la mayora de modelos tienen en comn un conjunto de elementos generales.
Elementos basados en el escritorio
El sistema se describe desde el punto de vista del usuario con el empleo de un enfoque
basado en el escenario. por ejemplo, los casos de us bsico y sus diagramas
correspondientes de casos de usos evolucionan haca otros ms elaborados que se basan
en formatos. Los elementos del modelo de requerimiento basados en el escenario con
frecuencia son la primera parte del modelo en desarrollo. Cmo tales, sirven cmo entrada
para la creacin de otros elementos del modelado.
Elementos basados en clases
Cada escenario de us implica un conjunto de objetos que se manipulan cundo un actor
interacta con el sistema. Estos objetos se clasifican en clases: Conjunto de objetos que
tienen atributos similares y comportamientos comunes. Por ejemplo, para ilustrar la clase
Sensor de la funcin de seguridad de Casa Segura puede utilizar un diagrama de clase de
UML.
Elementos del comportamiento
El comportamiento de un sistema basado en computadora tiene un efecto profundo en el
diseo que se elija y en el enfoque de implementacin que se aplique. Por tanto, el
modelo de requerimientos debe proveer elementos de modelado que ilustren el
comportamiento.
El diagrama de estado es un mtodo de representacin del comportamiento de un sistema
que ilustra sus estados y los eventos que ocasionan que el sistema cambie de estado. un
estado es cualquier modo de comportamiento observable desde el exterior. Adems, el
diagrama de estado indica acciones (como la activacin de un proceso, por ejemplo)
tomadas como consecuencia de un evento en particular.
Elementos orientados al flujo
La informacin se transforma cundo fluye a travs de un sistema basado en
computadora. El sistema acepta entradas en varias formas, aplica funciones para
transformarla y produce salidas en distintos modos. La entrada puede es una seal de
control transmitida por un transductor, una serie de nmeros escritos con el teclado por un
operador humano, un paquete de informacin enviado por un enlace de red o un archivo
grande de datos recuperado de un almacenamiento secundario. En efecto, es posible crear
un modelo del flujo para cualquier sistema basado en computadora, sin importar su
tamao y complejidad.

4.3 Modelo De Caso de Uso

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una forma de
diagrama de comportamiento UML mejorado. El Lenguaje de Modelado
Unificado(UML), define una notacin grfica para representar casos de uso llamada
modelo de casos de uso. UML no define estndares para que el formato escrito describa
los casos de uso, y as mucha gente no entiende que esta notacin grfica define la
naturaleza de un caso de uso; sin embargo una notacin grfica puede solo dar una vista
general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos
de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos estn
relacionados, los casos de uso son mucho ms detallados que los diagramas de casos de
uso. En los conceptos se debe detallar ms de un caso de uso para poder identificar qu es
lo que hace un caso de uso.

La descripcin escrita del comportamiento del sistema al afrontar una tarea de negocio o
un requisito de negocio. Esta descripcin se enfoca en el valor suministrado por el sistema
a entidades externas tales como usuarios humanos u otros sistemas.
La posicin o contexto del caso de uso entre otros casos de uso. Dado que es un
mecanismo de organizacin, un conjunto de casos de uso coherente y consistente
promueven una imagen fcil de comprender del comportamiento del sistema, un
entendimiento comn entre el cliente/propietario/usuario y el equipo de desarrollo.

4.5 Modelo De Dominio

Un modelo de dominio en la resolucin de problemas e ingeniera de software, es
un modelo conceptual de todos los temas relacionados con un problema especfico. En l
se describen las distintas entidades, sus atributos, papeles y relaciones, adems de las
restricciones que rigen el dominio del problema.
El modelo de dominio se crea con el fin de representar el vocabulario y los conceptos
clave del dominio del problema. El modelo de dominio tambin identifica las relaciones
entre todas las entidades comprendidas en el mbito del dominio del problema, y
comnmente identifica sus atributos. Un modelo de dominio que encapsula los mtodos
dentro de las entidades se asocia ms bien con modelos orientados a objetos. El modelo de
dominio proporciona una visin estructural del dominio que puede ser complementado
con otros puntos de vista dinmicos, como el modelo de casos de uso.

UNIDAD 5: CALIDAD DE SOFTWARE

5.1 Definicin De Calidad
Conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. la
calidad es sinnimo de eficiencia, flexibilidad, correccin, confiabilidad, mantenibilidad,
portabilidad, usabilidad, seguridad e integridad.
Es medible y vara de un sistema a otro o de un programa a otro. Un software elaborado
para el control de naves espaciales debe ser confiable al nivel de "cero fallas"; un software
hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un
producto de software para ser explotado durante un largo perodo (10 aos o ms),.
Puede medirse despus de elaborado el producto. Pero esto puede resultar muy costoso si
se detectan problemas deriva dos de imperfecciones en el diseo, por lo que es
imprescindible tener en cuenta tanto la obtencin de la calidad como su control durante
todas las etapas del ciclo de vida del software.

5.2 Importancia De La Calidad

Los fallos de software afectan a todos los sectores y a todos los pases, actualmente se
desarrolla software fiable y correcto a un costo razonable. los autnticos profesionales y
las empresas bien organizadas son prudentes y saben que deben aplicar distintas tcnicas
de control y prevencin, adems de un buen proceso de desarrollo.
Administracin

de

la

calidad

del

software

Se refiere a lograr un nivel de calidad requerido en el producto de software

Involucra a la definicin de estndares de calidad apropiados y procedimientos que
permitan
asegurar
que
estos
se
cumplan.
Debe llevar a desarrollar una cultura de calidad en donde la calidad es responsabilidad
de
todos
Comprobacin

independiente

de

los

procesos

de

desarrollo

Los productos resultantes de los procesos se introducen en el proceso de administracin

de la calidad para asegurar su consistencia con estndares y objetivos de calidad
Equipo de aseguramiento y control: independientes de los equipos de desarrollo
Responsabilidad

de

Visin

la
objetiva

administracin

de
del

la

calidad
proceso

Informan de problemas y dificultades a los administradores principales de la

organizacin.
5.3 Factores De Calidad

Entre los factores que Determinan la Calidad existen dos tipos de factores:
Factores que pueden ser medidos directamente (errores/KLDC/unidad de tiempo).
Factores que solo pueden ser medidos indirectamente (la facilidad de uso o de
mantenimiento).
En ambos casos se puede medir la calidad, debemos comparar el software (documentos,
programas, etc.) con alguna referencia y llegar a una indicacin de calidad.

Factores de Calidad segn McCall

PUNTO DE VISTA
REVISIN
PRODUCTO

DEL

FACTOR
Mantenibilidad
Flexibilidad
Testeabilidad

TRANSICIN
PRODUCTO

DEL

Portabilidad
Reusabilidad
Interoperabilidad

OPERACIN
PRODUCTO

DEL

Correctitud
Confiabilidad
Eficiencia
Integridad
Usabilidad

Factores de Calidad segn Boehm

El modelo que presenta Boehm presenta una jerarqua de caractersticas donde cada una
de ellas contribuye a la calidad global. Dentro de los factores que se describen en el
modelo se toman muchos de los que propone McCall. Parte de la estructura del modelo de
Boehm se presenta en la siguiente figura, se hace nfasis en los factores presentes en
dicho modelo. En total el modelo de Boehm presenta siete factores:

Factores de Calidad segn ISO 9126

Es un modelo jerrquico con seis atributos especiales.

5.4 Aseguramiento De La Calidad

El aseguramiento de la calidad (se usa con frecuencia el anglicismo quality assurance) es
el conjunto de actividades planificadas y sistemticas aplicadas en un sistema de gestin
de la calidad para que los requisitos de calidad de un producto o servicio sean satisfechos.
Entre estas actividades se encuentran la medicin sistemtica, la comparacin con
estndares, el seguimiento de los procesos, todas actividades asociadas con bucles de
realimentacin de informacin. Estas actividades contribuyen a la prevencin de errores,
lo cual se puede contrastar con el control de calidad, que se centra en las salidas del
proceso. Ambos conceptos suelen utilizarse de manera conjunta (vase QA/QC).
5.5 Estandares Y Metricas De Calidad
ESTNDARES
Los estndares de calidad de software son normas emitidas por organismos especficos,
que sirven para sentar un marco con el que comparar si un proceso de desarrollo es o no
de calidad. Las normas de calidad del software ms conocidas han sido desarrolladas por
ISO, y son la serie ISO-9000.
1.-ISO 9000
Las normas ISO-9000 son un estndar de calidad para todo tipo de industrias; contiene
una normativa especfica para el desarrollo de software, la ISO-9003. Consiste en una
serie de clusulas que deben aplicarse en el marco de trabajo, en el ciclo de vida del
proyecto y en las actividades de apoyo al mismo.
2.-CMMI

CMM fue desarrollado por el Software Engineering Institute en estados unidos, sirve para
comprobar la habilidad de los procesos de las organizaciones para realizar determinados
proyectos.
3.-SPICE
SPCE es el modelo de madurez propuesto por ISO, similar a CMMI.
-Factores de calidad
Los factores de calidad sirven para descomponer el concepto genrico de calidad; para
facilitar su control y su medicin. Se clasifican en:
1)Factores operativos
Los factores operativos son aquellos que afectan al uso del software.
2)Factores de mantenimiento
Los factores de mantenimiento son aquellos que se aplican a la capacidad de modificacin
del software.
3)Factores evolutivos
Los factores evolutivos son aquellos que indican si el software se puede trasladar con
facilidad a otra mquina o a otro producto de base (SO, SGBD).
MTRICAS
Las mtricas del producto son una medida cuantitativa que permite a la gente del software
tener una visin profunda de la eficacia del proceso del software y de los proyectos que
dirigen utilizando el proceso como un marco de trabajo;son analizadas y evaluadas por los
administradores del software.
-VENTAJAS DEL USO DE METRICAS:
-Determina la calidad del producto.
-Evala la productividad de los desarrolladores.
-Se tiene conocimiento cuantitativo de las caractersticas del proceso y del producto.
-Se tiene un soporte para la estimacin y la planificacin.
Se evalan los beneficios (en cuanto a calidad y productividad) derivados del uso de
nuevos mtodos y herramientas de ingeniera del software.
-Establece una lnea base para la estimacin
CARACTERISTICAS DE LAS METRICAS:
-ExactasPrecisas: No se debe perder informacin en los redondeos ya que la informacin
se desvirta.
-Consistentes: Una medicin de un atributo debe dar el mismo valor independientemente
de la medicin.

5.6 Modelos De Madurez (Enfoque De Proceso, PSP Y TSP, SPICE, CMMI,

MOPROSOFT)
Actualmente existe una gran variedad de modelos para procesos de software. Podemos
entenderlos ms fcilmente si los clasificamos en dos tipos: genricos y especficos.

Revisemos estos modelos para entender mejor su objetivo y estructura. Primero

conoceremos modelos genricos como CMM e ISO, y posteriormente estudiaremos
modelos especficos para software.
CMM (Capability Maturity Model) - Modelo de Madurez de Capacidades
Marco que describe elementos clave de procesos efectivos de software. Creado por el
Software Engineering Institute (SEI) en conjunto con Carnegie Mellon University. La
primera
versin
se
public
en
1994.
CMM describe un camino evolutivo en 5 niveles de mejora de procesos para lograr su
madurez. Cubre prcticas de planeacin, ingeniera y administracin del desarrollo y
mantenimiento de software.

1.
2.
3.
4.
5.
6.
7.
8.

ISO 9001-2000
ISO (International Standards Organization) en 1987 crea la norma ISO 9000, conjunto de
estndares que establecen los requerimientos para la gestin de los sistemas de calidad.
ISO 9000:2000 est formado por:
ISO 9000 Fundamentos y Vocabulario.
ISO 9001 Requisitos.
ISO 9004 Recomendaciones.
La parte de Requisitos - ISO 9001:2000, est estructurado en 8 secciones:
Alcance.
Normas para la Consulta.
Trminos y Definiciones.
Sistema de Gestin de la Calidad.
Responsabilidad de la Direccin.
Gestin de los Recursos.
Realizacin del Producto.
Medida, Anlisis y Mejora.
Aunque ISO 9001:2000 no otorga un estndar especfico para sistemas de desarrollo de
software, es decir, no abarca todos los procesos relacionados con el desarrollo de
software, muchas organizaciones de software han optado por gestionar su sistema de
calidad en base a este estndar, y obtener una certificacin reconocida de manera
internacional.

CMMI (Capability Maturity Model Integration) - Modelo de Madurez de Capacidades

Integrado
El proyecto de CMMI fue concebido como una iniciativa para reunir los diferentes CMMs
en un conjunto de modelos integrados, ms consistentes entre ellos. Los modelos fuente
que sirvieron como bases incluyen: CMM Software, CMM Ingeniera de Sistemas, y
CMM Desarrollo Integrado de Producto.
CMMI proporciona una gua para desarrollar procesos, que adems ayuda a evaluar la
madurez de la organizacin o capacidad de un rea de procesos. CMMI incluye los
procesos de ingeniera de software e ingeniera de sistemas.
El modelo est representado de forma continua y escalonada. Contiene 22 reas de
procesos. Cada rea de proceso est formada por: Objetivos especficos, Prcticas
especficas, Objetivos genricos, y Prcticas genricas.
CMMI Modelo Continuo
Esta formado por 5 niveles de capacidad del proceso:
0. Incompleto
1. Desempeado
2. Administrado
3. Definido
4. Administrado cuantitativamente
5. Optimizado
Y por cuatro categoras de reas de procesos: Administracin de Procesos, Administracin
de Proyectos, Ingeniera, Soporte. Estas categoras agrupan a las diferentes reas de
proceso, dividindolos en procesos bsicos y avanzados.
CMMI Modelo Escalonado
El modelo escalonado, al igual que CMM, describe un camino evolutivo en 5 niveles de
madurez de procesos, adems integra nuevas reas de proceso.
La seleccin entre el modelo escalonado y el continuo depende del objetivo de la
organizacin, adems de tener que considerar la situacin (si ya se tiene CMM, cultura en
procesos, etc.). Por ejemplo, si el objetivo es llevar a la organizacin a cierto nivel de
capacidad, deber seleccionarse la forma escalonada; en cambio si el objetivo es mejorar
cierto proceso, ser mejor seguir la forma continua.
Algunos Beneficios de CMMI vs. CMM
Algunos de los beneficios que han experimentado las organizaciones que pasan de CMM
a CMMI son los siguientes:
Mejor alineacin a objetivos de negocio.
Mejor visibilidad hacia las actividades de ingeniera, con el objetivo de asegurar que el
producto o servicio cumple las expectativas del cliente.
Aprovechamiento de mejores prcticas adicionales (e.j., medicin, riesgo, administracin,
y manejo de proveedores).
Acoplamiento ms estrecho con estndares de ISO.
ISO/IEC 15504
Estndar internacional que ofrece un marco para la evaluacin de procesos. Fue iniciado
en 1991 como el proyecto SPICE (Software Process Improvement and Capability
dEtermination). La versin de Reporte Tcnico fue aceptada y publicada en 1998,
enfocada nicamente en procesos de software.
En el transcurso de su desarrollo ha evolucionado, de ser un modelo de referencia de
buenas prcticas de software, para convertirse en un marco de trabajo para evaluacin de
mltiples modelos (de software o no). Su direccin actual es poder aplicarse a mltiples

disciplinas y permitir a las diferentes comunidades definir sus propios procesos

especficos, modelos de referencia o buenas prcticas. ISO 15504 est en vas de
convertirse en estndar internacional, y se espera que est completo para 2006. Esta
versin esta compuesta de cinco documentos, a diferencia del reporte tcnico que consta
de nueve partes (Ver grfica 1 - Estructura de documentos).
La parte 2 de este estndar es de especial inters, ya que es la que define como se realiza
una evaluacin. Establece requisitos tanto para modelos de procesos de referencia como
para los mtodos de evaluacin sin establecer alguno en particular.

Niveles de Capacidad (Ver grfica 2):

0.
Incompleto.Falta
de
cumplimiento
del
proceso.
1.
Realizado.Genera
los
productos
de
trabajo
esperados.
2. Administrado.- Proceso y productos administrados y controlados.
3. Establecido.- Proceso definido para la organizacin y utilizado adecuadamente.
4. Predecible.- El proceso opera dentro de los lmites estadsticos establecidos.
5. Optimizado.- El proceso mejora continuamente.
Las organizaciones de software no tienen que seleccionar entre 15504 y su modelo actual.
El rol de 15504 es proveer un marco de trabajo en el que los modelos y mtodos de
evaluacin puedan existir de una manera armnica. No esta diseado para ser utilizado
solo. La seleccin radica en decidir si el ajustarse a 15504 es importante para el negocio
(El negocio compite en el mercado global?, Provee software a algn cliente que
requiera 15504?, Existen varios modelos de evaluacin en la organizacin?). De ser as,
debern elegir modelos que se ajusten a 15504.

Compatibilidad entre Modelos

ISO/IEC 15504
Evaluacin de procesos de software.
En vas de ser estndar.
Direccin amplia.
Niveles de capacidad.
Evaluacin de capacidades por proceso individual.
Gua para realizar la evaluacin.
Toma como referencia ISO 9001 y CMMI.
CMMI
Modelo de madurez de procesos de software.
Modelo estndar de facto.
Direccin detallada.
Pasos progresivos (niveles) - Escalonada.
Categoras de procesos - Continua.
Gua para institucionalizacin e implementacin.
Modelo de evaluacin ser conforme al modelo de evaluacin de 15504.
ISO 9001-2000
Sistema de Gestin de la Calidad.
Estndar internacional.
Direccin amplia.
Un conjunto de requerimientos a ser cubierto.
No hay lineamientos para su implementacin.

Usado como referencia en actividades de gestin de calidad por CMMI y 15504.

Con eso conclumos nuestra revisin de modelos genricos. A continuacin veamos los
modelos especficos para software.
PSP Personal Software ProcessSM
Personal Software Process (PSP) es un proceso diseado para ayudar a los ingenieros de
software a controlar, manejar y mejorar su trabajo. PSP est basado en una motivacin: La
calidad de software depende del trabajo de cada uno de los ingenieros de software.
Debido a que los costos de personal constituyen 70% del costo del desarrollo de software,
las capacidades y hbitos de trabajo de los ingenieros determinan en gran manera los
resultados del desarrollo de software.
Basado en prcticas encontradas en CMM, el PSP puede ser usado por ingenieros para
estructurar y disciplinar el desarrollo de software. El ingeniero de software podr planear
mejor el trabajo, conocer con precisin el desempeo, medir la calidad de productos, y
mejorar las tcnicas.
PSP puede ser aplicado en:
Desarrollo de programas.
Definicin de requerimientos.
Documentacin.
Pruebas de sistemas.
Mantenimiento de sistemas.

TSP - Team Software Process

Team Software Process (TSP) es un marco para el desarrollo de software que pone igual
nfasis en el proceso, producto y trabajo en equipo. Al igual que PSP, TSP fue propuesto
por Watts Humphrey.
TSP se basa en PSP, y se fundamenta en que el software, en su mayora, es desarrollado
por equipos, por lo que los ingenieros de software deben primero saber controlar su
trabajo, y despus saber trabajar en equipo. TSP le ensea a los ingenieros a construir
equipos autodirigidos y desempearse como un miembro efectivo del equipo. Tambin
muestra a los administradores como guiar y soportar estos equipos.
Estrategia de TSP
Proveer un proceso sencillo basado en PSP.

 Desarrollar productos en varios ciclos. Ciclo de TSP: Lanzamiento, Estrategia, Plan,

Requerimientos, Diseo, Implementacin, Pruebas, Postmortem.
Establecer medidas estndares para calidad y desempeo.
Proveer definiciones de roles, y evaluaciones de rol y de equipo.
Requiere disciplina de proceso.
Provee gua para manejo de problemas de trabajo en equipo.

1.
2.
3.
4.

RUP
El Rational Unified Process (RUP) es un proceso de software desarrollado y
comercializado por Rational Software (ahora parte de IBM). RUP est diseado alrededor
de seis mejores prcticas para el desarrollo de software:
Desarrollar de manera iterativa.
Administrar los requerimientos.
Utilizar arquitecturas basadas en componentes.
Modelar el software visualmente.
Verificar la calidad de manera continua.
Controlar los cambios.
En s, RUP es una gua que define roles, actividades, flujos de trabajo y lineamientos para
ejecutar proyectos de software de acuerdo a estas mejores prcticas.
RUP organiza los proyectos de software en dos dimensiones: la del tiempo y la de las
actividades. En base al tiempo, los proyectos se dividen en cuatro fases secuenciales:
Concepcin Definicin de alcance, identificacin de riesgos.
Elaboracin Resolucin de riesgos, establecimiento de arquitectura.
Construccin Generacin del producto.
Transicin Disponibilidad a la comunidad de usuarios finales.
Las actividades se organizan en nueve diferentes disciplinas que son ejecutadas durante
las diferentes fases.

En realidad RUP es un framework (marco de trabajo) que pretende ser personalizado o

configurado para organizaciones y proyectos especficos. RUP no se puede aplicar de la
misma forma en todos los proyectos de una organizacin. Es por esto que pretender seguir
RUP a travs de ir cumpliendo con la lista de artefactos que define, es una estrategia poco
efectiva. Lo que las organizaciones deben hacer es entender la razn de ser de RUP las
prcticas citadas anteriormente y en base a esto aplicar lo que decidan que es
conveniente para cada rea o proyecto especfico.
RUP es una instancia particular del Proceso Unificado, definido por Ivar Jacobson, Grady
Booch y James Rumbaugh en el libro The Unified Software Development Process de
1998. Adicionalmente existen otras instancias de este proceso, tales como el Proceso
Unificado Mejorado (Enhanced Unified Process), el cual agrega soporte multiproyectos y
fases y disciplinas para el mantenimiento y retiro de sistemas de software.
Qu hay para la Industria Mexicana?
Mxico quiere y puede darse a conocer con una fuerte industria de software. Las
condiciones bsicas estn dadas: se generan recursos humanos capacitados, se tiene
acceso a los equipos y herramientas de desarrollo, el mercado local tiene necesidades lejos
de estar satisfechas, el mercado externo de habla hispana no est saturado y la cercana
con los E.U. trae oportunidades de exportacin potenciales.
MoProSoft, modelo de procesos para la industria de software mexicana, fue desarrollado
pensando en facilitar a las organizaciones dedicadas al desarrollo y mantenimiento de
software la adopcin de las mejores prcticas reconocidas internacionalmente a travs de
modelos como SW-CMM, CMMI, TSP, PSP, ISO/IEC 15504, PMBOK y SWEBOK.
Caractersticas
principales
1. Estructura adaptable - Los procesos estn organizados en 3 categoras, que
corresponden
a
la
estructura
de
cualquier
organizacin.
2. Nmero reducido de procesos - Slo 6 procesos principales y 3 subprocesos.
3.
Procesos
integrados
a
travs
de
roles
y
productos.
4.
Gestin
de
Negocio
como
proceso
explcito.
5. Integracin de la gestin de recursos humanos, de infraestructura y conocimiento.

6.
Verificaciones
y
validaciones
explcitas.
7.
Manejo
de
situaciones
excepcionales.
8.
Productos
de
trabajo
con
caractersticas
mnimas
explcitas.
9. Indicadores y propuestas de mediciones para evaluar el cumplimiento de los procesos.
10. Guas de ajuste para adecuar los procesos.

5.

CRONOGRAMA PRELIMINAR DE ACTIVIDADES

Agosto
Descripcin de las Actividades

1 2 3

Septiembre
4 1

Octubre
4

Noviembre

1 2 3 4 1

1. Plan rpido
2. Modelado, diseo rpido
3. Construccin del Prototipo
4. Desarrollo, entrega y
retroalimentacin
5. Comunicacin
6. Entrega del desarrollo final

6.

DESCRIPCIN DETALLADA DE LAS ACTIVIDADES

1. Se creara la base de datos.

2. Se iniciara el lector de huella.
3. Se verificara si est conectado o desconectado.
4. Se realizara la captura de la huella.
5. Se generara una imagen de la huella digital.
6. Se almacenara la huella en la base de datos asociada con un nombre.
7. Se realiza una segunda captura para la toma de asistencia
8. Se comparara la imagen generada con la almacenada en la base de datos.

Diciembre
4

9. En caso de ser igual se captura fecha y hora del sistema, se almacena en la base de
datos asociada con el nombre de la huella.
10. En caso de no ser igual se genera un mensaje de no registro.
11. En caso de contactar al administrador por no estar registrado se generara un nuevo
registro

7.

LUGAR DONDE SE REALIZARA EL PROYECTO

Instituto Tecnolgico de Pinotepa

km.26 carretera Pinotepa Nacional-Acapulco, San Jos Estancia Grande, Jamiltepec,
Oaxaca. Apartado Postal 26.
Pinotepa Nacional, Oaxaca. C.P.71600 Telfonos: 01-954 54-3 53 05, 54 3 53 06 y 54 3
52 87
www.itp.edu.mx

8.

INFORMACIN SOBRE LA EMPRESA O INSTITUCIN DONDE SE

DESARROLLAR EL TRABAJO
Descripcin detallada de la empresa, giro, direccin, ciudad o poblacin, encargado
(dueo o gerente general y responsable (asesor Externo), croquis de localizacin,
horario laboral, telfono.

9.

BIBLIOGRAFA

Sommerville, Ian (2011) Ingeniera de Software (9a. ed.) PEARSON EDUCACIN

Mxico.