DISEÑO Y DESARROLLO DE SOFTWARE Proceso de Análisis, Proceso de Diseño y Proceso de prueba y mantenimiento

El proceso de la ingeniería de sistemas. Consta de los siguientes pasos.

Es una actividad interdiciplinaria que conjunta equipos de personas con diferentes bases de conocimientos. Los equipos de ingeniería de sistemas son necesarios debido al amplio conocimiento requerido para considerar todas las implicaciones de las decisiones en el diseño de sistemas.

Las definiciones de requerimientos del sistema especifican qué es lo que el sistema debe hacer (sus funciones) y sus propiedades esenciales y deseables.

Definición de requerimientos. En esta fase usualmente se concentran en la derivación de 3 tipo de requerimientos:

Relaciona la descripción correcta de cada uno de los tipos de requerimientos. 1.- Requerimientos funcionales abstractos. 2.- Propiedades del sistema. 3.- Características que no debe mostrar el sistema. a.- Estas son propiedades emergentes no funcionales del sistema, tales como la disponibilidad, el rendimiento y la seguridad. b.- En un sistema de control de trafico aéreo, especificaría que una BD del plan de vuelo debe usarse para almacenar los planes de vuelo de todos los aviones que entran al espacio aéreo controlado. c,.- Si esta especificando un sistema de control de trafico aéreo, puede especificar que el sistema no debe presentar demasiada información al controlador.

Es tan complejo y en el que hay tantas entidades relacionadas que no existe una especificación definitiva del problema. Un ejemplo extremo es la previsión de terremotos.

El diseño de Sistemas, se centra en proporcionar la funcionalidad del sistema a través de sus diferentes componentes. Las actividades que se realizan en este proceso son:

Relaciona la descripción correcta de cada uno de los procesos del Diseño de sistemas: 1.- Dividir requerimientos 2.- Identificar subsistemas 3.- Asignar requerimientos a los subsistemas 4.- Especificar la funcionalidad de los subsistemas 5.- Definir las interfases del subsistema. a.- Una vez que estas interfaces se han acordado, es posible desarrollar estos subsistemas en paralelo. b.- Debe enumerar las funciones especificas asignadas a cada subsistema. También debe intentar especificar las relaciones entre los subistemas en esta etapa. c.- Esto debe ser sencillo si la división de requerimientos se utiliza para la identificación de subsistemas. No existe igualdad entre las divisiones de requerimientos y la identificación de subistemas. d.- Identificar los diferentes subsistemas que pueden individual y colectivamente, cumplir los requerimientos. De tal forma que esta actividad y la de división de requerimientos se puede fusionar. e.- Analice los requerimientos y organícelos en grupos afines.

Es una seria esencial de pasos que ayuda a asegurar la calidad del eventual sistema.

Antes de que el sistema se ponga en producción, todos los programas se deben verificar en el escritorio, verificar con datos de prueba y verificar para ver si los módulos trabajan entre sí como se planeó.

Cumplen un papel diferente en los varios aspecto a probar. Las pruebas de hardware normalmente se proporcionan como un servicio por los vendedores de equipo quienes ejecutaran sus propias pruebas en el equipo cuando se libere en el sitio.

El analista de sistemas sirve como consejero y coordinador para las pruebas del programa. El analista trabaja para asegurar que los programadores implementen las técnicas de prueba correctas pero probablemente no desempeñe personalmente este nivel de verificación. En esta fase, los programadores primero deben hacer pruebas de escritorio de sus programas para verificar la forma en que funcionará el sistema. El analista normalmente no recomendara o creará datos de prueba para las pruebas de programas pero podría señalar al programador las omisiones de tipos de datos a ser agregados en pruebas posteriores.

Cuando los programas pasan la verificación de escritorio y la verificación con datos de prueba, se deben pasar por las pruebas de vínculos, que también se conocen como prueba de cadena. Estas pruebas verifican si los programas que realmente son independientes trabajan juntos como se planeó. El analista crea datos de prueba especiales que cubren una variedad de situaciones de procesamiento para la prueba de vinculación.

Cuando las pruebas de vinculación se concluyen satisfactoriamente, se debe probar el sistema como una entidad completa. En esta fase, los operadores y los usuarios finales se involucran activamente en la prueba.

Existen varios factores a considerar cuando se prueban los sistemas con datos de prueba: 1.- Examinar si los operadores tienen la documentación adecuada en los manuales de procedimiento. 2.- Verificar si los manuales de procedimientos son lo bastante claros como para comunicar como se deben preparar los datos para la entrada. 3.- Determinar si los flujos de trabajo necesarios para el sistema nuevo o modificado realmente "fluyen". 4.- Determinar si la salida es correcta y si los usuarios entienden que esta salida es como se verá en su formulario final.

Cuando las pruebas de sistemas con datos de prueba se realizan de manera satisfactoria, es bastante recomendable probar el nuevo sistema repetidas veces con lo que se conoce como datos reales, datos que se han procesado de manera exitosa con el sistema existente. Sólo se usan pequeñas cantidades de datos reales en este tipo de prueba de sistemas.

Lo mejor y más fácil del diseño de sistemas será asegurar que el negocio tendrá que gastar menos dinero en el mantenimiento. Reducir los costos de mantenimiento es una consideración principal, debido a que el mantenimiento de software aislado puede consumir más de 50 % del presupuesto de procesamiento de datos para el negocio. Los costos de mantenimiento excesivos se reflejan directamente en el diseñador del sistema, debido a que aproximadamente 70 % de errores de software se han atribuido al diseño de software inadecuado. Detectar y corregir a tiempo los errores de diseño de software es menos costoso que permitir que permanezcan inadvertidos hasta que sea necesario el mantenimiento.

Auditar es otra forma de asegurar la calidad de la información contenida en el sistema. Auditar se refiere a pedirle a un experto, que no este involucrado en crear o usar un sistema,examinar la información para determinar su fiabilidad.

Generalmente hay dos tipos de auditores para los sistemas de información: interno y externo. Determinar si ambos son necesarios para el sistema que usted diseña, dependerá de que tipo de sistema es. Los auditores internos trabajan para la misma organización que posee el sistema de información, mientras que los externos se contratan por fuera.