EVALUACIN Y OPTIMIZACIN DEL

RENDIMIENTO EN APLICACIONES.

Rendimiento desde el diseo de una aplicacin.

 Planear para mejorar el rendimiento de
aplicaciones
La consecucin de los objetivos de rendimiento depende
de lo bien que desarrolle su estrategia de rendimiento. La
planeacin es la primera fase del desarrollo de cualquier
producto. En este tema se describen algunas reglas muy
simples para desarrollar una estrategia de rendimiento
acertada.
 1. Pensar en trminos de escenarios
Los escenarios pueden ayudarle a centrarse en los
componentes crticos de la aplicacin.
Los escenarios suelen derivarse de los clientes, as como de
los productos de la competencia. Estudie siempre a sus
clientes y averige qu es lo que les interesa de su producto y
de los productos de la competencia.
Los comentarios de sus clientes pueden ayudarle a determinar
el escenario principal de la aplicacin.
Por ejemplo, si va a disear un componente que se usar en el
inicio, es probable que solamente se llame a este componente
una vez, cuando se inicia la aplicacin. En este caso, el
escenario clave es el momento del inicio. Otros ejemplos de
escenarios clave podran ser la velocidad de los fotogramas en
las secuencias de animacin o el espacio de trabajo mximo
permitido para la aplicacin.
2. Definir los objetivos
Los objetivos le ayudan a determinar si el rendimiento de
una aplicacin es superior o inferior. Debe definir
objetivos para todos los escenarios.
Todos los objetivos de rendimiento que defina debern
basarse en las expectativas de sus clientes. Puede ser
difcil establecer los objetivos de rendimiento desde el
principio del ciclo de programacin, cuando todava
quedan muchos problemas sin resolver. Sin embargo, es
mejor fijar un objetivo inicial y revisarlo posteriormente
que no tener ningn objetivo en absoluto.
3. Entender la plataforma
Mantenga en todo momento el ciclo de medir, investigar,
refinar y corregir durante el ciclo de programacin de la
aplicacin.
Desde el principio hasta el final del ciclo de programacin, es
preciso medir el rendimiento de la aplicacin en un entorno
confiable y estable. Debe evitar las variaciones producidas por
factores externos.
Por ejemplo, al realizar pruebas de rendimiento, debe
deshabilitar los antivirus y las actualizaciones automticas,
como SMS, para que no afecten a los resultados de dichas
pruebas. Despus de medir el rendimiento de la aplicacin,
deber identificar los cambios que darn lugar a las mayores
mejoras. Cuando haya modificado la aplicacin, inicie de nuevo
el ciclo.
4. Convertir el ajuste del rendimiento en un
proceso reiterativo
Debe conocer el costo relativo de cada caracterstica que
va a utilizar.
Por ejemplo, el uso de la reflexin en Microsoft .NET
Framework suele afectar intensamente al rendimiento
por lo que se refiere a los recursos informticos, de
modo que es importante utilizarla juiciosamente. Esto no
significa que haya que evitar el uso de la reflexin,
nicamente que debe asegurarse de equilibrar los
requisitos de rendimiento de la aplicacin con las
exigencias de rendimiento de las caractersticas que
utilice.
5. Aumentar progresivamente la riqueza
grfica
Una tcnica clave para crear un enfoque escalable que permita
lograr un rendimiento adecuado de las aplicaciones de
WPF(Windows Presentation Foundation) es aumentar
progresivamente la riqueza grfica y la complejidad.
Empiece siempre utilizando los recursos que menos afectan al
rendimiento para lograr los objetivos del escenario. Cuando
haya logrado estos objetivos, aumente progresivamente la
riqueza grfica mediante caractersticas que afectan con mayor
intensidad al rendimiento, teniendo siempre presentes los
objetivos del escenario. Recuerde que WPF es una plataforma
extremadamente completa que proporciona caractersticas
grficas muy ricas.
6. Aumentar progresivamente la riqueza
grfica
El uso irreflexivo de caractersticas que afectan
intensamente al rendimiento puede impactar
negativamente en el rendimiento de la aplicacin en su
conjunto.
La extensibilidad es inherente a los controles de WPF, lo
que permite una personalizacin generalizada de su
aspecto sin modificar su comportamiento de
control.Aprovechando los estilos, las plantillas de datos y
las plantillas de control puede crear y modificar
gradualmente una interfaz de usuario (UI) personalizable
adaptada a los requisitos de rendimiento.
Creacin y Evolucin de Sistemas

Rendimiento desde el diseo de una aplicacin.

 Creacin y Evolucin de Sistemas
La "Creacin y Evolucin de Sistemas" describe de
manera global las distintas fases que componen el ciclo de
vida de un proyecto software, desde el inicio hasta la
finalizacin del mismo, especificando los objetivos y
entregables a generar en cada una de las fases.

Para desarrollar un sistemas siempre es aconsejable

seguir algn modelo de produccin de software que ms
se ajuste a proyecto a desarrollar a continuacin
explicamos el modelo en V y el Modelo en W.
 Modelos en V
El Mtodo-V define un procedimiento uniforme para el desarrollo de
productos para las TIC. Es el estndar utilizado para los proyectos
de la Administracin Federal Alemn y de defensa. Como est
disponible pblicamente muchas compaas lo usan. Es un mtodo
de gestin de proyectos comparable a PRINCE2 y describe tanto
mtodos para la gestin como para el desarrollo de sistemas.
El Mtodo-V fue desarrollado para regular el proceso de desarrollo
de software por la Administracin Federal Alemana. Describe las
actividades y los resultados que se reducen durante el desarrollo del
software.
El Mtodo-V es una representacin grfica del ciclo de vida del
desarrollo del sistema. Resume los pasos principales que hay que
tomar en conjuncin con las correspondientes entregas de los
sistemas de validacin.
 La parte izquierda de la V representa la corriente donde se definen las
especificaciones del sistema. La parte derecha de la V representa la corriente
donde se comprueba el sistema (contra las especificaciones definidas en la
parte izquierda). La parte de abajo, donde se encuentran ambas partes,
representa la corriente de desarrollo.
La corriente de especificacin consiste principalmente de:
Especificaciones de requerimiento de usuario
Especificaciones funcionales
Especificaciones de diseo
La corriente de pruebas, por su parte, suele consistir de:
Calificacin de instalacin
Calificacin operacional
Calificacin de rendimiento
Los proyectos llegan finalmente a ser exitosos desde los puntos de vista
de objetivos de negocio, costos, funcionalidad, sencillez y capacidad de
soporte. La corriente de desarrollo puede consistir (depende del tipo de
sistema y del alcance del desarrollo) en personalizacin, configuracin
o codificacin.
 Qu pensaras de m si empezara a poner ladrillos
por que s para construir una casa?
En qu casos la utilizo?
En que consiste exactamente?
Qu pensaras de m si empezara a
poner ladrillos
sin antes haber hecho un estudio...
...del suelo, materiales, recursos, y sin haber hecho un
diseo previo? Pensaras de m, lo mismo que yo pienso
de la gente que se pone a programar sin seguir una
metodologa de programacin.
La metodologa es el Modelo en V, o Modelo de Cuatro
Niveles.
 En qu casos la utilizo?
Se trata de un proceso ideal, por su robustez, para
proyectos pequeos, con equipos de una a cinco
personas.
Tambin es ideal, por su claridad, para toda esa gente que
nunca ha programado siguiendo una metodologa. Para el
proyecto final de carrera o para ese cliente que te ha
conseguido un amigo de un amigo que te lo pide a ti y no
se dirige a una empresa por esto de la desaceleracin.
En que consiste exactamente?
La figura que aparece a continuacin presenta el Modelo
en V, o Modelo de Cuatro Niveles, del ciclo de vida de un
proyecto de desarrollo de software. El modelo
representa, en forma de V, las relaciones temporales entre
las distintas fases del ciclo de desarrollo de un proyecto.
En que consiste exactamente?
En que consiste exactamente?
En los niveles lgicos del 1 al 4, para cada fase del
desarrollo, existe una fase correspondiente o paralela de
verificacin o validacin. Esta estructura obedece al
principio de que para cada fase del desarrollo debe existir
un resultado verificable.
En la misma estructura se advierte tambin que la
proximidad entre una fase del desarrollo y su fase de
verificacin correspondiente va decreciendo a medida
que aumenta el nivel dentro de la V. La longitud de esta
separacin intenta ser proporcional a la distancia en el
tiempo entre una fase y su homloga de verificacin.
En que consiste exactamente?
El nivel 1 est orientado al cliente. El inicio del proyecto y el
fin del proyecto constituyen los dos extremos del ciclo. Se
compone del anlisis de requisitos y especificaciones, se
traduce en un documento de requisitos y especificaciones.
El nivel 2 se dedica a las caractersticas funcionales del sistema
propuesto. Puede considerarse el sistema como una caja negra,
y caracterizarla nicamente con aquellas funciones que son
directa o indirectamente visibles por el usuario final, se
traduce en un documento de anlisis funcional.
El nivel 3 define los componentes hardware y software del
sistema final, a cuyo conjunto se denomina arquitectura del
sistema.
El nivel 4 es la fase de implementacin, en la que se desarrollan
los elementos unitarios o mdulos del programa.
 Tengo que hacer documentacin de todo?
Por qu utilizar una metodologa?
Tengo que hacer documentacin de
todo?
Por supuesto. Cada fase tiene que estar respaldada por su
documento correspondiente y test.
Por qu utilizar una metodologa?
Porque es lo ms rpido y barato.Volviendo al ejemplo de
la casa, imagina la cantidad de veces que debera volver
atrs y tirar paredes ya hechas porque de pronto
descubro que el suelo es inestable, la baera no cabe, la
instalacin elctrica no la haba tenido en cuenta
Pues, con el cdigo pasa exactamente lo mismo.
 Modelo en W
El modelo en W es una evolucin del modelo en V.
Ms que aportar algo nuevo lo que pretende es aclarar ciertos
aspectos que el modelo en V no termina de dejar claros (si
bien bastantes de las caractersticas del modelo en W ya eran
de aplicacin en el modelo en V).
En el modelo en V tenemos dos secuencias de pasos, una se
consideraba que era de carcter constructivo, la primera recta
de la V y la segunda de carcter destructivo (en el mejor de los
casos, si ha pasado el test se continua hacia adelante), lo cual
segua marginando en cierto modo las actividades de testing,
algo que precisamente intentaba evitar el modelo en V, al situar
las mismas a la misma altura y a la vez que las de desarrollo.
Modelo en W
En este caso tenemos dos V, una correspondiente al
proceso de desarrollo y otra correspondiente al proceso
de testing. Hay quienes piensan y tal vez no les falte razn
que aadir una V especfica para el testing lo nico que ha
hecho es trasladar el mismo defecto a otra dimensin, ya
que vamos a seguir teniendo un caso donde se construye
y otro donde se fiscaliza, si bien, el hecho de que este
modelo integre explcitamente las vueltas a atrs acerca
ms ambos tipos de tareas.
Modelo en W
Y es lgico que sea as porque todos sabemos que es
muy complicado (por no decir casi imposible) acertar a la
primera, por lo que el proceso de verificacin, feedback y
ajuste debe entenderse como un proceso integrado en el
desarrollo y no como tareas independientes y
enfrentadas.
Modelo en W
Entonces, si tenemos ahora dos V, qu representa el lado
creciente de cada una de ellas. Pues realmente lo que
hace el modelo en W es diferenciar claramente cules
son los hitos de un proyecto software (algo que poda
resultar confuso en el modelo en V) de manera que en la
primera recta estn los hitos previos a la construccin del
software (con las pruebas y verificaciones
correspondientes a los hitos documentales) y en la
segunda los posteriores a la construccin del software
(verificacin sobre el producto software).
Modelo en W
Entonces, si tenemos ahora dos V, qu representa el lado
creciente de cada una de ellas. Pues realmente lo que
hace el modelo en W es diferenciar claramente cules
son los hitos de un proyecto software (algo que poda
resultar confuso en el modelo en V) de manera que en la
primera recta estn los hitos previos a la construccin del
software (con las pruebas y verificaciones
correspondientes a los hitos documentales) y en la
segunda los posteriores a la construccin del software
(verificacin sobre el producto software).
Modelo en W
El modelo en W contempla los procesos definidos por Mtrica
v3, aadiendo adems al modelo en V una revisin de las fases
de desarrollo y una depuracin y correccin de los posibles
errores detectados en las fases de pruebas. As, el modelo en
W refleja mejor la interdependencia que existe entre equipo
de proyecto, el equipo de testing y el rea usuaria a lo largo de
todo el proceso de desarrollo del sistema, donde bsicamente:
En las primeras etapas se consideran las fases de desarrollo y
algunas labores de pruebas como son la elaboracin de los
planes de prueba y la revisin de estas fases.
En las etapas finales se desglosan las fases de pruebas y las
labores de depuracin y correccin de los errores detectados.
Las peticiones de cambio se pueden dar en todas las fases de
desarrollo y surgen por el cliente o por el propio equipo de
desarrollo.
Modelo en W
La siguiente figura representa el mo delo de
desarrollo en W:
W exterior, corresponde a las fases del desarrollo
software.
W interior, hace referencia a las fases de testing
(distinguindose las fases de testing temprano de las
de testing de software)
Modelo en W
 Trabajo en Clase
Realizar un resumen de la fases del modelo W
incluyendo las pruebas y documentos entregables por
fase.