FANDOM



IntroduçãoEdit

O processo está sendo elaborado com o propósito de ser utilizado em práticas acadêmicas na atual e nas futuras turmas de Tecnologia em Analise e Desenvolvimento de software, e vai abranger todo o sistema da Escola Agrícola de Jundiaí (EAJ-UFRN), envolvendo os professores e alunos para o compartilhamento de conteúdos e provas relacionadas a mais variadas disciplinas.

Sendo baseada em duas metodologias de desenvolvimento de software

Artefatos chave do processoEdit

Um Artefato é um produto de trabalho do processo: os papéis usam os artefatos para executar atividades e produzem artefatos ao executarem as atividades. Os artefatos são responsabilidade de um único papel e promovem a idéia de que todas as informações no processo devem ser responsabilidade de uma pessoa específica. Embora um artefato "pertença" a uma pessoa, muitas outras podem utilizá-lo e, talvez, até atualizá-lo se tiverem permissão.

Fase de concepção:Edit

A fase de concepção contém os Workflows necessários para que as partes interessadas (stakeholders) concordem com os objetivos, arquitetura e o planejamento do projeto. Se as partes interessadas tiverem bons conhecimentos, então, pouca análise será requerida. Caso contrário, uma análise maior será requerida.

Como cita o RUP, o ideal é que sejam feitas iterações. Porém estas devem ser bem definidas quanto a sua quantidade e objetivos

Documento de visão

Modelos de casos de uso

Plano de projeto

Esboço de interface

Gerenciamento de mudanças

Fase de Elaboração:Edit

Esta fase consiste nos fluxos de processos voltados à modelagem e arquitetura do sistema. Avaliam-se os requisitos funcionais e não funcionais quanto aos recursos tecnológicos de hardware e software. Revisa e valida o modelo de negócio, detalha os casos de uso e de teste, elaborando os protótipos funcionais. Reduzindo os riscos e produzindo um cronograma.

Objetivos: Assegurar que a arquitetura, os requisitos e os planos sejam estáveis o suficiente e que os riscos sejam suficientemente diminuídos a fim de determinar com segurança a programação para a conclusão do desenvolvimento.

Atividades: Unidade de trabalho que resulta em desenvolvimento de parte do projeto. Tem proposta clara e objetiva, em geral, desenvolvimento de artefatos. Podem se repetir diversas vezes.

  • Detalhar os casos de uso;
  • Elaborar plano e casos de teste;
  • Definir a arquitetura do sistema;
  • Definir o modelo de dados;
  • Revisar o modelo de negócio.


Artefatos: São produtos de trabalho, intermediários ou finais, que servem de entrada para execução de atividades ou que são gerados como fruto de realização de atividades.

  • Documento de visão revisado;
  • Documento de detalhamento de caso de uso;
  • Documento de arquitetura de sistema revisado;
  • Plano de testes;
  • Documento de Configuração de ambiente.


Disciplinas:



Diagramas: Desenvolvimento dos principais diagramas que serão utilizados no software, incluindo toda a parte de design e interfaces envolvidas

  • Diagramas Obrigatórios:
  1. Casos de Uso;
  2. Atividade;
  3. Sequência;
  4. Máquina;
  5. Diagrama de Entidade e Relacionamento.
  • Diagramas Opcionais:
  1. Classe


Areas de conhecimento:

  • Modelagem de negócio;
  • Requisitos;
  • Análise e Projeto.

Plano de Iterações: Este artefato também ajuda a equipe para monitorar o progresso da iteração, e mantém os resultados da avaliação de iteração que pode ser útil para melhorar a próxima. Nesse processo, o plano de iterações ficou decidido da seguinte forma: Para cada fase uma iteração, mas essa iteração poderá ser repetida quantas vezes for necessária.

Papéis: Define o comportamento e responsabilidades de um indivíduo (ou conjunto de indivíduos) envolvido com o projeto. Um papel é responsável por um ou mais artefatos e executa um conjunto de atividades. Não necessariamente o seu sistema tenha que conter todos esse papeis, dependendo da necessidade que utiliza apenas alguns ou todos.

Fase de Construção:Edit

A fase de construção é a fase onde começará a parte física do software. É nessa fase que os desenvolvedores irão começar a escrever o código fonte do software, documentar todo o código, reparar os erros e fazer testes nos códigos. Cada pedaço funcional do código é passado para a fase de validação, e lá será feito outros testes para poder passar para o cliente, e assim o sistema será feito, aos poucos o sistema irá se completando com partes funcionais do software.

Objetivo: Assegurar que o desenvolvimento do sistema está correndo como planejado e está tudo estável com a criação do mesmo.Edit

Ambiente: Todo ambiente de desenvolvimento deve se open souce (código aberto) ou free (sistemas com licença gratuida). Deve-se levar em consideração também, que antes do desenvolvimento é necessário testar todas as ferramentas que serão usadas no decorrer da fase de construção.

Atividades:Edit

  • Desenvolvimento do layout do sistema;
  • Construir Banco de Dados;
  • Desenvolvimento do código fonte;
  • Testes de código fonte.

Artefatos:Edit

  • Documentos de testes iniciais;
  • Documentação do código;
  • Documento gerado nos testes unitários;
  • Documento de apresentação de beta.

Áreas de conhecimento:Edit

  • Construção de banco de dados;
  • Saber interpretar diagramas;
  • Conhecimentos em programação e SQL;
  • Conhecimentos em testes.

Papéis:Edit

  • Desenvolvedor;

Testes da fase de construção:Edit

Implementação e teste na construção:Edit

  • O Teste na fazer de construção é muito importante, pois, ele irá definir os erros lógicos e bugs encontrados. O Fluxo abaixo mosta como deve ser feito os testes nessa fase.
Fluxo de Atividades de Teste na fase de Construção

Teste unitário:Edit

  • O teste unitário é a parte onde deverão ser realizados testes nos componentes do programa, como métodos e classes de objeto, por exemplo. As funções individuais ou métodos são o tipo mais simples de componente. Os testes devem ser chamadas para essas rotinas com parâmetros de entrada diferentes. Para fazer esse tipo de teste em classes, você deve:

- Testar todas as operações associadas ao objeto;

- Definir e verificar o valor de todos os atributos associados ao objeto;

- Colocar o objeto em todos os estados possíveis, ou seja, simular todos os eventos que causam mudanças de estado. 

Teste de componente:

  • Testes de componentes compostos devem mostrar que a interface do componente se comporta de acordo com a sua especificação. Você pode assumir que os testes unitários dos objetos individuais dentro do componente já foram concluídos. Existem diferentes tipos de interface entre os componentes do programa, e também vários tipos de erros diferentes.

Interfaces:

Erros de interface:

Algumas diretrizes para os testes de interface:
  • Examinar o código a ser testado e listar cada chamada para um componente externo;
  • Se os ponteiros forem passados por uma interface, teste a interface com os parâmetros de ponteiros nulos;
  • Quando um componente é chamado por uma interface de procedimento, projete testes que causem uma falha no componente;
  • Faça testes de estresse em sistemas de passagem de mensagem, ou seja, projete testes que gerem muito mais mensagens do que seria provável ocorrer na prática;
  • Quando vários componentes interagem por meio de memória compartilhada, faça testes que variam a ordem em que esses componentes são ativados.

Fase de validação        Edit

A parte final do processo de desenvolvimento é a Validação, refere-se a parte final de “construção” do software, que somente ocorre após uma análise positiva da avaliação do uso do software pelo usuário. Esta etapa divide-se em duas partes: a integração, realizada pelo profissional da área de computação, que irá verificar se existem pequenos ajustes que tenham sido observados no teste de aceitação e alterá-los. Também é realizada nesta atividade a integração do incremento ao produto final, caso o mesmo não se refira ao primeiro incremento; elaborar documentação, é essencial para qualquer software desenvolvido uma documentação detalhada, desde o projeto à implementação. Nesta atividade é gerada uma especificação detalhada do software e é criado um manual do usuário, contendo informações referentes à utilização do software.

No fim do ciclo de vida da fase, os objetivos devem ter sido atendidos e o projeto deve estar em uma posição de fechamento. Em alguns casos, o fim do ciclo de vida atual pode coincidir com o início de outro ciclo de vida no mesmo produto, conduzindo à nova geração ou versão do produto. Ao final da fase, os seguintes objetivos devem ser atingidos:

 

  • Instalar o produto gerado;Edit

    </li>

  • Corrigir defeitos e modificar o sistema para corrigir problemas não identificados previamente.Edit

     

    Esses objetivos são cumpridos através da geração dos seguintes artefatos:

    </li>

  • Produto;Edit

    </li>

  • Documentação do produto.Edit

     

    A validação é dividida em três disciplinas:

     

      1. Requisitos

      2. Análise e Projeto

      3. Implantação e Teste

    RequisitosEdit

         A disciplina de requisitos será executada apenas se novas funcionalidades tiverem sido adicionadas ao sistema. O seu fluxo possui apenas duas atividades. Uma responsável por verificar o surgimento de novas funcionalidades e, em caso positivo, outra para chamar as atividades da mesma disciplina na fase anterior.

     

     

    Fluxo de Atividades

     

     

    Análise e ProjetoEdit

    ===    Possui as mesmas características da disciplina anterior (Requisitos), porém se alguma nova funcionalidade for adicionada ao sistema, serão realizadas as atividades da disciplina de análise e projeto da fase de elaboração.===

    Implementação e TesteEdit

             O foco principal da disciplina de Implementação e Teste é realizar os testes do produto em preparação para release, bem como ajustes pequenos com base no feedback do usuário.

    As atividades acontecem basicamente em dois momentos:

     

    Teste Unitário:

     

    São planejados e executados testes no ambiente de desenvolvimento.

     

     Teste de Aceitação:

     

    O sistema é implantado e são executados testes de usabilidade e testes no ambiente do usuário.

             Ao final, é gerado um relatório com as informações coletadas nos testes. Sendo encontrados erros, tanto no teste alfa quanto no teste de aceitação, realiza-se uma verificação para identificar se apenas uma nova implementação os corrige ou se é necessário realizar uma nova modelagem. No caso de uma remodelagem as disciplinas de requisitos e análise e projeto são executadas e, ao final, realiza-se novamente os referidos testes. São realizadas tantas iterações quantas forem necessárias, até que o uso do sistema seja aprovado pelo usuário.Edit

    Fluxo de AtividadesEdit

    ArtefatosEdit

      • ===Produto===


    Software que está sendo desenvolvido, seja em sua versão final ou parcial (Release).

     

    </li>
  • DocumentaçãoEdit

    Todos os documentos gerados durante a produção do software, incluindo um manual de funcionamento do sistema, que será incrementado a cada módulo adicionado, e um documento de integração do sistema, que deverá conter todas as informações de cada módulo que foi adicionado ao sistema.

    ===

    === </li>

  • Community content is available under CC-BY-SA unless otherwise noted.