Elementos de Configuración de Software

Un elemento de configuración del software (ECS) es la información creada como parte del

proceso de ingeniería del software.

Son elementos de Configuración en un proyecto de software: 

01. El plan de proyecto. 
02. El plan de Gestión de Configuración. 
03. El documento de definición de requerimientos. 
04. Estándares de análisis, diseño, codificación, pruebas, y auditoria. 
05. Documentos de análisis del sistema. 
06. Documentos de diseño del sistema. 
07. Prototipos. 
08. Documentos de diseño de alto nivel. 
09. Documentos de diseño de bajo nivel. 
10. Especificaciones de prueba del sistema. 
11. El plan de pruebas del sistema. 
12. El Código fuente del programa. 
13. Código objeto y ejecutable. 
14. Especificaciones de pruebas de unidad. 
15. Planes de pruebas de unidad. 
16. Documentos de diseño de base de datos. 
17. Datos de prueba. 
18. Datos del proyecto. 
19 .Manuales de usuario. 

Bibliografía
http://www.ual.es/~rguirado/posi/Tema5-Apartado5.pdf
http://www.histaintl.com/soluciones/configuracion/configuracion.php

Reingenieria de Software

Requerimientos: 

1. El sistema debe de tener una sección en la cuál el usuario pueda registrarse.
2. El sistema debe de tener una sección en la cuál el usuario pueda eliminar su cuenta.
3. El sistema debe de tener una sección en la cuál el usuario pueda modificar su información.
4. El sistema debe de tener una sección en la cuál el usuario pueda visualizar la información acerca         de las Asignaturas.
5. El sistema debe de tener una sección en la cuál el usuario pueda visualizar la información acerca         de las Matrículas.

Diagramas de Casos de Uso: 

Diagramas de Secuencia

Diagrama de Actividades

Proceso de Reingeniería de Software

Reingeniería es comenzar de cero, es un cambio de todo o nada, además ordena la empresa alrededor de los procesos. La Reingeniería se puede dividir en dos grandes ramas, la reingeniería de negocios y la de software. En negocios, la reingeniería se concentra en el proceso de negocios con la intención de efectuar cambios que mejoren la competitividad en algún aspecto de los negocios. A nivel del software, la reingeniería examina los sistemas y aplicaciones de información con la intención de reestructurarlos o reconstruirlos de tal modo que muestren una mayor calidad. 

¿Qué es? 

La reingeniería es un proceso mediante el cual se mejora un software existente haciendo uso de técnicas de ingeniería inversa y reestructuración de código. También se puede definir como: “modificación de un producto software, o de ciertos componentes, usando para el análisis del sistema existente técnicas de Ingeniería Inversa y, para la etapa de reconstrucción, herramientas de Ingeniería Directa, de tal manera que se oriente este cambio hacia mayores niveles de facilidad en cuanto a mantenimiento, reutilización, comprensión o evaluación.”

Cuando una aplicación es usada por años, es fácil que esta aplicación se vuelva inestable a causa de las múltiples correcciones, adaptaciones o mejoras que han podido surgir a lo largo del tiempo. Por lo que cada vez que se pretende realizar un cambio se producen efectos colaterales inesperados y hasta de gravedad, por lo que se hace necesario, si se prevé que la aplicación seguirá siendo de utilidad, aplicar reingeniería a la misma.

La reingeniería en algunos casos requiere tiempo; conlleva un gran coste de dinero y absorbe recursos que de otro modo podrían emplearse en preocupaciones más inmediatas. Por todas estas razones, la reingeniería no se lleva a cabo en unos pocos meses, ni siquiera en unos pocos años. Esta es la razón por la cual toda organización necesita una estrategia pragmática para la reingeniería del software.

Una estrategia de trabajo también acompaña al modelo de procesos de reingeniería. El Proceso de la Reingeniería del Software:

1. Análisis de inventarios
2. Reestructuración de documentos
3. Ingeniería inversa
4. Reestructuración de programas y datos
5. Ingeniería directa

Análisis de inventario: Todas las organizaciones de software deberían tener un inventario de todas sus aplicaciones. El inventario puede que no sea más que una hoja de cálculo con la información que proporciona una descripción detallada (por ejemplo: tamaño, edad, importancia para el negocio) de todas las aplicaciones activas. El inventario deberá visitarse con regularidad, el estado de las aplicaciones puede cambiar en función del tiempo y, como resultado, cambiarán las prioridades para la reingeniería.

Los candidatos a la reingeniería aparecen cuando se ordena esta información en función de su importancia para el negocio, longevidad, mantenibilidad actual y otros criterios localmente importantes. Es entonces cuando es posible asignar recursos a las aplicaciones candidatas para el trabajo de reingeniería.

Reestructuración de documentos: Algunos sistemas heredados tienen una arquitectura de programa relativamente sólida, pero los módulos individuales han sido codificados de una forma que hace difícil comprenderlos, comprobarlos y mantenerlos. Una documentación escasa es la marca de muchos sistemas heredados.

 La creación de documentación consume muchísimo tiempo. El sistema funciona, y ya nos apañaremos con lo que tengamos. En algunos casos, éste es el enfoque correcto. No es posible volver a crear la documentación para cientos de programas de computadoras. Si un programa es relativamente estático está llegando al final de vida útil, y no es probable que experimente muchos cambios.

Para llevar a cabo esta actividad, se analiza el código fuente mediante una herramienta de reestructuración, se indican las violaciones de las estructuras de programación estructurada, y entonces se reestructura el código (esto se puede hacer automáticamente). El código reestructurado resultante se revisa y se comprueba para asegurar que no se hayan introducido anomalías. Se actualiza la documentación interna del código.

Ingeniería inversa:  La ingeniería inversa puede extraer información de diseño del código fuente, pero el nivel de abstracción, la completitud de la documentación, el grado con el cual trabajan al mismo tiempo las herramientas y el analista humano, y la direccionalidad del proceso son sumamente variables.

Una cierta compañía desensambla un producto de hardware competitivo en un esfuerzo por comprender los «secretos» del diseño y fabricación de su competidor. Estos secretos se podrán comprender más fácilmente si se obtuvieran las especificaciones de diseño y fabricación del mismo. Pero estos documentos son privados, y no están disponibles para la compañía que efectúa la ingeniería inversa. En esencia, una ingeniería inversa con éxito precede de una o más especificaciones de diseño y fabricación para el producto, mediante el examen de ejemplos reales de ese producto.

La ingeniería inversa del software es algo bastante similar. Sin embargo, en la mayoría de los casos, el programa del cual hay que hacer una ingeniería inversa no es el de un rival, sino, más bien, el propio trabajo de la compañía (con frecuencia efectuado hace muchos años). Los «secretos» que hay que comprender resultan incomprensibles porque nunca se llegó a desarrollar una especificación. Consiguientemente, la ingeniería inversa del software es el proceso de análisis de un programa con el fin de crear una representación de programa con un nivel de abstracción más elevado que el código fuente. La ingeniería inversa es un proceso de recuperación de diseño. Con las herramientas de la ingeniería inversa se extraerá del programa existente información del diseño arquitectónico y de proceso, e información de los datos.

Reestructuración del código: Algunos sistemas heredados tienen una arquitectura de programa relativamente sólida, pero los módulos individuales han sido codificados de una forma que hace difícil comprenderlos, comprobarlos y mantenerlos. En estos casos, se puede reestructurar el código ubicado dentro de los módulos sospechosos.  Para llevar a cabo esta actividad, se analiza el código fuente mediante una herramienta de reestructuración, se indican las violaciones de las estructuras de programación estructurada, y entonces se reestructura el código (esto se puede hacer automáticamente). El código reestructurado resultante se revisa y se comprueba para asegurar que no se hayan introducido anomalías. Se actualiza la documentación interna del código.

Reestructuración de datos:  Un programa que posea una estructura de datos débil será difícil de adaptar y de mejorar.  A diferencia de la reestructuración de código, que se produce en un nivel relativamente bajo de abstracción, la estructuración de datos es una actividad de reingeniería a gran escala. En la mayoría de los casos, la reestructuración de datos comienza por una actividad de ingeniería inversa. La arquitectura de datos actual se analiza minuciosamente y se definen los modelos de datos necesarios. Se identifican los objetos de datos y atributos y, a continuación, se revisan las estructuras de datos a efectos de calidad.

Cuando la estructura de datos es débil, se aplica una reingeniería a los datos. Dado que la arquitectura de datos tiene una gran influencia sobre la arquitectura del programa, y también sobre los algoritmos que lo pueblan, los cambios en datos darán lugar invariablemente a cambios o bien de arquitectura o bien de código.

Ingeniería directa: La ingeniería directa, que se denomina también renovación o reclamación, no solamente recupera la información de diseño de un software ya existente, sino que, además, utiliza esta información para alterar o reconstruir el sistema existente en un esfuerzo por mejorar su calidad global. En la mayoría de los casos, el software procedente de una reingeniería vuelve a implementar la funcionalidad del sistema existente, y añade además nuevas funciones y/o mejora el rendimiento global.

Conclusiones: 

El Proceso de Reingeniería de Software es muy importante para los sistemas software ya que es una actividad de reconstrucción, la cual es preferible de realizar antes de que se “derrumbe” la obra. Aunque a veces puede llegar a ser costosa y consumidora de tiempo, puede ser una mejor opción que construir un software desde cero porque esto implicaría aún más tiempo, personal y dinero. 

En otras ocasiones no es una buena opción, un ejemplo sería si el sistema al que se le desea hacer la reingeniería está en muy malas condiciones y sea muy difícil el aplicar los pasos. 

Bibliografía

isoftwareunesum. (28 de Abril de 2011). INGENIERÍA DEL SOFTWARE. Obtenido de https://isoftwareunesum.wordpress.com/2011/04/28/reingenieria-de-la-ingenieria-del-software/

Mendoza, E. E. (08 de Octubre de 2007). Reingenieria UCV. Obtenido de http://reingenieriaucv2007.blogspot.mx/2007/10/qu-es-reingeniera.html

NORSOFT. (25 de Marzo de 2015). NORSOFT Information Tecnologies. Obtenido de http://www.norsoft.com.ar/servicios/servicios-reingenieria.html

Solís, F. (12 de Octubre de 2012). Reingenieria de software. Obtenido de https://prezi.com/z4yorwp-ho2x/pasos-para-la-reingenieria-de-software/

Leyes de Lehman

Las Leyes de Evolución del Software propuestas por Lehman, las cuales describen el balance entre lo que impulsa nuevos desarrollos y lo que relentizan el proceso.

Lehman se basó en 8 leyes de las cuales algunos ejemplos son:

1. Cambio Continuo:  Un ejemplo de esta primera ley sería la evolución de los navegadores, por ejemplo, Internet Explorer ya que en comparación con Chrome está dejando de ser utilizado casi en su totalidad, ya que no se le dieron los cambios adecuados a tiempo, por lo que no se adaptó a este nuevo entorno, lo que ocasionó que se utilizara menos.
2. Incremento de la Complejidad: Esta ley habla principalmente de que 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. Un claro ejemplo son las incorporaciones tecnológicas a las empresas ya que mientras estas entran, no todos los empleados los empleados lo conocen saben cómo usarlo, por lo que se requiere capacitar al personal para que ellos puedan usar estas nuevas tecnologías, lo que provoca que las empresas gasten más recursos en esto. 
3. Evolución Prolongada del Programa (Autorregulación): En esta ley tomaremos como ejemplo los Antivirus, ya que estos han estado autorregulándose para atacar o prevenir los nuevos virus, ya que los virus cada vez se hacen más y más fuertes, así como cada vez hay más. 
4. Conservación de la Estabilidad Organizada:  "A lo largo del tiempo de vida de un programa, la carga que supone el desarrollo de dicho programa es aproximadamente constante e independiente de los recursos dedicados." Un ejemplo puede ser la elaboración de ropa en algún taller de costura, mientras más ropa se quiera elaborar y en el mismo tiempo se necesitarán de más personal. 
5. Conservación de la Familiaridad: Un ejemplo a esta ley es WhatsApp el cuál casi no conservo su familiaridad ya que le quitaron varias cosas y pusieron otras, como el estado, con lo que varias personas no están de acuerdo. 
6. Crecimiento Continuo: "Las funcionalidades del sistema tienen que crecer constantemente para mantener la satisfacción del usuario a lo largo de su ciclo de vida" Un ejemplo de esto son las empresas, las cuales sacan algún nuevo producto y creen que como se vende mucho ya no necesitan más cambios, sin embargo, esto no es cierto ya que los usuarios se pueden llegar a aburrir y dejar de usar ese producto por mas bueno que sea.
7. Calidad Decreciente: “La calidad de los sistemas comienza a disminuir a menos que se mantengan de forma rigurosa y se adapten a los cambios en su entorno de funcionamiento (operacional)”. Un ejemplo de esta ley es el sistema operativo Black Berry, el cual se quedó estancado y a pesar de lo popular que fue en su época ahora ya no se usa. 
8. Realimentación del Sistema: “El proceso de evolución del sistema es consecuencia de un proceso de realimentación (feedback) a diferentes niveles, de manera iterativa y por diferentes actores, y debe ser considerado como tal para conseguir mejoras significativas sobre cualquier base razonable”. Un muy buen ejemplo es Facebook ya que este software a base de sugerencias o quejas se ha ido retroalimentando con el tiempo y no se ha quedado estancado, al contrario, se ha vuelto más y más popular.

Reporte de Visita CASA TELMEX

El día jueves 16 de febrero del presente año mi grupo realizo una visita escolar al complejo Casa TELMEX.

Realizamos una serie de actividades entretenidas, que nos propusieron los ayudantes, también recibimos una plática sobre seguridad web, la cual fue realmente interesante ya que el instructor nos habló y enseño cosas que no sabíamos y que nos podrían ayudar en un futuro, ya sea que sigamos estudiando esta misma carrera o no. 

Dentro de las pláticas que nos dieron hablaron un poco de soporte de software. En TELMEX ofrecen muchos servicios para la comodidad del usuario, ofrecen soporte técnico ya sea vía internet o telefónica. 

Los servicios en soporte técnico que ofrecen son extensos, desde ayuda para instalar algún antivirus hasta guías y manuales para instalar programas. 

También ofrecen mantenimiento para navegadores o vías telefónicas. 

La visita a CASA TELMEX se me hizo muy interesante ya que los instructores sabían lo que hacían y decían, lo que me da a entender que en TELMEX hay personas con muchos conocimientos y de buena calidad. 

Soporte de Software

Soporte de Software 

INTRODUCCIÓN 

La ingeniería del software, según la definición de la IEEE en 1983, "El enfoque sistemático para el desarrollo, operación, mantenimiento y eliminación del software, definiendo como software los programas, procedimientos, reglas y documentación, así como los datos de operación de un sistema de cómputo."  Según esto la ingeniería del software ofrece los métodos para desarrollar software de calidad. Este concepto surgió después de la terrible crisis del software ya que se necesitaban métodos o técnicas para, como se dijo antes, desarrollar software de calidad.

Esto se desarrolló por que los software en ocasiones eran o muy costosos y no efectivos, o complicados para las mentes comunes las cuales lo ocuparían.

Uno de los cambios que tuvo el proceso de desarrollo de software fue el tener que hacer documentación y de esto se desencadenaron procesos para hacer más efectivo el desarrollo del mismo, a uno de ellos le llamarón "ciclo de vida del software" el cual comprende las estepas por las que pasa un proyecto software desde que es concebido.

Dentro de estos procesos está el mantenimiento del software, pero no solo se necesitaba el dar mantenimiento al producto, si no que también se necesitaba dar soporte al cliente, para que esté cuando tuviera dudas sobre cómo usarlo o algún otro, tenga la ayuda necesaria para resolver sus dudas. De esto nació el Soporte de Software.

SOPORTE DE SOFTWARE

El soporte de software, como se dijo anteriormente, enlaza lo que son el Soporte Técnico y el Mantenimiento de Software ya que es indispensable para cualquier buen desarrollador el tener no solo un buen producto software sino también es muy importante el dar al usuario las herramientas necesarias para usar el sistema y alguna ayuda por si el software presenta fallas o problemas.

El Soporte de Software no es un tema fácil de explicar, ya que no hay ningún concepto o definición que hable de este tema en concreto.

Pero técnicamente el soporte de software es un grupo de servicios o actividades en las que se provee asistencia hacia un cliente para proporcionarle soporte o mantenimiento sobre algún producto software. Esta asistencia puedo ser solo informativa, por ejemplo, sobre el uso del software, y se daría al cliente o puede ser de mantenimiento en la que se podría perfeccionar, adaptar, corregir o prevenir problemas en el software.  Por lo que sería indispensable el definir estos dos conceptos, el mantenimiento de software y el soporte técnico.

Mantenimiento de software.

Es el proceso en el que se mejora u optimiza el software, este proceso se puede realizar desde que se está desarrollando el software o después de haber sido entregado al cliente; estos cambios que se realizan sobre el software pueden ser adaptativos, correctivos, perfectivos o preventivos.

Tipos de Mantenimiento de Software:

• Adaptativo: Este se realiza cuando se requiere que el software se adapte a los cambios en el entorno en el cuál se ejecuta, un ejemplo podría ser cuando ocurre un cambio en el sistema operativo, como cuando se cambia a uno más moderno, o también cuando cambia la arquitectura física del sistema informático. Sin embargo, este en ciertas ocasiones puede ser muy caro y difícil, por lo que sería mejor comenzar un nuevo software.

• Correctivo: A pesar de las pruebas y verificaciones que se le hacen al proyecto después de haber sido entregado, puede haber defectos en el sistema. Este tipo de mantenimiento localiza y corrige los posibles defectos del software. Estos fallos o problemas pueden presentarse por diversas cuestiones. Sin embargo, estos defectos pueden llegar a ser muy costosos, si el error esta en los requerimientos debido a que puede ser necesario un rediseño extenso del sistema, o baratos si el error solo está en el diseño de la interface.

• Preventivo: Este tipo de mantenimiento puede facilitar el mantenimiento futuro del sistema ya que consiste en modificar esté para mejorar sus propiedades, sin alterar sus especificaciones funcionales o para que en un futuro sea más fácilmente reutilizable. Algunas acciones del mantenimiento preventivo son: ajustes, limpieza, análisis, lubricación, calibración, reparación, cambios de piezas, entre otros. El mantenimiento preventivo se efectúa periódicamente.

• Perfectivo: El principal objetivo del mantenimiento perfectivo es llevar a cabo las tareas y procesos necesarios para identificar aquellos puntos susceptibles de mejora. El mantenimiento perfectivo es el conjunto de actividades para mejorar o añadir nuevas funcionalidades requeridas por el usuario.

    El mantenimiento de software también presenta varios problemas, algunos de los cuales son:

• Cambios ad-hoc, ausencia metodológica del cambio
•  Ausencia de documentación adecuada (decisiones de diseño). 
• Degradación calidad del producto.
• Efectos dominó y efecto iceberg: Este es simple de explicar ya que este se presenta cuando al hacerle algún cambio al sistema como consecuencia debemos realizar cambios a otras partes del sistema. 

Soporte Técnico: 

El Soporte Técnico es un grupo de servicios que proporcionan asistencia con el hardware o software de una computadora, o algún otro dispositivo electrónico o mecánico, con la finalidad de ayudar a los usuarios a resolver ciertas dudas o problemas que tienen con el uso del producto.

Hay dos tipos de soportes: 

• Soporte Técnico presencial: Este tipo de soporte es el que realiza el técnico en presencia del cliente o usuario y en donde se encuentra el aparato o software en cuestión.
• Soporte Técnico a distancia o remoto: Es aquel que se realiza, como su nombre lo dice, vía teléfono o mail o de manera remota, para resolver algún problema a distancia sobre algún aparato o software. 

CONCLUSIÓN

El soporte de software es indispensable para desarrollar un producto software de calidad, y que sin esté muchas personas dejarían de usar dichos software por el simple hecho de no saber cómo utilizaros o si esté a su vez presenta alguna falla o error. 

Bibliografías: 

·        AESIS. (s.f.). Software para Soluciones Empresariales . Obtenido de Mantenimiento Perfectivo : http://www.aesist.com/soporte/mantenimiento-perfectivo

·         Francisco Ruiz, M. P. (2001). Mantenimiento del Software. Obtenido de http://alarcos.esi.uclm.es/per/fruiz/cur/mso/trans/s1.pdf

·         Hammer y Champy. (19 de mayo de 2013). Colorbits. Obtenido de Conceptos Básicos de Soporte de Software: http://colorbitsinc.blogspot.mx/2013/05/conceptos-basicos-de-soporte-de-software.html

·         Significados . (5 de Enero de 2013). Obtenido de Significado de Mantenimiento preventivo: https://www.significados.com/mantenimiento-preventivo/

·         Simon Pickin, M. G. (2010). Introducción a la ingeiería del software. Obtenido de http://ocw.uc3m.es/ingenieria-telematica/software-de-comunicaciones/transparencias/introduccion-a-la-ingenieria-del-software

·         SINCOWS. (s.f.). SINCOWS. Obtenido de Mantenimiento de Software : http://www.sincows.com/sincows/index.php?option=com_content&view=article&id=70&Itemid=68

·         Solano, D. (2 de marzo de 2013). Soporte Tecnico. Obtenido de http://soportetecnico4ctsmec.blogspot.mx/2013/03/definicion-de-soporte-tecnico.html

·         Tomás, P. P. (28 de diciembre de 2010). Blog Historia de la Informatica . Obtenido de Ingeniería de Software: http://histinf.blogs.upv.es/2010/12/28/ingenieria-del-software/