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

Leyes de Lehman

Tipos de Mantenimiento de Software:

Mantenimiento Preventivo

Un claro ejemplo de este mantenimiento es la plataforma de videojuegos llamada Steam ya que prevee la saturación de los servidores al momento de que se lanza una oferta o cualquier juego se da gratis en un periodo de 24 hrs.

Mantenimiento Correctivo

El ejemplo perfecto para este tipo de mantenimiento es la aplicación de Facebook en ciertas ocasiones se queda congelada la lista de contactos y no muestra quien esta conectado y quien desconectado realmente, otro punto en contra es que los mensajes a veces no se actualizan.

Mantenimiento Adaptativo

La plataforma de lanzamiento del juego conocido como “League of legends” la compatibilidad y jugabilidad en diferentes sistemas operativos que no sea Windows es bastante mala.

Mantenimiento Perfectivo

El emulador de juegos llamado Dolphin lo que se podría implementar para mejorar su rendimiento es corregir los bugs y parchar los juegos los cuales corre, además de que emule juegos de wii y de wii u.

Leyes de Lehman

Cambio continuo:  Un programa que se usa en un entorno real necesariamente debe cambiar o se volverá progresivamente menos útil y menos satisfactorio para el usuario.

Las Redes Sociales Son un claro ejemplodel cambio continuo, ya que si no son atractivas y funcionales, entonces los usuarios dejarán de usarlas. Por lo tanto deben estar actualizandose constantemente.

Complejidad creciente: A medida que un programa en evolución cambia, su estructura tiende a ser cada vez más compleja. Se deben dedicar recursos extras para preservar y simplificar su estructura.

Facebook y las versiones de Android en especifico están en evolución están en conste cambio y es por ello que su estructura debe ser cambiada debido a su complejidad.

Autoregulación:  La evolución de los programas es un proceso autoregulado. Los atributos de los sistemas, tales como tamaño, tiempo entre entregas y la cantidad de errores documentados son aproximadamente invariantes para cada entrega del sistema.

Podemos relacionar esta Ley con el virus de la influenza AH1N1, que ha estado autoregulandose para cambiar conforme avanza el tiempo desde que fue descubierta, ya que ha sido muy dificil encontrar una cura y el virus muta mas rápido, entonces concluimos que el virus se autoregula para cambiar.

Estabilidad organizacional:  Durante el tiempo de vida de un programa, su velocidad de desarrollo es aproximadamente constante e independiente de los recursos dedicados al desarrollo del sistema.

Conservación de la familiaridad: A medida que un sistema evoluciona todo lo que está asociado con ello, como los desarrolladores, personal de ventas, y usuarios por ejemplo, deben mantener un conocimiento total de su contenido y su comportamiento para lograr una evolución satisfactoria. Un crecimiento exagerado disminuye esta capacidad. Por tanto este incremento promedio debe mantenerse.

Multitasking en iOS: Para muchos quienes desconocían el mutitasking de iOS esta nueva funcionalidad fue problemática, ya que a falta de conocimiento de esta varias aplicaciones se mantenían funcionando en segundo plano, provocando que la memoria libre del dispositivo se redujera y por lo tanto su eficiencia fuera menor.
Está relacionada con la familiaridad, ya que para los usuarios perdían rendimiento de sus dispositivos a causa de una nueva funcionalidad que hasta entonces no conocían.

Crecimiento continuado:  La funcionalidad ofrecida por los sistemas tiene que crecer continuamente para mantener la satisfacción de los usuarios.

Decremento de la calidad: La calidad de los sistemas software comenzará a disminuir a menos que dichos sistemas se adapten a los cambios de su entorno de funcionamiento.

Yahoo rediseño su pagina en México donde muestra que están en constante cambio para que sus usuarios tenga una mejor experiencia. Además de que no es un cambio radical ya que solo cambia algunos aspectos para que la experiencia de del usuario sea mas intuitivo, conservando la estructura básica de su sitio pero agregando nuevas funciones a éste.

Bibliografia:
Lehman, M. M., & J. F. Ramil, P. D. (1997). Metrics and laws of software evolution—the nineties view.

Gestión de Proyectos. "Leyes de Lehman".Febrero 2014

http://alexistorreblanca.blogspot.mx/2014/02/tipos-de-mantenimiento-de-software-y.html

http://gcp5im6.blogspot.mx/2014/02/leyes-de-lehman.html

Leyes de Lehman. Primitivo López García
http://ronuor.blogspot.mx/2014/02/leyes-de-lehman.html
https://www.lifewire.com/use-multitasking-on-iphone-2000763

Modelos de desarrollo de Software

INTRODUCCIÓN:

      Dentro de estos modelos de software se sigue un proceso de producción de Software y un ciclo de vida de los modelos estructurados.

      La meta de meta de un modelo es determinar el orden de las etapas que componen el desarrollo y evolución del software. Y están hechos para contestar las siguientes preguntas:

        ¿Qué debemos hacer a continuación?
        ¿Cuánto tiempo debemos continuar haciéndolo?

     Según Sommerville (2005), para muchas personas el software son solo programas de computadora, sin embargo nos comenta que son todos aquellos documentos asociados a la configuración de datos que se necesitan para hacer que estos programas operen de manera adecuada.

DESARROLLO:

¿Qué es un modelo de desarrollo?

Un modelo de desarrollo es una representación abstracta de un proceso de software, cada modelo representa el proceso de desarrollo de software de una manera en particular. A pesar de estar definidos claramente, no representan necesariamente la realidad de cómo se debe desarrollar el software, sino que establece un enfoque común. Un modelo puede ser modificado y adaptado de acuerdo a las necesidades del software en desarrollo.
En forma general podemos clasificar los modelos de desarrollo en 3 grupos:

El modelo en cascada

 Considera las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución, y los representa como fases separadas del proceso, tales como la especificación de requerimientos, el diseño del software, la implementación, las pruebas, etcétera.

Desarrollo Evolutivo

El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de separarse. Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Un sistema inicial se desarrolla rápidamente a partir de especificaciones abstractas. Éste se refina basándose en las peticiones del cliente para producir un sistema que satisfaga sus necesidades.

Existen dos tipos de desarrollo evolutivo:

Desarrollo exploratorio

Donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.

Prototipos desechables

Donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.

Modelo Espiral

Es un modelo de desarrollo evolutivo propuesto por Barry Boehm, que utiliza prototipos como apoyo. La forma de espiral representa una iteración (repetición) de procesos que, a medida que se van entregando prototipos y éstos son revisados por los clientes o usuarios finales, el tiempo empleado para desarrollar la próxima versión es cada vez mayor. Cada división recibe el nombre de región de tareas.

Aunque el modelo espiral representa ventajas por sobre el desarrollo lineal, el cálculo de los riesgos puede ser muy complicado y no es tan usado en la realidad.

Modelo Incremental

El modelo incremental es una unión de las mejores funcionalidades del modelo de cascada y del modelo de prototipos. A medida que se presenta un prototipo se produce un “incremento”, que es una iteración del proceso anterior pero aplicando las experiencias aprendidas del proceso anterior. A diferencia del modelo de prototipos, los prototipos de este modelo están orientados a ser operacionales en cada incremento y no ser solo una “previa” de cómo sería el sistema en su versión final.

CONCLUSIÓN:

Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más ventajas en comparación con un enfoque en cascada ya que el sistema se va ajustando a las necesidades del cliente, a la vez que él mismo entiende mejor sus propios requerimientos. Sin embargo el enfoque evolutivo desde una perspectiva de ingeniería y gestión suele tener grandes problemas.

Pienso que el desarrollo de software es uno de los pilares fundamentales al cual se dedican muchas horas de esfuerzo, y conforme la tecnología va avanzando, se van apareciendo nuevas soluciones, nuevas formas de programación, nuevos lenguajes, y un sin fin de herramientas que intentan realizar el trabajo del desarrollador un poco mas fácil. Es importante conocer bien estos modelos, para tener un esquema mental que nos permita gestionar proyectos y organizar equipos que sean productivos.

BIBLIOGRAFÍA:

http://www.eumed.net/tesis-doctorales/2014/jlcv/software.htm
Carvajal Jose Carlos. Metodologías Ágiles. Septiembre 2008.
http://tema3isoftware.blogspot.mx/p/modelos-de-desarrollo-tecnicas-y.html

https://es.wikiversity.org/wiki/Procesos_de_desarrollo_software

http://www.monografias.com/trabajos39/desarrollo-del-software/desarrollo-del-software2.shtml

Soporte de Software

Soporte de Software:

Es dar mantenimiento al software realizando actividades de soporte técnico.

Metodologías Ágiles: (Ensayo y Mapa conceptual)

INTRODUCCIÓN:

Se puede destacar que en el pasado existía un estándar en el cual se definía para garantizar la calidad del software mediante métodos de análisis y diseño soportados por herramientas CASE (Ingeniería de Software Asistida por Computador), sin embargo estas metodologías tenían una carga pesada en la planificación, diseño y documentación dedicándole menos tiempo al desarrollo del sistema.

Sin embargo a finales de los años 80's y principios de los años 90's se proponen nuevos métodos ágiles de programación, los cuales se enfocan en el software y le dedican menos tiempo al diseño y documentación, entre algunos métodos de programación ágil se encuentran: XP (extreme programming), LSD (Lean Software Development), Scrum, entre otros, destacando estos por ser los más utilizados.

DESARROLLO

Una metodología es una colección de procedimientos, técnicas, herramientas y documentos auxiliares que ayudan a los desarrolladores de software en sus esfuerzos por implementar nuevos sistemas de información. Una metodología está formada por fases, cada una de las cuales se puede dividir en sub-fases, que guiarán a los desarrolladores de sistemas a elegir las técnicas más apropiadas en cada momento del proyecto y también a planificarlo, gestionarlo, controlarlo y evaluarlo.
Las metodologías comunes en el desarrollo de software son muy rígidas, muy resistente a los cambios a lo largo del proyecto y todo debe ser definido desde el inicio, y la gran mayoría de las veces eso no es posible seguir todo al pie de la letra, de aquí surge la necesidad de crear nuevas metodologías que puedan atacar los problemas que tienen las antes mencionadas, surgen cosas como la programación extrema, metodologías de cristal,  entre otros, explicaremos algunos.

Programación Extrema

Fué formulada por  Kent Beck en 1999,  siendo este el más destacado de los procesos ágiles de programación, pone énfasis en la adaptación del software en el proceso de desarrollo, es mas realista en muchos sentidos en especial en los requerimientos ya que aveces ponemos cosas que si bien son muy difíciles, algunas son ciencia ficción, es común que en esta metodología el cliente se involucre con el equipo de desarrollo o bien pertenezca a este, en lo personal, me gusta mucho este.

Crystal Clear

Mas que una metodología, son una familia de estas, fueron descritas por Alistair Cockburn, e ideal para equipos de 6 a 8 personas, se centra en las personas, no en los procesos, y la seguridad es una de sus mayores preocupaciones.

DSDM

El método de desarrollo de sistemas dinámicos (Dynamic Systems Development Method) desarrollado en el reino unido en la época de los 90's provee un framework de desarrollo y es increíblemente flexible a los cambios en los requerimientos, es ideal para proyectos que deben sacarse en poco tiempo.

SCRUM

Consiste en un modelo de asignación de tareas diarias basado en reuniones rápidas y control de la evolución de los procesos.

LEARN PROGRAMMING

Consiste en ciclos de evolución de software incrementales en los que se posponen las decisiones lo más posible hasta haber obtenido una retro alimentación del cliente y así reaccionar lo más rápido y eficazmente posible a sus necesidades.

Conclusiones:

Después de conocer lo que son las metodologías ágiles, se podría decir que éste tipo de planificación será la más utilizada por programadores, ya que son aplicables a una mayor cantidad de sistemas en el mercado y a miparecer, su filosofía es más confortable para los clientes porque le presta una mejor participación en el proyecto, también otorga mayor confianza al trabajo del programador por la constante comunicación y la entrega parcial de los avances funcionales del sistema, lo que lo hace un método favorable, y debido a que los proyectos que llevamos ahora suelen ser muy grandes y deben entregarse en tan solo algunos meses, me parece que estas metodologías son ideales, y aunque desde el inicio se siguió la metodología tradicional, me parece que hubiera sido mas acertado que hubiésemos seguidos alguna de estas metodologías, ya que habría sido mucho mas ameno, y la verdad es que al menos en los equipos en los que he estado, en buena parte hemos seguido estas metodologías en algunos aspectos y sin saber que o como se definían.

Bibliografía:
http://danielgrifol.es/metodologias-agiles-de-desarrollo-de-software/
http://blog.leanmonitor.com/es/que-son-las-metodologias-agiles/

http://carlosreynoso.com.ar/archivos/arquitectura/Metodos-Agiles.PDF

http://www.agilemanifesto.org/iso/es/principles.html

http://www.i2btech.com/blog-i2b/tech-deployment/5-beneficios-de-aplicar-metodologias-agiles-en-el-desarrollo-de-software/

http://www.agilemanifesto.org/iso/es/manifesto.html