martes, 24 de mayo de 2016

SISTEMA DE TIEMPO REAL (STR)


Un sistema de tiempo real es un sistema que responde a un estímulo externo dentro de un tiempo especificado, no depende solo de que la lógica e implementación de los programas computacionales sea correcto, también se debe conocer exactamente el tiempo que le tomará al sistema responder a un determinado evento. Este tiempo debe ser invariable/constante y además si las restricciones de tiempo no son respetadas se dice que el sistema ha fallado.

Los sistemas de tiempo real pueden dividirse en dos tipos diferentes:

  •   Tiempo real estricto (hard real-time): Cuando es absolutamente necesario que la respuesta se produzca dentro del límite especificado, en otro caso producirá daños no deseados o un error fatal en el sistema. Ej.: control de vuelo.

  •  Tiempo real no estricto(soft real-time): Son aquellos en los que los tiempos de respuesta son importantes pero el sistema seguirá funcionando correctamente aunque los tiempo limites no se cumplen y pese a que el plazo no se cumplió aún tiene sentido planificar y completar la tarea.

CARACTERÍSTICAS

  • Determinismo: Se refiere a cuanto es el tiempo que toma una tarea en iniciarse después de una interrupción, esto es importante porque los sistemas de tiempo real necesitan que ciertas tareas se ejecuten antes de que otras puedan iniciar. 

  • Tamaño y complejidad: A menudo los problemas relacionados con sistemas en tiempo real se convierten en problemas de gran tamaño y complejidad, es por ello que los sistemas de tiempo real precisan mantenimiento constante y mejoras durante su ciclo de vida, deben evolucionar continuamente. 

  • Manipulación de números reales: Es la manera de representar los valores leídos del mundo real en un computador. 

  • Seguridad y fiabilidad: Los sistemas en tiempo real suelen estar relacionados con procesos en los que los fallos tienen consecuencias graves, por lo tanto la tolerancia a fallos es un factor de vital importancia en su diseño. 

  • Concurrencia: En general, un mismo sistema ha de responder a distintos estímulos realizando distintos procesos ligados entre sí o independientes. Se deben realizar procesos de control concurrentes, por lo que es necesario disponer de herramientas que permitan programación concurrente. 

  • Eficiencia: Esta característica es exigible a todo tipo de sistemas, aun mas en sistemas que pueden ser críticos, como los STR(critico respecto al tiempo). Con esta característica se pretende asegura que el funcionamiento lógico del sistema es correcto y óptimo. 

  • Dependencia del tiempo: Como ya hemos visto el tiempo es el factor distintivo de los STR, a los que se les exige no solo una corrección lógica, si no que cumplan unos determinados requerimientos temporales. Su comportamiento temporal tiene que ser determinista, y a la hora del diseño, hay que prever el peor de los casos. 

  • Dispositivos de E/S especiales: La conexión con el exterior está adaptada a los procesos que se controlan y a menudo condicionan el funcionamiento de sistema. Las interacciones con el exterior pueden ser activas o pasivas, es decir, el sistema debe controlar el acceso al medio físico, o bien el medio físico perturba de alguna manera al sistema de control.

    Existen unas propiedades que permiten distinguir los sistemas de tiempo real de los que no lo son y aquí te nombramos las siguientes:

* Garantía de plazos: Todas las tareas ejecutan su actividad dentro de plazo cada vez que se activan (los plazos de todas las tareas están garantizados)


* Tiempo de respuesta máximo: En un sistema de tiempo real se trata de acotar el tiempo de respuesta en el peor de los casos de todas las tareas.


* Estabilidad: Si a causa de una sobrecarga del sistema no se pueden ejecutar todas las tareas dentro de plazo, se debe garantizar que, al menos, un subconjunto de tareas críticas cumpla los plazos.


HERRAMIENTA UTILIZADA PARA MODELAR EN STR

Podemos apoyarnos en UML para el modelado de sistemas en tiempo real y al hacerlo podemos tener en cuenta las siguientes pautas:

* Capturar y entender los requerimientos usando un modelo de casos de uso.

* Estudiar las distintas partes que conforman al sistema y cómo interactúan estas. Reflejando las interfaces, protocolos e intercambio de señales. Para tal fin nos podemos apoyar de los diagramas de clases, estructura compuesta y comunicación.

* Estudiar el comportamiento del sistema en el tiempo y el dependiente del estado usando diagramas de interacción, diagramas de transición de estados y diagramas de tiempo.

Por supuesto esta no es una relación exhaustiva, en caso de ser necesario adicione los diagramas que sean necesarios, lo importante como siempre es tener una comprensión aceptable del problema y especificar una solución que lo resuelva.

miércoles, 4 de mayo de 2016

MODELO DE SISTEMA DER (Elemento basados en la relación de entidades) - DIAGRAMA DE CLASES

  Ejemplo visto en la clase teórica de Ingeniería de software I en donde se puede visualizar dos entidades(Cliente, Mercadería) con sus atributos y su asociación(Compra).
  Dicho ejemplo fue plasmado en la herramienta Enterprise Architect, que en primer lugar lo pasamos a un modelo conceptual utilizando el Diagrama de Clase y DER, posteriormente generamos su correspondiente código lógico y finalmente lo transformamos al modelo físico.

  A continuación se encuentra el link de los correspondientes archivos del tema mencionado, el cual se podra descargar: 

https://drive.google.com/file/d/0B5AGO34R_gdMQTM0dTlnOVVleHM/view?usp=sharing
    
           

martes, 12 de abril de 2016

¿LA COMPUTACIÓN SOLUCIONA TODO?


  La computadora ha sido uno de los factores de cambio más importantes de nuestra sociedad; dicha sociedad admira la facilidad que tienen estas máquinas para resolver diferentes cuestiones que realiza el hombre en su vida diaria.
  Muchas personas creen que la maquina soluciona todo y no están en lo correcto; esto se debe al desconocimiento generalizado que tienen acerca de la misma; no saben que una computadora debe programarse adecuadamente para que realice las cosas que tanto nos maravillan. No conocen los procesos que se deben seguir para lograr que un problema se solucione; no saben que es el ser humano el encargado de programarlo; señalando una serie de ordenes o instrucciones que indican como debe reaccionar la computadora ante las variantes que se le presentan; las maquinas solo reaccionan de acuerdo a las variantes que se le indiquen; si dichas variantes están fuera de sus parámetros no lo comprende y no responden.
  Por lo tanto las computadoras solo solucionan aquellos problemas para los que fueron programados.

    Presentamos algunos de los problemas que aún no han sido solucionados mediante la computación:

  • En primer lugar, se ubica el lento ritmo de adopción del IPv6(Protocolo de Internet versión 6), el código de 128-bit que controla las direcciones de Internet y que está por reemplazar al actual IPv4(Protocolo de Internet versión 4) de 32-bit. Sin ese cambio, el mundo se quedará sin direcciones de internet dentro de los próximos tres años. 
  • El almacenamiento o cómo manejar la seguridad cuando todo el recurso de información de una compañía puede bajarse a un dispositivo que perfectamente entra en el bolsillo de un empleado.   Seguirá habiendo pérdida o robo de información confidencial almacenada en un pendrive o laptop. Un tema igualmente importante es que las compañías deberían decidir qué información descartar para no ahogarse en datos. 
  • Los software de código abierto. Los sistemas operativos como Linux y Mac OSX no son gratuitos a menos que uno cuente con conocimientos técnicos para manejar el código crudo, pero parecen más seguros que, digamos, Windows, el blanco que mayormente eligen quienes escriben códigos maliciosos. 
  • Las patentes del software siguen siendo un gran inconveniente para el sector, ya que son comunes las dificultades para asegurarlas y protegerlas. Para resolver eso, tendría que haber un juicio de prueba en los tribunales. 
  • P versus NP. Es un problema matemático que consiste en decidir si la inclusión entre las clases de complejidad P y NP es estricta, en donde podemos decir que a la hora de realizar algunos cálculos ni los ordenadores más potentes pueden llevarlos a cabo.

miércoles, 6 de abril de 2016

Prototipos


PROTOTIPOS:
 Son una representación limitada de un producto, permite probarlo en situaciones reales o explorar su uso. Un prototipo puede ser cualquier cosa, desde un trozo de papel con sencillos dibujos a un complejo software, esto nos ayuda a comunicar, discutir y definir ideas entre los diseñadores y las partes responsables.


Nos encontramos con:

* Prototipos de baja fidelidad: utilizan materiales distintos al del producto final, son baratos, simples y fáciles de producir.


* Prototipo de alta fidelidad: son aquellos que se parecen al producto final y utiliza sus mismos materiales.

Ejemplo: 



CARACTERÍSTICAS DE LOS PROTOTIPOS

  • Evolucionan a través de un proceso iterativo(repetitivo)
  • Se crean con rapidez
  • Tienen un costo bajo de desarrollo
  • Es una aplicación que funciona
  • Tiene funcionalidad limitada
  • Proporciona mayor conocimiento al usuario ayudando a que aprenda a utilizar el sistema


ALGUNAS HERRAMIENTAS DE PROTOTIPADO

* IPLOTZ: Esta herramienta permite hacer maquetas navegables de sitios web y de aplicaciones. Lo puedes descargar en tu ordenador (Windows/ Mac) o bien puedes usar el servicio vía web.

* JUSTINMIND: Herramienta profesional para prototipado de sitios web, aplicaciones de software y aplicaciones móviles.

* VISIO: Sólo está disponible para equipos que trabajen con Windows. Puedes crear varios tipos de proyectos visuales como diagramas de flujo, diagramas de Venn, mapas y maquetas de sitios web (estándar y móvil), así como prototipos de aplicaciones de software.

* BALSAMIG: Con ella puedes hacer prototipos interactivos de webs. Puedes usar esta herramienta como un servicio web o bien descargarla en tu equipo (funciona con Windows, Mac y Linux).


MODELO DE CONSTRUCCIÓN DE PROTOTIPOS





SPIKES: Sirve para incluir en un sprint tareas que no implican desarrollar una historia de usuario y por tanto no aporta directamente un incremento al producto que se esta desarrollando.

martes, 5 de abril de 2016

Metodologia Tradicional vs Metodologia Agil

 METODOLOGIA TRADICIONAL:
  Esta metodología del desarrollo del software se caracteriza por:
  • basarse en un ciclo de vida de desarrollo del software en cascada ya que organiza los proyectos en etapas que se ejecutan secuencialmente.
    1. Especificación de Requisitos
    2. Análisis
    3. Diseño
    4. Desarrollo
    5. Pruebas
    6. Implantación
    7. Mantenimiento
     
  • ejecutar las etapas una sola vez, lo que se define en cada etapa es inamovible y hasta que no finaliza con éxito una etapa no se pasa a la siguiente. Ejemplo: hasta que no se aprueba el diseño del software no se inicia el desarrollo y construcción del mismo.
  • definir etapas claramente diferenciadas en las que participan distintos profesionales especializados. 


Entre las principales metodologías tradicionales tenemos los ya tan conocidos RUP y MSF entre otros, que centran su atención en llevar una documentación exhaustiva de todo el proyecto y centran su atención en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto.
 
 Desventajas:

*  Si durante una etapa del ciclo del software nos damos cuenta de que algo está mal, la vuelta a una etapa anterior no está bien definida en la metodología.

*  El usuario no ve el producto hasta el final, no puede ir validando hitos intermedios e ir verificando que lo que se ha construido es lo que necesita.

*  Si mi negocio es muy cambiante, pueden variar las necesidades desde el día que se toman los requisitos hasta el día de inicio la construcción.



METODOLOGIA AGIL:

  Esta metodología se caracteriza por:
  • se basa en un ciclo de vida de desarrollo del software iterativo e incremental. Se repiten las etapas de cada ciclo, se va añadiendo funcionalidad al producto y se comprime al máximo el tiempo de las iteraciones, son iteraciones cortas de semanas. Se hacen entregas parciales del producto para ir validando con el usuario que el producto cumple los requisitos.
  • se solapan las etapas. No siempre dentro de cada iteración tiene que haber etapas en cascada, por ejemplo, la etapa de test se fusiona con la etapa de desarrollo o la del diseño con la etapa de construcción.
  • se cambia la documentación por la interacción cara a cara con el usuario, hay equipos multidisciplinares sin separación de roles (todos pueden diseñar y programar) y se tiende a una gestión de proyecto como equipo auto organizado y colaborativo.
 Entre las principales metodologia agil encontramos:

SCRUM:es un proceso en el que se aplican de manera regular un conjunto de buenas practicas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto.

Como tambien realizan entregas parciales y regulares del producto final, está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales.

Programacion Extrema (XP) :esta centrada en potenciar las relaciones interpersonales, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios, se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico. 

 Desventajas:
  • Existe el riesgo de entrar en un ciclo de entrega de prototipos y nunca cerrar el proyecto.
  • La gestión es más rigurosa y con menos holgura para cometer errores.



 Conclusion:
  Ambas metodologías son buenas, sólo hay que identificar cuál es la que mejor se ajusta a cada proyecto, para utilizar metodología ágil se debe poseer experiencia trabajando con metodologías tradicionales, ya que la experiencia es la que predomina en los momentos cruciales del proyecto, además debe tener la capacidad de ser equipos auto-gestionados, altamente motivados y con gran innovación, se deberían aplicar en proyectos donde exista mucha incertidumbre donde el entorno es volátil, donde los requisitos no se conocen con exactitud, mientras que las metodologías tradicionales es esencial al inicio en un equipo de desarrollo de software, obligan al cliente a tomar las decisiones al inicio del proyecto.
 Ejemplo: 

 * Si el proyecto es de innovación, de investigación o desarrollo de un nuevo producto aún sin definir por completo y se prevén muchos cambios-Opta por Metodología ágil.

*En cambio si tienes muy claro lo que quieres y necesitas- Metodología tradicional.

miércoles, 16 de marzo de 2016

ACOPLAMIENTO Y COHESION

ACOPLAMIENTO: Nos referimos al grado de dependencia que tienen dos unidades de software(modulos). Al programar o diseñar se debe tener un acoplamiento lo mas bajo posible entre dos unidades de software cualesquiera, logrando que los modulos funcionen sin depender demasiado unos de otros; siendo imposible lograr un desacoplamiento (unidades independientes) total entre las unidades.


COHESION: Una clase o módulo tiene alta cohesión si todas las responsabilidades, datos y métodos que incluye están estrechamente relacionados.


En conclusion, mantener el acoplamiento lo mas bajo posible y la cohesion lo mas alta posible suele ser el objetivo de todo arquitecto, diseñador o programador, ya que garantiza la modularidad, facilitando la reutilizacion del sotfware y gran parte de las tareas del desarrollo del software.

miércoles, 9 de marzo de 2016

Sistema Socio-Tecnico

SISTEMA SOCIO-TECNICO:  usado para designar la interaccion entre obrero-maquina en ambientes de trabajo, donde la tecnologia complementa al hombre y no lo reemplaza dando una nueva cultura a la organizacion, fomentando la buena relacion y cooperacion entre compañeros, incrementando su rendimiento.

Es decir, que este sistema tiene como objetivo  mejorar la relacion entre la tecnologia y las personas involucradas en el proyecto.