Pruebas Del Software

Prueba del software
Las pruebas deben llevarse a cabo durante todo el proceso de desarrollo de sistemas y no sólo  durante la implementación. Varía su clasificación y características dependiendo del momento en que se lleven a cabo. En este documento el enfoque es en las pruebas posteriores al diseño, es  decir de la implementación.


PRUEBAS BASADAS EN LA EJECUCIÓN
Estas se deben llevar a cabo a partir de que se genera código. Para su realización se requiere preparar previamente datos de prueba. La correcta elección de los datos de prueba será la clave del éxito de las mismas.
Las cualidades que deben verificarse en las pruebas son: utilidad, fiabilidad, solidez o robustez, desempeño y corrección.
La utilidad verifica a qué grado el sistema satisface las necesidades del cliente en cuanto a 
rentabilidad o utilidades.
La fiabilidad que es la medida de la frecuencia de fallas, es decir el tiempo entre fallas y el 
tiempo promedio de reparación. Esta medida permitirá tomar consideraciones de recuperación.
La solidez o robustez implica varios factores como la respuesta a entradas inválidas.
El desempeño mide qué tanto el sistema cumple con los tiempos de respuesta o requisitos de espacio establecidos en las especificaciones.
Finalmente, la corrección se refiere a qué tanto cumple con todas las especificaciones del 
usuario.
un proceso de Evaluación en el que los resultados obtenidos se comparan con los resultados 
esperados para localizar fallos en el software. Estos fallos conducen a un proceso de 
Depuración en el que es necesario identificar la falta asociada con cada fallo y corregirla, 
pudiendo dar lugar a una nueva prueba. Como resultado final se puede obtener una 
determinada Predicción de Fiabilidad, o un cierto nivel de confianza en el software 
probado.Modelo deEl objetivo de las pruebas no es asegurar la ausencia de defectos en un software, únicamente  puede demostrar que existen defectos en el software. Nuestro objetivo es pues, diseñar  pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.
Para ser más eficaces (es decir, con más alta probabilidad de encontrar errores), las pruebas
deberían ser realizadas por un equipo independiente al que realizó el software. El ingeniero de software que creó el sistema no es el más adecuado para llevar a cabo las pruebas de dicho software, ya que inconscientemente tratará de demostrar que el software funciona, y no que  no lo hace, por lo que la prueba puede tener menos éxito.


PASOS PARA PROBAR EL SOFTWARE
Veamos ahora cuáles son las tareas a realizar para probar un software:
1.  Diseño de las pruebas. Esto es, identificación de la técnica o técnicas de pruebas que se
utilizarán para probar el software. Distintas técnicas de prueba ejercitan diferentes criterios
como guía para realizar las pruebas. Seguidamente veremos algunas de estas técnicas.
2.  Generación de los casos de prueba. Los casos de prueba representan  los datos que se
utilizarán como entrada para ejecutar el software a probar. Más concretamente los casos de
prueba determinan un conjunto de entradas, condiciones de ejecución y resultados esperados 
para un objetivo particular. Como veremos posteriormente, cada técnica de pruebas 
proporciona unos criterios distintos para generar estos casos o datos de prueba. Por lo tanto, 
durante la tarea de generación de casos de prueba, se han de confeccionar los distintos casos de prueba según la técnica o técnicas identificadas previamente. La generación de cada caso de prueba debe ir acompañada del resultado que ha de producir el software al ejecutar dicho caso (como se verá más adelante, esto es necesario para detectar un posible fallo en el programa).
3. Definición de los procedimientos de la prueba. Esto es, especificación de cómo se va a llevar a cabo el proceso, quién lo va a realizar, cuándo …
4.  Ejecución de la prueba,  aplicando los casos de prueba generados previamente e identificando los posibles fallos producidos al comparar los resultados esperados con los
resultados obtenidos.
5. Realización de un informe de la prueba, con el resultado de la ejecución de las pruebas, qué casos de prueba pasaron satisfactoriamente, cuáles no, y qué fallos se detectaron.
Tras estas tareas es necesario realizar un proceso de depuración de las faltas asociadas a los  fallos identificados. Nosotros nos centraremos en el segundo paso, explicando cómo distintas técnicas de pruebas pueden proporcionar criterios para generar distintos datos de prueba. 



TÉCNICAS DE PRUEBA
Las técnicas de prueba proporcionan distintos criterios para generar casos de prueba que 
provoquen fallos en los programas. Estas técnicas se agrupan en:
− Técnicas de caja  de vidrio o estructurales (antes conocidas como de caja blanca), que se basan en un minucioso examen de los detalles procedimentales del código a evaluar, por lo que es necesario conocer la lógica del programa. Se examina el código a fin de generar datos de prueba que garanticen se ejecute cada una de las líneas de código para poder observar su resultado.
− Técnicas de caja negra o funcionales, que realizan pruebas sobre la interfaz del programa aprobar, entendiendo por interfaz las entradas y salidas de dicho programa.  Se preparan considerando únicamente las especificaciones del sistema, es decir, los requerimientos. Sin asomarse al código.  No es necesario conocer la lógica del programa, únicamente la funcionalidad que debe realizar.
A primera vista parecería que una prueba de caja blanca completa nos llevaría a disponer de un código perfectamente correcto. De hecho esto ocurriría si se han probado todos los posibles caminos por los que puede pasar el flujo de control de un programa. Sin embargo, para programas de cierta envergadura, el número de casos de prueba que habría que generar sería excesivo, nótese que el número de caminos incrementa exponencialmente a medida que el número de sentencias condicionales y bucles aumenta. Sin embargo, este tipo de prueba no se desecha como impracticable. Se pueden elegir y ejercitar ciertos caminos representativos de un programa.
Por su parte, tampoco sería factible en una prueba de caja negra probar todas y cada una de 
las posibles entradas a un programa, por lo que análogamente a como ocurría con las técnicas de caja blanca, se seleccionan un conjunto representativo de entradas y se generan los correspondientes casos de prueba, con el fin de provocar fallos en los programas.
En realidad estos dos tipos de técnicas son técnicas complementarias que han de aplicarse al realizar una prueba dinámica, ya que pueden ayudar a identificar distintos tipos de faltas en un programa.
A continuación, se describen en detalle los procedimientos propuestos por ambos tipos de 
técnicas para generar casos de prueba.


Pruebas de Caja de Vidrio o Estructurales
Este método se centra en cómo diseñar los casos de prueba  atendiendo al  comportamiento 
interno y la estructura del programa. Se examina así la lógica interna del programa sin 
considerar los aspectos de rendimiento.
El objetivo de la técnica es diseñar casos de prueba para que se ejecuten, al menos una vez, 
todas las sentencias del programa, y todas las condiciones tanto en su vertiente verdadera 
como falsa.
Como se ha indicado ya, puede ser impracticable realizar una prueba exhaustiva de todos los
caminos de un programa. Por ello se han definido distintos criterios de cobertura lógica, que
permiten decidir qué sentencias o caminos se deben examinar con los casos de prueba. Estos
criterios son:
- Cobertura de Sentencias: Se escriben casos de prueba suficientes para que cada sentencia en el programa se ejecute, al menos, una vez.
- Cobertura de Decisión: Se escriben casos de prueba suficientes para que cada decisión en el programa se ejecute una vez con resultado verdadero y otra con el falso.- Cobertura de Condiciones: Se escriben casos de prueba suficientes para que cada condición en una decisión tenga una vez resultado verdadero y otra falso.
- Cobertura Decisión/Condición: Se escriben casos de prueba suficientes para que cada
condición en una decisión tome todas las posibles salidas, al menos una vez, y cada decisión 
tome todas las posibles salidas, al menos una vez.
- Cobertura de Condición Múltiple: Se escriben casos de prueba suficientes para que todas las combinaciones posibles de resultados de cada condición se invoquen al menos una vez.
- Cobertura de Caminos: Se escriben casos de prueba suficientes para que se ejecuten todos
los caminos de un programa. Entendiendo camino como una secuencia de sentencias encadenadas desde la entrada del programa hasta su salida.


Pruebas de Caja Negra o Funcionales
También conocidas como Pruebas de Comportamiento, estas pruebas se basan en la 
especificación del programa o componente a ser probado para elaborar los casos de prueba. El componente se ve como una “Caja Negra” cuyo comportamiento sólo puede ser determinado estudiando sus entradas y las salidas obtenidas a partir de ellas. No obstante, como el estudio de todas las posibles entradas y salidas de un programa sería impracticable se selecciona un conjunto de ellas sobre las que se realizan las pruebas. Para seleccionar el  conjunto de entradas y salidas sobre las que trabajar, hay que tener en cuenta que en todo programa existe un conjunto de entradas que causan un comportamiento erróneo en nuestro sistema, y como consecuencia producen una serie de salidas que revelan la presencia de defectos. 
Entonces, dado que la prueba exhaustiva es imposible, el objetivo final es pues, encontrar una 
serie de datos de entrada cuya probabilidad de pertenecer al conjunto de entradas que causan dicho comportamiento erróneo sea lo más alto posible.
Al igual que ocurría con las técnicas de Caja Blanca, para confeccionar los casos de prueba de Caja Negra existen distintos criterios. Algunos de ellos son:
− Particiones de Equivalencia.
− Análisis de Valores Límite.
− Métodos Basados en Grafos.
− Pruebas de Comparación.
− Análisis Causa-Efecto.





ESTRATEGIA DE PRUEBAS
La estrategia que se ha de seguir a la hora de evaluar dinámicamente un sistema software 
debe permitir comenzar por los componentes más simples y más pequeños e ir avanzando
progresivamente hasta probar todo el software en su conjunto. Más concretamente, los pasos a
seguir son:
1. Pruebas Unitarias. Comienzan con la prueba de cada módulo.
2. Pruebas de Integración. A partir del esquema del diseño, los módulos probados se vuelven a probar combinados para probar sus interfaces.
3. Prueba del Sistema. El software ensamblado totalmente con cualquier componente hardware  que requiere se prueba para comprobar que se cumplen los requisitos funcionales.
4. Pruebas de Aceptación. El cliente comprueba que el software funciona según sus
expectativas.


Pruebas Unitarias
La prueba de unidad es la primera fase de las pruebas dinámicas y se realizan sobre cada 
módulo del software de manera independiente. El objetivo es comprobar que el módulo, 
entendido como una unidad funcional de un programa independiente, está correctamente 
codificado. En estas pruebas cada módulo será probado por separado y lo hará, generalmente, la persona que lo creó. En general, un módulo se entiende como un componente software que 
cumple las siguientes características:
− Debe ser un bloque básico de construcción de programas.
− Debe implementar una función independiente simple.
− Podrá ser probado al cien por cien por separado.
− No deberá tener más de 500 líneas de código.
Tanto pruebas de caja de vidrio como de caja negra han de aplicar para probar de la manera 
más completa posible un módulo. Nótese que las pruebas de caja negra (los casos de prueba) se pueden especificar antes de que módulo sea programado, no así las pruebas de caja de  vidrio.


Pruebas de Integración
Aún cuando los módulos de un programa funcionen bien por separado es necesario probarlos
conjuntamente: un módulo puede tener un efecto adverso o inadvertido sobre otro módulo; lassubfunciones, cuando se combinan, pueden no producir la función principal deseada; la 
imprecisión aceptada individuamente puede crecer hasta niveles inaceptables al combinar los módulos; los datos pueden perderse o malinterpretarse entre interfaces, etc.
Por lo tanto, es necesario probar el software ensamblando todos los módulos probados 
previamente. Ésta es el objetivo de la pruebas de integración.
A menudo hay una tendencia a intentar una integración no incremental; es decir, a combinar 
todos los módulos y probar todo el programa en su conjunto. El resultado puede ser un poco 
caótico con un gran conjunto de fallos y la consiguiente dificultad para identificar el módulo (o 
módulos) que los provocó.
En contra, se puede aplicar la integración  incremental  en la que el programa se prueba en 
pequeñas porciones en las que los fallos son más fáciles de detectar. Existen dos tipos de 
integración incremental, la denominada ascendente y descendente. Veamos los pasos a seguir para cada caso.
Integración incremental ascendente
1. Se combinan los módulos de bajo nivel en grupos que realicen una subfunción específica.
2. Se escribe un controlador (un programa de control de la prueba) para coordinar la entrada y
salida de los casos de prueba.
3. Se prueba el grupo.
4. Se eliminan los controladores y se combinan los grupos moviéndose hacia arriba por la
estructura del programa.

Integración incremental descendente:
1. Se usa el módulo de control principal como controlador de la prueba, creando  resguardos
(módulos que simulan el funcionamiento de los módulos que utiliza el que está probando) para 
todos los módulos directamente subordinados al módulo de control principal.
2. Dependiendo del enfoque e integración elegido se van sustituyendo uno a uno los 
resguardos subordinados por los módulos reales.
3. Se llevan a cabo pruebas cada vez que se integra un nuevo módulo.
4. Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo con el módulo real.



Pruebas del Sistema
Este tipo de pruebas tiene como propósito ejercitar profundamente el sistema para verificar 
que se han integrado adecuadamente todos los elementos del sistema (hardware, otro 
software, etc.) y que realizan las funciones adecuadas. Concretamente se debe comprobar que:
- Se cumplen los requisitos funcionales establecidos.
- El funcionamiento y rendimiento de las interfaces hardware, software y de usuario.
- La adecuación de la documentación de usuario.
- Rendimiento y respuesta en condiciones límite y de sobrecarga.
Para la generación de casos de prueba de sistema se utilizan técnicas de caja negra. Este tipo de pruebas se suelen hacer inicialmente en el entrono del desarrollador, denominadas Pruebas Alfa, y seguidamente en el entrono del cliente denominadas Pruebas Beta.


Pruebas de Aceptación
A la hora de realizar estas pruebas, el producto está listo para implantarse en el entorno del 
cliente.
El usuario debe ser el que realice las pruebas, ayudado por personas del equipo de pruebas, 
siendo deseable, que sea el mismo usuario quien aporte los casos de prueba.
Estas pruebas se caracterizan por:
- Participación activa del usuario, que debe ejecutar los casos de prueba ayudado por
miembros del equipo de pruebas.
- Están enfocadas a  probar los requisitos de usuario, o mejor dicho a demostrar que no se
cumplen los requisitos, los criterios de aceptación o el contrato. Si no se consigue demostrar
esto el cliente deberá aceptar el producto.
- Corresponden a la fase final del proceso de desarrollo de software.


Es muy recomendable que las pruebas de aceptación se realicen en el entorno en que se va a
explotar el sistema (incluido el personal que lo maneje). En caso de un producto de interés 
general, se realizan pruebas con varios usuarios que reportarán sus valoraciones sobre el 
producto.
Para la generación de casos de prueba de aceptación se utilizan técnicas de caja negra.


Pruebas de Regresión
La regresión consiste en la repetición selectiva de pruebas para detectar fallos introducidos 
durante la modificación de un sistema o componente de un sistema. Se efectuarán para 
comprobar que los cambios no han originado efectos adversos no intencionados o que se 
siguen cumpliendo los requisitos especificados.
En las pruebas de regresión hay que:
- Probar íntegramente los módulos que se han cambiado.
- Decidir las pruebas a efectuar para los módulos que no han cambiado y que han sido
afectados por los cambios producidos.
Este tipo de pruebas ha de realizarse, tanto durante el desarrollo cuando se produzcan cambios en el software, como durante el mantenimiento.


PRUEBAS ORIENTADAS A OBJETOS
En las secciones anteriores se ha presentado el proceso de pruebas orientado al concepto 
general de módulo. Sin embargo, en el caso de la orientación a objetos (OO) es el concepto de clase y objeto el que se utiliza. Veamos a continuación, algunas particularidades de las pruebas para el caso de la Orientación a Objetos
Prueba de Unidad
Al tratar software OO cambia el concepto de unidad. El encapsulamiento dirige la definición de clases y objetos. Esto significa que cada clase e instancia de clase (objeto) empaqueta los 
atributos (datos) y las operaciones (también conocidas como métodos o servicios) que 
manipulan estos datos.
Por lo tanto, en vez de módulos individuales, la menor unidad a probar es la clase u objeto
encapsulado. Una clase puede contener un cierto número de operaciones, y una operación 
particular puede existir como parte de un número de clases diferentes. Por tanto, el significado de prueba de unidad cambia ampliamente frente al concepto general visto antes.
De esta manera, la  prueba de clases  para el software OO es el equivalente a la prueba de 
unidad para software convencional. A diferencia de la prueba de unidad del software 
convencional, la cual tiende a centrarse en el detalle algorítmico de un módulo y los datos que 
fluyen a lo largo de la interfaz de éste, la prueba de clases para software OO está dirigida por 
las operaciones encapsuladas en la clase y el estado del comportamiento de la clase. Así, la
prueba de una clase debe haber probado mediante las correspondientes técnicas de caja  de 
vidrio y caja negra el funcionamiento de cada uno de los métodos de dicha clase. Además, se 
deben haber generado casos de prueba para probar valores representativos de los atributos de dicha clase (esto puede realizarse aplicando la técnica de clases de equivalencia y análisis de valores límite).


Prueba de Integración
Debido a que el software OO no tiene una estructura de control jerárquica, las estrategias
convencionales de integración ascendente y descendente poseen un significado poco relevante en este contexto.
Generalmente se pueden encontrar dos estrategias diferentes de pruebas de integración en 
sistemas OO. La primera,  prueba basada en hilos (o threads),  integra el conjunto de clases 
necesario para responder a una entrada o evento del sistema. Cada hilo se integra y prueba 
individualmente. El segundo enfoque para la integración, prueba basada en el uso. Esta prueba comienza la construcción del sistema integrando y probando aquellas clases (llamadas clases independientes) que usan muy pocas de las clases. Después de probar las clases independientes, se comprueba la próxima capa de clases, llamadas clases dependientes, que usan las clases independientes. Esta secuencia de capas de pruebas de clases dependientes continúa hasta construir el sistema por completo.
Nótese cómo la prueba basada en hilos proporciona una estrategia más ordenada para realizar la prueba que la prueba basada en el uso. Esta prueba basada en hilos, suele aplicarse utilizando los diagramas de secuencia de objetos que diseñan cada evento de entrada al sistema.
Concretamente, se pueden realizar los siguientes pasos para generar casos de prueba a partir de un diagrama de secuencias.
1. Definir el conjunto de secuencias de mensajes a partir del diagrama de secuencia. Cada 
secuencia ha de comenzar con un mensaje  m  sin predecesor (habitualmente, un mensaje 
enviado al sistema por un actor), y estará formada por el conjunto de mensajes cuya ejecución 
dispara m.
2. Analizar sub-secuencias de mensajes a partir de posibles caminos condicionales en los 
diagramas de secuencia.
3. Identificar los casos de prueba que se han de introducir al sistema para que se ejecuten las 
secuencias de mensajes anteriores, en función de los métodos y las clases afectadas por la 
secuencia. Tanto valores válidos como inválidos deberían considerarse.
Nótese cómo el conjunto de casos de prueba puede aumentar exponencialmente si se trabaja 
sobre un sistema OO con un número elevado de interacciones. Por lo tanto, es necesario tener en cuenta este factor a la hora de realizar el diseño.


Prueba de Sistema
En el nivel de prueba del sistema, los detalles de las conexiones entre clases no afectan. El 
software debe integrarse con los componentes hardware correspondientes y se ha de 
comprobar el funcionamiento del sistema completo acorde a los requisitos. Como en el caso del software convencional, la validación del software OO se centra en las acciones visibles del 
usuario y las salidas del sistema reconocibles por éste. Para asistir en la determinación de 
casos de prueba de sistema, el ejecutor de la prueba debe basarse en los casos de uso que 
forman parte del modelo de análisis. El caso de uso brinda un escenario que posee una alta 
probabilidad con errores encubiertos en los requisitos de interacción del cliente. Los métodos 
convencionales de prueba de caja negra, pueden usarse para dirigir estas pruebas.
Prueba de Aceptación


La prueba de aceptación en un sistema OO es semejante  a la prueba de aceptación en un 
software tradicional. El motivo es que el objetivo de este tipo de prueba es comprobar si el 
cliente está satisfecho con el producto desarrollado y si este producto cumple con sus 
expectativas, en términos de los errores que genera y de la funcionalidad que suministra. Al 
igual que las pruebas convencionales serán los clientes quienes realicen estas pruebas y 
suministren los casos de prueba correspondientes.

Para Saber Mas Visite http://is.ls.fi.upm.es/udis/docencia/erdsi/Documentacion-Evaluacion-
6.pdf#search=%22Juristo%2C%20Natalia%20T%C3%A9cnicas%20de%20Evaluaci%C3%B3n
%20de%20Software%22 

Gestión de Riesgos y Gestión la configuración del software

Gestión de Riesgos RSKM - CMMI
¿Qué es un Riesgo?
Evento o condición incierta que, en caso de ocurrir, tiene un efecto positivo o negativo sobre los objetivos de un proyecto. PMI-127/129
Un riesgo puede tener una o más causas y de ocurrir puede tener uno o más impactos


Tres Condiciones de Riesgos
Para que el riesgo exista en cualquier circunstancia, las siguientes tres condiciones deben cumplirse 


1. El potencial de pérdida debe existir.
2. La incertidumbre con respecto al resultado final debe estar presente.
3. La decisión es necesaria para hacer frente a la incertidumbre y potencial de pérdida.


Componentes del riesgo
Probabilidad: Medida de la ocurrencia de una amenaza se produce
Impacto:  Medida de la pérdida que se producirá si la amenaza se hace realidad.
Exposición al riesgo: Medida de la magnitud del riesgo basado en los valores probabilidad y el impacto.

Gestión de riesgos
Es un enfoque sistemático para reducir al mínimo la exposición a potenciales pérdidas:


1. Proporciona un entorno disciplinado para evaluar continuamente lo que podría ir mal. (Evaluación de riesgos).
2. Establecimiento de las prioridades de mitigación.
3. La implementación de acciones para riesgos de alta prioridad y llevar a los riesgos dentro de la tolerancia.


Metas y Prácticas específicas
1. PREPARAR LA GESTIÓN DE RIESGO
1.1. Determinar las fuentes y las categorías de los riesgos


1.2. Definir los parámetros de los riesgos


1.3. Establecer una estrategia de gestión de riesgos




2. IDENTIFICAR Y ANALIZAR LOS RIESGOS.
2.1 Identificar riesgos.

2.2 Evaluar, categorizar y priorizar los riesgos.




3. MITIGAR LOS RIESGOS.
3.1 Desarrollar los planes de mitigación de riesgo.
3.2 Implementar los planes de mitigación de riesgo.


Para mas información visite:
http://www.sei.cmu.edu/library/assets/20090910webinar.pdf
http://www.sei.cmu.edu/library/assets/20090618webinar.pdf
http://www.sei.cmu.edu/library/abstracts/risk/upload/dorofeetutorialndia09_8819.pdf

Gestión  la configuración del software
Problemas
El cambio se encuentra presente en todo el ciclo de vida de una aplicación.
El desarrollo de software siempre es incremental 
El desarrollo iterativo consiste de en una evolución Controlada


GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE
Actividad constante aplicada durante todo el proceso de ingeniería de software para identificar, organizar y controlar las modificaciones que sufre el software.
Comienza cuando se inicia el proyecto de desarrollo de software y termina sólo cuando el software queda fuera de circulación.


OBJETIVOS

• Maximizar la productividad y minimizar los errores.
• Mejorar la facilidad para implantar cambios y reducir el esfuerzo para implementarlos
• Garantizar la calidad del software.

Otras definiciones
“Es el conjunto total de actividades utilizadas para administrar el contenido de un producto de software desde el principio hasta el final del proceso de desarrollo.” Humphrey


“Es la disciplina de administrar y controlar los cambios en la evolución de los sistemas de software” Bruegge, Dutoit


Propósito 

• Asegurar que el contenido del producto es conocido y se encuentra disponible siempre 
• Apoyar el control de cambios.
• Ayudar a la coordinación entre el equipo de desarrollo
• Tener un repositorio (depósito) único para los entregables.
• Tener una base histórica con los cambios del producto durante el tiempo.
• Es el conjunto de características funcionales y físicas del software detalladas en la documentación técnica o alcanzadas en un producto. (IEEE610.12-90)

Evita el CAOS
porque:
Se identifica el cambio
Se controla el cambio
Se garantiza que el cambio se implementa adecuadamente
Se informa del cambio a todos los interesados 


Configuración del software
Una configuración de software es el conjunto de elementos
que componen toda la información producida en el proceso
de desarrollo de software.
Cada uno de estos elementos se denomina: “Elemento de
Configuración de Software” (ECS). Los ECS pertenecen a alguna de las siguientes categorías:

• Programas (código fuente y ejecutables)
• Documentos técnicos o de usuario que describen los programas
• Datos internos o externos al programa

Tareas

• Identificación de los ECS individuales
• Control de versiones
• Control de cambios
• Auditoria de la configuración del software
•  Generación de informes sobre cambios de configuración

LINEA BASE (Baseline)
Es una especificación o producto que se ha revisado formalmente y sobre el cual se ha llegado a un acuerdo y, que de ahí en adelante, sirve como base para un desarrollo o modificación posterior

CONTROL DE VERSIONES
Es la combinación de herramientas y procedimientos para gestionar las versiones de los objetos de configuración creadas durante el proceso de Ing. de Software.


La GCS permite a un usuario especificar configuraciones alternativas del sistema de software mediante la selección de las versiones adecuadas de los ECS. Para ello se asocian atributos a cada versión del software


Atributo:
Número especifico de versión
Cadena de variables lógicas (indicadores) 


Proceso de control de cambios
1. Petición de cambio
2. Evaluación del cambio: Esfuerzo técnico, efectos secundarios,  impacto sobre otros componentes, costos.
3.Informe de Cambios (resultados evaluación) a la ACC (Autoridad de Control de Cambios). 
4.Se genera una OCI (Orden de Cambio de Ingeniería) para cada cambio: qué se cambiará; restricciones, criterios de revisión y auditoría. 
5.Objeto dado de baja 
6.Realización del cambio 
7.Revisión del cambio. 
8.Objeto dado de alta aplicando mecanismos de control de versión.

Calidad Del Sotware y mitos del ingeniero

Calidad

La calidad en el desarrollo y el mantenimiento del software, se ha convertido hoy en día en uno de los principales objetivos estratégicos de las organizaciones, debido a que cada vez más, los procesos principales de las organizaciones – y su supervivencia - dependen de los sistemas informáticos para su buen funcionamiento.
El principal instrumento para garantizar la calidad de las aplicaciones sigue siendo el Plan de Calidad, el cual se basa en normas o estándares genéricos y en procedimientos particulares. 
Los procedimientos pueden variar en cada organización, pero lo importante es que estén escritos, personalizados, adaptados a los procesos de la organización y que se sean cumplidos. 
La Calidad del Software es resultado del movimiento global dentro del proceso de mejoramiento continuo de los modelos y/ o estándares de producción de sistemas de información y software especializado.
A la hora de definir la calidad del software se debe diferenciar entre la calidad del Producto de software y la calidad del Proceso de desarrollo. No obstante, las metas que se establezcan para la calidad del producto van a determinar las metas a establecer para la calidad del proceso de desarrollo, ya que la calidad del producto va a estar en función de la calidad del proceso de desarrollo. Sin un buen proceso de desarrollo es casi imposible obtener un buen producto. 
La Calidad del Software debe implementarse en todo el ciclo de vida del mismo. 



Aseguramiento
-  Son las medidas preventivas que se toman paso a paso durante un proceso para evitar que el resultado final no sea defectuoso
-  Diferente de Control de Calidad

• No es solo la Revisión al final del proceso
• No es solo enfocado al cliente

Modelos De Calidad
Son aquellos documentos que integran la mayor parte de las mejores prácticas
Proponen temas de administración en los que cada organización debe hacer énfasis, 
Integran diferentes prácticas dirigidas a los procesos clave. Permiten medir los avances en calidad




Estándares de Calidad
Son aquellos que permiten definir un conjunto de criterios de desarrollo.
Guían la forma en que se aplica la Ingeniería del Software. 
Suministran los medios para que todos los procesos se realicen de la misma forma
Son una guía para lograr la productividad y la calidad


Modelos y Estándares de Calidad
El objetivo es implantar el Modelo o Estándar de Calidad del Software adecuado y aplicable a las características de la empresa de que se trate. 
La base para diseñar e implantar un buen Modelo o Estándar de Calidad del Software es conocer profundamente las características y necesidades de la empresa que lo aplicará y los deseos y pretensiones de sus clientes actuales y potenciales
Es necesario que todos los elementos del Modelo o Estándar de Calidad se estructuren en forma tal que permitan un control y aseguramiento de todos los procesos involucrados con la calidad.


Estructura de un Modelo de Calidad de Software


Factores de Calidad: representan la calidad desde el punto de vista del usuario y son las características que componen la calidad. También se denominan Atributos de Calidad Externos


Criterios de Calidad del Producto: Estos criterios son atributos que, cuando están presentes, contribuyen al aspecto de la calidad que el factor asociado representa. Se trata de una visión de la calidad desde el punto de vista del producto de software. También se denominan Atributos de Calidad Internos. 


Métricas del Producto: cuales son medidas cuantitativas de ciertas características del producto que, cuando están presentes, dan una indicación del grado en que dicho producto posee un determinado atributo de calidad. 



Atributos De La Calidad De Software

• Cumplir con los siguientes atributos:
• Seguro, Fiable, Tolerante a fallas
• Comprensible, Fácil de usar
• De complejidad baja,
• Fácil de aprender a manejar
• Mantenibilidad
• Fácil de probar
• Auditable
• Extensibilidad
• Homogeneidad, Adaptable, Modular, Reutilizable
• Eficaz, Preciso, Exacto
• Compatible, Portable y Acorde al contexto Tecnológico vigente
• Viable financieramente (Costos de Adquisición y Mantenimiento Vs Beneficios en generación de Valor)

Cual Es La Necesidad Que El Software Debe Satisfacer

1. Ser el medio (herramienta) que permita contribuir a “poner en orden la organización”
2. Que problema puede resolver:

• Mejor gobernabilidad de los procesos de negocio
• Mejorar el ambiente colaborativo y los Niveles de Satisfacción de sus Stakeholders

           •Clientes

           •Accionistas

           •Empleados

           •Aliados de Negocios

           •Proveedores

• Métricas (Indicadores de Desempeño)
• Posición Competitiva

Propósito Del Software
Mejorar la productividad de las organizaciones y los negocios.
Mejorar la calidad de vida del ser humano (Contrarrestar lo tedioso, riesgoso, incomodo, etc)



Panorama Mundial De La Ingeniería Del Software

• Costo de $(1 ingeniero USA) = $(2.5 ingenieros Colombianos) = $(5 ingenieros de India) = $(8 ingenieros de China)
• Si nuestra industria de software no se fortalece aplicando modelos y mejores practicas que internacionalmente sean reconocidos (Cmmi, ISO´s, IEEE, etc) y se capitalicen las tecnologías disponibles ;los grandes negocios (> 500mUsd) se los llevaran las potencias del Software

Mitos De La Ingeniería Del Software

Mitos de Gestión

• Resistencia al cambio en la gestión de proyectos
• Con un libro de estándares es suficiente
• Computadores modernos = Buen entorno de desarrollo

Mitos de Gestión

• Experiencia para saltarse las metodologías
• Incapacidad de los usuarios para comunicar sus necesidades

Mitos del Cliente

• Ideas genéricas al principio, detalles al final
• Requisitos en continua evolución

Mitos del Desarrollador

• El trabajo acaba cuando se ha escrito el programa y funciona
• Hasta que no se ejecuta el programa no puede comprobarse su calidad
• Sólo se entrega un programa funcionando
• Lo que uno crea sólo debe entenderlo él

Mitos Del Ingeniero De Software (punto de vista)
Los ingenieros de software día a día se posicionan más en nuestra sociedad, convirtiéndose así en pilares fundamentales para la creación de software que suplan necesidades de las distintas empresas. Somos profesionales que nos encargamos de maximizar la calidad y minimizar el coste, además no solo nos centramos en el área de los sistemas, sino también en muchas otras áreas, ¿Por qué? Porque hoy día la mayoría de las empresas necesitan de sistemas inteligentes que manejen, organicen y contabilicen lo que se hace, se vende, se produce y la mejor forma de llevar estos datos, son mediantes software que lleven o guarden una mejor consistencia de los datos, almacenándolos en bases de datos en la cual la información esté segura y la empresa no se vea perjudicada por la mala manipulación de estos.
Hoy por hoy en el ámbito de la ingeniería de sistemas se han creado muchos mitos; claro que un ingeniero de sistemas debe estar informado de todo en cuanto a tecnología, pero muchas veces las personas asociamos el concepto de tecnología con un computador, dado que la tecnología abarca mucho más que esto, ahora bien asociando esto con los ingenieros de sistemas vemos como muchas personas tienen ideas o conceptos diferentes al cual se debería dar, por ejemplo, una persona común por decirlo así diría que los ingenieros de sistemas deben saber todo en cuanto a un computador (estructura, componentes, como armarlo y desarmarlo..) en fin debe saber todo acerca de ellos y sí, nos compete a nosotros saber lo que pasa en la tecnología, cuanto avanza, ya que es nuestra herramienta de trabajo, pero no es parte de nuestro trabajo desarmar y arreglar un computador, dado que la verdadera labor de un ingeniero de sistemas abarca muchos ámbitos en especial el ingeniero de software que realiza todas las actividades referentes al desarrollo de software, aunque el Ingeniero sabe desarrollar software, No es un desarrollador. Es decir, no solo se dedica a programar aplicaciones sino que tiene toda la formación para diseñarlo correctamente.
Otro mito que se podría generar alrededor de este tema, es que muchas veces vemos a los ingenieros como personas exitosas que se ganan el dinero fácil, y no es así, como cualquier otra profesión nosotros como ingenieros tenemos que dedicarnos a satisfacer los requerimientos de un cliente y al igual que las demás personas, recogemos frutos trabajando y esforzándonos en lo que hacemos; quizás muchos de nuestros padres nos ven como Bill Gates, uno de los fundadores de Microsoft, como un gran empresario , no sabiendo que para llegar allá, fue con mucho esfuerzo , sacrificio y dedicación.
Un colega Ingeniero de Sistemas, que esta al mismo nivel que yo, me ve con la capacidad de asumir grandes retos, de mostrar grandes resultados a la hora de realizar un proyecto, de desenvolverme de la mejor manera en cualquier escenario y ámbito,  como un profesional con muchas expectativas, pero la realidad es que considero que me falta mucho por aprender, tengo la disposición y las ganas, pero con tantos ingenieros muy bien preparados, es lógico que el campo laboral cuente con muchas personas altamente capacitadas y por ello me falta mucha preparación y experiencia.
Por último, yo como ingeniera de software me veo como la súper empresaria exitosa, como lo piensan mis padres, siendo buscada por muchas empresas para desarrollar grandes proyectos, y aunque yo me vea así, la realidad es otra, actualmente hay muchos ingenieros y tenemos mucha competencia, empresas las cuales por pagar menos contrata a técnicos y tecnólogos, además de no darle suficiente valor al trabajo que se está realizando y no apreciar lo que hacemos, y muchas veces  por ello pienso que el camino es largo, con mucho esfuerzo, pero sobre todo mucha dedicación, la cual sé que al final dará resultados positivos.
En conclusión, se han creado muchos mitos alrededor de los ingenieros de software y no solo de ellos, sino también de los ingenieros de sistemas en general, los cuales valen la pena aclarar, ya que son ideas erróneas en cuanto a lo que realmente hacemos y queremos, pero ya está de parte de nosotros inculcar y demostrar a las demás personas que sus ideas son equivocadas y que estamos acá para generar una nueva visión de las cosas y dar un aporte al desarrollo del entorno en el que vivimos.

Diagrama Arquitectura Cliente/Servidor- saas-soa-mvc-Cloud Computing

RMI- CORBA-BPM-BPML

RMI



RMI (Java Remote Method Invocation) es un mecanismo ofrecido por Java para invocar un método de manera remota. Forma parte del entorno estándar de ejecución de Java y proporciona un mecanismo simple para la comunicación de servidores en aplicaciones distribuidas basadas exclusivamente en Java. Si se requiere comunicación entre otras tecnologías debe utilizarse CORBA o SOAP en lugar de RMI.
RMI se caracteriza por la facilidad de su uso en la programación por estar específicamente diseñado para Java; proporciona paso de objetos por referencia (no permitido por SOAP), recolección de basura distribuida (Garbage Collector distribuido) y paso de tipos arbitrarios (funcionalidad no provista por CORBA).
A través de RMI, un programa Java puede exportar un objeto, con lo que dicho objeto estará accesible a través de la red y el programa permanece a la espera de peticiones en un puerto TCP. A partir de ese momento, un cliente puede conectarse e invocar los métodos proporcionados por el objeto.
La invocación se compone de los siguientes pasos:
Encapsulado (marshalling) de los parámetros (utilizando la funcionalidad de serialización de Java).
Invocación del método (del cliente sobre el servidor). El invocador se queda esperando una respuesta.
Al terminar la ejecución, el servidor serializa el valor de retorno (si lo hay) y lo envía al cliente.
El código cliente recibe la respuesta y continúa como si la invocación hubiera sido local.


Arquitectura 

La arquitectura RMI puede verse como un modelo de cuatro capas.
Primera capa
La primera capa es la de aplicación y se corresponde con la implementación real de las aplicaciones cliente y servidor. Aquí tienen lugar las llamadas a alto nivel para acceder y exportar objetos remotos. Cualquier aplicación que quiera que sus métodos estén disponibles para su acceso por clientes remotos debe declarar dichos métodos en una interfaz que extienda java.rmi.Remote. Dicha interfaz se usa básicamente para "marcar" un objeto como remotamente accesible. Una vez que los métodos han sido implementados, el objeto debe ser exportado. Esto puede hacerse de forma implícita si el objeto extiende la clase UnicastRemoteObject (paquete java.rmi.server), o puede hacerse de forma explícita con una llamada al método exportObject() del mismo paquete.
Segunda capa
La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que interactúa directamente con la capa de aplicación. Todas las llamadas a objetos remotos y acciones junto con sus parámetros y retorno de objetos tienen lugar en esta capa.
Tercera capa
La capa 3 es la de referencia remota, y es responsable del manejo de la parte semántica de las invocaciones remotas. También es responsable de la gestión de la replicación de objetos y realización de tareas específicas de la implementación con los objetos remotos, como el establecimiento de las persistencias semánticas y estrategias adecuadas para la recuperación de conexiones perdidas. En esta capa se espera una conexión de tipo stream (stream-oriented connection) desde la capa de transporte.
Cuarta Capa
La capa 4 es la de transporte. Es la responsable de realizar las conexiones necesarias y manejo del transporte de los datos de una máquina a otra. El protocolo de transporte subyacente para RMI es JRMP (Java Remote Method Protocol), que solamente es "comprendido" por programas Java.


Elementos

• Toda aplicación RMI normalmente se descompone en 2 partes:
• Un servidor, que crea algunos objetos remotos, crea referencias para hacerlos accesibles, y espera a que el cliente los invoque.
• Un cliente, que obtiene una referencia a objetos remotos en el servidor, y los invoca.

Para mas información visite http://es.wikipedia.org/wiki/Java_Remote_Method_Invocation




CORBA

En un sentido general, CORBA "envuelve" el código escrito en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos. Los objetos que resultan, pueden entonces ser invocados desde otro programa (u objeto CORBA) desde la red. En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras, pero con más información.
CORBA utiliza un lenguaje de definición de interfaces (IDL) para especificar las interfaces con los servicios que los objetos ofrecerán. CORBA puede especificar a partir de este IDL, la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Implementaciones estándar existen para Ada, C, C++, Smalltalk, Java, Python, Perl y Tcl.
Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). El código del cliente sirve para poder realizar las llamadas a métodos remotos. Es el conocido como stub, el cual incluye un proxy (representante) del objeto remoto en el lado del cliente. El código generado para el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que rellenar para implementar los métodos del objeto.
CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones. Y así este no es un sistema operativo en si, en realidad es un middleware.


Para mas información visite http://es.wikipedia.org/wiki/CORBA


BPM
Se llama Gestión o administración por procesos de negocio (Business Process Management o BPM en inglés) a la metodología corporativa cuyo objetivo es mejorar el desempeño (Eficiencia y Eficacia) de la Organización a través de la gestión de los procesos de negocio, que se deben diseñar, modelar, organizar, documentar y optimizar de forma continua. El Modelo de Administración por Procesos, se refiere al cambio operacional de la empresa al migrar de una operación funcional a una operación de administrar por procesos.


Ventajas

Un proceso se puede ver como un conjunto de recursos y actividades interrelacionados que transforman elementos de entrada en elementos de salida. Los recursos pueden incluir personal, finanzas, instalaciones, equipos, técnicas y métodos.
A través del modelado de los procesos de negocio, al interior de una organización, puede lograrse un mejor entendimiento de la operación de la empresa y muchas veces esto presenta la oportunidad de mejorar los procesos y con ello mejorar el desempeño. La estructuración de los procesos reduce errores, asegurando que los procesos se comporten siempre de la misma manera, reduciendo el margen de error y dando elementos que permitan visualizar el estado de los mismos durante cada etapa. La administración de los procesos permite asegurar que los mismos se ejecuten eficientemente, cumpliendo con estándares de calidad previamente establecidos, y ayudando a la obtención de información que luego puede ser usada para mejorarlos. Es a través de la información que se obtiene de la ejecución diaria de los procesos, que se puede identificar posibles ineficiencias o fallas en los mismos, y actuar sobre ellos para optimizarlos.

Razones de La Gestión de Procesos 

Existen diversos motivos que mueven la gestión de los Procesos dentro de una organización, entre los cuales se encuentran:

• Extensión del programa institucional de calidad
• Cumplimiento de legislaciones vigentes
• Crear nuevos y mejores procesos (mejoramiento continuo)
• Entender qué se está haciendo bien o mal a través de la comprensión de los procesos
• Documentar los procesos para la subcontratación y la definición del Service Level Agreement (SLA)
• Automatización y organización de los procesos
• Crear y mantener la cadena de valor

Para mayor Información visite http://es.wikipedia.org/wiki/Gesti%C3%B3n_de_procesos_de_negocio






BPML



BPML es un metalenguaje XML para el modelado de procesos de negocio. Una norma publicada por Business Process Management Initiative (BPMI), que proporciona una forma universal para describir los procesos de negocio en las organizaciones. Los procesos de negocio modelados con BPML se pueden implementar y ejecutar en cualquier sistema de gestión de BPML compatible con procesos de negocio (BPMS).


Fundamentos BPML


Proceso


El proceso es el concepto básico de BPML. Los componentes clave de un proceso son:


* Ejecución de un conjunto de actividades


* La interacción con los participantes por el intercambio de mensajes


* Las reglas predefinidas para determinar el flujo de la ejecución


* Los horarios para gobernar el inicio y la finalización de la ejecución


* Procesamiento de los datos mediante la celebración de los datos internos que pueden ser accedidos por todas sus actividades


Voy a usar un proceso handlePurchaseOrder simple para ilustrar cómo modelar un proceso que utiliza BPML. El proceso contiene los siguientes pasos:


1. En el inicio del proceso esperará a que la "orden de compra" del mensaje.


2. Cuando se recibe una orden de compra, el proceso será comprobar si es un cliente existente, y creará una cuenta de cliente si se trata de un nuevo cliente.


3. El proceso de revisar el sistema de inventario para ver si hay suficiente inventario para cumplir con la orden.


4. El proceso envía un intento de envío a todas las compañías se contrae. Se establece un precio predefinido, y aceptar la primera oferta que cumpla con el criterio de precio.


5. Los horarios de procesar una orden de entrega con el portador seleccionado.


6. El proceso envía una notificación de envío para el cliente.




Tomado de http://business.highbeam.com/436115/article-1G1-90305758/model-your-business-processes-using-bpml-just-bpml

SOA, SAAS, ASP, C/S

SOA

La arquitectura orientada a servicios de cliente (en inglés Service Oriented Architecture), es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio.
Permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros.
SOA define las siguientes capas de software:

• Aplicaciones básicas - Sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y bajo cualquier figura de propiedad;
• De exposición de funcionalidades - Donde las funcionalidades de la capa aplicativa son expuestas en forma de servicios (generalmente como servicios web);
• De integración de servicios - Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración;
• De composición de procesos - Que define el proceso en términos del negocio y sus necesidades, y que varía en función del negocio;
• De entrega - donde los servicios son desplegados a los usuarios finales.

SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integración y consolidación.


Diseño y Desarrollo De SOA

La metodología de modelado y diseño para aplicaciones SOA se conoce como análisis y diseño orientado a servicios. La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implementación. Para que un proyecto SOA tenga éxito los desarrolladores de software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son orquestados por clientes o middleware para implementar los procesos de negocio. El desarrollo de sistemas usando SOA requiere un compromiso con este modelo en términos de planificación, herramientas e infraestructura.
Cuando la mayoría de la gente habla de una arquitectura orientada a servicios están hablando de un juego de servicios residentes en Internet o en una intranet, usando servicios web. Existen diversos estándares relacionados a los servicios web. Incluyen los siguientes:

• XML
• HTTP
• SOAP
• REST
• WSDL
• UDDI

Hay que considerar, sin embargo, que un sistema SOA no necesariamente necesita utilizar estos estándares para ser "Orientado a Servicios" pero es altamente recomendable su uso.
En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado. La mayoría de las definiciones de SOA identifican la utilización de Servicios Web (empleando SOAP y WSDL) en su implementación, no obstante se puede implementar SOA utilizando cualquier tecnología basada en servicios.


Diferencias Con Otras Arquitecturas
Al contrario de las arquitecturas orientado a objetos, las SOAs están formadas por servicios de aplicación débilmente acoplados y altamente interoperables. Para comunicarse entre sí, estos servicios se basan en una definición formal independiente de la plataforma subyacente y del lenguaje de programación (p.ej., WSDL). La definición de la interfaz encapsula (oculta) las particularidades de una implementación, lo que la hace independiente del fabricante, del lenguaje de programación o de la tecnología de desarrollo (como Plataforma Java o Microsoft .NET). Con esta arquitectura, se pretende que los componentes de software desarrollados sean muy reutilizables, ya que la interfaz se define siguiendo un estándar; así, un servicio C# podría ser usado por una aplicación Java. En este sentido, ciertos autores definen SOA como una Súper-Abstracción.


Beneficios

Los beneficios que puede obtener una organización que adopte SOA son:

• Mejora en los tiempos de realización de cambios en procesos.
• Facilidad para evolucionar a modelos de negocios basados en tercerización.
• Facilidad para abordar modelos de negocios basados en colaboración con otros entes (socios, proveedores).
• Poder para reemplazar elementos de la capa aplicativa SOA sin disrupción en el proceso de negocio.
• Facilidad para la integración de tecnologías disímiles.

Para mas informacion visite http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios

SAAS

Software como Servicio (del inglés: Software as a Service, SaaS) es un modelo de distribución de software donde el software y los datos que maneja se alojan en servidores de la compañía de tecnologías de información y comunicación (TIC) y se accede con un navegador web o un cliente fino especializado, a través de internet. La empresa TIC provee el servicio de mantenimiento, operación diaria, y soporte del software usado por el cliente. Regularmente el software puede ser consultado en cualquier computador, esté presente en la empresa o no. Se deduce que la información, el procesamiento, los insumos y los resultados de la lógica de negocio del software están hospedados en la compañía de TIC.



Las características del software como servicio incluyen:

• Acceso y administración a través de una red.
• Actividades gestionadas desde ubicaciones centrales, en lugar de la sede de cada cliente, permitiéndoles tener acceso remoto a las aplicaciones mediante la web.
• La distribución de la aplicación es más cercana al modelo uno-a-muchos (una instancia con múltiples usuarios) que al modelo uno-a-uno, incluyendo arquitectura, precios, colaboración y administración.
• Actualizaciones centralizadas, lo cual elimina la necesidad de descargar parches por parte de los usuarios finales.
• Frecuente integración con una red mayor de software de comunicación, bien como parte de un mashup o como un enlace para una plataforma como servicio.

Ventajas 

• No es necesario que el cliente cuente con un área especializada de soporte para el sistema, por lo que se reducen sus costes y riesgo de inversión.
• La responsabilidad de la operación recae en la empresa IT. Esto significa que la garantía de disponibilidad de la aplicación y su correcta funcionalidad, es parte del servicio que da la compañía proveedora del software.
• La empresa IT no desatiende al cliente. El servicio y atención continua del proveedor al cliente es necesaria para que este último siga pagando el servicio.
• La empresa IT provee los medios seguros de acceso en los entornos de la aplicación. Si una empresa IT quiere dar SaaS en su cartera de productos debe ofrecer accesos seguros para que no se infiltren datos privados en la red pública.
• No es necesaria la compra de una licencia para utilizar el software, sino el pago de un alquiler o renta por el uso del software. Aunque se dan casos particulares donde el servicio es totalmente gratuito, como por ejemplo en el servicio de blogs de diferentes compañías: Wordpress, Blogger, etc. Es decir, se cuenta con el servicio, se puede acceder libremente, se garantiza usabilidad y actualidad, pero no se paga por el servicio.
• Se le permite al cliente completa flexibilidad en el uso de los sistemas operativos de su preferencia, o al cual pueda tener acceso.

Inconvenientes

• La persona usuaria no tiene acceso directo a sus contenidos, ya que están guardados en un lugar remoto, y en caso de no contar con mecanismos de cifrado y control disminuye el índice de privacidad, control y seguridad que ello supone, ya que la compañía TI podría consultarlos.
• El usuario no tiene acceso al programa, por lo cual no puede hacer modificaciones (dependiendo de la modalidad del contrato de servicios que tenga con la compañía TI).
• Al estar el servicio y el programa dependientes de la misma empresa no permite al usuario migrar a otro servicio utilizando el mismo programa (dependiendo de la modalidad del contrato de servicios con la compañía de TI).
• Si el servicio de Internet no está disponible por parte del ISP, el usuario no tendrá acceso al programa, por lo que sus operaciones se verán afectadas hasta que dicho servicio se restablezca.
• Otras consideraciones sobre dificultades en implementaciones SaaS, surgen de una falta de entendimiento de las verdaderas implicaciones de depender de un servicio externo que pueden llevar a incurrir en sobrecostos pero sobre todo en un servicio que no cumple las expectativas de ciertos clientes.

Para saber mas visite http://es.wikipedia.org/wiki/Software_como_servicio







Arquitectura Cliente -Servidor

Una arquitectura es un conjunto de reglas, definiciones, términos y modelos que se emplean para producir un producto. 
La arquitectura Cliente/Servidor agrupa conjuntos de elementos que efectúan procesos distribuidos y computo cooperativo.



Beneficios: 
Mejor aprovechamiento de la potencia de cómputo (Reparte el trabajo). 
Reduce el tráfico en la Red. 
Opera bajo sistemas abiertos. 
Permite el uso de interfaces gráficas variadas y versátiles. 


¿Qué es el Cliente? 
Conjunto de Software y Hardware que invoca los servicios de uno o varios servidores. 


Características: 
El Cliente oculta al Servidor y la Red. 
Detecta e intercepta peticiones de otras aplicaciones y puede redirigirlas. 
Dedicado a la cesión del usuario ( Inicia...Termina ). 
El método más común por el que se solicitan los servicios es a través de RPC (Remote Procedure Calls). 
Funciones Comunes del Cliente: 
Mantener y procesar todo el dialogo con el usuario. 
Manejo de pantallas. 
Menús e interpretación de comandos. 
Entrada de datos y validación. 
Procesamiento de ayudas. 
Recuperación de errores. 



¿Qué es el Servidor? 
Conjunto de Hardware y Software que responde a los requerimientos de un cliente. 


Tipos Comunes de Servidores: 
Servidor de Archivos. 
Servidor de Bases de Datos (SQL, CBASE, ORACLE, INFORMIX). 
Servidor de Comunicaciones 
Servidor de Impresión. 
Servidor de Terminal. 
Servidor de Aplicaciones. 
Funciones Comunes del Servidor: 
Acceso, almacenamiento y organización de datos. 
Actualización de datos almacenados. 
Administración de recursos compartidos. 
Ejecución de toda la lógica para procesar una transacción. 
Procesamiento común de elementos del servidor (Datos, capacidad de CPU, almacenamiento en disco, capacidad de impresión, manejo de memoria y comunicación). 


Arquitectura Multi-Capas

La arquitectura cliente/servidor genérica tiene dos tipos de nodos en la red: clientes y servidores. Consecuentemente, estas arquitecturas genéricas se refieren a veces como arquitecturas de dos niveles o dos capas.
Algunas redes disponen de tres tipos de nodos:

• Clientes que interactúan con los usuarios finales.
• Servidores de aplicación que procesan los datos para los clientes.
• Servidores de la base de datos que almacenan los datos para los servidores de aplicación.

Esta configuración se llama una arquitectura de tres-capas.
Ventajas de las arquitecturas n-capas:

• La ventaja fundamental de una arquitectura n-capas comparado con una arquitectura de dos niveles (o una tres-capas con una de dos niveles) es que separa hacia fuera el proceso, eso ocurre para mejorar el balance la carga en los diversos servidores; es más escalable.

Desventajas de las arquitecturas de la n-capas:

• Pone más carga en la red, debido a una mayor cantidad de tráfico de la red.
• Es mucho más difícil programar y probar el software que en arquitectura de dos niveles porque tienen que comunicarse más dispositivos para terminar la transacción de un usuario.

Ventajas

• Centralización del control: los accesos, recursos y la integridad de los datos son controlados por el servidor de forma que un programa cliente defectuoso o no autorizado no pueda dañar el sistema. Esta centralización también facilita la tarea de poner al día datos u otros recursos (mejor que en las redes P2P)..
• Escalabilidad: se puede aumentar la capacidad de clientes y servidores por separado. Cualquier elemento puede ser aumentado (o mejorado) en cualquier momento, o se pueden añadir nuevos nodos a la red (clientes y/o servidores).
• Fácil mantenimiento: al estar distribuidas las funciones y responsabilidades entre varios ordenadores independientes, es posible reemplazar, reparar, actualizar, o incluso trasladar un servidor, mientras que sus clientes no se verán afectados por ese cambio (o se afectarán mínimamente). Esta independencia de los cambios también se conoce como encapsulación.
• Existen tecnologías, suficientemente desarrolladas, diseñadas para el paradigma de C/S que aseguran la seguridad en las transacciones, la amigabilidad de la interfaz, y la facilidad de empleo.

Desventajas

• La congestión del tráfico ha sido siempre un problema en el paradigma de C/S. Cuando una gran cantidad de clientes envían peticiones simultaneas al mismo servidor, puede ser que cause muchos problemas para éste (a mayor número de clientes, más problemas para el servidor). Al contrario, en las redes P2P como cada nodo en la red hace también de servidor, cuanto más nodos hay, mejor es el ancho de banda que se tiene.
• El paradigma de C/S clásico no tiene la robustez de una red P2P. Cuando un servidor está caído, las peticiones de los clientes no pueden ser satisfechas. En la mayor parte de redes P2P, los recursos están generalmente distribuidos en varios nodos de la red. Aunque algunos salgan o abandonen la descarga; otros pueden todavía acabar de descargar consiguiendo datos del resto de los nodos en la red.
• El software y el hardware de un servidor son generalmente muy determinantes. Un hardware regular de un ordenador personal puede no poder servir a cierta cantidad de clientes. Normalmente se necesita software y hardware específico, sobre todo en el lado del servidor, para satisfacer el trabajo. Por supuesto, esto aumentará el coste.
• El cliente no dispone de los recursos que puedan existir en el servidor. Por ejemplo, si la aplicación es una Web, no podemos escribir en el disco duro del cliente o imprimir directamente sobre las impresoras sin sacar antes la ventana previa de impresión de los navegadores.

Para mayor informacion visite http://es.wikipedia.org/wiki/Cliente-servidor

Diferencias y Similitudes Entre Varias Arquitecturas


1. ES LO MISMO CLIENTE SERVIDOR QUE SOA


Para nuestro concepto tanto SOA como la arquitectura c/s son arquitecturas de gran importancia ya que la primera es la lógica del negocio y la segunda es la arquitectura en la cual se distribuye la información, Al contrario de las arquitecturas orientadas a objetos, SOA está formada por servicios de aplicación con acoplamiento débil y altamente interoperable.
Una diferencia clara de SOA con la arquitectura c/s es que esta está orientada a procesos y enfocada al cambio. De esta forma las empresas TI se benefician mucho ya que con esta pueden reconfigurar rápidamente sus recursos de TI sin necesidad de realizar una integración profunda, lo cual les permite liberar recursos para abrir espacio a la innovación y a la alta calidad.


2. ES LA  ARQUITECTURA CLIENTE SERVIDOR LA BASE DE SOA


La arquitectura C/S si es la base de SOA ya que SOA es una evolución de esta, aunque hay que tener en cuenta que SOA puede ser claramente independiente de la arquitectura C/S ya que esta es la lógica del negocio.
Como evolución de la arquitectura C/S esta contempla en si unos puntos claros de la arquitectura c/s Tales como:
-las funciones de la interface del usuario
- la lógica de las aplicaciones
- la administración de los datos, están separados de forma que cada una puede ser implementada usando las plataformas y las tecnologías que mejor se adapten a la tarea.
SOA incorpora servicios que corren en distintas plataformas y estos  están alojados en distintos servidores.


3. COMO SE ACOPLA SOA Y C/S CON SAAS Y ASP


Siendo SOA una evolución de la arquitectura cliente servidor enfocándose a los servicios podemos decir que hay una alta relación con las arquitecturas saas y asp ya que siendo ASP un proveedor de servicios, Y SAAS un modelo de distribución de software podemos contemplar que todos están con un mismo fin satisfacer las necesidades del cliente ofreciendo en si un servicio o un software de calidad.
Aunque existen diferencias notables entre estas arquitecturas como por ejemplo ASP siendo proveedor de software este ofrece sus servicios a múltiples clientes y este puede adaptar dicho software a su modo para garantizar su necesidad en cambio en SAAS estando esta en la nube presta sus servicios a muchos clientes con la clara diferencia de que estos solo pueden acceder a este sin modificarlo un ejemplo claro de este es gmail y siendo SOA una arquitectura orientada a servicios en donde su claro objetivo no es más que darle soporte a los requisitos del negocio y contemplando la clara perspectiva de que la arquitectura c/s no garantiza la buena lógica de negocios ya que esta presentaba La congestión del tráfico ya que esta siempre ha sido un problema en el paradigma de C/S. Cuando una gran cantidad de clientes envían peticiones simultáneas al mismo servidor, puede ser que cause muchos problemas para éste ya que a mayor número de clientes, más problemas para el servidor por este motivo fue creado SOA ya que este satisface dichos problemas. Entonces como conclusión podemos decir que estas arquitecturas buscan la mejora de las tecnologías en sí, ya que un cliente siempre lo que espera en un software o en un servicio es la seguridad, la fiabilidad y la disponibilidad estas están en la clara respuesta sobre estos planteamientos ofreciéndonos siempre un servicio o un software de alta calidad garantizándonos éxitos a nosotros como clientes.


4. ESTANDARES DE SOA


Service Component Architecture (SCA): En el post pasado dijimos que esta especificación provee un modelo para la creación de componentes de servicios dentro de una solución de negocios, es decir las actividades las cuales están en el corazón de las aplicaciones. SCA provee un modelo de programación para crear componentes de servicios escritos ya sea en Java, BPEL, C++ o lenguajes declarativos como XSLT.


Service Data Objects (SDO): Establece un significado consistente a los datos que operan entre diversas aplicaciones sin importar la fuente o el formato de las mismas.Ofrece un mecanismo para unificar datos de diversas bases de datos y servicios.


Business Process Execution Language (BPEL): Provee un estándar de procesos de negocio empresarial para la ejecución y orquestación. Usando BPEL se pueden diseñar procesos de negocio que integran servicios discretos dentro de un flujo de proceso de presentación final. Esta integración reduce tremendamente los costos de proceso y complejidad.


Transformaciones XSL (XSLT): Procesa documentos XML y transforma datos de un esquema de documento XML en otro. 


Java Connector Architecture (JCA): Provee una solución en tecnología Java para la conexión entre diversos servidores de aplicaciones.
Java Messaging Service (JMS): Provee un estándar de mensajeo para comunicar diversas aplicaciones basadas en Java 2 y Enterprise Edition (Java EE) a través de sistemas heterogéneos.


Archivos Web Services Description Language (WSDL): Proporcionan los puntos de entrada en una aplicación compuesta SOA (composite application). El archivo WSDL proporciona un lenguaje estándar reducido y es la base para entender las capacidades de un servicio. El Simple Object Access Protocol (SOAP) proporciona el protocolo de red para la entrega de mensajes.


http://oscaryani.blogspot.com/2010/07/estandares-adoptados-por-oracle-soa.html




5. SOA NO ES LO MISMO QUE WEBSERVICES ¿Por qué?


SOA y servicios web son dos cosas diferentes ya que estos  son la preferencia basada en estándares  al contrario de SOA ya que este se puede implementar con múltiples tecnologías tales como MOM, CORBA, COBOL ETC.


SOA  es un mecanismo de intercambio de información dentro de los muchos que se utilizan,  para conectar o transmitir información de las aplicaciones. Estos son estándares, lo que comúnmente utilizamos. Es importante concretar que Web Services no es SOA, sino un mecanismo de intercambio de información.


Aunque hay que tener en cuenta que cuando se desea conseguir la máxima reutilización de información  se pueden utilizar los estándares más ampliamente soportados teniendo en cuenta aspectos como la reutilización de funcionalidades por otros consumidores, Reutilización de funcionalidades de otros servicios, Aprovechamiento de otras herramientas y Conocimiento del personal.


En conclusión podemos decir que SOA es una abstracción del éxito de los servicios web para integración de sistemas de información ofreciendo así un gran alto potencial ,bajos costos , alta integración y de gran flexibilidad favoreciendo en si la automatización de las relaciones de negocio a negocio a través de Internet.