RAID

RAID (del inglés Redundant Array of Inexpensive Disks o, más común a día de hoy, Redundant Array of Independent Disks), traducido como «conjunto redundante de discos Independientes»

Introducción:

RAID hace referencia a un sistema de almacenamiento de datos en tiempo corto que utiliza múltiples unidades de almacenamiento de datos (discos duros o SSD) entre los que se distribuyen o replican los datos. Dependiendo de su configuración (a la que suele llamarse «nivel»), los beneficios de un RAID respecto a un único disco son uno o varios de los siguientes: mayor integridad, mayor tolerancia a fallos, mayor throughput (rendimiento) y mayor capacidad. En sus implementaciones originales, su ventaja clave era la habilidad de combinar varios dispositivos de bajo coste y tecnología más antigua en un conjunto que ofrecía mayor capacidad, fiabilidad, velocidad o una combinación de éstas que un solo dispositivo de última generación y coste más alto.

Desarrollo:

La idea de RAID se basa en la combinación de múltiples unidades de disco pequeñas y poco costosas que se agrupan en una formación para lograr objetivos de mejor rendimiento o redundancia que no se pueden lograr con una única unidad grande y costosa. Esta formación de discos el ordenador las considerará como si fueran una única de disco lógica.

RAID es el método que se usa para expandir información en diversos discos utilizando técnicas como el vaciado del disco (RAID Nivel 0), la creación de réplicas del disco (RAID nivel 1) y el vaciado del disco con paridad (RAID Nivel 5) para obtener redundancia, menos latencia y/o aumentar el ancho de banda para leer o escribir en discos y maximizar así la posibilidad de recuperar información cuando el disco duro no funciona.

Con diversos niveles de RAID, varios discos duros físicos se utilizan para dividir y/o almacenar datos. El método estándar de organización de datos también se le conoce como nivel de RAID.

 ° RAID 0: este nivel de RAID es conocido también como configuración por bandas. Aquí se almacenan los datos a través de varios discos duros. Se mejora el rendimiento de búsqueda mientras se accede a los datos, sin embargo, no ofrece tolerancia a fallas. Cualquier instancia de daño de disco duro tendrá como resultado la pérdida de datos.

 ° RAID 1: este nivel de RAID también es conocido como replicación. Aquí se escriben los datos idénticamente en dos discos duros. Al menos dos discos duros son necesarios para constituir una matriz RAID 1. Proporciona tolerancia máxima a las fallas cuando la computadora esté operativa, siempre que uno de los discos duros esté operativo.

RAID está basado en el concepto de que los datos tienen que ditribuirse en cada conjunto de discos de manera consistente. Para ello, los datos se rompen en pedazos o grupos de datos con un tamaño que varía normalmente entre 32K y 64K aunque se pueden usar otros tamaños. Cada grupo de datos se escribe en el disco duro según el nivel de RAID. Cuando se leen los datos, se invierte el proceso de manera que parece que existan muchas unidades de disco en una sola.

Conclusión:

Los arreglos de RAID permiten más fiabilidad y rendimiento que los de un servidor de almacenamiento. Mientras que un RAID 1 representa un buen punto de partida para aplicaciones de correo electrónico y servidores web, un RAID 10 es más indicado para aplicaciones de base de datos. Los RAID 5 y 50 pueden ser utilizados en aparatos de copia de seguridad que requieren gran tolerancia a las fallas y alta capacidad.

Bibliografía:

Desconocido. (Desconocido). RAID. 26/05/17, de WIKIPEDIA Sitio web: https://es.wikipedia.org/wiki/RAID

Desconocido. (Desconocido). Red Hat Enterprise Linux 3: Manual de administración del sistema. 26/05/17, de mit Sitio web: http://web.mit.edu/rhel-doc/3/rhel-sag-es-3/ch-raid-intro.html

https://hipertextual.com/archivo/autor/jjvelasco/. (8 de Enero de 2014). CIENCIA CINE Y TV MOBILE SOFTWARE STARTUPS MOTOR FUTURO TECNOLOGÍA ENTREVISTAS ESPECIALES  ¿En qué consiste la configuración de discos duros en RAID?. 26/05/17, de hipertextual Sitio web: https://hipertextual.com/archivo/2014/01/que-es-raid-discos-duros/

DELL. (Desconocido). RAID: matriz redundante de discos independientes. 26/05/17, de DELL Sitio web: http://www.dell.com/support/article/us/en/04/SLN179295/raid--matriz-redundante-de-discos-independientes?lang=ES

Help Desk

Introducción:

Mesa de Ayuda (en inglés: Help Desk, a veces traducido como 'Escritorio de ayuda'), o Mesa de Servicio (Service Desk), o simplemente CAU Centro de Atención al Usuario es un conjunto de recursos tecnológicos y humanos, para prestar servicios con la posibilidad de gestionar y solucionar todas las posibles incidencias de manera integral, junto con la atención de requerimientos relacionados a las Tecnologías de la Información y la Comunicación (TIC).

El personal o recurso humano encargado de Mesa de Ayuda (MDA) debe saber proporcionar respuestas y soluciones a los usuarios finales, clientes o beneficiarios (destinatarios del servicio), y también puede otorgar asesoramiento en relación con una organización o institución, productos y servicios. Generalmente, el propósito de MDA es solucionar problemas o para orientar acerca de computadoras, equipos electrónicos o software.

Las organizaciones suelen proporcionar soporte de MDA a sus usuarios a través de varios canales, como números de teléfono gratuitos, sitios web, mensajería instantánea o correo electrónico. También, pueden brindar asistencia con miras a los usuarios o empleados, dentro de la organización. Por lo tanto, los usuarios finales pueden ser internos o ajenos a la organización donde se encuentre MDA.

Desarrollo. 

Una Mesa de Ayuda le permite al departamento de IT responder incidentes inesperados dentro de la infraestructura IT o los servicios que provee. Una Mesa de Ayuda reacciona ante los incidentes y es usada para manejar problemas cuando los mismos surgen, permitiendo llevar un registro, control y con suerte, finalmente llegar a una resolución. La mesa de ayuda se va a enfocar en facilitar la comunicación entre el equipo de soporte y los usuarios para ayudar a resolver los problemas, y su propósito es mantener activa la infraestructura y los servicios en el día a día.

 Dependiendo de la estructura de la empresa trabajarán de dos modos distintos:

Atención a distancia: reciben llamadas, faxes o e-mails de los clientes con dificultades y los conducen a buen puerto.

Atención personal: se desplazan directamente hasta el usuario que ha avisado de la incidencia y la solucionan allí mismo.

Según la actividad de la empresa sus funciones se centrarán en:

Soporte en programas informáticos: muchas empresas utilizan paquetes ofimáticos estandarizados. ¿Algún problema con estas utilidades? Ellos lo resuelven.

Implantación y mantenimiento de software: incorporar nuevas versiones o programas a los equipos y comprobar que funcionan correctamente.

Mantenimiento de bases de datos de clientes o correo: cuando un empleado se incorpora o deja una empresa se le asigna una clave de usuario, un password, y se establecen las áreas a las que tiene acceso.

Servidores y redes: cuando falla el cerebro de todo el sistema informático, los help desk dan apoyo a los expertos en redes.

Conclusión:

A través del desarrollo del presente Trabajo, se a podido visualizar la importancia de la implementación de un Help-Desk en una organización. El sistema de Help Desk incrementa la productividad y aumenta la satisfacción de los usuarios internos y externos. Muchas empresas optan por delegar este servicio a terceros.

Para terminar, se puede decir que el beneficio que entregan estas herramientas es alto, permitiendo a la organización generar un registro y seguimiento de problemas, definir la responsabilidad y funciones, aumenta la productividad y reducción de costos.

Bibliografía:

laboris. (2015). profesion_help-desk. 20/05/2017, de ipn Sitio web: http://www.laboris.net/static/ca_profesion_help-desk.aspx

pcexperto. (2009). help-desk. 20/05/2017, de ipn Sitio web: http://pcexpertos.com/2009/08/cual-es-la-funcion-principal-de-help-desk.html

diego-edwin-amaro. (2013). help-desk-en-general. 20/05/2017, de ipn Sitio web: http://diego-edwin-amaro.webnode.es/news/funciones-de-los-miembros-del-equipo-help-desk-en-general-/

Desconocido. (2016). helpdesk. 20/05/2017, de ipn Sitio web: http://www.foro-helpdesk.com/?p=462

InvBlog. (2015). help-desk-service. 20/05/2017, de ipn Sitio web: http://blog.invgate.com/es/diferencia-help-desk-service-desk

Lineas Base

Líneas base

Una línea base es un concepto de gestión de la configuración que lleva a controlar los cambios sin impedir seriamente los cambios justificados. El Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) 610.12/1990 define una línea base como:

Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios.

La IEEE define una línea base como:
Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios.

Herramientas de configuración del Software

Introducción SCM

La gestión de configuración del software es un conjunto de actividades diseñadas para identificar y definir los elementos en el sistema que probablemente cambien, controlando el cambio de estos elementos a lo largo de su ciclo de vida, siendo uno de los procesos clave para toda organización dedicada a la ingeniería del software.

En la actualidad existe una gran variedad de herramientas que apoyan a este proceso cada una de ella con características propias y que se adaptan a diferentes metodologías de desarrollo.

Control: Se dispone de medios para realizar materialmente una tarea de manera segura.
Gestión: Hay criterios establecidos que hay que seguir en la realización de una tarea.

Desarrollo:

Elementos:

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

Por ejemplo:

Uso de un software de administración de versiones como IBM Rational Team Concert, CVS, Subversion, SourceSafe, ClearCase, Darcs, Plastic SCM.
Introducción de una herramienta para la documentación comunitaria con una administración de cambios, acceso interactivo y foro o alguna plataforma para la comunicación.
Determinar un entorno para el build automático.

Algunos ejemplos de sistemas de gestión de la configuración:

°AccuRev
°Rational ClearCase
°Fossil
°Git
°Harvest (CA)
°Perforce
°Plastic SCM
°Rational Synergy (Telelogic Synergy/CM: Telelogic Synergy (ehem. Synergy/CM, ehem. °CM/Synergy, ehem. CCM)
°Sablime
°SET-LIBER
°Smart Bear
°SpectrumSCM
°Surround SCM
°Subversion
°Trac
°Visual Source Safe (Microsoft)
°Microsoft Team Foundation Server 2010
°Microsoft Visual Studio 2010 ALM

Conclusión:

Con la gestión de Configuración podemos observar 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. Pienso que 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. 

Bibliografia:

www.map.es Ministerio de Administraciones Públicas.
www.csi.map.es Consejo Superior de Informática (CSI).
MÉTRICA v3 v3 en el CSI.
Gestión de la Configuración en MÉTRICA v3.

Reingeniería de Software

Introducción:

Reingeniería de Software es una forma de modernización para mejorar las capacidades y/o mantenibilidad de los sistemas de información heredados mediante la aplicación de tecnologías y practicas modernas. La Reingeniería de Software ofrece una disciplina de preparación para migrar un sistema de información heredado hacia un sistema evolucionable. El proceso aplica principios de ingeniería para un sistema existente para encontrar nuevos requerimientos.

Desarrollo:

Los objetivos de la reingeniería son:

Proporcionar asistencia automatizada para el mantenimiento.
Reducir los errores y costos del mantenimiento.
Incrementar la intercambiabilidad del grupo de mantenimiento.
Hacer sistemas fáciles de entender, cambiar y probar.
Habilitar la conversión y migración de sistemas.
Reforzar el apego a estándares.
Mejorar la respuesta a peticiones de mantenimiento.
Mejorar el estado de ánimo del grupo de mantenimiento.
Proteger y extender la vida del sistema.
Usar CASE para apoyar sistemas existentes
Re-usar componentes de sistema existentes.
La reingeniería puede ayudar a entender sistemas existentes y descubrir los componentes de software que son comunes en todo el sistema. Estos componentes comunes pueden ser re-usados en el desarrollo (o redesarrollo) de sistemas y así reducir el tiempo y riesgos del desarrollo de sistemas.

REINGENIERÍA DE PROCESOS

Una definición de Reingeniería basada en [Mang 95] y [Hamm 94] sería: es la actividad en el que los procesos son objeto de una revisión fundamental y rediseño radical, para lograr así la optimización de los flujos del trabajo y la productividad de una organización.
Para poder analizar esta definición es necesario también definir lo que es un proceso. "Definimos un proceso de negocios como un conjunto de actividades que recibe uno o más insumos y crea un producto de valor para el cliente." [Hamm 94]
Se dice que durante una reingeniería, los procesos son objeto de una revisión fundamental ya que es necesario realizarse las preguntas básicas sobre su compañía y como funciona sin dar nada por sentado. La reingeniería determina primero qué debe hacer una compañía para después determinar cómo debe hacerlo. Se olvida por completo de lo que es y se concentra en lo que debe ser.

A REINGENIERÍA VS LOS PROGRAMAS DE MEJORA INCREMENTAL

Como ya hemos visto, la reingeniería consiste en un cambio radical y si hay algo que las empresas quieren evitar es el cambio radical. La mejora continua incremental – en contraposición a la Reingeniería de Procesos – está más de acuerdo con la manera como las organizaciones se entienden naturalmente con el cambio. La mejora continua hace hincapié en cambios pequeños, incrementales; el objeto es mejorar lo que una organización ya está haciendo.

Conclusión:

El software siempre ha sido y será lo que le puede dar vida y plusvalía a la computación; sin el software, las computadoras serían inservibles y no podrían ser utilizadas para ningún beneficio. Es el software el que realiza los procesos necesarios a los datos introducidos para así obtener nuevos datos con los que se pueden tomar decisiones, en muchos de los casos, decisiones críticas. 

La reingeniería no es una actividad que se lleva a cabo de la noche a la mañana, además implica una gran inversión de esfuerzo, tiempo y recursos. Es por ello que es necesario planear de una manera muy cuidadosa todo el proceso. Este proceso se inicia con la justificación del proyecto de reingeniería, en el cual se tiene que analizar cada sistema candidato para así obtener una lista de aplicaciones ordenada según sus prioridades. Una vez obtenida la lista, se hace la estimación de costes que serán necesarios para modificar todos los componentes. Por último se comparan los costes con los beneficios esperados.

Bibliografía:

         

Author	Monografias.com Nicolás Johnatan Flores Carmona
Article title:	Reconstrucción de la arquitectura: Una actividad de la reingeniería de software - Monografias.com
Website title:	Monografias.com
URL:	http://www.monografias.com/trabajos17/reingenieria-software/reingenieria-software.shtml#conclu

Author	researchgate.net  1st Juan Carlos Álvarez García &   2nd Montserrat Mateos-Sánchez 6.9 · Universidad Pontificia de Salamanca
Article title:	Metodología de reingeniería del software para la remodelación de aplicaciones científicas heredadas
Website title:	researchgate.net
URL:	https://www.researchgate.net/publication/39698262_Metodologia_de_reingenieria_del_software_para_la_remodelacion_de_aplicaciones_cientificas_heredadas

Author	Monografias.com Nicolás Johnatan Flores Carmona
Article title:	Reconstrucción de la arquitectura: Una actividad de la reingeniería de software - Monografias.com
Website title:	Monografias.com
URL:	http://www.monografias.com/trabajos17/reingenieria-software/reingenieria-software.shtml#conclu

Historia de usuario

Historia de Usuario
Número: 10	Nombre: Venta de tarjeta del Suburbano
Modificación (o extensión) de Historia de Usuario (No. y Nombre): En caso de haber una modificación o extensión de la historia deberá quedar registrado en este espacio.
Usuario: Personas que deseen abordar el metro		Iteración Asignada: 1
Prioridad en Negocio: (Alta / Media / Baja)		Puntos Estimados: 4 hrs.
Riesgo en Desarrollo: (Alto / Medio / Bajo)		Puntos Reales: 2 hrs
Descripción: El usuario podrá comprar la tarjeta en cada uno de los puntos de venta disponibles en las estaciones y también introducir saldo en ella. El importe que pagará el usuario será igual al costo de la tarjeta más el costo de la recarga.
Observaciones: Deberá haber tarjetas disponibles. Deberá haber una tabla de precios. Deberá aceptar monedas de 1, 5 y 10 pesos y billetes de 20, 50 y 100 pesos. Deberá dar el cambio exacto.

Caso de Prueba de Aceptación
Código:	Historia de Usuario (Nro. y Nombre): Venta de tarjeta del Suburbano - 10
Nombre: Caso de prueba “Validación de venta exitosa”
Descripción: Que el sistema pueda realizar una venta de tarjeta sin inconvenientes.
Condiciones de Ejecución: El usuario debe introducir el monto necesario para adquirir la tarjeta. El usuario debe adquirir la tarjeta en algún punto de venta.
Entrada / Pasos de ejecución: 1.    El usuario introduce el monto para comprar la tarjeta. 2.    El sistema pregunta el saldo que desea recargar (máximo de $100). 3.    El usuario confirma la recarga. 4.    El sistema entrega el cambio exacto junto con la tarjeta.
Resultado Esperado: El sistema entregará el cambio exacto. El sistema entregará la tarjeta.
Evaluación de la Prueba: La prueba fue satisfactoria.

XP vs SCRUM

XP vs SCRUM

Introdución:
Extreme Programming (XP) y Scrum están definitivamente muy ligados entre sí. Es un hecho que si perteneces a un equipo que lleva una de estas dos metodologías vas a tener un tiempo difícil encontrando diferencias entre una y otra. Las diferencias son mínimas, pero muy importantes. Personalmente creo que existen 4 principales diferencias entre Scrum y XP.

Desarrollo:
Los Equipos de Scrum normalmente trabajan en iteraciones (llamadas sprints) con una duración de 2 semanas a un mes. Los Equipos de XP normalmente trabajan con iteraciones muy cortas (1 o 2 semanas).
Los equipos de Scrum no permiten cambios en sus sprints. Una vez que el sprint planning meeting ha concluido y se llegó a una acuerdo para elegir los product backlog items, estos no pueden recibir cambios, por lo menos hasta el final del sprint. Los equipos XP aceptan los cambios con más facilidad en sus iteraciones. Siempre y cuando el equipo no haya empezado ya a trabajar en un requerimiento en particular , un nuevo requerimiento de un tamaño similar puede ser cambiado por otro equivalente en la iteración.
Los  equipos de XP trabajan en un orden estricto. Los requerimientos que serán desarrollados son priorizados por el cliente (Product Owner en Scrum) y el equipo debe desarrollar los requerimientos en ese orden específico. En contraste, el product owner de Scrum prioriza los product backlog pero el equipo determina el orden en el que serán desarrollados.

Scrum no recomienda ninguna buena práctica de desarrollo. XP si lo hace. Personalmente amo las buenas prácticas de XP , particularmente cosas como el test-driven development, desarrollo basado en pruebas, pair programing, diseño simple, entre otros. Pienso que es un error de los equipos el pensar en “auto-organización, confiamos en ti , pero debes hacer estan buenas prácticas en específico”. Esto envía un mensaje confuso al equipo. Las buenas practicas de XP no es necesarios obligar a los equipos a realizarlas pues descubren sus virtudes por cuenta propia.

SCRUM	XP
Es una metodología de desarrollo ágil basada en la administración del proyecto.	Es una metodología de desarrollo que está más centrada en la programación o creación del producto.
Cada miembro de del equipo trabaja de forma indivisual.	Los miembro del equipo programan en parejas.
Las ietraciones de entrega son de 1 a 4 semanas.	Las ietraciones de entrega son de 1 a 3 semanas
Al finalizar un Sprint, las tareas del Sprint Backlog que se hayan realizado y que el Product Owner (propietario del producto) haya mostrado su conformidad ya no se retoca. Si funciona y está bién, se aparta y a otra cosa.	Las tareas se van terminando aunque son susceptibles de ser modificadas durante el transcurso de proyecto, incluso, después de que funcionen correctamente.
Trata de seguir el orden de prioridades que marca el Product Owneren el Sprint Backlog pero puede cambiarlo si es mejor para el desarrollo de la tareas.	El equipo de desarrollo sigue estrictamente el orden de prioridad de las tareas definido por el cliente.

Conclusión:
Puedo notar que estas son pequeñas diferencias, pero importantes entre XP y Scrum. De cualquier manera, pueden tener un gran impacto en el equipo. Las buenas prácticas de XP son demasiado buenas y prácticas, pero pueden no funcionar bien para todos los equipos, es mejor que vean por si mismos cuales son las que más se adaptan a todo el equipo. Scrum es tambien muy bueno puesto que trae por muchas mejoras a la forma en que trabajan los equipos y parte de un buen punto para añadir las mejoras de XP.

Bibliografia:
https://es.slideshare.net/edgarespinoza/programacion-extrema
http://ingenieriadesoftware.mex.tl/52753_XP---Extreme-Programing.html
https://manifesto.co.uk/kanban-vs-scrum-vs-xp-an-agile-comparison/
http://www.islavisual.com/articulos/desarrollo_web/diferencias-entre-scrum-y-xp.php
"Una historia de guerra ágil".Henrik Kniberg.© 2007 C4Media Inc
http://ingenieriadesoftware.mex.tl/52812_Scrum.html
http://www.islavisual.com/articulos/desarrollo_web/diferencias-entre-scrum-y-xp.php
http://ingenieriadesoftware.mex.tl/52753_XP---Extreme-Programing.html