Apoio ao Processo de Verificação em Ambientes de
Desenvolvimento de Software Orientados a Organização
Andrea Oliveira Soares Barreto ansoares@cos.ufrj.br
Orientador: Ana Regina Cavalcanti da Rocha darocha@cos.ufrj.br
COPPE/Universidade Federal do Rio de Janeiro
Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro, Brasil Dissertação de Mestrado
Curso iniciado em Março de 2003 Previsão de conclusão em Março de 2005
Proposta de Tese aprovada em: Esta atividade não existe formalmente na COPPE Resumo
O software está cada vez mais presente na sociedade moderna. A complexidade dos produtos de software continua a crescer quase que sem limites. Devido ao fato de apenas um pequeno número dos projetos de desenvolvimento de software serem concluídos com sucesso (de acordo com o cronograma, dentro da estimativa de custo e com a qualidade requerida), a necessidade de verificar efetivamente a qualidade do software, isto é, determinar se o software atende aos requisitos funcionais e não-funcionais especificados, é da maior importância. Este trabalho define um processo de verificação de software. O objetivo do trabalho é apoiar a verificação do software durante todo o processo de desenvolvimento e/ou manutenção possibilitando que se tenha produtos de melhor qualidade. Para isto, será desenvolvida uma ferramenta de apoio no contexto dos Ambientes de Desenvolvimento de Software Orientados a Organização.
Palavras-chave: Verificação de Software, Ambientes de Desenvolvimento de Software, Processo de Verificação, Ferramentas de Verificação
1. Caracterização do Problema
O papel dos computadores na sociedade, o poder de processamento que eles oferecem e as suas variedades de utilização em domínios diferentes têm crescido drasticamente. A competição aguçada através da indústria de computadores e a capacidade de se colocar produtos no mercado num intervalo de tempo cada vez menor têm determinado o sucesso de uma empresa. Desse modo, existe uma constante pressão para que o software seja produzido de forma mais rápida, com alta qualidade e mantendo um custo adequado.
Sendo o software um dos componentes mais caros e mais importantes nos sistemas computacionais atuais, é fundamental que sua construção seja organizada e disciplinada seguindo um conjunto de atividades bem definidas. Este conjunto ordenado de atividades, juntamente com as técnicas e ferramentas que as auxiliarão, os recursos que serão utilizados e os artefatos que serão produzidos formam um processo de software.
Para atender estas necessidades, o projeto TABA teve início em 1990 com o objetivo de se construir ADSs centrados em processos e adequados a projetos com diferentes características. Atualmente a Estação TABA é um meta-ambiente capaz de gerar, através de configuração e instanciação, ambientes de desenvolvimento de software orientados a organização (ADSOrg) [15].
Sendo assim, neste momento a Estação TABA permite configurar um ambiente específico para uma organização através de seu processo padrão e processos especializados para as diferentes abordagens de desenvolvimento utilizadas na organização (por exemplo, desenvolvimento OO ou desenvolvimento de sistemas baseados em conhecimento). Estes processos são finalmente instanciados para projetos específicos considerando-se suas particularidades (por exemplo, tamanho, requisitos de confiabilidade, etc). Entretanto, os ambientes TABA ainda não apóiam adequadamente o processo de verificação de software.
A proposta desta tese consiste em definir um processo de verificação para os ambientes TABA baseado na norma internacional ISO/IEC 12207 [7], no CMMI [10] e em outros padrões descritos na literatura que suporte os objetivos e práticas de Verificação descritas no CMMI como uma área de processo de engenharia do nível de maturidade 3, e construir uma ou mais ferramentas que apóiem a execução deste processo.
2. Fundamentação Teórica
Há diversas definições para Verificação. A norma internacional ISO/IEC 12207 [7], por exemplo, define verificação como a confirmação, por exame e fornecimento de evidência objetiva, do atendimento aos requisitos especificados. O objetivo da verificação é assegurar que o software, ou uma determinada função do mesmo, esteja sendo implementado corretamente. Verifica-se, inclusive, se os métodos de desenvolvimento foram adequadamente aplicados [9]. Uma verificação efetiva aumenta a visibilidade do processo de desenvolvimento e reduz os riscos do projeto [13].
A verificação de software está fortemente associada à validação de software. Existem várias definições para Validação. A norma internacional ISO/IEC 12207 [7] define validação como a confirmação, por exame e fornecimento de evidência objetiva, de que os requisitos específicos, para um determinado uso pretendido, são atendidos. O objetivo da validação é assegurar que o software que está sendo desenvolvido é o software correto de acordo com os requisitos do usuário [9]. A norma internacional ISO/IEC 12207 define, ainda, que nas atividades de desenvolvimento, a verificação refere-se ao processo de examinar o resultado de
uma atividade para determinar sua conformidade com os requisitos estabelecidos para a mesma atividade, enquanto a validação se refere ao processo de examinar um produto para determinar sua conformidade com as necessidades do usuário. Esta norma define que a validação é feita normalmente no produto final sob condições de operação definidas, podendo, contudo, tornar-se necessária em fases anteriores.
No contexto deste trabalho serão usadas as definições da norma ISO/IEC 12207 [7]. A literatura descreve vários métodos e técnicas de verificação que podem também ser usadas para validação. LAITENBERGER et al. [8] descrevem as seguintes técnicas de verificação de software: (i) walkthrough como uma técnica de análise estática na qual o projetista ou programador lidera membros da equipe de desenvolvimento e outras partes interessadas através de um segmento de documentação ou código, e os participantes fazem perguntas e comentários sobre possíveis erros, violações de padrões de desenvolvimento e outros problemas; (ii) revisão técnica como um processo de reuniões durante as quais um ou mais artefatos são apresentados à equipe do projeto, aos gerentes, aos usuários, aos clientes, ou a outras partes interessadas para que possam fazer comentários ou aprovar; (iii) revisão por pares (peer reviews) como um processo (normalmente informal) no qual, um artefato é examinado por qualquer integrante da equipe do projeto (inclusive a equipe de garantia da qualidade), com o propósito de detectar defeitos; (iv) inspeção como uma técnica que envolve um processo e critérios de avaliação bem definidos através da qual um produto de software é analisado usando uma técnica de leitura sistemática com propósito de detectar defeitos. De acordo com o CMMI [10], os métodos de verificação incluem inspeções, revisões por pares, auditorias, walkthrough, análises, simulações, testes e demonstrações, dentre outros.
A norma internacional ISO/IEC 12207 [7] define o processo de verificação como um processo para determinar se os produtos de software desenvolvidos em uma determinada atividade atendem completamente os requisitos ou condições impostas a eles nas atividades anteriores. Além disso, a norma define que, para a eficácia de custo e desempenho, a verificação deve ser integrada, o quanto antes, ao processo que a utiliza. Segundo esta norma, o processo de verificação inclui análise, revisão e teste. Este processo é composto de duas atividades: (i) implementação do processo e (ii) verificação. A atividade de implementação do processo consiste das seguintes tarefas: determinar se o projeto justifica um esforço de verificação, estabelecer um processo de verificação, determinar as atividades do ciclo de vida e os produtos de software que requerem verificação e desenvolver e documentar um plano de verificação. A segunda atividade do processo de verificação da ISO/IEC 12207, é composta pelas seguintes tarefas: verificação do contrato, verificação do processo, verificação dos requisitos, verificação de projeto, verificação do código, verificação da integração e verificação da documentação.
O modelo de maturidade e capacidade CMMI [10] define a área de processo de engenharia “Verificação” composta dos seguintes objetivos: (i) preparação para verificação; (ii), realização de revisões por pares; (iii) verificação dos artefatos selecionados. O primeiro objetivo consiste em selecionar os artefatos para verificação, estabelecer um ambiente para verificação e estabelecer procedimentos e critérios para verificação. O segundo objetivo é composto pelas seguintes práticas: preparar as revisões por pares, conduzir as revisões por pares e analisar os dados das revisões por pares. O terceiro objetivo consiste em realizar a verificação e analisar os resultados da verificação e identificar ações corretivas.
3. Metodologia de Trabalho e Estado Atual do Trabalho
Inicialmente, foram identificados na literatura os processos de verificação definidos e a abordagem da área de processo do CMMI que poderiam ser utilizados como base para a definição do processo de verificação a ser apoiado pelos ambientes TABA [7][10].
Em seguida, foram levantadas na literatura, as técnicas de verificação de software mais utilizadas no contexto do desenvolvimento. Na fase seguinte, foram analisados os processos de verificação de software identificados para se definir o processo objeto deste trabalho.
O processo de verificação definido para os ADSOrg é apresentado na Figura 1 com suas atividades, descrição de cada atividade e sub-atividades.
Processo de Verificação Atividade: Planejar Verificação de Artefatos
Descri ção: Definir o Plano de Verifi cação para o projeto. O plano deve descrever as atividades de veri fi cação, os artefatos sujeitos à veri ficação, procedimentos e cronograma para executar as atividades e os responsáveis pelas atividades.
Sub-Atividades:
Nome: Selecionar Artefatos para Verificação
Descri ção: Nesta atividade devem ser analisados os artefatos que serão produzidos ao longo do projeto e selecionados aqueles que deverão ser veri ficados. Os artefatos deve ser selecionados com base em suas contribuições para o alcance dos objetivos e requisitos do projeto, considerando também os riscos do projeto.
Nome: Selecionar Técnicas e Ferramentas
Descri ção: Os métodos e técnicas de veri ficação que est ão disponíveis para uso e que serão aplicados a cada um dos artefatos devem ser selecionados, bem como as ferramentas que serão usadas para apoiar a veri ficação.
Nome: Definir Procedimentos e Critérios de Verificação
Descri ção: Estabelecer e manter procedimentos e critérios para veri ficação para os artefatos. Critérios de verifi cação são definidos para garantir que os artefatos estão de acordo com os requisitos. Para isso, os requisitos a serem satisfeitos por cada artefato devem ser identi ficados. Deve ser gerado um conjunto compreensível e integrado de procedimentos para veri ficação dos artefatos. Nesta atividade também será identi ficado o momento do ciclo de vida do projeto no qual cada artefato selecionado será veri ficado e os responsáveis por cada atividade de veri ficação.
Nome: Planejar Testes de Unidades
Descri ção: Desenvolver um plano de testes de unidade. O plano deve conter: requisitos de teste, procedimentos, dados, responsabilidades e cronogram a .
Nome: Planejar Testes de Integração do Software
Descri ção: Desenvolver um plano de testes de integração para integrar as unidades e componentes de software no item de software. O plano deve conter: requisitos de teste, procedimentos, dados, responsabilidades e cronogram a .
Nome: Planejar Testes do Software
Descri ção: Desenvolver e documentar, para cada requisito de qualifi cação do item de software, um conjunto de testes, casos de teste (entradas, saídas e critérios de teste) e procedimentos de teste.
Nome: Planejar Testes do Sistema
Descri ção: Desenvolver e documentar um conjunto de testes, casos de testes e procedimentos de testes para conduzir o teste do sistema.
Nome: Definir Procedimentos para Encaminhar Relatórios da Verificação às Partes Envolvidas
Descri ção: Devem ser definidos procedimentos para envi ar os laudos de verifi cação e rel atórios de testes gerados pelas atividades do processo de veri fi cação às part es envolvidas no processo.
Atividade: Verificar Artefatos
Descri ção: Veri ficar os artefatos selecionados na atividade de planejam ento da veri ficação de artefatos. Sub-Atividades:
Nome: Verificar o Processo Planejado
Descri ção: Veri ficar se o processo de desenvolvimento definido está adequado às necessidades do projeto e padrões da organização e realizar os ajustes necessários. Qualquer inadequação identifi cada deve ser corrigida pelo gerente do projeto para poder obter o comprometimento dos stakeholders com o Plano do Processo.
Nome: Verificar o Plano do Projeto
Descri ção: Avaliar o Plano do Projeto e realizar as adequações e ajustes necessários. O objetivo da verificação é obter o comprometimento com o Plano do Projeto e consolidar as responsabilidades. Devem ser considerados os seguintes critérios: viabilidade econômica, financeira, de cronograma, de mão de obra, tecnológica e legal. Qualquer inadequação identifi cada deve ser corrigida pelo gerent e do projeto para poder obter o comprometimento dos stakeholders com o Plano do Projeto.
Nome: Verificar os Requisitos de Sistema
Descri ção: Avaliar os requisitos do sistema segundo os seguintes critérios: clareza, completeza, consistência, não-ambiguidade, rastreabilidade para as necessidades de aquisição, consistênci a com as necessidades de aquisição, testabilidade, viabilidade do projeto da arquitetura do sistema, viabilidade de operação e manut enção. Identi fi car os requisitos que não atendem aos critérios especi ficados e estabelecer as linhas gerais do plano de ação para adequá-los.
Nome: Verificar a Arquitetura do Sistema
Descri ção: Avaliar a arquitetura de alto nível considerando os seguintes critérios: rastreabilidade e consistência com os requisitos do sistema, adequação dos métodos e padrões de projeto utilizados, viabilidade de os itens de software at enderem seus requisitos alocados, viabilidade de operação e manutenção. Definir as linhas gerais do plano de ação para adequar a arquitetura do sistema quando os critérios estabelecidos não forem atendidos.
Nome: Verificar os Requisitos do Software
Descri ção: Avaliar, através de reuniões de inspeção, os requisitos do software segundo os seguintes critérios: clareza, completeza, não-ambiguidade, rastreabilidade para os requisitos do sistema e projeto do sistema, consistência externa com os requisitos do sistema, consistência interna, testabilidade, viabilidade do projeto de software, viabilidade da operação e manutenção. Definir as linhas gerais do plano de ação para adequar os requisitos de software que não estiverem de acordo com os critérios estabelecidos.
Nome: Verificar o Modelo de Análise
Descri ção: Avaliar o modelo de análise segundo os seguintes critérios: clareza, completeza, rastreabilidade para os requisitos do sistema, projeto do sistema e requisitos do software, consistência externa com os requisitos de software, consistência interna, testabilidade, viabilidade do projeto de software, viabilidade da operação e manutenção. Definir as linhas gerais do plano de ação para adequar o modelo de análise nos pontos em que este não atender aos critérios estabelecidos. Nome: Verificar o Modelo de Projeto de Alto Nível
Descri ção: Avaliar o modelo de projeto de alto nível segundo os seguintes critérios: clareza, completeza, rastreabilidade para os requisitos do item de software, consistência externa com os requisitos do item de software, consistênci a interna entre os componentes de software, adequação dos métodos e padrões de projeto utilizados, viabilidade do projeto detalhado, viabilidade da operação e manutenção. Definir as linhas gerais do plano de ação para adequar o modelo projeto de alto nível nos pontos onde este não atender aos critérios estabelecidos.
Nome: Verificar o Projeto Detalhado
Descri ção: Avaliar o modelo de projeto detalhado segundo os seguintes critérios: clareza, completeza, rastreabilidade para os requisitos do item de software e para o projeto de alto nível, consistência externa com o projeto de alto nível, consistência interna entre componentes e unidades de software, adequação dos métodos e padrões de projeto utilizados, viabilidade de testes, viabilidade da operação e manutenção. Definir as linhas gerais do plano de ação para adequar o modelo de projeto detalhado nos pontos onde este não atender aos critérios estabelecidos.
Nome: Testar Unidades
Descri ção: Testar cada unidade de software e base de dados, garantindo que sejam atendidos os seus requisitos. Os resultados dos testes devem ser documentados.
Nome: Verificar o Código de Unidades
Descri ção: Avaliar o código de unidades e os resultados dos testes, considerando os seguintes critérios: rastreabilidade para os requisitos e projeto do item de software, consistência externa com os requisitos e projeto do item de software, consistência interna entre os requisitos da unidade, cobertura de teste das unidades, adequação dos métodos e padrões de codi ficação utilizados, viabilidade da integração e testes do software, viabilidade da operação e manutenção. Definir as linhas gerais do plano de ação para adequar o código das unidades nos pontos onde este não atende aos critérios estabelecidos.
Nome: Verificar o Plano de Testes do Software e os Testes de Integração
Descri ção: Avaliar o plano de teste do software, projeto, código, testes, resultados dos testes e a documentação do usuário
considerando os seguintes critérios: rastreabilidade para os requisitos do sistema, consistência externa com os requisitos do sistema, consistência interna, cobertura de teste dos requisitos de software, adequação dos métodos e padrões de teste utilizados, conformidade com os resultados esperados, viabilidade do teste do software, viabilidade de operação e manutenção. Estabelecer as linhas gerais do plano de ação para adequar o plano de testes do software e os testes de integração.
Nome: Reali zar Testes do Software
Descri ção: Conduzir e documentar o teste de quali ficação para o item de software. Deve ser garantido que a implementação de cada requisito do software seja testada para conformidade. Os resultados do teste devem ser documentados.
Nome: Verificar o Software
Descri ção: Avaliar o código, testes, resultados dos testes e a documentação do usuário considerando os seguintes critérios: cobertura de teste dos requisitos do item de software, conformidade com os resultados esperados, viabilidade da integração e testes do sistema, se conduzidos, viabilidade da operação e manut enção. Registrar as não-conformidades identi ficadas e definir as linhas gerais do plano de ação para corrigi-las.
Nome: Verificar o Plano de Testes do Sistema e o Sistema Integrado
Descri ção: Avaliar o plano de testes do sistema e o sistema integrado segundo os seguintes critérios: cobertura dos testes dos requisitos do sistema, adequação dos métodos e padrões de teste utilizados, conformidade com os resultados esperados, viabilidade do teste do sistema, viabilidade da operação e manut enção. O desenvolvedor deve garantir que o sistema integrado está pronto para o teste do sistema. Registrar as não-conformidades identi ficadas e definir as linhas gerais do plano de ação para corrigi-las.
Nome: Reali zar Testes para Homologação Interna
Descri ção: Realizar o teste do sistema de forma a garantir que a especi fi cação de cada requisito seja testada, para conformidade, e que o sistema está pronto para ser entregue. Os resultados do teste devem ser documentados.
Nome: Verificar o Sistema
Descri ção: Avaliar o sistema segundo os seguintes critérios: cobertura de teste dos requisitos do sistema, conformidade com os resultados esperados, viabilidade da operação e manutenção. Registrar as não-conformidades identifi cadas e definir as linhas gerais do plano de ação para corrigi-las.
Figura 1 – Processo de verificação definido para os ADSOrg (continuação)
O processo aqui definido será integrado ao processo de desenvolvimento definido nos ADSOrg. Dessa forma, as atividades deste processo serão executadas a partir do processo de desenvolvimento. No estágio atual do trabalho, tem-se o processo definido e estão sendo estudados com maiores detalhes os métodos e técnicas disponíveis na literatura para apoiar a realização das atividades de verificação. A atividade seguinte será definir e implementar as ferramentas de apoio ao processo definido para os ADSOrg.
4. Trabalhos Relacionados
Diversos estudos referentes à verificação de software são encontrados na literatura. A norma internacional ISO/IEC 12207 [7] descreve um processo de verificação de software como um dos processos de apoio de ciclo de vida de software. O CMMI [10] define uma área
de processo de verificação de software que faz parte do nível de maturidade 3. Em ANDERSSON [1] é descrito um estudo que explora o estado da prática da verificação e validação de software, investiga e avalia técnicas de verificação e validação com o intuito de obter um melhor entendimento sobre as atividades de verificação e validação no processo de desenvolvimento de software. BERLING e THELIN [5] apresentam um estudo sobre as atividades de verificação e validação no contexto industrial. Vários trabalhos que estudam técnicas de verificação, tais como, inspeção, revisão por pares e walkthrough são descritos em [2][8][12][14]. BERLING [3] descreve um estudo sobre o aumento da qualidade do produto através da melhoria da verificação e validação no contexto industrial. SILVA [11] apresenta um trabalho para apoiar, por meio de ferramentas, a aplicação de técnicas de leitura baseada em perspectiva (PBR) durante a inspeção de documentos.
Finalmente, BERLING e HÖST [4] apresentam um estudo onde investigam as características das atividades de verificação e validação no processo de desenvolvimento de software.
5. Resultados Esperados
A contribuição deste trabalho será: (i) a definição de um processo de verificação para os ADSOrg; (ii) a definição e implementação de uma ou mais ferramentas de apoio à execução deste processo que será integrada aos ambientes configurados TABA.
Desta forma, com a realização desta tese de mestrado, os ADSOrg instanciados a partir dos ambientes configurados TABA serão capazes de apoiar os desenvolvedores de software na execução das atividades do processo de verificação.
Referências
[1] ANDERSSON, C., 2003, “Exploring the Software Verification and Validation Process with Focus on Efficient Fault Detection”, Licentiate Thesis, Lund Institute of Technology (LTH), Lund University, Sweden.
[2] AURUM, A., PETERSSON, H., WOHLIN, C., 2002, “State-of-the-Art: Software Inspections after 25 Years”, Software Testing, Verification and Reliability, 12(3):133-154.
[3] BERLING, T., 2003, “Increasing Product Quality by Verification and Validation Improvements in an Industrial Setting”, Doctoral Thesis, Lund University, Sweden.
[4] BERLING, T., HÖST, M., 2003, “A Case Study Investigating the Characteristics of Verification and Validation Activities in the Software Development Process”, 29th Euromicro conference, Belek-Antalya, Turkey, pp.405-408.
[5] BERLING, T., THELIN, T., 2003, “An Industrial Case Study of the Verification and Validation Activities”, 9th
International Software Metrics Symposius, Sydney, Australia, pp.226-238.
[6] GOLUBIÉ, S., 2003, “On Software Quality Verification in the Object-Oriented Development Enviroment”, 7th
International Conference on telecommunications – ConTEL, pp.557-563, Zagreb, Croatia.
[7] ISO/IEC 12207, 1995, Information Technology – Software Life-Cycle Processes.
[8] LAITENBERGER, O., VEGAS, S., CIOLKOWOSKI, M., 2002, “The State of the Practice of Review and Inspection Technologies in Germany”, Tech Report Number: ViSEK/011/E.
[9] ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C., 2001, Qualidade de Software, Teoria e Prática, São Paulo, Prentice-Hall.
[10] SEI, 2002, “Capability Maturity Model Integration, Version 1.1 Staged Representation”. URL: http://www.sei.cmu.edu
[11] SILVA, L., F., S., TRAVASSOS, G.H., 2003, “Apoio Ferramental para Aplicação de Técnicas de Leitura Baseada em Perspectiva (PBR)”, Workshop de Teses – XVII Simpósio Brasileiro de Engenharia de Software, Manaus – AM, Outubro.
[12] SHULL, F., CARVER, J., TRAVASSOS, G., MALDONADO, J., CONRADI, R., BASILI, V., 2003, “Replicated Studies: Building a Body of Knowledge about Software Reading Techniques”, In Lecture Notes on Empirical Software
Engineering (Juristo N. and Moreno A. Eds.), World Scientific, Singapore, 39-84.
[13] SINGH, H., BAWA, H. S., 1995, Management of Effective Verification and Validation, IEEE Engineering
Management Conference, pp.204-207.
[14] THELIN, T., 2002, “Empirical Evaluations of Usage-Based Reading and Fault Content Estimation for Software Inspections”, Tese de Doutorado, Lund University, Sweden.
[15]VILLELA, K., 2004, “Definição e Construção de Ambientes de Desenvolvimento de Software Orientados a Organização”, Doctoral Thesis, COPPE/UFRJ, Rio de Janeiro, RJ, Brasil, Março.
