domingo, 28 de mayo de 2017

¿QUE ES "RAID"?

En la actualidad, el uso de un disco duro para guardar datos e información es casi indispensable, un disco duro proporciona una manera sencilla de tener un sistema operativo instalado, guardar una configuración y poder almacenar datos en él, a veces incluso datos críticos. Debido a esto surgieron varias alternativas para mejorar la seguridad de dichos datos y a su vez, garantizar la preservación de los mismos.
A nivel empresarial, una de las alternativas más utilizadas por los gigantes de internet y los sistemas informáticos es la configuración RAID para utilizar estos discos. El término RAID es un acrónimo del inglés “Redundant Array of Independent Disks”. Significa matriz redundante de discos independientes. RAID es un método de combinación de varios discos duros para formar una única unidad lógica en la que se almacenan los datos de forma redundante. Ofrece mayor tolerancia a fallos y más altos niveles de rendimiento que un sólo disco duro o un grupo de discos duros independientes.
Una matriz consta de dos o más discos duros que ante el sistema principal funcionan como un único dispositivo. Un RAID, para el sistema operativo, aparenta ser un sólo disco duro lógico (LUN). Los datos se desglosan en fragmentos que se escriben en varias unidades de forma simultánea. En este método, la información se reparte entre varios discos, usando técnicas como el entrelazado de bloques (RAID nivel 0) o la duplicación de discos (RAID nivel 1) para proporcionar redundancia, reducir el tiempo de acceso, y/o obtener mayor ancho de banda para leer y/o escribir, así como la posibilidad de recuperar un sistema tras la avería de uno de los discos.
Utilizando RAID, se consigue optimizar servidores y con esto, sistemas enteros, debido a que permite que el servidor continúe su funcionamiento habitual aun cuando alguno de los discos duros pertenecientes a la matriz fallase. Por otro lado, al fragmentar los datos y tenerlos distribuidos en la matriz, se garantiza la seguridad de los mismos así como su preservación. Por último, la implementación e RAID incrementa el rendimiento de los servidores.

VENTAJAS
DESVENTAJAS
Mejora el rendimiento/velocidad
Dependientes de elementos críticos por duplicado: fuentes de alimentación y ventiladores redundantes y Hot Swap
Mayor Fiabilidad
Aumenta la complejidad
Alta Disponibilidad
No asegura que los datos no se puedan corromper
Incremento de Seguridad
No permite copias de seguridad (se requeriría una configuración en espejo para ello)

La configuración RAID se presenta en varios niveles. La elección de los diferentes niveles de RAID va a depender de las necesidades del usuario en lo que respecta a factores como seguridad, velocidad, capacidad, coste, etc. Cada nivel de RAID ofrece una combinación específica de tolerancia a fallos (redundancia), rendimiento y coste, diseñadas para satisfacer las diferentes necesidades de almacenamiento.

NIVEL
DESCRIPCION
RAID 0: Disk Striping “La más alta transferencia, pero sin tolerancia a fallos”.
También conocido como “separación o fraccionamiento/ Striping”. Los datos se desglosan en pequeños segmentos y se distribuyen entre varias unidades. Este nivel de “array” o matriz no ofrece tolerancia al fallo. Al no existir redundancia, RAID 0 no ofrece ninguna protección de los datos.
RAID 1: Mirroring “Redundancia. Más rápido que un disco y más seguro”
También llamado “Mirroring” o “Duplicación” (Creación de discos en espejo). Se basa en la utilización de discos adicionales sobre los que se realiza una copia en todo momento de los datos que se están modificando. RAID 1 ofrece una excelente disponibilidad de los datos mediante la redundancia total de los mismos.
RAID 0+1/ RAID 0/1 o RAID 10: “Ambos mundos”
Combinación de los arrays anteriores que proporciona velocidad y tolerancia al fallo simultáneamente. El nivel de RAID 0+1 fracciona los datos para mejorar el rendimiento, pero también utiliza un conjunto de discos duplicados para conseguir redundancia de datos.
RAID 2: “Acceso paralelo con discos especializados. Redundancia a través del código Hamming”
El RAID nivel 2 adapta la técnica comúnmente usada para detectar y corregir errores en memorias de estado sólido. En un RAID de nivel 2, el código ECC (Error Correction Code) se intercala a través de varios discos a nivel de bit. El método empleado es el Hamming.
RAID 3: “Acceso síncrono con un disco dedicado a paridad”
Dedica un único disco al almacenamiento de información de paridad. La información de ECC (Error Checking and Correction) se usa para detectar errores. La recuperación de datos se consigue calculando el O exclusivo (XOR) de la información registrada en los otros discos.
RAID 4: “Acceso Independiente con un disco dedicado a paridad.”
Basa su tolerancia al fallo en la utilización de un disco dedicado a guardar la información de paridad calculada a partir de los datos guardados en los otros discos. En caso de avería de cualquiera de las unidades de disco, la información se puede reconstruir en tiempo real
RAID 5: “Acceso independiente con paridad distribuida.”
Este array ofrece tolerancia al fallo, pero además, optimiza la capacidad del sistema permitiendo una utilización de hasta el 80% de la capacidad del conjunto de discos. Esto lo consigue mediante el cálculo de información de paridad y su almacenamiento alternativo por bloques.
RAID 6: “Acceso independiente con doble paridad”
Similar al RAID 5, pero incluye un segundo esquema de paridad distribuido por los distintos discos y por tanto ofrece tolerancia extremadamente alta a los fallos y a las caídas de disco, ofreciendo dos niveles de redundancia.

En conclusión, una configuración de discos duros en matriz RAID, busca precisamente construir un arreglo de discos duros con el fin de optimizar el rendimiento del servidor, pero sobre todo, se enfoca a como los datos son distribuidos, e esta manera y adecuando un nivel de RAID a nuestro sistema podemos conseguir desde velocidad y tolerancia a daños, hasta la detección de errores. Como tal, un RAID pretende distribuir los datos de un sistema a través de todos los discos que conformen el arreglo, en ocasiones fragmentando a los mismos, para conseguir una mejora significativa en la seguridad e integridad de estos, esto con el objetivo de que un servidor y sistema informático puedan seguir con su funcionamiento habitual aun si algún disco duro del arreglo falla. Como tal es una alternativa viable y comúnmente utilizada en las empresas.

REFERENCIAS:



domingo, 14 de mayo de 2017

¿Qué es un "Task Board"?


Una "Task Board" en esencia es una pizarra en donde se colocan actividades que alguien debe realizar, estas tareas pueden ser realizadas por una persona, equipo u organización, comúnmente el Task Board es utilizado por los equipos de desarrollo que utilizar SCRUM como metodología. 

Como tal, la implementación de un Task Board busca mejorar la administración de tareas, por esto mismo puede mostrar tareas por hacer, tareas en curso y tareas finalizadas. Independientemente de la complejidad de las tareas, un Task Board puede tomar papeles relevantes dentro de la organización de una persona o equipo, pues permite una visión amplia de la carga de trabajo, esto permite clasificar las tareas por prioridad.

Aunque tienen grandes usos personales, los Task Board están en el centro de la mayoría de las organizaciones, industrias o negocios que se basan en las personas que trabajan en conjunto para lograr un objetivo común. Son útiles para cualquier situación, ya sea desarrollo de software o logística, fabricación o ventas, etc.

Algunas de las ventajas de la implementación de un Task Board son:

·         Los flujos de trabajo a la vista
·         Asignación tareas
·         Compartir información
·         Visualizar los cuellos de botella
·         Manejo de dependencias
·         Predecir y evitar los problemas de producción
·         Aumentar la eficacia
·         Mejorar la producción
·         Cumplir con los plazos
·         Reduce el estrés

Si vemos el uso de un Task Board desde el enfoque de SCRUM, el Task Board representaría la lista de tareas a realizar en esa iteración y adopta el nombre de “SCRUM Task Board”.





Ejemplos:

Task Board Convencional

Task boards are a type of visual management tool - LeanKit


SCRUM Task Board

scrum-taskboard-dimensiones


Podemos concluir entonces, que la intención de la implementación de un Task Board es ayudar en la gestión de tareas, de manera que visualizar a las mismas resulta más cómodo y en muchas ocasiones tiene el efecto de mejorar la distribución y presentación de la información, aumentar la productividad y puntualidad de la realización de las actividades. 

El punto más importante en mi consideración es que para un equipo acaba siendo  muy sencillo y conveniente ver las actividades a realizar de una manera clara y accesible en todo momento. En realidad, la implementación de un Task Board no tiene una desventaja contundente, como sí lo son sus ventajas, es evidente que resultara más productiva y eficaz  una actividad que es realizada con una organización adecuada, y utilizar un Task Board como herramienta para ello es en todo sentido provechoso. Se puede omitir el uso de un Task Board, pero implementarlo solo traerá beneficios en las actividades y procesos.

Fuentes:




domingo, 2 de abril de 2017

CONFIGURACIÓN DEL SOFTWARE: CONCEPTO Y ELEMENTOS


Concepto (Hista Internacional S.A., 2007):

Gestión de Configuración es el proceso de identificar y definir los elementos en el sistema, controlando el cambio de estos elementos a lo largo de su ciclo de vida, registrando y reportando el estado de los elementos y las solicitudes de cambio, y verificando que los elementos estén completos y que sean los correctos.

El propósito de la Gestión de Configuración del Software es establecer y mantener la integridad de los productos de software a través del ciclo de vida del proceso de software.

La Gestión de Configuración del Software implica la identificación de la Configuración del software en puntos dados en el tiempo, el control sistemático de los cambios en la Configuración y el mantenimiento de la integridad y trazabilidad de la Configuración a través del ciclo de vida del software. Los productos incluidos son:

·         Software distribuido al cliente.
·         Documentos de requerimientos del software.
·         Código.
·         Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos de la configuración del software basados en METRICA v.3 (Públicas, 2001):

·         Ejecutables
·         Código Fuente
·         Modelos de datos
·         Modelos de procesos
·         Especificaciones de requisitos
·         Pruebas

Y para cada uno de estos elementos se almacenará al menos:

·         Nombre
·         Versión
·         Estado
·         Localización

Referencias

Hista Internacional S.A. (27 de Febrero de 2007). Obtenido de http://www.histaintl.com/soluciones/configuracion/configuracion.php
Públicas, M. d. (2001). MÉTRICA v.3. España.


ENSAYO: La Reingeniería de Software

REINGENIERIA DE SOFTWARE
La reingeniería de software es un término, una práctica constantemente utilizada en el campo de los sistemas de información. Esto se debe a toda una gama de factores, que van desde las necesidades de una empresa, errores humanos en los sistemas, el avance tecnológico, sistemas heredados y sistemas inservibles. En todos los casos, se utilizara a la reingeniería de software para poder recuperar información, fracciones del sistema o, incluso el sistema entero.


Primeramente definiremos a la reingeniería de software como:

“La reingeniería del software abarca una serie de actividades entre las que se incluye el análisis de inventario, la reestructuración de documentos, la ingeniería inversa, la reestructuración de programas y datos, y la ingeniería directa. El objetivo de esas actividades consiste en crear versiones de los programas existentes que muestren una mayor calidad, y una mejor mantenibilidad.” (Pressman, 2010)

Basándonos en la definición de Roger Pressman, la reingeniería de software nos permitirá, entonces, desarrollar desde nuevas versiones de un sistema ya existente a través de los mantenimientos perfectivos y correctivos, hasta desarrollar nuevos sistemas cuya base sea un sistema ya elaborado.

Sin embargo, antes de explicar el proceso de la reingeniería de software, nos preguntaremos, ¿Por qué hacer reingeniería? Como se mencionó previamente, hay todo un rango de posibilidades por las cuales una organización o un individuo quisieran realizar reingeniería de un sistema. Por ejemplo, si una compañía cuenta con un sistema que fue programado hace tanto tiempo que su tecnología se torna obsoleta, haciendo que la compañía este en una desventaja debido a su sistema, esta querría obtener un sistema que se parezca al anterior, pero mejorara en todos aspectos y que además conservara la información considerada valiosa para la compañía, entonces, recurrirían a la reingeniería.

Actividades de la reingeniería:

1.       Análisis de artefactos:

Durante esta actividad se deberán recolectar todos los documentos y artefactos bajo los cuales de desarrollo el sistema en sus inicios, así como todos los que registran sus posteriores modificaciones y mantenimientos. De esta manera tendremos una “descripción detallada del sistema, desde su funcionamiento como de su interfaz” (Bianchiotti, 2014) .

2.       Reestructuración de Documentos:

Una vez analizados, se recuperaran los documentos que sean posibles, basándonos en el código del sistema y su interpretación a “primera vista”, de cualquier manera esto se retomara en la siguiente actividad. Se pueden utilizar herramientas CASE.

3.       Ingeniería Inversa:

Es el proceso de análisis de los programas (fuentes y ejecutables) con el fin de crear una representación de un nivel de abstracción más elevado que el código fuente. Se extraerá de los códigos existentes información del diseño arquitectónico y de proceso, e información de los datos. Una vez se tenga toda la aplicación al nivel de abstracción necesario, que es aquel en el que se tienen todos los recursos para poder rehacer dicha aplicación, se toma la decisión de mantener el sistema actual, pero con mantenimientos o ligeros cambios, o, hacer un sistema nuevo.

4.       Restructuración de Código:

Actividades destinadas a la normalización del código fuente, así como la verificación del mismo respecto a los documentos originales y los resultados provenientes de la ingeniería inversa.

Restructuración de Datos:

La reestructuración de datos toma como insumos la documentación y registros obtenidos en la etapa anterior: entidades identificadas, diccionarios de almacenamientos, DER, etc. Estos esquemas que denominamos arquitectura de datos actual, aunque no cumplan todos las condiciones de una arquitectura, se analiza minuciosamente y en profundidad. A continuación se define el nuevo modelo de datos necesario, que implica la identificación de los objetos de datos y atributos y, a continuación, se revisan las estructuras de datos a efectos de mejorar su calidad. (Bianchiotti, 2014)

5.       Ingeniería Directa:

Se realiza el desarrollo del nuevo sistema basándonos en todos los resultados obtenidos en las fases anteriores. De esta manera, se toman decisiones acerca del nuevo sistema y se modifica su documentación, por ejemplo, agregando requerimientos a esta. Una vez recopiladas todas las nuevas especificaciones se desarrolla, prueba e implementa el nuevo sistema.


Para concluir, la reingeniería de software es aquel proceso donde tomaremos un sistema existente, conocemos su estructuración y funcionalidad con el fin de tomar la decisión de mantener el sistema haciendo uso de mantenimientos correctivos y perfectivos, o, si preferimos y es conveniente desarrollar un nuevo sistema, por supuesto, basados en el antiguo. De esta manera, conseguiremos que el sistema antiguo sea actualizado y se vea enriquecido  en aspectos sustanciales, mejorando su productividad, o, de lo contrario, obtendremos un sistema completamente nuevo que será mejor en todas sus características respecto al sistema antiguo.

Referencias

Bianchiotti, F. (2014). Guía para la Reingeniería de Sistemas Legados: Una Experiencia Practica y Real. Revista Lationo Americana de Ingeniera de Software, 99-106.

Pressman, R. (2010). Ingeniera del Software. MCGRAW-HILL.

domingo, 19 de marzo de 2017

METODOS AGILES: XP EN PRACTICA


Utilizando XP se planteo el escenario del acceso al metro, utilizando una tarjeta y con 3 diferentes tarifas.

Las historias de usuario, casos de pruebas de aceptación, tarjetas de ingeniería y tarjetas CRC están disponibles en el siguiente enlace:

METODOLOGIA XP EN PRACTICA: EJEMPLO DEL METRO

METODOS AGILES: VENTA DE BOLETOS

Historia de Usuario
4
VENTA DE BOLETOS
4.   VENTA DE BOLETOS
Usuario: Pasajero del metro
Iteración Asignada: 1
Prioridad en Negocio:
(ALTA / Media / Baja)

Puntos Estimados:
5
Riesgo en Desarrollo:
(Alto / MEDIO / Bajo)
Puntos Reales:
.
Descripción:
Se deben de vender boletos para ingresar al metro. Debido a que existen 3 zonas, deben de haber 3 tipos de boletos para  viajar a estas zonas, con 3 tarifas diferentes.
Observaciones:
Cada boleto solo puede usarse una vez.  












Caso de Prueba de Aceptación
Código:

4.- VENTA DE BOLETOS
Nombre: Comprobación para la venta de boletos
Descripción: Se planea vender tres tipos de boletos, así mismo, comprobar que estos correspondan a la tarifa y zona que el usuario desea acceder
Condiciones de Ejecución:
El usuario debe contar con un boleto valido y en buen estado
El sistema tiene que estar conectado a internet.
El torniquete y/o lector para boletos debe estar en funcionamiento
Entrada / Pasos de ejecución:
Primero se lee el tipo de boleto y se corrobora que éste corresponda a la zona y tarifa de abordaje.
Posteriormente se permite o niega el acceso
Resultado Esperado:
Se espera que el torniquete y/o lector lea correctamente el tipo boleto y permita el acceso
Evaluación de la Prueba:
El sistema no lee el boleto
El sistema no reconoce el tipo de boleto
El sistema rechaza cualquier boleto
El sistema no permite la entrada

El sistema lee el boleto
El sistema reconoce cualquier tipo de boleto
El sistema acepta cualquier boleto
El sistema permite el acceso





Tarea de Ingeniería
Número Tarea:
4
4.   Venta de Boletos
Nombre Tarea: Desarrollo del módulo correspondiente para la venta de boletos
Tipo de Tarea:
DESARROLLO / Corrección / Mejora / Otra (especificar)

Puntos Estimados:
5
Fecha de Inicio:
18/03/2017
Fecha de culminación.
18/03/2017
Programador Responsable:
Isaac Martínez Sánchez
Jeobany Ramírez Escobar
Descripción:
Se debe programar el módulo para la venta de boletos; esta actividad se podrá realizar en taquilla. Es necesario identificar el tipo de boleto, ya que de esto dependerá su costo.
Este módulo requiere realizar tanto la venta y cobro al usuario.












Boleto
Venta
Identificar zona de entrada
Identificar zona de salida
Identificar tarifa

Torniquete/Lector

ACTIVIDAD REINGENIERIA DE SISTEMAS 6IM6


EQUIPO:

  • RAMIREZ ESCOBAR JEOBANY
  • MARTINEZ SANCHEZ ISAAC