lunes, 9 de enero de 2017

diseñoEl acoplamiento y la cohesión juegan un rol central en el diseño de software. Yourdon y Constantine, en su obra clásica Diseño Estructurado, identifican que el objetivo del diseño es minimizar los costos. El costo del software está determinado por el costo de mantenimiento, y el costo del mantenimiento está determinado por el costo de los cambios que surgen en el sistema. Un diseño de software efectivo minimiza la probabilidad de que se propaguen los cambios. Los cambios que involucran a un único elemento son menos costosos y más predecibles que los cambios a un elemento que requieren cambiar dos más, y luego tres...
El costo esperado del cambio se puede reducir prestando especial atención a dos factores: el acoplamiento entre los elementos y la cohesión dentro de los elementos.
(El diseño de software también es importante para incrementar o acelerar las ganancias, pero las ganancias no están directamente conectadas al acoplamiento y la cohesión)

Acoplamiento

Dos elementos están acoplados en la medida en el que los cambios en uno tienden a necesitar cambios en el otro. Por ejemplo, la comunicación por red entre dos sistemas está acoplada respecto a cambios en el protocolo - si un sistema necesita ambiar el protocolo, el otro va a necesitar cambiar también. El acoplamiento entre los elementos es un conductor de cambios.

El acoplamiento propaga los cambios

Hablamos de acoplamiento (y cohesión) en términos de cambios particulares. Esta no es la definición estándar. El acoplamiento suele definirse como una propiedad estática: dos elementos están temporalmente acoplados si, por ejemplo, la secuencia invocante entre ellos está restringida. Estas propiedades estáticas son sólo costo potencial: si no ocurre ningún evento que dispare el acoplamiento, el costo nunca ocurre.
Un sistema podría estar acoplado a un proveedor de bases de datos específico, al utilizar características propias de ese proveedor (por ejemplo, de Oracle). Un cambio en la base de datos va a provocar cambios al sistema. Sin embargo, si la base de datos nunca cambia, entonces el acoplamiento es sólo potencial. Evaluar el costo del acoplamiento con precisión requiere de la evaluación del grupo de cambios que son realmente requeridos en el sistema. Y esto sólo puede hacerse a posteriori. Evaluar los costos en retrospectiva requiere estimar la probabilidad de los tipos de cambios que se propagarían a través de relaciones.
La relación entre el acoplamiento y el costo del cambio funciona en ambos sentidos. Los cambios que parecen ser más costosos van a ser menos probables que se elijan para hacer. Al romper el acomplamiento se crean oportunidades para nuevos tipos de cambios, antes imposibles de pensar.
Hay mucho más para decir sobre los distintos tipos de acomplamiento, y los tipos de cambios que se propagan. El concepto fundamental es que los elementos en un diseño no deben estar acoplados con respecto a los cambios que realmente van a ocurrir. Esto mantiene contenido al costo de los cambios.

Cohesión

El acoplamiento mide la dispersión del cambio a través de los elementos. La cohesión mide el costo del cambio dentro de un elemento. Un elemento es cohesivo a medida que cambia el elemento entero cuando el sistema necesita cambiar.
Un elemento puede tener poca cohesión tanto por ser muy grande o muy pequeño. Un elemento muy pequeño, que resuelve sólo una parte del problema, va a necesitar estar acoplado a otros elementos para resolver las otras partes del problema. Si cambia la solución se va a necesitar cambiar todos los elementos. Un elemento que resuelve muchos problemas sólo va a necesitar cambiarse en parte. Esto es más riesgoso y más costoso que cambiar un elemento completo, porque primero se necesita averiguar qué parte del elemento debe cambiarse, y luego probar que las partes sin cambios del elemento realmente sigan sin cambios. Los elementos cohesivos, que se reemplazan en su totalidad, no tienen estos costos.
La estrategia de aislar los cambios es una forma de inducir la cohesión antes de hacer un cambio; por ejemplo, extraer la parte de un método que necesita cambiarse dentro de un método propio antes de hacer el cambio.

Balance

Una de las cosas que hace divertido al diseño es que necesita ser balanceado. Si los elementos son muy grandes, cada cambio va a ser más costoso de lo que necesita ser. Si los elementos son muy chicos, los cambios van a esparcirse por todo el sistema. Y la optimización del diseño ocurre sobre un flujo impredecible de cambios.
Los elementos que son muy grandes tienden a multiplicar el costo del cambio: N * C. Los cambios que se propagan a través de los elementos pueden resultar potencialmente más caros: C ^ N. (Estas fórmulas son simplificadas y a modo de ejemplo, no para usar literalmente). Esto sugiere que debe invertirse más tiempo en reducir el acoplamiento.
El gran desafio del diseño es reducir el acoplamiento de forma no costosa. Si un elemento puede aislarse de un cambio probable que ocurra en otro elemento a un costo razonable, entonces es mejor hacerlo antes que después. Romper con otras formas de acoplamiento va a resultar más costoso y puede resultar mejor dejarlo hasta que ocurra el evento de cambio. Nuevamente, lo divertido del diseño es justamente la imprecisión de este análisis.
Como los cambios son impredecibles se hace imposible determinar de forma estática el "mejor" diseño para un sistema. Siempre va a ocurrir algún cambio que se propague por el sistema. Lo importante es crear diseños que disminuyan el costo de los cambios, sabiendo que nunca es posible llegar al costo cero.
Tomado de Dosideas.com

GRADOS DE LIBERTAD DE UN PROGRAMA (acoplamiento)


-El exe no tienen configuracion +1

-El exe  se invoca desde cualquier lado  +1

-Los datos generados  no son compartidos +1

-Los datos  utilizados no son compartidos +1

-La ejecucion del exe no necesita de parametros +1

-Los datos pueden estar en  ubicacion diferente de donde esta el exe +1

-Los datos de configuracion no son compartidos +1

 Total de grados de libertad del EXE =7

-El exe  tienen archivo de configuracion -1

-El exe se ejecuta desde donde se invoca -1

-Los datos generados y utilizados son compartidos -1

-Se utilizan datos compartidos ,generados por otros exe -1

-La ejecucion del exe necesita de parametros -1

-Los datos de configuracion son compartidos -1

-El directorio de datos debe ser el directorio del exe -1


Total de grados de libertad del EXE =0
Mas grados de libertad .... mayor independencia , mayor mantenibilidad ,


viernes, 18 de noviembre de 2016

6 - MANTENIMIENTO

o como mantener el valor de la inversión
 Todo software instituido presentara problemas que se manifestaran en disconformidades y/o fallas
  Algún defecto de procesos anteriores se manifestara como una falla , o sera la causa de           algún problema
  Ademas , los requerimientos del ambiente donde esta instituido , cambian con el tiempo

Esta problematica se ha enfrentado con el concepto de "mantenimiento"


Las fallas y /o disconformidades son la causa de las actividades que conocemos como "MANTENIMIENTO"
Según la IEEE mantenimiento es la molificación de un producto de software después de liberado , para corregir fallas , mejorar perfomance u otros atributos , o adaptar un producto a un ambiente cambiante
La esperanza matemática de que se manifieste una falla o disconformidad    es =0
El soft es una inversión , por lo tanto el mantenimiento es el costo por alcanzar los beneficios esperados .
Depende del área que afecten y del concepto de costo que una empresa utilice.
De cualquier manera debe ser un costo planificado porque es un gasto esperado
Son de utilidad las normas ieee 1219 , iso 9216 ,14764
Mantenimiento es
             Correctivo
                      Modificación en respuesta a una falla descubierta después de la institucion
             Adaptativo
                      Modificación hecha para mantener el soft funcionando ante cambios en el medio                                   ambiente
             Perfectivo
                     Modificación hecha para dotar al soft de nuevas propiedades
                     básicamente , mantenibilidad y perfomance
             Preventivo
                    No se considera en la IEEE 1219.
                    "Modificación del producto software tras la entrega para detectar y corregir
                    fallos latentes antes de que se conviertan en fallos efectivos".(ISO 9216)
                    Modificaciones hechas para mejorar  y optimizar el soft  . Revisión continua y mejora                         para anticipar rigidez de uso (bsicamente mantenibilidad  y perfomance).
                    Si un soft tiene demasiadas rigideces , esta "muerto" , todo soft necesita ser revisado para                     asegurar que se mantienen "los grados de libertad esperados" , caso contrario se                                   generaran gastos mayores
                    Este mantenimiento es una cuestión %100 técnica ,

Las Fallas de "mortalidad infantil" son un síntoma de defectos en las etapas anteriores y no es eficiente encararlas con una "orden de trabajo de mantenimiento"

viernes, 23 de septiembre de 2016

5- instalación , institucion

Instalación:

Colocar un cosa en un lugar para que funcione correctamente o realice la función que le corresponde.

proceso durante el cual el soft desarrollado es preparados para ser ejecutados en el  ámbito real (destino o sistema objeto), para cumplir la función por la cual fueron desarrollados
Hay que asegurar la compatibilidad con los recursos disponibles y la accesibilidad
Se puede ensayar el funcionamiento a escala reducida (prueba piloto) para verificar  la compatibilidad y accesibilidad
Hay que asegura la disponibilidad  de servicios imprescindibles , caso contrario instalarlos
Hay que  configurar con datos apropiados para que el soft funcione de la forma esperada , para ello
seteamos  información necesaria ,asegurando  acceso a información  externa y a infraestructura    
Las habituales tareas de esta etapa

  •        Generación de accesos
  •        Prueba de funcionamiento
  •        Generacion de instaladores
  •        Guias de uso para usuarios
  •        Entrenamiento de uso

Institucion


Instituir significa: crear ,erigir , establecer , instaurar (se parece al termino implantar del diccionario IBM)
Se instituye una alteración en el sistema de trabajo (un cambio que perdurara)
Eso altera la regla del equilibrio P-R-S  (propósito - recurso - sistema)
Tendremos que trabajar para que se produzca un desplazamiento hacia un nuevo equilibrio conveniente.
En sistemas conocidos , o de reemplazo basta con asegurarse que los usuarios resuelven sus problemas  explotando las nuevas herramientas.
En otros casos , la llegada de un nuevo sistema puede implicar reorganizacion de funciones , cambios en el flujo del trabajo , etc.
Esos casos requieren de manuales , entrenamiento en resolucion de problemas , talleres , help desk y un trabajo cercano con los promotores para que puedan apreciar que el cambio :es el que esperaban
Esta etapa ya empieza a generar cambios (todos urgentes) en el soft , hay que estar listo para el mantenimiento correctivo de prioridad urgente
Hay que prepararse porque se alteran todas las tareas de soporte

Documentación
Configuracion
Calidad
Vinificación
Validacion
Reuniones
Auditorías
Resolucion de problemas
Organizacionales
Gerenciamiento
Infraestructura
Mejora
Entrenamiento

El final de esta etapa es cuando el soft y todo su impacto , es parte normal del trabajo diario




viernes, 2 de septiembre de 2016

4-Pruebas

 

4.1.1)Prueba: de integracion

En este caso probamos cómo es la interacción entre dos o mas unidades del software.
Este tipo de pruebas verifican que los componentes de la aplicación funcionan correctamente actuando en conjunto.
Siguiendo con el caso anterior, las pruebas de integración son las que comprobarían que se ha mandado un email, la conexión real con la base de datos etc.
Este tipo de pruebas son dependientes del entorno en el que se ejecutan. Si fallan, puede ser porque el código esté bien, pero haya un cambio en el entorno.
Por ejemplo, también podríamos usar JUnit para realizar pruebas de integración, si no hacemos mocks o stubs, y nos centramos en probar el comportamiento de los componentes en su conjunto.
4.1..2)Pruebas de sistema
Aquí se engloban tipos de pruebas cuyo objetivo es probar todo el sistema software completo e integrado, normalmente desde el punto de vista de requisitos de la aplicación.
Aquí aparecerían las pruebas funcionales, pruebas de carga, de estrés etc.

4.1..3)Pruebas de carga

Las pruebas de carga son un tipo de prueba de rendimiento del sistema. Con ellas observamos la respuesta de la aplicación ante un determinado número de peticiones.
Aquí entraría por ejemplo ver cómo se comporta el sistema ante X usuarios que entran concurrentemente a la aplicación y realizan ciertas transacciones.

4.1..4)Pruebas de estrés

Este es otro tipo de prueba de rendimiento del sistema. El objetivo de estas pruebas es someter al software a situaciones extremas, intentar que el sistema se caiga, para ver cómo se comporta, si es capaz de recuperarse o tratar correctamente un error grave.

4.1..5)Pruebas de aceptación

Por último, las pruebas de aceptación se realizan para comprobar si el software cumple con las expectativas del cliente, con lo que el cliente realmente pidió.

4.2)Prueba de instalacion (o despliegue)


       Se trata de emular el ambiente donde se instalara el soft con el objetivo de verificar que el soft es instalable.
      Experimentar configuraciones optimas posibles  de cada server , servicio , puesto de trabajo , flujo de tareas
       -Generar instaladores 
      - Documentacion del entorno requerido/esperado

3-Implementación: codificacion o traslado del diseño en un lenguaje

4.1 diseño
      En el ámbito de la programacion , pensando la mejor forma de cumplir las especificaciones
4.2  Construccion
       Generación de código a partir de : reuso , componentes , rad  , codificacion artesanal de partes            visuales y   no-visuales
              /      
                                         


  4.3       depuración
            Para conseguir programas efectivos y libres de errores. Pulido / espulgado
  4.4       Pruebas unitarias y de programa
            Se trata de verificar que se cumplen requisitos funcionales y de integracion
  4.5       Documentacion
            Lo mas importante es documentar las decisiones del programador , las excepciones incorporadas , los problemas resueltos.
             los contratos asumidos y salidas correctas esperadas

miércoles, 17 de agosto de 2016

Extensiones:
Es una mejora . Una propiedad o atributo nuevo . Una innovación en la aplicacion
Las extensiones no afectan el servicio básico del app existente.
Son propiedades que se piensan buscando el beneficio . No alteran la ecuación Propósito- Recurso- Sistema
Buscamos aplicar la máxima : los procesos deben minimizarse , eliminando , combinando o simplificando procesos existentes