UNIDAD I: INTRODUCCION

DEFINICIN DE SOFTWARE
Parte lgica de la informtica constituida por tres elementos
1. Instrucciones ejecutables que proporcionan la funcin y el comportamiento
deseado
2. Estructura de datos que facilitan a los programas manipular adecuadamente la
informacin.
3. Documentos que describen la operacin y el uso de los programas.
IMPORTANCIA DEL SOFTWARE.
Durante las tres primeras dcadas de la informtica, el principal desafo era el desarrollo
del ard!are de las computadoras. " lo largo de la dcada de los #$, los a%ances en
microelectrnica dieron como resultado una mayor potencia de clculo a la %e& que una
reduccin de costo. 'oy el principal desafo es me(orar la calidad )y reducir el costo* de
las soluciones que se implementan con el soft!are.
EVOLUCIN
Durante los pr!eros a"os el ard!are era de propsito general. +l soft!are se
dise,aba a medida para cada aplicacin, y tenia una distribucin relati%amente peque,a.
-a mayora del soft!are se desarrollaba y era utili&ado por la misma persona u
organi&acin. -a misma persona lo escriba, lo e(ecutaba y si fallaba, lo depuraba.
1
Debido a que la mo%ilidad en el traba(o era ba(a, los e(ecuti%os estaban seguros que esa
persona estara all cuando se encontrara alg.n error.
+l dise,o era un proceso implcito, y la documentacin normalmente no e/ista.
La se#un$a era en la e%olucin de los sistemas de computadora se e/tienden desde la
mitad de la dcada de los 0$ asta finales de los 1$. 2e caracteri& por la aparicin de3
La Multiprogramacin y sistemas multiusuarios: permitieron la e%olucin
)me(oras* de la interaccin ombre 4 maquina, permitiendo nue%as aplicaciones.
Sistemas de tiempo real: podan recoger, anali&ar y transformar datos de
m.ltiples fuentes, controlando as los procesos y produciendo salidas en
milisegundos.
Bases de Datos: -os a%ances en los dispositi%os de almacenamiento en lnea
condu(eron a la primera generacin de sistemas de gestin de base de datos.
Establecimiento del software como producto: +l soft!are se desarrollaba para
tener una amplia distribucin en un mercado multidisciplinario. -os programas
de distribuan para miles de usuarios. )5risis del 2oft!are3 dificultad en el
mantenimiento*
Ter%era era& comen& a mediados de los 1$ y continu ms all de una dcada.
Sistemas distribuidos: +l procesamiento distribuido )m.ltiples computadoras,
cada una e(ecutando funciones concurrentemente y comunicndose con alguna
otra* increment notablemente la comple(idad de los sistemas informticos. -as
redes de rea local y de rea global, las comunicaciones digitales, supusieron
gran presin sobre los desarrolladores.
'()* '(+*
Primeros ",os
,*** '((* '(-* '(.*
2egunda +ra
6ercera +ra
5uarta +ra
2
Incorporacin de inteligencia: -legada y amplio uso de microprocesadores y
computadoras personales. +l microprocesador es una parte integral de un amplio
espectro de productos 7inteligentes8. )+(. "utom%iles, robots, etc.*
Hardware de bajo costo: -as computadoras personales an sido el catali&ador de
crecimiento de mucas compa,as de soft!are. +l ard!are de las P5 se a
con%ertido rpidamente en un producto estndar, mientras que el soft!are que se
suministra con ese ard!are es lo que marca la diferencia. De eco, las %entas
de P5s se estabili&aron acia mitades de los #$ y las %entas de productos
soft!are continuaron creciendo.
Cuarta era se dirige al impacto colecti%o de las computadoras y del soft!are.
Sistemas personales potentes: Potentes maquinas personales controladas por
sistemas operati%os sofisticados, en redes globales y locales, acompa,adas por
aplicaciones de soft!are a%an&adas, se an con%ertido en la 9orma.
r!uitecturas inform"ticas descentrali#adas
E$pansin de Internet
La industria del software como cuna de la econom%a del mundo&
'ecnolog%as orientadas a objetos despla&an rpidamente los enfoques de
desarrollo de soft!are ms con%encionales en mucas reas de aplicaciones.
E(olucin de la inteligencia del software: -os sistemas e/pertos y los sistemas
de inteligencia artificial an entrado en aplicaciones prcticas de una gran
%ariedad de problemas del mundo real. )+(. :edes neuronales, artificiales, etc.*
3
IN/ENIER0A DEL SOFTWARE
Es el establecimiento y uso de principios de ingenier%a robustos) orientados a obtener
software econmico !ue sea fiable y funcione de manera eficiente sobre ma!uinas
reales&
Bauer
-a ingeniera del soft!are surge de la ingeniera de sistemas y la ingeniera de
ard!are. "barca un con(unto de tres elementos cla%e3
1. M1to$os3 indican 7cmo8 construir tcnicamente el soft!are. "barcan un
amplio espectro de tareas, que incluyen3
planificacin y estimacin de proyectos,
anlisis de requisitos del sistema y del soft!are,
dise,o de estructura de datos, arquitectura de programas y
procedimientos algortmicos,
codificacin,
prueba y mantenimiento.
;ntroducen frecuentemente una notacin especial orientada a un lengua(e, o
grfica.
2. 2erra!entas3 2uministran un soporte automtico o semiautomtico para los
mtodos. 'oy en da e/isten erramientas para cada uno de los mtodos
mencionados anteriormente. 5uando se integran las erramientas dan lugar a lo
que se conoce como 5"2+ )computer assisted system engineering o ingeniera
de sistemas asistida por computadoras*.
3. Pro%e$!entos3 2on los que unen los mtodos y las erramientas y facilita el
desarrollo racional y oportuno del soft!are de computadora. Definen la
secuencia en que se aplican los mtodos, los controles, cambios, etc.
-os cimientos que son la base de la ingeniera del soft!are estn orientados acia la
calidad.
-a ingeniera de soft!are est compuesta por una serie de pasos que abarcan los
mtodos, erramientas y procedimientos antes mencionados, que se denominan
para$#!as $e la n#ener3a $e so4t5are. +ste paradigma se elige de acuerdo a la
naturale&a del proyecto y de la aplicacin, de los mtodos y erramientas a usar y los
controles y entregas requeridos.
<
PARADI/MA DEL CICLO DE VIDA CL6SICO
+ste paradigma e/ige un enfoque sistemtico y secuencial del desarrollo de soft!are
que comien&a a ni%el de sistema, y progresa a tra%s del anlisis, dise,o, codificacin,
prueba y mantenimiento. "barca las siguientes acti%idades3
In#ener3a 7 an8lss $e sste!a3 debido a que el soft!are es una parte de un sistema
mayor, se comien&a estableciendo los requisitos de todos los elementos del sistema y
luego asignando al soft!are, alg.n subcon(unto de estos requisitos. +ste planteamiento
inicial es muy importante cuando el soft!are debe interrelacionarse con otros elementos
tales como ard!are, personas y bases de datos.
An8lss $e re9ustos $e so4t5are3 2e debe comprender el mbito de la informacin
del soft!are, as como la funcin, el rendimiento y las interfaces requeridas.
Dse"o3 +s un proceso multipaso que se enfoca sobre cuatro aspectos del soft!are3
-a estructura de datos
-a arquitectura del soft!are
Detalle procedimental
5aracteri&acin de la interfa&
+l proceso de dise,o traduce los requisitos de la etapa anterior en una representacin del
soft!are para que se pueda obtener la calidad requerida antes de la codificacin.
Co$4%a%:n3 2e transforma el dise,o en cdigo mquina, empleando un lengua(e
determinado de programacin.
Prue;a3 2e reali&a luego de la generacin del cogido. -a prueba se centra en la lgica
interna del soft!are y en las funciones e/ternas.
Manten!ento3 +s la etapa posterior a la distribucin del soft!are. Puede ocurrir por
di%ersos moti%os3 2e an encontrado errores que se deben corregir= el soft!are debe
adaptarse a cambios de su entorno= el cliente requiere la ampliacin de su funcionalidad.
+/isten cuestionamientos importantes para este paradigma3
1. :aramente el desarrollo de soft!are es estrictamente secuencial >as bien se
requiere de iteraciones en las diferentes etapas.
2. +s difcil para el cliente establecer todos los requisitos del soft!are inicialmente.
3. +l cliente debe tener paciencia. 9o es asta las etapas finales de este paradigma
cuando el cliente puede %er una %ersin operati%a del soft!are desarrollado.
?
PARADI/MA: DESARROLLO PROTOTIPADO DEL SOFTWARE
-a construccin de prototipos es un proceso que facilita al programador la creacin de
un modelo de soft!are a construir. +l modelo tomar una de las tres formas siguientes3
1. @n prototipo en papel o un modelo basado en P5 que describa la interaccin
'ombreAmaquina, de forma que facilite al usuario la comprensin de cmo se
producir tal interaccin.
2. @n prototipo que implemente algunos subcon(untos de la funcin requerida del
programa deseado
3. @n programa e/istente que e(ecute parte o toda la funcin deseada, pero que
tengan caractersticas que deban ser me(oradas en el nue%o traba(o de desarrollo.
-a construccin de prototipos comien&a con una primera recoleccin de
requisitos, definiendo ob(eti%os globales, identificando requisitos conocidos
y perfilando reas donde se necesitan mayor atencin.
-uego se reali&a un dise,o rpido, enfocndose sobre la representacin de
los aspectos %isibles del soft!are para el usuario )+(. >todos de entrada,
formatos de salida, etc.*
+ste dise,o conduce a la construccin de un prototipo, que es e%aluado por el
clienteBusuario. 2e utili&a para refinar los requisitos del soft!are a
desarrollar. De este modo, el prototipo se %a afinando con las diferentes
interacciones, y facilita la comprensin de lo que ay que acer. ;dealmente
el prototipo sir%e como mecanismo para identificar requisitos del soft!are
6ambin en este paradigma e/isten cuestionamientos importantes3
1. +l cliente %e funcionando lo que parece una primera %ersin del soft!are,
informndole que este debe ser reconstruido. Puede generar que este solicite
mucas me(oras a reali&ar, incorporando nue%os requisitos, y prolongando el
tiempo del proyecto.
2. +l tcnico de desarrollo, frecuentemente, impone ciertos compromisos de
implementacin con el fin de obtener un prototipo que funcione rpidamente.
+sto es un problema, ya que con el fin de acerlo funcionar puede acer uso
de erramientas no adecuadas, para luego familiari&arse con ellas, y lle%ar a
0
cabo el desarrollo con estas, siendo que en un principio las us para acelerar
la construccin del prototipo.
PARADI/MA: MODELO EN ESPIRAL
+ste modelo a sido creado para cubrir las me(ores caractersticas de los dos paradigmas
anteriores. Define cuatro acti%idades principales3
1. Planificacin3 determinacin de ob(eti%os, alternati%as y restricciones
2. "nlisis de riesgos3 "nlisis de alternati%as e identificacinBresolucin de
riesgos.
3. ;ngeniera3 Desarrollo del producto de 7siguiente ni%el8.
<. +%aluacin del cliente3 %aloracin de los resultados de la ingeniera
5on cada iteracin alrededor de la espiral, %o!en<an$o $el %entro =a%a a4uera& se
construyen sucesi%as %ersiones del soft!are, cada %e& ms completas.
Durante la primera %uelta se definen los ob(eti%os, las alternati%as y las restricciones, y
se identifican y anali&an riesgos. 2i el anlisis de riesgos indica que ay incertidumbre
en los requisitos, se puede usar la creacin de prototipos en el cuadrante de ingeniera.
+l cliente e%al.a el traba(o de ingeniera y sugiere modificaciones. +n base a estas, se
produce la siguiente fase de planificacin y anlisis de riesgos. +n cada bucle alrededor
de la espiral, la culminacin del anlisis de riesgo, resulta en una $e%s:n $e >se#ur o
no se#ur?. 2i los riesgos son demasiado altos, se puede dar por finali&ado el proyecto.
5ada %uelta en el espiral requiere ingeniera, que se puede lle%ar a cabo mediante el
enfoque de ciclo de %ida clsico o de la creacin de prototipos.
+ste paradigma3
@tili&a un enfoque e%oluti%o para la ingeniera de soft!are, permitiendo al
desarrollador y al cliente entender y reaccionar a los riesgos en cada ni%el
e%oluti%o.
@tili&a la creacin de prototipos como medio de reduccin del riesgo.
>antiene el enfoque sistemtico correspondiente a los del ciclo de %ida
clsico, pero incorporndola dentro de un marco de traba(o interacti%o que
refle(a de forma ms realista el mundo real.
Demanda una consideracin directa de los riesgos tcnicos en todas las
etapas del proyecto, y si se aplica adecuadamente, debe reducir los riesgos
antes que se transformen en problemas.
1
CARACTER0STICAS DEL SOFTWARE
+l soft!are es un elemento del sistema, que es lgico en lugar de fsico, por lo que tiene
caractersticas distintas a la del ard!are3
1. +l soft!are se desarrolla, no se construye en un sentido clsico3
2i bien e/isten algunas similitudes entre el desarrollo de soft!are y la
construccin del ard!are, ambas acti%idades son fundamentalmente diferentes.
+n ambas la buena calidad se adquiere mediante un buen dise,o, pero la fase de
construccin del ard!are puede introducir problemas de calidad que no e/isten
en el soft!are. "mbas acti%idades dependen de las personas. Poseen mtodos de
construccin diferentes.
-os costos del soft!are se encuentran en la ingeniera, por lo que los proyectos
de soft!are no se pueden gestionar como si fuesen proyectos de fabricacin.
2. +l soft!are no se 7estropea8, sino que se deteriora.
-a proporcin de fallos en funcin del tiempo del =ar$5are frecuentemente se
denomina cur%a de ba,era
)Dibu(ito de cur%a de ba,era*
;ndica que el ard!are e/ibe mucos fallos al principio de su %ida,
normalmente atribuibles por defectos de dise,o, una %e& corregidos la tasa de
fallos cae asta un ni%el estacionario. 5onforme pasa el tiempo, los fallos
%uel%en a presentarse a medida que los componentes del ard!are sufren los
efectos acumulati%os de la suciedad, malos tratos, etc.
+l soft!are no es susceptible a males del entorno. -os defectos no detectados
arn que falle el programa durante las primeras etapas de su %ida, sin embargo
una %e& corregidos y suponiendo que no se introducen nue%os errores, la cur%a
se aplana.
+n realidad, durante su %ida, el soft!are sufre cambios )mantenimiento*.
5onforme se acen los cambios, es bastante probable que se introdu&can nue%os
defectos, aciendo que la cur%a de fallos tenga picos. "ntes que la cur%a )CDqu
cur%aEF* pueda %ol%er al estado estacionario normal se solicita otro cambio
crendose otro pico. +l ni%el mnimo de fallos comien&a a crecer y el soft!are se
%a deteriorando debido a los cambios.
#
3. -a mayora del soft!are se construye a medida, en %e& de ensamblar
componentes e/istentes.
-os desarrolladores de soft!are no cuentan con componentes definidos que se
puedan comprar, para ensamblarse, y obtener el soft!are final. -o que s se
puede acer, es comprar soft!are ya desarrollado.
APLICACIONES DEL SOFTWARE
+l soft!are puede aplicarse en cualquier situacin en que se aya definido pre%iamente
un con(unto especfico de pasos procedimentales. -as siguientes reas del soft!are
indican la amplitud de las posibilidades de aplicacin3
2oft!are de sistemas3 con(unto de programas que an sido escritos para ser%ir a otros
programas. 2e caracteri&a por3
1. @na fuerte interaccin con el ard!are de computadoras.
2. @na gran utilidad por m.ltiples usuarios
3. Gperacin concurrente que requiere una aplicacin
<. @na comparticin de recursos y gestin de procesos
?. @nas estructuras de datos comple(as
0. >.ltiples interfaces e/ternas.
+(emplos3 compiladores, editores, utilidades de mane(os de perifricos, algunos
componentes de sistemas operati%os.
2oft!are de tiempo real3 es aquel soft!are que mide, anali&a, controla sucesos del
mundo real conforme ocurren.
;ncluyen3 un componente de adquisicin de datos que recolecta y da formato a la
informacin recibida del entorno e/terno, un componente de anlisis que transforma la
informacin, un componente de control de salida que responde al entorno, un
componente de monitori&acin que coordina todos los dems componentes. +n este tipo
de soft!are, el tiempo de respuesta es un factor crtico.
2oft!are de gestin3 +l procesamiento de informacin comercial constituye la mayor de
las reas de aplicacin del soft!are. -as aplicaciones en esta rea reestructuran los datos
e/istentes en orden a facilitar las operaciones comerciales o gestionar la toma de
decisiones. +(. Procesamiento de transacciones en punto de %enta, Data!areouse.
H
2oft!are de ingeniera y cientfico3 +sta caracteri&ado por los algoritmos de mane(o de
n.meros. -as aplicaciones %an desde la astronoma asta el anlisis de la presin de los
automotores.
2oft!are empotrado3 2on programas que residen en memoria de solo lectura, y se
utili&an para controla productos y sistemas de los mercados industriales y de consumo.
Pueden e(ecutar funciones muy limitadas y curiosas. )+(. 5ontrol de las teclas del
microondas* o suministrar una funcin significati%a y con capacidad de control
)sistemas de frenos, etc.*
2oft!are de computadoras personales3 "barcan el procesamiento de te/tos, o(as de
clculos, grficos por computadora, gestin de base de datos, aplicaciones financieras,
de negocio y personales.
2oft!are de inteligencia artificial3 ace uso de algoritmos no numricos para resol%er
problemas comple(os, para lo que no son adecuados el clculo o el anlisis directo. )+(.
:edes neuronales3 simula la estructura de proceso del cerebro*
CRISIS DEL SOFTWARE
Para el soft!are, la crisis a significado un lento cambio e%oluti%o. 6anto si se llama
crisis o mal de soft!are, los problemas no se limitan al soft!are que no funciona
correctamente, sino a aquellos problemas asociados a como desarrollar soft!are, como
mantener el %olumen cada %e& mayor de soft!are e/istente y como poder esperar
mantenernos al corriente de la demanda e/istente de soft!are
Problemas
-os problemas que afligen al desarrollo de soft!are se centran en los siguientes
aspectos3
1. -a planificacin y estimacin de costos imprecisos
2. -a producti%idad de la comunidad del soft!are no corresponde con la
demanda de sus ser%icios
3. -a calidad del soft!are no llega a ser a %eces ni siquiera aceptable.
1$
6ales problemas son solo las manifestaciones ms %isibles de otras dificultades del
soft!are3
Ialta de tiempo para recoger datos sobre el proceso de desarrollo de
soft!are
;nsatisfaccin del cliente con el sistema terminado por causa de una
comunicacin escasa, lo que se produce con frecuencia.
-a calidad del soft!are es normalmente cuestionable.
+l soft!are e/istente puede ser muy difcil de mantener
Causas $e la %rss $e so4t5are
-as causas de la crisis del soft!are residen en la naturale&a del mismo. +s decir, esta
parte de la informtica cuya esencia es lgica, se mide por la calidad de una sola
entidad, en %e& de medirse la calidad por los componentes fsicos que se ensamblan.
Por otra parte, el desarrollo de soft!are presenta un gran desafo intelectual, y sus fallas,
por ende son causadas por fallas umanas.
9o se an aplicado tcnicas de desarrollo de soft!are. +l producto es ms bien
artesanal, con todos los problemas que esto trae. +n mucos casos las personas
desarrollan un mtodo ordenado y eficiente de desarrollo del soft!are mediante prueba
y error. Pero en otros, no e/iste tal mtodo y dan como resultado una pobre calidad y
mantenibilidad del soft!are.
6ambin se pueden %er las causas de la crisis del soft!are, refle(ados en los mitos
surgidos en los primeros a,os de %ida del soft!are.
MITOS DEL SOFTWARE
+stos mitos surgieron de acontecimientos, tu%ieron un sentido intuiti%o y
frecuentemente fueron promulgados por e/pertos que estaban al da.
'oy se consideran a estos mitos por lo que son3 actitudes errneas que an causado
serios problemas, tanto a los gestores como a los tcnicos.
Mtos $e #est:n
>ito3 +/isten libros llenos de estndares y procedimientos para construir
soft!are. C9o le proporciona ya a mi gente todo lo que necesita saberE
11
:ealidad3 -a pregunta debera ser si es que se usa, si es que los traba(adores de
soft!are conocen de su e/istencia, si est completo. -a mayora de las respuestas a esta
pregunta es 9G.
>ito3 >i gente dispone de las erramientas d desarrollo de soft!are ms
a%an&adas= les compramos las computadoras ms modernas.
:ealidad3 2e necesita muco ms que tecnologa ard!are para acer desarrollo
de soft!are de gran calidad.
>ito3 2i fallamos en la planificacin, podemos agregar ms programadores y
adelantar el tiempo perdido.
:ealidad3 +l desarrollo de soft!are no es un proceso mecnico como la
fabricacin. 2i se a,ade ms gente al proyecto, se lo retrasa ms, porque necesitaran
aprender sobre el proyecto y comunicarse con el equipo, lo cual lle%a tiempo.
Mtos $el %lente
>ito3 @na declaracin general de los ob(eti%os es suficiente para comen&ar a
escribir los programas= podemos dar los detalles ms adelante.
:ealidad3 @na mala definicin inicial es causa de mucos problemas en el
proceso de desarrollo de soft!are. +s necesaria una descripcin detallada del mbito de
la informacin, las funciones, rendimiento, interfaces, ligaduras de dise,o y criterios de
%alidacin. Debe aber entonces, una alta comunicacin entre el cliente y el analista.
>ito3 -os requisitos del proyecto cambian continuamente, pero los cambios
pueden acomodarse fcilmente, ya que el soft!are es fle/ible.
:ealidad3 +s %erdad que los requisitos cambian, pero el impacto del cambio
%ara seg.n el momento en que se introdu&ca.
o 2i se pone cuidado al dar la definicin inicial, los cambios solicitados al
principio pueden acomodarse fcilmente, con poco impacto en el coste.
o 5uando los cambios se solicitan durante el dise,o del soft!are, el
impacto del coste crece rpidamente. :equieren modificaciones
importantes en el dise,o )funcin, rendimiento, interfaces, etc.*
o 5uando se solicitan al final del proyecto, los cambios pueden producir un
orden de magnitud ms caro que el mismo cambio pedido al principio.
Mto $e los $esarrolla$ores
>ito3 @na %e& que escribimos el programa y acemos que funcione, nuestro
traba(o a terminado.
12
:ealidad3 -os datos industriales indican que entre el ?$J y el 1$J de todo el
esfuer&o dedicado a un programa se reali&ar despus de que se le aya entregado al
cliente por primera %e&.
>ito3 'asta que no tengo el programa 7e(ecutndose8, realmente no tengo forma
de comprobar su calidad.
:ealidad3 Desde el principio del proyecto, se puede aplicar un mecanismo muy
efecti%o para garanti&ar la calidad del soft!are3 la re%isin tcnica formal.
>ito3 -o .nico que se entrega al terminar el proyecto es el programa
funcionando.
:ealidad3 @n programa que funciona es solo una parte de una configuracin del
soft!are que incluye programas, documentos y datos. -a documentacin es la base de
un buen desarrollo y, lo que es ms importante, proporciona guas para la tarea de
mantenimiento del soft!are.
CALIDAD DEL SOFTWARE @ FACTORES AUE LA AFECTAN
+l ob(eti%o primordial de la ingeniera de soft!are es producir un sistema, aplicacin o
producto de alta calidad. Para lograr este ob(eti%o, los ingenieros de soft!are deben
aplicar mtodos efecti%os (unto con erramientas modernas dentro del conte/to de un
proceso maduro de desarrollo de soft!are.
-a calidad de un sistema, aplicacin o producto es tan buena como los requisitos que
describen el problema, el dise,o que modela la solucin, el cdigo que conduce a un
programa e(ecutable y las pruebas que e(ercitan el soft!are para detectar errores. @n
buen ingeniero utili&a mediciones que e%al.an la calidad del anlisis y los modelos de
dise,o, el cdigo fuente y los casos de prueba que se an creado al aplicar la ingeniera
de soft!are.
Fa%tores 9ue a4e%tan la %al$a$
-os factores que afectan la calidad del soft!are se pueden caracteri&ar en3
1. Gperacin del producto )utili&ndolo*3
5orreccin
Iiabilidad
@sabilidad )facilidad de mane(o*
;ntegridad
+ficiencia
13
2. :e%isin del producto )cambindolo*
Iacilidad de mantenimiento
Ile/ibilidad
Iacilidad de prueba
3. 6ransicin del producto )modificndolo para que funcione en un entorno
diferente*
Portabilidad
:eusabilidad )capacidad de reutili&acin*
;nteroperatibilidad
1<
UNIDAD II: PRO@ECTOS DE DESARROLLO DE SOFTWARE
PRO@ECTO. DEFINICIN
+s una accin iniciada por la empresa en la que recursos umanos, financieros y
materiales se organi&an de una nue%a forma para acometer un traba(o .nico, en el que
dada unas especificaciones y dentro de unas limitaciones en costo y tiempo, se intenta
conseguir un cambio beneficioso, definido por unos ob(eti%os cualitati%os y
cuantitati%os.
+l aspecto esencial de un proyecto es el de ser un traba(o .nico que se reali&a con una
nue%a organi&acin para producir un cambio beneficioso. +sto conlle%a a una
incertidumbre considerable.
6odo proyecto tiene un lder que tiene responsabilidades que acen al lidera&go del
proyecto es decir inter%ienen las capacidades de este para administrar los recursos
limitados en forma eficiente.
6ipos de recursos3
'umanos3 capacidades necesarias de las personas.
Isicos3 +quipamiento necesario )'ard!are, soft!are, muebles, etc.*
5onocimiento3 los necesarios que in%olucran el proyecto )cursos de
capacitacin*
Iinancieros3 se %e determinado en parte por los anteriores puntos.
6emporal3 6iempo del que se dispone.
ESPECTRO DE LA /ESTIN
1?
-a gestin de proyectos se define como el sistema de procedimientos, practicas,
tecnologas y conocimientos que facilitan la planificacin, organi&acin, gestin de
recursos umanos, direccin y control necesarios para que el proyecto termine con
/ito.
-a gestin efica& de un proyecto de soft!are se centra en las personas, en el problema y
en el proceso.
Personal3 -as reas prcticas cla%es para el personal que desarrolla soft!are
son3 reclutamiento, seleccin, gestin de rendimiento, entrenamiento,
retribucin, desarrollo de la carrera, dise,o de la organi&acin y del traba(o,
y desarrollo cultural y de espritu de equipo.
Problema3 "ntes de planificar un proyecto se deben establecer sus ob(eti%os
y su mbito, se deben considerar soluciones alternati%as e identificar
dificultades tcnicas y de gestin. 2in esta informacin es imposible definir
estimaciones ra&onables de costo, una %aloracin efecti%a del riesgo, una
subdi%isin de las reas del proyecto o una planificacin del proyecto tal que
proporcione una indicacin fiable del progreso.
+l proceso3 @n proceso de soft!are proporciona la estructura desde la cual
se puede establecer un detallado plan para el desarrollo del soft!are.
1. @n peque,o n.mero de acti%idades estructurales se pueden aplicar a todos
los proyectos de soft!are, sin tener en cuenta su tama,o y comple(idad.
10
2. Diferentes con(untos de tareas )tareas, itos, entregas y garantas de calidad*
permiten a las acti%idades estructurales adaptarse a las caractersticas del
proyecto de soft!are y a los requisitos del equipo del proyecto.
3. -as acti%idades protectoras )garanta de calidad de soft!are, gestin de la
calidad de soft!are y medicin* cubren el modelo de proceso.
-a gestin de un proyecto incluye conceptos cla%es, como ser3
Kmbito3 relacionado con el alcance del proyecto, es decir determinarlo, estableciendo el
ob(eti%o, dentro de la planificacin.
>tricas3 medidas que sir%en para la gestin de proyecto. 2eguimiento del proyecto
)5ostos, tiempo, producti%idad, cantidad de errores, etc.*
+stimacin3 "signacin de un %alor a una realidad con cierto grado de incertidumbre. 2e
utili&a muco para planificar.
Planificar3 +laborar un plan de accin para alcan&ar un ob(eti%o y asignarle los recursos
necesarios para que se puedan e(ecutar.
Lestin de riesgo3 Dirigir o atender un riesgo para que no se concrete. -a gestin de
riesgo significa colocar ba(o control los riesgos, e%itando que se transformen en
problemas )plan de contingencias*.
CAUSAS DE INICIO DE UN PRO@ECTO
Por problemas en la organi&acin
Para $ent4%ar pro;le!as Bus9ue estos s#nos espe%34%os
:e%ise la salida contra los
criterios de desempe,o
Demasiados errores
6raba(o terminado lentamente
6raba(o eco incorrectamente
6raba(o eco de forma incompleta
Gbser%e el comportamiento de
los empleados
"lto ausentismo
"lta insatisfaccin en el traba(o
"lta rotacin de personal
+scuce retroalimentacin
e/terna de %endedores, clientes
y pro%eedores
Mue(as
2ugerencias de me(oras
Perdidas de %entas
11
Por oportunidades de me(ora
Oportun$a$es $e !eCora %o!unes
"celeracin de un proceso
"gili&acin de un proceso mediante la
eliminacin de pasos innecesarios o duplicados
5ombinacin de procesos
:educcin de errores en la entrada por medio de
cambios de formas de pantallas
:educcin de salida redundante
>e(ora en la integracin de sistemas y
subsistemas
>e(ora en la satisfaccin del traba(ador con la
utili&acin del sistema
>e(ora de la facilidad de interaccin de los
clientes, pro%eedores y %endedores con el
sistema
CLASIFICACIN DE LOS REAUERIMIENTOS
ESTUDIO DE FACTIBILIDAD
-a factibilidad significa que el proyecto propuesto3
"yuda a la organi&acin a lograr sus ob(eti%os.
+s posible de lograr con los recursos actuales de la organi&acin
1. Iactibilidad tcnica3 +studio de la funcionalidad, el rendimiento, las
restricciones que pueden afectar a la posibilidad de reali&acin de un sistema
aceptable )2i la idea es tcnicamente posible*.
2. Iactibilidad econmica3 @na e%aluacin del costo de desarrollo frente al
beneficio final producido por el sistema desarrollado.
3. Iactibilidad operacional3 @n estudio para determinar si el sistema podr
emplearse cuando est desarrollado.
<. Iactibilidad legal3 @na determinacin de cualquier infraccin o ilegalidad que
pudiere resultar del desarrollo del sistema.
?. Iactibilidad ambiental3 +studio del impacto ambiental )desecos e insumos*
0. Iactibilidad socioApoltica3 5mo afecta a la %ida social en las cercanas.
1#
2i las factibilidades no se dan positi%amente, se debe a(ustar, modificar, asta
obtener algo me(or.
AN6LISIS COSTO D BENEFICIO
6iene como ob(eti%o que los beneficios que se esperan obtener con el nue%o sistema
superan a los costos esperados.
+l anlisis costo beneficio determina los costos para el desarrollo y los pondera con
los beneficios tangibles )por e(emplo, medible directamente en dinero* y beneficios
intangibles.
+l anlisis costo beneficio es complicado por criterios que %aran con las
caractersticas del sistema a desarrollar, el tama,o relati%o del proyecto y los
beneficios esperados de la in%ersin como parte del plan estratgico de la compa,a.
"dems, mucos beneficios obtenidos de los sistemas basados en computadoras son
intangibles.
Neneficios tangibles3 Oenta(as medibles en pesos. +(. Oelocidad de procesamiento,
me(ora de clculo, disminucin de tiempo de usuario, etc..
Neneficios intangibles3 >e(ora de proceso de toma de decisiones, aumento de la
precisin, ser%icio ms competiti%o, imagen del negocio, etc.
5ostos tangibles3 5ostos de equipo, costos de mano de obra. :equieren de
desembolso de efecti%o.
5ostos intangibles. Perdida de una %enta(a competiti%a, perdida de reputacin por
ser el primero con una inno%acin, etc.
Co!para%:n $e %ostos 7 ;ene4%os
1H
"nlisis de punto de equilibrio3 5omparando solo los costos, el punto de
interseccin indica el momento a partir del cual llega a ser rentable el nue%o
sistema de informacin. 5onsidera a los beneficios fi(os en un %alor.
-a grafica muestra que con el nue%o sistema se aceleran las %entas y se puede llegar a
%ender ms con un costo no tan ele%ado, ni tan ba(o como el antiguo sistema.
2i las unidades de %entas son inferiores no con%iene reali&ar el cambio de sistema, ya
que no se (ustifica el costo de implementacin del nue%o sistema.
2$
An8lss $e Re%upera%:n
>uestra en forma simple cunto tiempo le lle%ar a los beneficios del sistema pagar los
costos de su desarrollo.
+/isten proyectos en donde las cur%as nunca se cru&an. 2e dice que despus de tres a,os
el tiempo de recuperacin es demasiado. 2e debe pensar en dos a,os.
21
An8lss $e FluCo $e E4e%tEo
2e usa para determinar cundo comen&ar a tener ganancias la organi&acin y cundo
de(ar de 7estar en ro(o8 respecto a los costos de desarrollo.
-os datos son predicciones, y se debe tener en cuenta la coti&acin de la moneda
)posibles de%aluaciones*.
An8lss $e Ealor presente
+s una forma de %alorar todos los desembolsos y ganancias econmicas del 2.;. " lo
largo de su %ida econmica y de comparar los costos actuales con los futuros y los
beneficios actuales con los futuros.
Ao 1 Ao 2
Trim. 1 Trim. 2 Trim. 3 Trim. 4 Trim. 1
Ganancias
Desarrollo Soft
Personal
Capacitacin
Alquiler Har
!nsumos
"antenimiento
Costo Total
#lu$o e %fecti&o
#lu$o e %fecti&o Acumulao
5,000 20,000 24,960 31,270 39,020
10,000
8,000
3,000
4,000
1,000
26,000
5,000
8,400
6,000
4,000
2,000
2,000
27,400
8,800
4,000 4,000 4,000
9,260 9,700
2,370 2,990 3,730
2,200 2,420 2,660
17,370 18,670 20,090
-21,000 -7,400 7,590 12,600 18,930
-21,000 -28,400 -20,810 -8,210 10,720
Ao
1 2 3 4 ' ( Total
Costos
Valor presente de beneficios
Factor
Beneficios
Valor presente de los costos
Factor
40,000 42,000 44,100 46,300 48,600 51,000
89 80 71 64 57 51
35600 33600 31311 29,632 27,702 26,010 183,855
25,000
89
22,250
31,200 39,000 48,700 60,800 76,000
80 71 64 57 51
24,960 27,960 31,168 34,656 38,760 179,484
#rmula) 1 * + 1 , i - . n
!"e#plo con i $ 012
1 2 3 4 ' ( Total
Ao
Costos
/eneficios
40,000
25,000
42,000
31,200
44,100
39,000
46,300
48,700
48,600
60,800
51,000
76,000
272,000
280,700
!"e#plo sin considerar
Valor %resente
22
Para este e(emplo en particular lo me(or es colocar el dinero en el banco ya que el %alor
presente de os beneficios es menor que los costos, por lo que el proyecto no se
considera bueno.
ALCANCE DEL SISTEMA
+l alcance del proyecto ace referencia a determinados procesos que aseguran que el
proyecto incluye todo el traba(o requerido, y solo el traba(o requerido, para alcan&ar los
ob(eti%os.
23
UNIDAD III: MFTRICAS @ ESTIMACIN EN EL PRO@ECTO
INTRODUCCIN
Durante mucos a,os el proceso de desarrollo de soft!are se consider un arte en
manos del (efe de proyecto, resignndose la determinacin de tiempo y costo, como si
no fueran posibles de determinar.
2i e/istan estimaciones se acan solo al inicio del proyecto, pero con tal ambigPedad
que era imposible controlar el a%ance del proyecto basndose en ellas.
5onforme los costos de desarrollo y mantenimiento de soft!are crecen, es necesario
predecirlos y controlarlos. +sto es algo muy difcil de reali&ar.
-as cla%es del /ito en la gestin del desarrollo de soft!are son3 una adecuada gestin
del proyecto de desarrollo y una adecuada gestin del proceso de soft!are.
+/isten tres tareas a reali&ar por el director de proyectos que son crticas, y que deben
ser desarrolladas correctamente si se desea que el proyecto termine bien3
+stimacin de duracin, costo y esfuer&o3 2e define como el proceso que
proporciona un %alor a un con(unto de %ariables para la reali&acin de un
traba(o, dentro de un rango aceptable de tolerancia. +s decir, incorporar
conceptos cientficos para no depender totalmente de la e/periencia o
intuicin de la persona en el desarrollo de un proyecto.
2<
Planificacin de tareas a reali&ar, asignacin de personas, tiempos, etc., para
construir el producto. 2e define como el proceso de seleccin de una
estrategia para la construccin de unos productos finales dados, as como la
definicin de las acti%idades a reali&ar, para conseguir ese ob(eti%o, la
concurrencia y solapamiento de dicas acti%idades. 6ambin se deben
asignar recursos a las acti%idades en funcin del plan establecido.
2eguimiento durante la reali&acin del traba(o. +n caso de des%iaciones se
deben tomar medidas correcti%as. +s la recoleccin de datos y su
almacenamiento sobre tiempos, recursos, costos, e itos asociados con un
proyecto, para el anlisis y estudio de la e%olucin real de dico proyecto,
comparando el proceso real con el programado.
+stas acti%idades tienen una fuerte relacin entre s.
Dentro de la gestin de proyecto se pueden identificar las tareas mencionadas en el
grafico anterior.
+l primer paso de la gestin del proyecto de soft!are es reali&ar la planificacin del
mismo. Para lle%arlo a cabo seg.n buenas prcticas de ingeniera, se deben reali&ar
estimaciones, de modo que el grado de incertidumbre sea menor para esta etapa de
gestin.
2?
%stimacin
Planificacin
Desarrollo
Se0uimiento
@na %e& planificado, se procede al desarrollo del proyecto, que es poner en prctica las
acti%idades definidas en el paso anterior. "dems, se debe planificar el seguimiento a
reali&ar cuando se proceda a la e(ecucin del proyecto.
" la etapa de desarrollo se le debe aplicar un continuo seguimiento, para asegurar que lo
planificado se corresponda con lo que realmente se est lle%ando a cabo. De este modo,
se contribuye a la calidad del mismo.
"l e(ecutarse el proyecto y su correspondiente seguimiento, se pueden producir
des%iaciones de distinta importancia o incidencia en el proyecto. 2i estos des%os son
le%es, se proceder a reali&ar los a(ustes necesarios en la planificacin, para que el
mismo se encauce nue%amente de acuerdo a los ob(eti%os establecidos. 2i los des%os
son importantes, se deber re%isar y redefinir las estimaciones sobre las cuales se bas
la planificacin. +sto dar lugar, a la consiguiente correccin de la planificacin.
+n el proceso de seguimiento, se pueden recolectar mtricas tanto del producto como
del proceso, que ser%irn como datos istricos para lle%ar a cabo estimaciones en
futuros proyectos.
MEDIDAS& MFTRICAS E INDICADORES
Dentro del conte/to de la ingeniera del soft!are, una !e$$a proporciona una
indicacin cuantitati%a de e/tensin, cantidad, dimensiones, capacidad y tama,o de
algunos atributos de un proceso o producto
@na !1tr%a )seg.n el ;+++* se define como una medida cuantitati%a del grado en que
un sistema, componente o proceso posee un atributo dado. :elata de alguna forma, las
medidas indi%iduales sobre alg.n aspecto, +(. +l numero medio encontrado por
re%isin.
-a !e$%:n es resultado de la recopilacin de uno o %arios aspectos de los datos. +(. 2e
in%estiga un n.mero de re%isiones de mdulos para recopilar del n.mero de errores
encontrados.
@n ingeniero de soft!are recopila medidas y desarrolla mtricas para obtener
indicadores. @n indicador es una mtrica o una combinacin de mtricas que
proporcionan una %isin profunda del proceso de soft!are, del proyecto de soft!are o
del producto en s. Proporciona una %isin profunda que permite al gestor de proyecto o
a los ingenieros de soft!are a(ustar el proceso, el proyecto o el producto para que las
cosas salgan me(or.
20
MFTRICAS DEL PRO@ECTO
-as mtricas de soft!are pretenden me(orar los procesos de desarrollo de soft!are, y
me(orar por tanto, todos los aspectos de la gestin de aquellos procesos. +stas medidas
son aplicables en todo el ciclo de %ida. ;ncluyen la aplicacin de tcnicas para detectar y
corregir anticipadamente los errores de los distintos componentes de los productos antes
de llegar a la codificacin.
"dems las mtricas controlan el progreso del proyecto de tal manera que lo que pueda
ocurrir %arios meses ms tarde, se puede identificar tan pronto como sea posible.
Clas4%a%:n $e !1tr%as
+/isten mucas ra&ones por las cuales medir el soft!are3
1. Para indicar la calidad del producto
2. Para e%aluar la producti%idad de la gente que desarrolla el producto
3. Para e%aluar los beneficios )en trminos de producti%idad y calidad* deri%ado
del uso de nue%os mtodos y erramientas de ingeniera de soft!are
<. Para establecer una lnea base para la estimacin
?. Para ayudar a (ustificar el uso de nue%as erramientas o de formacin adicional.
2e puede reali&ar la siguiente categori&acin3
M1tr%as $e Pro$u%to3 son medidas del producto soft!are durante cualquier fase de su
desarrollo, desde los requisitos asta su instalacin.
M1tr%as $e Pro%eso )"cti%idades que las personas e(ecutan para modelar un
producto*3 son medidas del proceso de desarrollo del soft!are tales como tiempo de
desarrollo total, esfuer&o en dasBombre de desarrollo del producto, tipo de
metodologa utili&ada o ni%el medio de e/periencia de los programadores.
M1tr%as o;CetEas: deberan tener siempre un %alor igual para una medida dada
M1tr%as su;CetEas: aun obser%adores calificados podran incluir diferentes %alores
para una medida dada.
M1tr%as $re%tas: pueden ser obser%adas directamente, tales como lneas de cdigo,
n.mero de defectos.
M1tr%as In$re%tas: son aquellas que no pueden ser obser%adas directamente, sino que
se obtienen a partir de otras, tales como producti%idad )traba(o .til por tiempo* o
calidad.
21
MFTRICAS PARA LA PRODUCTIVIDAD @ LA CALIDAD DEL SOFTWARE
-as mtricas del soft!are se refieren a un amplio rango de medidas para el soft!are de
computadoras. Dentro del conte/to de la planificacin del proyecto soft!are, son
importantes las mtricas de producti%idad y calidad, que miden el rendimiento de la
7salida8 del desarrollo del soft!are como funcin del esfuer&o aplicado. Para los
propsitos de la planificacin y de la estimacin, nuestro inters es istrico )Proyectos
pasados, calidad, comparacin con el presente proyecto, etc.*
-as !1tr%as $e pro$u%tE$a$ se centran en el rendimiento del proceso de ingeniera
de soft!are.
-as !1tr%as $e %al$a$ proporcionan una indicacin de cmo se a(usta el soft!are a
los requisitos implcitos y e/plcitos del cliente.
-as !1tr%as t1%n%as se centran en las caractersticas del soft!are ms que en el
proceso a tra%s del cual a sido desarrollado.
>tricas orientadas al tama,o
2on medidas directas del soft!are y del proceso por el cual se desarrolla. 2i para un
proyecto, se lle%a registro de datos como ser el esfuer&o, costo, cantidad de lneas de
cdigo, paginas de documentacin, errores y gente, se puede desarrollar un con(unto de
mtricas sencillas de producti%idad y de calidad orientadas al tama,o3
Producti%idad Q R-D5 B personaAmes
5alidad Q errores B R-D5
"dems, se pueden calcular otras mtricas interesantes3
5oste Q dlares B R-D5
Documentacin Q paginas de documentacin B R-D5
-a cantidad de lneas de cdigo es una medida polmica, ya que puede no llegar a ser
.til para la comparacin cuando diferentes proyectos se lle%an a cabo empleando
diferentes lengua(es de programacin. 5ada uno de estos puede, por naturale&a, poseer
ms o menos lneas de cdigo, siendo que la funcionalidad es la misma.
>tricas orientadas a la funcin
2on medidas indirectas del soft!are y del proceso por el cual se desarrolla, y se centran
en la funcionalidad o utilidad del programa. @na medida de producti%idad es el punto de
funcin, que se obtiene utili&ando una relacin emprica basada en medidas
2#
cuantitati%as del dominio de informacin del soft!are y %aloraciones sub(eti%as de la
comple(idad del soft!are.
Para calcular los puntos de funcin se determinan cinco caractersticas del mbito del la
informacin3
9umero de entradas de usuario3 entrada que proporciona al soft!are
diferentes datos orientados a la aplicacin.
9.mero de salidas del usuario3 5ada salida que proporciona al usuario
informacin orientada a la aplicacin. +(.3 ;nformes, pantallas, mensa(es de
error, etc.
9.mero de peticiones al usuario3 Peticin se define como una entrada
interacti%a que resulta de la generacin de alg.n tipo de respuesta en forma
de salida interacti%a.
9umero de arci%os3 2e cuenta cada arci%o maestro lgico.
9umero de interfaces e/ternas3 2e cuentan las in%eraces legibles por la
maquina )+(.3 arci%os de datos en discos* que son utili&ados para transmitir
informacin a otro sistema.
@na %e& recogidos estos datos, se asocia un %alor de comple(idad a cada cuenta.
>ediante una formula, se obtiene la cantidad de puntos de funcin, en base a
estos datos recogidos. @na %e& calculados, se puede emplear de manera anloga
a la cantidad de -D5, como medida de producti%idad, calidad y otros atributos
del soft!are3
Producti%idad Q PI B personasAmes
5alidad Q errores B PI
5oste Q dlares B PI
Documentacin Q paginas de documentacin B PI
M1tr%as para la %al$a$ $el so4t5are
2e puede medir la calidad a lo largo del proceso de ingeniera de soft!are y una %e& que
el soft!are a sido distribuido al cliente y usuarios.
A -as mtricas obtenidas antes de la distribucin proporcionan una base
cuantitati%a sobre la que tomar decisiones sobre el dise,o y la prueba.
A -as mtricas que se usan tras la distribucin se centran en el n.mero de defectos
no descubiertos en la prueba y la facilidad de mantenimiento del sistema. +stas
2H
medidas suponen para los gestores y tcnicos una indicacin a posteriori de la
efecti%idad del proceso de ingeniera de soft!are.
Me$$as $e %al$a$
-as mtricas a posteriori para medir la calidad del soft!are son3
A 5orreccin3 es el grado con que el soft!are reali&a la funcin requerida. -a
medida ms com.n es la cantidad de defectos por -D5. De4e%to se $e4ne %o!o
%aren%a Eer4%a$a $e %on4or!$a$ %on los re9ustos.
A Iacilidad de mantenimiento3 +s la facilidad con la cual se puede corregir un
programa si se encuentra un error, adaptarlo si su entorno cambia, o me(orarlo si
as lo desea el cliente. Para esto se deben usar !e$$as n$re%tas. @na mtrica
sencilla es el te!po !e$o entre %a!;os )6>+5*, el tiempo que lle%a
anali&ar el cambio requerido, dise,ar una modificacin apropiada, implementar
el cambio, probarlo y distribuir a los usuarios.
A ;ntegridad3 >ide la abilidad del soft!are para resistir ataques )incidentales o
intencionados* contra su seguridad. +l ataque se puede reali&ar sobre cualquiera
de los tres componentes del soft!are3 programas, datos y documentos.
Para medir la integridad, se deben definir amena&a y seguridad3 "mena&a es la
probabilidad de que un ataque de un tipo determinado ocurra en un tiempo
determinado= -a seguridad es la probabilidad de que se pueda repeler el ataque
de un determinado tipo.
A Iacilidad de uso3 +s la un intento de cuantificar la 7amistad con el usuario8 del
soft!are y se puede medir en base a cuatro caractersticas3
1* abilidad intelectual yBo fsica para aprender el sistema.
2* 6iempo requerido para llegar a ser moderadamente eficiente en el uso del
programa.
3* "umento neto en producti%idad, medida cuando el sistema lo utili&a alguien
moderadamente eficiente.
<* Oaloracin sub(eti%a de la disposicin de los usuarios acia el sistema.
3$
ESTIMACIN: OBGETIVOS
-a estimacin tiene por ob(eti%o proporcionar %alores a %ariables para lle%ar a cabo la
planificacin en cuanto a tiempo, recursos, costos, tama,o y calidad, sir%iendo como
una gua para una buena ingeniera de soft!are.
Fa%tores 9ue a4e%tan a la est!a%:n
-a estimacin requiere e/periencia, acceder a una buena informacin istrica,
confian&a en las medidas cuantitati%as cuando todo lo que e/iste son datos cualitati%os.
-a estimacin conlle%a un riesgo inerente y es este riesgo el que lle%a a la
incertidumbre.
La complejidad del proyecto se %e afectada por la familiaridad por esfuer&os anteriores.
El tama*o del proyecto es otro factor importante que puede afectar a la precisin de las
estimaciones. " medida que el tama,o aumenta, crece rpidamente la interdependencia
entre %arios elementos del soft!are. +l problema de la descomposicin, un enfoque
importante acia la estimacin, se ace ms difcil porque los elementos descompuestos
pueden ser toda%a e/cesi%amente grandes.
La disponibilidad de informacin +istrica: cuando se dispone de las mtricas
completas de soft!are de proyectos anteriores, se pueden acer estimaciones con mayor
seguridad= establecer planificaciones para e%itar dificultades anteriores y as reducir el
riesgo global. +l riesgo se mide por el grado de incertidumbre en las estimaciones
cuantitati%as establecidas.
RECURSOS
@na de las tareas de la planificacin del desarrollo de soft!are es la estimacin de
recursos requeridos para acometer el esfuer&o de desarrollo de soft!are.
+n la base de la pirmide de recursos se encuentra el entorno $e $esarrollo )ard!are
y soft!are* que proporciona la infraestructura de soporte al esfuer&o de desarrollo. +n
un ni%el mas alto se encuentran los %o!ponentes $e so4t5are reutl<a;les )los
bloques de soft!are que pueden reducir drsticamente los costos de desarrollo y
acelerar la entrega*. +n la parte mas alta est el recurso primario, las personas. 5ada
recurso queda especificado mediante cuatro caractersticas3
Descripcin del recurso
;nforme de disponibilidad
31
Ieca en la que se requiere el recurso
6iempo durante el cual ser aplicado.
Est!a%:n $el pro7e%to $e so4t5are
'oy en da, el soft!are es el elemento ms caro de la mayora de los sistemas
informticos. @n gran error en la estimacin del costo puede ser lo que marque la
diferencia entre beneficio y prdida.
-a estimacin del costo y el esfuer&o del soft!are nunca ser una ciencia e/acta. 2on
demasiadas las %ariables )umanas, tcnicas, de entorno, etc.* que pueden afectar al
costo final del soft!are y al esfuer&o aplicado para el desarrollo.
Para reali&ar estimaciones seguras de costo y esfuer&o se tienen las siguientes opciones3
1. Analo#3a: basar las estimaciones en proyectos similares ya terminados.
,. Opn:n $e eHpertos
3. Las t1%n%as $e $es%o!pos%:n, utili&an un enfoque de 7di%ide y %encers8
para la estimacin. >ediante la descomposicin del proyecto, en sus funciones
principales y en las tareas de ingeniera de soft!are correspondientes, la
estimacin de costo y esfuer&o pueden reali&arse en forma escalonada.
<. E%ua%ones $e est!a%:n: 2e pueden reali&ar los modelos empricos de
estimacin, como complemento de las tcnicas de descomposicin, ofreciendo
un enfoque de estimacin potencialmente %alioso.
2e entiende e/itoso al mtodo de estimacin si
-a estimacin inicial est dentro del 3$J de des%iacin del costo final
real
+l mtodo permite refinamiento durante el 5iclo de Oida
+l mtodo es fcil de usar
-as reglas de estimacin son entendidas por todos los in%olucrados
+l mtodo es soportado por erramientas y est documentado
PRESENTACIN DE MODELOS EMP0RICOS @ TFCNICAS
@n modelo de estimacin para el soft!are de computadoras utili&a formulas deri%adas
empricamente para predecir el esfuer&o en funcin de lneas de cdigo -D5 o puntos
de funcin PI. +/isten %arios tipos de modelos.
Mo$elos esta$3st%os:
32
+sfuer&o Q ?,2 miles de -D5S$.H1
Mo$elos ;asa$os en teor3a
R Q - S 3 B )5S3* / )6S<*
- Q 9umero de instrucciones fuente producidas
R Q +sfuer&o durante todo el ciclo de %ida
5 Q una constante dependiente de la tecnologa
6 Q el tiempo de desarrollo en a,os
Mo$elos %o!puestos Iutili&an intuicin, anlisis estadstico y (uicio de e/pertosJ
>odelo 5G5G>G
"plica a los desarrollos que siguen el ciclo de %ida en cascada considerado con las
siguientes fases3 Planificacin y definicin de requisitos= dise,o de producto= dise,o
detallado= codificacin y pruebas unitarias= integracin y pruebas= implantacin=
e/plotacin y mantenimiento. ;ncorpora dentro del proceso3 Oerificacin y %alidacin y
gestin de configuracin.
-a (erarqua de modelos de Noem esta constituida por los siguientes3
>odelo bsico3 calcula el esfuer&o del desarrollo del soft!are en funcin del
tama,o del programa, e/presada en -D5 estimadas.
120io
Semir20io
3r04nico
/4sico !ntermeio Detallao
"3D%53 D% D%SA113553
D%5 S3#T6A1%
"3D%53S D%
AP5!CAC!37
+spacio para situar
un
Proyecto a estimar
por
5G5G>G
33
>odelo intermedio3 calcula el esfuer&o del desarrollo de soft!are en funcin
del tama,o del programa y de un con(unto de 7conductores de costo8, que
incluyen la e%aluacin sub(eti%a del producto, del ard!are, del personal y
de los atributos del proyecto.
>odelo detallado3 ;ncorpora todas las caractersticas de la %ersin intermedia
y lle%a a cabo una e%aluacin del impacto de los conductores de los costos
en cada fase )anlisis, dise,o, etc.* del proceso de ingeniera de soft!are.
-os modelos 5G5G>G estn definidos para tres tipos de proyectos soft!are3
>odo orgnico3 Proyectos relati%amente peque,os y sencillos en los que
traba(an peque,os equipos, con buena e/periencia en la aplicacin, sobre un
con(unto de requisitos poco rgidos. +T3 un programa de anlisis termal
desarrollado por un grupo calrico.
>odo semirigido3 Proyecto de tama,o y comple(idad intermedia. +(. @n
sistema de procesamiento de transacciones con requisitos fi(os para un
ard!are de terminal o un soft!are de gestin de base de datos.
>odo rgido3 Proyecto de soft!are que deben ser desarrollados en ard!are,
soft!are y restricciones operati%as muy restringido. +(. 2oft!are de control
de na%egacin para un a%in.
Est!a%:n por puntos $e 4un%:n
>iden el soft!are cualificando la funcionalidad que proporciona e/ternamente,
basndose en el dise,o lgico del sistema.
-os ob(eti%os son3
A >edir lo que el usuario pide y lo que recibe
A >edir independientemente de la tecnologa utili&ada
A Proporcionar una mtrica del tama,o que d soporte al anlisis de calidad y
producti%idad.
A Proporcionar un medio para la estimacin de soft!are
A Proporcionar un factor de normali&acin para la comparacin de distintos
soft!are.
+l ob(eti%o .ltimo es medir el tama,o de una aplicacin.
Pasos3
1. Definicin de parmetros
3<
2. Oaloracin de la comple(idad asociada a los parmetros
3. 5alculo de puntos funcin sin a(ustar )"I*
<. Oaloracin del grado de influencia 6D;
?. 5alculo del factor de a(uste
0. 5alculo de anlisis de punto de funcin a(ustado
Para aplicar correctamente este mtodo ace falta disponer de ratios relati%os a la
producti%idad, calidad, costo, documentacin yBo lneas de cdigo.
2ERRAMIENTAS AUTOM6TICAS
-as tcnicas de descomposicin y los modelos empricos de estimacin descritos se
pueden emplear con soft!are, y permiten al planificador estimar costos y esfuer&os. -os
resultados obtenidos por estas erramientas se deben usar solo como puntos de partida
para la obtencin de estimaciones, no como .nica fuente para la estimacin.
3?
UNIDAD IV: PLANIFICACIN TEMPORAL @ SE/UIMIENTO DEL
PRO@ECTO
-a realidad de un proyecto tcnico es que ay que reali&ar cientos de peque,as tareas
antes de alcan&ar la meta final. "lgunas de ellas pueden completarse sin afligirse en la
feca de terminacin de proyecto. Gtras tareas que son crticas al retrasarse ponen en
peligro la feca de terminacin del proyecto.
2e deben definir todas las tareas del proyecto, identificando las crticas, para despus
reali&ar un seguimiento y asegurarse el progreso y control del proyecto.
-a planificacin temporal de un proyecto de soft!are es una acti%idad que distribuye el
esfuer&o estimado a lo largo de la duracin pre%ista del proyecto, asignando el esfuer&o
a las tareas especficas de la ingeniera de soft!are.
+s importante remarcar que la planificacin temporal e%oluciona con el tiempo. +s
decir, a medida que el proyecto progresa, cada entrada en la planificacin temporal
macroscpica se refina en una planificacin temporal detallada.
-a planificacin temporal para proyectos de desarrollo de soft!are puede %erse desde
dos perspecti%as3
-a feca de terminacin del proyecto ya a sido establecida
irre%ocablemente.
-a feca final del proyecto es establecida por la organi&acin del proyecto.
-a planificacin de un proyecto de soft!are no difiere de la planificacin de cualquier
proyecto de ingeniera, ya que se gua por unos conceptos bsicos3
1. 5ompartimentacin3 +l proyecto debe di%idirse en un n.mero de acti%idades
y tareas mane(ables.
2. "signacin de tiempo3 " cada tarea se le debe asignar una feca de inicio y
fin, que son funcin de las interdependencias y si el traba(o se ar a tiempo
total o parcial.
3. ;nterdependencia y red de tareas3 "lguitas tareas deben ocurrir en una
secuencia determinada= otras pueden darse en paralelo. "lgunas acti%idades
no pueden comen&ar asta que el resultado de otras no est disponible. Gtras
acti%idades pueden ocurrir independientemente. " partir de esto, se establece
en forma grfica el flu(o de tareas del proyecto.
<. Oalidacin de esfuer&o3 2e estima el esfuer&o asociado a cada tarea.
?. :esponsabilidades definidas3 "signacin del personal y otros recursos.
30
&n'lisis (
especificaci)n
*e+isi)n de
los re,-isitos
.ise/o
ar,-itect)nico
( de datos
*e+isi)n del
dise/o
preli#inar
.ise/o
procedi#ental
0nspecci)n del
dise/o
Codificaci)n
0nspecci)n del
C)di1o
%r-eba de
2nidad
%r-eba de
0nte1raci)n
%r-eba de
Validaci)n
%lanificaci)n
de la pr-eba
%rocedi#iento
de %r-eba
*e+isi)n de
la pr-eba
$ 3ito
0. 'itos definidos3 6odas las tareas o grupo de ellas deberan asociarse con un
ito del proyecto. 2e consigue u ito cuando se a re%isado la calidad de uno
o ms productos y se an aceptado.
-a precisin en la planificacin puede a %eces ser ms importante que la precisin en
los clculos de costo. "lgunas cuestiones a considerar son3
C5omo acer corresponder el tiempo cronolgico con el esfuer&o umanoE
CMue tareas y paralelismos se pueden encontrarE
CMue 'itos se pueden establecer para la e%aluacin del progresoE
C2e dispone de mtodos de anlisis para la planificacin temporalE
C5omo se consigue el progreso del proyecto cuando este comien&aE
RELACIN ENTRE PERSONAS @ ESFUERKO
+n un proyecto de desarrollo de soft!are peque,o una sola persona puede anali&ar los
requisitos, reali&ar el dise,o, generar cdigo y reali&ar pruebas. " medida que crece el
proyecto, ms personas se %en en%ueltas.
",adir gente tarde a un proyecto tiene a menudo un efecto negati%o, pro%ocando a.n
ms retrasos. +l personal agregado debe aprenderse el sistema y la gente que les ense,a
es la misma que estaba traba(ando.
31
"dems del tiempo que se tarda en aprender el sistema, el in%olucrar ms personas
aumenta el n.mero de %as de comunicacin y la comple(idad de la comunicacin a lo
largo del proyecto. 5ada nue%a %a de comunicacin requiere un esfuer&o adicional y,
por tanto, un tiempo adicional.
Dstr;u%:n $el es4uer<o
5ualquiera de las tcnicas de la esitacin nos lle%a a calcular el esfuer&o en
personasBtiempo requeridos para completar el desarrollo de soft!are.
@na distribucin recomendada entre las diferentes fases puede ser3
"nlisis y dise,o3 <$ 4 ?$ J
5odificacin3 1? 4 2$ J
Prueba y depuracin3 3$ 4 <$ J
+sta distribucin se conoce como la regla <$ 4 2$ 4 <$ y solo es una directri& )muy .til
para distribuir el dinero*. -as caractersticas de cada proyecto dictan la distribucin mas
adecuada.
+l esfuer&o de la planificacin se mantiene ba(o el 3 J del total, a menos que el plan
comprometa a la organi&acin a grandes gastos.
MFTODOS DE PLANIFICACIN TEMPORAL
2e pueden utili&ar las tcnicas y erramientas generales de planificaron temporal de
proyectos. -a tcnica de e%aluacin y re%isin de programas )P+:6*, y el mtodo del
camino crtico )5P>* pueden ser aplicadas.
"mbos desarrollan una representacin grfica de la red de tareas del proyecto y
permiten al planificador3
1. Determinar el camino crtico
2. +stablecer las estimaciones de tiempo ms probables para las tareas indi%iduales
con la aplicacin de modelos estadsticos.
3. 5alcular los lmites de tiempo que definen la olgura de cada tarea indi%idual.
"simismo las tcnicas mencionadas permiten determinar3
1. -o ms pronto que puede comen&ar una tarea cuando todas las precedentes se
determinan en el mnimo tiempo posible.
2. -o ms tarde que puede iniciar la tarea sin que se retrase el tiempo mnimo de
finali&acin del proyecto.
3#
3. +l final ms temprano, la suma del comien&o ms temprano y la duracin de las
tareas.
<. +l final ms tardo la suma del comien&o ms tardo y la duracin de las tareas.
?. +l margen total de olgura, la cantidad de tiempo sobrante o margen permitido
en la planificacin de tareas, de forma que el camino de la red se mantenga
dentro de la agenda.
+l esfuer&o empleado no termina al finali&ar el desarrollo. +l esfuer&o de
mantenimiento llegar a ser el factor de mayor costo. @n ob(eti%o principal de la
ingeniera de soft!are es ayudar a reducir ese costo.
SE/UIMIENTO DE LA PLANIFICACIN TEMPORAL
@na %e& establecida la agenda, comien&a la acti%idad de seguimiento y control.
2i una tarea se sale de agenda, el gestor podr calcular el impacto del error de
planificacin, sobre los itos intermedios y sobre las feca final de entrega. +n ese caso
se pueden reasignar recursos, reordenar las tareas o, como ultimo recurso, modificar los
compromisos de entrega para resol%er el problema no detectado. De ese modo, se puede
controlar me(or el desarrollo de soft!are.
9ormalmente, los proyectos se salen de agenda, da a da, los das se %an acomodando,
y los retrasos pueden producir gra%es problemas.
+l seguimiento se puede lle%ar a cabo de diferentes formas3
:eali&ando reuniones peridicas.
+%aluando los resultados de todas las re%isiones reali&adas.
Determinando el alcance de los itos en el momento adecuado.
5omparando la feca de comien&o real con la planeada.
:eunindose con los tcnicos para conocer sus %aloraciones sub(eti%as del
a%ance.
+l control se basa en los datos sobre lo planificado y lo sucedido durante la e(ecucin
del proyecto. Puede definirse en cuatro fases3
1. Definir una medida )cantidad de personas, mdulos, mquinas, etc.*
2. :egistrar el a%ance
3. 5alcular la des%iacin
<. 6omar acciones correcti%as
3H
+l proceso de desarrollo de soft!are est sometido a un con(unto de peligros que se
manifiestan en problemas financieros y tcnicos. -as fuentes de estos peligros se
pueden categori&ar como3
A Perturbaciones )cambios en requisitos, deteccin de problemas, errores y fallos*.
A Personal )personal inadecuado, pocasBdemasiadas personas disponibles*. -a
capacitacin para el desarrollo de soft!are es elemental.
A +ntorno del proyecto )metodologa sin definir, calidad desconocida, tarda
deteccin de errores, etc.*
AN6LISIS DE RIES/OS
5ada %e& que se %a a desarrollar soft!are aparecen ciertas reas de incertidumbre. +l
riesgo es un problema potencial.
+n el conte/to de la ingeniera de soft!are se acen presentes las siguientes
consideraciones3
9os concierne el futuro3 C5ules son los riesgos que pueden acer que
fracase el proyecto de soft!areE
9os concierne los cambios3 C5mo afectar al /ito global y a los pla&os los
cambios en los requisitos del cliente, en las tecnologas, en las computadoras
de destino y en todas las dems entidades relacionadas con el proyectoE
9os enfrentamos con elecciones3 CMu mtodos y erramientas se deben
usarE C5unta gente debe estar in%olucradaE C5unta importancia ay que
darle a la calidadE
+l anlisis de riesgo consta de cuatro acti%idades principales3
1. ;dentificacin de riesgo3 +s un intento sistemtico para especificar las amena&as
al plan del proyecto.
o :iesgos del proyecto3 ;dentifican potenciales problemas
presupuestarios, de agenda, de personal )de organi&acin y
asignacin*, de recursos, del cliente y de requisitos, as como su
impacto sobre el proyecto de soft!are.
o :iesgos tcnicos3 ;dentifican potenciales problemas de dise,o,
implementacin, interfa&, %erificacin y mantenimiento. "dems,
ambigPedad de especificacin, incertidumbre tcnica, la
obsolescencia tcnica y la tecnologa de punta. -os riesgos tcnicos
<$
aparecen a que el problema es ms difcil de resol%er de lo que se
parece.
o :iesgos de negocio3
1. :iesgos de mercado )el producto es bueno pero nadie lo
quiere*
2. 2e construye un producto que no se a(usta a la estrategia
global de la empresa.
3. 2e construye un producto que el departamento Oentas no sabe
como %ender.
<. :iesgos de gestin )cambio de personal*
?. :iesgo de presupuesto
2. Proyeccin de riesgo3 ;ntenta e%aluar el riesgo de dos formas3
1. -a probabilidad que el riesgo se presente.
2. -a consecuencia de su aparicin )impacto*
Para ello nos apoyamos en3 la naturale&a del riesgo, su distribucin y
duracin. -as acti%idades de la proyeccin de riesgo son3
a. +stablecimiento de una escala que refle(e la probabilidad
obser%ada de un riesgo.
b. Definicin de las consecuencias de un riesgo.
c. +stimacin del impacto del riesgo en el proyecto y en el
producto.
d. +stablecer el grado de e/actitud de la proyeccin.
<1
4-( &lto
4-( Ba"o
0#pacto
%robabilidad
de ,-e oc-rra
1
*ele+ancia
para la 1esti)n
&lto
3. 5lculo de riesgo3 2e establecen ni%eles de referencia )costos, agenda y
rendimiento* a fin de determinar si se contin.a o no con el proyecto.
Pasos de la e%aluacin del riesgo3
a. Definir los ni%eles de referencia de riesgo para el proyecto.
b. ;ntentar desarrollar la relacin riesgo, probabilidad, impacto y
cada uno de los ni%eles de referencia.
c. Predecir puntos de referencia.
d. Predecir cmo afectarn al ni%el de referencia las
combinaciones de riesgo
<. Lestin de riesgos3 2e usa la terna asociada a cada riesgo como base para
desarrollar como base para desarrollar los pasos de gestin de riesgos )a%ersin
al riesgo*
<2
Gestin el
ries0o
1ies0o n
1ies0o 2
1ies0o 1
Pasos e 0estin
r n
Terna r8p8i +n-
Pasos e 0estin
r 2
Terna r8p8i +2-
Pasos e 0estion
r 1
Terna r8p8i +1-
Plan e Gestin 9
Super&isin el ries0o
Punto e 1eferencia
+&alor e costo8 &alor e tiempo-
!5ceso en el costo
!5ceso en a1enda
-os pasos de gestin de riesgo estn organi&ados en el plan de gestin y super%isin del
riesgo que documentan el anlisis de riesgo. @na %e& desarrollado este, comien&a la
super%isin del riesgo. 2e debe establecer qu acer y quien lo ace.
-a super%isin es el control del cumplimiento del plan. Dentro de este plan se
encuentran los pasos para minimi&ar la probabilidad de ocurrencia del eco.
/ARANT0A DE CALIDAD DEL SOFTWARE
Diferentes perspecti%as de la calidad en el proceso de desarrollo de soft!are.
1. -a %isin trascendental, seg.n la cual la calidad es algo que se puede reconocer,
pero que no se puede definir.
2. -a %isin del usuario, para la cual la calidad es adecuacin al propsito.
3. -a %isin de manufactura, donde la calidad es conformidad con la especificacin
<. -a %isin del producto, donde la calidad est %inculada a las caractersticas
inerentes al producto.
?. -a %isin basada en %alor, seg.n la cual la calidad depende de la cantidad de
dinero que el usuario est dispuesto a pagar por el producto.
Desde lo informtico, la calidad del producto se puede entender como el mayor
acercamiento a lo requerido por el cliente.
La #arant3a $e %al$a$ de soft!are es una acti%idad de proteccin que se aplica a lo
largo de todo el proceso d ingeniera de soft!are. +ngloba3
'. @n enfoque de gestin de calidad
,. Te%nolo#3as $e n#ener3a $e so4t5are e4e%tEas I!1to$os 7 =erra!entasJ
L. :e%isiones tcnicas formales que se aplican durante el proceso de soft!are.
M. @na estrategia de prueba multiescala
). +l control de la documentacin del soft!are y de los cambios reali&ados
+. @n procedimiento que asegure un a(uste a los estndares de desarrollo de
soft!are )cuando sea posible*
.. >ecanismos de medicin y de generacin de informes.
+l ob(eti%o de la garanta de calidad es proporcionar la gestin para informar de los
datos necesarios sobre la calidad del producto, por lo que se %a adquiriendo una %isin
ms profunda y segura de que la calidad del producto est cumpliendo sus ob(eti%os.
<3
Cal$a$ $el pro$u%to
-os usuarios (u&gan al soft!are como de buena calidad si ace lo que ellos desean, en
una forma que sea fcil de aprender y fcil de usar. 2in embargo a %eces calidad y
funcionalidad estn entrela&adas3 si algo es difcil de aprender o de usar, pero su
funcionalidad %ale la pena, entonces, toda%a se considera que el producto tiene alta
calidad.
Para medir la calidad los usuarios %aloran caractersticas e/ternas con el n.mero y tipos
de fallas.
-os desarrolladores obser%an en cambio, caractersticas internas del soft!are. " menudo
buscan el n.mero y tipo de fallas encontrados e inspecciones de los requerimientos, del
dise,o y del cdigo.
Cal$a$ $el pro%eso
2on mucas las acti%idades que afectan la calidad final de un producto= si alguna de
estas acti%idades se distorsiona, la calidad del producto puede deteriorarse. -a calidad
de los procesos de desarrollo y mantenimiento es tan importante como la calidad del
producto.
/ESTIN DE CONFI/URACIN DE SOFTWARE
" medida que a%an&a el proceso soft!are, el n.mero de elementos de configuracin del
soft!are crece rpidamente. +n todo proceso inter%ienen cambios en cualquier
momento, y por cualquier ra&n.
La #est:n $e %on4#ura%:n $e so4t5are es un con(unto de acti%idades desarrolladas
para gestionar los cambios a lo largo del ciclo de %ida del soft!are. Proporciona la
disciplina requerida para pre%enir el caos del cambio incontrolado.
-nea base3 +s un concepto de L52 que nos ayuda a controlar los cambios, sin impedir
seriamente los cambios (ustificados. :epresenta una especificacin o producto sobre lo
que se a llegado a un acuerdo, y que de a en adelante sir%a como base para un
desarrollo posterior y que pueda cambiarse solamente a tra%s de procedimientos
formales de control de cambios.
<<
CONTROL DE VERSIONES @ CAMBIOS
5ombina procedimiento y erramientas para gestionar las %ersiones de los ob(etos de
configuracin creados durante el proceso de ingeniera de soft!are.
-a L52 permite a un usuario especificar configuraciones alternati%as del sistema de
soft!are mediante la seleccin de las %ersiones adecuadas. +sto se puede gestionar
asociando atributos a cada %ersin del soft!are y permitiendo luego especificar y
construir una configuracin describiendo el con(unto de atributos deseado.
Control $e %a!;os
+n un gran proyecto de desarrollo de soft!are, el cambio incontrolado lle%a al caos. +l
control de cambio combina los procedimientos umanos y las erramientas automticas
para proporcionar un mecanismo para el control de cambios.
PLAN DE PRO@ECTO DE SOFTWARE
2e produce a la culminacin de las tareas de planificacin. Proporciona informacin
bsica de costos y planificacin temporal que ser empleada a lo largo del proceso de
ingeniera de soft!are.
2u ob(eti%o es ayudar a establecer la %iabilidad del esfuer&o de desarrollo de soft!are.
+l plan se concentra en una declaracin general de el qu y una especificacin
especifica de cunto y cundo. -os pasos subsiguientes en los procesos de ingeniera de
soft!are se concentraran en la definicin, desarrollo y mantenimiento.
<?
UNIDAD V: AN6LISIS @ DISENO
AN6LISIS DE REAUISITOS
Para el /ito de un desarrollo de soft!are es esencial una comprensin total de los
requisitos del soft!are. 6anto el desarrollador como el cliente tienen un papel acti%o en
el anlisis y especificacin de los requisitos. +l cliente intenta reformular su concepto a
%eces confuso de funcin soft!are y rendimiento en detalles concretos. +l desarrollador
act.a como un interrogador como consultor y como persona que resuel%e problemas.
+l "nlisis de :equerimientos facilita al ingeniero de sistemas la especificacin de la
funcin y rendimiento del soft!are, la descripcin de la interfa& con otros elementos del
sistema y el establecimiento de restricciones de dise,o que debe considerar el soft!are.
Permite construir modelos de los mbitos del proceso, de los datos y del
comportamiento que sern cubiertos por el soft!are.
+s un proceso de descubrimiento, refinamiento, modeli&acin y especificacin.
2e pueden identificar cinco reas de esfuer&o3
1. :econocimiento del problema
2. +%aluacin y sntesis
3. >odeli&acin
<. +specificacin
?. :e%isin
<0
0n1enier6a de 7iste#as de
Co#p-tadoras
&n'lisis de *e,-isitos del
7oft8are
.ise/o del 7oft8are
,onte$to de la 'area de n"lisis
:econocimiento del problema3 +l analista estudia la especificacin del sistema y el plan
del proyecto de soft!are. +s importante entender el soft!are en el conte/to de un
sistema. -uego se debe establecer la comunicacin para el anlisis de manera que se
garantice un correcto reconocimiento del problema. -a meta del analista es reconocer
los elementos bsicos del problema, tal como los reconoce el cliente o usuario.
+%aluacin y sntesis de la solucin3 2e deben definir todos los ob(etos de datos
obser%ables e/ternamente, e%aluar el flu(o y contenido de la informacin, definir y
elaborar las funciones del soft!are, entender el comportamiento del soft!are en el
conte/to del sistema, establecer caractersticas de la interfa& del sistema y descubrir
restricciones adicionales de dise,o.
Ca$a una $e las tareas srEe para $es%r;r el pro;le!a $e !anera 9ue se pue$a
sntet<ar un en4o9ue o solu%:n #lo;al.
-a modeli&acin sir%e para entender me(or el flu(o de datos y de control, el tratamiento
funcional y el comportamiento operati%o y el contenido de la informacin. 2ir%e
adems, como fundamento para el dise,o de soft!are y como base para la creacin de
una especificacin de soft!are.
-a especificacin3 las tareas asociadas con el anlisis y la especificacin intentan
proporcionar una representacin del soft!are que puede ser re%isada y aprobada por el
cliente. +n un mundo ideal, el cliente desarrolla una especificacin de requisitos del
soft!are de manera completa por s mismo.
:e%isin3 -os documentos de anlisis de requisitos sir%en como una base para la
re%isin por parte del cliente y del desarrollador. +sta re%isin casi siempre produce
modificaciones en lo anteriormente planeado. 2e %uel%e a e%aluar el Plan de Proyecto
de 2oft!are para determinar si las pre%ias estimaciones siguen siendo %lidas.
Prn%pos $el an8lss
6odos los mtodos de anlisis se relacionan por un con(unto de principios operati%os3
1. 2e debe representar y comprender el mbito de informacin del problema,
anali&ando desde tres %isiones diferentes a los datos y el control3
a. 5ontenido de la informacin y relaciones3 representan los ob(etos
indi%iduales de datos y de control que componen alguna coleccin mayor
de informacin a la que transforma el soft!are.
<1
b. Ilu(o de la informacin3 representa como cambian los datos y el control
a medida que se mue%en a tra%s de un sistema.
c. +structura de la informacin3 representa la organi&acin interna de los
elementos de los datos y control.
2. 2e deben desarrollar los modelos que representen la informacin, funcin y el
comportamiento del sistema. 2e debe ser capa& de modelar la informacin que
transforma el soft!are, las funciones que permiten que ocurran las
transformaciones y el comportamiento del sistema cuando ocurren estas
transformaciones, empleando una notacin grfica que muestra informacin,
procesamiento, comportamiento del sistema, etc. Gtras partes del modelo pueden
ser te/to puro.
3. 2e deben subdi%idir los modelos )y el problema* de forma que se descubran los
detalles de una manera progresi%a )o (errquica*. 2ugiere que se pude
descomponer el problema en peque,os problemas ms mane(ables, de modo que
se planteen soluciones especficas a cada uno de ellos, teniendo en cuenta su
funcionalidad como comportamiento dentro del sistema. 2e establece una
representacin (errquica de la informacin o de la funcin y despus se parte el
elemento de orden superior ya sea3
i. +/poniendo ms detalles cada %e& al mo%erse %erticalmente por
la (erarqua o
ii. descomponiendo el problema si se mue%e ori&ontalmente en la
(erarqua
DOCUMENTACIN DE LA ESPECIFICACIN DE REAUISITOS
EntreEstas
2e quiere conocer opinin y sentimientos del usuario respecto al estado actual del
sistema, ob(eti%os de la organi&acin, personal, procedimientos informales.
6ipos3
Piramidal
+mbudo
:ombo
5aractersticas
+structuradas
<#
9o estructuradas
Cuestonaros
Permiten estudiar actitudes, creencias, comportamientos y caractersticas de %arias
personas principales en la organi&acin que pueden ser afectadas por los sistemas actual
y propuesto.
6ipos
"biertos
5errados
O;serEa%ones
-a obser%acin tanto del tomador de decisiones, como del ambiente fsico de ste son
importantes para el analista de sistemas.
4 "cti%idades
4 >ensa(es
4 :elaciones
4 ;nfluencias
Grientada al comportamiento de los usuarios permite %erificar cmo realmente se
desempe,a el sistema actual.
ReEs:n $e re#stros
2e debe %erificar la informacin obtenida de entre%istas y cuestionarios con las reales
acti%idades representadas en documentos y dems papeles de la organi&acin.
+s con%eniente obtener copias de documentos rele%antes que estn usadas y no
formularios en blanco.
<H
2ERRAMIENTAS FORMALES DE DOCUMENTACIN
6r;ol $e De%s:n
2e usan cuando suceden ramificaciones comple(as en un proceso de decisin
Ta;las $e De%s:n
2e usan para determinar cules acciones deben reali&arse ante una condicin.
Con$%ones 7 A%%ones Re#las
5ondiciones "lternati%as de condicin
"cciones +ntradas de accin
Len#uaCe Estru%tura$o
?$
1
3 2
6
4
5
Condici)n 1
Condici)n 2
&cci)n
1
Condici)n 3
Condici)n 4
70
F0970
70
709:
F0970
DOCUMENTO DE ESPECIFICACIN DE REAUISITOS
-a ;+++ a establecido el siguiente formato para la especificacin de requisitos de
soft!are3
Intro$u%%:n
4 :eferencia del sistema
4 Descripcin Leneral
4 :estricciones del Proyecto soft!are
Des%rp%:n $e la n4or!a%:n
4 :epresentacin del flu(o de informacin
Ilu(o de Datos
Ilu(o de 5ontrol
4 :epresentacin del contenido de la informacin
4 Descripcin de la interfa& del sistema
Des%rp%:n Fun%onal
4 Particin Iuncional
4 Descripcin Iuncional
9arrati%a del procesamiento
:estricciones B limitaciones
:equisitos de rendimiento
:estricciones de dise,o
Diagramas de soporte
4 Descripcin del 5ontrol
+specificaciones del 5ontrol
:estricciones de dise,o
Des%rp%:n $el Co!porta!ento
+stados del 2istema
2ucesos y acciones
Crteros $e Val$a%:n
-mites de rendimiento
5lases de Pruebas
:espuestas esperadas del soft!are
?1
5onsideraciones especiales
B;lo#ra43a
Ap1n$%e
DISENO DE SISTEMAS
De4n%:n $e Dse"o
-.roceso de aplicar distintas t/cnicas y principios con el propsito de definir un
dispositi(o) un proceso o un sistema con suficiente detalle como para permitir su
reali#acin f%sica0
2uponiendo que se an anali&ado y especificado los requisitos del soft!are, el dise,o es
la primera )dise,o, codificacin y prueba* acti%idad tcnica necesaria para construir y
%erificar el soft!are. 5ada acti%idad transforma la informacin de manera que se
obtenga finalmente un soft!are %lido.
5ada uno de los elementos del modelo de anlisis proporciona informacin necesaria
para crear un modelo de dise,o.
+l dise,o de datos transforma el modelo de dominio de la informacin, creado durante
el anlisis, en las estructuras de datos necesarias para implementar el soft!are.
+l dise,o arquitectnico define la relacin entre los principales elementos estructurales
del programa. +sta representacin del dise,o )la estructura modular de un programa* se
Diccionario
e Datos
.ia1ra#a de
;ransici)n de
!stados
.ise/o
%rocedi#ental
.ise/o de .atos
.ise/o &r,-itect)nico
.ise/o de 0nterfa<
.ia1ra#a
!ntidad
*elaci)n
.ia1ra#a
de Fl-"o
de .atos
?2
puede obtener del modelo de anlisis y de la interaccin de subsistemas definidos dentro
del modelo de anlisis.
+l dise,o de interfa& describe como se comunica el soft!are consigo mismo, con los
sistemas que operan con el y con los operadores que lo emplean. @na interfa& implica u
flu(o de informacin, los diagramas de flu(o de datos y control proporcionan la
informacin necesaria para el dise,o de la interfa&.
+l dise,o procedimental transforma elementos estructurales de la arquitectura del
programa en una descripcin procedimental de los componentes del soft!are. -a
informacin se obtiene de la +specificacin de Procesos y de 5ontrol y del Diagrama de
6ransicin de +stado.
-a importancia del dise,o de soft!are radica en la calidad ya que fomenta la calidad en
el desarrollo de soft!are. +l dise,o nos proporciona representaciones de soft!are en las
que se puede %alorar la calidad. +l dise,o es la .nica manera de traducir con precisin
los requisitos del cliente en un sistema o producto soft!are. 2ir%e como fundamento
para todas las fases posteriores de ingeniera y mantenimiento de soft!are. 2in el
dise,o, nos arriesgamos a construir un sistema inestable que fallar cuando se agan
peque,os cambios, y que sea difcil de probar.
EL PROCESO DE DISENO
+l proceso de dise,o es un con(unto de pasos repetiti%os que permiten al dise,ador
describir todos los aspectos del soft!are a construir. -a capacidad creati%a, la
e/periencia acumulada, el sentido de 7buen soft!are8 y un empe,o global en la calidad
son factores crticos del /ito del dise,o.
+l modelo del dise,o es el equi%alente a los planos de una casa.
Con%eptos $e $se"o
"bstraccin
-a solucin a un problema se puede plantear en diferentes ni%eles de detalle. +n un
ni%el alto de abstraccin, se reduce el problema a e/presiones referidas al
comportamiento global del sistema, sin preocupaciones respecto a cmo implementar la
solucin al problema en cuestin mediante computadoras. " medida que se a%an&a en el
desarrollo del sistema, se ba(a de ni%el de abstraccin )se mane(an ms detalles* y se
?3
incorporan consideraciones de la implementacin en un ambiente tecnolgico concreto.
+/isten abstracciones de datos, procedimentales y de control.
:efinamiento
+l refinamiento paso a paso es una estrategia de dise,o descendente )9iUlaus Virt*.
+s un proceso de elaboracin. 2e inicia enunciando funciones a un alto ni%el de
abstraccin, sin informar sobre los procesos internos de la funcin o la estructura interna
de la funcin. 2e proporciona ms detalle en cada refinamiento sucesi%o.
-a abstraccin y el refinamiento son conceptos complementarios.
>odularidad
2e di%ide al soft!are en componentes identificables y tratables por separado )mdulos*,
que se integran para satisfacer los requisitos del programa.
-La modularidad es el atributo del software !ue permite a un programa ser manejable
intelectualmente0
2e llama soft!are monoltico al que se desarrolla como un .nico mdulo. +s muy difcil
de entender en cuanto a sus caminos de control, mbito de referencia, n.mero de
%ariables y comple(idad global.
Sean la complejidad del problema $ ,1$2) y el esfuer#o en tiempo necesario para
resol(erlo E1$2) se tiene:
Si ,1p32 4 ,1p52
entonces E1p32 4 E1p52
5)p1Wp2* X 5)p1* W
5)p2* entonces
+)p1Wp2* X +)p1* W
+)p2*
+/isten dos problemas3 5antidad y 6ama,o de los mdulos.
"rquitectura del soft!are
-a arquitectura del soft!are alude a 7la estructura global del soft!are y las maneras en
que esa estructura proporciona integridad conceptual a un sistema8
+s la estructura (errquica de los componentes del programa )mdulos*, la manera de
interactuar de estos componentes, y la estructura de datos usados por esos componentes.
2e deben especificar3
?<
Propiedades estructurales3 Define los componentes de un sistema.
Propiedades e/traAfuncionales3 Debe describirse cmo se espera obtener rendimiento,
capacidad, fiabilidad, seguridad, adaptabilidad y otras caractersticas.
Iamilias de sistemas relacionados3 Deberan reutili&arse esquemas definidos
pre%iamente.
Terarqua de 5ontrol
:epresenta la organi&acin )a menudo (errquica* de componentes del programa. 9o
representa aspectos procedimentales del soft!are.
Profundidad3 9.mero de ni%eles de control.
"ncura3 Kmbito global de control.
Lrado de 2alida3 medida del n.mero de mdulos controlados directamente por un
mdulo.
Lrado de +ntrada3 ;ndica cuntos mdulos controlan directamente al mdulo en
cuestin.
+/isten los conceptos de superior a y subordinado de para indicar (erarqua.
Particin estructural
-a particin ori&ontal define ramas separadas de la (erarqua modular para cada
funcin principal del programa. -os mdulos de control se usan para coordinar la
comunicacin entre ellas y la e(ecucin de las funciones del programa. +l enfoque ms
simple define tres particiones3 entrada, procesamiento y salida.
Neneficios3
??
a
e
f 0 :
i $
"
;
<
c
l m
o n p q
f
a. 2oft!are ms fcil de probar
b. 2oft!are ms fcil de mantener
c. Propaga menos efectos secundarios
d. 2oft!are ms fcil de ampliar
-a particin %ertical )descomposicin en factores* sugiere que el control y el traba(o se
distribuyan descendentemente en la arquitectura del programa. -os mdulos superiores
deberan reali&ar funciones de control y poco traba(o de procesamiento. -os mdulos de
ni%el inferior deberan reali&ar las tareas de entrada, procesamiento y salida.
@n cambio en un mdulo de control )parte alta de la arquitectura* tiene mayor
probabilidad de propagar error a otros mdulos subordinados, al contrario de cambios
en los mdulos de traba(o.
+structura de Datos
+s la representacin de la lgica entre los elementos indi%iduales de datos.
1. +lemento escalar es la forma ms simple.
2. Oector secuencial
3. +spacio nAdimensional )matri&*
<. -ista enla&ada
?. +structura de datos (errquica
-as estructuras de datos pueden representarse a distintos ni%eles de abstraccin. @na
pila es un modelo conceptual de una estructura que puede implementarse como un
%ector o como una lista enla&ada.
?0
"
; a
0

f :
e <
c
l m <
o p q
Procedimiento del soft!are
-a estructura del programa define la (erarqua de control sin tener en cuenta la secuencia
del procesamiento y las decisiones. +l procedimiento del soft!are se centra en los
detalles de procedimiento de cada mdulo indi%idualmente.
+/iste una relacin entre la estructura y el procedimiento. -a representacin del
procedimiento del soft!are se distribuye en capas.
DISENO @ CALIDAD DEL SOFTWARE
2e sugieren tres caractersticas que sir%en de directrices para e%aluar un buen dise,o3
1. +l dise,o debe implementar todos los requisitos e/plcitos contenidos en el
modelo de anlisis y debe acomodar todos los requisitos que desea el cliente.
2. +l dise,o debe ser una gua que pueda leer y entender los que construyan el
cdigo y los que prueban y mantienen el soft!are.
3. +l dise,o debe proporcionar una completa idea de lo que es el soft!are,
enfocando los dominios de datos, funcional y de comportamiento desde la
perspecti%a de la implementacin.
?1
UNIDAD V: CODIFICACIN
DEFINICIN
+s un proceso que transforma el dise,o e un lengua(e de programacin, es decir que
traduce una representacin del soft!are, dado por un dise,o detallado a una reali&acin
en un lengua(e de programacin. +stos tienen un %ocabulario limitado, una gramtica
definida e/plcitamente y regla bien formadas de sinta/is y semntica.
+l persona(e principal de esta etapa es el programador, quien se dedica a la creacin del
soft!are= antiguamente era muy coti&ado pero actualmente su traba(o a perdido muco
%alor.
CLASIFICACIN DE LOS LEN/UAGES DE PRO/RAMACIN
A. Se#On su #enera%:n
1. -engua(e de 1ra Leneracin )binarios*3 +s un lengua(e a ni%el de mquina )+(.
6ar(etas perforadas*
2. "ssembler3 -engua(e simblico, cuyas instrucciones se e/presan utili&ando
nemotcnicos.
3. -engua(es de 3ra Leneracin )de alto ni%el*3 6oman palabras del lengua(e
umano, y con esto se logra reali&ar instrucciones de la computadora. 2on instrucciones
generalmente e/presadas en ingles. "dems tienen notaciones matemticas de uso
com.n. Dentro de esta generacin se encuentran3
3.1 -engua(es de alto ni%el no estructurados )5GNG-*
3.2 -engua(es de alto ni%el estructurados3 2e di%ide el programa en
mdulos o procedimientos )Pascal, 5WW*, con el fin de solucionar el
problema de manera ms fcil.
<. -engua(es de <ta Leneracin3 Proporcionan grandes %enta(as a los
programadores en donde a tra%s de una sola instruccin, se e(ecuta todo un con(unto de
instrucciones de lengua(es de 3ra generacin. )2M-, 'erramientas 5"2+*
?. -engua(es de ?ta Leneracin3 -engua(es orientados a la inteligencia artificial.
B. Se#On para$#!as.
1. paradigmas de estructuras de datos
2. Paradigma procedural3 Grgani&a el cdigo mediante procedimientos y
funciones )Pascal*.
?#
3. Paradigma de orientacin a ob(etos3 2e clasifican en clases con atributos
)caractersticas y mtodos )acciones, e%entos, etc.* +(. 2malltalU.
C. Se#On su 8!;to $e apl%a%:n.
1. "dministracin de datos
2. Iuncional )sentencias de tipo funciones Y Q Z*. +( "da
3. ;nteligencia artificial3 -engua(es orientados a sistemas e/pertos )2e alimentan
de sus propias interacciones. 5onstan de una base de datos de conocimientos*.
<. lengua(es orientados a la formacin. )-ogo, que es un subcon(unto del -isp*.
5onsiguen estructurar el pensamiento mediante una interfa& intuiti%a
EFICIENCIA
-os sistemas catalogados como buenos son aquellos que desde el punto de %ista de
ingeniera usan los recursos crticos )ciclos de procesador y posiciones de memoria* de
manera eficiente. 2e deben tener en cuenta tres m/imas3
1. -a eficiencia es un requisito de rendimiento, que se debe establecer durante el
anlisis de requisitos del soft!are. +l soft!are debe ser tan eficiente como se
requiera, no tan eficiente como sea posible.
2. -a eficiencia se incrementa con un buen dise,o.
3. -a eficiencia del cdigo y la simplicidad %an de la mano. 9o ay que sacrificar
la calidad, la legibilidad, procurando me(orar la eficiencia que no sean
esenciales.
INTE/RACIN
-a integracin es el proceso por el cual se construye la estructura del programa,
asociando los mdulos para su interaccin, en coerencia con lo establecido en la etapa
de Dise,o.
;ntegracin topAdo!n o descendente3 5onsiste en la integracin de los mdulos
mo%indose acia aba(o por la (erarqua de control, comen&ando con el modulo de
control principal )programa principal*. -os mdulos subordinados al modulo de control
principal se %an incorporando en la estructura, en forma3
PrimeroAenAprofundidad3 integra todos los mdulos de un camino de control
principal de la estructura.
?H
PrimeroAenAancura3 ;ncorpora todos los mdulos directamente subordinados a
cada ni%el, mo%indose de forma ori&ontal.
;ntegracin bottonAup o ascendente3 +mpie&a la construccin con los mdulos atmicos,
o sea, de los ni%eles ms ba(os de la estructura del programa. -a principal des%enta(a es
que el programa como 7entidad8 no e/iste asta que se aya a,adido el .ltimo mdulo.
CRITERIOS DE SELECCIN
Para la eleccin de un lengua(e de programacin para un proyecto especfico se debe
tener en cuenta todas las caractersticas de ingeniera, como las psicolgicas. 2in
embargo, el problema asociado con la eleccin puede desaparecer si solo se dispone de
un lengua(e, o si el mismo es impuesto por el cliente.
+ntre los criterios que se aplican durante la e%aluacin de los lengua(es disponibles3
1. Kreas de aplicacin general.
2. 5omple(idad algortmica y computacional
3. +ntorno en que se e(ecutar el soft!are
<. 5onsideraciones de rendimiento
?. 5omple(idad de las estructuras de datos
0. 5onocimiento del grupo de desarrollo de soft!are
1. Disponibilidad de un buen compilador o compilador cru&ado
DOCUMENTACIN DEL CDI/O
-a documentacin interna del cdigo fuente ace referencia a los comentarios que se
a,aden al mismo para asegurar su legibilidad y comprensin por parte de los
desarrolladores.
5onsiste con la eleccin apropiada de los identificadores )%ariables, etiquetas, etc.*,
contin.a con la locali&acin y la composicin de los comentarios y termina con la
organi&acin %isual del programa.
2ERRAMIENTAS CASE
-as erramientas 5"2+ se clasifican en3
0$
@pper 5"2+3 2on erramientas de computadoras para ingeniera de soft!are, que
asisten a la gestin del proyecto )seguimiento, administracin, planificacin, recursos,
etc.*. +T. >icrosoft Pro(ect.
>iddle 5"2+3 2oft!are para lle%ar a cabo el anlisis y dise,o del soft!are, asistiendo a
las %alidaciones de la metodologa W erramientas grficas. +T. >icrosoft Oisio.
-o!er 5"2+3 2oft!are generador de cdigo. +(. Lene/us, 5larion, Gracle, etc.
01
UNIDAD VI: PRUEBA
DEFINICIONES
-a Prueba es un proceso por el cul se e(ecuta un soft!are con la intencin de descubrir
errores. +s un elemento crtico para la garanta de calidad del soft!are y representa una
re%isin final de las especificaciones de dise,o y de la codificacin. -a prueba no
garanti&a la ausencia de errores.
Los 4un$a!entos $e la prue;a $e so4t5are $e4nen los o;CetEos esen%ales $e la
prue;a $e so4t5are.
Un Caso $e Prue;a es el con(unto de %alores de %ariables y condiciones lgicas que
fuer&an la e(ecucin del soft!are de una manera determinada.
6n buen caso de prueba es a!uel !ue tiene una alta probabilidad de mostrar un error
no descubierto +asta entonces&
6na prueba es e$itosa si descubre un error no detectado a7n&
02
FluCo $e n4or!a%:n en la prue;a
PRINCIPIOS DE LA PRUEBA IB6SICOSJ
Para el dise,o de casos de prueba efecti%os, se deber entender los principios bsicos
que guan a las pruebas3
" todas las pruebas se les debera poder acer un seguimiento asta los
requisitos del cliente. 2e entiende que los defectos ms gra%es son los que
impiden al programa cumplir sus requisitos.
-as pruebas deberan planificarse muco antes de que empiecen. -a
planificacin de las pruebas puede empe&ar tan pronto como est completo el
>odelo de :equisitos. -a definicin detallada de los casos de prueba pueden
empe&ar tan pronto como el >odelo de Dise,o sea consolidado.
Coificacin
Prue;a
Soft=are
Prue;a
!nstalacin
Soft=are
>aliao
Prue;a
Plan e
Prue;as
Prue;a
Depuracin
Soft=are
con errores
Soft=are
Corre0io
Prue;a
!nice e
errores
03
+l principio de Pareto es aplicable a la prueba de soft!are. +l #$J de los
errores descubiertos en las pruebas surgen del 2$J del total de mdulos del
soft!are.
-as pruebas deberan empe&ar por lo peque,o y progresar acia lo grande.
9o son posibles las pruebas e/austi%as. +s imposible e(ecutar todas las
combinaciones posibles de caminos durante las pruebas. +s posible, sin
embargo, cubrir adecuadamente la lgica del programa y asegurarse que se
an aplicado todas las condiciones del dise,o procedimental.
Para ser ms efecti%as, las pruebas deberan ser conducidas por un equipo
independiente.
PRUEBAS DE CAGA BLANCA
+s un mtodo de dise,o de casos de prueba que usa la estructura de control del dise,o
procedimental para obtener los casos de prueba. >ediante los mtodos de prueba de
ca(a blanca se pueden obtener casos de prueba que3
1. Laranticen que se e(ercita por lo menos una %e& todos los caminos
independientes de cada mdulo.
2. +(erciten todas las decisiones lgicas en sus %ertientes %erdaderas y falsas.
3. +(ecuten todos los bucles en sus lmites y con sus lmites operacionales.
<. +(erciten las estructuras internas de datos para asegurar su %alide&.
-as pruebas de ca(a blanca se aplican sobre los detalles procedimentales. 2e centran en
la +structura de 5ontrol de la e(ecucin del programa. 2on [pruebas a peque,a escala[.
>todos
5amino bsico
Pruebas de condiciones
Prueba de flu(o de datos
Prueba de bucles
M1to$o $e %a!no ;8s%o
Permite obtener una medida de la comple(idad lgica de un dise,o procedimental y usar
esa medida como gua para la definicin de un con(unto bsico de caminos de
e(ecucin.
0<
Secuencia
Conicin !#
6:ile
1epeat
-os casos de prueba deri%ados del con(unto bsico garanti&an que durante la prueba se
e(ecuta por lo menos una %e& cada sentencia del programa.
Pasos
1. Definir el Lrafo de Ilu(o
2. Determinar 5omple(idad 5iclomtica
3. Determinar 5(to. Nsico de caminos linealmente independientes
<. Preparar los casos de prueba.
'J 9otacin del Lrafo3
9odo3 :epresenta una o ms sentencias procedimentales. 2i representa una condicin
lgica se llama 9odo Predicado.
"rista3 :epresenta el flu(o de control en la e(ecucin del soft!are.
:egin3 Krea delimitada por aristas y nodos. 5uando las contabili&amos un grafo
incluimos el rea e/terior.
0?
,J 5omple(idad 5iclomtica3 O)L* se calcula como3
a. O)L* Q 5antidad de regiones del grafo
b. O)L* Q " A 9 W 2
c. O)L* Q P W 1 5on P cantidad de nodos predicados.
LJ Para determinar los caminos linealmente independientes comen&ar por aquellos que
nos lle%en ms rpidamente al nodo final.
MJ Para probar, no siempre se puede aislar todos los caminos determinados, sino que
algunos se prueban como parte de la prueba de otros.
Prue;a $e %on$%:n
+(ercita las condiciones lgicas contenidas en el mdulo de un programa.
Prue;a $e ;u%le
5onsiste en descubrir los ciclos repetiti%os y e(ecutarlos asta el lmite para determinar
errores.
Prue;a $e 4luCo $e $atos
5onsiste en imaginar el camino que %a a seguir un dato dentro del cdigo, es decir sus
transformaciones.
PRUEBAS DE CAGA NE/RA
2e centra en los requisitos funcionales del soft!are, es decir, permite obtener con(untos
de condiciones de entrada que e(erciten completamente todos los requisitos funcionales
del programa. 9o es una alternati%a a las tcnicas de ca(a blanca, sino que se trata de un
enfoque complementario que intenta descubrir diferentes tipos de errores que los
mtodos de ca(a blanca.
-a prueba de ca(a negra intenta encontrar errores seg.n las siguientes categoras3
1. Iunciones incorrectas o ausentes.
2. +rrores de interfa&
3. +rrores en estructuras de datos o en accesos a bases de datos e/ternas.
00
<. +rrores de rendimiento.
?. +rrores de iniciali&acin y de terminacin.
>todos
Particin equi%alente
Oalor limite
Lrafo causa 4 efecto
5omparacin
Part%:n e9uEalente
+s un mtodo que di%ide el dominio de entrada de un programa en clases de datos de los
que se pueden deri%ar casos de pruebas, para as determinar clases de errores sobre estos
con(untos de datos.
Valor l3!te
+sta tcnica se complementa con la particin equi%alente, y en lugar de seleccionar
cualquier elemento de una clase de equi%alencias, el "O- lle%a a la eleccin de casos de
prueba en los e/tremos de la particin. +n lugar de centrarse .nicamente en las
condiciones de entrada, el "O- obtiene casos de prueba tambin para el campo de
salida.
/ra4o %ausaPe4e%to
2on tablas y grficos donde figuran los efectos de cada una de las decisiones. 2e
documenta el comportamiento del soft!are por medio de un rbol.
Prue;a $e %o!para%:n
2e lle%a a cabo la comparacin de dos sistemas informticos
a. +l construido con el sistema manual.
b. +l construido con el de un tercero.
DISENO DE CASOS DE PRUEBA
5ualquier producto de ingeniera puede comprobarse mediante estas dos formas3
a* 5onociendo la Iuncin
01
C
D
1
S
?
!
>
S
0n1enier6a del 7iste#a
*e,-isitos
.ise/o
Codificaci)n
%r-eba de 2nidad
%r-eba de 0nte1raci)n
%r-eba de Validaci)n
%r-eba del siste#a
2e preparan pruebas que demuestren que la funcin es alcan&ada plenamente.
b* 5onociendo el funcionamiento
2e preparan pruebas que demuestren que la operacin interna se a(usta a las
especificaciones y que todos los componentes internos se an probado adecuadamente.
ESTRATE/IAS DE PRUEBA
+strategias y tcticas permiten reali&ar un plan. 2us diferencias son3
6ctica consiste en el ordenamiento y planificacin interna.
+strategia consiste en el ordenamiento y planificacin acia el conte/to.
@na estrategia de prueba del soft!are integra las tcnicas de dise,o de casos de prueba
en una serie de pasos bien planificados que dan como resultado una correcta
construccin del soft!are. Y lo que es ms importante, una estrategia de prueba de
soft!are proporciona un mapa a seguir para el responsable del desarrollo de soft!are, a
la organi&acin de control de calidad y al cliente como parte de la prueba, cundo se
deben planificar y reali&ar esos pasos, y cunto esfuer&o, tiempo y recursos se %an a
requerir.
VALIDACIN @ VERIFICACIN
-a %alidacin consiste en el cequeo de la funcionalidad del soft!are. C+stamos
construyendo el producto correctoE
Oerificacin est orientada a la %erificacin de la construccin adecuada del soft!are.
C+stamos construyendo el producto correctamenteE
+stos conceptos son la gua para asegurar la calidad del soft!are= requieren ms que el
proceso de prueba, pero ste es el que puede e%aluar la calidad y de forma prctica
descubrir errores.
0#
+l proceso de ingeniera de soft!are se puede %er como un espiral, donde al mo%erse
acia adentro, se recorren las diferentes etapas.
6ambin se puede obser%ar la estrategia de prueba del soft!are aplicable a cada una de
estas etapas.
Pruebas de unidad
5entra el proceso de Eer4%a%:n en la menor unidad de dise,o de soft!are3 el mdulo.
2e reali&an aqu pruebas de ca(a blanca y se puede lle%ar a cabo en paralelo para
m.ltiples mdulos.
Prueba de integracin
5onsiste en la prueba de cada uno de los mdulos en su interaccin, donde el foco de
atencin es el dise,o y construccin de la arquitectura de soft!are.
Prueba de %alidacin
2e e%al.a si el soft!are funciona de acuerdo con las e/pectati%as ra&onables del cliente.
Para ello, se debe comparar con el anlisis de requerimientos. 2e reali&an pruebas alfa
)pruebas en el lugar del desarrollo de soft!are* y Neta )pruebas por el usuario final en el
lugar del traba(o*.
Prueba de sistema
Iinalmente el soft!are es incorporado a los otros elementos del sistema de informacin.
2e prueba como un todo el soft!are con otros elementos de dico sistema.
0H
UNIDAD VII: INSTALACIN @ MANTENIMIENTO
INSTALACIN
+s el proceso mediante el cual se pone en produccin el soft!are creado. Debe ser
planificado como cada una de las tareas de ingeniera de soft!are. Para eso se tiene en
cuenta los siguientes aspectos3
5apacitacin
"mbiente
5on%ersin
Capa%ta%:n
+s la acti%idad por la cual se asegura que el soft!are ser apro%ecado por los usuarios.
+stos deben conocer con detalle cuales sern sus roles, cmo pueden usar el sistema, y
qu ar o no ar el sistema.
5onsideraciones sobre la capacitacin
a. @suarios3 +/isten diferentes tipos de usuarios3
1. Iinales3 Deben tener capacidad para apro%ecar de manera
adecuada el soft!are.
2. "dministradores3 "dems, deben tener capacidad para
instalaciones de nue%as %ersiones del soft!are, primeras
soluciones, etc.)para el mantenimiento del soft!are*
3. Lerenciales o indirectos3 2on aquellos que piden reportes y
tambin deben ser capacitados. 9o mane(an el sistema, pero si
se benefician con el mismo.
b. -ugar de capacitacin3
1. Dentro de la empresa3 se cuenta con la %enta(a de conocer el
lugar, se tiene mayor comodidad
2. Iuera de la empresa3 puede implicar costos adicionales de
tiempo y dinero, por el lugar de capacitacin.
c. >aterial a entregar3 ;mplican gastos para su creacin y distribucin. Pueden
ser3
1. >anuales de usuario
2. >anuales tcnicos
1$
A!;ente
2e debe asegurar que el ambiente donde se instalar el 2oft!are sea apto para ello. Por
esto, es con%eniente estudiar pre%iamente sus condiciones con tiempo.
ConEers:n
+/isten diferentes tipos de con%ersiones.
a. De sistemas3 +s el proceso de cambiar el sistema anterior por el nue%o,
contando con mtodos y procedimientos para asegurarse que se lle%e a cabo
adecuadamente. +/isten dos formas3
1. Directa3 -a con%ersin se lle%a a cabo de manera abrupta. 2e usa el
sistema anterior asta un da de con%ersin ya planificado, en el cual
es reempla&ado por el nue%o. 2e corre el riesgo de que el nue%o
soft!are falle.
2. Paralela3 5onsiste en utili&ar ambos sistemas en paralelo. +s decir,
los usuarios siguen operando el sistema anterior, pero tambin
comien&an a usar el nue%o. +ste es el mtodo de con%ersin ms
seguro, ya que garanti&a que, en caso de surgir problemas, la
organi&acin pueda regresar al sistema anterior, ingresos, etc. 2u
des%enta(a es que los costos de sistema se duplican. 6ambin, los
usuarios pueden presentar resistencia al cambio.
b. De datos3 ;mplica traducir los datos del formato del sistema de informacin
anterior, al nue%o. +l problema surge cuando las tecnologas son incompatibles. Por otro
lado ay que asegurarse que la con%ersin de datos est o no incluida dentro del
presupuesto.
11
MANTENIMIENTO
+s el proceso posterior a la instalacin que trata de e/tender la %ida .til del soft!are en
el tiempo. +sta fase %uel%e a aplicar los pasos de las fases de definicin y de desarrollo,
pero en el conte/to del soft!are ya e/istente. 2e encuentran cuatro tipos de cambio3
Manten!ento %orre%tEo
+s muy probable que el cliente descubra defectos en el soft!are. +ste mantenimiento se
encarga de corregirlos.
Defecto3 Iuncionalidad inapropiada
+rror3 2oft!are mal eco, por lo que se lo considera ms serio
que el defecto.
+l ni%el de fallos nunca llega a cero, puesto que siempre ay errores nue%os.
Manten!ento preEentEo
;ntenta planificar acti%idades que aseguren la larga %ida del soft!are. +(. -impie&a.
+/iste un con(unto de acti%idades para asegurar un comportamiento estable del
soft!are, que estn relacionadas con la tecnologa utili&ada. +l mantenimiento
pre%enti%o ace cambios en programas de computadora a fin de que se puedan corregir,
adaptar y me(orar fcilmente. +(. +l bacUup es una acti%idad de mantenimiento
pre%enti%o. -a periodicidad es un aspecto muy rele%ante y est su(eto a3
"spectos tecnolgicos3 si crece demasiado, puede superar su capacidad fsica.
"specto funcional3 2i los datos son muy sensibles, mayor debe ser la frecuencia.
Manten!ento a$aptatEo
5onsiste en la modificacin del soft!are para acomodarlo a los cambios de su entorno
e/terno. +(. 5ambio del porcenta(e del ;O".
Manten!ento per4e%tEo
Permite ampliar el soft!are a una realidad ms grande, es decir, lle%a al soft!are ms
all de sus requisitos funcionales originales.
DIFICULTADES DEL MANTENIMIENTO
12
2e deben a las deficiencias de la forma en que el soft!are a sido definido y
desarrollado. +ntre ellas encontramos3
1. +s difcil o imposible a menudo seguir la e%olucin del soft!are a tra%s de
%arias %ersiones.
2. Difcil o imposible seguir el proceso por el que se construy el soft!are.
3. +/cepcionalmente difcil comprender un programa a(eno.
<. +l personal desarrollador no siempre se encuentra disponible
?. 9o e/iste documentacin apropiada, o est mal preparada
0. -a mayora del soft!are no a sido dise,ado pre%iniendo el cambio.
1. +l mantenimiento no se %e como un mantenimiento atracti%o.
13