docSoftwares

Fundamentos de Engenharia de Software
Prof. André Pichê
Alunos:
2007201305 - Bruno Alexandre
2007201122 - João Antônio
07/11/2007 - Trabalho sobre Documentação de Projeto
Documentação de Projeto
1. Metodologia Científica
1.1. Levantamento
Para levantar informação sobre usuários e tarefas, deve-se aplicar as técnicas de
levantamento a pelo menos 3 usuários representativos envolvidos com o problema
escolhido (pelo menos 1 de cada classe de usuários, se for o caso). Se for possível,
deve-se observá-los lidando com o problema em seu ambiente de trabalho real.
1.2. Problema
Especificação breve do problema. É uma sentença em forma interrogativa ou uma
questão sobre a relação de duas ou mais variáveis ou sobre fenômenos a serem
pesquisados.
 Questão não resolvida;
 Algo para o qual se vai buscar resposta;
 Deve ser formulado sob a forma de pergunta.
Sua formulação deve ser clara, compreensível e operacional
 Pergunta deve ser redigida de forma clara e concisa;
 É preciso muita atenção e precisão na sua formulação;
 Solução deve ser possível.
O conceito de problema de pesquisa pode ser entendido como uma questão que
desperta interesse e curiosidade cujas informações parecem não ser suficientes para
a solução.
1.2.1. Análise do Problema
Determina as tarefas do problema, análise de suas características e respostas para
as principais perguntas sobre tarefas que podem impactar na concepção do
software que se está projetando. Deve-se pensar em todas as perguntas que
sejam relevantes ao domínio da aplicação. Deve-se quebrar uma única tarefa em
outras mais específicas, podendo-se considerar tarefas emergenciais ou
excepcionais. Caso não seja possível, é provável que o problema seja pequeno
demais para a concepção de um projeto. Ao escrever as análises, não deve-se
fornecer descrições das tarefas, mas sim as suas conclusões, justificando-as com
base nos dados observados, quando for possível.
1.2.2. Análise do Usuário
Identifica as características dos usuários. Caso hajam várias classes de usuários,
deve-se identificar cada uma delas. Os usuários devem ser identificados pela sua
função e não pelo seu nome, salvo sob sua permissão.
1.3. Objetivos
1.3.1. Objetivo Geral (Indicação estratégica)
Orienta na construção da resposta ao problema.
 Constituem-se em declarações claras e explicitas do “para quê se deseja
estudar o fenômeno ou assunto”, ou seja, o que se pretende alcançar com
a realização da pesquisa.
 Assim os objetivos devem ser iniciados com verbos que exprimam ação,
ou seja, verificar, analisar, descobrir e determinar, entre outros.
1.3.2. Objetivos Específicos (Tática)
Operacionalizam o modo como se pretende atingir um objetivo geral. Cada
objetivo específico precisa ter pelo menos uma técnica de elicitação
correspondente que permita atingi-lo.
1.4. Metodologia
A opção pelo método de pesquisa, quantitativo e/ou qualitativo, orienta-se pela
formulação do problema de pesquisa, objetivos e hipóteses. Qualquer que seja a
escolha, esta deve estar claramente definida e justificada no tópico referente à
metodologia.
1.5. Técnicas (Operacional)
Descrição, de forma objetiva e completa, a maneira pela qual cada uma das técnicas
será utilizada. Deve-se observar o conjunto mais adequado de técnicas na literatura
sobre elicitação de requisitos de interface.
1.6. Restrições
Tanto é necessário, como prudente, avaliar-se a viabilidade de um projeto o mais
cedo possível. Teoricamente, todos os projetos são viáveis, desde que tenham
recursos ilimitados e tempo infinito.
1.6.1. Cronograma
Cada tarefa deve ter um objetivo, precondições, sub-tarefas (se for o caso), e
exceções (o que pode dar errado). Devem ser citadas outras características da
tarefa, tais quais restrições de tempo ou freqüência de uso.
1.6.2. Análise Econômica
Análise do custo-benefício do projeto. Confronta o custo de desenvolvimento do
projeto (tamanho relativo do projeto) com a renda e os benefícios derivados do
sistema desenvolvido (retorno esperado de investimentos).
1.6.3. Viabilidade técnica
Um estudo da função, do desempenho e das restrições que possam afetar a
capacidade de se conseguir um sistema aceitável. Coletar dados adicionais sobre
desempenho, confiabilidade, manutenibilidade e capacidade de reutilização.
1.6.4. Viabilidade legal
Uma determinação de qualquer infração, violação ou responsabilidade legal que
possa resultar do desenvolvimento do sistema.
1.7. Análise de Requisitos
Especificar todos os requisitos funcionais e de qualidade do software, incluindo as
capacidades do produto, os recursos disponíveis, os benefícios e os critérios de
aceitação.
2. Itens da Documentação do Software
2.1. Introdução
2.2. Descrição do Sistema
2.3. Diagrama de Contexto (DC)
2.4. Tabela de Eventos
2.5. Diagrama de Fluxos de Dados por Eventos
2.6. Diagrama de Entidades e Relacionamentos por Eventos
2.7. Diagrama Preliminar ou Tabela eventos x processos
2.8. Diagrama de Fluxos de Dados (DFD)
2.9. Especificação de Processos (EP)
2.10. Diagrama de Entidades e Relacionamentos (DER)
2.11. Diagrama de Transição de Estado (DTE)
2.12. Dicionário de Dados (DD)
 entidades
 depósitos de dados
 fluxos de dados
2.13. Documentação de Projeto Estruturado
 Diagrama de Estrutura Modular (DEM)
 pseudo-código
2.14. Cronograma de Construção do Sistema
2.15. definição do problema
2.16. análise
2.17. projeto lógico
2.18. Ambiente de Instalação
2.19. Custo previsto
2.20. hardware
2.21. software
2.22. peopleware
3. Referências
Seidl de Moura, M.L., Ferreira, M. C. & Paine, P. A. (1998). Manual de Elaboração de
Projetos de Pesquisa. Rio de Janeiro: Eduerj.