Según GOST, esta norma (reeditada en noviembre de 1987) establece el procedimiento para construir y preparar especificaciones técnicas para el desarrollo de un programa o producto de software para computadoras, complejos y sistemas, independientemente de su propósito y alcance.
Debes tener mucho cuidado y cuidado al crearlo, porque… A menudo, una especificación técnica redactada con habilidad (y competencia) determina el éxito de todo el trabajo. Son las especificaciones técnicas las que se acuerdan con el Cliente, quien normalmente se esfuerza por introducir tantos requisitos contradictorios e inflados como sea posible. La tarea del Ejecutor es, por el contrario, hacerle la vida más fácil. Pero una vez que se han colocado las firmas de ambas partes, ya es demasiado tarde para repetir algo.
Disposiciones generales
Los términos de referencia se redactan en hojas de formato A4 y/o A3, por regla general, sin completar los campos de la hoja. Los números de hoja (página) se colocan en la parte superior de la hoja, encima del texto.Para realizar cambios y adiciones a los antecedentes técnicos en etapas posteriores de desarrollo de un programa o producto de software, se publica una adición. Coordinación y aprobación de la incorporación a especificaciones técnicas realizarse en el mismo orden establecido en las especificaciones técnicas.
Los términos de referencia deben contener las siguientes secciones:
- nombre y ámbito de aplicación;
- base para el desarrollo;
- propósito del desarrollo;
- requisitos técnicos para un programa o producto de software;
- indicadores técnicos y económicos;
- etapas y etapas de desarrollo;
- procedimiento de control y aceptación;
- aplicaciones.
Sección: Nombre y alcance
en la sección Nombre y alcance indique el nombre, una breve descripción del ámbito de aplicación del programa o producto de software y el objeto en el que se utiliza el programa o producto de software.En el apartado Bases para el desarrollo se deberá indicar lo siguiente:
- documento(s) sobre cuya base se lleva a cabo el desarrollo;
- la organización que aprobó este documento y la fecha de su aprobación;
- nombre y (o) símbolo temas de desarrollo.
Sección: Objeto del desarrollo
en la sección Propósito del desarrollo Debe indicarse el propósito funcional y operativo del programa o producto de software. Puedes limitarte aquí a una o dos frases. Lo principal es definir claramente para qué sirve este programa.Por ejemplo: el programa es el núcleo de una estación de trabajo automatizada (AWS) para un desarrollador de servicios continuos. sistemas lineales control automático(ACS), permitiendo al usuario resolver problemas de análisis de modelos simples.
Capítulo: Requisitos técnicos para un programa o producto de software.
Esta sección debe contener las siguientes subsecciones: - requisitos de características funcionales;
- requisitos de confiabilidad;
- condiciones de uso;
- requisitos de composición y parámetros medios tecnicos;
- requisitos de información y compatibilidad de software;
- requisitos de etiquetado y embalaje;
- requisitos de transporte y almacenamiento;
- requisitos especiales.
Sección: Requisitos de características funcionales.
Aquí deben indicarse los requisitos para la composición de las funciones realizadas, la organización de los datos de entrada y salida, las características de sincronización, etc.Por ejemplo : El programa debería permitir... calcular... construir... crear...
Datos de entrada: archivo de texto con datos...
Datos de salida: información gráfica y textual - resultados del análisis del sistema...; archivos de texto: informes sobre ... diagnósticos del estado del sistema y mensajes sobre todos los errores que se han producido.
Requisitos de confiabilidad. Se deben especificar los requisitos para garantizar un funcionamiento confiable (garantizar un funcionamiento estable, monitorear la información de entrada y salida, tiempo de recuperación después de una falla, etc.).
Es difícil "adivinar" algo aquí. EN mejor escenario Puede haber una opción en la que su programa funcione solo con datos absolutamente correctos. Normalmente el Cliente no está de acuerdo con esto, pero puedes intentarlo.
Por ejemplo: El programa debe trabajar con una determinada matriz extendida de incidencias del gráfico en estudio de acuerdo con el algoritmo operativo, generar mensajes de error cuando los datos iniciales se especifican incorrectamente y soportar un modo interactivo dentro de las capacidades proporcionadas al usuario.
Condiciones de uso. Se deben indicar las condiciones de funcionamiento (temperatura ambiente, humedad relativa etc. para tipos seleccionados de medios de almacenamiento), que deben garantizar las características especificadas, así como el tipo de servicio, cantidad requerida y calificaciones del personal.
Generalmente no hay dificultades con este punto. Desafortunadamente, la cláusula sobre la profesionalidad del usuario por parte del Cliente está necesariamente implícita. Ésta, por supuesto, es otra razón para criticar su programa. Sin embargo, aquí podemos limitarnos a frases como “Las condiciones de funcionamiento del programa coinciden con las condiciones de funcionamiento de los PC IBM y de los PC compatibles con ellos”, “El programa debe estar diseñado para un usuario no profesional”. etc.
Requisitos para la composición y parámetros de los medios técnicos. indicar composición requerida medios técnicos indicando sus características técnicas.
Lo principal aquí es no olvidar nada y preverlo todo, por un lado (de lo contrario, introducirán una especie de IBM PC/XT con pantalla monocromática y sin ratón), y por otro lado, no Exagere con mayores requisitos; de lo contrario, el Cliente encontrará un Contratista más flexible.
Por ejemplo: debe tener una PC compatible con IBM PC con un adaptador de gráficos EGA (VGA). El espacio en disco requerido es de al menos 600 KB, la cantidad de espacio libre RAM- al menos 400 KB. Es deseable tener un controlador EMS y un manipulador tipo mouse.
Requisitos de información y compatibilidad de software. Las características son las mismas que en el párrafo anterior. Aquí se deben especificar los requisitos para las estructuras de información en la entrada y salida y los métodos de solución, códigos fuente y lenguajes de programación. Cuando sea necesario, se debe garantizar la protección de la información y los programas.
Por ejemplo: El programa debe funcionar de forma autónoma en una versión del sistema operativo MS DOS no inferior a 3.3. El lenguaje de programación básico es Turbo Pascal 6.0.
Los requisitos de etiquetado y embalaje, así como los de transporte y almacenamiento, son bastante exóticos. EN caso general Aquí se indican los requisitos para etiquetar el producto de software, las opciones y métodos de empaquetado. Y los requisitos de transporte y almacenamiento deben indicar para el producto de software las condiciones de transporte, lugares de almacenamiento, condiciones de almacenamiento, condiciones de almacenamiento y períodos de almacenamiento en diversas condiciones.
Los requisitos especiales son algo muy importante. Es mejor evitarlos si es posible. Y declararlo de inmediato.
Por ejemplo: no existen requisitos especiales para las características de tiempo del programa. No existen requisitos especiales para las características capacitivas del programa.
Indicadores técnicos y económicos. Este punto más difícil para un programador no siempre está ahí. Es necesario principalmente cuando su objetivo es justificar la enorme eficacia e importancia del trabajo que se está realizando. Este artículo suele funcionar muy bien para el Cliente. Como mínimo, esta es la mejor justificación para el momento y los montos monetarios del desarrollo.
Esta sección debe indicar: aproximado eficiencia económica, necesidad anual estimada (por ejemplo: número esperado de llamadas al complejo en su conjunto por año: 365 sesiones de trabajo), ventajas económicas del desarrollo en comparación con las mejores muestras o análogos nacionales y extranjeros.
Además, es aconsejable proporcionar una definición tanto del costo estimado del desarrollo del programa como de la complejidad de la programación.
Las etapas y fases de desarrollo (esto se discutirá con más detalle a continuación) establecen las etapas necesarias de desarrollo, etapas y contenido del trabajo (una lista de documentos del programa que deben desarrollarse, acordarse y aprobarse), así como, como regla, plazos de desarrollo y determinación de los artistas intérpretes o ejecutantes.
Los pasos estándar se describen aquí. Lo principal es determinar correctamente el momento. Si es posible, intente distribuir uniformemente las etapas según los plazos (y los montos). Recuerde que no todos los proyectos sobreviven última etapa. Y debería haber informes para cada etapa. Recuerde también que el proyecto de trabajo será el que más tiempo llevará. Si no completa la documentación a tiempo, el Cliente tiene todo el derecho a no aceptar el trabajo en absoluto con todas las consecuencias consiguientes.
Las etapas y pasos principales e indispensables son los propios términos de referencia, diseño preliminar, proyectos técnicos y de trabajo.
Anteproyecto de diseño. En esta etapa, se desarrollan en detalle las estructuras de los datos de entrada y salida y se determina la forma de su presentación. En desarrollo descripción general algoritmo, el algoritmo en sí, estructura del programa. Se está desarrollando un plan de acción para el desarrollo e implementación del programa.
Proyecto técnico. Contiene un algoritmo desarrollado para resolver el problema, así como métodos para monitorear la información inicial. Aquí se desarrollan herramientas para procesar errores y emitir mensajes de diagnóstico, se determinan formularios para presentar datos iniciales y la configuración de medios técnicos.
Borrador de trabajo. En esta etapa se lleva a cabo la programación y depuración del programa, el desarrollo de documentos del programa, programas y métodos de prueba. Se están preparando ejemplos de prueba y depuración. Se ultima la documentación y el material gráfico. Se suele especificar que durante el desarrollo del programa se debe preparar la siguiente documentación:
Texto del programa;
Descripción del programa;
Programa y metodología de prueba;
Descripción de la aplicación;
Manual de usuario.
Estos son requisitos estándar. Si el Cliente acepta que no se puede presentar toda esta lista, significa que sus intenciones con respecto a usted y su producto no son serias.
Puede que no haya ningún material gráfico. Especialmente cuando no vas a informar de los resultados de tu trabajo. Pero para proyectos serios se requiere este artículo.
Por ejemplo: Durante el desarrollo del programa se deberá preparar el siguiente material gráfico:
Indicadores técnicos y económicos;
Estructura del programa;
Formato para presentar datos de entrada del programa;
Diagrama de algoritmo general (2 hojas);
algoritmos computacionales básicos;
Un ejemplo de cómo funciona el programa.
La sección de Procedimiento de Control y Aceptación deberá indicar los tipos de pruebas y requisitos generales para la aceptación del trabajo. Si es posible, en este párrafo indique que “el control y la aceptación del desarrollo se lleva a cabo utilizando el equipo proporcionado por el Cliente”, de lo contrario, es posible que deba traer el equipo con usted.
Por ejemplo: el control y la aceptación del desarrollo se llevan a cabo sobre la base de pruebas de prueba y ejemplos de depuración. Esto verifica la ejecución de todas las funciones del programa.
En los Anexos a las especificaciones técnicas, si es necesario, se proporciona lo siguiente:
una lista de investigaciones y otros trabajos que justifiquen el desarrollo;
Diagramas algorítmicos, tablas, descripciones, justificaciones, cálculos y otros documentos que puedan utilizarse durante el desarrollo;
Otras fuentes de desarrollo.
La subsección “Requisitos de información y compatibilidad de software” debe indicar los requisitos de estructuras de información en los métodos de entrada y salida y solución, códigos fuente, lenguajes de programación y software utilizados por el programa. Cuando sea necesario, se debe garantizar la protección de la información y los programas.
Ejemplo. La computadora debe ejecutar un sistema operativo no inferior a Windows 98/NT 4.0. Requisito compatibilidad de información debe garantizarse trabajando con archivos de información geométrica de una determinada estructura como información de entrada y salida.
Fin del trabajo -
Este tema pertenece a la sección:
Tecnología de desarrollo de software
En el sitio web se lee: "Tecnología de desarrollo de software"...
Si necesitas material adicional sobre este tema, o no encontraste lo que buscabas, te recomendamos utilizar la búsqueda en nuestra base de datos de obras:
Qué haremos con el material recibido:
Si este material te resultó útil, puedes guardarlo en tu página en las redes sociales:
| Piar |
Todos los temas de esta sección:
Requisitos funcionales
La subsección "Requisitos para las características funcionales" debe indicar los requisitos para la composición de las funciones realizadas, la organización de los datos de entrada y salida y las características temporales.
Acuerdo de requisitos
Elaborar un acuerdo de requisitos es el objetivo de la segunda parte de la primera práctica de laboratorio. Además, el acuerdo sobre los requisitos es la segunda sección del trabajo del curso.
A continuación se muestra la operación.
Breve descripción del producto. Descrito brevemente y conceptos generales
Principales propiedades funcionales del producto. Si un producto de software es una extensión de uno existente, sólo se caracterizan sus nuevas características.
Componentes del producto resultante
Esta sección proporciona una tabla similar o equivalente a la Tabla 2.1. En este caso, se utiliza un formulario impreso preparado previamente, lo que reduce el tiempo de preparación de la información.
Solicitudes rechazadas Si el objetivo es reelaborar o mejorar un producto, o reemplazar un producto con errores conocidos, se deben hacer planes para corregir los errores encontrados en el producto. en este momento
tiempo. Por lo tanto, en este punto
Elementos del plan excluidos
Si hay instrucciones de planificación que requieren funciones y capacidades de software especiales que no se pueden proporcionar si el producto se desarrolla de acuerdo con otros requisitos.
Si la necesidad de crear un producto está justificada por un documento como un plan de lanzamiento del producto, un plan de lanzamiento en serie o una descripción de la tarea, entonces se cita un pasaje específico de cada documento, o
Lista de requisitos del usuario
Se indica a los clientes del producto y se explica por qué lo necesitan. Esta sección también indica el período previsto de uso del producto. Generalmente esta será la vida útil del equipo.
Alternativas consideradas
Se describen brevemente las alternativas a este diseño que fueron consideradas y rechazadas, así como los motivos del rechazo. Si se deben comprar programas, se explica por qué no lo son.
Retorno de la inversión
La ganancia que dará la creación del producto se determina en términos correspondientes a propósito previsto organizaciones.
Ejemplo. ABC Services espera que las ventas en Finlandia aumenten
software del sistema Sistémico software - Este es todo el resto del software, incluidos sistemas operativos, compiladores, utilidades y paquetes. programas de aplicacion
etc. Es software
Características generales de las funciones
Es necesario considerar todo el producto como un módulo funcional para que el número de subsecciones sea pequeño. Si es imposible describir adecuadamente el producto sin dividirlo en funciones funcionales separadas.
Restricciones externas
Se enumeran todas las restricciones cuyo alcance es más amplio que el alcance del ST; Esto incluye, por ejemplo, restricciones industriales o de línea de productos. puede estar permitido
Restricciones de compatibilidad
Siempre se deben considerar varios aspectos de la compatibilidad: lenguaje de origen, lenguaje de máquina, formatos de datos y mensajes, formatos de informes, formatos de listado y formatos de lenguaje de control de trabajos (JL).
Limitaciones del software
Indique, si es necesario, el sistema operativo con el que debe funcionar el producto de software propuesto, así como otro software con el que debe interactuar en el proceso.
Limitaciones de hardware
Se proporciona una tabla de dispositivos utilizados en el funcionamiento del producto de software. Para cada dispositivo se indica el número mínimo, nominal y máximo requerido. nominal es óptimo
Resultados del trabajo
Todos los datos de salida de un producto de software o módulo funcional se describen en términos de su contenido y propósito: informes, archivos, registros, campos de datos, mensajes, tablas, casillas de verificación. Debería
Describe las operaciones realizadas por un producto de software, que se considera en su conjunto o módulos funcionales como una caja negra (o un conjunto de cajas negras). Como mínimo, habiendo instalado
Fiabilidad
La confiabilidad del software se refiere a la capacidad de recuperar funcionamiento normal en caso de errores y mal funcionamiento del equipo. La protección de los datos de los usuarios es de suma importancia. SL
Reanudar
Se indican capacidades para garantizar que los datos se guarden y utilicen al reanudar el trabajo después de una interrupción de emergencia, por ejemplo, al reiniciar desde un punto de control.
Ejemplo 1. Programa
Satisfacer los requisitos del cliente
Se especifican las propiedades que permiten que un producto de software o su salida satisfaga requisitos específicos. Enumera, si es posible, los módulos que pueden no satisfacer los requisitos.
Características de rendimiento
Se da la variable principal o principio básico por el cual se debe medir la efectividad del programa; especifica el valor o rango de valores apropiado para esa variable. gl
Facilidad de uso
Se describen las propiedades que hacen que la interacción "hombre-máquina" sea conveniente para los humanos. Algunos ejemplos son formato de entrada libre, modo de diálogo, compatibilidad sintáctica, posible
Facilidad de mantenimiento
Se describen medidas para garantizar que los módulos sean identificables si la norma no aborda este problema.
Ejemplo 1. Cada módulo fuente y objeto se suministrará con un cifrado de software
Reiniciar la interfaz de usuario
Ejemplo. El estado del sistema para todos los usuarios activos (incluidos aquellos desconectados, pero que aún reciben servicio) se almacena periódicamente en el disco (en un intervalo especificado dentro de la definición de tiempos
Funciones de la interfaz de usuario
Ejemplo. Suponiendo que solo se ejecuta ASK en la computadora y que el parámetro de recuperación se caracteriza por un punto de control por minuto, cada comando debe ejecutarse o
Alcance de la interfaz de usuario
Ejemplo. En una sesión típica con ASK, un usuario sin experiencia en programación se conecta al sistema mediante un terminal y entabla un diálogo en el que define:
Indique, si es necesario, el sistema operativo con el que debe funcionar el producto de software propuesto, así como otro software con el que debe interactuar en el proceso.
Ejemplo. Además de los dispositivos necesarios para VSOS ILSAM (consulte la sección 2.4.1, b y c), el procesador de corrección necesitará los dispositivos enumerados en la Tabla 2.3.
Tabla 2.3 - Dispositivos
Restricciones internas
Es importante determinar no sólo cuál será el producto, sino también qué no será. Una restricción es una propiedad (o capacidad) que el usuario lógicamente esperaría, pero que
Documentos de referencia
Cada documento urbanístico o técnico al que se hace referencia en la ST se indica por separado. Cada uno de estos documentos debe existir realmente (y no estar implícito en el futuro) y
Recursos para apoyar la implementación
Se determinan los recursos necesarios para instalar el sistema, junto con los recursos descritos en el apartado 2.5.3 (aquí nos referimos a tiempo de máquina, costes de mano de obra y las cualificaciones necesarias).
Medios de almacenamiento
El tipo de dispositivo de almacenamiento se determina para todos los componentes distribuidos del producto de software (por ejemplo, cinta magnética, caracterizada por el número de pistas y la densidad de grabación).
Relaciones requeridas Se determinan los requisitos que plantea este producto de software a otros proyectos o funciones. Dado breve descripción
cada requisito e indica la etapa en la que se puede establecer
Interconexiones admitidas
Esta sección es similar en estructura a la anterior, pero contiene requisitos impuestos por otros productos a este producto. Cada requisito de la sección 2.6.1.2 debe cumplirse mediante un requisito
Comisión Técnica de Auditoría
Cada ST deberá recomendar la creación de una comisión técnica de auditoría (CTR), indicando el lugar de trabajo de cada miembro de la comisión y su nombre, de ser posible, así como el nombramiento.
Niveles de prueba
Las pruebas de programas se pueden organizar en tres etapas, llevarse a cabo en tres modos y tener diez categorías (consulte la sección 5 “Pruebas”). Esta información se presenta en forma de tabla. para ka
Estándares para comparar
Se determinan los sistemas de referencia con los que se realizará la comparación. Las características de este sistema se indican en unidades relativas. Si no hay un estándar para comparar
Aviso de cambio de fechas del calendario
Ejemplo. Nombre del proyecto: ASK desarrollo de producto Código del proyecto: C013. Código de producto: L301A.
Nombre del producto: PREGUNTE
Especificaciones de escritura
La fase de prueba suele representar la mitad del coste financiero de creación del sistema. Las pruebas mal planificadas provocan un aumento significativo del tiempo de desarrollo.
Organización de pruebas de productos de software.
Probar no significa depurar, diseñado para determinar por qué ocurre un error particular en un programa y eliminar sus causas, sino el proceso de establecer el hecho mismo de la presencia de defectos.
Tipos de pruebas de productos de software. Etapas de prueba
En general, las pruebas se realizan en varias etapas, separadas por tiempo.
La primera etapa incluye pruebas Clase A, que se realizan al final de la fase de programación.
Modos de prueba del programa
Las pruebas varían dependiendo de quién las realiza. La idea principal es la independencia de la función de prueba de la función de desarrollo.
Modo de prueba I implica completo
Categorías de prueba de productos de software
Las etapas de la prueba indican cuándo se realizan las pruebas y los modos determinan quién las realiza. Las categorías de pruebas establecen la naturaleza y el propósito de las pruebas. División reflexiva y
Tecnología de prueba, clases de equivalencia.
Una forma de explorar esta cuestión es explorar una estrategia de prueba llamada prueba de caja negra, prueba basada en datos o testo.
Pruebas de construcción
El proceso de construcción de la prueba incluye: 1) asignar un número único a cada clase de equivalencia;
2) diseñar nuevas pruebas, cada una de las cuales cubra
Disposiciones generales 1.1. La estructura y formato del documento se establecen de acuerdo con GOST 19.105-78. 1.2. El manual del programador del sistema debe contener las siguientes secciones: –
Estructura del programa
Programa "Automatizado lugar de trabajo Reader" consta de los siguientes componentes: 1) zcon: una aplicación que implementa las funciones del cliente Z39.50; 2) zgate -CGI- Instalando el programa
Este documento utiliza la sintaxis definida en ISO/IEC 9945-1 para nombrar archivos. en esos
sistemas operativos
, que no soportan
método especificado nombrar archivos en aplicaciones Comprobando el programa El programa se verifica por el método de su ejecución. Debido a que las condiciones específicas para el uso del programa (direcciones de servidores Z39.50, nombres de bases de datos, puntos soportados
Mensajes al programador del sistema.
La Tabla 5.1 muestra los mensajes que se pueden recibir programador del sistema durante la configuración, prueba del programa, así como el usuario durante la ejecución del programa.
El sistema de software debe proporcionar protección de datos contra eliminación y modificación accidentales. Sólo un administrador de base de datos autorizado o un miembro del personal docente que haya iniciado sesión en el servidor de la base de datos y tenga las funciones adecuadas debe tener acceso a los datos.
Para que sea fiable, el sistema de formación debe cumplir los siguientes requisitos:
el programa desarrollado debe tener medios de protección contra acciones erróneas del usuario;
todos los errores deben mostrarse con comentarios o sugerencias para eliminarlos;
garantizar la seguridad de los datos en caso de fallos en el funcionamiento de dispositivos externos.
Para mejorar la confiabilidad, se deben tomar las siguientes medidas:
configurar hardware y software de acuerdo con los requisitos técnicos;
realizar copias de seguridad periódicas de la información;
comprobar periódicamente la integridad de la base de datos;
Mantener la salud de los equipos de red.
Requisitos para la composición y parámetros de los medios técnicos.
La configuración mínima de hardware del sistema para garantizar el normal funcionamiento del sistema de formación no debe ser inferior a la siguiente:
RAM 128 MB o superior.
Al menos 150 MB de espacio libre en el disco duro.
Requisitos para la computadora utilizada para desarrollar configuraciones:
Procesador AMD Athlon de 900 MHz o superior.
RAM 256 MB o superior.
Al menos 250 MB de espacio libre en el disco duro.
Cuando se utiliza un sistema automatizado en una red local, el servidor Firebird1.5.3 con una base de datos preinstalada debe estar instalado y ejecutándose en una de las computadoras. En otras máquinas, es necesario instalar la aplicación cliente del sistema de contabilidad del equipo.
Requisitos de información y compatibilidad de software.
Para operar el producto de software, debe tener los siguientes componentes:
Sistema operativo de la familia Microsoft®Windows® (al menos 2000).
Productos de software instalados y configurados MicrosoftSQLServer, IBExpert2004, Borland®C++Builder™ 6.0, Microsoft.NETFrameworkSDKv2.0.
condiciones de uso
El programa debe ejecutarse en un hardware que funcione. Los requisitos para las condiciones de funcionamiento de la PC y otros equipos utilizados en el complejo se establecen en los documentos técnicos incluidos en el paquete de entrega de los dispositivos.
Requisitos para la documentación del software.
La documentación del programa debe incluir los siguientes documentos.
Guía del administrador del sistema.
Guía del profesor.
Guía del alumno.
La guía del administrador del sistema debe incluir descripciones de las características de configuración de este sistema.
El sistema de software debe incluir un manual completo del instructor que describa escenarios para el trabajo del instructor.
El sistema de software debe incluir un manual completo del alumno que describa los escenarios de trabajo del alumno.
Etapas del desarrollo de un sistema de software.
El desarrollo de un sistema de software debe organizarse dentro de las siguientes etapas.
desarrollo de un plan de implementación;
desarrollo de un plan de prueba;
desarrollo de un plan de implementación.
Diseño:
diseño lógico de arquitectura de sistemas de software;
desarrollo de estructura de base de datos;
diseño de interfaz de usuario.
Implementación:
implementación de la interfaz de usuario desarrollada;
Implementación de las principales funciones del sistema de software.
Pruebas del sistema:
pruebas estructurales;
pruebas funcionales;
correcciones de errores y mejoras.
Implementación del sistema:
comprobar la disponibilidad del equipo necesario;
instalación del sistema;
formación del personal.
Mantenimiento del sistema.
A petición del cliente, este software está desarrollado para la plataforma Windows. El programa debe funcionar bajo las principales versiones de esta plataforma: Windows98, Windows 2000, Windows XP. Además, la parte del servidor del programa para las versiones WinNT debería funcionar como un servicio (funcionar en segundo plano).
Es necesario garantizar la posibilidad de ampliar aún más las funciones del sistema (apertura al desarrollo y métodos para conectar nuevas tareas).
Requisitos de transporte y almacenamiento.
El sistema de gestión que se está desarrollando se suministrará como un kit cuando se venda el controlador RAID. Debe grabarse en un CD aparte, que contendrá los controladores del sistema y la documentación necesaria para el controlador que se vende. Para hacer esto, debe asegurarse de que el tamaño de los archivos de instalación no supere aproximadamente 2/3 de un CD estándar (700 MB).
Requisitos especiales
La parte del servidor del programa, que analiza el funcionamiento de RAID, debe ejecutarse siempre en un ordenador con sistema RAID. Si se detiene este módulo, sin él será imposible conectarse al sistema RAID y será imposible monitorear el funcionamiento del RAID (enviar notificaciones de fallas y mantener archivos del historial de operaciones del RAID).
Diagrama de bloques del programa.
Todo el proyecto de software se basa en dos módulos independientes. Como ya se mencionó, uno de ellos se ejecuta por separado en una computadora con sistema RAID y el segundo en la computadora del administrador. Por brevedad, llamaremos al primer módulo Agente, y el segundo – Gerente.
Gerente– el lado del usuario del programa, que contiene la interfaz del programa, el asistente de instalación inicial y la sección de ayuda. Gerente gestionará el sistema RAID a través de Agente.
Agente Sirve principalmente para transmitir comandos desde Gerente Sistema RAID y viceversa. También Agente supervisará RAID (mantendrá un archivo de registro) y notificará al administrador en caso de errores.
Neto
Arroz. 1.2. La estructura básica del programa GUIRAIDManager.
La estructura básica del trabajo en su conjunto se presenta en la Fig. 1.2. Muestra diferentes opciones sobre cómo funcionan los dos módulos. Agente Y Gerente:
Agente(do3 ) se inicia en la computadora y analiza el funcionamiento de la matriz RAID R2 ;
Gerente Con computadora remota (C2 o C4) se puede conectar a través de una red a A gentom(C3) para controlar el funcionamiento de la matriz RAID R2 ;
Gerente Y Agente iniciado en una computadora C1 para controlar el funcionamiento de la matriz RAID R2 . Con esta opción, no se requiere conexión de red.
Estructura de datos de entrada y salida.
El principal intercambio de datos en el sistema en su conjunto se produce a través de dos canales:
entre Gerente Y Agente a través de la red utilizando el protocolo TCP/IP (comandos Gerente y respuestas Agente);
entre Agente y un controlador RAID a través de la interfaz RS-232 (encuesta del controlador y respuestas del mismo).
El esquema general de intercambio de datos en el proyecto se ilustra en la Fig. 1.3.
Arroz. 1.3. Intercambio de datos en el programa GUIRAIDManager
Formato de datos entre Gerente Y Agente, y también entre Agente y el controlador RAID se describe en el párrafo “Formato de datos del módulo Agente» de esta sección.
Mi tarea en este proyecto es desarrollar un módulo Agente. Por lo tanto, echemos un vistazo más de cerca al intercambio de datos en el módulo. Agente entre Gerente y un controlador RAID. Estructura modular Agente mostrado en la Fig. 1.4
Arroz. 1.4. Intercambio de datos en el módulo Agente
Este diagrama muestra que los datos entre Gerente Y Agente pasar a través del módulo para recibir y transmitir datos a través de la red. Para comprobar la conexión Gerente Este módulo utiliza un bloque de autorización. Todos los datos recibidos se analizan en el bloque del procesador de comandos. Gerente. Dependiendo del tipo de comando, la información va al bloque de configuración, al bloque del archivo histórico o al módulo de sondeo de estado RAID. Este último sirve para enviar comandos al controlador RAID y recibir respuestas del mismo. Si ocurre un error durante la solicitud o la respuesta del controlador contiene un mensaje crítico, el módulo de notificación notificará al administrador sobre este error.