Dpss u3 a2_lummm.docx
Descargar como PPTX, PDF0 recomendaciones44 vistas
Este documento resume los procesos de evolución del software, incluyendo las etapas alfa, madurez y salida de los diferentes tipos de programas, así como ejemplos. También describe las leyes, tipos de cambio y reingeniería de sistemas que deben considerarse. Finalmente, ofrece conclusiones sobre cómo la evolución del software aplica la ingeniería de sistemas a su propio desarrollo.
Dpss u3 a2_lummm.docx
- 1. Unidad 3. Mantenimiento de s is temas de s oftwar e. A ctiv idad 2: P r oces os de evolución del s oftwar e . Docente: R icardo Rodríguez Nieves <f a.1004355@nube.unadmex ico.mx > Pruebas y Mantenimiento de Sistemas de Software Luis Gabriel Mateo Mejía- ES1421000963-UNADM-Ingeniería en Desarrollo de Software. <mateo.gabriel@nube.unadmexico.mx>, a 7 de marzo de 2018.
- 2. 1 . - A N Á L I S I S D E L S U B T E M A 3 . 2 . • LA EVOLUCIÓN DEL SOFTARE: Es el desarrollo del equilibrio entre las fuerzas impulsoras de los nuevos desarrollos, (UNADMÉXICO, 2018), y las que frenan el progreso por otro. • Las leyes se distinguen entres categorías: 1. Un programa S se escribe de acuerdo con una especificación exacta de lo que el programa puede hacer. • 2. Un programa P se escribe para implementar ciertos procedimientos que determinan lo que el programa puede hacer. 3. Un programa E está escrito para llevar a cabo algún tipo de actividad en el mundo real; su comportamiento está relacionado con el entorno en el que se ejecuta.
- 3. 1.1. LAS LEYES A CONSIDERAR PARA LOS PROCESOS DE EVOLUCIÓN DEL SOFTWARE L1 • Cambio continuo • Aumento de la complejidad L2 • Evolución de sistemas grandes • Estabilidad organizacional • Sistema de retroalimentación L3 • Conservación de familiaridad • Continuo crecimiento • Disminución de la calidad
- 4. 1.1. LAS LEYES A CONSIDERAR PARA LOS PROCESOS DE EVOLUCIÓN DEL SOFTWARE • Hay una propuesta de evolución del software de autores tratados por UNADM, (2018, que se muestra en la siguiente imagen, la cual considera a todos los sistemas de software, incluyendo a los de programa E, y se basa en el principio de que todos los sistemas tienen una versión alfa, una etapa de madurez y una de salida.
- 5. 2 . - E t a p a s d e c a d a t i p o d e p r o g r a m a Alfa: Se detectan faltas y características Etapa de salida: Mantiene su estabilidad hasta la inadaptabilidad Etapa de Madurez: Los usuarios implican cambios por necesidades E n la e voluc ión d el proceso d e inic io, d e sar r ollo y c onsumac ión Referencia de la ingeniería de sistemas, la cual implica el cambio y transformación de procesos a variables de entrada y salida, (UNADMÉXICO, 2018).
- 6. 3 . - E j e m p l o s d e l a e v o l u c i ó n d e c a d a t i p o d e s o f t w a r e Programa cmapstools – herramienta de programa para pc individual- para hacer diagramas conceptuales, rudimentariamente y adaptado al uso del internet 2.0. Su cambio y migración a programas con mayor diseño de adaptabilidad fue casi necesario poco después de la promoción del programa. Plataformas php para gestión de base de datos, ahora se comienzan a ver obsoletas, debido a que los mismos programas se pueden ejecutar desde la nube, sin necesidad de costosos pagos a servidores externos. 3-SALIDA Desarrollo de la plataforma de trabajo colaborativo Moodel, versión 1.2. y 2.3, su eficiencia permitió que fuera adaptada a todas las instituciones educativas a nivel internacional. 1 - A L FA 2 - M A D U R E Z
- 7. 4.- Ejemplo g rafico de la reingeniería de sistemas Se define como: “la 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”, (UNADM, 2018). Su gráfico de estructura es: C o n s t r u c c i ó n – d e c o n s t r u c c i ó n d e l s i s t e m a
- 8. 4.1. EJEMPLO GRÁFICO DE REINGENIERÍA DE SISTEMAS 1. Se observa una necesidad. 2. Se aplica un programa. 3. Se cálculo el producto. 4. No se logra la necesidad y se observa el código para re- estructurarlo. 5. Se hace el nuevo cálculo. 6. Se obtiene el resultado esperado. Del 1 al 3 Del 4 al 6
- 9. 5 . T I P O S D E C A M B I O Lógicos: Operandos incorrectos en una expresión lógica Lógica fuera de secuencia. Variable incorrecta Falta de prueba lógica o condición Número de iteraciones incorrectas en un ciclo De entrada: Formato incorrecto Lectura de entrada desde ubicación incorrecta Fin de archivo no encontrado o encontrado prematuramente Manejo de datos Archivo de datos no disponible Datos de referencia fuera de límites. Datos de inicialización variables usados como bandera, o índice no ajustado apropiadamente Los datos no están apropiadamente definidos ni dimensionados Error de subíndices Computacionales: Operandos incorrectos en ecuación Uso incorrecto de paréntesis Ecuación incorrecta o inexacta Error de redondeo o truncamiento T I P O S D E C A M B I O
- 10. 5. TIPOS DE CAMBIO De salida: Manejo de datos Archivo de datos no disponible Datos de referencia fuera de límites. Datos de inicialización variables usados como bandera, o índice no ajustado apropiadamente Los datos no están apropiadamente definidos ni dimensionados Error de subíndices Interfaz: Interfaz de software/hardware Interfaz de usuario software Interfaz de base de datos de software Rendimiento Tiempo límite excedido Límite de almacenamiento excedido Código o diseño ineficiente Eficiencia de la red Especificación: Interfaz del sistema Especificación incorrecta o inadecuada Especificación de requerimientos incorrecta o inadecuada Entrenamiento / manual de usuario inadecuado Operaciones Cambio de software Configuración del control Mejora: Mejora de funciones existentes Mejora de interfaz
- 11. 5. TIPOS DE CAMBIO El equipo de mantenimiento asigna también una prioridad al FCS, (formulario de cambio de software), bajo las siguientes características: • Emergencia, si el FCS es necesario para evitar tiempo de inactividad del sistema, o si los requisitos son de alta prioridad. • Urgente, si se necesita el FCS en la próxima entrega de software para un proceso en particular, o para solucionar un problema que surgió como resultado de un cambio en las operaciones. • Rutina para el resto de los FCS, por ejemplo, la conversión de unidades, cambios en el valor por defecto y para arreglar la impresión.
- 12. 6 . - C O N C L U S I O N E S La evolución del software es la aplicación de la ingeniería de sistemas a su desarrollo propio y autónomo El análisis de requerimiento implica el tipo de cambio de la evolución a evaluar en la elaboración-reingeniería del software La evolución del software gira en torno a la función de las etapas del programa, que son: alfa, de madurez y de salida bajo los esquemas de: Reingeniería de sistemas. Consideración de las leyes de cambio del proceso de desarrollo del software.
- 13. 7 . - B I B L I O G R A F Í A Y F U E N T E S D E C O N S U L TA • UNADMÉXICO (2018). Apuntes de la unidad tres de la asignatura: Pruebas y mantenimiento de sistemas de software. En línea. Recuperado el día 6 de marzo de 2018 en: https://unadmexico.blackboard.com/webapps/assignment/uplo adAssignment?content_id=_1473365_1&course_id=_47028_1& user_id=_136691_1