Gerenciamento de requisitos no SEI-CMM e ISO 9000

Gerenciamento de requisitos no SEI-CMM

Em novembro 1986, o Instituto de Engenharia de Software (SEI), de Carnegie-Mellon University, iniciou o desenvolvimento de um framework para acompanhar a maturidade do processo com a finalidade de ajudar aos desenvolvedores em seus projetos de software. Em setembro de 1987, o SEI realizou uma breve descrição do seu framework para o processo de maturidade após passar por ampliação de Watts Humprey’s – Managing the Software Process (1989). Em 1991, esse framework foi encapsulado naquilo que se denominou versão 1.0 do Capability Maturity Model, ou CMM. Em 1993 a versão 1.1 do CMM foi publicada (SEI 1993). A versão 1.1 define cinco níveis de maturidade de software para uma organização e provê um framework para condução de um nível para o nível seguinte, como ilustrado na figura 1. O CMM conduz o desenvolvedor através das suas atividades e ajuda a organização a acompanhar os seus processos de software, objetivando o reaproveitamento, controle e estimativa do processo.

Desconsiderando as controvérsias e discussões sobre as vantagens e desvantagens do CMM, a simples análise dos resultados comparativos mostram a aderência do CMM, pois confirmam o aumento significativo da qualidade de software e o baixo custo despendido pela adoção da metodologia por muitas empresas. O CMM tem sido adotado por muitas organizações do mundo todo e essas organizações, segundo os seus relatos estatísticos, têm obtido retorno positivo de investimento. O retorno aferido refere-se aos aumentos de produtividade e significante redução do tempo de construção dos produtos. Em uma época de progressivo aumento de ambientes competitivos, por mínimo que seja o ganho em produtividade não pode ser ignorado.
O CMM dispõe um framework para monitoramento em ‘áreas chaves do processo’, ou das atividades organizacionais que forem identificadas como as que influenciam em vários aspectos o processo de desenvolvimento e resulta na qualidade do software desenvolvido. A tabela 1 identifica as áreas chaves do processo de todos os cinco níveis do CMM.

O CMM sumariza a área do processo de gerenciamento de requisitos da seguinte forma: O propósito da gerencia de requisitos é o estabelecimento de um entendimento comum entre usuários e a equipe de software para as necessidades dos usuários.

O entendimento comum entre os clientes e a equipe de desenvolvimento serve como base para o acordo, que é documento central que define e controla as atividades seguintes. Requisitos são controlados para estabelecer a linha de base para o gerenciamento da engenharia de software utilizada. O CMM estabelece um guia específico para todas as atividades, planos, agendas. Os produtos de software são ajustados para serem desenvolvidos ou modificados quando necessário para se tornarem consistente com os requisitos alocados para o software. Desta maneira, o CMM promove a organização numa visão integrada consistente com o plano do projeto e as atividades. Para suportar esse processo, os requisitos do software devem ser documentados e revistos pelo gerente de software e grupos afetados, incluindo representantes dos clientes e comunidade de usuários.
A especificação de requisitos do software serve como o documento central do projeto, definindo o relacionamento entre outros elementos do plano do projeto. Os requisitos inclusos são os requisitos técnicos (relativos ao ambiente da aplicação) e os não-técnicos (outros requisitos do projeto, incluído cronograma entre outros). Adicionalmente, critérios de aceitação, que são os testes e estimativas que poderão ser utilizadas para a validação do software de encontro aos requisitos. Portanto, tudo deverá ser estabelecido formalmente e documentado.

Em suma, o CMM prover uma visão compreensiva das atividades que devem ser aplicadas para a qualidade de software e um aumento de produtividade. O eficiente gerenciamento de requisitos é a parte fundamental desse processo.

Gerenciamento de requisitos em ISO 9000:2000

Nas ultimas duas décadas passadas, um número significativo de organizações em torno do mundo, tem adotado uma série de padrões de gerenciamento de qualidade conhecidos como ISO 9000 para impor um meio mais produtivo em seus processos e reduzir custos. Em dezembro de 2000, esse documento foi revisado conforme as lições aprendidas nos últimos cinco anos, resultando no padrão denominado por ISO 9000:2000.

Atualmente, a ISO 9000 foi adaptada pela comunidade européia como EN29000 e foi um fator importante para o comércio internacional; organizações que desejavam ter negócios na Europa, freqüentemente apresentavam a certificação ISO 9000. Então, com a globalização da economia, muitas corporações americanas tem adotado a ISO 9000 para assegurar sua credibilidade no mundo dos negócios.

Análise de problemas em engenharia de software

A análise de problema

Nesse artigo, eu quero retomar a discussão sobre os caminhos que a equipe de desenvolvimento de software e usuários encontram para a construção de um novo sistema ou aplicação. Muitos sistemas são construídos para resolver um problema em particular, então, para isso usamos a técnica de análise de problema para estarmos seguros de que estamos, realmente, entendendo o problema.

Devemos também reconhecer que nem todo o desenvolvimento de aplicação visa a solução de um problema; algumas vezes, constrói-se sistemas para tirar proveito de situações e oportunidades que se fazem presentes, sem que necessariamente exista um problema a ser resolvido.
Concordamos, que problemas e oportunidades são apenas lados opostos de uma mesma moeda; seu problema é a minha oportunidade pregam os livros de auto-ajuda. Isso é, portanto, apenas um perspectiva diferente para se observar essa questão.

Podemos definir a análise de problemas como:

O processo de entendimento de problemas no mundo real, suas relações com as necessidades do usuário e a proposta de soluções que vão de encontro a essas necessidades.

Assim sendo, o domínio do problema deverá ser analisado, entendido e uma variedade de soluções para o problema deve ser explorada. Usualmente, uma variedade de soluções é possível e, dentre todas essas, pelo menos, uma solução será ótima para o problema a ser resolvido. Deve-se atentar para o fato de que, algumas vezes, a solução mais simples para o problema é uma simples revisão do processo de negócio ao invés da construção de um novo sistema.
O alvo principal da análise do problema é obter um melhor entendimento sobre o problema antes de iniciar-se, efetivamente, o desenvolvimento da solução. Desta forma, cinco passos devem ser cumpridos para a efetiva aplicação da análise do problema.

Cinco passos para a análise do problema:

Passo 1: Obtenção sobre a definição do problema

O primeiro passo no caminho mais simples para a obtenção das definições sobre um problema a ser solucionado é, simplesmente, registrá-lo. O simples ato de registrar um problema já nos permite vislumbrar soluções.
Como parte desse processo, esse registro freqüentemente traz benefícios para o entendimento e alguns benefícios para a fixação da solução proposta. Devemos ser cuidadosos para fazer com esses benefícios sejam claramente descritos em termos dominados também pelos stakeholders. Tendo o usuário descrito os benefícios advindos do contexto do problema no mundo real e ao verificar os benefícios, também, do ponto de vista dos usuários, também se obterá um melhor entendimento dos pontos de vista do stakeholder sobre os seus problemas.

O registro do problema

A tabela 1 ajudará a registrar o seu problema em um formato padrão. A simples utilização de um registro padronizado fará com que você esteja seguro de que todos os stakeholder estejam focados nos mesmos problemas.

Passo 2: Entendendo as causas raízes – por dentro do problema

Sua equipe pode utilizar-se de uma variedade de técnicas para obtenção de entendimento sobre um problema real e suas causas reais. Uma técnica utilizada para isso e a análise “causas raízes”, que é uma sistemática para desvendar a raiz, ou identificar o sintoma provocado por um problema.
O próximo passo para identificar as causas raízes de um problema é determinar quais os fatores contribuem para a presença do problema. O Gerenciamento Total de Qualidade (TQM – Total Quality Management) nos ensina a usar o diagrama espinha de peixe (veja na Figura 1) para identificar o problema em seu âmago. Em nossa análise específica, a companhia identifica vários recursos que contribuem para a existência do problema. Toda a fonte do problema deverá ser listada com uma das “espinhas” do diagrama.

Se o problema é mais sério, a simples indagação sobre o que é afetado por este não cria uma sensação de conforto, isto pode ser necessário para uma investigação mais detalhada de toda a contribuição do problema e da dimensão do ser impacto individual. Esta investigação pode variar de um simples brainstorm cujos participantes tenham conhecimento sobre os pontos afetados do projeto ou, potencialmente, para uma investigação científica mais rigorosa. Nesse caso, o alvo é a quantidade com que cada causa raiz contribui para o problema.

Passo 3: Identificando os stakeholders e os usuários

Efetivamente a solução de um problema complexo, tipicamente, envolve satisfazer as necessidades de um grupo diverso de stakeholders. Stakeholders têm tipicamente uma perspectiva variada do problema e uma diversidade de necessidades que devem ser satisfeitas pela solução. Define-se stakeholder como:

Alguém que pode ser materialmente afetado pela implementação de um novo sistema ou aplicação.

Muitos stakeholders são usuários do sistema e suas necessidades são facilmente fixadas, pois estão diretamente envolvidos na definição e uso do sistema. De outra forma, alguns stakeholders são apenas usuários indiretos do sistema ou são afetados, tão somente, pelos resultados do negócio que o sistema influencia. Esse stakeholders pode ser membros de Conselhos, Agências reguladoras, enfim, agentes internos ou externos ao ambiente de desenvolvimento do sistema e que, não são afetados diretamente por esse, mas sim pelos resultados gerados sob sua influência. As necessidades dos stakeholders não-usuários também devem ser identificadas e apontadas. Um entendimento de quem são os stakeholders e quais são suas necessidades, esse é um importante fator para o desenvolvimento de uma solução efetiva. A relação dos stakeholders deve seguir o formato demonstrado na tabela 2.

Outros stakeholders, como os vendedores e o supervisor são diretamente afetados pelo sistema, mas acessam o sistema por intermédio de diferentes interfaces de usuário e relatórios. De outro modo, o Chefe do departamento financeiro da empresa são stakeholders que podem sofrer influência no aumento da produtividade, qualidade e rendimento da empresa. Assim, se espera que o diretor de TI e os membros da equipe de desenvolvimento sejam também classificados como stakeholders, pois, esses serão os responsáveis diretos pelo desenvolvimento e manutenção do sistema.

Passo 4: Define a fronteira para a solução

Uma atividade super importante com relação ao desenvolvimento de softwares reside na delimitação do que está no interior da fronteira do sistema e do que reside fora desta. Ou seja, a delimitação clara das responsabilidades do sistema. A fronteira do sistema define a borda entre a solução e o mundo real em torno da solução (Figura 2). Em outras palavras, a fronteira do sistema descreve um cenário em que a solução do sistema está contida.

Passo 5: Identificar os constrangimentos impostos pela solução

Antes de despender milhares de reais em busca de uma solução revolucionária, o verdadeiro estado da arte em termos de comércio, por exemplo. Deveremos parar e considerar os constrangimentos que serão impostos pela solução. Definimos constrangimentos como:

A restrição sobre os graus de liberdade que será imposto sobre uma aplicação.

Todo constrangimento ocasiona uma severa e potencial restrição para o desenvolvimento de uma solução. Dessa forma, todo constrangimento deve ser cuidadosamente considerado como parte do planejamento de processo e, muitas vezes, esse constrangimento poderá fazer com que sejam reconsideradas abordagens tecnológicas que foram inicialmente consideradas.

Várias fontes de constrangimentos deve ser consideradas. Essas incluem agendas, retornos e investimentos, custo de produção e equipamentos, ambiente, sistemas operacionais, bancos de dados, servidores e sistemas clientes, insumos técnicos, política organizacional, licenças de software, procedimentos e recursos da empresa, ferramentas e linguagens, pessoal e outros recursos. Esses constrangimentos devem ser mapeados antes de darmos de tomarmos uma decisão. A lista apresentada na tabela 3 apresenta os potenciais recursos de constrangimento de um sistema.

Tentou-se com esse artigo dar uma idéia geral sobre a análise de risco e problemas com relação ao desenvolvimento de software. Apresentamos os tópicos principais que devem ser monitorados quando da elicitação de requisitos para a construção de um produto de software.

Sobre protótipos em projetos de software

Prototipação
Protótipo em termos de software é a materialização aproximada de um sistema e demonstra um conjunto de funcionalidades do novo sistema. A construção de um protótipo poderá ser efetiva para a elucidação de necessidades dos usuários. Os usuários poderão tocar, sentir e interagir com o protótipo fazendo com que sejam descobertas necessidades ocultas e, conseqüentemente haja, elucidação de possíveis dúvidas. A prototipação aliada com outras técnicas poderá prover a redução de retrabalho e minimização de riscos na implementação do projeto. A prototipação é muito eficiente na redução da síndrome do “Sim, mas”, “Não é exatamente isso que pensava” e a síndrome da “Ruínas ocultas” (“Só agora que percebemos isso, temos outros requisitos para adicionar”).

Tipo de protótipos

Protótipos podem ser categorizados de muitas formas. Por exemplo, Davis (1995a) categoriza protótipos como descartável verso evolucionário verso operacional, vertical verso horizontal, interface de usuários verso algoritmo e assim por diante. O tipo do protótipo depende do problema que você está tentando solucionar pela sua construção.

Por exemplo, se em seu projeto os risco estão baseados, principalmente, na viabilidade da abordagem tecnológica – essa solução nunca foi tentada antes e você está incerto quanto à aplicabilidade da tecnologia que pode afetar o desempenho ou desviar dos alvos (requisitos não funcionais de desempenho, por exemplo). Você pode decidir por realizar uma prova de conceito (que é o protótipo arquitetural) a fim de verificar a aderência da solução tecnológica. Um protótipo arquitetural pode ser descartável ou evolutivo (descartável é o protótipo que não será aproveitado no desenvolvimento. Sendo que, o termo evolutivo se refere ao protótipo que será aproveitado durante o processo de desenvolvimento). O protótipo descartável implica que o esforço empregado servirá, tão somente, para estabelecer a viabilidade, portanto, poder-se-á utilizar soluções restritas, tecnologias alternativas, simulações, cujo objetivo seja armazenar informações que o ajude na tomada de decisão. Quando a opção recai sobre a construção do protótipo descartável, os benefícios do exercício recaem sobre o aprendizado adquirido no exercício. O protótipo evolutivo implica que você implementou um protótipo com mesmos recursos e na mesma arquitetura em que será desenvolvido o sistema final e você estará habilitado a construir o sistema final a partir da evolução gradual do protótipo.

Se a área de risco primária do seu projeto reside na interface com o usuário, você deverá, então, desenvolver um protótipo de requisitos, usando tecnologias infinitas que possibilitam desenvolver de forma mais ágil o seu protótipo de interface. A figura 1, abaixo, mostra a árvore de decisão que pode ser utilizada para selecionar o modelo do protótipo que deverá ser desenvolvido, de acordo com as características do seu projeto.





Figura 1 – Árvore de decisão para seleção de protótipo: (a) protótipos para validação de requisitos; (b) protótipos para validação de arquitetura.

Protótipos para validação de requisitos

Para o propósito de elicitação de requisitos, deveremos nos fixar nos tipos de protótipos que estão representados na parte superior da árvore acima apresentada. Nós definimos um protótipo para validação de requisitos de software como:

Implementação parcial de um software cuja construção visa apoiar ao desenvolvedor, usuário e consumidores de software para melhor entender os requisitos de um sistema.

Para o processo de elicitação de requisitos, podemos construir uma interface de usuário, descartável e horizontal. “Horizontal” implica em, termos que, atentar para uma construção com ampla visão das funcionalidades do sistema; o protótipo vertical, pelo contrário, constrói apenas uns poucos requisitos, porém, atentando por implementá-los de forma qualificada. “Interface de usuários” implica que deverá ser construído mais detalhe da navegação da interface do sistema para os seus usuários diretos, do que a implementação de lógica e algoritmos que deverão residir no interior do software ou interfaces de outros módulos ou sistemas. Uma ferramenta de elicitação, como um servidor de protótipos pode conduzir aos seguintes caminhos:

· Construído pelo desenvolvedor - este pode ser utilizado para obter confirmação do usuário quanto ao entendimento sobre determinados requisitos;
· Construído pelo desenvolvedor – este pode ser usado como um catalisador para encorajar o usuário a fim de entender melhor os requisitos;
· Construído pelo usuário – este pode comunicar melhor os requisitos para o desenvolvedor.

Nesses três casos, o objetivo da construção do protótipo é construí-lo consumindo-se poucos recursos. Se for muito caro construí-lo, será melhor construir o próprio sistema!

Muitos protótipos de software tende a ser protótipos de requisitos e são usados primariamente para capturar aspectos das interfaces de usuários do sistema a ser construído. Existem, provavelmente, duas razões para isso:

1. A emergência de um projeto de baixo orçamento, sendo necessário a aplicação de ferramentas para construção de interfaces de usuário de baixo custo;
2. Para usuários de sistema com interação-intensiva, um protótipo de interface de usuários poderá revelar muitos outros requisitos ocultos inicialmente, com as funcionalidades que deverão ser providas aos usuários, onde todas as funções poderão ser avaliadas pelo usuário e que funções estão ocultas.

Na maioria das vezes, necessitamos de estar certos de que, não seremos influenciados a construir partes do sistema que não representam altos índices de risco para o projeto.

Artefatos fundamentais para registro de requisitos

1. Relação das necessidades dos stakeholders

O artefato, relação das necessidades dos stakeholders, é o documento em que se devem relacionar as necessidades dos usuários do software. Nesse artefato estarão identificadas todas as necessidades definidas pelos usuários, com indicação dos seus respectivos perfis e contatos. As necessidades devem se relacionadas já pré-classificadas como: necessidades funcionais, necessidades não-funcionais, necessidades negociais (regras de negócio). Além dessa classificação, deve ser informado qual são os usuários gestores da necessidade apontada. Necessidades afins devem ser apresentadas de forma agrupada. É importante indicar a referência sobre a identificação da necessidade, tais como, a ata e a reunião em que foi identificada, por exemplo.

2. Relação das funcionalidades do software

A partir da relação das necessidades dos stakeholders a equipe de analistas de requisitos responsáveis pela construção do software fará a identificação das funcionalidades (requisitos funcionais) a partir das necessidades classificadas como funcionais que foram definidas pelos usuários. A relação das funcionalidades deve conter, além da identificação da funcionalidade propriamente dita, as necessidades funcionais as quais estão relacionadas.

3. Relação dos requisitos não-funcionais

Da mesma forma que o procedimento anterior, deverá ser feito à identificação dos requisitos não-funcionais, a partir das necessidades classificadas como não-funcionais que, também, foram definidas pelos usuários. Os requisitos não-funcionais deverão ser classificados e agrupados por categoria, segundo a relação abaixo: Requisitos de sistemas, requisitos de desempenho, requisitos de ambiente, requisitos de usabilidade, requisitos de confiabilidade, requisitos de suportabilidade, requisitos de segurança, requisitos de documentação. Oportunamente, falaremos sobre cada uma dessas classificações.

4. Diagrama geral de relacionamento entre casos de uso

A UML (Unified Modeling Language) nos ajuda a descrever os relacionamentos entre os casos de usos envolvidos no desenho do software. Para se definir esse diagrama, inicialmente, é necessário definir cada um dos casos de uso do sistema. Um caso de uso se resume num conjunto (agrupamento) de funcionalidades que serão desenvolvidas no software para resolver cada uma das necessidades levantadas. Cada caso de uso, deve ser ater as suas responsabilidades específicas e, pelos relacionamentos com outros casos de uso, compor o conjunto de funcionalidades necessárias para o bom funcionamento do software. A boa arquitetura de cada um desses casos de uso desenhados definirá uma boa arquitetura final para o software em questão.
No diagrama de relacionamento entre os casos de usos deverão estar representados os relacionamentos entre os atores e os ‘seus’ casos de uso e entre os casos de usos relacionados.

5. Relação das regras gerais e específicas dos casos de uso

Um outro artefato muito importante no processo de gerenciamento de requisitos é a relação de regras gerais e específicas dos casos de uso para o software. É comum, encontrarmos as regras específicas para os casos de uso descritas na própria especificação de caso de uso. Pessoalmente, eu não gosto muito desse agrupamento, pois na minha visão pessoal a especificação de caso de uso não deve ser apenas um documento de negócio é sim, um documento fundamental para o processo de construção do software incluindo-se nesse artefato conceitos relacionados a navegabilidade quando necessário. Claro que, quando se trata de um projeto complexo, podemos optar por construir o artefato especificação geral de interfaces e, quando necessário, pode-se ter também a especificação de interface de um determinado caso de uso. Desta feita, o que deve ser validado pelo usuário, segundo o meu ponto de vista, são as regras de negócio, tanto as especificas (que dizem respeito a um caso de uso específico) quanto as gerais (que dizem respeito a mais de um caso de uso). Prefiro que a validação de navegabilidade seja feita diretamente por intermédio de um protótipo medianamente funcional. As regras gerais ou especificas devem ser listadas com seus respectivos identificadores (código, nome reduzido, nome completo), teor da regra (contendo inclusive as operações aritméticas quando necessário e, conseqüentemente, exemplos que esclareçam o texto), identificação do stakeholder responsável pela definição da regra.

6. Matriz de rastreabilidade entre funcionalidades x necessidades x regras gerais x casos de uso

A matriz de rastreabilidade é um artefato muito importante nesse processo e um dos mais trabalhosos, em razão, da exigência de atualizações a que estará submetido. Qualquer alteração deverá ser registrada assim que consolidada. As rasteabilidades fundamentais são as que relacionam funcionalidades com necessidades; regras com funcionalidades e necessidades; casos de uso com funcionalidades e necessidades e regras com casos de uso. Existem muitas formas de se manter esse relacionamento, sendo a mais simples o registro em células de planilhas eletrônicas.

7. Especificação de caso de uso

A especificação de caso de uso pode ser um documento muito importante e de muita utilização no processo de construção de software ou apenas um artefato alegórico e que não ‘serve pra nada’. Eu prefiro, trabalhar com especificações que documentem realmente o software que está sendo desenvolvido. Portanto, deve-se evitar construir um caso de uso puramente negocial para se validado pelo usuário como, normalmente, vemos. É comum, construir especificação de caso de uso com a finalidade de fixar os requisitos junto aos usuários. Porém, como a linguagem adequada ao artefato não é fácil ao usuário comum, muitas vezes obriga-se o mesmo a se qualificar na linguagem. Em minha experiência, alguns usuários perdem-se em discutir a forma do documento (o que é fluxo alternativo, fluxo de exceção, entre outros) e não discute o teor das informações que são importantes para a construção do aplicativo. Por isso, eu opto por registrar as regras em documentos próprios e na especificação teremos apenas a navegabilidade, que deverá ser empregada no sistema (desenho dos processos dos casos de uso de uma determinada interface). Portanto, meu conceito de caso de uso é o de caso de uso de implementação e não apenas um documento negocial.
Essa especificação pode ser classificada em caso de uso comum e caso de uso CRUD [agrupamento dos processos básicos: Create (Inserir), Retrieve (Consulta), Update (Atualização) e Delete (Exclusão)]. Pode-se definir no CRUD outros processos além dos acima citados.
Uma especificação deve apresentar os seguintes fluxos:
Fluxo básico;
Sub-fluxos;
Fluxo alternativo;
Fluxo de exceção.

8. Projeto de interfaces

Um projeto de interfaces bem elaborado pode facilitar o processo de construção, além de reduzir o próprio tempo, em termos de cronograma, nessa fase. Os usuários, muitas vezes têm dificuldade em validar texto, uma interface com navegação básica, facilitará sobremaneira essa processo. Eu sempre opto por construir protótipos medianamente funcionais utilizando-me de HTML (Hiper Text Markup Language), quando se desenvolve um aplicativo que deverá obedecer a um determinado padrão de interface, o melhor já será incorporar partes desses padrões ao projeto. O tempo consumido na construção de um bom projeto de interface reduzindo o retrabalho com testes funcionais e de navegabilidade e, também, o retrabalho.