Documento de Processo

Transcrição

1 Documento de Processo versão 1.0 Desenvolvimento do Sistema de Gestão de Documentos Doc Manager Cliente: São José Agroindustrial Representante do cliente: Paulo José de Souza

2 2 Histórico de Alterações Data Versão Descrição Autor 29/04/ Criação do documento Alexandre Gomes Índice

3 3 Histórico de Alterações Introdução Propósito Público Alvo Referências Visão geral do documento Processo de Desenvolvimento Comunicação Apresentação do projeto Definição dos requisitos Confecção do documento de requisitos Planejamento e Modelagem Definição da arquitetura Seleção da Sprint Construção Implementação Testes Integração Implantação Definição do time de suporte Ações para Publicação Processos de Qualidade Objetivos Produtos Gerados Atividades e Ações Reuniões Técnicas Formais (RTFs) Objetivos Questões a serem revisadas Recomendações Gerais Gestão da Configuração Papéis e Responsabilidades Anexo A Introdução 1.1.Propósito

4 4 Este documento irá mostras detalhadamente todos os processos, qualidade e configuração obtidos no decorrer do desenvolvimento do Doc Manager. 1.2.Público Alvo Pretende-se atingir com este documento os pertencentes a Usina São José Agroindustrial, com o intuito de melhorar sua organização e diminuição no transtorno no gerenciamento de documentos. 1.3.Referências Visão geral do documento Este documento apresenta uma descrição geral do sistema Doc Manager, de forma organizada demostra funções, configurações, desenvolvimento e etc. 2. Processo de Desenvolvimento No processo de desenvolvimento do software, a Fast Software adotou um processo organizacional que evolui em produção, rendimento e comprometimento. Acompanhamento de todo documento e modificações ocorrida no decorrer do projeto, mantendo uma base para um bom desempenho do sistema, as reuniões de equipe facilitam o desenvolvimento e processos para aplicação, nossos analistas trabalham para obter o máximo de aproveitamento possível, na criação se obtém ideias que visam a melhoria de alguma área que necessita mudar. 2.1 Comunicação Apresentação do projeto Como primeiro passo em nosso processo de desenvolvimento, fizemos uma reunião com a Equipe Fast Software tendo como membros presentes, o Product Owner (representado pelo gerente de qualidade / testes), a gerente de configuração / processos, um engenheiro de software como representante do time, e o cliente representado por um funcionário que está ligado diretamente com o sistema e sua usabilidade, assim por meio dessa reunião, buscou-se entender os problemas do cliente, bem como regras de negócios propondo dessa forma soluções para os problemas levantados/apresentados, ou seja, discutir de forma clara e objetiva tudo que o Cliente precisa e deve ser atendido para solução do problema Definição dos requisitos Em nova reunião analisando as definições coletadas junto ao representante do Cliente desenvolvemos do documento de Caso de Uso onde já foi possível definir alguns requisitos,

5 5 sabendo que em outro momento será elaborado o documento de requisitos solicitado pelo Cliente Confecção do documento de requisitos No primeiro contado com a problemática do cliente através de seu representante foi possível captar através de gravação de tela e áudio processos onde o mesmo nos informa os pontos relevantes que irão auxiliar gerente de projeto e o engenheiro de software para desenvolver os requisitos Planejamento e Modelagem Definição da arquitetura Com o término do processo de validação e priorização das estórias de usuário, passa a ser trabalhado pelo engenheiro de configurações, qual será a arquitetura de software utilizada para o projeto de acordo com a dimensão/escalabilidade do mesmo, gerando assim o documento de configuração, contendo todos os detalhes da arquitetura do sistema a ser utilizada, assim como os padrões de projetos utilizados e componentes reúsados. Contudo serão apresentados no documento de configuração alguns diagramas básicos para demonstrar como os componentes do sistema estão organizados e como acontecerá a comunicação/relacionamento dos mesmos Seleção da Sprint Depois de confeccionado o documento de arquitetura, haverá reunião com gerente de projeto e equipe para atribuição de grau de dificuldade às funcionalidades do backlog do produto (Planning Poker) e seleção da sprint onde, de acordo com a classificação do cliente e da equipe sobre as funcionalidades, serão selecionadas aquelas que serão desenvolvidas na Sprint, dando origem ao Sprint backlog (documento simples que contém somente as funcionalidades para cada sprint. É atualizado ao início de cada Sprint) Construção Após a seleção da sprint o ciclo se inicia e as tarefas passam a ser desenvolvidas Implementação Costuma-se armazenar as informações do Sprint Backlog em tabelas ou planilhas, contendo nas colunas a A fazer, fazendo, feito, testado, não planejado e problemas. É fundamental o envolvimento e comprometimento constante do time na seleção dos itens e dimensionamento do Sprint Backlog, já que são eles que desenvolverão e completarão as tarefas definidas, identificando assim os impedimentos e estimativas de

6 6 prazos. Devido aos esforços dentro da faixa de tempo do Sprint, o Scrum Master é responsável por manter os Sprints Backlogs atualizados, sendo assim ele e todos os integrantes informados sobre as atualizações realizadas, pelo menos uma vez por dia, prioritariamente nas Reuniões de Planejamento assim acompanhando as atividades completas e estimando o prazo das pendentes, será sempre responsabilidade da equipe determinar o quanto ela será capaz de se comprometer a fazer. Aconselha-se que nem todos os itens do Sprint Backlog estejam diretamente relacionados às metas e que não sejam feitas Sprints muito longas. Isso porque, caso não seja possível concluir um deles, a meta estará comprometida e, assim, a Sprint não terá sucesso Testes Os testes necessários para cada estória de usuário serão descritos nas mesmas, de forma resumida e com bastante clareza, porém esses casos de testes serão descritos com mais detalhes no desenvolvimento do plano de teste Integração Durante as sprints, o time de desenvolvimento fará seus testes individuais para cada tarefa construída, com o intuito de identificar de maneira precoce algumas falhas e bugs aplicando correções de forma imediata, diminuindo as correções a serem realizadas nos resultados de falha na fase rígida de teste. No entanto, a cada sprint, é iniciado um período de teste de no máximo 4 dias, para assegurar a qualidade da implementação finalizada, dependendo dos erros levantados, um ou mais de um membro fará a correção dos erros encontrados. Com os testes finalizados e as correções aplicadas cada parte do sistema é apresentada ao stakeholder do cliente como parte de um produto final, onde essa parte executável do produto é exposta para o stakeholder ao final de cada sprint Implantação Definição do time de suporte Toda a equipe estará disponível para prestação do serviço de suporte, com ênfase nos integrantes mas hábitos para tal atividade.

7 Ações para Publicação Todas as nossas aplicações desenvolvidas assim como o Doc Manager será publicado no site da Fast Software Processos de Qualidade Para os critérios de qualidade todas as funcionalidades devem estar em conformidade com relação as estórias de usuários, ter todos os artefatos gerados com total clareza e de fácil compreensão do que foi estabelecido para todo o processo de construção do projeto, assim como a alta performance do sistema como sendo uma das grandes metas de qualidade para a equipe Fast Software. Contudo, temos o nosso plano de qualidade estabelecido pelo gerente de qualidade, aplicando ações para garantir a qualidade do produto de forma padronizada obtendo por meio dos resultados alcançados, melhorias para o nosso processo de desenvolvimento de software. 3.1.Objetivos Tem-se como objetivo, desenvolver um plano de qualidade a fim de garantir melhores serviços e produtos prestados pela FAST SOFTWARE. 3.2.Produtos Gerados Os produtos gerados para apoio a qualidade tem relatórios que servirão como uma forma de revisar e identificar o que tivemos de melhoria e o que podemos melhorar diante dos problemas levantados. 3.3.Atividades e Ações Como atividade para gerência de qualidade tem: Detalhar de forma participativa toda construção do software da empresa, verificando se o software satisfaz os critérios de qualidade e os padrões de negocio da empresa. Ter um acompanhamento contínuo do processo, identificando falhas e pontos de melhorias do software, gerar documentos e relatórios técnicos para que fique mais detalhado seu acompanhamento. A cada produto finalizado, fazer uma avaliação de qualidade com os critérios estabelecidos no plano de qualidade. Garantir que o processo de software e padrões está sendo seguidos por toda a equipe do projeto.

8 8 A cada não satisfação do cliente será gerado um relatório para melhoria do software e melhor satisfação do cliente. 3.4.Reuniões Técnicas Formais (RTFs) Para as reuniões técnicas, serão levantada tudo que for relacionado a questões de qualidade para melhoria de nosso processo e produto, também serão discutidas as questões de qualidade Objetivos Verificar erros e falhas no software e corrigi-lo o mais rápido possível prevenido de erros futuros que possa acontecer. Atender todos os requisitos necessários do cliente, se esta nos conforme que foi esperado. Torna que o projeto seja de fácil compreensão de todos os envolvidos. Decidir sobre a melhor forma de ter um controle adequado de qualidade mantendo um forte gerenciamento dos processos. Discutir e aplicar melhorias com base nos resultados gerados pelo controle de qualidade Questões a serem revisadas O produto está satisfazendo o cliente? As funcionalidades estão de acordo com as exigências do cliente? O desenvolvimento do projeto está dentro da arquitetura e padrões estabelecidos no projeto? O processo de comunicação entre os envolvidos no projeto é praticado de maneira eficiente? Os processos estão sendo executados, conforme estabelecido no início e no fim de cada etapa do projeto? Ocorreu algum risco previsto no projeto? O Plano de Contingência solucionou? Ocorreu algum risco imprevisto no projeto? Qual Plano foi aplicado? Onde ocorreram falhas? Como a equipe pode melhorar seus resultados? Ao término das reuniões técnicas, serão produzidos os relatórios das revisões técnicas, bem como identificar os participantes, ou seja, quem fez e por fim extrair de maneira significativa o que foi abordado no encontro Recomendações Gerais Evitar atrasos na reunião de Sprints, cabendo ao revisor de qualidade se precaver com os relatórios necessários para realização das reuniões técnicas;

9 9 Um dia após o término da Sprint, iniciar a reunião com o objetivo de não atrasar as outras reuniões; Cada reunião não pode ultrapassar mais que uma hora; O Gerente de Qualidade deve registrar todos os questionamentos abordados; O Gerente de Qualidade deve ficar atento às pendências identificadas na reunião; Tudo aquilo que for revisado, de acordo com o resultado e discussões levantadas sobre o mesmo, deve ser aprovado ou não pela equipe envolvida; Todos os resultados levantados devem ser passados para o gerente de projetos Gestão da Configuração No documento de Configuração constará tudo o que for pertinente à gerência de configuração e resumidamente no documento de Plano de Projeto Papéis e Responsabilidades Os integrantes da fábrica são responsáveis pela garantia de qualidade dos produtos e serviços, por meio dos processos definidos. Os papéis específicos de qualidade são: Gerente de qualidade tem maior responsabilidade em fazer as reuniões técnicas e controle de qualidade; Revisor e redator dos produtos e anotações levantadas nas inspeções. 4. Anexo A Solicitação de modificação pelo Cliente Nome do Cliente: Nome do Projeto: Data da Solicitação do Cliente: Data da entrega: Quem Codificou a Mudança: Descrição do Problema:

10 10