AADSP Guia de implementação Geral: Fundamentação para implantação da abordagem adaptativa para implantação de processo de software.

Transcrição

1 # IMPLANTAÇÃO AADSP Guia de implementação Geral: Fundamentação para implantação da abordagem adaptativa para implantação de processo de software. Este documento tem por objetivo orientar pesquisadores, empresas e profissionais do âmbito do desenvolvimento de software no processo de implantação da abordagem AADSP. Copyright 2016 IFBA / Labrasoft Direitos desta edição reservados ao Instituto Federal de Educação Ciência e Tecnologia da Bahia IFBA.

2 IFBA / Labrasoft AADSP Guia de implementação Geral: Fundamentação para implantação da abordagem adaptativa para implantação de processo de software. AUTORES: Antonio Carlos dos Santos Souza Labrasoft / IFBA Antônio Maurício da Silva Pitangueira Labrasoft / IFBA Felipe Pereira Coelho Labrasoft / IFBA Luiz Cláudio Machado dos Santos Labrasoft / IFBA Márcio Cerqueira de Farias Macedo Labrasoft / IFBA Romilson Lopes Sampaio Labrasoft / IFBA Ronaldo Pedreira Silva Labrasoft / IFBA Simone da Silva Amorim Labrasoft / IFBA SALVADOR BA 2016

3 SUMÁRIO 1. Introdução Objetivos... 5 Geral... 5 Específicos Valoração dos Artefatos... 5 Essencial... 5 Importante... 5 Desejável Iniciando a implementação Gerências e Artefatos... 6 Gerência de projetos... 6 Gerência de requisitos e modelagem... 6 Gerência configuração e mudanças... 6 Gerência de colaboradores... 7 Gerência de testes... 7 Gerência de reutilização Objetivos das gerências... 7 Objetivo geral... 7 Objetivos específicos... 7 Gerência de projetos... 7 Gerência de requisitos... 7 Gerência configuração e mudanças... 8 Gerência de colaboradores... 8 Gerência de testes... 8 Gerência de reutilização Composição dos artefatos... 8 Gerência de projetos... 8 Termo de abertura do projeto de software TAP... 8 Estrutura analítica do projeto de software EAP... 8 Documento de estimativa de escopo DEP... 8 Definição das funções da equipe executora do projeto - EEP... 9 Cronograma de execução do projeto de software CEPS... 9

4 Orçamento do projeto OP... 9 Recursos especiais RE... 9 Plano organizacional de dados ou plano de gerenciamento de dados... 9 Plano de riscos do projeto... 9 Gerência de requisitos e modelagem... 9 Documento de requisitos do software... 9 Projeto de tela do software Diagrama de entidade e relacionamento - DER Relação dos diagramas UML do projeto Gerência de configuração e mudanças Documento de solicitação de mudança Documento de evolução do projeto Gerência de colaboradores Plano de treinamento dos colaboradores Plano de avaliação dos colaboradores Matriz de responsabilidade do projeto de software Gerência de testes Plano de execução de testes do projeto Lista de ocorrência de erros Termo de formação da equipe de qualidade Glossário de erros do projeto Gerência de reutilização Repositório de reutilizáveis dos projetos de software Diagramas e documentação dos frameworks utilizados no projeto de software Avaliação da abordagem Referências bibliográficas... 11

5 5 1. Introdução O LABRASOFT, Grupo de Pesquisa Laboratório de Desenvolvimento de Software, propõe uma abordagem adaptativa para implantação de processo de software em micro e pequenas empresas - MPEs soteropolitanas. A abordagem denominada de Adaptive Approach for Deployment of Software Process (AADSP) tem como alicerce práticas inovadoras em conformidade com o modelo MPS-BR, desenvolvido no Brasil pela Softex (SOFTEX, 2012), algumas práticas contidas em metodologias ágeis e do guia de conhecimento PMBOK da PMI (Project Management Institute) para gerenciamento de projetos. 2. Objetivos Geral Abordagem AADSP objetiva a promoção da qualidade de software por meio da utilização de técnicas especificas e resultados esperados (artefatos documentais) durante o processo de desenvolvimento de software. Específicos Promover maior qualidade nos softwares produzidos pelas MPEs; Promover a existência artefatos documentais em projetos de software; Promover práticas inovadoras para as MPEs no âmbito da engenharia de software; Promover qualidade de software por meio de artefatos documentais e resultados esperados. Promover adaptabilidade ao artefatos que compõe o projeto de software; 3. Valoração dos Artefatos AADSP qualifica os artefatos documentais de acordo com seu grau de importância, desse modo esta abordagem busca implementar estes artefatos de forma adaptativa nas MPEs. Os três graus de importância são: Essencial o Artefatos base para implementação do modelo AADSP, de modo que sua continuidade deverá ser garantida no processo de implantação desta abordagem. Importante o Artefatos que são consideráveis, todavia não são obrigatórios, assim sua implementação resultará em resultados adicionais ao modelo. Desejável o Artefatos pouco consideráveis, estes não implicam necessariamente na melhoria do processo ou em resultados satisfatórios.

6 6 4. Iniciando a implementação O AADSP trabalha o software como um produto, e deste modo, devendo ser avaliado no decorrer do seu desenvolvimento. Assim, esta abordagem elenca alguns artefatos documentais que promoverão indiretamente resultados a partir de sua confecção estes que são segmentados em diversas gerências. 5. Gerências e Artefatos Gerência de projetos Termo de abertura do projeto de software TAP (essencial) Estrutura analítica do projeto de software EAP (essencial) Documento de estimativa de escopo (essencial) Definição das funções da equipe executora do projeto (essencial) Cronograma de execução do projeto de software (essencial) Orçamento do projeto (essencial) Recursos especiais (desejável) Plano organizacional de dados ou Plano de gerenciamento de dados (importante) Plano de riscos do projeto (desejável) Gerência de requisitos e modelagem Documento de requisitos do software (essencial) Controle do comprometimento da equipe com os requisitos (importante) Projeto de tela do software (importante) Diagrama de entidade e relacionamento (essencial) Rastreabilidade dos requisitos (essencial) Documentação do código contendo a identificação dos requisitos (desejável) Plano de testes relacionado a identificação dos requisitos (importante) Relação de diagrama UML do projeto Caso de uso (essencial) Classe (essencial) Sequência (importante) Estado (importante) Atividade (desejável) Implantação (essencial) Gerência configuração e mudanças Controle das revisões dos artefatos em ocorrência de mudança de requisitos do projeto (essencial) Controle de versionamento dos artefatos do projeto (essencial) Documento de solicitação de mudança (essencial)

7 7 Documento de evolução do projeto (desejável) Gerência de colaboradores Plano de treinamento dos colaboradores (essencial) Plano de avaliação dos colaboradores (essencial) Lista de competência dos colaboradores (importante) Matriz de responsabilidade do projeto de software (essencial) Registro dos stakeholder (essencial) Controle da equipe execução (essencial) Gerência de testes Plano de execução de testes do projeto (essencial) Lista de ocorrência de erros e não conformidades (importante) Lista de ações corretivas (importante) Controle de inspeção e qualidade (essencial) Termo de formação da Equipe de qualidade (desejável) Documento de homologação do teste de software (importante) Glossário de erros do projeto (importante) Gerência de reutilização Repositório de reutilizáveis dos projetos de software (essencial) Diagramas e documentação dos frameworks utilizados no projeto de software (essencial) 6. Objetivos das gerências Objetivo geral Realizar o controle da elaboração dos artefatos documentais e sua continuidade no projeto de software, permitindo maior transparência e existência de bases históricas nas MPEs. Objetivos específicos Gerência de projetos O principal propósito da gerência de projetos é estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto Gerência de requisitos O propósito do processo Gerência de requisitos é de levantar, analisar e desenvolver os requisitos de um software, definindo suas atividades, dependências com os demais requisitos de um projeto.

8 8 Gerência configuração e mudanças Durante o projeto, os requisitos podem mudar por uma série de motivos. Desta forma, requisitos adicionais podem ser incorporados no projeto, requisitos podem ser retirados do projeto e/ou mudanças podem ser feitas nos requisitos já existentes. Ressalta-se que, devido às mudanças, os requisitos podem ter que ser revistos. Gerência de colaboradores O gerenciamento dos recursos humanos do projeto inclui os processos que organizam, gerenciam e guiam a equipe do projeto. A equipe do projeto consiste em pessoas com papéis e responsabilidades designadas para completar o projeto. Os membros da equipe do projeto podem ter vários conjuntos de habilidades, atuar em regime de tempo integral ou parcial e podem ser acrescentados ou removidos da equipe à medida que projeto progride. Gerência de testes O propósito do processo Gerência de Testes é de elaborar planos e estratégias para execução e testes em seus mais diversos modelos, objetivando maior qualidade e integridade dos dados apresentados nos produtos finais. Gerência de reutilização O propósito do processo Gerência de reutilização é de prover maior usabilidade de artefatos produzidos pelos projetos través do mapeamento e documentação de componentes e outros ativos reutilizáveis de um software. 7. Composição dos artefatos Gerência de projetos Termo de abertura do projeto de software TAP Este é documento inicial considerado para AADSP que será emitido formalmente entre o Patrocinador e executor do projeto. Estrutura analítica do projeto de software EAP A EAP será definida em três tipos: pacote, Fase e Entregas. Dentro destas representações é realizado o detalhamento do pacote, fases ou entrega a ser trabalhado. Documento de estimativa de escopo DEP É realizada a estimava de escopo através da análise da complexidade envolvendo tabelas internas/externas ao sistema, classes, objetos, relatórios, telas, consultas a banco de dados, cálculos, transações e atores dos casos de uso, linhas de código etc.

9 9 Definição das funções da equipe executora do projeto - EEP As funções podem ser designadas para pessoas ou grupos, os quais podem ser internos ou externos à organização. Em relação a competências (conhecimento, habilidades, atitudes e experiências) para que as tarefas previstas possam ser executadas de forma adequada e de acordo com a responsabilidade esperada. Cronograma de execução do projeto de software CEPS Neste artefato estará incluso as fases do ciclo de vida e o tempo e esforço em escala de: alta, média e baixa. Para execução de cada tarefa. Orçamento do projeto OP Todos os custos do projeto contendo: salario, materiais (consumo e permanente), viagens e treinamentos. Recursos especiais RE Todo os custos que não fazem parte do orçamento principal do projeto de software. Plano organizacional de dados ou plano de gerenciamento de dados A identificação, coleta, armazenamento, distribuição (incluindo regras de segurança e confidencialidade) para garantir a integridade, acesso e segurança aos dados devem ser planejados. É importante identificar os dados relevantes do projeto, para depois coletá-los, armazená-los e distribuí-los de forma controlada, lembrando que isso implica em custo. Desta forma, os dados devem ser coletados somente quando forem necessários. Plano de riscos do projeto É artefato que lista os riscos que são mais comuns e potenciais, verificando a probabilidade de ocorrência (Baixo, Médio e Alto), categoria (Técnico, Gerencial, organizacional ou externo) e impactos (Baixo, Médio e Alto) e a prioridade de tratamento de cada ocorrência (1 a 5). Gerência de requisitos e modelagem Documento de requisitos do software Este é o documento onde será armazenado todos os requisitos que compõe o software. Os requisitos devem estar apresentados em: nome do requisito, grau de importância, ator a qual está relacionado e quando necessário definir suas dependências.

10 10 Projeto de tela do software O projeto tela consiste em um modelo visual onde se apresenta os requisitos do software de forma gráfica, este modelo deverá ser aprovado pelos stakeholders durante o processo de desenvolvimento do software. Diagrama de entidade e relacionamento - DER Este é o diagrama onde serão apresentadas as relações entre as entidades que serão fisicamente implantadas no banco de dados. Relação dos diagramas UML do projeto São requeridos os seguintes diagramas: Caso de uso (essencial), Classe (essencial), Sequência (importante), Estado (importante), Atividade (desejável), Implantação (essencial). Gerência de configuração e mudanças Documento de solicitação de mudança Este artefato visa o controle de mudanças ocorridas no projeto durante o processo de desenvolvimento ou produtos já finalizados. Documento de evolução do projeto Este é um artefato onde deverá ser representada a evolução projeto, e deste modo, demonstrando as etapas já executadas no projeto de software. Gerência de colaboradores Plano de treinamento dos colaboradores Este plano deverá conter modelos de treinamento realizados ou a realizar, manuais utilizados pela empresa, processos de treinamento e outras atividades inerentes ao treinamento dos colaboradores. Plano de avaliação dos colaboradores O plano de avaliação dos colaboradores é artefato que irá conter analises de competências esperadas e resultados obtidos dentro processo de desenvolvimento de software. Matriz de responsabilidade do projeto de software A matriz de responsabilidade poderá seguir o modelo RACI. Esta matriz é um instrumento que tem como principal objetivo a atribuição de funções e responsabilidades dentro de um processo ou de um projeto. Gerência de testes Plano de execução de testes do projeto Um é um mapa que deverá conter os objetivos ou resultados esperados de um determinado artefato do projeto de software.

11 11 Lista de ocorrência de erros Devem ser confeccionadas listas contendo as ocorrências de erros durante o processo de desenvolvimento do software. Termo de formação da equipe de qualidade Durante o processo de desenvolvimento do software deve ser definida a equipe responsável pela qualidade do produto que está sendo desenvolvido o AADSP não restringe que os membros da equipe façam parte da própria equipe de desenvolvimento do produto, ressalta-se que, as decisões tomadas devem ser pela equipe evitando inconsistências aos resultados esperados. Glossário de erros do projeto O glossário de erros do projeto é o artefato que deverá conter os erros ocorridos no projeto e as soluções utilizadas para resolve-los evitando deste modo redundâncias de resoluções de erros econtrados. Gerência de reutilização Repositório de reutilizáveis dos projetos de software Este é um repositório onde deverá conter todo os ativos reutilizáveis do projeto de software. Estes ativos devem ser agrupados por características comuns mediante suas funcionalidades. Diagramas e documentação dos frameworks utilizados no projeto de software O AADSP requer o armazenamento das informações dos frameworks utilizados e diagramas do projeto. 8. Avaliação da abordagem O AADSP diferente de outras abordagens não realiza entrevistas com os participantes dos projetos em uma avaliação. Assim a abordagem AADSP audita os artefatos documentais produzidos considerando que mediante a existência destes artefatos existam processos internos que resultaram em sua confecção. 9. Referências bibliográficas Ágil, M. (2011). Manifesto para o desenvolvimento ágil de software. Disponível em: com. br/. Acessado em, 17/08/2016. Implementação, G.MPS.BR: Guia de implementação Parte Disponível em: pdf. Acessado em, 21/09/2016. Projetos, Gerenciamento de. Guia PMBOK, 5ª Edição. Project Management.

12 12 Responsabilidade, M. Matriz de responsabilidades em projetos: tudo o que você precisa saber. Disponível em: Acessado em, 21/09/2016. SABBAGH, Rafael. Scrum: Gestão ágil para projetos de sucesso. Editora Casa do Código, Scrum, Framework. Desenvolvimento Ágil de software com utilizando o framework Scrum. Disponível em: Acessado em, 20/09/2016. Teste, S. Plano de teste: um mapa essencial para teste de software. Disponível em: Acessado em, 16/08/2016.