¿Por qué exactamente el hospital?

Por que no Este es un buen ejemplo. El proyecto está en todas partes: más o menos las mismas etapas, el mismo esquema de gestión, gestión de documentos, gestión de riesgos, control de calidad, etc. En todas partes hay requisitos para equipos, instalaciones y software. Usted pregunta, ¿cuáles pueden ser los requisitos para locales en el Sistema de Información? Es muy simple: la ubicación de las estaciones de trabajo del operador, el servidor, ambos requieren aire acondicionado. Aquí están los requisitos para las instalaciones. Y casi nadie duda ahora si el hospital necesita software. Si desea mantenerse al día, se enfrentará a la tarea de crear una institución médica automatizada con registros médicos electrónicos, donde los médicos realicen un examen con tabletas y, por ejemplo, las enfermeras marquen el inodoro lavado no en la sábana, sino en el teléfono. Habrá muchos requisitos de software en este caso. Y tan pronto como se necesite el software, será necesario instalar el servidor, colocar al administrador y los operadores en algún lugar. Todo esta interconectado.

Elegimos un proyecto de construcción porque es más fácil demostrar cómo diseñar una IP. El sistema de información está oculto en algún lugar del interior, no lo vemos, y las paredes están aquí frente a nosotros: curvas y oblicuas, con pasillos sin salida, porque el proyecto se realizó en la rodilla y el cliente cambió sus requisitos cien veces durante la obra.

Código de programa dentro (pero nadie lo ve)

¿Qué tiene que ver un hospital si desarrollamos software?

Y aquí está, queridos desarrolladores, ejecutivos, analistas, probadores.

No es el software que estás desarrollando ... Toma Android, este es un software. Y si, por ejemplo, tiene un sistema de contabilidad, entonces ya no se trata solo de software, sino también de un SISTEMA DE INFORMACIÓN.

La diferencia es obvia. Si compró un teléfono, todo es simple: enciéndalo, se inicia un hombre verde (Android), úselo. Y si compró una caja con software de contabilidad, está claro que ahora necesita servidores, debe configurar la red, configurar las estaciones de trabajo, capacitar a los empleados, integrar el sistema con otras IP de la empresa y conducir el sistema en modo de prueba. Sí, y los contadores deben ser persuadidos de alguna manera para que cambien al nuevo software, no todos están listos para las innovaciones. En general, en cualquier proyecto de TI, 10-20% es TI, y todo lo demás son medidas organizativas y administrativas, bueno, muy denso, joyas, trabajo con el personal.

Sistema de información (¿es solo software?)

Y finalmente, recordamos la definición de un sistema de los 90 distantes, que nadie ha cancelado:

Sistema automatizado: un sistema que consiste en personal y un conjunto de herramientas de automatización para sus actividades que implementa tecnología de información para realizar funciones establecidas.

GOST 34.003-90. Tecnología de la información. Un conjunto de estándares para sistemas automatizados. Sistemas automatizados. Términos y definiciones.

Es decir, la IP en primer lugar son las personas, además de la tecnología que ayuda a automatizar sus actividades, y no al revés.

Cómo diseñar un hospital

Imagine que es una organización de construcción, un cliente acude a usted y le pide que construya un hospital en ese lugar. ¿Corres inmediatamente a poner ladrillos o ...? Si observa con qué frecuencia se crean los sistemas de información, entonces lo es: los artistas comienzan inmediatamente a "interferir con el concreto y comprar paquetes de vidrio". Al igual, no funcionará de esa manera: ¡reconstruiremos! Vamos a reconstruir hasta lograr el resultado deseado.

Sin embargo, si usted es una organización seria, primero ofrezca al cliente un DISEÑO para la construcción. Estas de acuerdo ¿Y por qué está mal con el sistema de información? Tal vez no sea la diferencia entre la construcción y el desarrollo de software, pero ¿en el caso del mismo hospital, piensan mucho, planifican y luego construyen, y primero desarrollan y luego piensan en software? ¿No es por eso que escuchas mucho sobre los programadores krivoruky, pero nada sobre los mismos trabajadores migrantes en un sitio de construcción? Los constructores trabajan en el proyecto, a diferencia de los desarrolladores.

Siempre es así sin un proyecto, incluso si no es visible

Ahora consideramos el proceso de diseño con más detalle. Tiene varias etapas. ¿Por qué necesitamos pasar por varias etapas, por qué no hacerlo al mismo tiempo? Para mayor claridad, daré un ejemplo escolar ... ¿Cuántos años en la escuela han estado estudiando la operación de multiplicación? Dices uno o dos meses y estarás fundamentalmente equivocado. Sí, cómo multiplicar 5 por 6, pasar en una semana. Un cierto tiempo se enseña la tabla de multiplicar. Y la multiplicación de fracciones, números con un grado, logaritmos, expresiones entre paréntesis, números complejos, elevar hasta cierto punto ¿cuántas personas estudian? ¡Casi todos los años escolares! Resulta que estudiamos la misma multiplicación cada año desde diferentes ángulos.

¿Y por qué no se estudia esto en primer grado?

Por lo tanto, cualquier proceso de aprendizaje y diseño es cíclico. Primero, obtuvimos conceptos generales sobre números, luego aprendimos cómo realizar acciones simples con ellos, luego aprendimos sobre fracciones y aprendimos cómo trabajar con ellos, y así sucesivamente.

Primero, nos dimos cuenta de qué problema debería resolverse con la ayuda del Sistema de Información. Luego determinamos el círculo de tareas a resolver, entendimos qué debe hacer el sistema, qué acciones debe llevar a cabo el personal. Luego pensaron en CÓMO el sistema debería cumplir con las tareas definidas anteriormente. Puede omitir estos pasos, solo tiene que regresar y rehacer todo: mida siete veces y corte una vez mucho más rápido que viceversa, y quedará menos material.

Damos otro ejemplo. Estás en la cima de la montaña mirando hacia abajo con binoculares fuertes y tratando de hacer una ruta de descenso detallada. En los oculares, puedes ver cada piedra en el camino, cada charco. Pero aquí está este camino y si no conduce a la cima con binoculares no es visible: no hay un plan general. Un escalador razonable primero describirá los senderos de descenso a simple vista, y luego los examinará con un gran aumento. Tan pronto como te sumerjas en los detalles, pierdes tu visión general del proyecto. Tomando el catalejo de inmediato, lo ideal es describir 10 funciones, mientras se olvida de las otras 40 y, en general, no las menciona.

Se puede ver bien, pero solo una pequeña parte

La complejidad del diseño por fases es que al comienzo del proceso debe operar con conceptos abstractos. Así que quiero "sentir" algo listo, y no hablar sobre ciertos requisitos, funciones, tareas, procesos. Dibujar una interfaz de usuario de inmediato es más simple, pero también es más fácil omitir al menos la mitad de los requisitos. Si al principio hacemos una lista detallada de las operaciones que el usuario debe realizar cuando trabaja con una u otra forma de pantalla, entonces el diseñador solo tendrá que dibujar y no fantasear, como suele ser el caso.

Ahora finalmente pasar a las etapas de diseño.

1. Elaboración de requisitos generales

Entonces, digamos que eres un diseñador. Un cliente llega a usted, "enviado" por constructores responsables. El cliente naturalmente le pide que desarrolle un proyecto hospitalario. Corres al Kuhlmann y ... Bueno, esto es antigüedad: inicia ArchiCAD y dibuja.

Pero, por supuesto, no se trata de ti. Eres un profesional y comienzas a hacer un montón de preguntas "estúpidas". Y el más importante de ellos: ¿por qué necesita construir un hospital? ¿Cuál es el propósito de la construcción? Si el objetivo no está claro, entonces no podrá responder la pregunta, si se trata de un hospital grande o pequeño, de qué perfil, que equipado. Desafortunadamente, los clientes a menudo dicen muchas cosas interesantes, excepto lo principal: cuál es su propósito. Aquí es necesario "sacar" de ellos en primer lugar. Y deberías hacer una pregunta. El cliente mismo no es un especialista, tiene una idea y sobre esto ve cumplido su papel. No entiende qué camino se necesita para realizar su idea. Como regla general, el cliente espera un viejo milagro: venir a la orilla del mar, arrojar una red (pagar dinero), pescar y ella cumplirá su deseo ... Pero sucede como en una broma sobre un hombre rico que, después de atrapar un pez dorado, pidió cumplir un deseo: " ¡Quiero que todo esté conmigo! "No hay problema", respondió el pez, "tenías todo ..."

Para comprender el objetivo del proyecto, no es suficiente hacer un par de oraciones con un conjunto estándar de frases. El objetivo de un proyecto generalmente se determina en base a la oposición: describen el modelo de información existente (por ejemplo, las personas están sentadas en el archivo y clasificando los documentos), luego sus deficiencias (debido a la falta de automatización, 10 personas están involucradas en el archivo, lo que es claramente redundante, otros departamentos no pueden recibir durante semanas del archivo, la información que necesitan, etc.) y ofrecer una solución (para introducir un software que permita llevar a cabo una serie de operaciones en modo automatizado, las operaciones deben estar enumeradas). Si se introduce un tipo de servicio completamente nuevo en el mercado, entonces es necesario estudiar el mercado existente y "criticar" las herramientas disponibles allí, luego proponer una solución.

Además, en esta etapa es necesario determinar qué requisitos legislativos deben tenerse en cuenta, cómo ejecutar legalmente ciertas operaciones, cómo se monetizará el nuevo servicio, cómo se planea ingresar al mercado, cómo interesar a los participantes externos del nuevo sistema.

En otras palabras, debe elaborarse un modelo de negocio. Por un lado, esta no es tarea de los desarrolladores, pero, por otro lado, sin una definición clara del objetivo y cómo implementarlo, no está claro qué tareas debe resolver el sistema. Y si el propio cliente aún no ha formulado claramente lo que necesita, es poco probable que esté satisfecho con al menos algún resultado.

2. Elegir un concepto de sistema

En esta etapa, es necesario elegir soluciones técnicas generales con las que se puedan cumplir los requisitos realizados en la etapa anterior. Ya sea una aplicación web o un cliente nativo, grueso o una base de datos delgada y centralizada o DBMS relacional o distribuido, noSQL, monolito o microservicios, Java o Python. A menudo, estos temas se olvidan de ser discutidos a tiempo, y luego resulta que uno de los programadores eligió de forma independiente una determinada herramienta, y al final esta solución no permite alcanzar el objetivo.

3. Desarrollo de términos de referencia

Compuesto requisitos generales para el hospital, eligió el concepto. "Bueno", dirá el cliente, "ahora todo está claro, puedes dibujar". ¿Es posible? Los requisitos son generales, deben detallarse. Por ejemplo, en el primer paso, determinó que debería haber un laboratorio de análisis de sangre. Pero, ¿qué tipo de equipo habrá, cuánto consume electricidad, aire comprimido (¿y si?) ¿Necesita lámparas de cuarzo para desinfección, mesas de laboratorio, ventilación? Sin esto, será difícil de diseñar. Este es el primero. Y en segundo lugar, es necesario prescribir un plan para construir un hospital, prepararlo y ponerlo en funcionamiento.

Para el Sistema de Información, el desarrollo de TOR ( Términos de Referencia ) es la parte central del proyecto. Los términos de referencia describen:

1. QUÉ debe hacer el sistema.
2. Cuál debería ser la estructura general del sistema.
3. Cómo crear un sistema.

Es decir, el TOR contiene requisitos funcionales y no funcionales, así como requisitos para las etapas de desarrollo, entrega, aceptación, documentación. También en el ToR se deben describir brevemente los procesos que realmente automatizamos.

Al describir las funciones del sistema (y esta es la parte central de los TOR), debe entenderse: damos los requisitos de QUÉ debe hacer el sistema y no CÓMO. Para usted, la amplitud de la cobertura debería ser más importante que la profundidad. Por ejemplo, en la primera etapa (preparación de requisitos generales), identificamos la necesidad de una función de bloqueo de inicio de sesión del usuario. La declaración de trabajo indicó que la cuenta está bloqueada si no se usa durante 90 días o después de 6 intentos de inicio de sesión fallidos, el administrador puede limitar el acceso durante un cierto período de tiempo, al intentar ingresar a un usuario bloqueado, se debe mostrar un mensaje, etc. Y en el proyecto técnico (adelantémonos), dibujaremos una maqueta de la tarjeta del usuario con la bandera de bloqueo y la fecha de desbloqueo, escribiremos un script para iniciar sesión en el sistema, que verificará el bloqueo, se desbloqueará automáticamente después de un período establecido, bloqueando en caso de intentos fallidos de inicio de sesión; Vamos a determinar qué se hace en el lado del cliente y qué se hace en el lado del servidor.

Me gustaría desacreditar varios mitos relacionados con el desarrollo de especificaciones técnicas .

Mito uno: TK contiene requisitos solo para el contratista.

No, TK es cómo crear un sistema, y ​​hay secciones en los términos de referencia en las que se puede describir la distribución de la responsabilidad.

Mito dos: en los Términos de Referencia a menudo hay mucha "agua".

De hecho, a menudo TK contiene información general sobre el sistema, pero son necesarios. Por ejemplo, discutimos y discutimos los requisitos para el sistema, como resultado, un equipo se dio cuenta de que era necesario desarrollar una aplicación para Windows y el otro para un navegador. Uno pensó que el sistema se llamaba así, y el otro un nombre diferente. Parece que son cosas obvias, pero todos los miembros del equipo y todos los especialistas involucrados deben entenderlos por igual.

Mito tres: los requisitos para el personal, los servidores, los canales de comunicación y los modos de operación de los administradores son superfluos, ya que están en el área de responsabilidad del cliente.

En primer lugar, como ya hemos considerado, TK está escrito para todos a la vez, y en segundo lugar, TK describe cómo hacer que el sistema funcione, y no solo el software está escrito. De lo contrario, habrá otra caja en un estante con un disco e instrucciones gruesas. Por lo tanto, la parte organizativa de los conocimientos tradicionales, los requisitos no funcionales, no son menos importantes que los requisitos funcionales.

Consideramos la preparación de TK con más detalle en un artículo separado. El desarrollo de los Términos de Referencia de acuerdo con GOST 34 es fácil y simple .

4. Desarrollo de un proyecto técnico.

Entonces, sigue adelante. Aquí está frente a usted (admitimos que es un diseñador). Términos de referencia para la construcción de un hospital con una enorme lista de requisitos. Te sientas, miras con tristeza las 100 páginas de TK y no sabes por dónde empezar. Luego, la imagen comienza a aclararse gradualmente. Usted piensa: sí, necesitamos tantos metros debajo de las salas, muchos debajo de la cocina, mucho en el área de descanso, laboratorio, salas de enfermería, etc. Luego nacen muchos bocetos, bocetos, opciones, rehaces, intercambias habitaciones, en resumen, buscando la mejor relación. Luego, vaya a los detalles: dibujos, dibujos, planos: paredes, puertas, ventanas, canales de cable, cableado, tuberías, ventilación, pisos, materiales de pared, acabados ... y así sucesivamente. En general, lo más detallado posible, describa cómo debe verse y funcionar el hospital después de que se complete la construcción.

Al desarrollar un proyecto técnico del Sistema de Información, se requieren documentos que contengan lo siguiente: escenarios detallados que describen la operación e interacción del sistema desarrollado, los usuarios y los sistemas relacionados; diseños detallados de la interfaz de usuario que contienen una descripción del tipo de datos y el comportamiento de cada elemento de la interfaz (valor predeterminado, condiciones bajo las cuales puede cambiar el valor del campo, visibilidad, acciones realizadas por el sistema cuando el elemento cambia, etc.); Descripción de protocolos para la integración con sistemas y equipos relacionados, formularios de informes y una descripción del algoritmo para su formación, la estructura de servidores y bases de datos, si hay varios.

Por lo general, esto es más que suficiente para poder entregar documentos a los desarrolladores y obtener un resultado sensato. Las maquetas y los scripts detallados proporcionan suficiente información sobre el comportamiento del sistema y la interfaz, así como la estructura de datos. Los desarrolladores se pondrán en un marco apretado en el que puedes fantasear, pero luego no saldrás.

Espero que en los siguientes artículos examinemos con más detalle cómo realizar un diseño técnico de manera de alta calidad, cómo desarrollar maquetas, escenarios y qué documentos deben elaborarse.

5. Desarrollo de documentación de trabajo.

La pregunta lógica es ¿cuál es la documentación de trabajo del hospital? ¿Realmente las instrucciones para limpiar el corredor? Bromeando como una broma, ¿necesitas mantener un sistema contra incendios? Es necesario ¿Y los ascensores? ¿Qué pasa con las redes informáticas? ¿Y el suministro de agua? "¡Bueno, eso no se aplica al proyecto del hospital!" - usted dice Sí, esto es en parte cierto. Sin embargo, el hospital se entrega al cliente en su conjunto, y todos los sistemas deben tener la documentación operativa adecuada. Y para que el cambio sea rápido, exitoso, elaborará una lista de requisitos, frente a la cual puede verificar si todo está en orden.

La presencia de guías de usuario y administrador para IP es un estándar, con esto todo está claro. Pero el cliente a menudo piensa en el proceso de aceptación del sistema en el último momento. Y en vano. Para esto, hay un excelente documento, "Metodología de programas y pruebas", que también suele estar relacionado con documentos de trabajo. Es un tipo de lista de verificación que contiene una descripción de los procedimientos de verificación. Si este documento se prepara por adelantado (y el guión, como base, se puede tomar prestado del proyecto técnico), entonces los desarrolladores tendrán un criterio claro para aceptar su trabajo. No necesita sus propios programadores o subcontratistas para probar su caso: hay un escenario, debe resolverse. Y no habrá problemas con el cliente: la fantasía ya está limitada por el documento.

¿Y dónde está el lugar para Agile?

Algunas personas con dos manos detrás de Agile (u otros métodos de desarrollo "flexibles"), otros están fuertemente en contra. El autor del artículo tiene su propia opinión: Agile es muy bueno, pero va al grano. Y generalmente lo usan para otros fines.

Dime, amantes de Agile, ¿es posible usar esta tecnología para determinar el resultado que obtienes al final del desarrollo, el costo y los términos? No?Bueno, ¿cuántos tontos encontrarás a esos clientes que se involucran en el trabajo con un resultado, presupuesto y duración poco claros? ¿Pediría un equipo de reparación de apartamentos usando Agile? Por lo tanto, Agile tiene un lugar para estar, pero para proyectos internos. Puede hacer las reparaciones usted mismo tanto como desee y revisar todo varias veces. Para clientes externos, esta es una estafa llamada por un término inteligente (usted, por supuesto, no estará de acuerdo con esta formulación, pero intenta convencer al cliente de lo mismo).

El cliente piensa: ¿y cuántos más me llevarán por la nariz?

En segundo lugar, Agile es bueno en innovación, donde no está claro qué tipo de resultado desea obtener o la forma de lograrlo no está claro. Esto se llama TOC, desarrollo experimental. O incluso I + D: investigación y desarrollo. En cualquier planta hay un taller experimental donde se obtienen prototipos con un archivo, remodelando varias veces. Imagine que necesita volver a desarrollar la pantalla táctil, todos los gestos y comportamientos. Aquí realmente debería intentarlo, no puede describir el comportamiento de antemano. ¿Pero a menudo te enfrentas a tareas de este tipo? Se debe hacer una distinción entre ingeniería e investigación. Básicamente, somos ingenieros de diseño de sistemas de información.

En tercer lugar, en un proyecto grande, puede haber etapas en las que se requiere TOC, y luego Agile para ayudar. Nadie se molesta en usar sprints a nivel de planificación operativa. Por el contrario, es una tecnología muy conveniente: planifique una o dos semanas y monitoree constantemente el resultado. A nivel estratégico, planificación en cascada, a nivel táctico, iterativo. Y sin contradicciones!

Desafortunadamente, muy a menudo, mientras "predican" a Agile, los desarrolladores intentan enmascarar su incapacidad para desarrollar un proyecto de sistema (o ni siquiera saben que esto es posible). Actúan de la manera más conveniente para ellos: terminaremos y terminaremos por el dinero del cliente. Si bien nadie controla los costos, esto se está escapando por completo. Pero entonces, un observador externo (jefes) puede sentir que el proceso está allí, pero no hay final ni límite, y ningún resultado es visible. Intenta mirar no solo desde tu campanario.

¿Dónde puedo encontrar más información sobre el diseño de sistemas de información?

Hay muchos libros sobre este tema. Grueso y no tan. Pero un libro siempre es una experiencia EXTRANJERA. Y tienes un personaje diferente, una gran situación y un proyecto. Existe tal sistema TRIZ: la teoría de resolver problemas inventivos. Su autor, Altshuller, está tratando de explicar los pasos que debe seguir para inventar algo. Resulta que? En general no. Los principios se declaran interesantes, útiles, pero no sale una plantilla única de acuerdo con la invención. Cada persona piensa y crea a su manera, y es imposible enseñar esto, solo se puede aprender. Es necesario usar la experiencia de otra persona, es estúpido no usarla, pero debe ser experimentada (procesada) por usted, trasladada a SU pensamiento. Copiar el milagro no tendrá éxito.

Si desea aprender diseño, le propongo tomar como base las especificaciones estándar estatales de la 34ª serie. Esta es una verdadera obra maestra, el resultado del trabajo de institutos de investigación enteros. Durante el desarrollo de estos estándares, se estudiaron docenas (si no cientos) de los proyectos más complejos para la automatización de varios sistemas. La experiencia colosal se acumula.

Estos estándares son difíciles de dominar, y no aprenderá cómo usarlos en un instante. Por lo tanto, trataremos de revelar su esencia en artículos posteriores.

Lea la continuación: Algunas notas sobre el diseño de sistemas de información .

Lea otros artículos del autor:

• El desarrollo de los Términos de Referencia de acuerdo con GOST 34 es fácil y simple.
• Encuesta previa al diseño en el desarrollo de un sistema de información.
• Algunas notas sobre el diseño de sistemas de información.