Home

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

• Extreme programming
• Rational Unified Process

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:

• Disciplina de Requisitos;
• Disciplina de Análise e Projeto;
• Disciplina de Testes.

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.

• Analista de Requisitos;
• Analista de Design;
• Analista de Testes ou Testador;
• Desenvolvedor;
• Projetista de Banco de Dados;
• Orientador Específico;
• Gerente de Projeto.

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:

• Interface de parâmetro;
• Interfaces de memória compartilhada;
• Interfaces de procedimento;
• Interface de passagem de mensagem.

Erros de interface:

• Mau uso de interface;

• Mau-entendimento da interface;
• Erros de timing.

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: