viernes, 3 de diciembre de 2010

Ingenieria del software asistida por Computadora.

¿ Que Significa CASE ?

Computer Aided Software Engineering, Ingeniería De Software Asistida por Computadora
     CASE proporciona al ingeniero la posibilidad de automatizar actividades manuales y de mejorar su visión general de la ingeniería. Al igual que las herramientas de ingeniería y de diseño asistidos por computadora que utilizan los ingenieros de otras disciplinas, las herramientas CASE ayudan a garantizar que la calidad se diseñe antes de llegar a construir el producto.

       La ingeniería del software asistida por computadora puede ser tan sencilla como una única herramienta que preste su apoyo para una única actividad de ingeniería del software, o tan compleja como todo un entorno que abarque «herramientas», una base de datos, personas, hardware, una red, sistemas operativos, estándares, y otros mil componentes más.

Marco de integración:  Es un conjunto de programas especializados  que permiten a cada herramienta CASE comunicarse con las demás.
Servicios de portabilidad: Este conjunto constituye un puente entre las herramientas CASE, su marco de integración y la arquitectura de entorno. De esta forma permiten que las herramientas CASE y su marco de integración puedan migrar a través de diferentes plataformas de hardware y sistemas operativos sin problemas de adaptación.
Sistema operativo: Gestiona el hardware, la red y las herramientas; mantiene el entorno unido.
 Plataforma hardware: Son las estaciones de trabajo individuales interconectadas mediante la red para que los ingenieros del software puedan comunicarse de forma efectiva.
Arquitectura de entorno: Es la base del CASE, en este bloque se construyen los entornos de la ingeniería del software, engloba los sistemas de software y hardware. Además considera los patrones del trabajo humano que se aplican durante el proceso de ingeniería del software.


Clasificación de las herramientas case
Las herramientas CASE se pueden clasificar bajo diferentes enfoques:
♦ Por su función
♦ Por su papel como instrumentos para el personal técnico o los directivos.
♦ Por la arquitectura del entorno que las soporta (hardware y software)
Origen
Tomando la funcionalidad como criterio principal se creó la siguiente clasificación:

         
         Herramientas de codificación convencionales  
     
Esta vez por ser informacion muy amplia les debo un video ^_^u

         

jueves, 2 de diciembre de 2010

Reingenieria de software

Reingeniería del software se puede definir como: “modificación de un producto software, o de ciertos componentes, usando para el análisis del sistema existente técnicas de Ingeniería Inversa y, para la etapa de reconstrucción, herramientas de Ingeniería Directa, de tal manera que se oriente este cambio hacia mayores niveles de facilidad en cuanto a mantenimiento, reutilización, comprensión o evaluación.”

Entre los beneficios de aplicar reingeniería a un producto existente se puede incluir:

    * Pueden reducir los riegos evolutivos de una organización.
    * Puede ayudar a las organizaciones a recuperar sus inversiones en software.
    * Puede hacer el software más fácilmente modificable
    * Amplía las capacidades de las herramientas CASE
    * Es un catalizador para la automatización del mantenimiento del software
    * Puede actuar como catalizador para la aplicación de técnicas de inteligencia artificial para  resolver problemas de reingeniería


    La reingeniería del software involucra diferentes actividades como son:
 
    * análisis de inventarios
    * reestructuración de documentos
    * ingeniería inversa
    * reestructuración de programas y datos
    * ingeniería directa

Con la finalidad de crear versiones de programas ya existentes que sean de mejor calidad y los mismos tengan una mayor facilidad de mantenimiento.   
Pasos de la reingenieria del software


Análisis de Inventarios

Todas las organizaciones de software deberían tener un inventario de todas sus aplicaciones. El inventario tal vez no sea más que un modelo en una hoja de cálculo que contenga información que proporcione una descripción detallada (tamaño, edad, importancia para el negocio) de las aplicaciones activas.


Los candidatos a la reingeniería aparecen cuando se ordena esta información en función de su importancia para el negocio, longevidad, mantenibilidad actual y otros criterios localmente importantes. Es entonces cuando es posible asignar recursos a las aplicaciones candidatas para el trabajo de reingeniería.


Es importante señalar que el inventario deberá visitarse con regularidad, el estado de las aplicaciones puede cambiar en función del tiempo y, como resultado, cambiarán las prioridades para la reingeniería.

   
Reestructuración de documentos



La documentación débil es la marca de muchos sistemas heredados. ¿Pero que se hace acerca de ellos? ¿Cuáles son las opciones? Crear documentación consume mucho tiempo, si el sistema funciona vivirá con lo que tenga. La documentación debe actualizarse pero se tiene recursos limitados. Se utiliza un enfoque de “documentar cuando se toque”. El sistema es crucial para el negocio y debe volver a documentarse por completo incluso en este caso un enfoque inteligente es recortar la documentación a un mínimo esencial. Cada una de estas opciones es viable. Una organización de software debe elegir la más apropiada para cada caso.

   
Ingeniería Inversa

La Ingeniería inversa es un proceso de recuperación de diseño. Con las herramientas de la ingeniería inversa se extraerá del programa existente información del diseño arquitectónico y de proceso, e información de los datos.


Este término tiene sus orígenes en el mundo del hardware. Una cierta compañía desensambla un producto de hardware competitivo en un esfuerzo por comprender los “secretos” del diseño y fabricación de su competidor. Estos secretos se podrán comprender más fácilmente si se obtuvieran las especificaciones de diseño y fabricación del mismo. Pero estos documentos son privados, y no están disponibles para la compañía que efectúa la ingeniería inversa. 


La ingeniería inversa del software es algo similar. En la mayoría de los casos, el programa del cual hay que hacer una ingeniería inversa no es el de un rival, sino, más bien, el propio trabajo de la compañía. Los “secretos” que hay que comprender resultan incomprensibles porque nunca se llegó a desarrollar una especificación. Consiguientemente, la ingeniería inversa del software es el proceso de análisis de un programa con el fin de crear una representación de programa con un nivel de abstracción más elevado que el código fuente.
   
Reestructuración de código



El tipo más común de reingeniería es la reestructuración de código, se puede hacer con módulos individuales que se codifican de una manera que dificultan comprenderlos, probarlos y mantenerlos.


Llevar a cabo esta actividad requiere analizar el código fuente empleando una herramienta de reestructuración, se indican las violaciones de las estructuras de programación estructurada, y entonces se reestructura el código (esto se puede hacer automáticamente). El código reestructurado resultante se revisa y se comprueba para asegurar que no se hayan introducido anomalías. Se actualiza la documentación interna del código.

   
Reestructuración de datos



La reestructuración de datos es una actividad de reingeniería a gran escala. En la mayoría de los casos, la reestructuración de datos comienza con una actividad de ingeniería inversa. La arquitectura de datos actual se analiza con minuciosidad y se define los modelos de datos necesarios, se identifican los objetivos de datos y los atributos, y después se revisa la calidad de las estructuras de datos existentes.


Dado que la arquitectura de datos tiene una gran influencia sobre la arquitectura del programa, y también sobre los algoritmos que lo pueblan, los cambios en datos darán lugar invariablemente a cambios o bien de arquitectura o bien de código.

   
Ingeniería directa



En un mundo ideal, las aplicaciones se reconstruyen utilizando un “motor de reingeniería” automatizado. En el motor se insertaría el programa viejo, que lo analizaría, reestructuraría y después regeneraría la forma de exhibir los mejores aspectos de la calidad del software. Después de un espacio de tiempo corto, es probable que llegue a aparecer este “motor”, pero los fabricantes de CASE han presentado herramientas que proporcionan un subconjunto limitado de estas capacidades y que se enfrentan con dominios de aplicaciones específicos. Lo que es más importante, estas herramientas de reingeniería cada vez son más sofisticadas.


La ingeniería directa no solo recupera la información de diseño a partir del software existente, también utiliza esta información para alterar o reconstruir el sistema existente con la finalidad de mejorar su calidad global. En la mayoría de los casos el software sometido a reingeniería vuelve a implementar la función del sistema existente y también añade nuevas funciones o mejoras.




Nuevamente para aquellos que se nos hace mas facil aprender por medio de un video.


miércoles, 1 de diciembre de 2010

Arquitectura Cliente-Servidor

TCP es un protocolo orientado a conexión. No hay relaciones maestro/esclavo. Las aplicaciones, sin embargo, utilizan un modelo cliente/servidor en las comunicaciones.

Un servidor es una aplicación que ofrece un servicio a usuarios de Internet; un cliente es el que pide ese servicio. Una aplicación consta de una parte de servidor y una de cliente, que se pueden ejecutar en el mismo o en diferentes sistemas.

Los usuarios invocan la parte cliente de la aplicación, que construye una solicitud para ese servicio y se la envía al servidor de la aplicación que usa TCP/IP como transporte.
El servidor es un programa que recibe una solicitud, realiza el servicio requerido y devuelve los resultados en forma de una respuesta. Generalmente un servidor puede tratar múltiples peticiones(múltiples clientes) al mismo tiempo.










Un video extraido de youtube permitira una mejor comprension de esta arquitectura.

Ventajas de la arquitectura cliente/servidor

El modelo cliente/servidor se recomienda, en particular, para redes que requieran un alto grado de fiabilidad. Las principales ventajas son:
  • recursos centralizados: debido a que el servidor es el centro de la red, puede administrar los recursos que son comunes a todos los usuarios, por ejemplo: una base de datos centralizada se utilizaría para evitar problemas provocados por datos contradictorios y redundantes.
  • seguridad mejorada: ya que la cantidad de puntos de entrada que permite el acceso a los datos no es importante.
  • administración al nivel del servidor: ya que los clientes no juegan un papel importante en este modelo, requieren menos administración.
  • red escalable: gracias a esta arquitectura, es posible quitar o agregar clientes sin afectar el funcionamiento de la red y sin la necesidad de realizar mayores modificaciones.

Desventajas del modelo cliente/servidor

La arquitectura cliente/servidor también tiene las siguientes desventajas:
  • costo elevado: debido a la complejidad técnica del servidor.
  • un eslabón débil: el servidor es el único eslabón débil en la red de cliente/servidor, debido a que toda la red está construida en torno a él. Afortunadamente, el servidor es altamente tolerante a los fallos (principalmente gracias al sistema RAID).

Informacion extraida de Kioskea.net (=w=)/)

 

Sala Limpia







Comprobacion de Sala Limpia

-Su objetivo es  validar los requisitos de software mediante la demostración de una muestra estadística de casos prácticos.

-Equivale a comprobar el software en la forma en los que el usuario tienen intención de utilizarlo.
 
-Determina la distribución de probabilidad de utilización correspondiente al software.

-Analiza la especificación (caja negra) de c/incremento del software para definir los estímulos (entradas o procesos) que dan lugar a modificar el comportamiento del software.

-Desarrolla un incremento del software que gestione la interacción del usuario con el teclado del sistema de seguridad.

-Genera una serie de números aleatorios entre 1 y 99, correspondiente al intervalo de la probabilidad.

 Informacion extraida del libro de Ingenieria del software de RogerPressman
 

miércoles, 20 de octubre de 2010

METRICAS



Una métrica es una cantidad insignificante que puede extraerse de algún documento o código dentro de un proyecto de software.

Un ejemplo de métrica es el número de ramas condicionales en una sección de código de un programa.

Esta métrica es significativa en el sentido de que proporciona alguna indicación del esfuerzo necesario para probar el código: está directamente relacionado con el número de caminos de prueba dentro del código.

Los indicadores de proceso permiten a una organización deingeniería del software tener una visión profunda de la eficacia de un proceso ya existente (por ejemplo: el para- digma, las tareas de ingeniería del software, productos de  trabajo e hitos). También permiten que los gestores evalúen lo que funciona y lo que no. Las métricas del proceso se recopilan de todos los proyectos y durante un largo período de tiempo.


 figura 1. Determinantes de la calidad del software y de la efectividad de organización (Ing.software un enfoque practico)
 Métricas del proyecto

Las métricas del proceso de software se utilizan para propósitos estratégicos. Las medidas del proyecto de software son tácticas. Esto es, las métricas de proyectos y los indicadores  derivados de ellos los utilizan un gestor de proyectos y un equipo de software para adaptar el flujo del trabajo del proyecto y las actividades técnicas.

 
Métricas Orientadas al Tamaño 


Las métricas del software orientadas al tamaño provienen  de la normalización de las medidas de calidad y/o productividad considerando el «tamaño» del software que se haya producido. Si una organización de software mantiene registros sencillos, se puede crear una tabla de  datos orientados al tamaño.

 figura 2. metrica orientada al tamaño(Ing. software un enfoque 
practico)

La tabla lista cada proyecto de desarrollo de software de los últimos años y las medidas correspon dientes de cada proyecto. Refiriéndonos a la entrada dela tabla del proyecto alfa: se desarrollaron 12.100 líneas de código (LDC) con 24 personas-mes y con  un coste de E168.000. Debe tenerse en cuenta que el esfuerzo y el coste registrados en  la tabla incluyen todas las actividades de ingeniería del software (análisis, diseño, codificación y prueba) y no sólo la codificación. Otra información sobre el proyecto alfa indica que se desarrollaron 365 páginas de documentación, se registraron  134 errores antes de que el software se entregara y se encontraron 29 errores después de entregárselo al  cliente dentro del primer año de utilización.


Métricas Orientadas a la Función 


Las métricas del software orientadas a la función utilizan una medida de la funcionalidad entregada por la aplicación como un valor de normalización. Ya  que la «funcionalidad>> n o se puede medir directamente, se debe derivar indirectamente mediante otras medidas directas.



Los puntos de función se calculan completando la tabla de la Figura 4.5. Se determinan cinco características de dominios de información y se proporcionan las cuentas en la posición apropiada de la tabla. Los valores de los dominios de información se definen de la forma siguiente?

Número de entradas de usuario. Se cuenta cada entrada de usuario que proporciona diferentes datos orientados a la aplicación. Las entradas se deberían diferenciar de las peticiones, las cuales se cuentan de forma separada. los puntos de  función se  derivan de  medidas directas del dominio de la información.

Número de salidas de usuario. Se cuenta cada salida que proporciona al usuario información orientada a la aplicación. En este contexto la salida se refiere a informes, pantallas, mensajes de error, etc. Los elementos de datos particulares dentro de un informe no se cuentan de forma separada.

Número de peticiones de usuario. Una petición se define como una entrada interactiva que produce la generación de alguna respuesta del software inmediata en forma de salida inleractiva. Se cuenta cada petición por separado. 

Número de archivos. Se cuenta cada archivo maestro lógico (esto es, un grupo lógico de datos que puede ser una parte de una gran base de datos o un  archivo independiente).
Número de interfaces externas. Se cuentan todas las interfaces legibles por la máquina (por ejemplo: archivos de datos de cinta o disco) que se utilizan para transmitir información a otro sistema.


Informacion sacada  del libro (ing software un enfoque practico, roger pressman)

ejemplo  de metricas :

FUNDACIÓN FES

Programa de Métricas
1.     Objetivo/s del Negocio
Mejorar gestión de fondos asignados a los programas Nicas.

2.     Nuevos sabores/aprendizajes
Para la solución del caso de estudio Fundación FES escogimos el modelo básico semilibre porque el equipo de trabajo es principiante, es decir, no tiene mucha experiencia en el desarrollo de software y sus métricas. También se escogió este modelo porque en el equipo de trabajo hay quienes les gusta compartir trabajo y otros que proponen ideas. A la vez se utilizó la metodología orientada a objetos por ser la más actualizada, adecuada al caso y útil para el equipo de trabajo.

La Fundación Friedrich Ebert (FES) fue creada en 1925 como legado político de Friedrich Ebert, el primer presidente socialdemócrata Friedrich Ebert, un artesano de origen humilde el cual promovió la creación de una fundación para fomentar la formación política y social de hombres y mujeres de todos los sectores en un espíritu democrático y pluralista, para facilitar a los jóvenes el acceso a la educación superior y la investigación, y para contribuir a la cooperación y al entendimiento internacional. Hoy en día la Fundación sigue trabajando en este sentido a través de sus múltiples programas. FES es una institución político-cultural privada, sin fines de lucro, comprometida con los principios y los valores fundamentales de la democracia social.

En el ámbito del trabajo internacional, la Fundación Friedrich Ebert coopera con contrapartes en más de cien países; en la mayoría de estos países con oficinas propias y colaboradores alemanes y locales que trabajan en pro de la democracia, del desarrollo y de la paz. El trabajo de la Fundación tiene como objetivo fomentar la participación, el pluralismo y la justicia social así como fortalecer el estado de derecho y promover la búsqueda de soluciones pacíficas de conflictos en la esfera estatal y en la sociedad civil.

FES abarca temas tanto la política de reformas democráticas en los países, como los desafíos de la integración económica y política a nivel mundial. El trabajo internacional de la FES es financiado, en su mayor parte, con fondos proporcionados por el Ministerio Federal de Cooperación Económica y Desarrollo y el Ministerio Federal de Relaciones Exteriores.

3.     Sub objetivos
Automatizar la agenda de eventos.

4.     Entidades y atributos de los sub objetivos







































 





















5.     Objetivo/s de medición

ü  Entender qué ocurre durante el desarrollo y el mantenimiento
ü  Controlar qué es lo que ocurre en nuestro proyecto
ü  Mejorar nuestros procesos y nuestros productos

6.     Preguntas cuantitativas e indicadores relacionados

PREGUNTAS CUANTITATIVAS
INDICADORES RELACIONADOS
a.       ¿Cuáles son los objetivos de desarrollo de software?
                              OBJ (objetivos)
b.      ¿Cuáles son las actividades  y étapas que se harán en el desarrollo del software?
ACT (actividades)
c.       ¿Cuáles son las estrategias de desarrollo del software?
EST(estrategia)
d.      ¿Cuánto es el tiempo de desarrollo del software?
TD (meses)
e.       ¿De qué recursos haremos uso?
REC (recursos)
f.        ¿Quiénes serán el personal responsable  durante el desarrollo del software?
P (personas)
g.       ¿Cuál es el costo de desarrollo del software?
CT (U$)
h.      ¿Cuáles serán los cargos asignados?
CRG (cargos)

7.     Recolecta de datos y cálculos de indicadores
                          
                                           

Las constantes tienen los siguientes valores:
                 a = 3:00, b= 1.12, c=2.50, d=0.35
)

PARÁMETRO
#
SIMPLE
MEDIO
COMPLEJO
SUB TOTAL
#Entradas
40
3
4
6
160
#Salidas
16
4
5
7
80
#Peticiones
16
3
4
6
64
#Archivos
15
7
10
15
150
#Interfaz
26
5
7
10
260





CUT = 714

Factor (Cualitativa)
1
5
2
3
3
3
4
5
5
5
6
5
7
5
8
5
9
3
10
3
11
5
12
1
13
1
14
5
54

Cálculo de M(x)
SOFTWARE
HARDWARE
PERSONAL
PROYECTO
Fiabilidad                 1.15
Rest. Tiempo
de Ejecución            1.00
Capacidad Análisis        0.88
Técnicas act.
de prog.             0.91
Tamaño BD            1.08
Rest. Memoria           1.00
Virtual
Experiencia Aplic.
1.00
Utilización herramientas   0.91
soft.
Complejidad            1.15
Volatilidad Máq.        1.00
Virtual
Calidad Prog.
1.00
Restr. tiempo ejecución           1.00

Tiempo de
Respuesta                    1.00
Experiencia Máq.
Virtual                            1.00



Experiencia
 Lenguaje                       1.00


8.     Medidas a usar (definición operativa de los resultados)

                                                            (personas/ mes)
                                                                              (meses)
                                                                               (personas)   
               (costo U$)
              )                                 (cuenta total)

9.     Acciones de mejora

                                      ESTIMADO
REAL
Desarrollo                 3 1/2 meses
3- 4 meses
Personas                    3 P
3-4 P
Costo                            U$ 200
150-200 U$

10.Plan de implementación (Diagrama en Project)