1. Universidad Abierta y a Distancia de México
Carrera: Ingeniería en Desarrollo en Software
Alumna: Rosalinda Yehuala Mastranzo
AL10524119
Profesor: Ricardo Rodríguez Nieves
Unidad 3
Actividad 2.Proceso de Evaluación de Software.

2. Al observar que la mayoría del software está sujeto a cambios en el curso de su existencia, Lehman y Belady (1985)
determinaron las leyes que suelen obedecer, o deben obedecer para que el software pueda sobrevivir, mediante la
distinción de tres categorías de software:
1.Un programa S ('static-type', tipo estático) se escribe de acuerdo con una
especificación exacta de lo que el programa puede hacer. Ejemplo: sistemas que
devuelven resultados en base a fórmulas ya definidas. Ejemplo: Una calculadora.
Un programa P ('practical-type', tipo práctico) se escribe para implementar ciertos
procedimientos que determinan lo que el programa puede hacer. Ejemplo: Software
de Juegos.
1.Un programa E ('embedded-type', tipo embebido o empotrado) 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. Un programa de este tipo tiene que
adaptarse a las diferentes necesidades y circunstancias del medio ambiente.
Ejemplo: Software de comercio en línea.

3. •Durante la versión alfa del sistema de software, a pesar de las diferentes pruebas, es posible que se detecte la
falta de algunas características, que se incorporarán durante esta etapa también conocida como de desarrollo
inicial. Se basan en escenarios o casos de estudios. El desarrollo inicial genera un banco de conocimiento, tal
como el de dominio de aplicación, requisitos de los usuarios, reglas de negocio, políticas, soluciones, algoritmos,
etc. Una vez que la versión alfa se completó con éxito, el sistema de software es puesto en marcha, lo que
conlleva a la necesidad de la evolución como consecuencia del uso.
•Se origina por que los usuarios tienden a cambiar sus necesidades, así como su propia percepción de mejoras en
el sistema. La industria del software se enfrenta al reto de cambios vertiginosos en el entorno, de ahí que la meta
de la evolución sea la adaptación de la aplicación a las siempre cambiantes necesidades de los usuarios y el medio
ambiente de trabajo. En el sistema de software ya en producción, y durante los primeros días, los usuarios pueden
detectar fallas, que se pueden corregir durante la etapa de madurez a partir de requisitos más específicos y
precisos, debido al estudio de casos o escenarios.
•El software evoluciona continuamente manteniéndose estable hasta que el sistema ya no sea adaptable, entonces se
llega a la etapa de salida, que se caracteriza porque ya no hay soporte técnico; sin embargo, el software todavía está en
producción. Por último, el sistema es dado de baja, se apaga o se interrumpe y los usuarios son redireccionados hacia el
nuevo. Se va preparando el nuevo, considerando siempre que las necesidades del usuario sean satisfechas. Si se
conocen las leyes de evolución del software, que aunque se aplican a un tipo en particular de sistema, y las etapas de
evolución, se tienen parámetros reales para medir la funcionalidad, determinar cuando ya no da más y sustituirlo a
tiempo antes de perder ventaja competitiva. Antes de que el sistema sea obsoleto es el momento en que entra la
reingeniería de sistemas para identificar el código reutilizable, y tomarlo como base para el nuevo componente, módulo
o sistema.

4. Análisis de
Inventarios
Reestructuración
de documentos
Ingeniería inversa
Reestructuración
de código.
Reestructuración
de datos.
Ingeniería
avanzada.

5. •Se modifico el módulo de “Control de Documentos”, para que este permitiera crear, modificar, publicar, controlar y realizar el seguimiento de la
documentación establecida por la ISO 9001: 2000, para ello se incluyeron las plantillas en ISOxPERT para la creación esos documentos basado
en los formatos ya establecidos en el “Manual para la elaboración de documentos” de PDVSA DN, con la finalidad de facilitarle a los usuarios la
carga de estos y disminuir el tiempo de esa actividad. Las plantillas o formatos que se crearon en el sistema son los siguientes: documentos de
soporte, formato de registro, entre otros , con la finalidad de que los usuarios ejecutaran la actividad de manera más fácilmente.
Rendimiento:
Tiempo límite
excedido
•Se modifico la condición en la que todas las personas cargadas en el sistema para un determinado rol (autor, revisor, aprobador y
publicador), aprobaran o rechazaran conjuntamente el documento para dar continuidad al flujo de trabajo y reducirlo a una sola
persona por rol, lo que permitió agilizar la publicación de documentos y su posterior ubicación el submódulo correspondiente al tipo
de documento. También se incluyó la nueva codificación de los documentos, teniendo en cuenta la organización que desarrollo el
documento, el proceso al que pertenece, el tipo de documento, y el correlativo, el cual se expresa en números desde el 001 hasta el
999 dependiendo del orden de publicación.
Lógico
•Se disponía del módulo de “Registros”, y estaba conformado por cuatro (04) submódulos los cuales eran: otros registros, Agenda -
Minuta, Comunicaciones internas y Buzón de sugerencias ISO, sin embargo, se desactivo “Agenda – Minuta”, ya que se estaba
desarrollando un software específico para esa actividad, por lo tanto este no era funcional para el sistema, a su vez se desarrollaron los
siguientes submódulos: registros de inspección, productos no conformes, planes de adiestramiento, evaluaciones de empleados,
comunicaciones internas, atención al cliente, registro de cliente, registro de proveedores, proyectos ISO, control de diseño y
planificación de proceso, en los que se incluyeron formularios y recursos de imágenes compartido al igual que en el módulo de control
de documentos.
Especificación: De
requerimientos in
correcta o
inadecuada.
•Esos submódulos se desarrollaron con la finalidad de organizar y controlar los registros de manera ordenada de: las inspecciones
realizadas en las áreas operativas y el resultado de estas, los productos no conformes resultado de las auditorias efectuadas en las
organizaciones del distrito, de los planes de adiestramiento para los empleados así como sus evaluaciones, lo relacionado con la
atención al cliente y su respectivo registro así como de los proveedores, los proyectos relacionados directamente con las normas
ISO y el control del diseño del producto.
Mejora: Mejora de
funciones
existentes
Cambios del software de la empresa venezolana Petróleos de Venezuela Sociedad Anónima División Oriente Distrito Norte, con la finalidad de adaptar el sistema
ISOxPERT Bitor al distrito norte, a través de la aplicación de técnicas de reingeniería del software.
El sistema ISOxPERT fue necesario desarrollar los siguientes cambios:

6. El desarrollo de un software lleva consigo mismo un cambio , durante su
puesta en marcha se obtiene varios beneficios pero este no es estático y se
renueva constantemente por diversos necesidades de trabajo, avances de
tecnología o errores que surgen, por consecuencia el software esta sujeto a
cambios entra en un proceso de evolución y nos lleva a invertir en su
mantenimiento. La reingeniria de software es la encargada de aplicar técnicas
, herramientas para ls cambios en el software.

7. • UnADM, (2018), Pruebas y Mantenimiento de Software.
• Tutorial Point, tomado de:
https://www.tutorialspoint.com/es/software_engineering/software_
engineering_overview.htm
• Gascón, Yamila , Lara, Mayra , (2009),San Cristóbal, Venezuela,
Reingeniería del Software a la Herramienta ISOxPERT del Sistema de
Gestión de la Calidad de los Procesos de PDVSA Distrito Norte