Evolução do Universo de Informações

A Figura 17 página 26 (Parte II) mostra algo que, comumente, é esquecido.

A Figura mostra que o Universo de Informações evolui na medida em que construímos os requisitos! Ou seja, a base, que utilizamos para entendermos o que os clientes desejam, muda durante o processo de construção dos requisitos. É preciso ter consciência de que isso é uma dificuldade, a mais, no processo de entender as necessidades dos clientes.

Portanto, é importante que a fase de construção de requisitos tenha uma visão de processo contínuo. É preciso saber que os requisitos não estão prontos para serem descritos e formalizados, que o próprio processo de questionamento dos requisitos leva a com que eles mudem.

Processo de Construção de Requisitos

A Figura 16 página 25 mostra nosso entendimento do processo de construção de requisitos. Essa Figura é de um modelo SADT [Ross 77] do tipo “actigrama”, ou seja utiliza a perspectiva de função ou atividade. Nele vemos o quão importante é escolher as pessoas e os métodos com que se irá trabalhar. Mostra também que, fundamentalmente, o processo de construção de requisitos (no livro uso o termo definição) é pautado por três atividades: elicitar, modelar e analisar. É importante notar que a saídas dessa Figura: delta, requisitos e modelo refletem: a importância da retro-alimentação, o papel de comunicação dos requisitos em linguagem natural e a necessidade de utilização de modelos para explicitar a semântica dos requisitos.

A Figura 16 abstrai-se do processo gerencial que é ortogonal ao processo de construção e que fundamentalmente cuida para que o processo seja eficaz e eficiente. Particularmente importante, é notar, que o ciclo de retro-alimentação é inerente ao processo, através da produção de deltas. Esses deltas podem ser gerados pelas atividade de análise. No contexto da atividade de análise é importante ressaltar a implementação de políticas de qualidade quer por processos de verificação, quer por processos de validação.

Referência Bibliográfica

[Ross 77] Douglas T. Ross: Structured Analysis (SA): A Language for Communicating Ideas. IEEE Trans. Software Eng. 3(1): 16-34 (1977)

Universo de Informações

A Seção 2 da Parte II procura ressaltar o papel de contexto na produção de software. O texto enfatiza a importância de modelos como força de contextualização. Esses modelos estabelecem perspectivas para os engenheiros de software.

O conceito de Universo de Informações (UdI) é essencial na produção de software. Todo processo de software tem um UdI, no entanto muitas vezes os engenheiros de software não tem um mapa desse UdI. Você já esteve numa situação onde, em terras estranhas, você precisa locomover-se? Turistas precisam de mapas, porque querem saber como locomover-se em lugares com os quais não tem familiaridade.

Definimos UdI como:

"É o contexto no qual o software deverá ser desenvolvido e operado. O UdI inclui todas as fontes de informação e todas as pessoas relacionadas ao software. Essas pessoas são também conhecidas como os atores desse universo. O UdI é a realidade circunstanciada pelo conjunto de objetivos definidos pelos que demandam o software."

É no UdI que os engenheiros de requisitos irão trabalhar. É no UdI que o software desempenhará suas funções.

Saber da existência do UdI é fundamental. Saber que o UdI é um corte da realidade, ou seja é uma redução do contexto mais geral, mundo, para um contexto mais específico. Em Banco de Dados utiliza-se o nome Mini Mundo. O termo escopo é também utilizado em alguns métodos de produção de software.

O UdI é representado por uma forma que se assemelha a uma nuvem. Essa forma é importante porque mostra que os limites (vejam os pontos fundamentais da TGS, Parte I) não são bem definidos. A forma gasosa da nuvem passa também a idéia de volatilidade, e essa característica é também presente no UdI, em maior ou menor grau, dependo de cada caso. Na verdade, o UdI diminui ou aumenta na medida em que, no processo de construção de software, melhor entendemos as necessidades dos clientes e as restrições de implantação. O UdI evolui.

A estratégia para mapear o UdI é fundamentada no objetivo mais geral disponível. Ou seja, no evento que dispara o uso do SDS (veja entrada do SDS). Um processo de produção de software é iniciado por atores que têm interesse na construção ou evolução de um determinado artefato de software. Vejamos três casos como exemplo.

Caso 1: uma empresa produtora de software tem conhecimento de um edital para concorrência pública para a evolução de um sistema de software. O edital mencionará o objeto da concorrência, a infra-estrutura de software pré-existente, normas de produção, por exemplo, a Mps. Br, local físico onde o trabalho deverá ser implantado entre outras informações. Nesse caso, o edital, através de suas informações, delineia a primeira versão do UdI.

Caso 2: o departamento de software de uma organização recebe um memorando do diretor financeiro pedindo que um novo sistema de software seja feito para auxiliar a visualização do acompanhamento do fluxo de caixa da organização. O UdI nesse caso já tem um delimitado o ator requisitante (diretor financeiro), o objetivo geral (software de visualização) e onde será empregado (integração como sub-sistema de fluxo de caixa).

Caso 3: um empreendedor resolve apostar na construção de um software para ajudar as pessoas no controle de suas finanças. O empreendedor acredita que as soluções disponíveis deixam a desejar e pensa em fazer um software, que será acessado via navegadores padrão, com facilidade de mobilidade (celular). Portanto esse empreendedor já estabeleceu os contornos do UdI em pauta.

Para a Engenharia de Requisitos o UdI é de fundamental importância porque será no UdI que as fontes de informação serão identificadas. Essas fontes de informação é que permitirão com que o delineamento do UdI seja elaborado e constantemente evoluído. O Engenheiro de Requisitos precisa das fontes de informação da mesma maneira que um repórter precisa de fontes para escrever uma matéria.

O UdI é formado através de aproximações sucessivas, principalmente na identificação de fontes de informação. As fontes de informação podem ser de diferentes tipos, sendo as principais: atores (pessoas ou organizações), artefatos de software, artefatos físicos e documentos.

Uma estratégia utilizada para identificar as fontes de informação é saber que fonte de informação aponta para outras fontes de informação. As fontes mais referenciadas certamente deverão ser consideradas na formação do UdI: se pensarmos em grafos essas fontes seriam nós com um maior número de elos.

Outra maneira de identificar a importância de fontes de informação é através de prioridades. No que se refere a atores, normalmente os "donos" do software são os de maior prioridade.

Um mapa de fontes de informação se assemelharia ao uma rede, como a mostrada num mapa de ligações entre grandes corporações alemãs. O uso do software "They Rule" permite que você monte seu próprio mapa de atores do mundo corporativo americano.

Modelos

Na parte II, ressaltamos quatro pontos fundamentais para melhor entendermos o contexto de um artefato de software.

São eles:

• Aspectos Sociais
• Modelos
• Um Sistema é Sempre um Sub-Sistema de um Sistema Maior
• A Definição de um Sistema é Função da Implantação de Seu Macro-Sistema
• Falácia da Completeza
• Falácia da Página em Branco

Um desses pontos é o conhecimento de modelos (páginas 4 e 5, Parte II). Aqui usamos o sentido da palavra modelo de uma forma bastante ampla. Modelos são abstrações gerais sobre algo do mundo real. Apresentamos diferentes Modelos na Seção 3 da Parte II.

Um desses modelos é o modelo de Sá Carvalho. Esse modelo mostra que, para entendermos o que uma Fábrica de Informações deve produzir, é necessário saber quais as ações concretas que ocorrem no contexto organizacional em que essa Fábrica funcionará. Veja que Sá Carvalho usou de uma analogia para descrever Sistemas de Informação como Fábricas. Ações concretas são ações que ocorrem numa organização e que estão diretamente relacionadas com seus objetivos.

O modelo de Sá Carvalho mostra que devemos deslocar o foco do que a Fábrica produz, ou deverá produzir, e centrar nossa atenção na razão da existência da Fábrica. Dessa maneira, o modelo nos ensina que, para chegarmos as saídas da fábrica, devemos fazer um percurso inverso: identificar as ações, identificar as tomadas de decisão que motivaram a ação, e identificar as informações necessárias para as decisões.

Especificação versus Requisitos

Essa nota repete o que está na Página 2 da Parte II do pré-livro.

Veja aqui a diferença, conforme o dicionário do Aurélio.

Sistema de Desenvolvimento de Software

A Figura 11 na página 20 (Parte I) é um modelo que descreve as partes fundamentais de uma organização que tem por objetivo produzir software. Sua descrição é feita na linguagem SADT (Structured Analysis and Design Technique) de Douglas Ross. No caso estamos usando uma das perspectivas do SADT, a perspectiva de dados (datagrama).

Essa Figura foi produzida com base no livro de Peter Freeman Software Perspectives: The System is the Message e retrata como 5 sub-sistemas fundamentais para a produção de software se inter-relacionam. Vejam que temos duas entradas: “ estabelecer objetivos” e “manter o estado da arte”, uma saída: “produzir software” que é uma composição de “criar sistemas”, “organizar sistemas”, “reutilizar software” e “produzir informação”, e três retro-alimentações: “informar sobre o processo”, “medir desempenho” e “arquivar software”. Veja que na Figura a palavra “sistema” é sinônimo de “software”.

Portanto o subsistema Gerência cuida da interface com os clientes da organização procurando entender os objetivos e utilizando os sub-sistemas de Pessoal, Métodos e Ferramentas para atingir os objetivos. Veja o papel do subsistema de Informação que ajuda a gerência tanto para saber como anda o processo como também como o mercado tem evoluído na prática da construção de software. Esse subsistema também é importante por ser repositório do conhecimento produzido na produção do software. Esse modelo coloca o subsistema Pessoal como central no processo de produção. A produção de software é um trabalho criativo acima de tudo; depende da inteligência e criatividade do ser humano, mas para ser mais homogêneo necessita de padrões (sub-sistema de Métodos), como necessita de apoio para uma maior produtividade (sub-sistema de Ferramentas e sub-sistema de Informação).

Veja que essa Figura é independente do processo de produção a ser utilizado pela organização, ou seja, cada organização pode escolher diferentes maneiras de produzir software (diferentes implementações do subsistema Métodos) dependente de uma série de fatores, mas principalmente, do Pessoal disponível, dos objetivos a serem atingidos assim como pelas Ferramentas disponíveis.

É importante ressaltar que o SDS (Sistema de Desenvolvimento de Software) apresenta um esquema de aprendizado embutido, quer seja combatendo a entropia através da entrada “manter o estado da arte”, bem como aprendendo com os possíveis desvios através de processos de retro-alimentação (“medir desempenho” e “informar sobre o processo”). Ou seja, esta visão do SDS incorpora a idéia do ciclo de aperfeiçoamento presente no ciclo PDCA (veja o uso desse conceito por uma grande empresa) .

Abstração X Formalismo na Produção de Software

A Figura 8 da página 17 (Parte I) é uma tentativa de explicar o dualismo entre alto nível de abstração e alto grau de formalismo. Essa figura procura retratar o problema entre sair do canto superior esquerdo da Figura e atingir o canto inferior direito. O processo de produção de software busca exatamente isso: parte de uma definição abstrata, normalmente informal, e procura atingir uma implantação em forma detalhada e completamente formal. Completamente formal porque será uma descrição a ser executada por uma máquina, que só aceita descrições não ambíguas. Detalhada, porque a máquina é uma máquina construída para tratar lidar com dois estados diferentes (ligado e desligado), e nível lingüístico em que opera, apesar dos compiladores hoje existentes ainda requer um nível de detalhamento bastante grande.

O grande desafio do processo de produção de software é não perder-se na tentativa de sair da origem (canto superior esquerdo) e chegar à meta (conto inferior direito). Ocorre que durante o “caminho” várias distorções podem ocorrer, quer seja devido às falhas no entendimento do que deve ser a meta, a falhas no processo de produção (um desenho equivocado), ou a uma re-interpretação da meta em função de mudanças na origem.

A importância desse gráfico, cuja origem não consigo recordar, mas que está ligado a uma palestra de um Professor da Alemanha, é o de mostrar que o espaço de trabalho do engenheiro de software leva em consideração a dificuldade de ser preciso a um alto nível de abstração e a dificuldade de ser sucinto em face da exigência de um formalismo que impeça interpretações ambíguas.

Forma Canônica

A Figura 7 da página 16 (Parte I) mostra uma abstração do processo de produção em sua forma canônica, isto é na forma mais simples que se pode reduzir o processo de produção de software. Veja que esse modelo, onde o Universo de Informações é a entrada e o Software é a saída, é independente da forma como o processo de produção irá ser executado. Ou seja, pode-se optar por um esquema de protótipos (Figura 5, página 14), por um processo espiral (Figura 4, página 13), por um processo clássico (Figura 3, página 12), por um processo ágil ou pelo processo V.

Independente da estratégia de produção, sempre teremos um início, um meio e um fim. O início está ligado a motivação do que faremos, o meio é como pensamos em tratar o que faremos e o fim é o que fizemos. Portanto: a definição é processo de entender o que vai ser feito; o desenho ou arquitetura é o processo de imaginar como será o que faremos; e a implantação ou código é o processo de programar uma máquina para que ela comporte-se conforme entendemos o que deveríamos fazer. O modo como executamos o meio, o início e o fim, é dependente do esquema de produção (método) escolhido.