04 PD DS Iis PDF

Introduccin a la Ingeniera de Software
Unidad 1. Ingeniera de Software

1

Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software
1

Ingeniera en Desarrollo de software

5 cuatrimestre

Programa de la asignatura

Clave
150920520/ 160920518
Unidad 1.
Ingeniera de Software

Universidad Abierta y a Distancia de Mxico

2

2
ndice

UNIDAD 1. INGENIERA DE SOFTWARE ......................................................................... 3
Presentacin de la unidad ........................................................................................................... 3
Propsito ........................................................................................................................................ 3
Competencia especfica .............................................................................................................. 3
Actividad 1.Intercambio de conocimientos ............................................................................... 3
1.1. Introduccin a la Ingeniera de Software ......................................................................... 4
1.1.1. Ingeniera ............................................................................................................................ 4
1.1.2. Software .............................................................................................................................. 5
1.1.3. Ingeniera de Software ..................................................................................................... 6
1.2. El proceso de desarrollo ...................................................................................................... 7
1.2.1. Mtodos de desarrollo: alternativas ................................................................................ 7
1.2.2. El proceso unificado de desarrollo ................................................................................ 14
1.2.3. Mtodos giles ................................................................................................................. 16
Actividad 2. Mtodos de desarrollo de software .................................................................... 21
Autoevaluacin ........................................................................................................................... 21
Evidencia de aprendizaje: metodologa de desarrollo .......................................................... 22
Autorreflexiones .......................................................................................................................... 22
Cierre de la unidad ..................................................................................................................... 23
Para saber ms ........................................................................................................................... 23
Fuentes de consulta ................................................................................................................... 23


3

3

Presentacin de la unidad

En esta unidad aprenders la definicin, caractersticas y elementos que conformanla
ingeniera de software, analizars los diferentes mtodos de desarrollo para comprender
cmo se relacionan con los elementos del ciclo de vida del software. Todo esto con la
finalidad de que entiendas el proceso que involucra la creacin de un software, el cual
abarca, desde la concepcin de la idea hasta su implantacin y mantenimiento.

Tambin comprenders varios procesos de desarrollo de software, cada uno con sus
ventajas y desventajas, diferentes enfoques y caractersticas. Cada uno apropiado para
un tipo de proyecto en especfico. Entender esto te servir para aplicar o recomendar en
un momento dado en tu vida profesional.

Propsito

En esta unidad logrars:

Identificar los conceptos fundamentales de la ingeniera del software.
Comparar las caractersticas de los mtodos de desarrollo de software.
Identificar los tipos de tcnicas de recoleccin
Identificar los requerimientos de un caso de estudio
Identificar diagramas del dominio y de interaccin
Analizar los lineamientos del diseo de la interfaz
Analizar los lineamientos de la codificacin
Analizar los tipos de pruebas y el proceso de mantenimiento

Competencia especfica

Analizar los diferentes mtodos de desarrollo de software para comprender cmo se
relacionan con loselementos del ciclo de vida del software, identificando las
caractersticas de cada mtodo en un caso de estudio.

Actividad 1.Intercambio de conocimientos

Bienvenido, como primera actividad tendrs la oportunidad de presentarte con el grupo y
para ello ingresarasal foroutilizando ste espacio como un medio de comunicacin, de
debate y en general de expresin de los temas relacionados con la asignatura.El

4

4
foroestar abierto durante todo el curso y consta de varias entradas o categoras a las
que debers ingresar, dependiendo del tipo de participacin que quieras hacer y estas
sern resueltas entre tus compaeros, moderadas por tu facilitador.

Comienza tu participacin contestando los siguientes datos:
Generales (nombre, edad, estado civil, lugar de procedencia, etc.).
Personales (intereses, ocupacin, gustos, aficiones, etc.).
Acadmicos (razones para estudiar esta carrera, lo que esperas de la asignatura,
conocimiento previo en los temas de la asignatura)
Del tema (para ti, Qu es la Ingeniera de Software?).
Nota: es recomendable que utilices este espacio de manera respetuosa y responsable.

Para comenzar ingresa al Foro Presentacin e intercambio de conocimientos.

1.1. Introduccin a la Ingeniera de Software

Entender el concepto de la ingeniera de software es muy importante, ya que es el
fundamento de todas las metodologas, modelos, teoras, estndares, etc. Que se han
generado a travs del tiempo, con el fin de hacer el proceso de desarrollo de software
ms exacto y predecible, de tal manera que se generen acciones de mejora que lleven a
la masificacin del producto de manera industrial y econmicamente redituable.

Antes de comenzar a explicar la ingeniera de software como tal, debers conocer que es
la ingeniera y el software por separado, entendiendo las caractersticas y elementos que
los constituyen, para que posteriormente comprendas porque uniendo ambas definiciones
conforman una amplia rea de estudio.

1.1.1.Ingeniera

Partir de la definicin de ingeniera nos permite entender porqu surge la necesidad de
generar procesos, para aplicar el ingenio, mtodos, modelos, estndares y conocimiento
cientfico, para aplicarlo en algo prctico y redituable econmicamente hablando;as como
la sistematizacin y mejora de los procesos que permitan la produccin ms rpida y
abundante de producto siendo ste un bien o servicio.

Pero entonces, Qu es la Ingeniera?

Ingeniera
(1) Conjunto de conocimientos y tcnicas que permiten aplicar el saber cientfico a la
utilizacin de la materia y de las fuentes de energa.

5

5
(2) Conjunto de conocimientos y tcnicas cuya aplicacin permite la utilizacin
racional de los materiales y de los recursos naturales, mediante invenciones,
construcciones u otras realizaciones provechosas para el hombre.
(3) Profesin y ejercicio del ingeniero.
Ingeniero
(1) Persona que profesa o ejerce la ingeniera

(Pressman, R. 2010, pg. xxi).

Por lo anteriorse puede afirmar que la ingeniera busca la aplicacin de la ciencia en los
procesos industriales para su perfeccionamiento y las personas encargadas deaplicar
estos procesos son los especialistas llamados ingenieros.

1.1.2.Software

Referente al software podemos decir que es un elemento de la computadora que abarca
la lgica de la misma, el cual es necesario para ejecutar una tarea. Tiene la propiedad de
ser intangible y se compone de sistemas operativos y de aplicacin. A continuacin se
presentan 3 definiciones:

Software
(1) Instrucciones (programas de computadora) que cuando se ejecutan proporcionan la
funcin y el rendimiento deseados.
(2) Estructuras de datos que permiten a los programas manipular adecuadamente la
informacin.
(3) Documentos que describen la operacin y el uso de programas.
(Pressman, R. 2010, pg. 7).

Como notars en las tres definiciones se refieren al software como un conjunto de
programas. Entonces podemos definir alsoftware como un cdigo escrito en un lenguaje
especfico para un procesador. El cdigo es escrito en un lenguaje de programacin.
Existen tres tipos de lenguajes:

1. Bajo nivel o lenguaje mquina (ceros y unos),
2. Ensamblador formado por mnemnicos (palabras fciles de recordar)
3. Alto nivel que se acerca ms al lenguaje humano.

Los lenguajes ensamblador y el de alto nivel requieren ser traducidos a lenguaje mquina
para ser ejecutados.


6

6
1.1.3. Ingeniera de Software

Tomando en cuenta los conceptos anteriores tenemos elementos para deducir una
definicin de la ingeniera de software y para ello podemos considerar que es un rea de
estudio que se constituye por una serie de mtodos y tcnicas para desarrollar software.
Sin embargo es preciso que se analicen algunas definiciones como las que presenta el
siguiente autor:

La ingeniera del software es el establecimiento y uso de principios robustos de la
ingeniera a fin de obtener econmicamente software que sea fiable y que funcione
eficientemente sobre mquinas reales. (Pressman, R. 2010, pg. 17).

Ingeniera del software: La aplicacin de un enfoque sistemtico, disciplinado y
cuantificable hacia el desarrollo, operacin y mantenimiento del software; es decir, la
aplicacin de ingeniera al software. (Pressman, R. 2010, pg. 17).

Como puedes observar en la primera definicin habla sobre los principios robustos, lo cual
hace referencia a procesos mejorados y confiables. Respecto al aspecto econmico
sugiere que por la aplicacin de la ingeniera de software, se lograr establecer un
proceso donde se puedan estimar mejor los costos y obtener beneficios econmicos, que
sean redituables para quin produce el software y ms accesible para quin lo compra.

En la definicintambinse menciona el producto que es el software, ste simplemente
debe poder ser utilizadoy la informacin que genere deber ser fiable, eso encierra un
gran sentido de calidad en el proceso de construccin de software, la cuestin no es solo
construir en volumen, sino garantizar que el producto cubra los propsitos para los que
fue creado, es decir, los requerimientos que defini el cliente para su desarrollo.

La segunda definicin tambin tiene un enfoque claro hacia los procesos bien
establecidos y cuantificables, es decir medibles, esto para revisar como se desempean
los procesos y de esta manera, poder mejorar cuando los resultados no son los
esperados. Todo esto se contempla desde la creacin del software hasta su instalacin y
mantenimiento.

Sin embargo la ingeniera de software se confronta con su enemigo principal: el
desnimo por aplicar las practicas y modelos que sta propone es decir construir
software con apego a un proceso y el tiempo que se necesita para administrarlo son
factores que no todos los desarrolladores estn dispuestos a invertir en sus proyectos.
Otro factores que el tiempo nunca parece ser suficiente, esto lleva a los desarrolladores
de software a dedicarse por completo a la codificacin, haciendo a un lado procesos como
el anlisis y el diseo. Esto es equivalente a la construccin de un edificio, sin planos o
maquetas, entonces; El ingeniero se arriesga a construir algo que no ha planeado ni

7

7
definido previamente? La respuesta es clara: no se arriesga, tiene que planear, analizar y
disear antes de construir algo. En la ingeniera de software es muy similar, antes de
construir el software se debe planear, analizar y disear lo que se va a construir, de
lo contrario se toma un gran riesgo de no construir el producto esperado en tiempo y
forma.La ingeniera de software contempla todo el proceso de desarrollo de sistemas de
informacin, software de aplicacin o de sistemas. En el siguiente tema podrs descubrir
en qu consiste dicho proceso.

1.2. El proceso de desarrollo

El proceso de desarrollo de software consta de una serie de actividades necesarias para
construir un producto de software. Existen diferentes modelos que proponen su propio
estilo de proceso de desarrollo, pero todos comparten por lo menos las siguientes etapas:

1. Especificacin: se definen los requerimientos y restricciones de operacin.
2. Diseo e implementacin: actividades necesarias para construir el software
abarcando los requerimientos de la especificacin.
3. Validacin: revisin con el cliente para su aprobacin.
4. Evolucin: capacidad de adaptacin a cambios y actualizaciones del
software.(Sommerville, Ian 2011 pg. 28).

No existe un modelo de construccin de software ideal, algunas empresas incluso han
diseado su propio proceso de desarrollo partiendo de la idea de alguno ya existente y
haciendo las mejoras que se adapten a su realidad.

A continuacin en los temas siguientes analizaremos algunos modelos de proceso de
desarrollo de software de manera general resaltando las etapas, as como sus ventajas y
desventajas.

1.2.1. Mtodos de desarrollo: alternativas

Para la construccin de cualquier tipo de producto de software se desarrollan una serie de
actividades partiendo desde la visin del proyecto que el cliente tiene, hasta el producto
final. Un modelo de desarrollo establece el orden en que se ejecutarn esas actividades
en forma de procesos. Cada proyecto es nico y no existe un modelo que pueda
aplicarse cien por ciento a todos los proyectos. Por lo cual existen varias alternativas de
modelos de desarrollo para ser utilizadas dependiendo de cada tipo de proyecto. Pero los
modelos solamente se describen como marcos del proceso, esto significa que no se
detallan las actividades, estas dependen de la seleccin de mejores prcticas de
desarrollo que cada organizacin utilice para cada etapa del proceso.A parte de las
actividades, las descripciones de los procesos deben contener:

8

8

Productos: son el resultado de ejecutar cada proceso, por ejemplo: un producto del
proceso del anlisis pueden ser las descripciones y diagramas del modelado de
requerimientos.
Roles: representan la responsabilidad que las personas tienen con el proyecto.
Estos roles pueden ser lder o administrador del proyecto, analistas, diseadores,
programadores, encargados de pruebas, de calidad, etc.

Condiciones: declaraciones vlidas que restringen de alguna manera las
actividades que tengan relacin con el proceso o con el producto. Por ejemplo una
precondicin puede ser que el cliente haya aprobado todos los requerimientos.
(Pressman, R. 2010. Pg. 28)

A continuacin se explican diferentes modelos y sus caractersticas.

Modelo en cascada

Es el modelo ms antiguo de desarrollo de software y ha servido como base para la
generacin de otros modelos de ciclo de vida. Propone la construccin de software a
travs de una secuencia simple de fases. Cada fase contiene una serie de actividades
para lograr un objetivo. Cada fase depende de la meta lograda en la anterior y por ello se
representa con una flecha hacia abajo. Las flechas de regreso representan
retroalimentacin.

Figura 1 Diagrama del Ciclo de vida cascada
(Pressman, R. 2010, pg. 30).

Etapas del modelo cascada:
Anlisis.- Analista y cliente definen todos los requerimientos del sistema y su
especificacin detallada.
Diseo.-A partir del anlisis se disean las estructuras de datos, bases de datos,
interfaces y procedimientos para dar solucin a los requerimientos del cliente.

9

9
Codificacin.- El diseo se traduce a cdigo para la generacin del software.
Pruebas.- Se hace la revisin del cdigo para comprobar que no tenga errores y
realice lo esperado de acuerdo al diseo y al detalle del requerimiento.
Mantenimiento.- Esta etapa se realiza despus de la entrega del software y sirve
para asegurar que el sistema siga funcionando y se da seguimiento a las mejoras
que el cliente solicite.

Ventajas del modelo cascada:
Es ms sencillo planear las actividades del ciclo completo.
La calidad del producto es alta.
Permite trabajar con personal inexperto.
Es el modelo ms conocido.
Es fcil de aprender.

Desventajas del modelo cascada:

Los proyectos reales no siempre siguen el orden que propone este modelo, los
cambios pueden causar confusin al equipo del proyecto por la poca interaccin
que propone el modelo.
Es difcil que el cliente (quin solicit la construccin del proyecto) exponga todos
los requerimientos y en este modelo se requiere que desde el comienzo del
proyecto sean definidos.
El cliente deber ser paciente, ya que ver alguna versin del trabajo hasta que el
proyecto est muy avanzado y cualquier error que detecte ser cada vez ms
difcil y costoso corregirlo.
Este tipo de modelo genera estados de bloqueo, cuando una etapa sufre algn
retraso, algunos miembros del equipo debern esperar a otros para completar su
actividad.

Modelo de construccin de prototipos

Este modelo fue creado como una herramienta para identificar los requerimientos del
software. Facilita al equipo de desarrollo entender los requerimientos del cliente y tambin
ayuda al cliente a detallarms claramente las necesidades que tiene respecto a la
construccin del software.

Existen varias formas de hacer un prototipo, esto depende de la naturaleza del proyecto,
algunas de ellas son:
1. Un borrador de historia, tal y como lo escuchamos del cliente, se plantea a manera
de historieta las funcionalidades del sistema, por ejemplo una interfaz con las
opciones del men, el rea de despliegue de resultados, si es necesario la imagen

10

10
corporativa. Apoyndose de la descripcin de la historia podemos representar la
interactividad del sistema con los usuarios. Para construir este tipo de modelo
puede ser utilizando un block de notas de papel o herramientas de software que
faciliten la construccin de interaccin hombre-mquina y permitan simular el
proceso que se solicita. De esta manera el cliente puede hacerse a la idea de
cmo va a funcionar el sistema final sin tener que construirlo, y as discutirlo con el
analista.
2. Un modelo que implementa alguna funcin importante del sistema. Por ejemplo se
puede construir una aplicacin rpida sin aspectos de diseo ni con la base de
datos completa, lo mnimo requerido para simular un proceso interno del sistema o
la validacin de alguna frmula. De esta manera se obtiene el entendimiento del
requerimiento por parte del equipo de desarrollo.

Estos prototipos pueden servir como documentacin de apoyo para especificar bien los
requerimientos, sin embargo no se recomienda que se utilicen como primera versin del
sistema, pues seguramente se han construido de una manera rpida y con pocos detalles
de calidad y no representa el sistema real que el cliente necesita.

Figura 2 Diagrama del modelo de construccin de prototipos
(Pressman, R. 2010. Pg. 24)

Como podrs observar en la figura el modelo de construccin de prototipos tiene una
serie de etapas que se describen a continuacin.

11

11

La flecha que indica el comienzo seala la recoleccin de requisitos, as que presta
atencin a las siguientes descripciones:
1. Recoleccin de requisitos.- Analista y cliente definen la especificacin de
requerimientos.
2. Diseo rpido.- Se hace el diseo del prototipo.
3. Construccin del prototipo.- En cualquiera de las herramientas seleccionadas.
4. Evaluacin del prototipo.-Cliente y usuario revisan el prototipo y generan
observaciones.
5. Refinamiento del prototipo.-Las observaciones del cliente y usuarios sirven para
mejorar el prototipo que nuevamente es construido y regresa al paso 2.
6. El ciclo concluye cuando el cliente y el usuario no tienen ms observaciones y
adems el prototipo es claro para el analista y el equipo de desarrollo.

Ventajas del modelo de construccin de prototipos:
No modifica el flujo del ciclo de vida.
Reduce el riesgo de construir productos que no satisfagan las necesidades de los
usuarios.
Reduce costos y aumenta la probabilidad de xito.
Exige disponer de las herramientas adecuadas.

Desventajas del modelode construccin de prototipos:
El cliente puede confundir las primeras versiones del prototipo con el producto
final.
El cliente puede desilusionarse al saber que los prototipos no son el producto y
que este an no se ha construido.
Se requiere compromiso y trabajo del cliente para estar revisando los prototipos.
No se sabe exactamente cunto ser el tiempo de desarrollo, ni cuantos prototipos
se tienen que desarrollar.
Si un prototipo fracasa, el costo del proyecto puede resultar muy caro.
El desarrollador puede caer en la tentacin de utilizar un prototipo, por ejemplo la
interfaz grfica de un mdulo y continuarlo para construir el sistema sin tomar en
cuenta aspectos de calidad necesarios para el proyecto.

Modelo incremental
El modelo incremental combina elementos del modelo cascada (aplicados repetidamente)
con la filosofa interactiva de construccin de prototipos. Cada secuencia cascada
produce un incremento. Cuando se utiliza este modelo, el primer incremento a menudo
es un producto esencial (ncleo). Es decir, se afrontan requisitos bsicos, para muchas
funciones suplementarias (algunas conocidas, otras no) que quedan sin extraer. El cliente
utiliza el producto central (o sufre la revisin detallada). Como resultado de utilizacin y/o
de evaluacin, se desarrolla un plan para el incremento siguiente. El plan afronta la

12

12
modificacin del producto central a fin de cumplir mejor las necesidades del cliente y la
entrega de funciones, y caractersticas adicionales. Este proceso se repite siguiendo la
entrega de cada incremento, hasta que se elabore el productivo completo.(Pressman, R.
2010, pg. 26).

Figura 3 Diagrama del modelo incremental.
(Pressman, R. 2010 pg. 27)

Ventajas del modelo incremental:
Construir un sistema pequeo es menos riesgoso que construir un sistema grande.
Si un error es detectado, slo la ltima iteracin necesita ser descartada.
Al desarrollar parte de las funcionalidades, es ms fcil determinar si los
requerimientos planeados para los niveles subsiguientes son correctos.

Desventajas del modelo incremental:
Se puede suponer que los requerimientos han sido definidos desde el inicio del
proyecto.
Se necesita experiencia para definir los incrementos de forma de distribuir las
tareas de manera proporcional.
Se corre el riesgo de que el desarrollo se prolongue demasiado en cuestiones de
tiempo.


13

13
Modelo vida espiral

El modelo en espiral es un modelo de proceso de software evolutivo que acompaa la
naturaleza interactiva de construccin de prototipos con los aspectos controlados y
sistemticos del modelo cascada. Se proporciona el potencial para el desarrollo rpido de
versiones incrementales del software. Durante las primeras iteraciones, la versin
incremental podra ser un modelo en papel o un prototipo. Durante las ltimas iteraciones,
se producen versiones cada vez ms completas de ingeniera del sistema. (Pressman, R.
2010, pg. 28).

Se incorpora un nuevo elemento en el proceso de desarrollo del software como lo es el
anlisis de riesgos y define entre 3 y 6 regiones de tareas. Por ejemplo las que se
muestran en la figura son:

Regiones del modelo espiral:
1. Comunicacin con el cliente.- Cliente y analista establecen las polticas de
comunicacin.
2. Planificacin.- Determinan tiempos, objetivos, restricciones, etc. del proyecto.
3. Anlisis de riesgos.- Identificacin y gestin del riesgo.
4. Ingeniera.- Desarrollo y verificacin del producto del siguiente nivel.
5. Construccin y adaptacin.-Actividades para desarrollar, realizar pruebas,
instalacin y mantenimiento al software.
6. Evaluacin del cliente.- Validacin del cliente hasta su aprobacin y liberacin.

Figura 4 Diagrama del ciclo de vida espiral
(Pressman, R. 2010 pg. 28).

Ventajas del Ciclo de vida espiral:
No se requiere tener todos los requerimientos definidos desde el inicio del
proyecto.

14

14
Es evolutivo, lo cual permite al cliente ir definiendo mejor sus requerimientos y
tambin junto con el equipo ir gestionando los riesgos.
Se pueden construir prototipos para disminuir el riesgo del proyecto, cuando no se
cuenta con requerimientos claros.
Representa de mejor manera un proceso de desarrollo real, con respecto al
modelo cascada.
Los requerimientos se van validando con cada iteracin.

Desventajas del Ciclo de vida espiral

Genera la apariencia de ser interminable.
Es muy complejo.
Se requiere el trabajo y participacin del cliente de manera contina.
El modelo es relativamente nuevo por lo que no se cuenta con los casos
suficientes para demostrar su efectividad.

1.2.2. El proceso unificado de desarrollo

El Proceso Unificado Racional (RUP, por las siglas de RationalUnifedProcess) Es un
ejemplo de un modelo de proceso que se deriv del trabajo sobre UML y el proceso
asociado de desarrollo de software unificado. Conjunta elementos de todos los modelos
de proceso genricos. RUP se describe desde tres perspectivas: (Sommerville, Ian 2011).
1. Dinmica.- Muestra las fases del modelo a travs del tiempo.
2. Esttica.- Presenta actividades del proceso que se establecen.
3. Prctica.- Sugiere buenas prcticas a usar durante el proceso.

RUP es un modelo en fases que identifica 4 fases discretas en el proceso de software:
1. Inicio.- Define el alcance y objetivos del proyecto.
2. Elaboracin.- Plan del proyecto, especificacin de caractersticas y arquitectura
base.
3. Construccin.- Construye y opera el producto.
4. Transicin.- Transicin del producto a la comunidad del usuario.


15

15

Figura 5 Diagrama del proceso unificado de desarrollo.
(Mornacco, D. 2006, pg. 1).

Ventajas del Proceso Unificado Racional
Identificacin y gestin del riesgo en etapas tempranas del proyecto.
El conocimiento adquirido en una iteracin puede aplicarse de iteracin a iteracin.
Involucramiento de los usuarios contino.

Desventajas del Proceso Unificado Racional
Por el grado de complejidad puede no resultar muy adecuado.
El RUP es generalmente mal aplicado en el estilo cascada.
Requiere conocimientos del proceso y de UML.
El RUP no es un proceso adecuado para todos los tipos de desarrollo, por
ejemplo, para el desarrollo de software embebido.

Independientemente del proceso de desarrollo que se seleccione, ste debe adaptarse
para utilizarse por el equipo de desarrollo del proyecto de software. Si el proceso es dbil,
tendr efecto sobre el producto final (el software). Adems todos los procesos debern
incluir actividades para gestionar el cambio, ya sea que implique la generacin de
prototipos para hacer ms claros los cambios o bien que los procesos se estructuren para
desarrollo y entrega de interactivos y de esta forma los cambios no afecten al sistema
como un todo.

Existen otras metodologas que proponen procesos ms rpidos de construccin de
software para atender proyectos donde se requiere hacer un uso inmediato del mismo. En
el siguiente tema se vern algunos procesos giles de desarrollo.


16

16
1.2.3. Mtodos giles

Debido a que muchas empresas operan en ambientes econmicos internacionalesy
cambiantes, deben responder rpidamente a las nuevas oportunidades, a mercados, a
situaciones econmicas, al surgimiento de productos y servicios competitivos. El software
forma una parte importante en casi todas las operaciones empresariales por lo cual, los
procesos de desarrollo debern tambin construir software de una manera ms rpida
para que ste pueda seguir estando disponible como una herramienta confiable y
actualizada a las nuevas demandas organizacionales.

El software es un elemento clave en casi todos los procesos y operaciones industriales,
por ello se requiere que ste sea desarrollado de una manera rpida y efectiva para
aprovechar las oportunidades y permanecer dentro del mercado.(Sommerville, Ian 2011).

Los procesos de desarrollo de software que se han visto hasta el tema anterior no estn
orientados al desarrollo rpido del software. A medida que los requerimientos cambian, o
se descubren errores, el diseo tiene que reelaborarse y probarse de nuevo. Provocando
que el proceso se prolongue entregando el producto al cliente despus de lo que se
planeo originalmente.Adems, estos procesos involucran un importante tiempo de gestin
para no perder el control en el tiempo que lleva construir un software. Estas son algunas
de las razones por las cuales han surgido nuevos modelos giles de desarrollo de
software.

Los procesos de desarrollo gil se desarrollan para generar software til de forma rpida.
Esto de manera incremental aumentando funcionalidades al sistema. En este tema
veremos dos opciones de metodologas giles, que a continuacin se explicaran:

Programacin Extrema XP

La programacin extrema (XP) es uno de los mtodos giles ms conocidos y utilizados.
El trmino se gener por haber llevado los mtodos tradicionales a niveles extremos
como lo es el desarrollo iterativo.

Los involucrados en estos proyectos principalmente es el cliente que toma diferentes roles
y puede ser una o varias personas; es quien contrata al equipo de desarrollo, ser el
usuario del software y ser quin apruebe y libere el proyecto. El equipo de desarrollo
que generalmente est conformado por programadores que son los encargados de
realizar el anlisis, el plan y el desarrollo del sistema hasta liberarlo completamente.


17

17
En el XP muchas versiones de un sistema pueden desarrollarse por distintos
programadores, integrarse y ponerse a prueba en un solo da. Adems los requerimientos
se expresan como escenarios del usuario que posteriormente son traducidos a tareas.
Los programadores trabajan en pares y antes de escribir el cdigo desarrollan pruebas
para cada tarea.(Sommerville, Ian 2011, pg. 65).

El proceso de liberacin de la programacin extrema consiste en los siguientes pasos:

1. El usuario describe la historia del proceso que quiere automatizar, con sus
propias palabras.
2. El equipo traduce la historia en tareas para construir las funciones del sistema.
3. El equipo y el usuario eligen cul historia y actividades se pueden traducir ms
rpidamente en una funcin del sistema y planean liberarla en 2 semanas
aproximadamente.
4. El equipo se encarga de codificar, integrar y probar la funcionalidad que se ha
planeado liberar.
5. Liberacin del software, al principio con la primera entrega la funcionalidad es
mnima, pero como las liberaciones son frecuentes se va agregando ms
funciones al sistema.
6. Se evala el sistema con el cliente de la iteracin comprobando que la
funcionalidad realmente opere de acuerdo a las especificaciones de la historia
del usuario. (Sommerville, Ian 2011, pg. 65).

Para poder llevar a cabo los pasos anteriores ser necesario tomar en cuenta los
siguientes puntos:

Realizar una planeacin incremental basada en las tarjetas de historia, stas se deben
ordenar de acuerdo a la prioridad que se les haya asignado, se obtienen las tareas
necesarias para su desarrollo y se les asigna un tiempo. Es incremental porque cada
avance ser un incremento en las funciones del sistema.

Cada liberacinser pequea, pero deben ser frecuentes de tal manera que se vayan
integrando al sistema hasta terminarlo.

No se cuenta con mucho tiempo para diseos detallados, por lo cual ste debe ser
rpido cubriendo nicamente los requerimientos planeados en cada entrega (iteracin).

Las primeras pruebas son realizadas desde antes que se escriba el cdigo y durante su
desarrollo de tal manera que al terminar el cdigo ya est tambin probado.


18

18
De manera rpida el equipo de programacin realiza una refactorizacin que consiste en
remover el cdigo duplicado, revisin de nombre de atributos y mtodos, substitucin de
cdigo, etc. Con la finalidad de mejorar el cdigo.

Los programadores trabajan en pares para apoyarse en el anlisis, diseo, desarrollo y
prueba del software.

Todos los programadores del equipo se responsabilizan por todo el cdigo y todos lo
conocen, de tal manera que cualquiera de ellos puede realizar cambios cuando sea
necesario

El cdigo que se genera en cada iteracin se integra inmediatamente al sistema y se
realizan inmediatamente las pruebas de integracin.

No es recomendable que se presione al equipo desarrollando de forma exhaustiva en
horas extras, ya que esto baja el estndar de calidad del cdigo y la productividad se
reduce.

Como parte del equipo de desarrollo debe integrarse a un representante del cliente
(usuario) para proveer los requerimientos del sistema, o sea las historias que
representarn las funcionalidades del sistema y tambin apoyara en la revisin de la
iteracin y su liberacin. (Sommerville, Ian 2011, pg. 66).

Metodologa Scrum

Scrum tiene como objetivo gestionar y controlar los procesos de creacin de software
utilizando un modelo gil iterativo e incremental aplicando mtodos como RUP y mtodos
giles como XP.

Scrum es un conjunto de reglas, procedimientos y prcticas relacionadas entre s,que
trabajan en conjunto para mejorar el entorno de desarrollo, reduce los gastos generales
de la organizacin y se asegura que coincidan las iteraciones con los entregables a
usuarios finales.

El proceso de desarrollo Scrum

Los proyectos se realizan en bloques cortos y fijos (iteraciones de 30 das o menos). Cada
iteracin debe generar un resultado completo. El proceso comienza con la lista de
objetivos y requerimientos del producto que pueden funcionar como el plan del proyecto.
En la lista de objetivos y requerimientos el cliente agrupa los requerimientos en distintas
iteraciones y entregas, tomando en cuenta el valor que aportan con respecto a su costo
(los prioriza).

19

19

El primer da se realiza la junta de planificacin de la iteracin y se realiza lo siguiente:

1. Seleccin de requerimientos. El cliente presenta la lista de requerimientos del
proyecto previamente priorizada. El equipo pregunta las dudas que hayan surgido
y selecciona los requerimientos prioritarios que se compromete a completar en la
iteracin.

2. Planificacin de la iteracin. El equipo desarrolla una lista de actividades de la
iteracin para desarrollar los requerimientos a los que se ha comprometido, se
asignan responsables para cada actividad y la estimacin del tiempo se realiza
tomando la opinin de cada integrante.

3. Ejecucin de la iteracin. Diariamente el equipo realiza una reunin 15 minutos,
para revisar el trabajo que han realizado y se hacen adaptaciones necesarias que
permitan cumplir con el compromiso adquirido. Cada integrante del equipo debe
contestar las siguientes preguntas:

Qu han realizado los miembros del equipo desde la ltima reunin?
Hay algn problema? Hay obstculos para concluir las tareas?
Qu va a hacer cada miembro del equipo antes de la prxima reunin?

En cada iteracin debe existir un facilitadorque es quien se encarga de que el equipo
pueda realizar su trabajo eliminando los obstculos y evitando interrupciones externas
que puedan afectar el desempeo de los miembros del equipo.

Inspeccin y adaptacin.Cuando termina la iteracin se realiza una junta de revisin que
consta de:

1. Demostracin: el equipo presenta al cliente los requerimientos que se
desarrollaron en la iteracin, lo cual representa el incremento de producto y debe
estar preparado para integrarse sin el mnimo esfuerzo.
2. Retrospectiva: el equipo analiza sus lecciones aprendidas en este proyecto.

Este proceso se representa en el siguiente grfico.

20

20

SCRUM
(Hunt, J. 2006. Pg. 26)

El mtodo Scrum tiene los siguientes beneficios:

La gestin y control se desarrolla de manera gil.
Se reconoce explcitamente que los requerimientos pueden cambiar rpidamente
en su enfoque iterativo e incremental de desarrollo del producto.
Es posible utilizar todava prcticas de ingeniera existentes dentro de SCRUM
para facilitar la introduccin a los mtodos giles en una organizacin.
Es un enfoque basado en el equipo y ayuda a mejorar las comunicaciones y
cooperacin.
til para proyectos pequeosy grandes.
Ayuda a identificar y luego eliminar cualquier obstculo para el buen desarrollo del
producto final.

Muchas organizaciones han utilizado con xito Scrum en miles de proyectos para
gestionar y controlar el trabajo, al parecer con importantes mejoras en la
productividad.Una observacin interesante relacionada con Scrum es que puede ser visto

21

21
como un proceso que ayuda a concluir que existen las prcticas de ingeniera dentro de
un proceso iterativo controlado. De este modo, proporciona los valores, procedimientos y
reglas que pueden ayudar a introducir un proceso de desarrollo ms dinmico y flexible.
(Hunt, J. 2006. Pg. 25)

Actividad 2. Mtodos de desarrollo de software

En esta actividad afirmaras tus conocimientos adquiridos durante esta unidad,
practicando y comparando cada trmino utilizado en el tema de mtodos.

Propsito: Identificar las principales caractersticas y similitudes entre los modelos de
desarrollo de software proporcionados durante la unidad.

Instrucciones:

1. De manera individual Analiza los diferentes mtodos de desarrollo de software vistos
en esta unidad y compara sus caractersticas.
2. Realiza una tabla donde puedas indicar las caractersticas comunes que tienen los
modelos de desarrollo de software. Utiliza la primera columna para las caractersticas
similares de los mtodos y el resto de las columnas para las caractersticas principales
de cada mtodo de desarrollo.
3. Posteriormente establece una seccin para las conclusiones, en el cual realizarasuna
explicacin respecto a la tabla de comparacin, respondiendo a la siguiente pregunta:
Qu es lo que pudiste observar mediante la tabla respecto a las caractersticas de
los modelos? La extensin para las conclusiones debe ser un prrafo de 15 a 20
lneas.
4. Guarda la actividad con el nombre IIS_U1_A2_XXYZ. Sustituye las XX por las dos
primeras letras del primer nombre, la Y por la inicial del apellido paterno y la Z por la
inicial del apellido materno.
5. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.

Autoevaluacin

Para reforzar los conocimientos relacionados con los temas que se abordaron en esta
primera unidad del curso, es necesario que resuelvas las actividades ya que te ayudaran
A continuacin te presentamos la actividad de Mtodos de desarrollo de
Software, que a diferencia de otros cuatrimestres, a partir de ste podrs
consultar los criterios de evaluacin de cada una de las actividades.


22

22
a completar los logrosplaneados. Recuerda que es muy importante leer cuidadosamente
los planteamientos indicados y elegir la opcin adecuada para cada uno.

Evidencia de aprendizaje: metodologa de desarrollo

Ahora que ya tienes claro las caractersticas y similitudes que existen entre los mtodos
de desarrollo de software, podrs analizar casos que sean resueltos por el mtodo que
mejor se adapte, por ello te invitamos a realizar las siguientes instrucciones.

Propsito: Seleccionar el mtodo adecuado que se solucione el caso de estudio
mediante el anlisis de ste.

Instrucciones:

1. De manera individual Analiza el caso de estudio que te proporcione tu facilitador (a) y
selecciona el mtodo de desarrollo que mejor se adapte; toma en cuenta las
caractersticas del equipo de trabajo y los datos del proyecto.
2. Elabora un reporte detallando el anlisis del punto 1de la seleccin del mtodo para el
caso de estudio y responde las siguientes preguntas:
Qu mtodo de desarrollo elegiras?
Explica Por qu? Utiliza las caractersticas del mtodo seleccionado.
comparndolas con las caractersticas que se mencionan en el caso.
3. Guarda la actividad con el nombre IIS_U1_A3_XXYZ. Sustituye las XX por las dos
primeras letras del primer nombre, la Y por la inicial del apellido paterno y la Z por la
inicial del apellido materno.
5. Consulta la escala de evaluacin para conocer los parmetros de la actividad.

Autorreflexiones

Adems de enviar tu trabajo de la Evidencia de aprendizaje, es importante que ingreses
al foro Preguntas de Autorreflexin y consultes las preguntas que tu Facilitador(a)
presente, a partir de ellas, debes elaborar tu Autorreflexin en un archivo de texto
llamado XXX_UX_ATR_XXYZ. Posteriormente enva tu archivo mediante la herramienta
Autorreflexiones.


23

23
Cierre de la unidad

Durante esta primera unidad del curso, revisaste los conceptos de la ingeniera de
software y algunos de los diferentes mtodos del proceso de desarrollo del software que
existen, esto te ayudar a identificar proyectos por sus caractersticas y en base a stas
seleccionar la forma en que convendra desarrollarlos.

Es recomendable investigar en internet otras metodologas que no se cubren en esta
unidad, para que puedas tener un criterio ms amplio al identificar un repertorio mayor de
opciones de desarrollo.

Es importante que resuelvas los casos de estudio ya que de esta manera te forzars a
realizar un anlisis de la informacin contenida en esta unidad.

Para saber ms

Si deseas saber ms acerca de metodologas giles consulta la siguiente direccin
electrnica:

(B. Boehm, IEEE Computer, enero 2002)
http://www.computer.org/portal/web/csdl/doi/10.1109/2.976920

Obtendrs una crtica ms detallada de los mtodos giles, que examina sus fortalezas y
debilidades; est escrito por un ingeniero de software con vastaexperiencia.

Fuentes de consulta
Bibliografa
Pressman, R. (2010) Ingeniera de software. Espaa: Mcgraw-HillInteramerican.

Sommerville, Ian (2011) Ingeniera de software. Mxico:Pearson Educacin.

Hunt, J. (2006) Agile software construction. United States: Springer.
Bibliografa complementaria
Larousse Editorial SL. (2011). Diccionario Larousse de la lengua espaola.
Consultado en http://www.diccionarios.com


24

24
Real Academia Espaola. (2001). Diccionario de la lengua espaola (22.aed.).
Consultado en http://www.rae.es/rae.html

Mornacco, D. (2006). Epidataconsulting. Argentina. Consultado
enhttp://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId=57

Snchez, S (2007). Intro ingeniera de
software.http://cflores334.blogspot.es/tags/MODELO/
Introduccin a la ingeniera de software
Unidad 2. Anlisis y modelado de requerimientos

1


5 cuatrimestre


Clave:
150920520/ 160920518

Unidad 2.
Ingeniera de Software



2

ndice
UNIDAD 2. ANLISIS Y MODELADO DE REQUERIMIENTOS ........................................ 3
PRESENTACIN DE LA UNIDAD ..................................................................................... 3
Propsito ........................................................................................................................................ 3
2.1. Obtencin y especificacin de requerimientos................................................................. 4
2.1.1. Requerimientos funcionales y no funcionales .............................................................. 6
2.1.2. Tcnicas de recoleccin, identificacin y priorizacin de requerimientos ................ 9
2.1.3. Documento de requerimientos ...................................................................................... 13
Actividad 1. Tipos de tcnicas de recoleccin ....................................................................... 15
Actividad 2. Tcnicas de recoleccin ...................................................................................... 16
2.1.4. Validacin de requerimientos ........................................................................................ 16
2.1.5. Casos de uso ................................................................................................................... 17
Actividad 3. Requerimientos ..................................................................................................... 20
2.2. Aplicacin de modelo del dominio y de la interaccin .................................................. 21
2.2.1. Diagramas de clases ...................................................................................................... 22
2.2.2. Diagramas de secuencia ................................................................................................ 25
2.2.3. Diagramas de colaboracin ........................................................................................... 27
2.2.1. Diagramas de estado ...................................................................................................... 28
Autoevaluacin ........................................................................................................................... 29
Evidencia de aprendizaje. Diagramas del dominio e interaccin ...................................... 30
Para saber ms ........................................................................................................................... 31


3



En la unidad anterior comprendiste los diferentes tipos de procesos de desarrollo de
software, por ejemplo: el de cascada, el incremental, el espiral, etc. cada uno con sus
propias etapas; sin embargo, todos tienen en comn una etapa destinada para el anlisis
del proyecto. Como parte de esta etapa se requiere de una serie de actividades que tiene
que desempear el analista de un proyecto para poder identificar cules sern las
funciones que el software deber realizar. Estas actividades las veremos mas adelante.

El objetivo de esta unidad es aprender los tipos de requerimientos de software que
existen, los mtodos de recoleccin para identificarlos, documentarlos y por ltimo la
manera de representarlos utilizando estndares de modelado como lo es UML, Lenguaje
Unificado de Modelado (por sus siglas en ingls Unified Modeling Language).

Los requerimientos son las necesidades o especificaciones que tiene el cliente con
respecto a un producto. Para fines de esta asignatura, entendemos que ese producto es
el software. En esta unidad, es importante que se logre la comprensin de cmo obtener
una adecuada descripcin de las necesidades que el cliente pretende cubrir con las
funciones del software, para poder transformarlas en requerimientos claros y bien
definidos para el equipo de trabajo y para el mismo cliente. Los conjuntos de
requerimientos sern desarrollados y gestionados a travs de las etapas del proceso de
desarrollo y poco a poco sern transformados en un software que reunir todas esas
caractersticas solicitadas. A continuacin se mostrara un ejemplo para mejor
comprensin:

Cuando un cliente solicita que se le desarrolle un software para llevar el control de las
existencias de su almacn de materia prima, ya que la empresa ha crecido y por lo tanto
el almacn cada vez tiene una mayor cantidad de materiales, lo cual provoca que la
actual forma de trabajo que es realizada con hojas de clculo, resulta cada vez ms difcil
de actualizar y mantener. Por lo cual ha decidido que un software construido para este fin
podra ser una solucin a esta necesidad.

El ejemplo previo representa las necesidades que se deben detectar y traducir en
requerimientos y posteriormente representarlos en un lenguaje de modelado para que
sean entendibles para el equipo de desarrollo de software.

Propsito


4

Al estudiar esta unidad identificars:

1. Tipos de tcnicas de recoleccin.
2. Requerimientos de un caso de estudio.
3. Diagramas del dominio y de interaccin.


Analizar los diagramas del dominio e interaccin, para la representacin grfica de los
requerimientos de un caso de estudio, tomando en cuenta los estndares del Lenguaje
Unificado de Modelado (UML).

2.1. Obtencin y especificacin de requerimientos

Muchos proyectos de desarrollo de software no llegan a terminar en tiempo y forma de
acuerdo a lo planeado, esto es debido a que los requerimientos no se obtuvieron ni se
especificaron completamente, o no fueron muy precisos, el caso es que durante la
construccin del software se van identificando inconsistencias, por ejemplo: puede haber
duplicidad de requerimientos por un mal manejo de nombres que se han registrado varias
veces, pero en esencia es el mismo; otro ejemplo sera la inconsistencia en revisiones de
lo que se requiere; es decir, a veces con una revisin puede parecer entendible pero en el
momento de tratar de traducirla para generar algo, no es posible por falta de datos o
porque simplemente no se comprende.

Ahora bien, en la obtencin de requerimientos, tenemos que las tareas del cliente y del
analista sern llegar a la definicin adecuada de requerimientos procurando que las
necesidades del cliente con respecto al software se cumplan y se puedan describir en
trminos entendibles para el equipo de desarrollo (lder, analista, diseadores,
programadores, encargados de pruebas). Por ello la funcin del analista o ingeniero de
requerimientos es ser un interrogador consultor, que ser de ayuda al cliente para
determinar la completa definicin de requerimientos.

Entonces decimos que los requerimientos son la base del desarrollo de software, ya que,
nos servirn para entender qu es lo que se va a producir y estos debern describirse de
manera clara, concreta, completa y sin ambigedades (evitar que sean confusos, mal
escritos, redundantes). Debemos tener presente que los lectores de los requerimientos
sern personas que posiblemente no conocen aspectos tcnicos; por ejemplo el cliente,
usuarios, contratistas y, por otra parte, personal altamente especializado como
diseadores, programadores, arquitectos de software, encargados de pruebas y de
implantacin, el lder, y el mismo analista. Para describirlos, podemos comenzar a
clasificarlos como requerimientos del usuario y requerimientos del sistema, tal como se
muestra a continuacin:


5

Diagrama de clasificacin de requerimientos.

En este diagrama se visualiza la primera clasificacin que observa y comprende lo que el
autor Ian Sommerville (2011. Pg. 83) define: Los requerimientos del usuario son
enunciados, en un lenguaje natural junto con diagramas, acerca de qu servicios esperan
los usuarios del sistema, y de las restricciones con las cuales ste debe operar. Un
ejemplo de esto puede ser el siguiente:

Requerimiento del usuario.

El usuario puede realizar la consulta de las existencias del almacn de materia prima de
manera remota va Internet.

En seguida se definen los principales requerimientos del usuario:

Casos de uso: representaciones grficas de las funciones de un software. Sus elementos
son el caso de uso o funcin del software, actor que es representado por una figura de un
monigote y los arcos que son lneas que relacionan al actor y los casos de uso.

Escenarios: son descripciones del usuario de lo que se espera que el software realice.
Estas descripciones se realizan como una historieta y son consideradas como
requerimientos. Generalmente se utilizan en modelos de desarrollo giles.

Prototipos: representaciones tipo borrador de la construccin del software, generalmente
se utiliza para mostrar interfaces y su navegacin.

La segunda clasificacin son los requerimientos del sistema. Observa la siguiente
definicin de Sommerville (2011. Pg. 83): Los requerimientos del sistema son
descripciones ms detalladas de las funciones, los servicios y las restricciones
operacionales del sistema de software.

Requerimientos
Usuario Sistema

6

Ejemplo de requerimiento del sistema.

Todos los viernes el software generar el reporte denominado Explosin de materiales
que consiste en mostrar la materia prima que se necesitar para la produccin de la
siguiente semana. El cual deber indicar de color rojo los materiales que debern
comprarse y las cantidades para poder producir y mantener los niveles de stock
adecuados.

La manera de representar los requerimientos del sistema es el documento de
especificacin de requerimientos del software o SRS (Software Requierement
Specification), que contiene todos los requerimientos descritos con un alto nivel de detalle.
A veces forma parte del contrato entre el comprador del software y el equipo de
desarrollo.

De cualquier manera, an y con todo el cuidado que se haya tenido al detectar los
requerimientos, stos podrn presentar cambios durante el desarrollo del software. Sin
embargo, un adecuado control mantendr el proyecto dentro del margen de lo planeado
en tiempo, costo y recursos.

Los requerimientos del sistema del software se clasifican como funcionales y no
funcionales. Esta clasificacin nos servir para identificar de una mejor manera cules
requerimientos se refieren a las caractersticas para concebir el software como un todo y
cuales funciones el sistema debe realizar de manera especfica. En el siguiente tema
encontrars una explicacin ms amplia de este tipo de requerimientos.

2.1.1. Requerimientos funcionales y no funcionales

Como se ha mencionado en el tema anterior, la redaccin de requerimientos puede ser
poco exacta, lo cual puede generar problemas en su interpretacin, ocasionando que no
se logre el entendimiento del software. Es por ello que tenemos otra manera de clasificar
los requerimientos, sta es una sub clasificacin de los requerimientos del sistema que los
divide en funcionales y no funcionales:

Requerimientos
Usuario Sistema
No funcionales Funcionales

7

Diagrama de clasificacin de requerimientos y de requerimientos del sistema.

Para entender de forma clara, observa la siguiente definicin que Sommerville (2011, pag.
84) da sobre los requerimientos funcionales. Son enunciados acerca de servicios que el
sistema debe proveer, de cmo debera reaccionar el sistema a entradas particulares y de
cmo debera comportarse el sistema en situaciones especficas. En algunos casos, los
requerimientos funcionales tambin explican lo que no debe hacer el sistema.

Un ejemplo de requerimiento funcional sera:

El software debe enviar una alerta cuando los niveles de stock o reservas han
comenzado a utilizarse y debe sugerir generar la orden de compra.

Un requerimiento no funcional podra estar conformado por varios requerimientos
funcionales y stos generalmente son restricciones en presupuesto, polticas de la
empresa, imposiciones del gobierno, vnculos con algn otro sistema de informacin o
atributos de calidad del sistema. Estos requerimientos se refieren al software como una
sola entidad y no como un conjunto de elementos. Por ejemplo:

El software debe estar accesible para realizar las consultas en tiempo real va Internet
las 24 horas del da los 365 das del ao.

El software debe restringir el acceso a personas ajenas a la organizacin.

Es importante comentar que, al redactar la descripcin de cada requerimiento no
funcional, ste debe cuantificarse de alguna manera ya que, de lo contrario, dicha
descripcin quedar imprecisa provocando una mala interpretacin llena de subjetividad.
Algunas expresiones comunes son las que encontramos en la siguiente tabla que te
presentamos a continuacin con dos columnas; la primera se llama Descripcin
incorrecta la cual contiene palabras o frases que normalmente nos sentimos tentados a
utilizar en la descripcin de algn requerimiento no funcional, lo cual no debe ser as; la
segunda columna llamada Descripcin correcta ofrece ejemplos para quitar la
imprecisin del requerimiento, haciendo ste ms cuantificable, medible y por lo tanto
alcanzable.

Descripcin incorrecta Descripcin correcta
Que el software sea rpido (veloz,
en tiempo real, lento)
El tiempo de despliegue de las pginas estticas
ser dado en un rango de tiempo de <=5
segundos.

Otros elementos pueden ser transacciones,

8

tiempos de respuesta del usuario, eventos,
todo sobre la unidad de tiempo.

Ser un software pequeo
(grande, mediano)
Se espera que el archivo que se genere no
exceda los 10,000 KB para que pueda ser
descargado fcilmente por el usuario desde
internet.

Bits, Kb, B, KB, TB, GB, etc.
Que sea fcil de usar (sencillo,
amigable, lgico)
El software contar con un mdulo de ayuda de
cada uno de los procesos y ventanas.

Tambin se puede disminuir la ambigedad del
requerimiento indicando que el personal ser
capacitado por un cierto periodo de tiempo
estimado para que pueda aprender a utilizarlo.

La informacin que genere debe ser
fiable (veraz, oportuna)
El software deber realizar procesos de
eliminacin de registros incompletos cuando
estos no hayan sido completados cuando el
software se haya apagado por fallos elctricos.
Conservando de esta manera, solo los registros
completos.

Otras consideraciones son la probabilidad de que
el sistema no est disponible (Si se hacen
respaldos o migraciones a otro servidor).

Que el software sea robusto (
potente)
Cuando el software detecta algn error de
autentificacin, por ejemplo la prdida de
variables de sesin o cookies, lanzar una pgina
indicando al usuario que vuelva a introducir su
nmero y contrasea.

Otros casos podran ser: indicar si se requiere el
reinicio despus de una falla e incluso podra
indicar en qu porcentaje los datos estn
corruptos por un error o falla.

El software debe ser portable
(porttil, transportable, movible)
Se espera que el software pueda ser visible en
los navegadores iExplorer v. 9, Chrome v. 18,
Mozilla 6.


9

La idea es que describa exactamente en que
otros sistemas o equipos debe funcionar el
software.
Tabla para describir requerimientos no funcionales.

Observa el siguiente ejemplo que demuestra un requerimiento no funcional y que tambin
se encuentra mal definido:

El software debe ser fcil de usar para el personal del almacn.

Como pudiste ver es incorrecto ya que no es posible cuantificar o medir su cumplimiento,
ahora se presentara el mismo requerimiento no funcional descrito de forma correcta:

El personal del almacn tomar una capacitacin de 3 horas en el uso del software,
adems el software contar con videos explicando la funcionalidad del mismo como
apoyo extra.

Los requerimientos son la base del desarrollo de un sistema de software, es por ello que
se hace un especial nfasis en su obtencin, especificacin, clasificacin y buena
redaccin. Pero no siempre se cuenta con la informacin necesaria a la mano, para ello
habr que utilizar algunas tcnicas de recoleccin para identificar y priorizar los
requerimientos. Este tema se abordar en el siguiente punto.

2.1.2. Tcnicas de recoleccin, identificacin y priorizacin de
requerimientos

Obtener la informacin de la descripcin de un software no es una tarea sencilla. Sera
deseable que todos los clientes tuvieran la definicin, clara, precisa y detallada de lo que
esperan que, una empresa de desarrollo de software construya para la solucin o mejora
de sus procesos. Sin embargo esto no siempre es as. A veces, se necesita utilizar una o
varias estrategias para llegar obtener la informacin necesaria que ayude a determinar
detalladamente dichas caractersticas. En este tema analizaremos algunas tcnicas que
se utilizan para este fin.

El proceso de desarrollo de requerimientos segn Sommerville, Ian (2011, 102) consta de
4 fases, las cuales debern realizarse iterativamente hasta determinar que ya se tienen
completamente los requerimientos que representan la funcionalidad del software y que el
cliente espera. Observa las fases:

1. Descubrimiento de requerimientos.

10

Esta etapa incluye actividades para interactuar con los involucrados del sistema
para identificar los requerimientos y toda la documentacin relacionada:
Diagramas y descripcin de casos de uso, escenarios, SRS, diagramas de
dominio e interaccin, etc. Mismos que se explican con mayor detalle en los
siguientes temas.

2. Clasificacin y organizacin de requerimientos.
Consiste en organizar el listado de requerimientos agrupndolos de acuerdo a su
contenido lgico, es decir, en el orden en que se realizan los procedimientos en la
realidad y en un orden funcional, que vaya de acuerdo a la secuencia en que se
ha diseado el software para su operacin. Deber identificar requerimientos que
se relacionen y puedan formar mdulos o divisiones del software.

3. Priorizacin y negociacin de requerimientos.
Consiste en identificar a los requerimientos que tienen mayor importancia o
urgencia de ser desarrollado con respecto a los dems, este es un proceso de
negociacin entre los diversos proveedores de requerimientos de la organizacin.

4. Especificacin de requerimientos. Este proceso consiste en ir documentando los
requerimientos con todo el detalle posible, por ejemplo la descripcin de los casos
de uso es una muestra de cmo se puede describir detalladamente un
requerimiento. Un documento ms completo y a la vez ms complejo es el SRS,
que integra todos los diagramas y su descripcin, que hayas realizado para
describir cada requerimiento. Cada vez que se repite un ciclo de este proceso el
detalle aumenta y a esto le llamamos refinamiento de requerimientos.

Como ya se mencion estos 4 pasos se repiten y la comprensin de los requerimientos
por parte del analista mejora en cada iteracin. La comprensin de los requerimientos por
parte de los involucrados es un proceso difcil, principalmente porque el cliente pocas
veces tienen bien definido lo que necesitan de un sistema de cmputo y pueden hacer
peticiones inalcanzables en tiempo, costo o recursos. Adems utilizan sus propios
trminos, tambin suelen decir un mismo requerimiento de muchas maneras haciendo
entender que se tratan de cosas diferentes.

Otra dificultad para el equipo de desarrollo es cuando, a la mitad del proceso de creacin
del software, se realizan cambios en la organizacin por nuevos participantes que no se
haban involucrado desde el inicio del proyecto, lo cual puede afectar en tener que volver
a realizar otras descripciones en los requerimientos o incluso insertando nuevos
requerimientos. Llevar una gestin adecuada del cambio puede ayudar para atenuar el
problema.

En seguida se plantearn algunas tcnicas para obtener informacin de la descripcin de
un software como son: la observacin, el cuestionario, la entrevista y encuestas:

11

La observacin

Partiendo de la idea de que todo software es un modelo de un modelo del usuario,
debemos identificar como es que el usuario opera su modelo para entonces, poder
simular esto con un software. Es por ello que la observacin es una tcnica sencilla, pero
poderosa, ya que nos permite estar directamente siendo testigos de cmo operan las
cosas en la organizacin.

Para aplicar la tcnica de la observacin el analista deber estar presente en el lugar
donde se ejecuta el proceso que se desea observar, analizando la funcionalidad de la
operacin que se quiere construir en un software. Su principal ventaja es que se
observan todos los detalles del funcionamiento real de la empresa (que a veces no es
como se encuentra descrito en los manuales de proceso) y adems se detecta el
ambiente en el que se instalar el proyecto

Entrevistas

Las entrevistas son importantes, ya que nos permiten estar en contacto con el cliente y se
pueden combinar con otras tcnicas de recoleccin de informacin, como son la
observacin o escenarios, entre otras. Las entrevistas se pueden realizar de dos
maneras: cerradas y abiertas

1. Cerradas: los participantes responden a un conjunto de preguntas. No se pueden
agregar ms preguntas.
2. Abiertas: no hay un conjunto de preguntas predefinidas solo se abarca una
problemtica especfica, las preguntas van surgiendo de acuerdo a lo que el
entrevistador quiere indagar o descubrir.

En la prctica puede realizarse la combinacin de ambos tipos de entrevistas. El analista
prepara un conjunto de preguntas, que incluso, puede enviar previamente al cliente.
Durante la entrevista, estas servirn de gua. El analista podr realizar nuevas preguntas
para obtener mayor detalle; basarse en las respuestas dadas o, bien, para indagar un
nuevo tema que no haya contemplado en la entrevista cerrada. El analista podr solicitar
al cliente ejemplos o documentos de la organizacin para completar las respuestas.

Escenarios

Se utilizan para comprender como funcionara el sistema de software en un escenario
real. Los analistas utilizarn esta informacin como requerimientos del sistema. Los
escenarios consisten en ejemplos sobre las descripciones de las sesiones de cada

12

interaccin, comienzan con el bosquejo de una iteracin y se va detallando en cada
iteracin. Esta tcnica se aplica generalmente en la programacin extrema. Cada
escenario debe incluir la descripcin de:

1. El evento que dispara el proceso, corresponde a la explicacin de la actividad
que genera el uso del proceso que posteriormente ser realizado en el software.
2. Flujo normal, se refiere a la secuencia de actividades que se realizan para operar
el proceso que se pretende automatizar por medio del software.
3. Que puede salir mal, describir aquellas actividades que no estn incluidas en el
flujo normal, pero que si llegasen a ocurrir alteraran la secuencia del proceso o
causaran algn error.
4. Otras actividades, actividades que pueden o deben ejecutarse al mismo tiempo,
es decir, actividades paralelas.
5. Estado final del sistema, describir el estado del software cuando las actividades
del proceso llegan al fin.

Veamos los puntos anteriores con un ejemplo de un escenario:

Lo que dispara el proceso:
Todos los lunes desde las 8:00 am llegan los proveedores con diferentes materias
primas, este proceso es el resultado de las compras que se generaron durante el
viernes de la semana anterior. Otros tipos de entradas corresponden a la materia
prima de importacin, esta puede llegar en cualquier momento del da y cualquier
da de la semana.

Flujo normal:
El almacenista revisa que el proveedor haya llegado con la orden de compra y
factura. Posteriormente hace la inspeccin fsica revisando que se haya surtido lo
que se indic en la orden de compra, tanto en cantidad como en las caractersticas
del producto. Por ltimo revisa que la factura contenga exactamente lo que se
pidi y que est correctamente escrita. Cuando termina procede a dar la entrada
fsica al almacn y genera el registro de entrada en el sistema. Realizando una
bsqueda con las primeras tres palabras del artculo para ubicar su cdigo y
capturar la cantidad que est recibiendo.

Que puede salir mal
Si el artculo no ha sido registrado previamente, no podr localizarlo para registrar
entradas. Por lo cual deber registrarlo como un nuevo artculo obteniendo del
sistema la clave que le corresponde de acuerdo a las reglas del negocio
plasmadas en el documento de Registro de artculos.

Otras actividades
Mientras se realizan estas actividades, las consultas y generacin de reportes del

13

sistema del almacn podrn estarse realizando sin ningn problema.

Estado final del sistema
Los registros de entrada al almacn debern estar en la base de datos. Se deber
actualizar los campos de existencias y costos promedios del registro de cada
artculo que ha tenido un registro de entrada.
Ejemplo de escenario: entrada de materia prima al almacn.

Cuestionario

Esta tcnica resulta til cuando es necesario captar un gran volumen de informacin en
poco tiempo. Tambin cuando la separacin geogrfica impide que la informacin sea
captada por otras tcnicas. Para que un cuestionario sea til, ste debe ser conciso y
enfocado a pocos aspectos del sistema. Su redaccin debe estar bien definida, debe ser
precisa y clara. Se pueden combinar preguntas abiertas (puede redactar libremente una
respuesta) y cerradas (la respuesta queda limitada a una cantidad de opciones), adems
se puede incluir una descripcin para explicar el objetivo del cuestionario y favorecer que
el usuario conteste lo ms objetivamente posible. Por ltimo puede contener una frase de
agradecimiento. (Piattini, M., Calvo M., Cervera J. & Fernandez, Luis. 2004. Pg. 184).

A continuacin presta atencin al siguiente tema el cual describe el documento de
requerimientos.

2.1.3. Documento de requerimientos

Existe mucha documentacin que se va generando con los requerimientos, pero el
llamado SRS (especificacin de requerimientos de software) es un documento formal para
detallar lo que debe implementar el equipo de desarrollo, ya que incluye a los
requerimientos de usuario y del sistema.

Este documento SRS es til por las siguientes razones:
Es una herramienta de comunicacin y de integracin de las especificaciones del
software entre el equipo de desarrollo.
Puede ser utilizado como la base del contrato entre el comprador y la empresa que
desarrolla el software.
Se puede utilizar para estimar tiempos y costos del proyecto. Y por lo tanto poder
generar el plan del proyecto.
Es til para describir las etapas de anlisis, siendo uno de los principales
entregables de estas etapas.
Es til para controlar los cambios que vayan surgiendo en el desarrollo del
software.
Ayuda a evaluar el producto final.

14

El SRS se desarrolla para varios lectores por ejemplo, clientes, administradores,
desarrolladores, testers, etc.

El contenido de un documento SRS de acuerdo al estndar de la IEEE (Institute of
Electrical and Electronics Engineers) es un estndar genrico y se adapta a usos
especficos. Como se muestra en la siguiente tabla.

Tabla. Estructura de un documento de requerimientos. (Sommerville, Ian. 2011, pg. 93)
CAPTULO DESCRIPCIN
Prefacio Describir a quin va dirigido, la historia de versiones con el resumen
de cambios realizados en cada versin.
Introduccin Describe brevemente la necesidad que se cubrir con el sistema, las
funciones que tendr y cmo funcionar con otros sistemas. Y cmo
se ajusta el sistema a los objetivos de la organizacin.
Glosario Define los trminos tcnicos que se emplean en el documento.
Definicin de
requerimientos
del usuario
Aqu se presentan los servicios que ofrecen al usuario. Tambin, en
esta seccin se describen los requerimientos no funcionales del
sistema. Se hace uso del lenguaje natural o diagramas que
entiendan los lectores.
Arquitectura del
sistema
Se muestra una descripcin de alto nivel de la arquitectura del
sistema, mostrando su funcionalidad a travs de mdulos del
sistema.
Especificacin
de
requerimientos
del sistema
Se muestran con detalle los requerimientos funcionales y no
funcionales e, incluso, las interfaces a otros sistemas.

Modelos del
sistema
Son grficos que muestran relaciones entre componentes del
sistema y su entorno. Por ejemplo grficos de objetos, modelos de
flujos de datos o modelos semnticos.
Evolucin del
sistema
Describe los posibles cambios futuros para el sistema como parte de
una continuidad ya sea ocasionada por el hardware, por el usuario o
por la organizacin.
Apndices Informacin detallada y especfica que se relaciona con la aplicacin
a desarrollar.
ndice Pueden incluirse varios ndices, el de contenido, de diagramas, de
funciones, etc.

Como vimos el documento SRS tiene algunas ventajas sin embargo, las metodologas
giles no estn de acuerdo en llenar un documento tan extenso, pues -argumentan que-
en cuanto lo escriben comienza a hacerse obsoleto, as que este documento se
desperdicia en gran medida, por ejemplo, en el enfoque que presenta la programacin
extrema se recopila de manera incremental requerimientos del usuario y los escriben en

15

tarjetas como historias de usuario. De esta manera, el usuario da prioridad a los
requerimientos para su implementacin en el siguiente incremento del sistema.

Ya sea que decida o no utilizar un documento tan especfico como lo es un SRS o que se
decidan por las metodologas giles cuya especificacin es mnima, en ambas
metodologas deber existir la validacin de los requerimientos para asegurar que estn
correctos. En el siguiente tema se explicar con mayor detalle el proceso de validacin
pero antes realiza tu primera actividad para la unidad.

Actividad 1. Tipos de tcnicas de recoleccin

El proceso de descubrir requerimientos nos lleva a emplear diferentes tcnicas de
recoleccin y emplearlas de acuerdo a la situacin que se viva en cada proyecto. Por
ejemplo; habr situaciones en las que el cliente necesita ver ejemplos o prototipos del
software para definir ms precisamente sus requerimientos, otras, en las que, se tendr
que observar el proceso. O bien puede haber otros casos en los que una o dos
entrevistas sern suficientes para obtener todos los requerimientos. Escucha atentamente
el siguiente audio para poder realizar esta actividad:

Audio: Empresa manufacturera de productos de piel elite

Propsito: dado el caso de estudio, identificar las tcnicas de recoleccin que se
emplean.

Instrucciones:
1. Despus de haber escuchado atentamente el audio, completa el siguiente cuadro:
Dialogo Respuesta
1.
2.
3.
En donde en la primera columna dialogo establecers por escrito la parte que
identificaste del audio que corresponda a la respuesta de la pregunta y en la segunda
columna respuesta redactaras lo que responde a la pregunta.
Y las preguntas son las siguientes:

Para qu se utiliz alguna tcnica de cuestionario?
Para qu se utilizar la tcnica de observacin?
Qu tipo de entrevista se est utilizando?

2. Guarda la actividad en un archivo de texto con el nombre IIS_U2_A1_XXYZ.


16

Actividad 2. Tcnicas de recoleccin
Seleccionar alguna tcnica de recoleccin, depender del objetivo que se pretenda lograr,
esto en base a cada caso particular. Por ejemplo, si nuestro cliente no tiene bien definido
el alcance del software y tampoco sabe cmo expresar los requerimientos. El analista
podr ayudarle utilizando la tcnica de casos de uso o de prototipos para hacer
escenarios del funcionamiento del sistema y de esta manera el cliente indique si es lo que
espera o no.

Propsito.
El propsito de esta actividad es discutir la tcnica de recoleccin que mejor se adapte a
un caso en particular.

Instrucciones
1. Escucha de nuevo el audio Empresa manufacturera de productos de piel Elite. (si es
necesario) y responde las siguientes preguntas:

a. De acuerdo a la entrevista e informacin que se tiene del proyecto Ya se tiene claro
su alcance?
b. Consideras que las tcnicas que se aplicaron al caso de estudio, fueron apropiadas?
Fundamenta tu respuesta y si es posible establece las mejoras.
c. Pon atencin a las necesidades que comenta el cliente respecto al software,
Consideras que todos los requerimientos que mencion deben ser parte del
software?
d. De las tcnicas vistas en este tema Qu otra tcnica podras utilizar? Explica por
qu?

2. Dirgete al foro para realizar tu participacin.

2.1.4. Validacin de requerimientos

La validacin de requerimientos consiste en revisar que stos definan adecuadamente el
sistema que necesita el cliente. Este proceso es importante porque los errores en
requerimientos pueden conducir a grandes costos por tener que rehacerlos. Por lo cual es
necesario que se realicen varios tipos de comprobaciones:

1. Comprobacin de validez. Que los requerimientos adicionales o derivados
realmente se relacionen con lo que el cliente necesita.
2. Comprobaciones de consistencia. Los requerimientos en el documento no
deben estar en conflicto, no deben ser contradictorios o tener descripciones
diferentes de la misma funcin del sistema.

17

3. Comprobaciones de totalidad. El documento de requerimientos debe contener
todas las peticiones del usuario y sus restricciones.
4. Comprobaciones de realismo. Revisar que los requerimientos sean factibles y
alcanzables. Tomando en cuenta la tecnologa a emplear, presupuesto y
conocimiento necesario para su desarrollo.
5. Verificabilidad. Que los requerimientos puedan ser entendibles para el cliente y el
desarrollador y puedan ser verificables.

Para realizar la verificacin se utilizan varias tcnicas, algunas de ellas son:
1. Revisiones de requerimientos. Personal del equipo de desarrollo revisa que no
haya errores e inconsistencias.
2. Creacin de prototipos. Se construye un modelo ejecutable del sistema para que
el cliente pueda comprobar si cubre con las funcionalidades que solicit.
3. Generacin de casos de prueba. Al realizar casos de prueba, s resulta difcil
realizarla, o no se puede comprobar, esto nos indica que el requerimiento est mal
definido o presenta alguna inconsistencia.

Ya que nuestros requerimientos estn ms confiables y correctos, es posible comenzar a
modelarlos con los diagramas UML. En los siguientes temas veremos diferentes
diagramas de modelado.

2.1.5. Casos de uso

Traducir las peticiones del cliente en un lenguaje ms tcnico y formal, resulta ser una
actividad a veces complicada, por lo que convendra apoyarse de alguna herramienta que
pueda ser fcil de usar y comprender. Esto se cubre con los casos de uso que son
diagramas del lenguaje unificado de modelado (UML) y tambin se consideran como una
tcnica de recoleccin de requerimientos. Se describe en un diagrama todas las
iteraciones posibles entre los usuarios y el sistema. Son muy tiles para representar las
funciones que el sistema debe tener y sus elementos son los siguientes:

o Actor.- Se refiere a cualquier elemento que interacta con el sistema. ste puede
ser un usuario, otro sistema o algn hardware. Se representa con un monigote
con su nombre en la parte inferior. Dicho nombre debe comenzar con mayscula.

Almacenista

o Caso de uso.- Son las funciones o comportamientos del sistema. Se representan
con una elipse que contiene la descripcin de la funcin en lenguaje natural o

18

estructurado. Algunas veces si el nombre es muy largo es conveniente colocarlo
debajo de la elipse.

Alta de materia
prima

o Las lneas entre los actores y los casos de uso se denominan arcos de
comunicacin o relaciones.

Hay diferentes tipos de relaciones:

Asociacin. Interaccin entre el actor y el caso de uso.
Extiende. Comportamiento adicional de un caso de uso
base. Tambin se puede poner la palabra <<Utiliza>>

Generalizacin. Hereda las caractersticas de un caso de
uso a otros generando una relacin de especializacin.

Incluye. Contiene el comportamiento de un caso de uso
dentro de otro.
Los diagramas de caso de uso deben tener una descripcin, en la cual se detalla las
especificaciones de su comportamiento en flujo de actividades de secuencia normal y
excepciones. Para lo cual se puede utilizar una tabla como la siguiente:

Tabla. Descripcin de los casos de uso. Adaptacin de la tabla de (Sommerville,
Ian. 2011, pg.125)
[Id
requerimiento]
Nombre del requerimiento
Descripcin Lo que el sistema debe permitir con [actores] en un [tiempo] la
[funcionalidad]
Requerimientos [id requerimiento] [Nombre del requerimiento]
Eliminar materia prima
Almacenista
Alta de materia
prima
<< Extiende>>
<< Incluye>>

19

asociados [id requerimiento] [Nombre del requerimiento]

Secuencia
normal
[# paso] [Accin]
[# paso] Si [situacin que produce alternativa]
realizar [accin]

Excepciones [# paso] En el caso de que [situacin que provoca la
excepcin] el sistema deber [accin]

Frecuencia Cantidad de veces en que se lleva a cabo
Prioridad Con respecto a otros requerimientos [Alta, media, baja]
Observaciones Otras especificaciones necesarias

Ejemplo

RF-01 Registro de materia prima al almacn
Descripcin El sistema debe permitir al almacenista cada vez que exista
una materia prima nueva registrarla como un nuevo material al
almacn.
Requerimientos
asociados
RF-01-01 Alta materia prima
RF-01-02 Baja lgica de materia prima
RF-01-03 Modificar materia prima
RF-01-04 Consultar materia prima
RF-02 Registro de movimientos al almacn
Secuencia
normal
1. Almacenista consulta una materia prima en el sistema
2. Si existe
Selecciona en el sistema la materia prima
Si no existe
Da de alta la materia prima asignndole un cdigo
3. Registra movimiento de entrada al almacn.
Excepciones 1. En caso de que haya encontrado un error en la captura de
la materia prima, el sistema debe tener la opcin de
modificar los datos.
2. En caso de tener materia prima descontinuada, el sistema
debe permitir cambiar el estado a Baja, para que se
muestren las consultas nicamente con materiales
vigentes.
Frecuencia El almacn recibe las compras todos los lunes en un horario
de 8 am a 2 pm, sin embargo puede existir alguna compra no
programada algn otro da de la semana.
Prioridad Alta
Observaciones Cuando se inserta una nueva materia prima el cdigo que se
le asigna tambin lo lleva en barras para facilitar la lecto

20

escritura en el sistema.

Los diagramas de caso de uso pueden ser tiles para descubrir requerimientos en los
procesos de los usuarios, pero tambin son de gran ayuda para describir a los
requerimientos funcionales del software. Hay otros diagramas que tambin sirven para
mostrar con otra vista a los requerimientos. Estos son los que a continuacin veremos en
el modelado del dominio y de la interaccin.

Actividad 3. Requerimientos

Durante este tema has podido identificar como se obtienen y se clasifican los
requerimientos. Dentro de esta clasificacin se han mencionado principalmente a los
requerimientos del usuario y del sistema. Como una sub clasificacin de los
requerimientos del sistema tenemos los requerimientos funcionales y no funcionales.

21

Dentro del tema previo se han citado algunos ejemplos para aclarar y complementar ms
las definiciones. Por lo tanto ests listo para identificar los requerimientos provenientes de
las peticiones de un cliente y clasificarlos de acuerdo a la estructura mencionada.

Propsito.
Identificar los requerimientos y su tipo dado un caso de estudio.

Instrucciones
Escucha nuevamente el audio Empresa manufacturera de productos de piel Elite para
que identifiques todas las peticiones del cliente.
1. Completa lo que se te pide en la siguiente tabla con todas las peticiones del cliente
(Requerimientos):
Nmero Requerimiento Tipo de
requerimiento
#consecutivo
por cada
requerimiento
-Peticiones del cliente- Funcional o no
funcional

2. De la tabla anterior obtendrs un listado de requerimientos, el cual debers compartir
en el foro.

3. Ingresa al foro y genera una nueva entrada.

2.2. Aplicacin de modelo del dominio y de la interaccin

Un modelo es la representacin de un concepto, objeto o sistema. Se toma como
referencia para producir algo igual. Enfocando esto al desarrollo de software, podemos
decir que necesitamos identificar los modelos del usuario de la forma en que realiza sus
procesos y convertirlos en modelos con grficos o smbolos que representen este proceso
y que puedan ser entendibles para el equipo de desarrollo de software (analistas,
diseadores, programadores, responsables de pruebas, etc.)

El modelado de sistemas es una disciplina til para representar la visin que se tiene del
software que se va a construir o la descripcin tcnica del software terminado. El
modelado de sistema consiste en la construccin de diferentes tipos de diagramas y el
estndar que ms se utiliza es UML, que cuenta con aproximadamente trece diagramas
para describir diferentes perspectivas del software. En este tema veremos dos categoras
de diagramas: de dominio del sistema y los de interaccin.

Modelos del dominio del sistema:


22

Los diagramas de dominio se utilizan para representar aspectos de la realidad del
contexto del software. No describen al software, ms bien muestran su entorno; incluso
incluyen a otros sistemas automatizados y el tipo de asociacin que pueden tener.

Los modelos de dominio se pueden representar por medio de diagramas de clases donde
puedes delimitar la frontera de un software y mostrar su entorno, que puede incluir o no, a
otros sistemas automatizados y las relaciones que pueden tener. Un modelo de dominio
consta de un conjunto de diagramas de clases con sus atributos, pero omitiendo la
definicin de sus operaciones. Los diagramas de clases se vern en el siguiente tema.

Modelos de interaccin:

Los sistemas tienen interacciones de algn tipo, por ejemplo, con el usuario que implican
entradas y salidas del mismo. Tambin hay interacciones entre el sistema a desarrollar y
otros sistemas; o interacciones entre los componentes del sistema. En el modelado de
caso de uso y los de secuencia muestran interacciones con diferentes niveles de detalle y
es posible utilizarlos juntos. El diagrama de colaboracin es otro ejemplo de este tipo de
modelos de interaccin.

A continuacin comenzaremos explicando cmo puede modelarse la estructura de un
sistema por medio de los diagramas de clases.

2.2.1. Diagramas de clases

Una manera de modelar la estructura de un sistema es utilizando un diagrama de clases.
Los diagramas de clases nos ayudan a desarrollar un sistema con un diseo orientado a
objetos. Una clase es considerada como una definicin general de un tipo de objeto del
sistema y est representada por un rectngulo con nombre de la clase (esto en su
representacin sencilla). La lnea que une las clases es una asociacin que indica un
vnculo entre dichas clases. Entonces los objetos representan cualquier cosa del mundo
real, por ejemplo: un material, una factura, un almacenista, etc. Por parte del sistema se
agregan objetos que le dan funcionalidad al sistema. (Sommerville, Ian. 2011, pg.129)

Por ejemplo la siguiente figura es un diagrama de clase simple que muestra dos clases:
Materia_prima y Movimientos_E_S (movimientos de entrada y salida) con una asociacin
entre ellos. Adems muestra cuantos objetos intervienen en la asociacin, en este caso
es 1:* lo que significa que 1 materia prima puede tener muchos movimientos de entrada y
salida. Esto es denominado multiplicidad.

Materia_prima Movientos_E_S
1 *

Figura. Diagrama de clases y asociacin

23

Multiplicidad: La multiplicidad determina cuantos objetos de cada tipo intervienen en la
relacin. Y existen los siguientes.

1 Uno y solo uno
0..1 Cero o uno
X..Y Desde X hasta Y
* Muchos
0..* Cero o muchos
1..* Uno o muchos

- Cada lnea de relacin tiene dos multiplicidades (una para cada extremo de la
relacin)
- Para especificar hay que indicar la multiplicidad mnima y mxima
(mnima...mxima)
- Cuando a multiplicidad es 0, la relacin es opcional.
- Cuando es 1 indica que la relacin es obligatoria.

Para especificar con mayor detalle las clases, se puede agregar las caractersticas de
sta. Por ejemplo: un objeto Artculo tendr atributos como un identificador, la
descripcin, existencias y costo unitario, sus operaciones podran ser Alta, Baja, Consultar
y Modificar principalmente. En UML los atributos y operaciones se muestran en un
rectngulo con tres secciones. De esta manera tenemos que:

1. El nombre de la clase - objeto aparece en la parte superior.
2. Los atributos aparecen en la parte media y de manera opcional tienen el tipo de
dato de cada atributo.
3. Las operaciones o comportamientos (Llamadas mtodos en algunos lenguajes de
programacin como Java) estn en la seccin inferior del rectngulo.

Algunas veces encontraremos objetos que pertenecen a un mismo tipo y por lo tanto,
pueden compartir atributos o comportamientos que les son comunes. Estos pueden ser
asociados por medio de la relacin llamada herencia.

Herencia (Especializacin/Generalizacin):
Indica que una clase hereda los mtodos y atributos de la clase base, por lo cual una
clase derivada adems de tener sus propios mtodos y atributos, podr acceder a las
caractersticas y atributos visibles de su clase base (public y protected).


24

Diagrama de clases con propiedades y generalizacin.

En seguida te presentamos dos conceptos de los cual necesitas comprender para poder
observar el diagrama que se encuentra posterior a stos:

Composicin:
La composicin es una relacin en donde el tiempo de vida del objeto est condicionado
por el tiempo de vida del que lo incluye. El objeto base depende del objeto que lo
compone o sea es parte de un todo.

Agregacin:
La agregacin es una relacin donde el tiempo de vida del objeto incluido no depende del
que lo incluye. El objeto base utiliza al objeto incluido para su funcionamiento.

Diagrama de clases con composicin y agregacin.

El anterior diagrama demuestra lo siguiente:

- Un Almacn se compone de 1 a muchos objetos tipo Artculo y se asocia con 0 o
muchos objetos tipo Proveedor.

25

- Cuando se destruye la clase Almacn tambin es destruida la clase Artculo. En
cambio no es afectada la clase Proveedor.
- La composicin se identifica con un rombo relleno.
- La agregacin se identifica con un rombo transparente.

Los diagramas de clases son los ms comunes dentro del modelado de sistemas
orientados a objetos. Pero nos sirven para representar una vista esttica del sistema. Si
queremos demostrar cmo se da la comunicacin e interaccin dentro del sistema
tendremos que acudir a otro tipo de diagramas. Por ejemplo el diagrama de secuencia
que veremos a continuacin.

2.2.2. Diagramas de secuencia

El diagrama de secuencia en UML es un diagrama de interaccin donde destaca el envo
de mensajes entre un conjunto de objetos. Los objetos pueden ser instancias con el
nombre del objeto o bien, objetos annimos. Estos diagramas se utilizan para describir la
vista dinmica de un sistema. En otras palabras el diagrama de secuencia muestra las
funcionalidades que se representan en un caso de uso. Los objetos y actores se
muestran en la parte superior del diagrama; de estos se desprende una lnea punteada
vertical. Las interacciones entre objetos se indican con flechas dirigidas. El rectngulo
sobre las lneas punteadas representa el ciclo de vida del objeto. La lectura es de arriba
hacia abajo. Los mensajes llevan unas flechas que indican las llamadas a objetos,
parmetros y valores que regresan. Las condiciones o alternativas se expresan dentro de
corchetes.

Observa el siguiente diagrama de secuencia:


26

:InterfazUsuario :RegistroArtculo :ProgramaPrincipal
:BDAlmacn
RegistroUsuario
:Usuario
GeneraEvento(RegistroUsuario)
RegistroArtculo
Ejecutar(Insercin SQL)
Ejecuta(Insercin SQL)
DespliegaPantallaRegistroArtculo
Salir
Retroalimenta Retroalimenta
Retroalimenta
Retroalimenta

Diagrama de secuencia de alta de artculo del almacn de materia prima. (Booch, G.,
Rumbaugh J. & Jacobson, I. 1999. Pg. 83).

El diagrama de secuencia de la imagen anterior despliega una serie de mensajes entre
los objetos usuario, InterfazUsuario, RegistroArtculo, ProgramaPrincipal, BDAlmacn.
Comienza con el DespliguePantallaRegistroArtculo, cuando el usuario entra por primer
ocasin debe registrarse en la InterfazUsuario, lo cual dispara el evento
GeneraEvento(RegistroUsuario) en el ProgramaPrincipal, a su vez, ejecuta la insercin
SQL en la BDAlmacn. Cuando realiza la consulta, el resultado de esta es regresado al
ProgramaPrincipal y la InterfazUsuario.

Retorna el DesplieguePantallaRegistroArtculo, el usuario introduce datos en el
RegistroArtculo y se ejecuta la InsercinSQL en la BDAlmacn. La BDAlmacn,
Retroalimenta al ProgramaPrincipal y al RegistroArticulo.

El diagrama de secuencia es un tipo de diagrama de interaccin es decir, de
comportamiento, ya que demuestran los aspectos dinmicos del sistema. Otro tipo de
diagrama con estas caractersticas es el diagrama de colaboracin que vers en el
siguiente tema.


27

2.2.3. Diagramas de colaboracin

Los diagramas de colaboracin se utilizan para explicar una estructura entre los objetos
que se envan mensajes. Los objetos generalmente son instancias con o sin nombres
(annimos). Y se utilizan para describir una de las vistas del sistema. Estos diagramas
son tiles para entender cul es la mejor manera de desarrollar un sistema, permite a los
diseadores de software asegurarse de que el software que se desarrolla cubrir con los
requerimientos cuando sea implementado. (Booch, G., Rumbaugh J. & Jacobson, I. 1999.
Pg. 84).

A continuacin se presenta un ejemplo de un diagrama de colaboracin donde se
describe el caso de uso del registro de un pedido. Desde el objeto Ventana de registro
de pedidos se emite el mensaje prepara() para el objeto Pedido, este a su vez enva el
mensaje prepara() condicionado para cada elemento del pedido. Por ejemplo PVC
pegamento es un ejemplo de una instancia del elemento del pedido, del cual se revisar
si hay existencia y si hay existencia se aplica descuenta() y se prepara el Artculo para
entrega, si no se debe revisar si se necesitaReordenar(), en este caso se aplica el
Reorden de artculo.

Diagrama de colaboracin.

En el diagrama anterior se pueden apreciar los componentes. Los rectngulos con el texto
subrayado representan instancias de objetos que pueden tener nombre o no (annimos).
Si carecen de nombre se dejan los dos puntos [:]. Tienen lneas de transicin que llevan
un mensaje con una flecha que indica la direccin del mensaje. Los mensajes van
numerados marcando el orden de la secuencia, esta numeracin puede ser entera o
Objeto
Mensaje
Nmero de secuencia

Auto delegacin

28

decimal. Los objetos pueden enviarse mensajes ellos mismos, lo cual es llamado auto
delegacin. Y los mensajes pueden contener una condicin.

Los aspectos dinmicos del software se representan por medio del flujo de mensajes
principalmente como en la figura anterior. Otro tipo de diagramas de interaccin son los
diagramas de estado que a continuacin se muestra.

2.2.1. Diagramas de estado

Los diagramas de estados se aplican para mostrar una vista dinmica de un sistema. Son
tiles para modelar el comportamiento de una interfaz o una clase. Se aplican
ampliamente para modelar sistemas reactivos. (Booch, G., Rumbaugh J. & Jacobson, I.
1999. Pg. 85).

Grficamente un estado se representa por un rectngulo ovalado. Las transiciones
mediante flechas con el nombre del evento respectivo. Para indicar el estado inicial se
utiliza un crculo relleno. Y para el estado final se utiliza un crculo hueco que incluye un
crculo relleno ms pequeo en el interior. Las transiciones pueden llevar condiciones que
limitan al estado hasta que la condicin sea verdadera y estas condiciones van entre
corchetes.

A continuacin lee el fragmento de la descripcin de un caso de uso Devoluciones en el
almacn y en seguida observa cmo es representado en un diagrama de estado.

Tabla de un fragmento de la descripcin del caso de uso Devoluciones en almacn
Descripcin
Se registra la entrada al almacn si es que no hubo algn error. Ya
que los artculos estn dentro, se pueden detectar defectos en el
mismo almacn o en la produccin. El almacenista genera los
documentos necesarios para devolver dicho artculo al proveedor.
Precondiciones 1. El proveedor debe presentarse con la factura.
Pos condiciones
1. Se registra la entrada en el sistema
2. Se registra la devolucin y nmero de nota de crdito en el
sistema
3. Se registra la cancelacin en el sistema
4. Se hace el clculo inverso de los costos promedios por cada
devolucin

29

Flujo Normal
1. El proveedor presenta los artculos solicitados con su factura
respectiva
2. El almacenista revisa que los artculos no tengan defectos (E1)
3. El almacenista registra la entrada de los artculos y los acomoda
4. Personal del almacn detectan defecto en el artculo.(E2)
5. Usuarios de la empresa detectan defecto en los artculos (E3)
6. El proveedor recibe el material devuelto y genera una nota de
crdito
Flujos
Alternativos
A1: Se debe generar el clculo inverso de los costos promedios por
cada devolucin.
Excepciones
E1: el almacenista explica al proveedor el defecto y rechaza el
artculo
E2: el almacenista hace devolucin y solicita nota de crdito
E3: el almacenista hace una cancelacin (entrada), una
devolucin(salida) y solicita nota de crdito al proveedor.

En seguida observa cmo es representada en un diagrama de estado:

Diagrama de estados de devolucin de un articulo al almacn.

Todos los diagramas son tiles para representar diferentes vistas del modelo del software
que se quiere construir, para poder lograrlo ser necesario partir de una buena base: los
requerimientos y como lo hemos visto durante esta unidad debemos definirlos
adecuadamente.

Autoevaluacin

Para reforzar los conocimientos relacionados con los temas que se abordaron en esta
tercera unidad del curso, es necesario que resuelvas la actividad de autoevaluacin.
Recuerda que es muy importante leer cuidadosamente los planteamientos indicados y
elegir la opcin adecuada para cada uno.


30

Evidencia de aprendizaje. Diagramas del dominio e interaccin

Es importante saber construir diagramas de modelado para lograr un mejor y rpido
entendimiento de los requerimientos por parte del equipo de desarrollo. De la misma
manera es importante saber interpretar los diagramas. Por lo cual la siguiente prctica
refuerza este criterio de interpretacin de diagramas.

Propsito. Identificar los diagramas de modelado del dominio y de la interaccin y de los
elementos que los componen.

Instrucciones.
1. De manera individual analiza los diagramas de casos de uso, de clases y de
colaboracin y realiza una interpretacin de cada diagrama, mnimo 5 lneas por
diagrama.
2. En un archivo de texto elabora un reporte con las interpretaciones que has realizado
de cada diagrama, para ello descarga el documento formato de reporte para poder
desarrollar esta indicacin.
3. Guarda la actividad con el nombre IIS_U2_EA_XXYZ. Enva el archivo a tu
Facilitador(a) para recibir retroalimentacin.
4. Consulta la escala de evaluacin para conocer los parmetros de la actividad.

Autorreflexiones

presente, a partir de ellas, debes elaborar tu Autorreflexin en un archivo de texto
llamado XXX_UX_ATR_XXYZ. Posteriormente enva tu archivo mediante la herramienta
Autorreflexiones.

Cierre de la unidad

Aprender a construir diagramas de modelado y saber interpretarlos, forman parte de las
habilidades que todo desarrollador de software debe tener, no importa el rol que
desempee dentro del equipo. El lder, analista, diseador, programador, encargado de
pruebas, documentador, etc. deben entender este tipo de lenguaje que facilita la rpida
comprensin de los requerimientos del software y su exposicin desde diferentes vistas.

Todo este conocimiento te servir para saber interpretar software documentado por
terceros y tambin para aprender a documentar tus propios proyectos. Si formas parte de
un equipo de desarrollo de software, el modelado es una parte importante de la traduccin

31

e interpretacin de los requerimientos, por lo cual para una ptima comunicacin entre los
miembros de un equipo sern necesarios estos conocimientos.

Para saber ms

Para complementar ms acerca del tema de requerimientos. La siguiente propuesta
es un estudio de la ingeniera de requerimientos que abarca retos futuros como lo son
la escala y la agilidad.
Cheng, B.H.C.; Atlee, J.M. (2007) Research the Requeriments Process, 2nd edition.
Michigan State Univ., East Lansing, MI.
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4221627

Para buscar ms ejemplos y otra forma de describir los diagramas vistos en clase, o
bien, para conocer los otros diagramas que no se abarcaron en el programa de la
asignatura puedes consultar el siguiente manual de UML.

Btz, J. (2011) Desarrollo Orientado a Objetos con UML. Mxico: Mcgraw-Hill.
Recuperado el 23 de enero de 2012 de: http://es.scribd.com/doc/2458870/Desarrollo-
Orientado-a-Objetos-con-UML-librobookespanolspanish

Fuentes de consulta

Booch, G., Rumbaugh J. & Jacobson, I. (1999). El lenguaje unificado de modelado.
Madrid: Addison Wesley.
Piattini, M., Calvo M., Cervera J. & Fernndez, Luis. (2004). Anlisis y diseo de
aplicaciones informticas de gestin. Una perspectiva de ingeniera de software.
Mxico: Alfaomega. Ra-Ma.
Sommerville, Ian (2011) Ingeniera de software. Mxico: Pearson Educacin.

Unidad 3. Diseo, codificacin, pruebas y
mantenimiento

1
Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software 1



5 cuatrimestre


Clave
150920520/ 160920518
Unidad 3.
Diseo, codificacin, pruebas y mantenimiento.

mantenimiento

2
ndice

3. DISEO, CODIFICACIN, PRUEBAS Y MANTENIMIENTO ........................................ 3
Presentacin de la unidad ........................................................................................................... 3
Propsito ........................................................................................................................................ 3
3.1. Diseo..................................................................................................................................... 3
3.1.1. Diseo del sistema ............................................................................................................ 8
3.1.2. Tipos de Arquitecturas ...................................................................................................... 9
Actividad 1. Interfaz .................................................................................................................... 14
3.1.3. La interaccin Hombre-Mquina ................................................................................... 14
3.1.4. Diseo de la interaccin ................................................................................................. 16
Actividad 2. Diseo de interfaz ................................................................................................ 17
3.2. Codificacin ......................................................................................................................... 18
3.2.1. Traduccin de diseo a cdigo ..................................................................................... 18
3.2.2. Codificacin de la interfaz .............................................................................................. 20
Actividad 3. Lineamientos de codificacin .............................................................................. 21
3.2.3. Herramientas de desarrollo: gestin de la configuracin .......................................... 21
3.3. Pruebas y mantenimiento .................................................................................................. 23
3.3.1. Tipos de pruebas y herramientas ................................................................................. 24
3.3.2. Mantenimiento ................................................................................................................. 27
Evidencia de aprendizaje: Tipos de pruebas y el proceso de mantenimiento .................. 28
Para saber ms ........................................................................................................................... 29

mantenimiento

3
3. Diseo, codificacin, pruebas y mantenimiento


En la pasada unidad abarcamos los temas de anlisis y modelado de requerimientos;
enella conociste el concepto de requerimiento y su clasificacin. Respecto al modelado se
abarcaron dos clasificaciones de diagramas UML: los del modelado del dominio y los del
modelado de la interaccin.

En la presente unidad podrs conocer aspectos importantes del diseo del software como
lo son: los lineamientos para disear la interfaz y el cdigo. Adems, identificars los
principales tipos de pruebas y comprenders en qu consiste la etapa de mantenimiento
del ciclo de desarrollo de software.

Al trmino de la presente unidad, habrs abarcado las principales fases del desarrollo del
software y sus caractersticas. Todo sto te servir para que puedas identificar como se
conforma un producto de software: desde la idea, hasta su instalacin y mantenimiento.

Propsito

En esta unidad logrars analizar los:

1. Lineamientos del diseo de la interfaz.
2. Lineamientos de la codificacin.
3. Tipos de pruebas y el proceso de mantenimiento.


Seleccionar estndares de desarrollo de las etapas de diseo, codificacin, pruebas y
mantenimiento para resolver un caso de estudio, analizando sus caractersticas.

3.1. Diseo

El diseo forma parte de las etapas de desarrollo de software, en el cual se utilizan
tcnicas y principios para bosquejar la estructura de los componentes de un software con
suficiente detalle y permitir su interpretacin y construccin. La base del diseo son los
requerimientos del software y su anlisis. A continuacin veremos diferentes elementos
que se deben disear.

mantenimiento

4
Es importante puntualizar que este tema abarca el diseo de sistemas- considerando que
un sistema es un conjunto de partes o elementos organizados y relacionados que
interactan entre s con objetivo especfico-. stos reciben principalmente datos de
entrada y proveen informacin de salida. Los sistemas de software son abstractos y cada
uno puede contener subsistemas que pueden ser parte de uno ms grande. A
continuacin veremos cmo se disea un sistema de software con diferentes vistas.
Comenzaremos con el diseo del contexto.

Diseo de contexto

Adems de disear el sistema se identifican las fronteras del mismo y de otros sistemas
con los que est vinculado. Para realizar esto, los modelos de contexto y de interaccin
cuentan con diferentes vistas para el diseo del sistema en su entorno. Por lo tanto, se
puede definir un modelo de contexto del sistema como: un modelo estructural que incluye
a los otros sistemas con los que se relaciona y, un modelo de interaccin es un modelo
dinmico que muestra el comportamiento del sistema con su entorno.

Cuando se modelan las interacciones de un sistema con su entorno, se utiliza un enfoque
abstracto sin muchos detalles. Puede representarse con un caso de uso el cual se
representa con una elipse que equivale a una interaccin con el sistema. El actor puede
ser un usuario o un sistema de informacin, por ejemplo:

Diagrama de casos de uso de registro y consulta de informacin.

mantenimiento

5
En el diagrama anterior podemos ver al actor Usuario interactuando con varios casos de
uso y con el actor Sistema. El Usuario puede registrar los datos del artculo y solicitar
informacin. Por otro lado el actor Sistema muestra la informacin solicitada. Vemos
tambin a los casos de uso interactuando entre ellos, tal situacin del caso de uso registra
datos del artculo y enva datos del artculo.

Diseo arquitectnico

Ya que se definieron las interacciones entre el sistema y su entorno, se utiliza esta
informacin como base para disear la arquitectura del sistema. Se deben identificar los
componentes del sistema y sus interacciones, despus se organizan en un patrn
arquitectnico como un modelo en capas o cliente servidor.

Interfaces del usuario Lgica de las interfaces
Lgica del negocio
Datos Servicios

Diseo arquitectnico de capas.

En este diagrama se puede apreciar un diseo arquitectnico de la programacin por
capas que son las siguientes:

Presentacin

Aplicacin

Datos
C

A

P

A

S

mantenimiento

6
Capa de presentacin Es la que ve el usuario, tambin se le puede llamar capa de
usuario o interfaz grfica. Permite la interaccin del usuario con el software dndole
informacin y permitindole introducir datos. Contiene el cdigo que soporta la lgica de la
funcionalidad de las interfaces. Y se comunica con la capa de la aplicacin utilizando la
lgica del negocio.

Capa de negocio.- Contiene todos los programas que se ejecutan, recibe las peticiones
de la capa del usuario y se le regresan los resultados de la operacin; adems se
comunica con la capa de datos para hacer peticiones al gestor de base de datos (por
ejemplo instrucciones SQL).

Capa de datos.- Es la que contiene todos los datos los cuales son almacenados y
administrados en uno o ms gestores de bases de datos. Mantiene comunicacin con la
capa de negocio atendiendo las peticiones almacenamiento o recuperacin de datos que
sta le demande.

A continuacin se presenta otra vista del diseo con un enfoque orientado a objetos.

Identificacin de la clase objeto

El diseo orientado a objetos es diferente al diseo estructurado, ya que no se realiza un
problema como en tareas (subrutinas) ni en trminos de datos, si no que, se analiza el
problema como un sistema de objetos que interactan entre s. Lo primero que debe
realizarse es identificar los objetos del programa y, por lo tanto, de las clases con sus
atributos y comportamientos, as como las relaciones entre stas y su posterior
implementacin.

Los sistemas orientados a objetos se deben disear considerando las 4 capas siguientes:

La capa del subsistema. En esta capa se describen los subsistemas en que fue dividido
el software y la solucin tcnica que los soporta.

La capa de clase y objetos. Contiene clases, generalizaciones de clases y
representaciones de diseo de cada objeto.

La capa de mensajes. Contiene los detalles que le permiten a cada objeto comunicarse
con sus colaboradores. Esta capa establece las interfaces externas e internas para el
sistema.

La capa de responsabilidades. Contiene estructuras de datos y diseo algortmico para
todos los atributos y operaciones de cada objeto.

mantenimiento

7
Para entender este tema es importante revisar los mtodos: Booch, Coad y Yourdon, los
cuales son los mtodos de mayor importancia en el mbito del anlisis y el diseo
orientado a objetos. El mtodo, fue realizado por Grady Booch -quien adems es
reconocido por participar en la creacin del lenguaje unificado de modelado (UML)-. El
enfoque de este mtodo es la representacin de la vista lgica del software. Existen otros
mtodos con diferentes enfoques, tal es el caso del mtodo de Coad y Yourdon cuyo
nfasis es en la aplicacin e infraestructura. A continuacin veremos en qu consisten:

Mtodo Booch. Consiste en un proceso evolutivo basado en micro-desarrollos y
macro-desarrollos. Abarca las siguientes fases:

Planificacin arquitectnica que consiste en agrupar y distribuir objetos por niveles,
crear y validar un prototipo.
Diseo tctico para definir reglas de uso de operaciones y atributos, definir
polticas y sus escenarios, refinar prototipo.
Planificacin de la realizacin por medio de la organizacin de escenarios
asignando prioridades, diseo de la arquitectura de escenarios, construir cada
escenario, ajustar objetos y el plan de la realizacin incremental.

Mtodo de Coad y Yourdon. Su enfoque de diseo se dirige a la aplicacin y a la
infraestructura. Su proceso consiste en:

Componente del dominio del problema, que consiste en agrupar las clases y su
jerarqua, simplificar la herencia, refinar diseo para mejorar rendimiento,
desarrollo de la interfaz, generacin de los objetos necesarios y revisin del
diseo.
Componente de interaccin humana, abarca la definicin de actores humanos,
desarrollo de escenarios, diseo de la jerarqua de rdenes, refinar la secuencia
de interacciones, diseo de clases y su respectiva jerarqua.
Componente para gestin de tareas, para identificar tipos de tareas, las
prioridades, identificar la tarea coordinadora, diseo de objetos para cada tarea.
Componentes para la gestin de datos, nos permite disear la estructura de datos,
los servicios, seleccionar herramientas para la gestin de datos y diseo de clases
y jerarquas.

Estos y otros mtodos nos ayudan para el anlisis y diseo orientado a objetos con el
enfoque que cada uno propone. A continuacin veremos un modelo genrico del diseo
orientado a objetos.

Modelo genrico del diseo orientado a objetos

mantenimiento

8
Mientras que el Anlisis Orientado a Objetos (AOO) es una actividad de clasificacin, en
otras palabras, se analiza un problema identificando sus objetos y de qu clase son, as
como sus relaciones y comportamiento del objeto. El Diseo Orientado a Objetos (DOO)
permite indicar los objetos que se derivan de cada clase y su relacin, adems muestra
cmo se desarrollan las relaciones entre objetos, cmo se debe implementar su
comportamiento y cmo implementar la comunicacin entre objetos. En general define
cuatro componentes:

Dominio del problema: subsistemas que implementan los requerimientos.
Interaccin humana: subsistemas reutilizables de interfaz grfica.
Gestin de tareas: subsistemas responsables del control de tareas concurrentes.
Gestin de datos: subsistema responsable del almacenamiento y recuperacin
de datos. (Pressman, R. 2010, pg. 407- 412).

Ya que has visto diferentes modelos para el anlisis y el diseo de un software a
continuacin observa cmo es su proceso del diseo.

3.1.1. Diseo del sistema

El diseo es un proceso iterativo (que se repite) que aplica diversas tcnicas y principios
para definir un dispositivo, proceso o sistema detalladamente para permitir su realizacin
fsica. A continuacin se presentan las principales actividades involucradas en este
proceso de acuerdo a Pressman, R. (2010, pg. 413- 412).:

- Dividir el modelo analizado en subsistemas con las siguientes caractersticas:
o Definir una adecuada interfaz.
o Establecer la comunicacin entre clases.
o Mantener un nmero pequeo de subsistemas.
o Los subsistemas pueden dividirse internamente para reducir la complejidad.
- Identificar concurrencia y asignar de alguna de estas dos maneras:
o Asignar cada subsistema a un procesador independiente.
o Asignar los subsistemas al mismo procesador y ofrecer soporte de
concurrencia a travs de las capacidades del sistema operativo
- Asignar subsistemas a procesadores y tareas con la siguiente estrategia:
o Determinar las caractersticas de la tarea.
o Definir una tarea coordinadora y objetos asociados.
o El coordinador y las otras tareas que lo integran.

Tarea: el nombre del objeto.
Descripcin: descripcin del propsito del objeto.
mantenimiento

9
Prioridad: baja, media, alta
Operaciones: una lista de servicios del objeto.
Coordinado por: como invocar el comportamiento del objeto.
Comunicacin: datos de entrada salida relevantes.

La plantilla bsica de la tarea (Diseo estndar).

- Elegir una de las dos estrategias para la gestin de datos: (1) la gestin de datos para
la aplicacin, y (2) la creacin de infraestructura para el almacenamiento y
recuperacin de objetos.

- Identificar recursos y mecanismos para acceder a ellos.
Los recursos globales del sistema pueden ser unidades externas por ejemplo torres de
discos, procesadores, lneas de comunicacin, etc.
- Diseo de control apropiado para el sistema.
Definir el componente interfaz hombre-mquina (IHM), se pueden aplicar los casos de
uso como datos de entrada. Ya que se defini el actor y su escenario de uso, se
identifica la jerarqua de rdenes o comandos lo cual define las principales categoras
de mens del sistema. Esto se va refinando con cada interaccin hasta que cada caso
de uso pueda implementarse navegando a travs de la jerarqua de funciones.
- Definir como manipular condiciones lmite.
Ya que se definieron los subsistemas es necesario definir las colaboraciones que
existen entre ellos, para esto es til un diagrama de colaboracin como se vio en el
capitulo anterior.
.

Ya que has conocido el proceso del diseo del sistema, es importante conocer los
aspectos importantes de la arquitectura de un software, subtema que vers a
continuacin.

3.1.2. Tipos de Arquitecturas

La arquitectura de software es una abstraccin que muestra un marco de referencia que
sirve de gua en la construccin de un software. Esta se construye con diferentes
diagramas que ayudan a mostrar diferentes vistas del sistema.

La arquitectura de un software puede ser muy simple como un mdulo de un programa o
puede ser tan complejo como incluir bases de datos, comunicarse con componentes de
software o aplicaciones que puedan intercambiar datos entre s. Incluso, aplicaciones
distribuidas que incluyan servidores web, servidores de aplicaciones o gestores de
mantenimiento

10
contenido y actualmente la mayora de los sistemas de cmputo que se construyen son
distribuidos. A los sistemas distribuidos se les define como:

Una coleccin de computadoras independientes que aparecen al usuario como un solo
sistema coherente. (Sommerville, Ian, 2011, pg. 480).

Los sistemas distribuidos presentan las siguientes ventajas:
Comparten recursos de hardware y software.
Diseados de manera estndar que permiten la combinacin de hardware y software
de diferentes proveedores.
Permiten que grandes procesos puedan ejecutarse al mismo tiempo y en
computadoras independientes en red, a esta caracterstica se le llama concurrencia.
Permiten agregar nuevos recursos o aumentar las capacidades del sistema, lo cual se
conoce como escalabilidad.
Pueden existir computadoras con fallas, pero la prdida completa de servicio slo
ocurre cuando hay una falla de red. Cuando ocurre esto se dice que el sistema es
tolerante a las fallas.

Estos sistemas son ms complejos que los sistemas que se ejecutan en un solo
procesador. Algunos de los problemas de diseo ms importantes que se deben
considerar son:

Transparencia: el reto que se tiene en este atributo es lograr que cada nodo
trabaje como si fuese independiente, unificando todos los recursos y sistemas para
la aplicacin y por lo tanto para el usuario.
Apertura: en los sistemas distribuidos se debe dar la apertura a los nuevos
servicios pero sin perjudicar a los ya existentes.
Escalabilidad: poder incrementar las capacidades de trabajo sin perder las
capacidades y usos anteriores.
Seguridad: el reto de la seguridad es mantener la confidencialidad por medio de la
proteccin contra individuos no autorizados. Integridad, con la proteccin contra la
alteracin o corrupcin y la disponibilidad protegerse ante la posibilidad de
interferencia.
Calidad en el servicio: identificar la configuracin que mejor se adapte y sea
aceptable por los usuarios.
Gestin de fallas. Tiene el reto de que el sistema contine funcionando ante fallos
de algn componente de manera independiente, para lo cual debe existir un plan
de mitigacin ante cualquier riesgo latente.

Modelos de interaccin
mantenimiento

11
El modelo de interaccin tiene que ver con el rendimiento y la dificultad de poner lmites
temporales en un sistema distribuido, hay varios tipos de interaccin.

Paso de mensajes.
Radiado (multicast).
Llamada a procedimiento remoto (RPC).
Cita multiflujo (multithreaded).
Publicacin/subscripcin (publish/subscribe)

Y pueden ser representados con los diagramas de interaccin como el que se muestra a
continuacin:

Usuario AplicacinCajero Sistema Impresora
1:IntroduceNip()
2: Ingresar al sistema()
3: Enva Saldo()
4: Cobro al cliente ()
5: Cliente paga()
6: Abono al saldo()
7: Imprime comprobante()

Diagrama de interaccin

Middleware

Los sistemas de informacin se construyen con diferentes lenguajes de programacin, la
base de datos se genera en algn software gestor especfico, adems pueden ser
ejecutados en distintos procesadores, por lo tanto un sistema distribuido necesita software
para gestionar todas estas partes y asegurarse que puedan comunicarse e intercambiar
datos. El trmino middleware se usa para referirse a este software que se encuentra en el
mantenimiento

12
centro y se compone de un conjunto de libreras que se instalan en cada computadora
distribuida.

Computacin cliente - servidor

Los sistemas distribuidos a los que se accede por Internet normalmente son del tipo
clienteservidor. En esta arquitectura, una aplicacin se modela como un conjunto de
servicios que proporciona el servidor. Los clientes pueden acceder a dichos servicios y
presentar los resultados a los usuarios. Los clientes desconocen la existencia de otros
clientes, pero deben identificar a los servidores que les otorgaran el servicio.

Los sistemas clienteservidor dependen de que est bien estructurada la informacin que
solicitan y que aparte se ejecuten los clculos o procesos para generar esa informacin.
Para esto se deben disear de manera lgica las diferentes capas lgicas:

- Capa de presentacin: se ocupa de presentar informacin al usuario y gestionar todas
sus interacciones.
- Capa de gestin de datos: gestiona los datos que pasan hacia y desde el cliente. Puede
comprobar datos y generar pginas Web, etc.
- Capa de procesamiento: para implementar la lgica de la aplicacin y proporcionar la
funcionalidad requerida a los usuarios finales.
- Capa de base de datos: almacena datos y ofrece servicios de gestin de transaccin,
etc.

Los diseadores de sistemas distribuidos deben organizar sus diseos de sistema para
encontrar un equilibrio entre rendimiento, confiabilidad, seguridad y manejabilidad del
sistema. No existe un modelo universal de organizacin de sistemas adecuado para todas
las circunstancias. Por ejemplo los siguientes tipos de patrones de arquitectura:

1. Arquitectura maestro-esclavo: se usan en un sistema de tiempo real donde puede
haber procesadores separados asociados con la adquisicin de datos del entorno
del sistema, procesamiento de datos y computacin y actuador de gestin. Este
modelo se usa en situaciones donde es posible predecir el procesamiento
distribuido que se requiere, y en el procesamiento puede asignarse a
procesadores esclavos que pueden usarse para operaciones de cmputo
intensivo, como el procesamiento de seales y la administracin de equipo
controlado por el sistema.

2. Arquitecturas cliente servidor de dos niveles: es la forma ms simple de este tipo
de arquitecturas. El sistema se implementa como un solo servidor lgico ms un
nmero indefinido de clientes que usan dicho servidor.

mantenimiento

13
a. Cliente ligero: La capa de presentacin se implementa en el cliente y todas
las otras capas (gestin de datos, la aplicacin y base de datos) se
implementan en el servidor. Generalmente se utiliza un navegador Web
para presentar los datos en la computadora cliente.
b. Cliente pesado: el procesamiento de la aplicacin se realiza en el cliente.
Las funciones de gestin de datos y base de datos se implementan en el
servidor.

3. Arquitecturas cliente servidor multinivel: en esta arquitectura las diferentes capas
del sistema (presentacin, gestin de datos, procesamiento de aplicacin y base
de datos) son procesos separados que se pueden ejecutar en diferentes
procesadores. Por ejemplo una arquitectura clienteservidor de tres niveles
permite optimizar la transferencia de informacin entre el servidor Web y el
servidor de base de datos. La comunicacin entre estos puede usar rpidos
protocolos de intercambio de datos. Para manejar la recuperacin de informacin
de la base de datos, se usa el middleware que soporta consultas de base de datos
(SQL). El modelo cliente servidor de tres niveles puede extenderse a una
variante multinivel, donde se agregan servidores adicionales al sistema. Haciendo
uso del servidor Web para los datos y servidores separados para la aplicacin y
servicios de base de datos. O bien cuando se requiere tener acceso a datos de
diferentes bases de datos, en este caso conviene agregar un servidor de
integracin al sistema, para recolectar los datos distribuidos y presentarlos al
servidor de aplicacin como si fuera una sola base de datos.

Observa la siguiente tabla que se contiene el tipo de aplicaciones que soporta cada
tipo de arquitectura.

Tabla de tipos de patrones de arquitecturas
Arquitectura Aplicacin
Cliente servidor de
dos niveles con
clientes ligeros
Aplicaciones de cmputo intensivo, como compiladores
con poca o ninguna gestin de datos y aplicaciones web
con gestin de datos.
Cliente servidor de
dos niveles con
clientes pesados
Aplicaciones con software comercial por ejemplo
Microsoft Excel en el cliente, aplicaciones que requieran
procesamiento de datos intensivo y aplicaciones mviles
con aplicaciones por Internet o red local.
Cliente servidor
multinivel
Aplicaciones con miles de clientes, con datos y
aplicaciones voltiles. Se integran los datos
provenientes de diferentes fuentes.
.

mantenimiento

14
Existen otros tipos de arquitecturas que no se basan en capas, por ejemplo las
arquitecturas de componentes distribuidos y arquitecturas entre pares (peer to peer).
(Sommerville, Ian, 2011, pg. 485 - 495)

El diseo de la arquitectura del software es una de las vistas que describen cmo deber
ser construido. Otros aspectos del diseo de un software son los que tienen que ver con
la interaccin hombre mquina y el diseo de la interfaz, estos conceptos sern
abarcados en los siguientes temas.

Actividad 1. Interfaz
Despus de haber revisado los tipos de arquitecturas que se pueden disear para un
sistema de informacin. En el siguiente tema conocers aspectos de diseo de la
interaccin hombre mquina y el diseo de interfaces. Es por ello que a manera de
introduccin se te invita a participar en el foro con las opiniones que tengas sobre el tema.

El propsito de esta actividad es discutir los lineamientos para el diseo de una interfaz
del usuario.

Ingresa al aula virtual para realizar la actividad.

Instrucciones
2. De acuerdo a tu visin, Cules son los criterios que deben tomarse en cuenta para
disear una interfaz del usuario? Escribe por lo menos 5 criterios.
3. Contribuye con algn comentario por lo menos dos compaeros(as) y contesta al
menos algn comentario que te hayan realizado.

3.1.3. La interaccin Hombre-Mquina

En el contexto del diseo de software podemos entender a la interaccin como la relacin
dada entre el ser humano y la mquina a travs de una interface. Esta relacin produce
en el ser humano una extensin de sus capacidades por medio de las mquinas, gracias
a esta ventaja el ser humano logra realizar tareas que antes le ocasionaban rutina y le
hacan el trabajo ms complicado. El trmino mquina dentro de este tema se refiere a
computadoras, dispositivos, ordenadores incluso mviles, robots o cualquier equipo que el
sistema requiera.

Entonces podemos definir a la interaccin humanomquina como el estudio de la
interaccin entre la gente, los ordenadores y las tareas. De esta manera comprenders
como la gente y las computadoras interactan para lograr hacer tareas especficas.
Adems se atiende a la forma en que deben ser diseados y para lograr esto observa
algunos enfoques de esta rea:
mantenimiento

15

Interaccin hardwaresoftware
Diseo orientado al usuario
Modelos mentales del usuario y su relacin con el sistema.
Funciones del sistema y su adaptacin a las necesidades del usuario.
Su impacto en la organizacin.

La interaccin entre el humano y la computadora puede darse de varios modos
(multimodal); por ejemplo la mayora de los sistemas interactan con un usuario a travs
del monitor, teclado, ratn, bocinas, etc. De esta manera se abarcan varios canales de
comunicacin por medio de los sentidos humanos como lo son el tacto, la vista, el odo,
etc. Los sistemas actuales tienden a tener mltiples canales de comunicacin de
entrada/salida. Los humanos procesan informacin por varios canales de manera
simultnea. Y dadas estas caractersticas se logra una interaccin dimensional por el
concepto de mltiples funciones del ser humano.

Los estilos de interaccin ms importantes son (Sabatini, A. 2010, pg. 1):

Interfaz por lnea de rdenes: puede ser con teclas de funcin, abreviaciones
cortas, palabras completas, etc.
Mens y formularios: Los formularios contienen un grupo de elementos que
permiten al usuario introducir datos para que sea utilizada en la aplicacin, ya sea
que se almacene en alguna base de datos o se utilice directamente en funciones o
clculos del mismo software. Los mens son elementos agrupados como un
conjunto de opciones que el usuario puede seleccionar y al seleccionarse se
espera la ejecucin de alguna funcionalidad del sistema. Cuando los mens
ocupan mucho espacio se puede incluir mens desplegables o mens pop-up.
Manipulacin directa: sistemas con acciones rpidas que provocan efectos visibles
y claramente identificables en el objeto seleccionado. Por ejemplo ventanas,
conos, cursores, mens, etc.
Interaccin asistida: con asistentes o programas tipo agente que ayudan, leen la
entrada que el usuario presenta en la interface y pueden hacer cambios en los
objetos que el usuario ve en la pantalla. Los agentes son autnomos porque
pueden trabajar en un segundo plano, si as se les configura. Tienen inteligencia
por tener iniciativa y capacidad de adaptacin a mltiples situaciones. Son de uso
personal, ya que aprenden del usuario, sugieren sin imponer soluciones.

Estos son aspectos generales de la interaccin humanocomputadora, a continuacin
vers las caractersticas que se deben tomar en cuenta para su diseo. Al desarrollar la
etapa del diseo del software tambin se debe considerar como debe darse la interaccin
mantenimiento

16
de los usuarios y el software para lo cual se debe disear su interaccin, estudia el
siguiente tema:

3.1.4. Diseo de la interaccin

Considerando que la interaccin entre el usuario y un software se realiza principalmente
por medio de la interfaz, le llamamos mutuamente dependientes. Por lo tanto se abarcar
este tema realzando el diseo de la interfaz.

A continuacin se presentan una serie de principios relevantes para el diseo de
interfaces grficas efectivas. Se dice que una interfaz es efectiva cuando sta oculta al
usuario el funcionamiento del sistema. (Tognazzini, B. 2003, pg. 1)

Las aplicaciones deben anticiparse a las necesidades del usuario, no esperar a que el
usuario busque o recuerde informacin, la aplicacin debe ofrecer todas las
herramientas necesarias para cada etapa de su trabajo.
Se debe evitar llenar de restricciones al usuario, dejarle cierto nivel de autonoma para
que trabaje con confianza y logre el control del sistema. Pero es importante
mantenerle informado del estado del sistema y tenerlo siempre visible y actualizado.
Considerar a las personas que padecen el defecto gentico del daltonismo, por lo cual
no debe disear la transmisin de la informacin basada nicamente en el color.
Disear una aplicacin que funcione como lo espera el usuario, por ejemplo, s un
cono muestra cierta imagen, se espera que la accin realice algo relacionado con la
imagen. La nica manera de comprobar la consistencia es revisar las expectativas del
usuario y hacer pruebas de interfaz con ellos.
Considerar el diseo de campos de texto que contengan valores por defecto o
sugeridos, estos deben mostrarse seleccionados para que el usuario slo tenga que
teclear, borrar o escribir. Los valores que aparezcan por defecto deben tener sentido
con el dominio del campo.
Buscar la productividad del usuario y no de la mquina. El gasto ms alto de un
negocio es el trabajo humano. Cada vez que el usuario tiene que esperar la respuesta
del sistema, es dinero perdido. Escribe mensajes de ayuda concisos y que ayuden a
resolver el problema: un buen texto ayuda mucho en comprensin y eficacia. Los
mens y etiquetas deben comenzar con la palabra ms importante.
No se debe encerrar a usuario en una sola ruta, dejar varias posibilidades para que
ellos elijan como realizar su tarea. Permitir y facilitar que siempre pueda regresar al
inicio. Disear las acciones reversibles para que el usuario pueda experimentar, en
otras palabras permitir siempre la opcin deshacer.
Reducir el tiempo de espera con acciones como: efectos visuales al dar clic al botn,
mostrar reloj de arena animado para acciones entre medio y dos segundos, mostrar
mensaje o barra de estado en procesos que tarden ms de dos segundos, indicar con
mantenimiento

17
alarmas o pitidos cuando termine el proceso y el usuario pueda volver a tomar el
control del sistema.
Realizar diseos intuitivos cuyo tiempo de aprendizaje por parte del usuario sea
mnimo aproximndose al ideal de que los usuarios se sentaran frente al software y
supieran como utilizarlo. La usabilidad y facilidad de uso no son excluyentes, debes
decidir cul es la ms importante y luego implementa ambas.
El uso de metforas que evoquen lo familiar, pero con un nuevo punto de vista.
Utilizar texto con alto contraste. Por ejemplo negro sobre blanco o amarillo plido.
Evitar fondos grises cuando haya texto. El tamao de letra que sea legible en los
monitores ms comunes tomando en cuenta a los usuarios mayores, cuya visin suele
ser peor que la de los jvenes.
Administrar y mostrar los estados del sistema, por ejemplo cuando el usuario es la
primera vez que entra, ubicacin de la navegacin del usuario, a donde quiere ir,
histrico de navegacin en el sistema, cuando abandon la sesin el usuario.

Despus de haber conocido los principios relevantes para el diseo de interfaces
conocers la fase de codificacin, la cual lleva el peso de la construccin del software,
pues es donde se deben aplicar todos los modelos y principios generados en el anlisis y
diseo que hemos visto hasta este punto. Cualquier inconsistencia en las etapas previas a
la codificacin, se vern reflejadas en sta y cualquier cambio o nuevo requerimiento
identificado en esta fase involucrar modificar o aadir a lo ya previamente generado.
(Requerimientos definidos, diagramas de anlisis, diseo, etc.)

Actividad 2. Diseo de interfaz
En este subtema diseo del sistema se han revisado principios para disear un sistema
correctamente. Especficamente hemos visto el tema del diseo de la interaccin que nos
ayudar a definir algunos criterios para disear y/o evaluar la interaccin de las interfaces
de un sitio web.

El propsito de esta actividad es aplicar los criterios del diseo de la interaccin para
evaluar un sitio web.

Instrucciones: (trabajo individual)

1. Utiliza la siguiente estructura para completar la siguiente tabla en un archivo de Word.
Nombre del sitio web
Ubicacin del enlace web
# Criterio Si
cumple
No
cumple
Comentarios

mantenimiento

18

2. Elige un sitio web de tu preferencia y coloca su nombre en el encabezado de la tabla
as como su direccin electrnica.
3. De manera individual realiza la lista de al menos 5 criterios del diseo de la
interaccin.
4. Revisa cada criterio en el sitio y evala si lo cumple o no, marca una x segn sea el
caso. En la seccin de comentarios justifica cada evaluacin.
5. Guarda la actividad con el nombre IIS_U3_A2_XXYZ.
6. Enva el archivo a tu facilitador(a) para recibir retroalimentacin

3.2. Codificacin

Ahora veremos la fase de codificacin como parte del desarrollo de software. Esta etapa
implica desarrollar los programas que integrarn el software para resolver los
requerimientos que el cliente nos solicit. La manera de realizarlo normalmente es a
travs de mdulos que al trmino sern integrados en una sola unidad, el principal
entregable del proceso de desarrollo del software.

En esta etapa las acciones del algoritmo tienen que convertirse en instrucciones. Para
codificar un algoritmo tiene que conocerse la sintaxis del lenguaje al que se va a traducir.
La lgica del programa que indique las acciones y el orden en que se debe ejecutar. Por
lo tanto, es conveniente que todo programador aprenda a disear algoritmos antes de
pasar a la fase de codificacin.

En este tema encontrars aspectos importantes sobre el proceso de crear cdigo y
organizarlo de tal manera que vaya obteniendo el aspecto esperado por el usuario y
trazado en la etapa de diseo. As mismo que resuelva la funcionalidad solicitada en los
requerimientos del software. Comenzaremos con la traduccin del diseo a cdigo.
**
3.2.1. Traduccin de diseo a cdigo

En el proceso de traduccin y codificacin pueden aparecer inconsistencias de muchas
maneras y, la interpretacin equivocada de las especificaciones del diseo detallado,
puede conducir a un cdigo fuente errneo. La complejidad o las restricciones de un
lenguaje de programacin pueden conducir a un cdigo que sea difcil de probar y
mantener, es decir, las caractersticas de un lenguaje de programacin pueden influir en
la forma de pensar.

Para poder desarrollar cdigo se necesita un lenguaje de programacin que es un
lenguaje artificial que permite escribir instrucciones para indicar a una computadora lo que
tiene que hacer. Existen diversos tipos de lenguajes que se pueden clasificar en:
mquina, de bajo nivel y de alto nivel. El lenguaje mquina es el que est basado en
mantenimiento

19
ceros y unos (binario) es el lenguaje natural de la computadora. El lenguaje de bajo nivel
est basado en palabras reservada llamadas mnemotcnicos que ayudan a generar
operaciones que sern ejecutadas por el procesador. A este tipo de lenguajes se les llama
ensambladores y necesita un traductor para convertirlo al lenguaje mquina. Y por
ltimo, los lenguajes de alto nivel son los que se basan en un conjunto de palabras,
sintaxis y reglas muy parecidas al lenguaje natural del ser humano,ms fcil de
programar, sin embargo tambin necesitar ser traducido al lenguaje mquina-. De los
lenguajes de alto nivel se desprenden una gran variedad de lenguajes de programacin
que nos llevara otro curso comentar sus caractersticas, por lo tanto solo se mencionan
algunos: C, Java, C++, Lisp, Python, Ruby, html, javascript, prolog, etc. Para escoger el
lenguaje de programacin deberamos considerar los siguientes principios. (lvarez J.,
Arias M. 2002. pg. 1)

Respecto a los aspectos generales debemos buscar un lenguaje que: sea de alto
nivel, permita el uso de nombres significativos y creacin de mdulos y funciones,
utilice estructuras de control, se puedan declarar variables y tenga mtodos de
manejo de error.
Respecto a la funcionalidad, evaluar: el tamao del proyecto, conocimiento del
lenguaje por parte de los programadores, disponibilidad del software y
documentacin de ayuda, que funcione en varios sistemas operativos (en el caso
de que el cliente lo solicite), el tipo de aplicacin a desarrollar, complejidad de la
lgica y estructuras de datos necesarias.

Para definir un estilo de programacin principalmente se hace nfasis en la buena
escritura del cdigo, que sea auto descriptivo, lo cual se logra por medio de un adecuado
uso de nombres para variables, objetos, clases, arreglos y todo elemento que necesite ser
nombrado. Utilizar palabras que se relacionen con el contenido que almacenar dicho
elemento, por ejemplo un arreglo que contenga los das de la semana puede llamarse
dasDeLaSemana o una variable que almacenar temporalmente el resultado del total
de la venta puede llamarse ventaTotal. Adems debemos respetar las restricciones que
las reglas del lenguaje nos impongan para nombrar a los elementos que utilicemos.

Una buena prctica de programacin es aquella que utiliza los recursos crticos de forma
eficiente. La eficiencia es un requisito de todo sistema y se debe planear considerando los
siguientes aspectos: hacer expresiones lgicas y aritmticas ms simples, revisar si las
sentencias que estn repitindose en los ciclos estn correctas y deben repetirse. Evitar
el uso excesivo de arreglos multidimensionales, de apuntadores y listas complejas. No
mezclar tipos de datos, aunque el lenguaje lo permita, evitar declarar variables que no
sean utilizadas, minimizar el uso de peticiones de entrada / salida (E/S) y considerar si
algunos de los dispositivos de E/S puede afectar la calidad o velocidad.

mantenimiento

20
Como te has dado cuenta este proceso del paso del diseo a la codificacin debe ser
debidamente organizado. Ahora conocers las caractersticas necesarias para codificar la
interfaz.

3.2.2. Codificacin de la interfaz

La codificacin de la interfaz se refiere a la implementacin del diseo y a la aplicacin de
los estndares seleccionados para tal fin. El aprovechamiento de las nuevas tecnologas
nos facilita la velocidad de desarrollo, ya sea por el uso de generadores automticos de
interfaces, lenguajes de POO que permiten construir plantillas padre y heredar sus
atributos a diferentes plantillas hijo, permitiendo que los cambios sean ms sencillos de
realizar. En el mbito web encontramos herramientas de desarrollo tipo WYSIWYG es el
acrnimo de What You See Is What You Get (en espaol, "lo que ves es lo que
obtienes"); que ayudan al desarrollador a construir dinmicamente las interfaces para
internet. (Snchez, Javier, 2005, pg. 1)

Cada organizacin establece su propio proceso de construccin de interfaces que en
general podra ser similar al siguiente:

Codificacin de pantallas: para facilitar la interaccin entre el usuario y las funciones del
sistema. Los elementos que deben crearse son los mens, encabezados, rea de
mensajes, seccin del contenido, estndares de diseo.

Respecto al contenido de las pantallas este debe organizar: la informacin que se
mostrar, las validaciones ante posibles errores del usuario, los datos y sus relaciones, la
navegacin entre ventanas.

Generalmente se realizan formularios para introducir datos provenientes del usuario y por
ello es importante definir de una manera ms precisa a las validaciones. stas se
refieren a la comparacin de un valor esperado con el conjunto de valores que son
permitidos para cada campo. Por ejemplo la validacin de tipo revisar que el valor sea
numrico, cadena o fecha, segn el que se haya asignado para el dato. Otra validacin
puede ser la longitud, no deber permitir valores que sean menores o mayores a los
esperados. Y por ltimo la validacin de caracteres especiales no permitir que se
capturen caracteres que no sean los esperados. Si no activamos este proceso de
validacin estaremos permitiendo que el usuario introduzca datos imprecisos que se
vern reflejados en la salida de informacin poco confiable.

Y en el tema de informacin, sta deber ser presentada solo para los usuarios que
tengan la facultad para tenerla. Lo cual implica que deber programarse niveles de
mantenimiento

21
seguridad en el software, habilitando y limitando funciones de acuerdo a cada tipo de
usuario definido.

La programacin abarcar tambin aspectos grficos que contienen elementos que le
darn una imagen esttica al software y sern construidos con una adecuada distribucin
de colores, texto, imgenes, etc.

Y por ltimo la manera de navegar a travs del software generado, est y todos los
elementos anteriores debieron haber sido estratgicamente planeados en la etapa de
diseo. En esta etapa de codificacin nicamente se encargar de implementarlo con
cdigo aadiendo la funcionalidad previamente indicada.

Como podrs darte cuenta es necesario implementar un estndar para facilitar el proceso
de codificacin, tanto en el diseo de interfaces como en la forma de escribir el cdigo. A
continuacin veremos estrategias para administrar los estndares dentro de la
organizacin del desarrollo del software.

Actividad 3. Lineamientos de codificacin
Como viste en el tema de codificacin es importante organizar, mantener y aplicar una
serie de estndares que cada programador utilice en su cdigo. Con la finalidad de hacer
que el trabajo sea fcil de mantener por el programador o por algn otro compaero del
equipo. Cules podran ser esos lineamientos?, discute con tus compaeros en el foro.

El propsito de esta actividad es discutir lineamientos de codificacin que puedas
aplicar para el desarrollo del cdigo. Genera tu propia lista de estndares y comparte con
tus compaeros para complementarla con sus opiniones.

Ingresa al aula virtual para realizar la actividad.

Instrucciones
2. De acuerdo a tu criterio, Cules seran los lineamientos que te permitirn crear
cdigo bien escrito y fcil de entender? Realiza una lista de al menos 5 caractersticas
y comparte con tus compaeros.
3. Contribuye con algn comentario por lo menos dos compaeros(as) y contesta a
alguno de los comentarios que te hayan realizado.

3.2.3. Herramientas de desarrollo: gestin de la configuracin

Como ya habrs notado hasta este punto, son muchos procesos y demasiada informacin
que la que se genera durante las etapas del desarrollo de software, lo que hace
mantenimiento

22
necesario la gestin de la configuracin, por lo que es fcil perderse cuando existe un
cambio o se generan nuevas versiones por actualizacin. (Sommerville, Ian, 2011, pg.
682)

La administracin de la configuracin CM (Configuration Management) gestiona las
polticas, procesos y las herramientas para administrar los elementos cambiantes del
desarrollo de software. CM es til para el trabajo individual y en equipo. Al implementar
una administracin configurada se obtendrn los siguientes alcances:

1. Administracin del cambio: cuando se encuentra un cambio ya sea por parte del
equipo o del cliente es necesario realizar el anlisis de su impacto, estimar costos,
tiempos y decidir si se implementan o no.
2. Gestin de versiones: se refiere al seguimiento de las versiones de los elementos
del sistema y garantizar que los cambios o actualizaciones realizadas por
diferentes miembros del equipo no interfieran entre s.
3. Construccin del sistema: consiste en ensamblar los componentes del sistema,
datos y libreras y luego compilarlos para generar el ejecutable.
4. Gestin de entregas: Implica preparar el software para la entrega y hacer un
control de versiones de lo que se entreg al cliente.

La administracin de la configuracin implica una gran cantidad de informacin, por lo
cual se han generado muchas herramientas de gestin de documentos y administracin
de la configuracin.

Las herramientas de software que existen en el mercado para administrar versiones
son:

CVS, es una herramienta famosa por ser de uso libre, permite generar repositorios para
administrar los documentos que se generen en los proyectos. Favorece la administracin
de versiones, por ejemplo cuando se ha creado un archivo no podr renombrarse ni sobre
escribirse, cualquier cambio se guarda en una nueva versin, conservando las versiones
anteriores.

Subversion: es una herramienta de uso libre, fue creada para reemplazar al CVS,
y tambin funciona para llevar el control de las versiones de los documentos.
Genera una versin a nivel proyecto.
ClearCase: ayuda a facilitar el proceso del cambio, permite administrar los
documentos de manera confiable, flexible, es ptimo para equipos de desarrollo
grandes. Funciona en sistemas operativos Linux, Windows, Unix.
Darcs: es una herramienta de control de versiones para ambientes distribuidos.
Permite la generacin de puntos de restauracin para restablecer documentos con
versiones anteriores. Es muy til para los archivos que generan los
mantenimiento

23
desarrolladores de software, mantienen las versiones y se registran a los autores
de los cambios. Tiene una interfaz muy sencilla de usar.
Plastic SCM: es una herramienta de control de versiones para desarrollo
distribuido, funciona para sistemas operativos Windows, GNU/Linux Solaris, Mac
OS X, .Net/Mono. Es til para equipos grandes y ayudan a comprender el estado
del proyecto. Su principal caracterstica es que simplifica la ramificacin y fusin.

Establecer una adecuada estructura de trabajo con los estndares, polticas y
herramientas de gestin es muy importante para el logro del buen desempeo del equipo
de desarrollo. Facilitar a los desarrolladores herramientas que hagan su trabajo ms
sencillo y les agilice su labor, permitir que se puedan organizar la produccin generada
evitando prdidas de informacin, duplicidad de archivos y otros errores.

Las etapas que faltan por abarcar son la de pruebas y las de mantenimiento. Es
importante marcar la diferencia entre las etapas de codificacin y de pruebas, cada etapa
implica el desarrollo de cdigo sin embargo se corre el riesgo de que la etapa de
codificacin se extienda absorbiendo el tiempo de pruebas, lo cual se convertir un
problema si se lanza un producto que no fue probado adecuadamente. As mismo la
etapa de mantenimiento involucra codificar para realizar ajustes al software o la
generacin de cdigo nuevo para atender nuevas solicitudes de requerimientos. Es
importante que cada etapa tenga sus propios tiempos asignados y se respeten las
actividades planeadas para cada fase. Observa los siguientes temas para que consideres
las caractersticas de estas etapas.

3.3. Pruebas y mantenimiento
A continuacin vers el tema de pruebas, sus caractersticas y tipos de pruebas que se
pueden aplicar al desarrollo del software. Adems se incluyen sugerencias de
herramientas de software para administrar los documentos de pruebas, as como
herramientas que se utilizan para probar el cdigo generado.

Las pruebas tienen el objetivo de demostrar que un programa hace lo que se espera que
haga y descubrir los defectos que el programa tenga antes de usarlo. Al probar el
programa, ste se ejecuta con datos de ejemplo para verificar los resultados y revisar
errores en la informacin que arroje el programa. El proceso de prueba tiene 2 metas:

1. Demostrar al desarrollador y al cliente que el software cumple con los
requerimientos.
2. Encontrar situaciones vulnerables del software para evitar cadas del sistema,
clculos incorrectos o corrupcin de datos.

mantenimiento

24
Las pruebas no pueden demostrar que el software est exento de defectos o que se
comportar de alguna manera especfica en un momento dado. No es posible dejar con
cero defectos ya que es posible que el software no sea probado en todas las situaciones
probables. Dentro del proceso de pruebas existen dos procesos que normalmente se
confunden: verificacin y validacin. La validacin contesta la pregunta de
construimos el producto correcto? Y la verificacin responde a la pregunta construimos
bien el producto?

La finalidad de la verificacin es revisar que el software cumpla con la funcionalidad
esperada. La validacin es un proceso ms general, su meta es que el software cumpla
con las expectativas del cliente. Adems tambin existen los procesos de inspeccin que
se enfocan principalmente al cdigo fuente de un sistema. Cuando el sistema se
inspecciona se utiliza el conocimiento del sistema, del dominio de aplicacin y del
lenguaje de programacin para descubrir errores. Las inspecciones no substituyen las
pruebas de software, ya que no son eficaces para descubrir defectos que surjan por
interacciones entre diferentes partes de un programa. (Sommerville, Ian, 2011, pg. 206-
207)
/
A continuacin vers una clasificacin de los tipos de pruebas, as como las herramientas
que se utilizan para administrarlas e incluso probar cdigo, principalmente tenemos
pruebas enfocadas a los componentes que conforman al software y pruebas enfocadas al
software integrado.

3.3.1. Tipos de pruebas y herramientas

Por qu aplicar pruebas al cdigo? Principalmente porque el cdigo es un
modelo basado en un modelo humano, que adems es construido por humanos, por lo
que est expuesto a la generacin de errores y fallos imperceptibles. Inspeccionar
adecuadamente el producto puede ser la diferencia entre un software con calidad y uno
que no la tiene; por lo que realizar pruebas al software, es un proceso obligado para todo
equipo de desarrollo; as como inspeccionar la calidad del producto durante el proceso de
desarrollo, involucra diversas tareas que tienen relacin con el tipo de pruebas que se
hayan decidido aplicar. Las caractersticas del software nos indicarn que pruebas y
cuando debern aplicarse. Sommerville (2011, pg. 210-230) lo define de la siguiente
manera:

Tipos de prueba

Pruebas de desarrollo: son un proceso de prueba obligado, cuyo objetivo consiste en
descubrir errores en el software, generalmente estn entrelazadas con la depuracin:
localizar problemas con el cdigo y cambiar programas para corregirlos.
mantenimiento

25

Pruebas de unidad: para probar programas o clases. Sirven para comprobar la
funcionalidad de objetos o mtodos.
Pruebas del componente: se prueban las interfaces de los componentes.
Pruebas del sistema: se prueba la integracin de todos los componentes.

Pruebas de unidad: se encarga de probar componentes del programa, como mtodos o
clases de objetos. Se tienen que disear pruebas para revisar todas las operaciones
asociadas, establecer y verificar el valor de todos los atributos y poner el objeto en todos
los estados posibles.

Pruebas de componentes: se enfoca en demostrar que la interfaz de componente se
comporte segn la especificacin. Existen diferentes tipos de interfaz entre componentes
de programa y, en consecuencia, distintos tipos de error de interfaz. Por ejemplo:
Uso incorrecto de la interfaz.
Mala interpretacin de la interfaz.
Errores de temporizacin.

Pruebas del sistema: incluyen la integracin de los componentes y luego probar el
sistema completamente integrado. La prueba del sistema es un proceso colectivo ms
que individual. En algunas compaas, las pruebas del sistema implican un equipo de
prueba independiente, sin incluir diseadores ni programadores.

Pruebas de versin: sirven para poner a prueba una versin particular de un sistema que
se pretende usar fuera del equipo de desarrollo, generalmente esta versin es para
clientes y usuarios, sin embargo en proyectos muy grandes, una versin podra ser para
otros equipos que desarrollan sistemas relacionados. La principal meta de este tipo de
pruebas es convencer al proveedor del sistema de que: ste es suficientemente apto para
su uso. Si es as puede liberarse como producto o entregarse al cliente.

Pruebas basadas en requerimientos: Estas pruebas son de validacin ms que
defectos, se intenta demostrar que el sistema implement adecuadamente sus
requerimientos. Para esto es necesario escribir muchas pruebas para garantizar que
cubri los requerimientos.

Pruebas de escenario: son similares a las de versin, donde se crean escenarios que
generalmente suceden y se les utiliza en el desarrollo de casos de prueba para el
sistema. Un escenario es una historia que describe cmo puede utilizarse el sistema.
Estos deben ser realistas con usuarios reales. Si los escenarios fueron parte de los
elementos de tus requerimientos, entonces podra utilizarlos como escenarios de prueba.

mantenimiento

26
Pruebas de rendimiento: Se aplican cuando el sistema ha sido integrado
completamente, con ellas es posible probar el rendimiento y confiabilidad. Generalmente
consisten en aumentar la carga hasta que el sistema se vuelve inaceptable. Una manera
de descubrir defectos es disear pruebas sobre los lmites del sistema. En las pruebas de
rendimiento, significa estresar el sistema al hacer demandas que estn fuera de los
lmites del diseo del software. Esto se conoce como prueba de esfuerzo.

Pruebas de usuario: Este tipo de pruebas son necesarias por la influencia del entorno de
trabajo que tiene gran efecto sobre la fiabilidad, el rendimiento, el uso y la robustez de un
sistema. En la prctica existen tres tipos de pruebas de usuario:
Pruebas alfa: las realiza el usuario en presencia de personal de desarrollo del
proyecto haciendo uso de una mquina preparada para tal fin.
Pruebas beta: las realiza el usuario despus de que el equipo de desarrollo les
entregue una versin casi definitiva del producto.
Pruebas de aceptacin: son las nicas pruebas que son realizadas por los
usuarios, deciden si est o no listo para ser aceptado.

Dependiendo del tipo de prueba que se aplique, ser la dificultad o sencillez. (Para lograr
que las pruebas sean ms sencillas se pueden utilizar herramientas para probar cdigo).
Si utilizas software para administrar las pruebas podrs llevar un control ms preciso
sobre ellas, pues existen herramientas para desarrollar pruebas de software en todas las
etapas del desarrollo del sistema, estas soportan las pruebas y el desarrollo a lo largo del
ciclo de vida, desde la validacin de requerimientos hasta el soporte del funcionamiento
del sistema. Otras herramientas se enfocan en una sola parte del ciclo de vida. Por
ejemplo a continuacin veremos herramientas de software cuya funcin va orientada al
tipo de aplicacin. (Fernndez, A. 2012, pg. 1)

HP Unified Functional Testing. Es til para probar la interfaz grfica de las aplicaciones
de Java, Sap, Siebel, Visual Basic, .Net, Oracle, etc. Ayuda a la generacin de las
pruebas y su administracin. Adems de ser til para probar interfaz grfica, sirve para
otros mdulos. Se pueden crear escenarios de prueba. Ofrece un entorno de trabajo
sencillo de utilizar.

Selenium es una herramienta til para probar aplicaciones web, desarrolladas en C#,
Java, Groovy, Perl, PHP, Python y Ruby. Es multiplataforma ya que se puede usar en
Windows, Linux y MacOS, es gratis y opensource (cdigo fuente abierto). Adems se
puede encontrar mucha documentacin en Internet sobre cmo utilizarla.

Eggplant es una herramienta que se puede aplicar en diferentes plataformas como
Windows, MacOS y Linux, en otras palabras, no depende de ninguna ya que convierte a
la pantalla en imagen y aplicando la tecnologa de reconocimiento ptico de caracteres
(OCR) puede identificar imgenes y texto para su interpretacin. Su ambiente de trabajo
mantenimiento

27
es fcil de utilizar y ayuda en la automatizacin de pruebas de pantalla por medio de la
comparacin.

Ranorex es exclusiva para plataformas Windows, es capaz de identificar todos los
elementos de una aplicacin escritorio o web. Se basa en el reconocimiento de objetos y
tiene un ambiente de trabajo sencillo y fcil de aprender. Es un medio para desarrollar y
administrar desde las pruebas unitarias hasta los proyectos de prueba. Y permite la
depuracin del cdigo ya que cuenta con un editor.

TestComplete es una herramienta muy completa para hacer pruebas de software, pero
nicamente para la plataforma Windows. Los tipos de pruebas que se pueden gestionar
son de regresin, de cargas web, unitarias, etc. Su interfaz de desarrollo es muy completa
y se integra con las herramientas de Microsoft Visual Studio. Se pueden probar las
tecnologas de Visual Basic, Delphi, C++ y otras.

Microsoft Test Manager principalmente es una herramienta para la administracin y
automatizacin de pruebas y puede integrarse al kit de Microsoft Visual Studio. Los tipos
de pruebas que puede gestionar son unitarias, de interfaz de usuario, de base de datos,
de carga y genricas. Se debe utilizar otra herramienta Team Fundation Server para
almacenar casos de pruebas y requerimientos. Es para la plataforma Windows
exclusivamente.

3.3.2. Mantenimiento

Haber concluido con un proyecto de desarrollo de software, no implica que el software
haya llegado a su final, ya que como todo proceso, el paso del tiempo producir mejoras
ya sea por iniciativa, cambios tecnolgicos o por situaciones externas (gobierno,
instituciones, organizaciones), produciendo mejoras al software ya sea modificando lo
existente o agregando nuevos requerimientos. En este tema analizaremos el proceso de
mantenimiento al software.

El proceso de mantenimiento consiste en cambiar un sistema despus de que ste se
entreg; generalmente se aplica a software hecho a la medida y los cambios consisten
desde la simple correccin de errores, hasta mejoras significativas para corregir errores
de especificacin o bien, agregar nuevos requerimientos. Existen tres tipos de
mantenimiento de software:

1. Reparacin de fallas. Errores de codificacin, diseo o requerimientos, siendo
estos ltimos los ms costosos de corregir.
mantenimiento

28
2. Adaptacin ambiental. Es necesario cuando algn aspecto del entorno del
sistema como hardware, plataforma operativa o algn otro elemento hacer cambiar
al software. El sistema debe modificarse para que se adapte a dichos cambios.
3. Adicin de funcionalidad. Este tipo de mantenimiento es necesario cuando los
requerimientos funcionales cambian por algn factor organizacional o empresarial.
Generalmente este tipo de cambios es ms grande que los anteriores.

Como puedes darte cuenta, la adaptacin es una palabra clave en el proceso del
mantenimiento al software; ya que lo que se busca es hacer que ste se adapte cada vez
ms a la solucin de las necesidades del ser humano, por ello desde la reparacin de
fallas, los ajustes al contexto ambiental en el que se encuentra o simplemente agregarle
mayor funcionalidad, son actividades que convertirn al software en una verdadera
herramienta de trabajo para la humanidad.

Evidencia de aprendizaje: Tipos de pruebas y el proceso de
mantenimiento
Como habrs notado, existen muchos tipos de pruebas que pueden aplicarse al software
y estas dependen de lo que se quiera probar. Tambin el proceso del mantenimiento
puede ser variado y principalmente depende de la situacin de cada software en
particular. Por lo cual podemos decir que no existe una receta que pueda adaptarse a
todos los proyectos. A continuacin completa lo que se te indica para que de esta
manera puedas experimentar sto que se comenta.

Esta actividad tiene como propsito seleccionar criterios de pruebas y mantenimiento
para un caso de estudio.

Instrucciones.
1. De manera individual, analiza el caso de estudio dado por tu facilitador y describe los
tipos de prueba que estn utilizando. Justifica cada respuesta.
2. Adems analiza el proceso de mantenimiento que se sugiere en el caso de estudio y
describe a que tipo pertenece. Justifica tu respuesta.
3. En Word elabora un reporte con los resultados del paso 1 y 2.
4. Guarda la actividad con el nombre IIS_U3_EA_XXYZ.
6. Consulta tu escala de evaluacin.

Autorreflexiones

mantenimiento

29
presente, a partir de ellas, debes elaborar tu Autorreflexin en un archivo de texto llamado
XXX_UX_ATR_XXYZ. Posteriormente enva tu archivo mediante la herramienta
Autorreflexiones.

Cierre de la unidad

En el transcurso de la unidad has podido ver las etapas de diseo, codificacin y pruebas
que corresponden al proceso de desarrollo de software. Tambin conociste aspectos que
tienen relacin con el mantenimiento al software y los tipos que existen. Estos
conocimientos te sern de ayuda para entender el proceso de desarrollo de software y
podrs aplicarlos en tu ciclo personal de construccin de software, s es que trabajas de
manera independiente. Si formas parte de un equipo de desarrollo o en algn momento
formars parte de alguno, podrs ver reflejadas estas etapas del proceso del software y
los roles que aplican para cada fase. Estos temas te dan la visin de lo que implica
construir software de una manera organizada y ms certera al entender los conceptos que
la ingeniera de software propone.

Para saber ms

1) Ejemplos de Interaccin Humano-Mquina. Contiene ilustraciones y videos de
ejemplos de la interaccin humano mquina.
http://interfacemindbraincomputer.wetpaint.com/page/2.A.1.0.-
+Ejemplos+de+Interacci%C3%B3n+Humano+Maquina

2) Visita esta pgina, encontrars una plantilla de uso libre para realizar casos de
prueba. Se explica detalladamente cmo se realiza su llenado.
http://readyset.tigris.org/nonav/es/templates/test-case-format.

Fuentes de consulta

Bibliografa bsica
Pressman, R. (2010) Ingeniera de software. Espaa: Mcgraw-Hill Interamerican.
Sommerville, Ian (2011) Ingeniera de software. Mxico:Pearson Educacin.

Bibliografa complementaria
lvarez J., Arias M. (2002). Fase de implementacin. UNED.
http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node39.html
Fernndez, A. (2012) Comparativa de herramientas para pruebas automticas.
mantenimiento

30
Globe Testing. Espaa. http://www.globetesting.com/2012/03/comparativa-de-
herramientas-para-pruebas-automaticas/

Sabatini, A. (2010) Interaccin Humano Mquina. Buenos Aires, Argentina
http://interfacemindbraincomputer.wetpaint.com/page/1.A.1.1.-
+Meta+Proyecto+%28Interaction+-+Interface%29
Snchez, J. (2005) Metodologa para el diseo y desarrollo de interfaces de
usuario. http://pegasus.javeriana.edu.co/~fwj2ee/descargas/metodologia(v0.1).pdf
Tognazzini, B. (2003) First Principles of Interaction Design, E.U.
http://galinus.com/es/articulos/principios-diseno-de-interaccion.html

04 PD DS Iis PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

04 PD DS Iis PDF

Uploaded by

Copyright:

Available Formats

Introduccin a la Ingeniera de Software

Unidad 1. Ingeniera de Software

You might also like