Elicitação e definição de requisitos baseada em meta-avaliação: o caso do Censo CRAS 2008

Resumos

O Ministério do Desenvolvimento Social e Combate à Fome (MDS) promove periodicamente a avaliação dos seus programas sociais, como aqueles desenvolvidos nos Centros de Referência em Assistência Social (CRAS). Essa avaliação utiliza como instrumento um sistema web que suporta o processo de coleta e tratamento de informações e disseminação de resultados aos gestores municipais, estaduais e federais mediante o chamado Censo CRAS. Conduziu-se uma meta-avaliação do CRAS 2008, baseada nos critérios especificados peloJoint Committee (1994), a partir da qual foram elicitados requisitos que possibilitaram a melhoria do referido sistema web. Neste artigo são relatados os resultados da meta-avaliação do Censo CRAS 2008, realizada no período de 2009 a 2010, na qual novos requisitos foram elicitados. A abordagem da meta-avaliação como fonte alternativa de elicitação de requisitos considerou os resultados de avaliações de programas sociais para identificar os problemas do sistema, sem a necessidade da usual e intensa interação com usuários, e revelou oportunidades de melhorias no processo de avaliação que conduziram à elicitação de requisitos para o sistema informatizado. Algumas funcionalidades elicitadas foram incorporadas ao Censo CRAS 2010 e outras poderão ser incorporadas em censos futuros.

Elicitação de requisitos; Avaliação; Meta-avaliação

The Brazilian Ministry of Social Development and Fight against Hunger (MDS) regularly promotes the evaluation of its social programs, such as those developed in the Reference Centers for Social Assistance (CRAS). Such evaluations make use of a web system that supports the collection and processing of information as well as the dissemination of its results to local, regional and central government officials through the so-called CRAS Census. A meta-evaluation of the CRAS 2008 Census was carried out based on criteria specified by the Joint Committee (1994), from which we elicited requirements that enabled improvements of the web system. The article reports new requirements elicited from the meta-evaluation of the CRAS 2008 Census, held in the period 2009-2010. The approach of meta-evaluation as an alternative source of requirements elicitation took into consideration results from evaluations of social programs in order to identify system problems without the usual need of intense interaction with users. This approach revealed opportunities for improvements in the evaluation process that led to the elicitation of requirements for the computerized system. Some of the elicited features were incorporated into the Census 2010 and others may be incorporated in future censuses.

Requirements Elicitation; Evaluation; Metaevaluation

1. Introdução

Engenharia de Requisitos, no contexto da Engenharia de Software, pode ser entendida como uma importante ação que perpassa as atividades de comunicação e modelagem, de modo a construir uma ponte entre a necessidade de um software e seu projeto e implementação (PRESSMAN, 2010, p. 120).

Para o IEEE (1990), os itens que compõem os requisitos de um sistema são: (i)as condições ou potencialidades requeridas por um usuário para resolver um problema ou atingir um objetivo; (ii) as condições ou potencialidades que um sistema, componente ou produto deve exibir para que seja aceito e(iii) a expressão documentada desses itens.

Pressman (2010, p. 121) categoriza as tarefas de Engenharia de Requisitos em concepção, levantamento, elaboração, negociação, especificação (modelagem), gestão e validação dos requisitos de um software, alertando para a possibilidade de sobreposição destas atividades no tempo, conforme as necessidades do projeto. Este trabalho detalha um caso específico de elicitação de requisitos funcionais, não funcionais e regras de negócio no âmbito dos sistemas de informação utilizados na avaliação do Censo CRAS 2008^[1].

No caso aqui tratado, não se parte de entrevistas com os clientes para descobrir o que eles esperam ou desejam do software, mas sim de uma análise crítica utilizando os padrões de avaliação aceitos pela comunidade da área de meta-avaliação (COOSKY; CARACELLI, 2009) como principal insumo para a descoberta de novos requisitos.

2. O caso estudado

Os Centros de Referência de Assistência Social (CRAS) são unidades geridas pelo Ministério do Desenvolvimento Social e Combate à Fome (MDS), instaladas nos 5.560 municípios brasileiros, onde são prestados serviços de assistência social. Parte do financiamento destes centros é assegurada pelo Governo Federal, através do MDS, e a gestão é de responsabilidade dos municípios. Sua estrutura descentralizada, por um lado levou à maior participação dos municípios, mas por outro dificultou o acompanhamento da implantação das políticas nos municípios e a gestão da qualidade desse processo por parte do Governo Federal.

Por isso, no ano de 2007, o MDS, por meio da Secretaria de Avaliação e Gestão da Informação (SAGI) e da Secretaria Nacional de Assistência Social (SNAS), realizou um censo para quantificar, identificar e coletar informações dos CRAS. A SAGI foi responsável pelo desenho, criação e desenvolvimento e tem mantido os sistemas de informação e a SNAS pela mobilização, definição do sistema e pelo atendimento aos municípios. Para este censo, foi disponibilizado pela SAGI um site na Internet onde o gestor municipal insere as informações relativas aos CRAS do seu município.

Também em 2007, foi realizada uma coleta de dados quanto à localização, recursos humanos, estrutura física e capacidade de articulação com outros órgãos públicos e privados. Os primeiros resultados do censo levaram o MDS a propor indicadores e patamares a serem alcançados pelos CRAS para a prestação dos serviços, estrutura física e qualidade a serem medidos em futuros censos. Desta forma, o que seria somente um censo passou a ter um caráter avaliativo, pois subsidiou a delimitação de critérios que seriam utilizados para aferir a qualidade da oferta dos serviços nos CRAS.

Nos anos seguintes, além dos censos anuais dos CRAS, foram realizados censos dos Centros Especializados de Referência de Assistência Social (CREAS), dos conselhos municipais e estaduais de assistência social e da gestão da assistência social. Contudo, o processo avaliativo com indicadores e critérios de avaliação foi implantado primeiramente a partir do Censo CRAS realizado em 2007. (BRASIL, 2008a). Os resultados dessa avaliação foram publicados em 2010.

O processo avaliativo do Censo CRAS foi pioneiro nas duas secretarias envolvidas, no sentido de utilizar uma abordagem apoiada em sistemas de informações, indicadores, capacitação e mobilização para aperfeiçoamento da tomada de decisão da gerência Estadual e Federal baseada em dados relativos a dezenas de variáveis coletadas nos municípios brasileiros.

Como todo processo avaliativo pode ser objeto de aprimoramento em seus diversos aspectos, como em sua qualidade e precisão (POSAVAC; CAREY, 2003), nesta pesquisa analisou-se o processo com base nos padrões de avaliação propostos pelo Joint Committee (1994), realizando uma meta-avaliação. De acordo com Hedler (2007, p. 59), meta-avaliação é “um método de pesquisa a partir do qual são reanalisadas uma ou mais etapas do(s) estudo(s) avaliativo(s) já concluído(s); compara-se a avaliação anterior com padrões de qualidade e validade aceitos pela comunidade científica e ao final emite-se nova avaliação sobre o estudo avaliativo analisado”. Os padrões foram utilizados como ferramenta para realização de meta-avaliação, conforme trabalho realizado porHedler (2007), e aplicados ao processo do Censo CRAS realizado em 2007.

Na meta-avaliação utilizaram-se os padrões propostos pelo Joint Committee (1994) para subsidiar os melhoramentos nos sistemas de informação utilizados no censo. Ou seja, realizou-se uma elicitação de requisitos por meio de resultados de uma meta-avaliação.

3. Referencial teórico

3.1 Engenharia de Requisitos

A Engenharia de Software (ES), como área de pesquisa, provê ajuda metodológica para a elaboração/construção de softwares. Ela possui técnicas, métodos e padrões que podem ser utilizados no ciclo de vida de um software.

Em geral, a fase inicial do desenvolvimento de um sistema é apoiada pela Engenharia de Requisitos (ER). A ER é uma subárea da ES responsável pela definição dos objetivos e delimitações do software (Pressman, 2006, p. 116;Paula Filho, 2009; p. 165; Wiegers, 2003, p. 380). Também existem padrões como o Capability Maturity Model Integration(CMMI), adotado pelo mercado e pela academia, com processos destinados especificamente à elaboração de requisitos: definição de requisitos (SEI, 2010, p. 325) e gestão de requisitos (SEI, 2010 p. 341).

Wiegers (2003, p. 47) divide as atividades da ER relacionadas ao desenvolvimento de requisitos em:(i) elicitação, (ii) análise,(iii) especificação e (iv) validação. A etapa de elicitação de requisitos tem como foco a descoberta e a comunicação entre os desenvolvedores com os clientes. Caso esta comunicação inicial falhe, o software tende a não atender às necessidades e às expectativas do cliente. Esta é a fase mais crítica com relação à comunicação entre o desenvolvedor de software e o cliente (Wiegers, 2003, p. 115). Entrevistas, coleta de informações e discussões em grupo são os principais procedimentos metodológicos empregados nessa fase.

Pressman (2006, p. 118) aponta ainda os principais problemas na elaboração de requisitos: (i) problemas com o escopo do projeto,(ii) de entendimento do problema e(iii) na volatilidade ou mudança dos requisitos durante o projeto. Somam-se a estes, problemas apontados por Saiedian e Dale (1999): (i) a comunicação pobre, (ii) a resistência à mudança pelos envolvidos, (iii) os problemas de articulação entre os envolvidos e (iv) as perspectivas diferentes entre os interessados. Nesse sentido, o Software Engineering Institute (SEI) com o CMMI, a Softex (2009) com o Guia Geral Programa de Melhoria de Processo do Software Brasileiro (MPSBR) e outras organizações tentam minimizar estes problemas com a documentação de padrões para serem utilizados na fase de requisitos.

Entre os possíveis insumos para a descoberta de requisitos estão (SEI, 2010, p. 329-330):(i) questionários, entrevistas e cenários,(ii) protótipos e modelos, (iii)questionários de mercado, (iv) brainstorm,(v) casos de uso, (vi) análise de casos de negócio, (vii) testes de softwares,(viii) demonstração de tecnologia,(ix) políticas do negócio,(x)produtos legados, (xi) estatutos regulatórios e (xii) padrões. Neste trabalho, a produção de requisitos foi realizada com base em padrões de avaliação de programas.

Com base nos conceitos da ES e nos processos da ER preconizados pela IEEE (1990), e considerando-se também o padrão de qualidade de software ISO 9126^[2] e o conceito de Gestão de Processo de Negócio – BPM^[3], foi construído um processo chamado de eXtreme Requirements (XR), proposto por Castro e Guimarães (2010), para a produção de requisitos segundo as fases: análise de negócio, proposta de solução, definição de requisitos, prototipação, teste e gerência de requisitos.

O XR classifica os requisitos em não funcionais, funcionais, complementares e regras de negócio. Requisitos funcionais são as funcionalidades ou atividades que o sistema deve fazer. Os requisitos complementares são as características e propriedades de detalhamento dos requisitos funcionais. Regras de negócio são provenientes do contexto organizacional, tais como as normas, condições e padrões para executar cada funcionalidade. Requisitos não funcionais são as características de qualidade do software.

3.2 Avaliação

Para Worthen, Sanders, Fitzpatrick (2007, p. 35), uma avaliação refere-se à identificação, esclarecimento e aplicação de critérios defensáveis para determinar o valor, mérito, a utilidade, eficácia ou importância do objeto avaliado. Stufflebeam e Shinkfield (2007, p.16) definem avaliação como um processo sistemático para delimitar, obter, reportar, descrever e julgar a informação sobre o mérito, o valor, a integridade, a viabilidade, a segurança e a significância ou equidade de algum objeto. Weiss (1997, p. 4) afirma que avaliação é um modo de atestar de forma sistemática a operação e os resultados da política ou programa comparados com um conjunto de padrões como meio de contribuir para a melhoria do programa ou política.

Observa-se, por essas definições, que avaliações devem julgar ou esclarecer alguma questão com base em padrões ou critérios, de forma a qualificar um programa social, uma pessoa, uma organização ou um processo. Assim, a primeira definição é a mais abrangente, por sua generalidade e por não se limitar especificamente a programas sociais, tendo sido a norteadora desta pesquisa no que concerne ao entendimento de avaliação.

Segundo Worthen, Sanders e Fitzpatrick (2007, p. 44), os resultados de uma avaliação podem trazer aprimoramento ao objeto, programa ou política avaliada. Em contraposição, uma avaliação mal construída e mal aplicada pode levar seus gestores a decisões equivocadas. A razão de fracasso de uma avaliação pode ser o mau planejamento metodológico e até mesmo a falta de ética das pessoas ou organizações envolvidas no processo avaliativo.

A necessidade de atestar a qualidade e aperfeiçoar a construção de novas avaliações levou diversas organizações e autores a proporem padrões. Estes padrões podem ser utilizados como mecanismos de meta-avaliação.

Segundo Stufflebeam (2001), "meta-avaliação é o processo de delinear, obter e aplicar informações descritivas e de julgamento de uma avaliação a respeito de sua utilidade, viabilidade, propriedade e precisão, e a natureza sistemática, competência, integridade/honestidade, respeitabilidade e responsabilidade social desse processo para orientar a avaliação e publicamente relatar suas forças e fraquezas". Entre os padrões de avaliação disponíveis estão oEducational Evaluation Standards, do Joint Committee(1994); o Guiding Principles for Evaluators, daAmerican Evaluation Association (AEA, 2004); e oGovernment Auditing Standards, do U.S. Government Auditing Office (USGA, 2007).

O Joint Committee foi formado por um grupo de autores na área de avaliação que trabalharam em conjunto entre os anos de 1970 e 1990 discutindo conjuntos de padrões destinados a guiar e avaliar a construção de avaliações. Ele propõe 30 padrões divididos em quatro grupos, criados para subsidiar a avaliação de programas e projetos educacionais, visando estimular e melhorar o diálogo entre os profissionais envolvidos em avaliações. O Joint Committee (1994, p. 4), no entanto, encoraja o uso de padrões de outros métodos de avaliação que, de acordo com Stufflebeam e Shinkfield (2007, p. 92), são também aplicáveis a meta-avaliações.

O Guiding Principles for Evaluators (AEA, 2004) conta com cinco princípios: (i) inquérito sistemático,(ii) competência, (iii) integridade e honestidade, (iv) respeito às pessoas e(v) responsabilidade pelo bem-estar geral e público. Para Stufflebeam e Shinkfield (2007, p. 110), no entanto, esses princípios já são contemplados pelos padrões doJoint Committee.

Os princípios orientadores do Government Auditing Standards(USGA, 2007) foram propostos para garantir a realização de auditorias de alta qualidade, essenciais para a prestação de contas e transparência dos investimentos dos recursos públicos. Para isso, auditorias devem ser objetivas, baseadas em fatos, imparciais, capazes de medir o desempenho dos programas e disponibilizar informação para a tomada de decisão. Segundo Stufflebeam e Shinkfield (2007), estes padrões também se aproximam da proposta do Joint Committee e tratam de padrões para independência da auditoria, julgamentos dos profissionais, competência, controle e qualidade, trabalho em campo, relatórios e desempenho de auditoria.

Os padrões Joint Committee, USGA e AEA, tal como os sugeridos por Stufflebeam e Shinkfield (2007, p. 109), são variados em detalhes e orientações, não se contradizem e se complementam. Diante do exposto, para este trabalho, foram adotados os critérios do Joint Committee (1994).

4. Aspectos metodológicos

Este trabalho parte do pressuposto de que uma avaliação que envolve Sistemas de Informação (SI) é passível de ser meta-avaliada objetivando gerar insumos para a elicitação de requisitos de software visandoaperfeiçoamento de futuras avaliações. A Figura 1 ilustra este pressuposto, segundo uma visão de melhoria contínua expressa na forma de uma espiral com ponto de partida na avaliação informatizada.

Figura 1
- Ciclo de aprimoramento de sistemas de avaliação por meio de meta-avaliação que utilizem Sistemas de Informação

4.1 Definição de método para o estudo de caso: Censo CRAS 2008

Para a identificação de novos requisitos no processo avaliativo dos CRAS, analisou-se a avaliação presente no Censo CRAS 2008. Foi realizada uma elicitação de requisitos baseada nos resultados da meta-avaliação utilizando os padrões propostos pelo Joint Committee (1994). Esta meta-avaliação envolveu uma investigação através de entrevistas, documentos e normas do processo.

A escolha dos padrões do Joint Committee se deve à sua generalidade, abrangência e ampla aceitação pela comunidade científica (COOSKY e CARACELLI, 2009). Ademais, estes padrões sugerem recomendações e erros comuns em avaliações, permitindo sua utilização como guia para a identificação de pontos fracos no processo avaliativo cuja solução possa envolver o emprego das Tecnologias da Informação e Comunicação (TIC). No Quadro 1 são apresentados os documentos, sistemas e entrevistas averiguados na meta-avaliação dos CRAS.

No Joint Committee(1994) existem padrões para verificar a propriedade, utilidade, viabilidade e precisão de uma avaliação. Optou-se pela análise de três padrões: (i) Avaliação Completa e Justa,(ii) Informação Sistemática e (iii)Conclusões Justificadas. Esses padrões foram escolhidos por uma comissão de três profissionais sêniores de TIC que concordaram que esses padrões estão associados à identificação de novos requisitos de software.

Como detalhado no Quadro 1, os principais insumos para a realização da meta-avaliação foram:(i) o relatório da avaliação (BRASIL, 2010), (ii) a entrevista semiestruturada com um especialista do negócio, (iii) o Sistema Gerente CRAS 2008 (BRASIL, 2008b) e (iv) a entrevista semiestruturada com o especialista de TI do MDS. Ambos os entrevistados participaram do processo avaliativo. O especialista do negócio acompanhou o processo avaliativo CRAS 2008, desde a formulação de questões até o desenvolvimento do relatório final da avaliação. O especialista de TI participou do desenvolvimento e acompanhou os processos de informação da avaliação CRAS 2008. Esses insumos, de acordo com os preceitos de Coosky e Caracelli (2009), são frequentemente utilizados em processos de meta-avaliação.

Quadro 1
- Recomendações e principais erros conforme orientações doJoint Committee (1994)

Para a realização da definição de requisitos, foi utilizado o artefatoDocumento de Definição de Requisitos (DDR), proposto por Castro e Guimarães (2010) e que faz parte do eXtreme Requirements. Esse artefato busca identificar os requisitos de software, as regras de negócio, a matriz de rastreabilidade e a priorização dos requisitos a partir dos processos de negócio avaliados. Neste documento, são definidos os seguintes itens:(i) requisitos funcionais, (ii)requisitos complementares, (iii) requisitos não funcionais,(iv) regras de negócio, (v) fluxo de processo, (vi) lista de usuários e (vii)análise de risco. Não se considerou a rastreabilidade de requisitos, pois o objetivo de subsidiar a gerência de requisitos não é o foco deste trabalho.

5. Resultados da meta-avaliação CRAS 2008 e elicitação de requisitos

De acordo com o padrão “Avaliação Completa e Justa”, uma avaliação deve apontar pontos positivos e negativos e limitações do programa avaliado, possibilitando a valorização de aspectos do sucesso do programa e a correção de falhas existentes. No Quadro 2 é apresentado um resumo dos resultados da análise dos dados coletados em função desse padrão.

Quadro 2
- Análise do padrão “Avaliação Completa e Justa”

Recomendações	Resultados	Aperfeiçoamentos de TI
1. Os relatórios devem indicar os pontos fortes e fracos da avaliação e justificá-los	Sim	-
2. Existência de comentários críticos e meticulosos pelos envolvidos no processo antes da publicação dos resultados	Parcialmente	Disponibilização de uma ferramenta transacional para registro dos comentários
3. Reportar as restrições quanto a custo e tempo para a realização da avaliação	Não	Pode-se utilizar um sistema de informação financeiro/contábil para registro dos gastos ou a utilização de algum software de gerência de projetos
Principais erros	Resultados	Aperfeiçoamentos de TI
4. Manipulação dos relatórios dos pontos fracos e fortes para favorecimento de indivíduos ou grupos	Indeterminado	É possível a utilização de agentes de software para verificar todos os dados publicados Disponibilização de ferramenta transacional para que os Estados validem os dados
5. Promoção ou proteção dos interesses pessoais dos avaliadores ou viés na avaliação	Não	-
6. Reportar julgamentos ou interpretar achados de pontos fortes e fracos sem considerar outras perspectivas que possam alterar as conclusões	Parcialmente	Disponibilização de ferramenta transacional para que os Estados e Municípios emitam sua opinião
7. Reportar de maneira especulativa ou tentar encontrar modos no processo de apresentar resultados de forma que os pontos fracos e fortes estejam controlados	Sim	-
8. Não mostrar quais foram os métodos para a definição de pontos fortes e fracos	Não	-
9. Reportar somente pontos negativos	Não	-

Segundo o padrão “Informações Sistemáticas” do Joint Committee (1994), a informação coletada, processada e incluída em relatórios deve ser sistematicamente revisada e qualquer erro encontrado deve ser corrigido. O resultado da análise deste padrão para o problema em questão é mostrado no Quadro 3. Os principais aperfeiçoamentos de TI encontrados na análise desse padrão foram relativos à comunicação com os envolvidos na avaliação e autenticação dos usuários.

Quadro 3
- Análise do padrão “Informação Sistemática”

Recomendações	Resultados	Aperfeiçoamentos de TI
1. Assegurar que a equipe da avaliação esteja treinada para seguir as regras da coleta de dados	Sim	-
2. Sistematicamente verificar erros na coleta, processamento e disseminação da informação como forma de garantir a qualidade do processo	Parcialmente	Aperfeiçoar o componente de coleta de dados no sentido de melhorar os aspectos de interação com o usuário
3. Utilizar auditorias externas para verificar a entrada de dados	Parcialmente	O sistema deve possibilitar a comunicação formal de problemas encontrados por auditorias externas nos dados
4. Manter o controle da informação original para que a integridade da informação possa ser protegida	Sim	-
5. Adotar e implementar padrões e procedimentos para recuperação da informação	Sim	-
6. Criar rotinas com os envolvidos para confirmar se os dados estão precisos	Parcialmente	O Sistema Gerente deve possibilitar a visualização dos dados coletados pela sociedade organizada, com um canal de comunicação para relatar erros ou pedir esclarecimentos
Principais erros	Resultados	Aperfeiçoamentos de TI
7. Assumir que quem coleta informações segue as regras estabelecidas	Não	-
8. Assumir que os responsáveis leem, entendem e seguem as instruções que lhes foram dadas	Sim	Melhorar o processo de autenticação do sistema para garantir que quem foi treinado foi o mesmo profissional que preencheu o sistema
9. Verificar a precisão dos instrumentos de coleta de dados	Parcialmente	Melhorar o processo de teste das ferramentas
10. Assumir que os resultados de testes realizados por máquinas estão corretos somente porque foram realizados por máquinas	Não	-
11. Falhar na gerência de grande volume de informação	Não	-
12. Contratar pessoas inexperientes	Parcialmente	-
13. Ignorar o controle de grande volume de informação	Não	-
14. Falhar ao controlar o acesso à informação	Parcialmente	Aperfeiçoar o mecanismo de autenticação do sistema

Em seu padrão “Conclusões Justificadas”, o Joint Committee (1994) defende que as conclusões de uma avaliação devem ser explicitamente justificadas para que possam ser analisadas pelos principais interessados/afetados pela avaliação e/ou programa. Um resumo dos resultados da análise deste padrão é apresentado noQuadro 4. O principal aperfeiçoamento de TI encontrado na análise deste padrão foi permitir que os envolvidos pudessem fornecer um feedback com relação a todo processo de avaliação.

Quadro 4
- Análise do padrão "Conclusões Justificadas"

Recomendações	Resultados	Aperfeiçoamentos de TI
1. Desenvolver conclusões que respondam simultaneamente às questões da avaliação e reflitam de forma confiável os processos e os achados	Sim	-
2. Relacionar as conclusões com as informações coletadas	Sim	-
3. Gerar, avaliar e reportar conclusões alternativas e indicar por que essas conclusões não foram utilizadas	Não	-
4. Limitar quais foram as situações, tempo, pessoas, contextos e propósitos para cada achado da avaliação	Sim	-
5. Cautela da equipe ao interpretar os dados encontrados	Sim	-
6. Solicitarfeedback dos participantes da avaliação sobre a credibilidade e interpretação, explicações, conclusões e recomendações antes de terminar o relatório	Não	Coletar dados através de sistema de informação relacionados ao feedback dos participantes
Principais erros	Resultados	Aperfeiçoamentos de TI
7. Concentrar em responder questões dos envolvidos sem a preocupação com as limitações dos procedimentos da avaliação e dados	Não	-
8. Basear as conclusões em informações insuficientes ou em informações inadequadas	Não	-
9. Ser muito cauteloso na interpretação dos resultados da avaliação	Não	-
10. Falhar ao reportar as limitações da avaliação	Sim	-

A seguir, a título de exemplo, o resultado completo da análise para o padrão “Avaliação Completa e Justa”, sendo que os itens 1, 2 e 3 correspondem às recomendações e os demais (de 4 a 9) aos principais erros:

1. Foram identificados no Sistema Gerente todos os indicadores para cada CRAS que apontam dados positivos e negativos. Nesse sistema, não há informações sobre a metodologia utilizada para a geração desses indicadores. Contudo, essa informação consta do relatório da avaliação (BRASIL, 2010, p. 137-173).

2. Não foi encontrado, tanto no Sistema Gerente como no relatório final, qualquer registro de comentário de outros envolvidos. Questionado sobre isso, o especialista do negócio informou que ocorreram encontros com os representantes dos Estados, Municípios e do Governo Federal para criticar o processo avaliativo, contudo nada foi documentado. Como forma de registro de informação, é possível, por exemplo, utilizar-se um sistema de informação transacional integrado com o gerente que permita aos gestores municipais e estaduais realizarem críticas aos dados e indicadores a serem publicados.

3. Nada consta no relatório ou no Sistema Gerente. Existem sistemas de informação financeiros e contábeis que poderiam ser utilizados na avaliação. Também é possível a utilização de sistemas de gerenciamento de projetos.

4. Nenhuma inconsistência foi detectada. Contudo, a análise dos dados demanda uma investigação mais profunda que poderia ser realizada, por exemplo, por um agente de software^[4] que compararia os resultados com os dados originais. Os Estados podem também verificar os resultados via Sistema Gerente e com apoio de um sistema para registro de dados e informações sobre manipulação de qualquer relatório.

5. Consultado, o especialista do negócio afirmou que, segundo ele, não houve nenhuma promoção ou proteção de interesses do MDS.

6. Não há no Sistema Gerente ou no relatório final qualquer informação sobre outras possíveis perspectivas de análise dos dados e indicadores apresentados.

7. Segundo o especialista do negócio, o processo de produção de indicadores foi realizado de forma a não prejudicar extremamente os CRAS e Municípios.

8. No relatório da avaliação estão disponíveis os métodos de definição de pontos fortes e fracos (BRASIL, 2010 p. 137-173).

9. Tanto o Sistema Gerente como o relatório de avaliação apresentam pontos fracos e fortes de cada CRAS.

Uma síntese dos pontos fracos encontrados e as respectivas recomendações para a área técnica de informática é mostrada no Quadro 5. Esse quadro resume a elicitação de requisitos baseada na meta-avaliação.

Quadro 5
- Resumo dos resultados da elicitação de requisitos a partir da meta-avaliação do Censo CRAS 2008

Padrões	Pontos Fracos	Recomendações
Avaliação Completa e Justa	A falta de comentários críticos e meticulosos pelos envolvidos no processo de avaliação antes da publicação dos resultados	1. Disponibilização de uma ferramenta transacional para registro dos comentários
	Não foram reportadas questões de custos e tempo nos relatórios	2. Pode-se utilizar um sistema de informação financeiro/contábil para registro dos gastos ou a utilização de algum software de gerência de projetos
	Publicar relatórios sem considerar outras perspectivas	3. Construção de ferramenta transacional para registro de opiniões dos Estados e Municípios
Informação Sistemática	Verificação de erros na coleta de dados	4.1 É possível utilizar de agentes de software para verificar todos os dados publicados 4.2 Disponibilização de ferramenta transacional para que os Estados validem os dados
	Inexistência de auditorias externas para validar os dados	5. A checagem e a conferência de dados poderiam ser mais formais através de ferramenta de colaboração que contasse com a participação dos Estados e Municípios
	Inexistência de rotinas que validem os dados pelos envolvidos	6. A checagem e conferência de dados poderia ser mais formal através de ferramenta de colaboração que contasse com a participação dos Estados e Municípios
	Assumir que os envolvidos leem e entendem as instruções da coleta de dados	7. Melhorar o processo de autenticação do sistema para garantir que quem foi treinado foi o mesmo profissional que preencheu o sistema
	Verificação dos instrumentos da coleta de dados	8. Melhorar o processo de teste da ferramenta
	Falha no controle e acesso à informação	9. Melhorar o processo de autenticação
Conclusões Justificadas	Solicitarfeedback dos participantes da avaliação sobre a credibilidade e interpretação, explicações, conclusões e recomendações antes de terminar o relatório	10. Coletar dados, através de sistema de informação, relacionados ao feedbackdos participantes

6. Definição de requisitos de software

Com base nas recomendações levantadas durante a meta-avaliação do Censo CRAS 2008, formulou-se uma definição de requisitos desejáveis para a melhoria das soluções de TIC disponíveis no contexto das avaliações dos CRAS. Para isso, optou-se pela construção dos requisitos para as recomendações 1, 3, 4.2, 5, 6, 7, 9 e 10, apresentadas no Quadro 5. Essas recomendações dizem respeito ao registro de informações e comentários dos Estados e Municípios quanto aos dados coletados ou às conclusões da avaliação. Desta forma, a construção de um sistema que disponibilize um canal de comunicação formal entre os níveis federal, estadual e municipal, e que se integre ao sistema Gerente CRAS, caracteriza uma forma de implantar as recomendações sugeridas pela meta-avaliação. As recomendações 2, 4.1 e 8 não foram consideradas por não estarem diretamente relacionadas a uma atividade de concepção e desenvolvimento de sistemas de informação.

6.1 O fluxo de atividades do Censo CRAS 2008

O fluxo de atividades de avaliação dos CRAS 2008 é apresentado na Figura 2. Nesta figura, cada coluna representa um dos três atores envolvidos no processo (MDS, Estados e Municípios) e as atividades sob a responsabilidade de cada um deles. Ele se inicia com a disponibilização, por parte da equipe técnica e negocial do MDS, do questionário online para preenchimento pelos gestores dos CRAS. Os questionários preenchidos são analisados pela equipe técnica e negocial do MDS e disseminados para os Estados e funcionários do MDS por meio do Sistema Gerente CRAS. No entanto, comentários, críticas e informações suplementares dos Estados só podem ser feitos de modo informal e não controlada. Sendo assim, o MDS é o único responsável pela análise e interpretação dos dados e pela geração das conclusões da avaliação. Ou seja, não há participação formal dos Estados e Municípios no processo de análise.

Figura 2
- Fluxo de atividades do Censo CRAS 2008

No processo sugerido (Figura 3), acrescentou-se um componente de comunicação da avaliação dos CRAS (MODCCRAS) entre MDS, Estados e Municípios. Esse componente permite o registro formal de comentários e perguntas e a verificação de dados por todos os envolvidos na avaliação. Desta forma, eles podem opinar sobre o processo de avaliação e informações geradas. Essas opiniões podem ser consideradas para a análise e para subsidiar a decisão de se realizar novos tratamentos da informação. Entre os resultados da avaliação estão os problemas encontrados na execução das políticas referentes aos CRAS, potencialmente úteis para a reformulação dessas políticas.

Figura 3
- Fluxo de atividades proposto

6.2 Requisitos

Para a implementação do processo descrito na Figura 3, propõe-se os requisitos funcionais, requisitos complementares, regras de negócios e requisitos não funcionais, respectivamente apresentados nos Quadros 6, 7, 8 e 9.

Quadro 6
- Requisitos funcionais

Id	Descrição
- Componente Comentários/Críticas
RF1:	O sistema deve registrar todos os comentários/críticas dos gestores do MDS/Estados/Municípios (RC1, RC2, RNG1, RNG2, RNG25)
RF2:	O sistema deve registrar comentários/críticas sobre cada tabela, gráfico e mapa disponível no Sistema Gerente CRAS (RC1, RC2, RNG3)
RF3:	O sistema deve permitir aos usuários do MDS a exclusão de críticas e comentários (RNG5, RNG6)
RF4:	Gerar consulta: quantitativo de comentários (RC3)
RF5:	Pesquisar por comentários/críticas que contenham palavras específicas (RC4, RNG7)
RF6:	Pesquisar todos os comentários de um determinado usuário (RC5)
RF7:	Pesquisar quantidade de acessos de usuários (RC6)
RF8:	Gerar consulta: listar comentários/críticas não respondidas (RC7, RNG4, RNG7)
RF9:	O sistema deve permitir aos usuários do MDS moderar as mensagens (RC8, RNG6)
- Componente Controle de Erros
RF10:	O sistema deve registrar todos os erros encontrados pelos gestores do MDS/Estados/Municípios (RC8, RNG8, RNG9)
RF11:	O sistema deve registrar erros sobre cada tabela, gráfico e mapa disponível no SIG Gerente CRAS (RC8, RNG9, RNG10)
RF12:	O sistema deve permitir aos usuários do MDS moderar as mensagens de erros (RC9, RNG11)
RF13:	O sistema deve permitir aos usuários do MDS excluir mensagens de erros (RNG11, RNG12)
RF14:	O sistema deve permitir registrar possíveis soluções para os problemas encontrados (RNG13)
RF15:	Gerar consulta: lista de erros relatados que faltam ser respondidos (RC10)
RF16:	Gerar consulta: lista de usuários que relataram erros (RC11)
- Componente Enquete
RF17:	O sistema deve permitir a construção de enquete pelo MDS (RC12, RNG14)
RF18:	O sistema deve permitir gerar uma lista de usuários que irão preencher a enquete (RC13, RNG15)
RF19:	O sistema deve permitir aos usuários do MDS habilitar a obrigatoriedade do voto na enquete (RNG15, RNG16)
RF20:	O sistema deve permitir ao MDS a associação da enquete com os comentários e críticas relatados (RNG17)
RF21:	Gerar relatório: para cada enquete o sistema deve gerar um relatório com o resultado dela (RC14, RNG18)
- Componente Autenticação
RF24:	O sistema somente poderá dar acesso aos usuários que realizarem autenticação (RC15, RNG19, RNG20)
RF25:	O sistema deve permitir aos usuários do MDS o cadastro de usuários dos Estados e Municípios (RC16, RNG21)
RF26:	O sistema deve identificar os usuários do MDS através da autenticação LDAP (RNG22)
RF27:	O sistema deve permitir aos usuários dos Estados o cadastro de usuários municipais (RC16, RNG23)
RF28:	O sistema tem que permitir aos usuários dos Estados o cadastro e o bloqueio de usuários municipais (RNG23)
RF29:	O sistema deve permitir aos funcionários do MDS bloqueio de qualquer usuário (RNG24)
RF30:	Gerar relatório com todas as autenticações no sistema (RC17)

Quadro 7
- Requisitos complementares

Id:	Descrição
RC1:	Os comentários/críticas devem estar habilitados para anexo de arquivos
RC2:	Comentários/críticas devem registrar o usuário, a data e a hora de todo o lançamento
RC3:	Número de acesso por usuário, quantidade total de acesso e usuários que não acessaram as ferramentas
RC4:	Pesquisar no título e corpo do comentário
RC5:	Pesquisar através do nome de usuário todos os comentários/críticas realizados por este gestor
RC6:	Deve ser gerado um relatório contendo o login, identificação do usuário, nome, tipo de gestor (MDS/Estado/Município último acesso, quantidade de acessos realizados e quantidade de comentários/ críticas realizados
RC7:	O sistema deve registrar cada erro por um único identificador com data e hora de cada lançamento
RC8:	O registro deve conter identificação única, título, data, hora e usuário
RC9:	Permitir ou não a publicação
RC10:	Detalhar hora, data, usuário, número de identificação e permitir o ordenamento baseado nestes critérios
RC11:	Lista de usuários que relataram erros em ordem alfabética
RC12:	A enquete deve ter um número identificador, um tema e opções para escolha
RC13:	Os usuários devem ser escolhidos entre todos os do MDS, Estados e Municípios
RC14:	O relatório deve conter: usuários que a responderam e resultado da enquete
RC15:	O usuário deve ser autenticado por meio de um e-mail válido e a senha com caracteres alfanuméricos com seis ou mais dígitos
RC16:	Deve ser registrado nome, CPF, Estado, Município, tipo de gestor (estadual ou municipal)
RC17:	O relatório deve conter dia, hora, IP, usuário e tipo de gestor

Quadro 8
- Regras de negócio propostas

Id:	Descrição
RNG1:	Os Estados devem poder registrar comentários/críticas sobre tabelas, gráficos e mapas disponíveis no SIG Gerente
RNG2:	Os Municípios devem poder registrar comentários/críticas sobre tabelas, gráficos e mapas disponíveis no SIG Gerente CRAS
RNG3:	O MDS/Estados/Municípios podem responder todos os comentários e críticas do sistema e este deve poder responder os comentários/críticas dos Estados e Municípios
RNG4:	O sistema deve permitir o ordenamento dos comentários/críticas segundo critérios de quantidade de visitas, votação dos participantes e ordem cronológica
RNG5:	O MDS deve ter o direito de excluir comentários e críticas existentes
RNG6:	O MDS deve ter o direito de moderar comentários e críticas
RNG7:	O MDS deve visualizar os comentários e críticas não respondidas
RNG8:	O MDS deve poder registrar erros encontrados nos dados, no SIG Gerente e nos relatórios
RNG9:	Os Estados devem poder registrar erros encontrados nos dados, no SIG Gerente e nos relatórios
RNG10:	Os Municípios devem poder registrar erros encontrados nos dados, SIG Gerente e nos relatórios
RNG11:	O MDS deve poder moderar os registros de erros
RNG12:	O MDS deve ter o direito de excluir o registro de erros
RNG13:	O MDS deve poder registrar possíveis soluções para os problemas encontrados
RNG14:	O MDS deve ter a opção de abrir enquetes para os Municípios/Estados se pronunciarem
RNG15:	Cada enquete deve estar planejada para receber uma lista de Municípios/Estados que podem opinar
RNG16:	O voto das pessoas desta lista pode ou não ser obrigatório
RNG17:	Cada enquete pode estar associada a uma discussão/comentário/crítica
RNG18:	Cada enquete deve gerar um relatório descritivo disponível para o MDS
RNG19:	Cada usuário do sistema deve ter um login e senha
RNG20:	Os usuários do MDS/Estados/Municípios devem se autenticar para ter acesso ao sistema
RNG21:	Os usuários do MDS devem cadastrar a equipe do Estado e a equipe do Município
RNG22:	Os usuários do MDS devem ser identificados por autenticação LDAP
RNG23:	Cabe aos Estados o cadastro/bloqueio de usuários locais
RNG24:	Cabe ao MDS o bloqueio de qualquer usuário
RNG25:	Comentários ou críticas devem possuir um número único de identificação

Quadro 9
- Requisitos não funcionais

Id	Descrição
- Funcionalidade
RNF1:	Todos os relatórios emitidos devem estar disponíveis nos formatos: HTML, PDF e CSV
- Confiabilidade
RNF2:	Os dados gerados pelo software devem ser armazenados em um ambiente RAID 1 e realizado um backup em outro ambiente ou cidade
RNF3:	Toda a troca de dados deve ser realizada utilizando uma conexão segura (HTTPS)
- Desempenho
RNF4:	O sistema deve suportar mais de 100 transações concorrentes no banco de dados
- Portabilidade
RNF5:	O sistema deve ser compatível com os browsers de internet (Internet Explorer 6,7,8 e Firefox 1,2,3)
RNF6:	O sistema deve funcionar em plataforma web (Linux + Apache + PostGres + PHP)
- Usabilidade
RNF7:	O sistema deve ter acessibilidade para deficientes visuais
- Manutenibilidade
RNF8:	O sistema deve está disponível para acesso 99% do tempo em que estiver em produção
RNF9:	Os bancos de dados devem ser verificados diariamente em busca de erros ou falhas através de agentes

Os requisitos funcionais foram divididos nos seguintes componentes do módulo MODCCRAS: (i) comentários e críticas, (ii)controle de erros, (iii) enquete e(iv) autenticação. O objetivo desses quatro componentes é solucionar problemas de autenticação e registro de comentários, críticas e erros, de acordo com as recomendações da meta-avaliação.

Apesar dos requisitos não funcionais do sistema não serem obtidos diretamente do processo de meta-avaliação, eles foram discutidos com o especialista de TI que participou desse processo. Eles foram inseridos por fazer parte do artefato DDR do método eXtreme Requirements.

6.3 Perfis, permissões e análise de risco

Existem três perfis de usuários credenciados do sistema: funcionários do MDS, usuários dos Estados e os dos Municípios. Todos podem acessar qualquer componente, mas com restrições previamente delimitadas nos requisitos funcionais e nas regras de negócio.

Análise de risco consiste em mapear os possíveis problemas ou interferências que um projeto poderá enfrentar durante sua execução. Por exemplo, o risco mapeado para este projeto advém dos próprios Municípios e Estados que participaram do processo de avaliação. Como fica evidenciado na Figura 4, sem a participação ativa deles, não seria possível construir uma avaliação que atendesse às recomendações da meta-avaliação.

Figura 4
: Exemplo de Matriz de Risco MODCCRAS

7. CONCLUSÕES

Os CRAS são centros que prestam serviços de assistência social e estão distribuídos por todo o Brasil. No ano de 2008, o MDS, como um dos principais financiadores dos programas e de políticas sociais, avaliou a qualidade desses centros. Essa avaliação envolveu a mobilização de pessoas em todo o Brasil para o fornecimento das informações utilizadas para a elaboração dos indicadores de qualidade.

Tendo como base o resultado consolidado do censo CRAS 2008, foi realizada uma meta-avaliação a partir de uma abordagem metodológica mista que envolveu uma metodologia de meta-avaliação como forma de elicitação de requisitos e a metodologia XR para a definição de requisitos. Apesar das limitações deste trabalho com relação à quantidade de padrões utilizados para a meta-avaliação dos CRAS 2008, foram obtidas dez recomendações relativas à forma como as TIC podem aperfeiçoar o processo de avaliação.

Constatou-se que o trabalho trouxe contribuições no contexto da ER, uma vez que o processo atual de análise de requisitos orientado a objetos da UML para projetos de sistemas de informação tem como ponto de partida a formulação de casos de uso que envolve (i) a identificação das necessidades de um determinado ator (humano ou não), (ii) suas interfaces com o sistema e (iiii) ações a serem encaminhadas (PRESSMAN, 2010, p. 161). Este é um processo tipicamente baseado nas expectativas dos usuários em relação aos sistemas de informação. A visão crítica adotada em uma meta-avaliação permite a identificação de fragilidades que podem ser mapeadas em soluções de TIC.

A partir dos resultados desta pesquisa podem-se antever diversos desdobramentos, como: (i) estender a aplicação da metodologia aos demais padrões do Joint Committee no âmbito das avaliações dos CRAS;(ii) aplicar a metodologia proposta em outras avaliações realizadas pelo MDS ou por outros órgãos interessados no aprimoramento de seus sistemas de informação para avaliação; (iii) estudar o papel das TIC em cada padrão do Joint Committee e(iv) aprofundar os estudos sobre formas de elicitação de requisitos baseadas em avaliações críticas de processos.

References

• AMERICAN EVALUATION ASSOCIATION. Guiding principles for evaluators. Disponível em: <http://www.eval.org/Publications/aea06.GPBrochure.pdf>. Acesso em: 22 maio 2009.
  » http://www.eval.org/Publications/aea06.GPBrochure.pdf
• ASSOCIATION OF BUSINESS PROCESS MANAGEMENT PROFESSIONALS. Guia para o Gerenciamento de Processos de Negócio Corpo Comum de Conhecimento (BPM CBOK®) - Versão 2.0. ABPMP, 2009. Disponível em: <http://www.abpmp-br.org/CBOK/CBOK_v2.0_Portuguese_Edition_Thrid_Release_Look_Inside.pdf>.
  » http://www.abpmp-br.org/CBOK/CBOK_v2.0_Portuguese_Edition_Thrid_Release_Look_Inside.pdf
• Brasil. Ministério do Desenvolvimento Social e Combate à Fome. Linha de Base do Monitoramento dos CRAS. Brasília, DF: Secretaria de Avaliação e Gestão da Informação, Secretaria Nacional de Assistência Social, 2008a. 104 p.
• Brasil. Ministério do Desenvolvimento Social e Combate à Fome.Gerente CRAS 2008 2008b. Disponível em: <http://aplicacoes.mds.gov.br/sagi/CRAS2008/adm>.
  » http://aplicacoes.mds.gov.br/sagi/CRAS2008/adm
• Brasil. Ministério do Desenvolvimento Social e Combate à Fome. Monitoramento SUAS: censo CRAS 2008. Brasília: Secretaria de Avaliação e Gestão da Informação, Secretaria Nacional de Assistência Social, 2010. 235 p.
• Castro, E. J. R.; Guimarães, F. A. Processo eXtreme requirements XR. Disponível em: <http://www.quaddract.com.br/download/Metodo_eXtreme_Requirements_XR.pdf>. Acesso em: 27 fev. 2010.
  » http://www.quaddract.com.br/download/Metodo_eXtreme_Requirements_XR.pdf
• Coosky, L.; Caracelli, V. Metaevaluation in practice.Journal of MultiDisciplinary Evaluation, v. 6, n.11, 2009.
• Hedler, H. Meta-avaliação das auditorias de natureza operacional do Tribunal de Contas da União: um estudo sobre auditorias de natureza operacional de programas sociais. Tese de Doutorado apresentada ao Instituto de Psicologia da UnB, 2007. 260f.
• IEEE. Standard Glossary of Software Engineering Terminology (IEEE Std. 610.12-1990). New York, EUA: IEEE, 1990.
• INTERNATIONAL STANDARD ORGANIZATION . ISO/IEC 9126-1, Software engineering – product quality – Part 1: Quality Model, first ed.: 2001-06-15.
• JOINT COMMITTEE. The Program Evaluation Standards Thousand Oaks, EUA: SAGE, 1994.
• Paula Filho, W. Engenharia de software fundamentos, métodos e padrões Rio de Janeiro, RJ: LTC, 2009.
• Posavac, E. J., & Carey, R. G. Program evaluation. Methods and case Studies 6ª Ed., New Jersey, EUA: Prentice Hall. 2003.
• Pressman, R. Software engineering: a Practitioner’s Approach 7. Ed., New York, EUA: McGraw-Hill, 2010.
• Russel, S.; Norvig, P. Artificial Intelligence a Modern Approach 3. Ed. Boston, EUA: Pearson, 2010.
• Saiedian, H. Dale, R. Requirements engineering: making the connection between the software developer and customer. Information Software Technology, n. 42, 1999.
• SEI. Software Engineering Institute. Improving process for developing better products and services. Disponível em: <http://www.sei.cmu.edu/reports/10tr033.pdf>. Acesso em 9 de novembro de 2010·
  » http://www.sei.cmu.edu/reports/10tr033.pdf
• Softex. MPS.br – Melhoria de Processo de Software Brasileiro - Guia Geral 2009. Disponível em: <http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2009.pdf>
  » http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2009.pdf
• Stufflebeam, D. The metaevaluation imperative. American Journal of Evaluation, v. 22, p. 183-209, 2001.
• Stufflebeam, D.; Shinkfield, A. Evaluation, theory, models & applications San Francisco, EUA: Jossey-Bass, 2007.
• UNITED STATES GOVERNMENT ACCOUNTABILITY OFFICE.GOF: Government Auditing Standards. 2007. Disponível em: <http://www.gao.gov/new.items/d07731g.pdf>. Acesso em: 08 out. 2009.
  » http://www.gao.gov/new.items/d07731g.pdf
• Weiss, C. H. Evaluation 2. Ed., Saddle River, EUA: Prentice Hall, 1997.
• Wiegers, K. Software requirements: practical techniques for gathering and managing requirements throughout the product development cycle 2. ed. Redmond, EUA: Microsoft Press, 2003.
• Worthen, B.; Sanders, J.; Fitzpatrick, J. Avaliação de programas: concepções e práticas São Paulo, SP: Editora Gente, 2004.

• [1]
  O Censo CRAS é realizado anualmente pelo MDS e refere-se à coleta e análise de dados dos Centros de Referência de Assistência Social. Este processo teve início em 2007 e desde então é realizado anualmente.
• [2]
  A norma ISO/IEC 9126 (INTERNATIONAL STANDARD ORGANIZATION, 2001) foca na qualidade do produto de software. Ela estabelece um modelo de qualidade baseado nos seguintes componentes:(i) processo de desenvolvimento, (ii)qualidade do produto final e (iii) qualidade no uso do produto de software.
• [3]
  Gestão por Processo de Negócio é uma abordagem disciplinada para identificar, desenhar, executar, documentar, medir, monitorar, controlar e melhorar processos de negócio automatizados ou não para alcançar os resultados pretendidos consistentes e alinhados com as metas estratégicas de uma organização (ASSOCIATION OF BUSINESS PROCESS MANAGEMENT PROFESSIONALS, 2009).
• [4]
  Segundo Russel e Norvig (2010, p. 34), um agente é uma entidade que percebe seu ambiente por meio de sensores e que atua sobre este ambiente através de atuadores, processando informação e conhecimento.

Datas de Publicação

• Publicação nesta coleção
  Abr 2014

Histórico

• Recebido
  26 Set 2011
• Aceito
  11 Fev 2014