SOFTWARE DE AUXÍLIO À IMPLANTAÇÃO DA NORMA ISO/IEC PROCESSOS DO CICLO DE VIDA DO SOFTWARE.

Transcrição

1 UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CUROS DE CIÊNCIAS DA COMPUTAÇÃO BACHARELADO SOFTWARE DE AUXÍLIO À IMPLANTAÇÃO DA NORMA ISO/IEC PROCESSOS DO CICLO DE VIDA DO SOFTWARE. ALTAIR BERNARDI BLUMENAU /2-04

2 ALTAIR BERNARDI SOFTWARE DE AUXÍLIO À IMPLANTAÇÃO DA NORMA ISO/IEC PROCESSOS DO CICLO DE VIDA DO SOFTWARE Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciência da Computação Bacharelado. Prof. Marcel Hugo Orientador BLUMENAU /02-04

3 SOFTWARE DE AUXÍLIO À IMPLANTAÇÃO DA NORMA ISO/IEC PROCESSOS DO CICLO DE VIDA DO SOFTWARE Por ALTAIR BERNARDI Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por: Presidente: Membro: Membro: Prof. Marcel Hugo Orientador, FURB Prof. Carlos Eduardo Negrão Bizzotto, FURB Prof. Alexander Roberto Valdameri, FURB

4 AGRADECIMENTOS Aos meus pais, pois sem eles não teria chegado até aqui. Ao meu orientador, Marcel Hugo, pela ajuda e por ter acreditado na conclusão deste trabalho. Aos meus amigos, pelo apoio recebido para finalizar este trabalho.

5 RESUMO Através do estudo dos processos fundamentais de ciclo de vida de software proposto pela Norma NBR ISO/IEC foi desenvolvido um questionário que objetiva determinar qual o percentual de adequação dos processos utilizados por uma organização no desenvolvimento de software em relação aos processos definidos pela norma. Para facilitar a aplicação do questionário foi desenvolvido um aplicativo web que pode ser acessado em O trabalho foi aplicado em uma grande empresa do setor alimentício da região e além de determinar o percentual de adequação de seus processos de desenvolvimento com a norma determinou-se o também o nível CMM da empresa. Palavras chaves: NBR ISO/IEC 12207; Qualidade; Software.

6 ABSTRACT Through the studies about the fundamental processes of software life cycle considered for the Norma NBR ISO/IEC it was developed a questionnaire that aims to determine which is the adaptation percentage of the processes used by an organization in the software development. In order to make the questionnaire application easier it was developed a web application that can be accessed at This work was applied in a big company in the food section determining the adaptation percentage of its development processes against the standard and it was also determined the CMM level of the company. Key-Words: NBR ISO/IEC 12207; Quality; Software.

7 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS DO TRABALHO ESTRUTURA DO TRABALHO MODELOS DE QUALIDADE DE SOFTWARE MODELOS ISO 9001/ CMM SPICE TRABALHOS CORRELATOS Theilacher Anacleto Frare A NORMA ISO/IEC CARACTERÍSTICAS GERAIS Processos de Software Objetivo Campo de Aplicação Conformidade Limitações ESTRUTURA DA NORMA Processos Fundamentais Processos de Apoio Processos Organizacionais RELAÇÃO CMM E NBR ISO/IEC DESENVOLVIMENTO DO TRABALHO DETERMINAÇÃO DO NÍVEL CMM QUESTIONÁRIO DA NORMA NBR ISO/IEC REQUISITOS PRINCIPAIS DO SOFTWARE ESPECIFICAÇÃO Casos de Uso Diagramas de classes Diagrama de seqüência...40

8 4.4.4 Diagrama Entidade Relacionamento IMPLEMENTAÇÃO Técnicas e Ferramentas utilizadas OPERACIONALIDADE DA IMPLEMENTAÇÃO Acesso Cadastro e Logon de usuários Utilização do Aplicativo RESULTADOS E DISCUSSÃO CONCLUSÕES EXTENSÕES...66 REFERÊNCIAS BIBLIOGRÁFICAS...67 ANEXO A Metodologia utilizada pela empresa...68 ANEXO B Questionário ANEXO C Questionário ANEXO D Questionário APÊNDICE A Perguntas criadas a partir da Norma ISO/IEC

9 8 1 INTRODUÇÃO Atualmente as organizações estão em busca de certificados que comprovem a qualidade de seus produtos e processos no intuito de conseguir uma maior competitividade, participação no mercado e em conseqüência aumentar seus lucros. Segundo a ISO 8402 (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 1997) qualidade é a totalidade das características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas. Esta definição da qualidade exige alguns complementos, principalmente para definir o que são as entidades, as necessidades explícitas e as necessidades implícitas. A entidade é o produto do qual está se falando, que pode ser um bem ou um serviço. As necessidades explícitas são as próprias condições e objetivos propostos pelo produtor. As necessidades implícitas incluem as diferenças entre os usuários, a evolução no tempo, as implicações éticas, as questões de segurança e outras visões subjetivas. Segundo Barreto [200-] a qualidade de um prato de comida (a entidade, o produto) está relacionada com a satisfação de necessidades (requisitos) tais como: sabor, aparência, temperatura, rapidez no serviço, preço, higiene, valor nutricional etc. Para avaliar a qualidade de um produto, você deve fazer uma lista destas necessidades e analisar cada uma destas necessidades. Segundo Fuggeta (apud ROCHA, 2001) uma das evoluções mais importantes no estudo da qualidade está em notar que a qualidade do produto é algo bom, mas que qualidade do processo é ainda mais importante, visto que a qualidade de produtos está fortemente relacionada à qualidade do processo. Em software esta afirmação não é diferente. Assim houve uma grande preocupação com a modelagem e melhorias no processo de software. Abordagens importantes como as normas de qualidade ISO 9000 e a ISO/IEC 12207, o modelo Capability Maturity Model (CMM) e o modelo Software Process Improvement and Capability Determination (SPICE) sugerem que melhorando o processo de software, pode-se melhorar a qualidade dos produtos (PFLEEGER apud Rocha (2001)).

10 9 Segundo Curtis (apud ROCHA, 2001) a organização que for capaz de integrar, harmonizar e acelerar seu processo de desenvolvimento e manutenção de software terá a primazia do mercado. Observando-se este fato, este trabalho de conclusão almeja determinar quais itens dos processos Fundamentais do ciclo de vida da Norma NBR ISO/IEC foram adotados no processo de software de uma empresa do setor alimentício da região, determinar o nível CMM para validar os resultados obtidos com a Norma NBR ISO/IEC e desenvolver um aplicativo para auxiliar na avaliação da adequação à Norma NBR ISO/IEC Conforme se pode observar, a área de desenvolvimento de software não é o foco principal desta empresa, contudo a mesma está preocupada na qualidade de seus processos de software, pois poderá ter um aumento em seus lucros se estes puderem ser melhorados. A determinação dos itens da Norma NBR ISO/IEC e do nível CMM foi feita através de levantamento bibliográfico e posteriormente comparados com os métodos adotados pela empresa no seu processo de desenvolvimento de software. O aplicativo foi implementado utilizando-se o ambiente Active Servers Page (ASP) juntamente com o Microsoft Access, sendo especificado utilizando-se a Unified Modeling Language (UML) com o apoio da ferramenta Rational Rose. Ao ser executado o aplicativo, será feita uma série de perguntas, cada uma com seu respectivo peso e no seu término será fornecido ao usuário medidas que devem ser tomadas para que a empresa em questionamento seja adequada à norma ISO/IEC Será permitida a inclusão de novas perguntas juntamente com seus respectivos pesos, sendo que estas juntamente com os resultados ficarão armazenadas no Microsoft Access. Existem pelo menos três estudos já realizados interligados com este trabalho de conclusão de curso: Frare (1998) que especifica um roteiro para a implantação da Norma NBR ISO/IEC 12207; Theilacher (2000) que realiza a análise de uma organização de software utilizando o modelo CMM/SEI e Anacleto (1996) que faz a mensuração do processo de software baseado no modelo CMM/SEI. O que difere este trabalho dos demais é o fato do mesmo estar focado em determinar se o processo interno utilizado por uma empresa está de acordo com a Norma NBR ISO/IEC e caso não esteja fornecer respostas do que a empresa precisa implantar para ficar de acordo com a norma em questão.

11 OBJETIVOS DO TRABALHO O objetivo deste trabalho de conclusão de curso é desenvolver um software para auxiliar na avaliação da adequação de uma empresa aos Processos Fundamentais do ciclo de vida da Norma ISO/IEC e determinar o nível CMM da empresa onde o software foi utilizado para validar os resultados obtidos. Os objetivos específicos do trabalho são: a) permitir a inclusão de um check list com perguntas sobre os tópicos propostos pela norma; b) estabelecer quantitativamente o grau de conformidade da empresa em relação a cada tópico da norma; c) permitir a inclusão de novas perguntas de acordo com mudanças na norma ou processos; d) trazer para a empresa avaliada um relatório apontando críticas sobre a situação da mesma frente a cada item da norma. 1.2 ESTRUTURA DO TRABALHO A seguir é descrito brevemente cada capítulo deste trabalho. O primeiro capítulo apresenta a origem, os objetivos e a estrutura do trabalho. O segundo capítulo apresenta uma descrição de modelos existentes para a avaliação dos processos de software e uma breve descrição de trabalhos correlatos. O terceiro capítulo apresenta a Norma ISO/IEC 12207, seus objetivos, necessidades, campo de aplicação, conformidade, limitações e estrutura dos processos. O quarto capítulo apresenta todas as etapas realizadas no desenvolvimento do trabalho acadêmico. O quinto capítulo apresenta as conclusões e sugestões para futuros trabalhos.

12 11 2 MODELOS DE QUALIDADE DE SOFTWARE Segundo Rocha (2001) a globalização da economia tem influenciado as empresas produtoras e prestadoras de serviços de software a alcançar o patamar de qualidade e produtividade internacional para enfrentarem a competitividade cada vez maior. Este reconhecimento é obtido através de certificações a um ou vários modelos de qualidade de software. Segundo Fuggeta (apud ROCHA, 2001) a qualidade de produtos de software está fortemente relacionada à qualidade do processo de software. Assim, na década de 90 houve uma grande preocupação com a modelagem e melhorias no processo de software. Abordagens importantes como as normas ISO 9000, ISO/IEC 12207, o modelo CMM e o SPICE sugerem que melhorando o processo de software, pode-se melhorar a qualidade dos produtos (PFLEEGER apud Rocha (2001)). 2.1 MODELOS A seguir tem-se uma descrição geral dos principais modelos e normas de Qualidade de Software. A Norma ISO/IEC será tratada em um capítulo a parte devido sua importância para este trabalho ISO 9001/ Segundo Rocha (2001) a norma ISO 9001 abrange todo o ciclo de vida de um produto ou serviço, cobrindo os requisitos para a garantia de qualidade em projetos, desenvolvimento, produção, instalação e serviços associados e a norma ISO estabelece diretrizes para a aplicação da norma ISO 9001 ao desenvolvimento, fornecimento e à manutenção de software. Segundo Barreto [200-] todas as orientações da norma ISO giram em torno de uma situação contratual, onde uma parte contrata outra para desenvolver um produto de software. A tabela 1 apresenta os processos definidos da norma ISO :

13 12 Tabela 1 Processos definidos da norma ISO Grupo Atividade Estrutura do Sistema de Qualidade Responsabilidade do fornecedor; Responsabilidade do comprador; Análise crítica conjunta. Atividades do Ciclo de Vida Análise crítica do contrato; Especificação dos requisitos do comprador; Planejamento do desenvolvimento; Projeto e implementação; Testes e validação; Aceitação; Cópia, entrega e instalação; Manutenção. Atividades de Apoio Gerenciamento de configuração; Controle de documentos; Registros da qualidade; Medição; Regras, convenções; Aquisição; Produto de software incluído; Treinamento. Fonte: Barreto [200-] CMM Segundo Barreto [200-] o modelo CMM (Capability Maturity Model) é uma iniciativa do SEI (Software Engineering Institute) para avaliar e melhorar a capacitação de empresas que produzem software e foi financiado pelo Departamento de Defesa do Governo dos Estados Unidos, que precisava de um modelo formal que permitisse selecionar os seus fornecedores de software de forma adequada Maturidade Segundo Barreto [200-] o CMM é um modelo para medição da maturidade de uma organização no que diz respeito ao processo de desenvolvimento de software. A definição do que é Maturidade pode ser mais bem compreendida através da análise da tabela 2.

14 13 Tabela 2: Maturidade Organizações maduras Organizações imaturas Papéis e responsabilidades bem definidos Processo improvisado Existe base histórica Não existe base histórica É possível julgar a qualidade do produto Não há maneira objetiva de julgar a qualidade do produto A qualidade dos produtos e processos é Qualidade e funcionalidade do produto monitorada sacrificadas O processo pode ser atualizado Não há rigor no processo a ser seguido Existe comunicação entre o gerente e seu Resolução de crises imediatas grupo Fonte: Barreto [200-] Níveis O CMM classifica as organizações em cinco níveis distintos, cada um com suas características próprias. No nível 1, o das organizações mais imaturas, não há nenhuma metodologia implementada e tudo ocorre de forma desorganizada. No nível 5, o das organizações mais maduras, cada detalhe do processo de desenvolvimento está definido, quantificado e acompanhado e a organização consegue até absorver mudanças no processo sem prejudicar o desenvolvimento. Veja a tabela 3. Tabela 3: Níveis CMM Nível CMM Descrição 1) Inicial O processo de desenvolvimento é desorganizado e até caótico. Poucos processos são definidos e o sucesso depende de esforços individuais e heróicos. 2) Repetível Os processos básicos de gerenciamento de projeto estão estabelecidos e permitem acompanhar custo, cronograma e funcionalidade. É possível repetir o sucesso de um processo utilizado anteriormente em outros projetos similares. 3) Definido Tanto as atividades de gerenciamento quanto de engenharia do processo de desenvolvimento de software estão documentadas, padronizadas e integradas em um padrão de desenvolvimento da organização. Todos os projetos utilizam uma versão aprovada e adaptada do processo padrão de desenvolvimento de software da organização. 4) Gerenciado São coletadas medidas detalhadas da qualidade do produto e processo de desenvolvimento de software. Tanto o produto quanto o processo de desenvolvimento de software são entendidos e controlados quantitativamente. 5) Otimizado O melhoramento contínuo do processo é conseguido através de um "feedback" quantitativo dos processos e pelo uso pioneiro de idéias e tecnologias inovadoras. Fonte: Barreto [200-]. Uma empresa no nível 1 não dá garantia de prazo, custo ou funcionalidade. No nível 2, a empresa já consegue produzir bons softwares, no prazo e a um custo previsível. O nível 3

15 14 garante um excelente nível de qualidade, tanto no produto quanto no processo de desenvolvimento como um todo. Não há, no mundo, muitas empresas que tenham chegado aos níveis 4 e 5 (BARRETO [200-]) SPICE Segundo Rocha (2001) Spice (Software Process Improvement and Capability Determination) é o nome do projeto de elaboração da norma ISO/IEC 15504, que se presta à realização de avaliações de processos de software com dois objetivos: a) melhoria dos processos; b) determinação da capacidade de processos de uma organização. Uma das contribuições do modelo SPICE é definir em seu modelo de referência todos os processos envolvidos no desenvolvimento de software, agrupados em categorias (BARRETO [200-]). Observe na tabela 4 a estrutura completa das categorias e dos processos de cada categoria. O SPICE, entretanto, não se limita a listar categorias e processos. Seu principal objetivo é avaliar a capacitação da organização em cada processo e permitir a sua melhoria. O modelo de referência do SPICE inclui seis níveis de capacidade. Cada um dos processos mencionados acima deve ser classificado nestes níveis (BARRETO [200-]). Os níveis são descritos na tabela 5.

16 15 Tabela 4: Categorias e Processos Processo Descrição CUS Cliente Fornecedor Processos que provocam impacto diretamente nos produtos e serviços de software do fornecedor para o cliente. CUS. 1 Adquirir Software. CUS. 2 Gerenciar necessidades do Cliente. CUS. 3 Fornecer Software. CUS. 4 Operar Software. CUS. 5 Prover Serviço ao Cliente. ENG Engenharia Processos que especificam, implementam ou mantém um sistema ou produto de software e sua documentação. ENG. 1 Desenvolver requisitos e o projeto do sistema. ENG. 2 Desenvolver requisitos de software. ENG. 3 Desenvolver o projeto do software. ENG. 4 Implementar o projeto do software. ENG. 5 Integrar e testar o software. ENG. 6 Integrar e testar o sistema. ENG. 7 Manter o sistema e o software. SUP Suporte Processos que podem ser empregados por qualquer um dos processos. SUP. 1 Desenvolver a documentação. SUP. 2 Desempenhar a gerência de configuração. SUP. 3 Executar a garantia da qualidade. SUP. 4 Executar a verificação dos produtos de trabalho. SUP. 5 Executar a validação dos produtos de trabalho. SUP. 6 Executar revisões conjuntas. SUP. 7 Executar auditorias. SUP. 8 Executar resolução de problemas. MAN Gerência Processos que contém práticas de natureza genérica que podem ser usadas por quem gerencia projetos ou processos dentro de um ciclo de vida de software. MAN. 1 Gerenciar o projeto. MAN. 2 Gerenciar a qualidade. MAN. 3 Gerenciar riscos. MAN. 4 Gerenciar subcontratantes. ORG Organização Processos que estabelecem os objetivos de negócios da organização. ORG. 1 Construir o negócio. ORG. 2 Definir o processo. ORG. 3 Melhorar o processo. ORG. 4 Prover recursos de treinamento. ORG. 5 Prover infra-estrutura organizacional. Fonte: Barreto [200-].

17 16 Tabela 5: Níveis Spice Nível Nome Descrição 0 Incompleto Há uma falha geral em realizar o objetivo do processo. Não existem produtos de trabalho nem saídas do processo facilmente identificáveis. 1 Realizado O objetivo do processo em geral é atingido, embora não necessariamente de forma planejada e controlada. Há um consenso na organização de que as ações devem ser realizadas e quando são necessárias. Existem produtos de trabalho para o processo e eles são utilizados para atestar o atendimento dos objetivos. 2 Gerenciado O processo produz os produtos de trabalho com qualidade aceitável e dentro do prazo. Isto é feito de forma planejada e controlado. Os produtos de trabalho estão de acordo com padrões e requisitos. 3 Estabelecido O processo é realizado e gerenciado usando um processo definido, baseado em princípios de Engenharia de Software. As pessoas que implementam o processo usam processos aprovados, que são versões adaptadas do processo padrão documentado. 4 Previsível O processo é realizado de forma consistente, dentro dos limites de controle, para atingir os objetivos. Medidas da realização do processo são coletadas e analisadas. Isto leva a um entendimento quantitativo da capacitação do processo a uma habilidade de predizer a realização. 5 Otimizado A realização do processo é otimizada para atender as necessidades atuais e futuras do negócio. O processo atinge seu objetivo de negócio e consegue ser repetido. São estabelecidos objetivos quantitativos de eficácia e eficiência para o processo, segundo os objetivos da organização. A monitoração constante do processo segundo estes objetivos é conseguida obtendo feedback quantitativo e o melhoramento é conseguido pela análise dos resultados. A otimização do processo envolve o uso piloto de idéias e tecnologias inovadoras, além da mudança de processos ineficientes para atingir os objetivos definidos. Fonte: Barreto [200-]. 2.2 TRABALHOS CORRELATOS Há pelo menos três estudos desenvolvidos na FURB interligados com este Trabalho de Conclusão de Curso. São eles: Theilacher (2000), Frare (1998) e Anacleto (1996) Theilacher O trabalho desenvolvido por Theilacher (2000) informa a existência de modelos de qualidade de software, no qual são incluídos a Norma ISO 9001, NBR ISO/IEC 12207, BOOTSTRAP, SPICE e explica em detalhes o modelo CMM fazendo referência ao seu histórico, conceito, estrutura, formas de avaliação e evolução. Foi feito em forma de estágio na empresa Datasul havendo então uma apresentação desta que inclui o seu histórico, áreas da atuação, processo de software e qualidade já aplicados pela empresa.

18 17 Em cada fase da avaliação do processo de software ocorre uma descrição das atividades desenvolvidas incluindo: seleção de equipe de avaliação, aplicação do questionário da maturidade, análise das respostas, entrevistas e revisões dos documentos, avaliação baseada no modelo e método proposto pelo CMMI e quadro de verificação das áreas-chave de processo. O protótipo de software de apoio foi desenvolvido utilizando-se o Progress versão 8.3C e realiza o gerenciamento dos questionários previstos no modelo. Além disto o relatório de Estágio Supervisionado incluiu a apresentação, especificação e demonstração do funcionamento do protótipo Anacleto O trabalho de Anacleto (1996) apresenta um estudo do modelo CMM, propondo uma forma de mensuração do processo de software. O modelo CMM é explicado em detalhes incluindo suas origens, conceitos, estrutura e formas de avaliação além de explicar superficialmente os modelos ISO , NBR ISO/IEC 1207, Spice e BOOTSRAPT. Houve a criação de três questionários do modelo CMM. O primeiro questionário tem o objetivo de obter o perfil da organização a ser avaliada. O segundo questionário objetiva verificar se a organização atende as diversas metas definidas para todas as áreas-chave do processo de software. O terceiro questionário objetiva checar, após a análise dos resultados do segundo questionário, a efetividade das atividades que sustentam as diversas áreas-chave do processo e suas metas respectivamente. O questionário foi aplicado pelos alunos de Análise e Projeto de Sistemas I através de entrevista em 17 empresas. Com as respostas houve a avaliação das mesmas. O trabalho também inclui a descrição, definição e explicação do protótipo, sendo que este foi desenvolvido em Microsoft Access e realiza as perguntas criadas nos três questionários e fornece o resultado quanto ao atendimento do modelo.

19 Frare O trabalho de Frare (1998) apresenta conceitos de qualidade de software e os modelos ISO 9001, ISO , CMM, Spice e BOOTSTRAP. Além disto contém a explicação da Norma NBR ISO/IEC 12207, fases de implantação e roteiro de aplicação da Norma. Um roteiro que facilite a implantação da Norma NBR ISO/IEC é criado e apresentado através de diagramas servindo então como um guia para o responsável pela implementação da norma em uma organização. O roteiro é apoiado por um protótipo de ferramenta, que é um roteiro eletrônico. Todas as recomendações e ações inseridas nos diagramas podem ser obtidas da mesma forma usando-se tal ferramenta, guiando assim o responsável pela implantação por computador. E ainda, o trabalho apresenta sugestões de melhorias do roteiro e da ferramenta sugerida.

20 19 3 A NORMA ISO/IEC Segunda a norma ISO/IEC (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 1998) software é uma parte fundamental da tecnologia de informação e de sistemas convencionais, tais como sistemas de transportes, militares, da área médica e financeira. Atualmente tem havido uma proliferação de normas, procedimentos, métodos, ferramentas e ambientes de desenvolvimento e de gerência de software. Esta proliferação tem criado dificuldades na gerência e engenharia de software, principalmente na integração de produtos e serviços. A disciplina de software necessita migrar desta proliferação para uma estrutura comum que possa ser usada por profissionais de software para falar a mesma língua na criação e gerência de software. Esta Norma provê tal estrutura comum. 3.1 CARACTERÍSTICAS GERAIS A seguir tem-se uma descrição completa das características da Norma ISO/IEC Processos de Software É o conjunto de todas as atividades relacionadas ao desenvolvimento, controle, validação e manutenção de um software operacional, ligado tanto à área técnica quanto à gerência (HUGO apud Frare (1998)). O processo de software envolve os recursos disponíveis e é baseado nos requisitos solicitados para o sistema, gerando os produtos ou serviços de software. Os modelos de avaliação verificam se um processo de software é capaz de gerar produtos de software com qualidade garantida (HUGO apud Frare (1998)) Objetivo A Norma ISO/IEC estabelece uma estrutura comum para os processos de ciclo de vida de software desde a concepção de idéias até a descontinuação do software com uma terminologia bem definida e é composta de processos, atividades e tarefas que servem para ser aplicada durante a aquisição de um sistema que contém software, de um produto de software independente ou de um serviço de software, e durante o fornecimento, desenvolvimento, operação e manutenção de produtos de software. Além disto a Norma também provê um

21 20 processo que pode ser utilizado para definir, controlar e melhorar os processos de ciclo de vida de software (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 1998) Campo de Aplicação A Norma ISO/IEC (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 1998) aplica-se, quer seja executada interna ou externamente a uma organização, a auxiliar os envolvidos na produção de software a definir seus papéis, por meio de processos bem definidos, e assim proporcionar às organizações que a utilizam um melhor entendimento das atividades a serem executadas nas operações que envolvem, de alguma forma, o software (Rocha, 2001). Destina-se a ser utilizada em uma relação que envolva duas partes, sendo que estas podem pertencer à mesma organização. Esta relação pode ser estabelecida através de um acordo informal ou um contrato legal e pode ser utilizada por uma única parte por meio de tarefas impostas a ela mesma. Os processos formam um conjunto abrangente. Uma organização, dependendo de seu objetivo, pode selecionar um subconjunto apropriado para satisfazê-lo. Esta Norma é, portanto, projetada para ser adaptada para uma organização, projeto ou aplicação específicos. Também é projetada para ser utilizada quando o software é uma entidade independente ou embutida ou integrada a um sistema. A norma não se aplica para os produtos de software de prateleira, a menos que eles estejam incorporados dentro de um produto encomendado e foi escrita para adquirentes de sistemas e produtos e serviços de software, e para fornecedores, desenvolvedores, operadores, mantenedores, gerentes, gerentes de garantia de qualidade e usuários dos produtos de software Conformidade Segundo ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (1998) a conformidade a esta norma é definida como a execução de todos os processos, atividades e tarefas. A execução de um processo ou uma atividade é concluída quando todas as suas tarefas requeridas são executadas de acordo com os critérios preestabelecidos e com os requisitos especificados no contrato, quando aplicável.

22 21 Para auxiliar a determinar o grau de requerimento de uma determinada tarefa a Norma utiliza-se de verbos auxiliares que integram o corpo da tarefa. São eles: a) deve: expressam uma obrigação entre duas ou mais partes; b) deverá: expressa uma declaração de objetivo ou intenção de uma das partes; c) deveria: expressa uma recomendação entre várias possibilidades; d) pode: indica uma ação permitida dentro dos limites da Norma Limitações Segundo ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (1998) a Norma ISO/IEC 12207: a) não especifica os detalhes de como implementar ou executar as atividades e tarefas incluídas nos processos de ciclo de vida de software; b) não pretende prescrever o nome, formato ou conteúdo explícito na documentação a ser produzida. A Norma pode requerer o desenvolvimento de documentos de mesma categoria ou tipo, contudo não sugere que tais documentos sejam desenvolvidos ou emitidos separadamente ou combinados de alguma forma. Estas decisões são deixadas para o usuário da Norma; c) não prescreve um modelo específico de ciclo de vida ou método de desenvolvimento de software. As partes envolvidas com esta Norma são responsáveis pela seleção de um modelo de ciclo de vida para o projeto de software e pelo mapeamento dos processos, atividades e tarefas da Norma dentro do modelo. As partes envolvidas são também responsáveis pela seleção e aplicação dos métodos de desenvolvimento de software e pela execução das atividades e tarefas adequadas ao projeto de software; d) não pretende entrar em conflito com quaisquer políticas, normas ou procedimentos já existentes na organização. Entretanto, qualquer conflito necessita ser resolvido e quaisquer condições e situações de sobreposição precisam ser citadas por escrito como exceções para a aplicação da Norma. 3.2 ESTRUTURA DA NORMA A norma ISO/IEC agrupa as atividades que podem ser executadas durante o ciclo de vida de software em cinco processos fundamentais, oito processos de apoio e quatro

23 22 processos organizacionais. Cada processo de ciclo de vida é dividido em um conjunto de atividades, cada atividade é então dividida em um conjunto de tarefas. Para maiores detalhes veja a fig. 1. Fonte: ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (1998). Figura 1: Estrutura da Norma ISO/IEC Processos Fundamentais Segundo (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 1998) os processos fundamentais constituem um conjunto de cinco processos que atendem as partes fundamentais (pessoa ou organização) durante o ciclo de vida de software. Uma parte fundamental é aquela que inicia ou executa o desenvolvimento, operação ou manutenção dos

24 23 produtos de software. Estas partes fundamentais são o adquirente, o fornecedor, o desenvolvedor, o operador e o mantenedor do software. Os conceitos sobre os processos a seguir foram extraídos de (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 1998) Processo de Aquisição O processo de aquisição contém as atividades e tarefas do adquirente. Inicia-se com a definição da necessidade de adquirir um sistema, um produto de software ou um serviço de software. O processo continua com a preparação e emissão de pedido de proposta, seleção de fornecedor e gerência do processo de aquisição através da aceitação do sistema, produto de software ou serviço de software. As organizações individuais, que tem a necessidade, podem ser chamadas de proprietárias. O proprietário pode contratar algumas ou todas as atividades de aquisição junto a um agente que, por sua vez conduzirá estas atividades de acordo com o processo de aquisição. O adquirente então pode ser tanto o proprietário quanto o agente contratado por ele Processo de Fornecimento O processo de fornecimento contém as atividades e as tarefas do fornecedor. O processo pode ser iniciado tanto por uma decisão de preparar uma proposta para responder a um pedido de proposta de um adquirente quanto pela assinatura e celebração de um contrato com o adquirente para fornecer o sistema, produto de software ou serviço de software. O processo continua com a determinação dos procedimentos e recursos necessários para gerenciar e garantir o projeto, incluindo o desenvolvimento e a execução dos planos de projeto até a entrega do sistema, produto de software ou serviço de software para o adquirente Processo de Desenvolvimento O processo de desenvolvimento contém as atividades e tarefas do desenvolvedor. O processo contém as atividades para análise de requisitos, projeto, codificação, integração, testes, instalação e aceitação relacionadas aos produtos de software. Pode conter atividades

25 24 relacionadas ao sistema, se estipulado no contrato. O desenvolvedor executa ou apóia as atividades neste processo, de acordo com o contrato Processo de Operação O processo de operação contém as atividades e as tarefas do operador. O processo cobre a operação do produto de software e o suporte operacional aos usuários. Como a operação do produto de software está integrada à operação do sistema, as atividades e tarefas deste processo se referem ao sistema Processo de Manutenção O processo de manutenção contém as atividades e tarefas do mantenedor. Este processo é ativado quando o produto de software é submetido a modificações no código e na documentação associada devido a um problema, ou à necessidade de melhoria ou adaptação. O objetivo é modificar um produto de software existente, preservando a sua integridade. Este processo inclui a migração e a descontinuação do produto de software. O processo termina com a descontinuação do produto de software Processos de Apoio Os processos de apoio ao ciclo de vida constituem um conjunto de oito processos. Um processo de apoio auxilia um outro processo como uma parte integrante, com um propósito distinto, e contribui para o sucesso e qualidade do projeto de software. Um processo de apoio é empregado e executado, quando necessário, por outro processo. Os processos de apoio são mostrados a seguir Processo de Documentação O processo de documentação é um processo para registrar informações produzidas por um processo ou atividade do ciclo de vida. O processo contém o conjunto de atividades que planeja, projeta, desenvolve, produz, edita, distribui e mantém aqueles documentos necessários a todos os interessados, tais como gerentes, engenheiros e usuários do sistema ou produto de software.

26 Processo de Gerência de Configuração Processo de gerência de configuração é um processo de aplicação de procedimentos administrativos e técnicos, por todo o ciclo de vida de software, destinado a identificar e definir os itens de software em um sistema e estabelecer suas linhas básicas; controlar as modificações e liberações dos itens; registrar e apresentar a situação dos itens e dos pedidos de modificação; garantir a completeza, a consistência e a correção dos itens; e controlar o armazenamento, a manipulação e distribuição dos itens Processo de Garantia de Qualidade O processo de garantia de qualidade é um processo para fornecer garantia adequada de que os processos e produtos de software, no ciclo de vida do projeto, estejam em conformidade com seus requisitos especificados e sejam aderentes aos planos estabelecidos. Para ser imparcial, a garantia de qualidade necessita ter autoridade e autonomia organizacional, independente das pessoas diretamente responsáveis pelo desenvolvimento do produto de software ou pela execução do processo do projeto. A garantia de qualidade pode ser interna ou externa, dependendo da necessidade da qualidade do produto ou do processo ser evidenciado para a gerência do fornecedor ou do adquirente. A garantia de qualidade pode utilizar os resultados de outros processos de apoio tais como: verificação, validação, revisões conjuntas, auditorias e resolução do problema Processo de Verificação O processo de verificação é um processo para determinar se os produtos de software de uma atividade atendem completamente os requisitos ou condições impostas a eles nas atividades anteriores. Para a eficácia de custo e desempenho, a verificação deveria ser integrada, o quanto antes, com o processo que a utiliza (tais como fornecimento, desenvolvimento, operação ou manutenção). Este processo pode incluir análise, revisão e teste.

27 Processo de Validação O processo de validação é um processo para determinar se os requisitos e o produto final, sistema ou produto de software construído, atendem ao uso específico pretendido. A validação pode ser conduzida como parte ou atividade de apoio à aceitação do software Processo de Revisão Conjunta O processo de revisão conjunta é um processo para avaliar a situação e produtos de uma atividade de um projeto, se apropriado. As revisões conjuntas são feitas tanto nos níveis de gerenciamento do projeto como nos níveis técnicos e são executados durante a vigência do contrato. Este processo pode ser empregado por qualquer das duas partes, onde uma parte (parte revisora) revisa a outra parte (parte revisada) Processo de Auditoria O processo de auditoria é um processo para determinar adequação aos requisitos, planos e contrato, quando apropriado. Este processo pode ser empregado por quaisquer das duas partes, onde uma parte (parte auditora) faz a auditoria nos produtos de software ou nas atividades da outra parte (parte auditada) Processo de Resolução de Problemas O processo de resolução de problema é um processo para analisar e resolver os problemas (incluindo não-conformidades), de qualquer natureza ou fonte, que são descobertos durante a execução do desenvolvimento, operação, manutenção ou outros processos. O objetivo é prover os meios em tempo adequado e de forma responsável e documentada para garantir que todos os problemas encontrados sejam analisados e resolvidos e tendências sejam identificadas Processos Organizacionais Os processos organizacionais de ciclo de vida constituem um conjunto de quatro processos. Eles são empregados por uma organização para estabelecer e implementar uma estrutura subjacente, constituída de processos de ciclo de vida e pessoal associado e melhorar continuamente a estrutura e os processos. Eles são tipicamente empregados fora do domínio

28 27 de projetos e contratos específicos; entretanto, ensinamentos destes projetos e contratos contribuem para a melhoria da organização Processo de Gerência O processo de gerência contém as atividades e tarefas genéricas que podem ser empregadas por quaisquer das partes que têm que gerenciar seu(s) respectivo(s) processo(s). O gerente é responsável pelo gerenciamento de tarefa do(s) processo(s) aplicável(eis), tais como aquisição, fornecimento, desenvolvimento, operação, manutenção ou processos de apoio Processo de Infra-estrutura O processo de infra-estrutura é um processo para estabelecer e manter a infra-estrutura necessária para qualquer outro processo. A infra-estrutura pode incluir hardware, software, ferramentas, técnicas, padrões e recursos para o desenvolvimento, operação ou manutenção Processo de Melhoria O processo de melhoria é um processo para estabelecer, avaliar, medir, controlar e melhorar um processo de ciclo de vida de software Processo de Treinamento O processo de treinamento é um processo para prover e manter pessoal treinado. A aquisição, o fornecimento, o desenvolvimento, a operação ou a manutenção de produtos de software é extremamente dependente de pessoal com conhecimento e qualificação. Por exemplo: pessoal de desenvolvimento deveria ter treinamento básico em gerência de software e engenharia de software. É, portanto, imperativo que o treinamento de pessoal seja planejado e implementado com antecedência para que o pessoal treinado esteja disponível quando o produto de software for adquirido, fornecido, desenvolvido, operado ou mantido. 3.3 RELAÇÃO CMM E NBR ISO/IEC A Norma NBR ISO/IEC parece alcançar o nível 3 de maturidade do CMM. Esta correlação fica mais clara através da tabela 6, que demonstra o mapeamento do

29 28 relacionamento entre as áreas-chave de processo do CMM e os processos da Norma NBR ISO/IEC (GRAHL, 1997). Outros processos da Norma NBR ISO/IEC não citados na tabela 6 também são utilizados em sua aplicação. Como por exemplo, o processo de Documentação que provê meios de registro de informações produzidas por qualquer processo (GRAHL, 1997). Tabela 6 Relacionamento entre CMM e Norma NBR ISO/IEC Nível CMM Áreas-Chave de Processo CMM Processos da ISO/IEC Gerenciamento de Requisitos Aquisição, Fornecimento 2 Planejamento do Projeto de Software Aquisição, Fornecimento, Gerência 2 Acompanhamento e Supervisão do Projeto Gerência, Revisão Conjunta, Resolução de Problema 2 Gerenciamento da Sub-Contratação de Software Aquisição, Fornecimento 2 Garantia da Qualidade de Software Garantia da Qualidade, Verificação, Validação, Revisão Conjunta, Auditoria, Resolução de Problema 2 Gerenciamento de Configuração de Software Gerência de Configuração 3 Foco nos Processos da Organização Melhoria 3 Definição do Processo da Organização Melhoria, Desenvolvimento 3 Programa de Treinamento Treinamento 3 Gerenciamento Integrado de Software Gerência, Desenvolvimento 3 Engenharia do Produto de Software Desenvolvimento, Manutenção 3 Coordenação Inter-Grupos Desenvolvimento, Revisão Conjunta, Resolução de Problema 3 Revisões Revisão Conjunta, Resolução de Problema 4 Gerenciamento Quantitativo do Processo Melhoria 4 Gerenciamento da Qualidade de Software Garantia da Qualidade, Validação 5 Prevenção de Defeitos Resolução de Problema, Melhoria, Revisão Conjunta 5 Gerenciamento da Mudança de Tecnologia Infra-estrutura 5 Gerenciamento da Mudança do Processo Melhoria Fonte: retirado de Grahl (1997) A tabela 7 mostra os graus de atendimento de cada área-chave de processo do CMM pela Norma NBR ISO/IEC Os resultados apresentados baseiam-se na verificação do atendimento das metas estabelecidas em cada área-chave. Uma área-chave possui um alto grau de atendimento quando 2/3 ou mais de suas metas possui relação direta com atividades e tarefas dos processos da Norma NBR ISO/IEC Uma área-chave possui um baixo grau de atendimento quando menos de 1/3 de suas metas possui relação direta com atividades e tarefas dos processos da Norma NBR ISO/IEC Finalmente, o grau médio encontra-se entre as duas faixas citadas (GRAHL, 1997).

30 Tabela 7 - Grau de atendimento de cada área-chave Nível Áreas-Chave de Processo CMM Grau de Atendimento CMM Baixo Médio Alto 2 Gerenciamento de Requisitos 2 Planejamento do Projeto de Software 2 Acompanhamento e Supervisão do Projeto 2 Gerenciamento da Sub-Contratação de Software 2 Garantia da Qualidade de Software 2 Gerenciamento de Configuração de Software 3 Foco nos Processos da Organização 3 Definição do Processo da Organização 3 Programa de Treinamento 3 Gerenciamento Integrado de Software 3 Engenharia do Produto de Software 3 Coordenação Inter-Grupos 3 Revisões 4 Gerenciamento Quantitativo do Processo 4 Gerenciamento da Qualidade de Software 5 Prevenção de Defeitos 5 Gerenciamento da Mudança de Tecnologia 5 Gerenciamento da Mudança do Processo Fonte: retirado de Grahl (1997) 29

31 30 4 DESENVOLVIMENTO DO TRABALHO O objetivo deste trabalho é desenvolver um software para auxiliar na avaliação da adequação de uma empresa aos Processos Fundamentais do ciclo de vida da Norma NBR ISO/IEC e determinar o nível CMM da empresa onde o software foi utilizado para validar os resultados obtidos. Através dos resultados fornecidos pelo software desenvolvido são obtidos os itens adotados nos Processos Fundamentais do ciclo de vida da Norma NBR ISO/IEC O nível CMM é obtido através da aplicação dos questionários desenvolvidos por Anacleto (1996). O software e os questionários foram aplicados em uma grande empresa do setor alimentício da região que atualmente possui funcionários e que obteve o faturamento de R$ 1,7 bilhões em O setor responsável pelo desenvolvimento de softwares desta empresa é composto de 20 funcionários e 4 terceiros, sendo que todos os itens aplicados foram respondidos pelo gerente do setor que possui como formação acadêmica o Bacharelado em Ciências Contábeis (FURB), pós-graduação em Administração de Negócios (INPG) e que trabalha na área de Informática desde DETERMINAÇÃO DO NÍVEL CMM Para determinar o atual nível CMM da empresa foram aplicados os questionários desenvolvidos por Anacleto (1996) e para obter maiores informações sobre os mesmos Anacleto (1996) pode ser consultada. A metodologia utilizada pela empresa no desenvolvimento de seus sistemas encontrase no Anexo A. O primeiro questionário que objetiva obter o perfil da organização (ANACLETO, 1996) encontra-se respondido no Anexo B. O segundo questionário que objetiva verificar se a organização atende as diversas metas definidas para todas as áreas-chave do processo de software (ANACLETO, 1996) encontram-se respondido no Anexo C.

32 31 Com o segundo questionário respondido realizou-se o mapeamento das questões por áreas-chaves de processo e determinou-se que apenas as perguntas 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 41, 42, 43, 44, 45, 46, 47, 48, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71 e 72 do terceiro questionário deveriam ser feitas à empresa. O terceiro questionário que objetiva checar a efetividade das atividades que sustentam as diversas áreas-chaves de processo e suas metas (ANACLETO, 1996) encontra-se respondido no Anexo D. Tabela 8 Atendimento a área-chave de processo CMM Não Atende Atende Parcialmente Atende Nível 1 Inicial X Nível 2 Repetitivo X Gerenciamento de Configuração de X Software Garantia da Qualidade de Software X Gerenciamento da Sub-Contratação de X Software Acompanhamento e Supervisão do Projeto de X Software Planejamento do Projeto de Software X Gerenciamento de Requisitos de Software X Nível 3 Definido X Revisões X Coordenação Inter-Grupos X Engenharia do Produto de Software X Gerenciamento Integrado de Software X Programa de Treinamento X Definição do Processo da Organização X Foco nos Processos da Organização X Nível 4 Gerenciado X Gerenciamento da Qualidade de Software X Gerenciamento Quantitativo do Processo X Nível 5 Otimização X Gerenciamento da Mudança do Processo X Gerenciamento da Mudança de Tecnologia X Prevenção de Defeitos X Analisando-se as respostas obtidas do terceiro questionário pode-se determinar que a empresa atualmente está no Nível 1 Inicial do CMM, pois o nível 2 não foi atendido e especificamente nenhuma área-chave de processo foi atendida no nível 2 (tabela 8).

33 QUESTIONÁRIO DA NORMA NBR ISO/IEC O questionário desenvolvido neste trabalho trata os Processos Fundamentais de Ciclo de Vida da Norma NBR ISO/IEC e encontra-se no Apêndice A. Os processos de apoio e organizacionais de ciclo de vida não são tratados neste trabalho acadêmico. Como já foi mencionado a Norma NBR ISO/IEC é dividida em processos, atividades e tarefas. As perguntas foram criadas pela análise das tarefas. Através desta determinou-se a quantidade de ações necessárias para realizar individualmente cada tarefa presente na Norma. Cada tarefa gerou n perguntas, sendo que n é igual ao número de ações encontradas no corpo de texto da tarefa. Cada pergunta gerada possui um peso e este é determinado pelo verbo auxiliar utilizado no corpo de texto da tarefa. A pergunta gerada por uma tarefa que possui o verbo deve, deverá, deveria e pode vale, se cumprida, 10, 5,2 e 1 pontos respectivamente. As perguntas possuem as seguintes respostas possíveis: a) sim quando a pergunta foi cumprida. Se selecionada, o valor do peso da pergunta é acrescido à pontuação total do usuário; b) não quando a pergunta não foi cumprida. Se selecionada, nada é acrescido à pontuação total do usuário; c) múltipla escolha a pergunta é composta por uma série de itens de resposta. O usuário seleciona os itens de resposta cumpridos, sendo que para auxiliar existe o item de resposta Todas as opções que deve ser selecionado quando todos são cumpridos e o item de resposta Nenhuma das opções que deve ser selecionado quando nenhum é cumprido. Cada item de resposta possui como peso um valor proporcional ao peso da pergunta. Por exemplo: uma pergunta que tenha como peso o valor 10 e que possua 5 itens de resposta terá cada item cumprido acrescentando 2 pontos a pontuação total do usuário.

34 33 O Apêndice A também contém as soluções para os itens de resposta do questionário e as dependências das perguntas. Com relação às soluções para os itens de resposta do questionário deve-se observar que os itens de resposta Sim e Todas as opções indicam que a pergunta foi cumprida e conseqüentemente não possuem solução e o item de resposta Nenhuma das opções também não possui solução cadastrada, pois quando selecionado fará que seja mostrada ao usuário a solução de todos os itens de resposta da pergunta. Um resumo das perguntas criadas pode ser observado na tabela 9. Tabela 9 Resumo das perguntas criadas

35 34 Processo Atividade Perguntas Aquisição Iniciação 11 Preparação do Pedido de Proposta 08 Preparação e atualização do contrato 09 Monitoração do fornecedor 03 Aceitação e Conclusão 06 Fornecimento Iniciação 02 Preparação de resposta 02 Contrato 02 Planejamento 12 Execução e controle 07 Revisão e avaliação 11 Entrega e conclusão 03 Fornecimento Implementação do processo 08 Análise dos requisitos do sistema 06 Projeto da arquitetura do sistema 11 Análise dos requisitos do software 06 Projeto da arquitetura do software 19 Projeto detalhado do software 21 Codificação e testes de software 14 Integração do software 29 Testes de qualificação do software 22 Integração do sistema 08 Teste de qualificação do sistema 09 Instalação do software 10 Apoio à aceitação do software 06 Operação Implementação do processo 05 Teste operacional 03 Operação do sistema 01 Suporte ao usuário 07 Manutenção Implementação do processo 04 Análise do problema e da modificação 10 Implementação da modificação 08 Revisão/aceitação da manutenção 03 Migração 14 Descontinuação da manutenção REQUISITOS PRINCIPAIS DO SOFTWARE Procurando facilitar o processo de avaliação optou-se pela criação de um aplicativo web, pois seu acesso poderá ser feito de qualquer computador conectado a Internet. A página inicial do aplicativo ( mostrará uma breve descrição da Norma NBR ISO/IEC 12207, explicando sua importância e informando que será

36 35 possível determinar ao usuário se os processos utilizados pela sua organização no desenvolvimento de software estão de acordo com a Norma NBR ISO/IEC Para isso será necessário cadastrar-se. Este processo solicitará que seja informado um usuário, senha, redigitação da senha e endereço de . Com o cadastro efetuado o usuário poderá efetuar o logon no software e acessar a área de questionários, área de relatórios e área administrativa. Ao acessar a área de questionários o usuário poderá escolher o processo que será respondido. Não haverá problemas se o usuário efetuar logout sem o processo estar totalmente respondido. Quando efetuar logon novamente poderá optar por responder um novo processo ou continuar respondendo um processo iniciado anteriormente. Caso opte por continuar respondendo um processo a primeira pergunta a ser feita será a próxima da ordem, tomandose como referência a última pergunta respondida do processo escolhido. Após terminar de responder inteiramente um processo o usuário poderá obter a análise de suas respostas. Estas serão fornecidas na área de relatórios do Software. A análise poderá ser sintética ou detalhada. A análise sintética informará o percentual de adequação à Norma NBR ISO/IEC 12207, sendo esta oferecida para cada par Processo/Atividade. A análise detalhada além de fornecer os dados da análise sintética oferecerá recomendações para a organização ficar de acordo com a Norma NBR ISO/IEC A área administrativa somente será acessada se o usuário utilizado possuir o nível Administrador. O processo de cadastro que estará na página principal fornecerá automaticamente ao usuário informado o nível Normal e este somente poderá ser alterado na Manutenção de Usuários que estará na área administrativa, ou seja, somente quem possuir o nível Administrador poderá alterar o nível de um usuário específico. Também será permitido na área administrativa: a) cadastrar processo. Informação requerida: descrição; b) cadastrar atividade. Informação requerida: processo no qual a nova atividade será subordinada e descrição; c) cadastrar pergunta. Informação requerida: processo e atividade no qual a nova pergunta será subordinada, descrição, tipo (Sim/Não ou Múltipla Escolha) e peso. Após o envio destas informações será solicitado ao usuário que seja fornecido os

37 36 Itens de Resposta/Soluções para esta nova pergunta. Se a nova pergunta for do tipo Sim/Não os itens de resposta Sim e Não serão cadastrados automaticamente sendo solicitado ao usuário apenas à solução do item de resposta Não. Se a nova pergunta for do tipo Múltipla Escolha será solicitado ao usuário que seja preenchido a descrição e solução de todos os itens de resposta, sendo que não haverá limite no número destes. Ao cadastrar um novo Item de Resposta/Solução será possível visualizar todos os Itens de Resposta/Soluções já cadastrados para esta nova pergunta; d) alterar processo cadastrado. Informação requerida: nova descrição para o processo; e) alterar atividade cadastrada. Informação requerida: nova descrição para a atividade; f) alterar pergunta cadastrada. Informação requerida: nova descrição para a pergunta. Será também permitido alterar o tipo e peso da pergunta. Caso o tipo (Sim/Não ou Opções) seja alterado será perguntado ao usuário se realmente deseja aplicar esta alteração e sendo a resposta afirmativa todas os Itens de Resposta/Soluções serão excluídos e o cadastramento de novos Itens de Resposta/Soluções conforme o novo tipo selecionado será solicitado; g) alterar Item de Resposta/Solução. Informação requerida: nova descrição para o Item de Resposta/Solução; h) alterar a ordem em que serão perguntadas as atividades, perguntas e itens de resposta no questionário; i) excluir processo; j) excluir atividade; k) excluir pergunta; l) excluir item de resposta; m) criação de dependências. Informação requerida: determinação do par Item de Resposta/Pergunta. Todas as perguntas sem dependência serão feitas ao usuário. Para restringir que uma determinada pergunta seja feita deve-se criar uma dependência para a mesma. Por exemplo, não seria correto perguntar A definição e análise dos requisitos do software é realizada internamente (por conta própria) ou é terceirizada? se na pergunta anterior o usuário respondeu que em nenhum momento ocorre a definição e análise dos requisitos do software. Para evitar esta situação deve-se criar uma dependência informando que a pergunta A definição e análise dos requisitos do software é realizada internamente (por conta própria) ou é

38 37 terceirizada? somente seja feita se o usuário selecionar o item de resposta Sim da pergunta Quanto ao sistema, ocorre a definição e análise de seus requisitos?. Será possível criar os seguintes tipos de dependência: - um Item de resposta/pergunta. Se o item de resposta for selecionado habilitará a pergunta no questionário feito ao usuário; - vários Itens de resposta/pergunta. Se algum dos itens de resposta estiver selecionado habilitará a pergunta no questionário feito ao usuário; - em cascata. Criar uma dependência da dependência. n) manutenção de usuários: além de permitir que seja possível alterar o nível de um usuário específico, também será permitido que seja cadastrado novo usuário; 4.4 ESPECIFICAÇÃO A especificação do aplicativo web foi baseada na técnica Unified Modeling Language (UML) utilizando a ferramenta Rational Rose. Este ferramenta foi escolhida por ser uma ferramenta que dá suporte a todos os diagramas UML utilizados nesta especificação, e por ter sido abordado durante o período acadêmico. Os diagramas utilizados foram: diagrama de casos de uso, diagrama de classes e diagrama de seqüência Casos de Uso Os casos de uso do aplicativo podem ser observados na fig. 2. Abaixo se tem a descrição dos mesmos. Criar Processo: o administrador informa a descrição do processo. Criar Atividade: o administrador informa o processo em que a atividade estará subordinada e sua descrição. Criar Tarefa: o administrador informa o processo e atividade em que a tarefa estará subordinada, sua descrição, tipo e peso. Se o tipo informado for 1 o administrador informa a solução do item de resposta Não e se o tipo informado for 2 o administrador informa o par item de resposta/solução, sendo que não há limite para este. Criar dependência: o administrador seleciona o par pergunta/item de resposta para criar a dependência.

39 38 Criar usuário: o administrador e respondente informam usuário, senha, redigitação da senha e endereço de . Contudo o administrador possui a opção de selecionar o nível do novo usuário ( Normal ou Administrador ) enquanto todo novo usuário cadastrado pelo respondente possui nível Normal. Criar Processo Criar Atividade Administrador Criar Tarefa Criar Dependencia Responder questionario Criar usuario Respondente Gerar Relatorio de Adequacao FIGURA 2 Casos de Uso Responder Questionário: o usuário seleciona o processo que deseja responder e com isso as perguntas começam a ser feitas. Para cada pergunta o usuário fornece uma resposta. Com a resposta fornecida a próxima pergunta é feita. Quando não houver mais perguntas a serem feitas será informado ao usuário que o processo foi respondido completamente. Gerar relatório de Adequação: o relatório de adequação pode ser sintético ou detalhado. No relatório sintético o usuário seleciona o processo desejado e é fornecido o percentual de adequação a Norma para cada par processo/atividade. No relatório detalhado o usuário seleciona um processo e são fornecidas as informações do relatório sintético e recomendações para a organização ficar de acordo com a Norma NBR ISO/IEC

40 Diagramas de classes O diagrama de classes do aplicativo pode ser observado na fig. 3. Abaixo se tem uma explicação sobre o mesmo. Processo cd_processo : Integer ds_processo : String Criar() Obter() 1 1..* Atividade cd_atividade : Integer ds_atividade : String ord_atividade : Integer Criar() Obter() CalculaPercentualAdquacao() ObterSolucao() 1 1..* Tarefa cd_tarefa : Integer ds_tarefa : String tipo : Integer peso : Integer ord_tarefa : Integer Obter() Criar() InsereDependencia() ObterPeso() Usuario cd_usuario : Integer username : String password : String String nivel : Integer criar() 1 respondida 1 0..* depende fornece 1..* Opcao 0..* cd_opcao : Integer ds_opcao : String solucao : String ord_opcao : Integer Obter() Criar() SetaSolucao() contem 1 1..* Resposta cd_resposta : Integer Obter() Fornece() 0..* FIGURA 3 Diagrama de classes A classe Processo contém o código e a descrição dos processos da Norma. A classe Atividade contém o código, descrição e ordem em que a atividade será perguntada no questionário. Além disso, indica que a classe está subordinada à classe Processo. A classe Tarefa contém o código, descrição, tipo, peso e ordem que a tarefa será perguntada no questionário e indica que a classe está subordinada à classe Atividade. A classe Opção contém o código, descrição, solução e ordem em que a opção será perguntada no questionário. Ocorre a indicação que uma tarefa pode ser respondida por uma ou muitas opções e cada opção pertence a uma tarefa, pois o código da opção é único.

41 40 Também indica que uma tarefa pode depender de nenhuma ou várias opções e que uma opção pode gerar nenhuma ou várias tarefas. A classe Resposta armazena as respostas fornecidas pelo usuário. A classe Usuário contém o código, nome de usuário, senha, endereço de e nível dos usuários criados no aplicativo Diagrama de seqüência Abaixo se podem observar os diagramas de seqüência dos casos de uso do aplicativo. Criar Processo: o diagrama de seqüência pode ser observado na fig. 4. : Administrador : Processo Criar( ) FIGURA 4 Diagrama de seqüência do caso de uso Criar Processo Criar Atividade: o diagrama de seqüência pode ser observado na fig. 5.

42 41 : Administrador : Processo : Atividade Obter( ) Criar( ) FIGURA 5 Diagrama de seqüência do caso de uso Criar Atividade Criar Tarefa: o diagrama de seqüência pode ser observado na fig. 6 e na fig.7. Na fig. 6 o tipo informado é 1 e na fig. 7 o tipo informado é 2. : Administrador : Proces so : Atividade : Tarefa : Opcao Obter( ) Obter( ) Criar( ) Criar(Sim) Criar(Nao) SetaSolucao(Nao) FIGURA 6 diagrama de seqüência do caso de uso Criar Atividade (Tipo 1)

43 42 : Respondente : Processo : Atividade : Tarefa : Opcao Obter( ) Obter( ) Criar( ) Criar( ) SetaSolucao( ) FIGURA 7 diagrama de seqüência do caso de uso Criar Atividade (Tipo 2) Criar Dependência: o diagrama de seqüência pode ser observado na fig. 8. : Administrador : Tarefa : Opcao Obter( ) Obter( ) InsereDependencia( ) FIGURA 8 Diagrama de seqüência do caso de uso Criar Dependência

44 43 Criar Usuário: o diagrama de seqüência pode ser observado na fig. 9. : Administrador : Us uario criar() FIGURA 9 diagrama de seqüência do caso de uso Criar Usuário Responder Questionário: o diagrama de seqüência pode ser observado na fig. 10 : Respondente : Processo : Atividade : Tarefa : Opcao : Resposta Obter( ) Obter( ) Obter( ) Obter( ) Fornece( ) FIGURA 10 diagrama de seqüência do caso de uso Responder Questionário Gerar Relatório de Adequação: o diagrama de seqüência pode ser observado na fig. 11 e na fig. 12. A fig. 11 é referente ao relatório sintético e a fig. 12 é referente ao relatório detalhado.

45 44 : Respondente : Processo : Atividade : Tarefa : Resposta Obter( ) Obter( ) CalculaPercentualAdquacao( ) ObterPeso( ) Obter( ) FIGURA 11 Diagrama de seqüência do caso de uso Gerar Relatório de Adequação (Sintético) : Respondente : Processo : Atividade : Tarefa : Resposta : Opc ao Obter( ) Obter( ) CalculaPercentualAdquacao( ) ObterPeso( ) Obter( ) ObterSolucao( ) Obter( ) ObterSolucao( ) FIGURA 12 - diagrama de seqüência do caso de uso Gerar Relatório de Adequação (Detalhado)

46 Diagrama Entidade Relacionamento A base de dados do aplicativo será salva em um arquivo.mdb do Microsoft Access. Na fig 13 pode-se observar o diagrama físico do modelo. Este modelo foi criado a partir de um mapeamento objeto relacional seguindo as regras indicadas por Hugo (2002). CD_PROCESSO = CD_PROCESSO ATIVIDADE CD_ATIVIDADE LongInteger CD_PROCESSO LongInteger DS_ATIVIDADE Memo ORD_ATIVIDADE LongInteger CD_ATIVIDADE = CD_ATIVIDADE PROCESSO CD_PROCESSO LongInteger DS_PROCESSO Memo TAREFA CD_TAREFA LongInteger CD_ATIVIDADE LongInteger DS_TAREFA Memo TIPO LongInteger PESO LongInteger ORD_TAREFA LongInteger CD_TAREFA = CD_TAREFA CD_TAREFA = CD_TAREFA DEPENDE CD_OPCAO LongInteger CD_TAREFA LongInteger RESPOSTA CD_RESPOSTA LongInteger CD_OPCAO LongInteger CD_USUARIO LongInteger CD_OPCAO = CD_OPCAO OPCAO CD_OPCAO LongInteger CD_TAREFA LongInteger DS_OPCAO Memo SOLUCAO Memo ORD_OPCAO LongInteger CD_OPCAO = CD_OPCAO CD_USUARIO = CD_USUARIO USUARIO CD_USUARIO LongInteger USERNAME Text(8) PASSWORD Text(8) Text(20) NIVEL LongInteger FIGURA 13 modelo físico da base de dados 4.5 IMPLEMENTAÇÃO A seguir será descrita a implementação do aplicativo web, ferramentas utilizadas e sua operacionalidade Técnicas e Ferramentas utilizadas A modelagem do aplicativo foi feita no software Rational Rose que ofereceu suporte a todos os diagramas UML utilizados na especificação. Para a base de dados se optou por utilizar um arquivo.mdb do Microsoft Access. Com isso foi realizado um mapeamento objeto relacional seguindo as regras indicadas por Hugo

47 46 (2002) obtendo-se assim o modelo físico da base de dados. O software utilizado para detalhar o modelo físico e gerar a base de dados foi o PowerDesigner versão 6.1. O aplicativo web foi desenvolvido no ambiente Active Servers Page (ASP) com suporte a VBScript sendo utilizado o software Macromedia Dreamweaver MX versão 6.0 como ferramenta de desenvolvimento em um computador com o Microsoft Windows 2000 Professional e Internet Information Server versão 3.0 instalado. As páginas dinâmicas desenvolvidas seguem o comportamento apresentado na fig. 14. A fig. 14 indica o comportamento do aplicativo para criar um processo. O usuário faz a requisição da página de cadastrar processos para o servidor; o servidor processa esta requisição e envia o resultado para o navegador do computador do usuário; o usuário preenche as informações necessárias e ao serem enviadas o servidor processa as mesmas e as armazena na base de dados do aplicativo. Para facilitar a compreensão dos usuários utilizou-se no aplicativo web os termos perguntas, itens de resposta, tipo sim/não, tipo múltipla escolha ao invés de tarefas, opções, tipo1 e tipo2 respectivamente. Estes últimos foram utilizados na modelagem do aplicativo. <<Build>> spcriarprocesso cpcriarprocesso frmcriaprocesso ds_processo bn_criar_processo cd_processo <<Submit>> spgravarprocesso FIGURA 14 comportamento do aplicativo Além de armazenar as informações do aplicativo foram criadas consultas no Microsoft Access. Um exemplo de consulta pode ser observado no quadro 1.

48 47 No desenvolvimento do aplicativo foram utilizados os componentes TreeView e Yaromat. O componente TreeView fornece uma visão em forma de árvore dos processos, atividades, perguntas e itens de resposta cadastrados no arquivo.mdb. O resultado da consulta apresentada no quadro 1 pode ser observado na fig. 16 e este é a informação de entrada do componente TreeView que gera como saída a estrutura em forma de árvore encontrada na página alterar_excluir.asp. O componente Yaromat possui a função de realizar consistências nas informações fornecidas pelo usuário em um formulário, como por exemplo: verifica se alguma informação foi ou não fornecida em um campo obrigatório; determina se o endereço de informado é ou não válido, etc... SELECT [PROCESSO].[CD_PROCESSO], [PROCESSO].[DS_PROCESSO], [ATIVIDADE].[CD_ATIVIDADE], [ATIVIDADE].[DS_ATIVIDADE], [TAREFA].[CD_TAREFA], [TAREFA].[DS_TAREFA], [OPCAO].[CD_OPCAO], [OPCAO].[DS_OPCAO], [ATIVIDADE].[ORD_ATIVIDADE], [TAREFA].[ORD_TAREFA], [OPCAO].[ORD_OPCAO] FROM (PROCESSO LEFT JOIN (ATIVIDADE LEFT JOIN TAREFA ON [ATIVIDADE].[CD_ATIVIDADE]=[TAREFA].[CD_ATIVIDADE]) ON [PROCESSO].[CD_PROCESSO]=[ATIVIDADE].[CD_PROCESSO]) LEFT JOIN OPCAO ON [TAREFA].[CD_TAREFA]=[OPCAO].[CD_TAREFA] ORDER BY [PROCESSO].[CD_PROCESSO], [ATIVIDADE].[ORD_ATIVIDADE], [ATIVIDADE].[CD_ATIVIDADE], [TAREFA].[ORD_TAREFA], [TAREFA].[CD_TAREFA], [OPCAO].[ORD_OPCAO], [OPCAO].[CD_OPCAO]; QUADRO 1 Exemplo de consulta FIGURA 16 resultado da consulta do Quadro 1

49 OPERACIONALIDADE DA IMPLEMENTAÇÃO A operacionalidade do aplicativo web é descrita a seguir Acesso Para utilizar o aplicativo web desenvolvido é necessário estar conectado a Internet e acessar o endereço eletrônico Realizando-se este acesso a página principal do aplicativo é aberta na fig. 17 e conforme se observa contém: a) explicação da necessidade de utilizar a norma NBR ISO/IEC 12207; b) objetivos do site; c) link quero me cadastrar ; d) campo de texto Usuário, Senha e botão Entrar ; e) link Questionário, Sintético e Detalhado. FIGURA 17 Página principal de aplicativo Se ocorrer a tentativa de acessar o link Questionário, Sintético ou Detalhado sem que seja efetuado o logon no aplicativo a página principal será aberta novamente. Caso contrário ao acessar o link Questionário o usuário poderá escolher o processo que deseja

50 49 responder e através do link Sintético e Detalhado o usuário poderá obter o respectivo relatório dos processos já finalizados Cadastro e Logon de usuários O cadastro de usuários é feito através do link quero me cadastrar. Este link aciona a página de cadastro de usuários (fig. 18) onde é solicitado que seja fornecido um usuário, senha, redigitação da senha e endereço de . FIGURA 18 Página de cadastro de usuários Com os dados preenchidos deve-se clicar no botão Enviar para que o novo usuário seja cadastrado. Caso alguma informação esteja inserida de maneira incorreta o aplicativo fará o tratamento do erro e informará o que deve ser feito para corrigí-lo. Além disso, o botão Enviar faz com que a página principal do aplicativo seja reaberta e nesta pode ser informado um usuário e senha já cadastrados no campo de texto usuário e senha e assim efetuar o logon no aplicativo. Se o usuário e senha fornecidos estiverem incorretos o aplicativo avisará através da mensagem Usuário ou senha inválidos.

51 Utilização do Aplicativo A seguir será descrita a operacionalidade do aplicativo em nível de usuário e em nível de administrador Utilização do Aplicativo em nível de Usuário Se o usuário e senha fornecidos estiverem corretos o aplicativo abrirá a página de logon efetuado com sucesso onde se podem encontrar instruções referentes ao questionário, obtenção de relatórios e efetuar logout do aplicativo. A página de logon efetuado com sucesso pode ser observada na fig. 19. FIGURA 19 Logon efetuado com sucesso Respondendo o Questionário Ao clicar no link questionário é aberta a página para selecionar o processo que se deseja responder.

52 51 Ao selecionar o processo desejado o aplicativo faz a primeira pergunta sobre o mesmo (fig. 20). Após marcar os itens realizados clique no botão Responder para que o aplicativo faça a próxima pergunta. Ao responder a última pergunta o usuário será avisado que todas as perguntas já foram respondidas para o processo selecionado. FIGURA 20 Primeira pergunta do processo selecionado Relatórios Somente é possível obter a análise de adequação a Norma NBR ISO/IEC dos processos já respondidos completamente. A análise pode ser sintética ou detalhada. A análise sintética informa o percentual de adequação a Norma NBR ISO/IEC 12207, sendo esta oferecida para cada par Processo/Atividade. A análise detalhada além de fornecer os dados da análise sintética oferece recomendações para a organização ficar de acordo com a Norma NBR ISO/IEC Para obter a análise sintética deve-se clicar no link Sintético. Com isso será solicitado que seja selecionado um processo e após haver esta seleção será obtida a análise sintética das respostas fornecidas para o mesmo.

53 52 Para obter a análise detalhada deve-se clicar no link Detalhado. Com isso também será solicitado que seja selecionado um processo e após haver esta seleção será obtida a análise detalhada das respostas fornecidas para o mesmo. Se o processo selecionado não estiver respondido completamente será avisado que não é possível gerar o relatório devido à presença de perguntas sem respostas no processo em questão. Este aviso será dado pelos dois relatórios. Um exemplo de relatório sintético pode ser observado na fig. 21 e um exemplo de relatório detalhado pode ser observado na fig. 22. FIGURA 21 Relatório Sintético

54 53 FIGURA 22 Relatório Detalhado Utilização do Aplicativo em nível de Administrador Se o logon for efetuado com um usuário e senha que possuem o nível Administrador o aplicativo abrirá a página de logon efetuado com sucesso e esta conterá instruções referentes aos serviços realizados pelo administrador e acesso a Área Administrativa. A página de logon efetuado com sucesso em nível de Administrador pode ser observada na fig Criando Processos Para criar um novo processo deve-se clicar no link Processo que esta logo abaixo de Criar. Com isso a página para criar processos é aberta (fig. 24). Deve-se informar a descrição (nome) do novo processo e clicar no botão Enviar. Se o usuário clicar no botão Enviar com o campo de texto Descrição em branco o aplicativo solicitará que a descrição do processo seja fornecida.

55 54 FIGURA 23 Logon efetuado com sucesso em nível de Administrador FIGURA 24 Cadastro de Processos

56 Criando Atividades Para criar uma nova atividade deve-se clicar no link Atividade que está logo abaixo de Criar. Com isso a página para criar atividades é aberta (fig. 25). Deve-se selecionar qual o processo em que a nova atividade estará subordina, informar sua descrição e clicar no botão Enviar. FIGURA 25 Cadastro de Atividades Se o usuário clicar no botão Enviar com o campo de texto Descrição em branco o aplicativo solicitará que a descrição da atividade seja fornecida Criando Perguntas Para criar uma nova pergunta deve-se clicar no link Pergunta que está logo abaixo de Criar. Com isso a página para criar perguntas é aberta (fig. 26). Deve-se selecionar qual o processo e atividade em que a nova pergunta estará subordinada, informar sua descrição, escolher seu tipo, selecionar seu peso e clicar no botão enviar.