Por que exatamente o hospital?

Porque não Este é um bom exemplo. O projeto está em qualquer lugar do projeto: mais ou menos os mesmos estágios, o mesmo esquema de gerenciamento, gerenciamento de documentos, gerenciamento de riscos, controle de qualidade e assim por diante. Em todos os lugares existem requisitos para equipamentos, instalações e software. Você pergunta, quais podem ser os requisitos para instalações no Sistema de Informação? É muito simples: a localização das estações de trabalho do operador, servidor - ambos exigem ar condicionado. Aqui estão os requisitos para as instalações. E quase ninguém agora duvida se o hospital precisa de software. Se você deseja manter-se atualizado, terá a tarefa de criar uma instituição médica automatizada com registros médicos eletrônicos, onde os médicos fazem um exame com comprimidos e, por exemplo, as enfermeiras marcam o banheiro lavado não na folha, mas no telefone. Haverá muitos requisitos de software nesse caso. E assim que o software for necessário, será necessário instalar o servidor, colocar o administrador e os operadores em algum lugar. Tudo está interconectado.

Escolhemos um projeto de construção porque é mais fácil demonstrar como projetar um IP. O sistema de informação está escondido em algum lugar do lado de dentro, não o vemos e as paredes estão aqui à nossa frente: curvas e oblíquas, com corredores sem saída, porque o projeto foi feito no joelho, e o cliente mudou seus requisitos cem vezes durante a peça.

Código do programa dentro (mas ninguém vê isso)

O que um hospital tem a ver com isso se desenvolvermos software?

E aqui está, queridos desenvolvedores, executivos, analistas, testadores.

Não é o software que você está desenvolvendo ... Leve o Android, este é um software. E se, por exemplo, você possui um sistema contábil, já está lidando não apenas com software, mas com um SISTEMA DE INFORMAÇÃO.

A diferença é óbvia. Se você comprou um telefone, tudo é simples: ligue-o, um homem verde (Android) inicia, use-o. E se você comprou uma caixa com software de contabilidade, fica claro que agora você precisa de servidores, precisa configurar a rede, configurar estações de trabalho, treinar funcionários, integrar o sistema a outros IPs corporativos e acionar o sistema no modo de teste. Sim, e os contadores precisam ser convencidos de alguma forma a mudar para o novo software, nem todos estão prontos para inovações. Em geral, em qualquer projeto de TI, 10 a 20% é de TI, e todo o resto são medidas organizacionais e administrativas, bem, jóias muito densas, trabalho com funcionários.

Sistema de informação (é apenas software?)

E, finalmente, lembramos a definição de um sistema dos anos 90 distantes, que ninguém cancelou:

Sistema automatizado: um sistema composto por pessoal e um conjunto de ferramentas de automação para suas atividades que implementa a tecnologia da informação para executar funções estabelecidas.

GOST 34.003-90. Tecnologia da informação. Um conjunto de padrões para sistemas automatizados. Sistemas automatizados. Termos e definições.

Ou seja, o IP em primeiro lugar são pessoas, além de tecnologia que ajuda a automatizar suas atividades, e não vice-versa.

Como projetar um hospital

Imagine que você é uma organização de construção, um cliente vem até você e pede para construir um hospital nesse local. Você corre imediatamente para colocar tijolos ou ...? Se você observar com que frequência os Sistemas de Informação são criados, é o seguinte: os artistas imediatamente começam a "interferir no concreto e na compra de pacotes de vidro". Como, não vai funcionar dessa maneira - vamos reconstruir! Vamos reconstruir até alcançar o resultado desejado.

No entanto, se você é uma organização séria, primeiro ofereça ao cliente um PROJETO para construção. Você concorda? E por que isso está errado com o Sistema de Informação? Talvez não seja a diferença entre construção e desenvolvimento de software, mas que, no mesmo hospital, eles pensem muito, planejem e depois construam, e primeiro desenvolvam e depois pensem em software? Não é por isso que você ouve muito sobre programadores da krivoruky, mas nada sobre os mesmos trabalhadores migrantes em um canteiro de obras? Os construtores trabalham no projeto, diferentemente dos desenvolvedores.

É sempre assim sem um projeto, mesmo que não seja visível

Agora, consideramos o processo de design com mais detalhes. Tem várias etapas. Por que precisamos passar por várias etapas, por que não fazê-lo ao mesmo tempo? Para maior clareza, darei um exemplo escolar ... Quantos anos na escola estuda a operação de multiplicação? Você diz um ou dois meses e estará fundamentalmente errado. Sim, como multiplicar 5 por 6, passe em uma semana. Um certo tempo é ensinado a tabuada. E a multiplicação de frações, números com um grau, logaritmos, expressões entre colchetes, números complexos, elevando a um grau quantas pessoas estudam? Quase todos os anos escolares! Acontece que estudamos a mesma multiplicação todos os anos de diferentes ângulos.

E por que isso não está sendo estudado na primeira série?

Portanto, qualquer processo de aprendizado e design é cíclico. Primeiro, obtivemos conceitos gerais sobre números, aprendemos a executar ações simples com eles, aprendemos sobre frações e aprendemos a trabalhar com eles, e assim por diante.

Primeiro, percebemos que problema deveria ser resolvido com a ajuda do Sistema de Informação. Em seguida, determinamos o círculo de tarefas a serem resolvidas, entendemos o que o sistema deveria fazer, quais ações o pessoal deveria realizar. Então eles pensaram em COMO o sistema deveria cumprir as tarefas definidas anteriormente. Você pode pular essas etapas, basta voltar e refazer tudo: meça sete vezes e corte uma vez muito mais rápido que vice-versa, e menos material será deixado.

Nós damos outro exemplo. Você está no topo da montanha, olhando para baixo com binóculos fortes e tentando fazer uma rota de descida detalhada. Nas oculares, você pode ver todas as pedras no caminho, todas as poças. Mas aqui está este caminho e se ele leva ao topo com binóculos não é visível: não há plano geral. Um alpinista razoável esboçará primeiro os caminhos de descida a olho nu e depois serão examinados sob forte ampliação. Assim que você mergulha nos detalhes, perde a visão geral do projeto. Ao pegar a luneta imediatamente, você descreve idealmente 10 funções, esquecendo as outras 40 e geralmente não as menciona.

Pode ser visto bem, mas apenas uma pequena parte

A complexidade do design em fases é que, no início do processo, você precisa operar com conceitos abstratos. Então, eu quero "sentir" algo pronto, e não falar sobre certos requisitos, funções, tarefas, processos. Desenhar uma interface do usuário imediatamente é mais simples, mas também é mais fácil perder pelo menos metade dos requisitos. Se, a princípio, fizermos uma lista detalhada de operações que o usuário deve executar ao trabalhar com uma ou outra tela, o designer precisará apenas desenhar, e não fantasiar, como costuma ser o caso.

Agora, finalmente, passe para as etapas de design.

1. Elaboração de requisitos gerais

Então, digamos que você é um designer. Um cliente chega até você, "enviado" por construtores responsáveis. O cliente naturalmente pede que você desenvolva um projeto hospitalar. Você corre para o Kuhlmann e ... Bem, isso é antiguidade - abra o ArchiCAD e desenhe.

Mas é claro que não é sobre você. Você é um profissional e começa a fazer várias perguntas "estúpidas". E o mais importante deles - por que você precisa construir um hospital? Qual é o objetivo da construção? Se o objetivo não for claro, você não poderá responder à pergunta, seja um hospital grande ou pequeno, com qual perfil, do que equipado. Infelizmente, os clientes costumam dizer muitas coisas interessantes, exceto a principal - qual é o seu objetivo. Aqui é necessário "puxar" para fora deles em primeiro lugar. E você deve fazer uma pergunta. O próprio cliente não é um especialista, ele tem uma ideia e, com isso, vê seu papel cumprido. Ele não entende que caminho leva para realizar sua idéia. Como regra, o cliente espera que um bom e velho milagre - chegue à praia, jogue uma rede (pague dinheiro), pegue um peixe e ela cumprirá seu desejo ... Mas acontece como em uma piada sobre um homem rico que, depois de pegar um peixe dourado, pediu para realizar um desejo: " Eu quero que tudo esteja comigo! "Não tem problema", respondeu o peixe, "você tinha tudo ..."

Para entender o objetivo do projeto, não basta fazer algumas frases com um conjunto padrão de frases. O objetivo de um projeto geralmente é determinado com base na oposição: eles descrevem o modelo de informações existente (por exemplo, as pessoas estão sentadas no arquivo e classificando os documentos), depois suas deficiências (devido à falta de automação, 10 pessoas estão envolvidas no arquivo, o que é claramente redundante, outros departamentos não podem receber por semanas do arquivo, as informações de que precisam etc.) e oferecer uma solução (para introduzir um software que permita que várias operações sejam executadas de modo automatizado, as operações devem ser listadas). Se um tipo de serviço completamente novo for introduzido no mercado, será necessário estudar o mercado existente e "criticar" as ferramentas disponíveis no local, e propor uma solução.

Além disso, nesta fase, é necessário determinar quais requisitos legislativos devem ser levados em consideração, como executar legalmente determinadas operações, como o novo serviço será monetizado, como está planejado para entrar no mercado, como interessar aos participantes externos do novo sistema.

Em outras palavras, um modelo de negócios deve ser elaborado. Por um lado, essa não é uma tarefa dos desenvolvedores, mas, por outro lado, sem uma definição clara do objetivo e como implementá-lo, não está claro quais tarefas o sistema deve resolver. E se o próprio cliente ainda não formulou claramente o que precisa, é improvável que esteja satisfeito com pelo menos algum resultado.

2. Escolhendo um conceito de sistema

Nesse estágio, é necessário escolher soluções técnicas gerais com as quais os requisitos estabelecidos no estágio anterior possam ser atendidos. Seja um aplicativo da Web ou um cliente grosso nativo ou um banco de dados fino e centralizado ou DBMS relacional distribuído ou noSQL, monólito ou microsserviços, Java ou Python. Freqüentemente, esquece-se de que essas questões sejam discutidas a tempo e, em seguida, um dos programadores escolheu independentemente uma determinada ferramenta e, no final, essa solução não permite atingir o objetivo.

3. Desenvolvimento de Termos de Referência

Compostos requisitos gerais para o hospital, escolheu o conceito. "Bem", o cliente dirá, "agora está tudo claro, você pode desenhar". Isso é possível? Os requisitos são gerais, eles precisam ser detalhados. Por exemplo, na primeira etapa, você determinou que deveria haver um laboratório de análises ao sangue. Mas que tipo de equipamento haverá, quanto consome eletricidade, ar comprimido (e se?). Você precisa de lâmpadas de quartzo para desinfecção, mesas de laboratório, ventilação? Sem isso, será difícil projetar. Este é o primeiro. Em segundo lugar, é necessário prescrever um plano para a construção de um hospital, preparando-o e colocando-o em operação.

Para o Sistema de Informação, o desenvolvimento do TOR ( Termos de Referência ) é a parte central do projeto. Os termos de referência descrevem:

1. O que o sistema deve fazer.
2. Qual deve ser a estrutura geral do sistema.
3. Como criar um sistema.

Ou seja, o TOR contém requisitos funcionais e não funcionais, bem como requisitos para as etapas de desenvolvimento, entrega, aceitação e documentação. Também no ToR devem ser descritos brevemente os processos que realmente automatizamos.

Ao descrever as funções do sistema (e essa é a parte central do TOR), deve-se entender - damos requisitos para o QUE o sistema deve fazer, e não COMO. Para você, a amplitude da cobertura deve ser mais importante que a profundidade. Por exemplo, no primeiro estágio (preparação de requisitos gerais), identificamos a necessidade de uma função de bloqueio de login do usuário. A declaração de trabalho indicava que a conta é bloqueada se não for usada por 90 dias ou após 6 tentativas malsucedidas de login, o acesso pode ser limitado pelo administrador por um determinado período, ao tentar inserir um usuário bloqueado, uma mensagem deve ser exibida etc. E no projeto técnico (vamos nos antecipar), desenharemos uma maquete do cartão do usuário com a bandeira de bloqueio e a data de desbloqueio, escreveremos um script para fazer login no sistema, que verificará o bloqueio, desbloqueia automaticamente após um período definido, bloqueando em caso de tentativas malsucedidas de login; vamos determinar o que é feito no lado do cliente e o que é feito no lado do servidor.

Eu gostaria de desmascarar vários mitos relacionados ao desenvolvimento de especificações técnicas .

Mito um: a TK contém requisitos apenas para o contratante.

Não, TK é como criar um sistema, e há seções nos termos de referência nos quais a distribuição de responsabilidade pode ser descrita.

Mito dois: Nos Termos de Referência , muitas vezes há muita "água".

De fato, muitas vezes o TK contém informações gerais sobre o sistema, mas elas são necessárias. Por exemplo, discutimos e discutimos os requisitos para o sistema, como resultado, uma equipe percebeu que era necessário desenvolver um aplicativo para Windows e outro para um navegador. Um pensou que o sistema era chamado assim, e o outro um nome diferente. Parece coisas óbvias, mas elas devem ser entendidas igualmente por todos os membros da equipe e por todos os especialistas envolvidos.

Mito três: Os requisitos para equipe, servidores, canais de comunicação, modos de operação dos administradores são supérfluos, pois estão na área de responsabilidade do cliente.

Primeiro, como já consideramos, o TK é escrito para todos de uma vez e, segundo, o TK descreve como fazer o sistema funcionar, e não apenas o software é escrito. Caso contrário, haverá outra caixa em uma prateleira com um disco e instruções grossas. Assim, a parte organizacional da TK, requisitos não funcionais, não é menos importante que os requisitos funcionais.

Consideramos a preparação do TK com mais detalhes em um artigo separado.O desenvolvimento dos Termos de Referência de acordo com o GOST 34 é fácil e simples .

4. Desenvolvimento de um projeto técnico

Então, siga em frente. Aqui está à sua frente (admitimos que você é um designer) Termos de Referência para a construção de um hospital com uma enorme lista de requisitos. Você senta, olha tristemente para 100 páginas de TK e não sabe por onde começar. Então a imagem gradualmente começa a se esclarecer. Você pensa: sim, precisamos de tantos metros embaixo das enfermarias, tantos embaixo da cozinha, tanto na área de descanso, laboratório, salas de enfermagem e assim por diante. Então, muitos esboços, esboços e opções nascem, você refaz, troca de salas, enfim, procurando a melhor proporção. Em seguida, vá para os detalhes - desenhos, desenhos, plantas: paredes, portas, janelas, canais a cabo, fiação, tubos, ventilação, pisos, materiais de parede, acabamentos ... e assim por diante e assim por diante. Em geral, o mais detalhado possível, descreva a aparência e o funcionamento do hospital após a conclusão da construção.

Ao desenvolver um projeto técnico do Sistema de Informação, são necessários documentos contendo o seguinte: cenários detalhados que descrevem a operação e a interação do sistema desenvolvido, usuários e sistemas relacionados; layouts detalhados da interface do usuário contendo uma descrição do tipo de dados e comportamento de cada elemento da interface (valor padrão, condições sob as quais você pode alterar o valor do campo, visibilidade, ações executadas pelo sistema quando o elemento é alterado, etc.); descrição de protocolos para integração com sistemas e equipamentos relacionados, formulários de relatório e descrição do algoritmo para sua formação, estrutura de servidores e bancos de dados, se houver vários.

Geralmente, isso é mais do que suficiente para poder fornecer documentos aos desenvolvedores e obter um resultado sensato. Maquetes e scripts detalhados fornecem informações suficientes sobre o comportamento do sistema e da interface, bem como a estrutura de dados. Os desenvolvedores serão colocados em uma estrutura rígida na qual você pode fantasiar, mas depois não sairão.

Espero que nos artigos a seguir examinemos mais detalhadamente como executar o projeto técnico de maneira de alta qualidade, como desenvolver modelos, cenários e quais documentos precisam ser elaborados.

5. Desenvolvimento da documentação de trabalho

A questão lógica é qual é a documentação de trabalho para o hospital? Realmente as instruções para limpar o corredor ?! Brincando como uma piada, você precisa manter um sistema de incêndio? É necessário. E os elevadores? E as redes de computadores? E o abastecimento de água? "Bem, isso não se aplica ao projeto do hospital!" você diz. Sim, isso é parcialmente verdade. No entanto, o hospital é entregue ao cliente como um todo e todos os sistemas devem ter documentação operacional apropriada. E para que a mudança seja rápida e bem-sucedida, você elaborará uma lista de requisitos, na qual você pode verificar se tudo está em ordem.

A presença de guias de usuário e administrador para IP é um padrão, com isso tudo está claro. Mas o cliente costuma pensar no processo de aceitação do sistema no último momento. E em vão. Para isso, existe um excelente documento, “Metodologia de Programas e Testes”, também geralmente relacionado a documentos de trabalho. É um tipo de lista de verificação que contém uma descrição dos procedimentos de verificação. Se este documento for preparado com antecedência (e o script, como base, puder ser emprestado do projeto técnico), os desenvolvedores terão um critério claro para aceitar seu trabalho. Você não precisa de programadores próprios ou de terceirização para provar seu caso - existe um cenário, ele deve ser resolvido. E não haverá problemas com o cliente - a fantasia já está limitada pelo documento.

E onde é o lugar para o Agile?

Algumas pessoas com as duas mãos atrás do Agile (ou outros métodos de desenvolvimento "flexíveis"), outras são fortemente contra isso. O autor do artigo tem sua própria opinião: Agile é muito bom, mas direto ao ponto. E eles costumam usá-lo para outros fins.

Diga-me, amantes do Agile, é possível usar essa tecnologia para determinar o resultado que você obtém ao final do desenvolvimento, custo e termos? Não?Bem, quantos tolos você encontrará nos clientes envolvidos no trabalho com um resultado, orçamento e duração pouco claros? Você pediria uma equipe de reparo de apartamento usando o Agile? Assim, o Agile tem um lugar para estar, mas para projetos internos. Você pode fazer reparos por conta própria e revisar tudo várias vezes. Para clientes externos, essa é uma farsa chamada por um termo inteligente (é claro que você não concorda com essa formulação, mas tenta convencer o cliente da mesma).

O cliente pensa: e quantos mais eles vão me levar pelo nariz?

Em segundo lugar, o Agile é bom em inovação, onde não está claro que tipo de resultado você deseja obter ou a maneira de alcançá-lo não é clara. Isso é chamado de TOC, desenvolvimento experimental. Ou mesmo P&D - pesquisa e desenvolvimento. Em qualquer fábrica, há uma oficina experimental onde protótipos são obtidos com um arquivo, remodelando várias vezes. Imagine que você precisa re-desenvolver a tela sensível ao toque, todos os gestos e comportamento. Aqui você realmente deve tentar e não pode descrever o comportamento com antecedência. Mas você costuma enfrentar tarefas desse tipo? Uma distinção deve ser feita entre engenharia e pesquisa. Basicamente, somos engenheiros de design de sistemas de informação.

Em terceiro lugar, em um projeto grande, pode haver estágios em que o TOC é necessário e, em seguida, o Agile para ajudar. Ninguém se incomoda em usar sprints no nível de planejamento operacional. Pelo contrário, é uma tecnologia muito conveniente: planeje por uma semana ou duas e monitore constantemente o resultado. No nível estratégico, planejamento em cascata, no nível tático, iterativo. E sem contradições!

Infelizmente, muitas vezes, enquanto “pregam” para o Agile, os desenvolvedores tentam mascarar sua incapacidade de desenvolver um projeto de sistema (ou eles nem sabem que isso é possível). Eles agem da maneira mais conveniente para eles: terminaremos e terminaremos pelo dinheiro do cliente. Enquanto ninguém controla os custos, isso é completamente impossível. Mas então, um observador externo (chefes) pode sentir que o processo está lá, mas não há fim e margem, e nenhum resultado é visível. Tente olhar não apenas da sua torre sineira.

Onde posso descobrir mais sobre o design de sistemas de informação?

Existem muitos livros sobre esse assunto. Grosso e não é assim. Mas um livro é sempre uma experiência alienígena. E você tem um personagem diferente, uma ótima situação e um projeto. Existe um sistema TRIZ - a teoria da solução de problemas inventivos. Seu autor, Altshuller, está tentando explicar as etapas necessárias para inventar algo. Acontece? Geralmente não. Os princípios são declarados interessantes, úteis, mas não é apresentado um único modelo de acordo com a invenção. Cada pessoa pensa e cria à sua maneira, e é impossível ensinar isso, você só pode aprender. É necessário usar a experiência de outra pessoa, é estúpido não usá-la, mas deve ser experimentada (processada) por você, mudada para o SEU pensamento. Copie o milagre não terá sucesso.

Se você quer aprender design, proponho que se baseiem as especificações padrão do estado da 34ª série. Esta é uma verdadeira obra-prima, resultado do trabalho de institutos de pesquisa inteiros. Durante o desenvolvimento desses padrões, dezenas (se não centenas) dos projetos mais complexos para a automação de vários sistemas foram estudados. A experiência colossal é acumulada.

É difícil dominar esses padrões e você não aprenderá a usá-los rapidamente. Portanto, tentaremos revelar sua essência em artigos subseqüentes.

Leia a continuação: Algumas notas sobre o design de sistemas de informação .

Leia outros artigos do autor:

• O desenvolvimento dos Termos de Referência de acordo com o GOST 34 é fácil e simples.
• Levantamento pré-projeto no desenvolvimento de um sistema de informação.
• Algumas notas sobre o design de sistemas de informação.