FASES  DA METODOLOGIA – VISÃO

O produto final da fase de visão são documentos e diagramas que consigam ilustrar o escopo do projeto. Através das reuniões de oficina de requisitos, entendemos e documentamos exatamente o que o cliente espera do projeto.
Com os documentos homologados pelo cliente, e o comum acordo que todos temos a mesma visão do escopo do projeto, é possível dimensionar e modularizar o projeto, definir as metas fechando um planejamento para o projeto. A fase de visão é documentada nos seguintes artefatos:

Definição dos papéis

 No inicio do projeto, realizamos uma reunião de integração das pessoas que participarão do projeto, onde documentamos os papeis e responsabilidades de cada pessoa dentro do projeto. Os papéis definidos seguem a estrutura de Team Model da metodologia MSF (Microsoft Solutions Framework);

Levantamento Técnico Inicial (LTI)

O documento é desenvolvido através de reuniões e entrevistas com o cliente e usuários do sistema. O principal objetivo é detalhar os problemas e cenários de negócio do cliente e documentá-los, O LTI é composto dos seguintes documentos: Diagrama Macro Funcional e Modelo de Negócios do sistema, o resultado das entrevistas e reuniões e a conclusão tecnológica que melhor atende o cliente.

Diagrama Macro Funcional

Tem como principal objetivo representar graficamente o escopo macro do sistema, identificando suas macro funções e os atores (pessoas ou outros sistemas) que interagem com o sistema;

Modelo de Negócios

O modelo de negócios é uma visão mais detalhada das macro funções, ilustrando as funcionalidades envolvidas em uma macro função bem como sua hierarquia dentro do sistema. Para que o documento possa ser desenvolvido, é imprescindível que tenhamos o comprometimento do cliente, pois seu conhecimento de negócio, permite que a visão das funcionalidades necessárias fique clara e objetiva.

Diretrizes de Arquitetura

Este documento é destinado ao levantamento e documentação de todos os padrões técnicos que devam ser seguidos para o sistema, como por exemplo: Padrões de Interface, padrões de nomenclatura de banco de dados, padrões de infra-estrutura, regras de segurança, integrações, e toda característica técnica mantida como requisito não funcional do sistema;

Métricas do sistema

 Para dimensionar o sistema, utilizamos as técnicas da Análise de Ponto de Função, com base na nossa realização histórica em no desenvolvimento de software.

 FASES DA METODOLOGIA - ESPECIFICAÇÃO

Conhecendo o escopo do projeto, podemos detalhar todo o sistema iniciando  sua especificação, nesse momento utilizamos as técnicas da UML para documentarmos os comportamentos, estruturas e a arquitetura do sistema.

Glossário do Sistema

O objetivo é listar os termos específicos do negócio para que todas as pessoas envolvidas no projeto tenham um mesmo entendimento sobre o conteúdo. Geralmente o documento é elaborado e mantido pelo cliente.

Protótipo de Navegação

Trata-se da primeira versão do sistema e tem como objetivo auditar tanto os padrões de interface definidos como a hierarquia das funcionalidades descrita no modelo de negócio, bem como a navegação pelas telas do sistema. O documento é elaborado a partir dos esboços de telas fornecidos pelo cliente ou documentados nas oficinas de requisitos, as inconsistências encontradas são reportadas e introduzidas no protótipo.

Diagrama de Casos de Uso

Tem como objetivo identificar as dependências entre os casos de uso (funcionalidades do sistema) e a partir desse ponto definir a ordem de construção para os módulos que farão parte do sistema planejando assim o desenvolvimento dos mesmos.

Especificação de Casos de Uso

Cada Caso de Uso (funcionalidade do sistema), que foi apresentado no Diagrama será agora detalhado quanto as suas dependências funcionais e de negócio. É importante que qualquer programador ou analista entenda os fluxos do sistema apresentados nessas descrições, por isso utilizamos os padrões UML para documentação dos casos de uso.

 4Descrição do Objetivo: Breve descrição do objetivo do caso de uso;

4Pré-Condições: Eventos que são pré-requisitos para o acontecimento do caso de uso;

4 Pós-Condições: Descrição dos estados do sistema gerados pelo caso de uso;

4 Regras de Negócio Associadas: Regras de negócio que serão aplicadas naquela funcionalidade.

4Regras Técnicas: Regras associadas aos componentes visuais da funcionalidade.

4Tabela de Mensagens: Conjunto de mensagens que serão utilizadas no caso de uso;

4Protótipo de Tela: Demonstração visual da tela correspondente ao caso de uso;

4Detalhamento dos Fluxos: Documentação do fluxo principal e dos alternativos do caso de uso. Em funcionalidades complexas utilizamos os Diagramas de Seqüência para documentar os fluxos.

Modelo de Entidades e Relacionamentos – MER

O objetivo é descrever o modelo físico do banco de dados, identificando as entidades (tabelas) e seus atributos (campos), otimizando a estrutura de dados e criando o banco de dados.

Oficinas de Requisitos

As oficinas de requisitos são as reuniões onde são levantados os detalhes para a completa especificação do sistema.

FASES DA METODOLOGIA – DESENVOLVIMENTO

Na fase de desenvolvimento, toda a especificação do sistema é submetida ao time de desenvolvedores que irão construir o sistema. Buscando sempre a excelência na qualidade dos nossos projetos, o desenvolvimento de software é todo padronizado dentro na ArchITettura seguindo um documento interno de boas práticas de codificação e para garantia dos padrões, submetemos o código fonte a periódicas auditorias a qual denominamos Code Review.

 Code Review

O principal objetivo é garantir a utilização dos Patterns de desenvolvimento e certificar que o código utilizado é o melhor para a aplicação. Quando o padrão é seguido conseguimos atingir os índices de qualidade de código que futuramente facilitarão as manutenções do sistema.

FASES DA METODOLOGIA - ESTABILIZAÇÃO

É a fase em que são feitas entregas (parciais) do projeto ao cliente. Essas entregas são chamadas de:

 4RC1 (Release Candidate One): É quando o cliente tem o primeiro contato com um ou mais módulos prontos do sistema. O cliente deverá testar todas as funcionalidades do módulo entregue, e apontar o que é erro ou que seriam melhorias a serem feitas no sistema.

4RC2 (Release Candidate Two): É a segunda entrega de um ou mais módulos do sistema. Esta entrega estará próxima do produto final, e assim como na primeira o cliente deverá testar as funcionalidades e apontar novos  erros caso seja necessário.

4RTM (Release To Manufatcture): O RTM é entrega final do projeto, após a aprovação do cliente é efetivada a conclusão do processo de desenvolvimento do sistema. São entregues ao cliente todos os documentos gerados durante o projeto e também os códigos fontes, e então inicia-se o ciclo de garantia.  

O pacote formado por cada uma dessas entregas antes de ser entregue ao cliente, passa primeiramente pela a área de SQA (Software Quallity Assurance) para uma bateria de testes, as inconsistências encontradas voltam para o time de desenvolvimento e a versão só é liberada ao cliente quando não forem mais encontrados erros de sistema.

Planilha de Inconsistências (Testes de Liberação)

Neste documento são descritas todas as inconsistências encontradas no sistema, e a planilha é enviada aos desenvolvedores para que eles corrijam os problemas. O SQA verifica se todas elas foram corrigidas e então libera para avaliação do cliente. Caso não seja aprovada ficará nesse ciclo até que não hajam mais erros no sistema.

Recibos de Release (RC1 – RC2 – RTM)

O principal objetivo é documentar a entrega dos módulos do sistema. Este documento é elaborado e em seguida protocolado pelo cliente.

 FASES DA METODOLOGIA -  IMPLANTAÇÃO

É a fase em que é implantado o sistema no ambiente do cliente. Nesta fase será fornecido o seguinte documento:

Manual de Implantação do Projeto

Neste manual estarão documentados todos os pré-requisitos para a instalação do sistema, o processo de instalação e as configurações necessárias para o sistema(conexão no banco de dados, configurações de segurança, entre outros).

FASES DA METODOLOGIA - CONTROLE

A fase de controle está presente em todas as fases do projeto. Os documentos gerados são:

Cronograma

Com base no planejamento criado, será gerado o cronograma detalhado do projeto, para que todas as pessoas envolvidas possam se programar e concluir suas atividades no prazo estipulado;

Task Plan

Gerenciamento e acompanhamento semanal de cada membro do projeto. Devemos definir as atividades dos membros da equipe para a próxima semana e verificar se as atividades da semana anterior foram realizadas.