miércoles, 9 de enero de 2013

METRICAS DISEÑO PARA WEBAPPS

Las metricas deben ofrecer respuestas cuantitativas a las siguientes preguntas:

  • ¿La interfaz de usuario  promueve la facilidad de uso? 
  • ¿La estetica de la WebApp  es apropiada para el dominio de la aplicacion  y confortable al uso? 
  • ¿El contenido  esta diseñado en una forma que proporciona mayor informacion  con  el menor esfuerzo? 
  • ¿la navegacion es eficiente y directa? 
  • ¿La arquitectura de la WebApp se ha diseñado  para acomodar  las metas  y objetivos  especiales  de los usuarios  de la WebApp  la estructura de contenido y funcionalidad y el flujo  de navegacion  requerido  para usar el sistema de manera efectiva? 
  • ¿ Los componentes estand diseñado en una forma que reduce  la complejidad  y aumenta la exactitud, la confiabilidad y el desempeño?
Hasta el momento no existe un conjunto de metricas cuantitativas por lo que estos deben ser tratados de manera cualitativa.  


El diseño web abarca actividades tecnicas y otras que no lo son. La vision y el sentido del contenido se desarrolan como parte del diseño grafico, la plantilla estetica de la interfaz de usuario se crea como  parte de diseño de la interfaz y la estructura tecnica de la webapp se modela como parte del diseño arquitectonico  y de navegacion.

La webapps abarca seis diferentes tipos de diseño cada uno contribuye a la calidad global de la web esto se puede ver por medio de la piramide siguiente:
Métricas de interfaz
Para webapps pueden considerarse las siguientes medida
  • Corrección de plantilla
  • Tiempo de reconocimiento 
  • Complejidad de selección
  • Tiempo de adquisición de contenido ...Etc
Los principios y directrices esenciales del diseño de una WebApp se pueden mencionar:
  • Uso equitativo
  • Flexibilidad en el uso
  • Uso sencillo e intuitivo
  • Información perceptible
  • Tolerancia al error
  • Esfuerzo físico reducido
  • Tamaño y espacio para acercarse y usar
Métricas estéticas 
Se apoya en el juicio cualitativo y por lo general no es sensible a la medición ni a las métricas.
Sin embargo Ivory propone un conjunto de medidas que pueden ser útiles para valorar enl impacto del diseño estético.
El diseño estético, también llamado diseño grafico, es un esfuerzo artístico que complementa los aspectos técnicos de la ingeniería Web. Sin él una WebApp puede ser funcional, pero sin atractivo. 

Métricas de contenido
Se enfoca en la complejidad del contenido y en los grupos de contenido que se organizan en páginas.
El diseño de contenido se enfoca en dos asuntos de diseño diferentes, cada uno lo abordan individuos con distintos conjuntos de habilidades. El diseño de contenido desarrolla una representación de diseño para los objetos de contenido y representa los mecanismos que se requieren para que establezcan sus relaciones uno con otro. 

Métricas de navegación
Abordan la complejidad del flujo de navegación.
En general, son útiles sólo para aplicaciones web estáticas, que no inclyen vínculos y áginas generados de manera dinámica. 
El diseñador debe definir las rutas de navegación que habiliten para la ruta de los usuarios el acceso al contenido y las funciones de las WebApp. Para ello se debe:
  • Identificar la semántica de navegación para diferentes usuarios del sitio
  • Definir la mecánica que logra la navegación.
INGENIERIA  SOFTWARE
METRICAS DE PRODUCTO
Un elemento fundamental en el proceso de ingenierìa es la mediciòn.
Se pueden usar medidas para valorar la calidad de los productos o sistemas sometidos a ingenierìa que se construyen.
Las mediciones y mètricas del software con frecuencia son indirectas, estan abieratas a debate.

Fenton9 aborda este conflicto cuando afirma:
"Es un proceso en el que se asignan nùmeros o simbolos a los atributos de las entidades en el mundo real".

Aunque las mètricas de producto para el software de computadoras son imperfectas, pueden proporcionar una forma sistemàtica de valorar la calidad con base en un conjunto de reglas claramente definidas.

MARCO CONCEPTUAL PARA LAS METRICAS DE PRODUCTO
La mediciòn asigna nùmeros o sìmbolos a atributos de entidades en el mundo real.
Para que esto se logre se requiere un modelo de mediciòn que abarque un conjunto consitnte de reglas.

MEDIDAS, METRICAS E INDICADORES
En el contexto de la ingeniería de software, una medida proporciona un indicio cuantitativvo de la extención, cantidad, dimensión, capacida o tamaño de algún atributo de un producto o proceso.

La medición es el acto de determinar una medida.
Cuando se ha recolectado un solo punto de datos se establece una medida.

Un ingeniero de software recolecta medidas y desarrolla métricas de modo que se obtengan indicadores.

Un indicador es una métrica o combinación de métricas que proporcionan comprensión acerca del proceso de software.

Un indicador proporciona comprensión que permite al gerente de proyecto o a los ingenieros de software ajustar el proceso, el proyecto o el producto para hacer mejor las cosas.

PRINCIPIOS DE LA MEDICION
Las métricas de software serán útiles sólo si se caracterizan efectivamente y si se validan de manera adecuada. Los siguientes principios son representativos de muchos que pueden para la caracterización y validación de métricas.  
  • Una métrica debe tener propiedades matemáticas deseables
  • El valor de la métrica debe aumentar o disminuir en la misma forma
  • Una métrica debe medir el facrtor de interés, independientemente de otros factores

MEDICION DE SOFTWARE ORIENTADO A META
El paradigma meta/pregunta/métrica (MPM) fue desarrollado como una técnica para identificar métricas significativas para cualquier parte del proceso de software.
Destaca la necesidad de establecer un objetivo de medición que sea especifíco para la actividad del proceso o las caracteristícas del producto que se esta evaluando.
Definir un conjunto de preguntas que deben responderse con el fin de alcanzar el objeto.
Identificar métricas bien formadas que ayuden a responder esas preguntas. 
Para definir cada meta de medición, puede usarse una plantilla de definición de meta.
GESTION DE PROYECTOS
      
La gestión de proyectos es el proceso por el cual se planifica, dirige y controla el desarrollo de un sistema aceptable con un costo mínimo y dentro de un período de tiempo especifico.

La gestion de proyectos implica la planificación, supervisión y control del personal, del proceso y de los eventos  que ocurren mientras evoluciona el software desde la fase preliminar a la implementación operacional.

EL ESPECTRO DE LA GESTION
El gestor tiene a cargo al personal.  
La gestión eficaz de un proyecto de software se centra en las cuatro P´s:
  • Personal
  • Proyecto
  • Producto
  • Proceso  
Personal  
La necesidad de contar con personal para el desarrollo del software altamente altamente preparado y motivado se viene discutiendo desde los años 60.

Es necesario que el personal se capacite continuamente para ser competitivo.

El factior humano es tan importante que el Instituto de Ingeniería de Sistemas desarrollo el Modelo de madurez de la capacidad de gestión de personal (MMCGP) para llevar a cabo las cada más complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de software.

Los participantes
El proceso del software (y todos los proyectos de software) lo componen participantes que pueden clasificarse en una de estas cinco categorías:
  1. Gestores superiores, que definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto.
  2. Gestores (técnicos) del proyecto, que deben planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de software.
  3. Profesionales, que proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación.
  4. Clientes, que especifican los requisitos para la ingeniería del software y otros elementos que tienen menor influencia en el resultado. 
  5. Usuarios finales, que interaccionan con el software una vez que se ha entregado para la producción. 
Para ser eficaz, el equipo del proyecto debe organizarse de manera que maximice las habiiidades y capacidades de cada persona. Y este es el trabajo del jefe del equipo.

El equipo de software
La organización del personal esta directamente involucrado en el nuevo proyecto de software es competencia del Gestor del Proyecto

Los jefes de equipo
Es una actividad intensamente humana y por esta razón los profesionales competentes del software a menudo no son buenos jefes de equipo.

Los gestores son los que se encargan de señalar el camino a los participantes para llegar a la meta.
METODOLOGIAS
Una metodología de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de información.
 
 A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados diferenciándose por su fortaleza y debilidad.

El framework para metodología de desarrollo de software consiste en:
  • Una filosofía de desarrollo de programas de computacion con el enfoque del proceso de desarrollo de software
  • Herramientas, modelos y métodos para asistir al proceso de desarrollo de software
Estos frameworks son a menudo vinculados a algún tipo de organización, que además desarrolla, apoya el uso y promueve la metodología. La metodología es a menudo documentada en algún tipo de documentación formal.
PROCESO DE CREACION DEL SOFTWARE

Modelos del ciclo de vida de software 

Los modelos de ciclo de vida de software es una lista de las actividades que ocurren durante el desarrollo de software, en el cual se intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.

Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software.

Modelo en Cascada 
Es el predecesor de todos los modelos de ciclo de vida y ha servido de base para otros modelos. En el modelo de cascada pura  un proyecto progresa a través de una secuencia ordenada de etapas, partiendo desde su concepto inicial hasta la prueba del mismo, así el proyecto realiza una revisión al final de cada etapa para determinar si está preparado para pasar a la siguiente.
Modelo en Espiral
Es un modelo orientado a riesgos que divide un proyecto en miniproyectos, cada miniproyecto se centra en uno o más riesgos importantes hasta que todos éstos estén controlados.
El concepto “riesgo” puede referirse a requerimientos y arquitecturas poco comprensibles, a problemas de ejecución importantes o a problemas con la tecnología subyacente. Una vez que se han controlado todos los riesgos importantes, el modelo finaliza del mismo modo que el modelo de ciclo de vida en cascada. 
Modelo de prototipos de sistemas  
Este método hace que el usuario participe de manera más directa en la experiencia de análisis y diseño.
La construcción de prototipos es más eficaz bajo las circunstancias correctas sin embargo, al igual que los otros métodos, el método es útil sólo si se emplea en el momento adecuado y en la forma apropiada.
El prototipo es un sistema que funciona –no solo una idea en el papel- , desarrollado con la finalidad de probar ideas y suposiciones relacionadas con el nuevo sistema. Al igual que cualquier sistema basado en computadora, está constituido por software, que acepta entradas, realiza cálculos, produce información ya sea impresa o en pantalla, o que lleva a cabo otras actividades significativas. 
Los usuarios evalúan el diseño de información generada por el sistema y deben esperarse cambios a medida que el sistema es utilizado.

Las razones por las cuales se deben utilizar los prototipos de sistemas son que los requerimientos de información no siempre están bien definidos; los prototipos permiten evaluar situaciones extraordinarias, donde los encargados de diseñar sistemas no tienen información ni experiencia, ya que en realidad es un modelo piloto o de prueba, y es un sistema que funciona debido a que está diseñado para ser modificado con facilidad.
Modelo Evolutivo  

Es un modelo de ciclo de vida en el que se desarrolla el concepto del sistema a medida que avanza el proyecto.
Normalmente se comienza desarrollando los aspectos más visibles del sistema, posteriormente se presenta la parte ya desarrollada del sistema al cliente y se continúa el desarrollo del prototipo en base a la realimentación que se recibe del cliente. Finalmente, el ciclo continúa hasta que el prototipo se convierte en el producto final de ingeniería.
Es conveniente utilizar el prototipado evolutivo cuando los requerimientos cambian con rapidez, cuando el cliente es reacio a especificar el conjunto de los requerimientos, cuando ni el analista ni el cliente identifican de forma apropiada el área de aplicación o cuando los desarrolladores no están seguros de la arquitectura o los algoritmos adecuados a utilizar.
Modelo en V
Uno de los inconvenientes del modelo en cascada es que las pruebas del software son dejadas al final del desarrollo.
El ciclo de vida en V, es una variación del modelo en cascada que trata este problema, toma su nombre de la forma en la cual se visualiza y es una evolución del modelo en cascada en el cual se realizan actividades en paralelo y facilita las pruebas del sistema. Así, se basa en la premisa de que las pruebas de calidad no se deben dejar al final, sino realizarse a lo largo del proceso.
Modelo de Entrega por Etapas o Implementación Incremental 
El sistema se muestra al cliente en etapas refinadas sucesivamente.
A diferencia del modelo de prototipado evolutivo, se conoce exactamente qué es lo que se va a construir cuando se procede a construirlo.
Lo que hace diferente a este modelo es que el sistema no se entrega como un todo al final del proyecto, sino que éste se entrega por etapas sucesivas a lo largo del proyecto. 
INGENIERIA DE SISTEMAS
 
Tecnologías multicapas 
 
 
El proceso de la ingeniería del software: Es la unión que mantiene juntas las capas de tecnología y que permite un desarrollo racional y oportuno de la ingeniería del software. El proceso define un marco de trabajo para un conjunto de Tareas Clave.
Las áreas claves del proceso forman la base del control de gestión de proyectos del software y establecen el contexto en el que se aplican los métodos técnicos, se obtienen productos del trabajo (modelos, documentos, datos, informes, formularios, etc.)

Los métodos de la ingeniería del software: indican «cómo» construir técnicamente el software. Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. 

Las herramientas de la Ingeniería del software: Proporcionan un enfoque automático o semiautomático para el proceso y para los métodos. Cuando se integran herramientas para que la información creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado ingeniería del software asistida por computadora (CASE)