Académique Documents
Professionnel Documents
Culture Documents
2 de Setembro de 2008
Conteúdo
II Informações Básicas 5
2 Plano de ensino 21
2.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Público Alvo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Pré-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7 Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9 Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Introdução 24
3.1 Conceitos iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Exemplo de sistema de informação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Considerações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Problemas e mitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
5 Práticas de planejamento 32
5.1 Planejamento de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2 Modelo de processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3 Processo de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4 Ciclos de vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5 Técnicas de quarta geração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7 Disciplinas de um projeto 41
7.1 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1.1 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1.2 Perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.2 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.3 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.3.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.3.3 Perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.4 Protótipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2
Parte I
3
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
Conteúdo
O conteúdo dessa apostila é fruto da compilação de diversos materiais livres publicados na in-
ternet, disponíveis em diversos sites ou originalmente produzido no CDTC em http://www.cdtc.org.br.
O formato original deste material bem como sua atualização está disponível dentro da licença
GNU Free Documentation License, cujo teor integral encontra-se aqui reproduzido na seção de
mesmo nome, tendo inclusive uma versão traduzida (não oficial).
A revisão e alteração vem sendo realizada pelo CDTC (suporte@cdtc.org.br), desde outubro
de 2006. Criticas e sugestões construtivas são bem-vindas a qualquer tempo.
Autores
A autoria deste conteúdo, atividades e avaliações é de responsabilidade de Gabriel Gianelli
Pena (gabriel@cdtc.org.br) .
O texto original faz parte do projeto Centro de Difusão de Tecnolgia e Conhecimento, que vem
sendo realizado pelo ITI em conjunto com outros parceiros institucionais, atuando em conjunto
com as universidades federais brasileiras que tem produzido e utilizado Software Livre, apoiando
inclusive a comunidade Free Software junto a outras entidades no país.
Garantias
O material contido nesta apostila é isento de garantias e o seu uso é de inteira responsabi-
lidade do usuário/leitor. Os autores, bem como o ITI e seus parceiros, não se responsabilizam
direta ou indiretamente por qualquer prejuízo oriundo da utilização do material aqui contido.
Licença
Copyright ©2006,Gabriel Gianelli Pena (gabriel@cdtc.org.br) .
Permission is granted to copy, distribute and/or modify this document under the terms
of the GNU Free Documentation License, Version 1.1 or any later version published by
the Free Software Foundation; with the Invariant Chapter being SOBRE ESSA APOS-
TILA. A copy of the license is included in the section entitled GNU Free Documentation
License.
4
Parte II
Informações Básicas
5
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
Sobre o CDTC
Objetivo Geral
Objetivo Específico
Guia do aluno
Neste guia, você terá reunidas uma série de informações importantes para que você comece
seu curso. São elas:
• Primeiros passos
É muito importante que você entre em contato com TODAS estas informações, seguindo o
roteiro acima.
Licença
6
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
É dada permissão para copiar, distribuir e/ou modificar este documento sob os termos
da Licença de Documentação Livre GNU, Versão 1.1 ou qualquer versão posterior
publicada pela Free Software Foundation; com o Capítulo Invariante SOBRE ESSA
APOSTILA. Uma cópia da licença está inclusa na seção entitulada "Licença de Docu-
mentação Livre GNU".
• 5. Organização pessoal: planejar e organizar tudo é fundamental para facilitar a sua revisão
e a sua recuperação de materiais.
• 6. Vontade para realizar as atividades no tempo correto: anotar todas as suas obrigações e
realizá-las em tempo real.
• 10. Responsabilidade: ser responsável por seu próprio aprendizado. O ambiente virtual não
controla a sua dedicação, mas reflete os resultados do seu esforço e da sua colaboração.
A primeira é o uso dos fóruns de notícias e de dúvidas gerais que se distinguem pelo uso:
O fórum de notícias tem por objetivo disponibilizar um meio de acesso rápido a informações
que sejam pertinentes ao curso (avisos, notícias). As mensagens postadas nele são enviadas a
7
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
todos participantes. Assim, se o monitor ou algum outro participante tiver uma informação que
interesse ao grupo, favor postá-la aqui.
Porém, se o que você deseja é resolver alguma dúvida ou discutir algum tópico específico do
curso, é recomendado que você faça uso do Fórum de dúvidas gerais que lhe dá recursos mais
efetivos para esta prática.
. O fórum de dúvidas gerais tem por objetivo disponibilizar um meio fácil, rápido e interativo
para solucionar suas dúvidas e trocar experiências. As mensagens postadas nele são enviadas
a todos participantes do curso. Assim, fica muito mais fácil obter respostas, já que todos podem
ajudar.
Se você receber uma mensagem com algum tópico que saiba responder, não se preocupe com a
formalização ou a gramática. Responda! E não se esqueça de que antes de abrir um novo tópico
é recomendável ver se a sua pergunta já foi feita por outro participante.
Uma wiki é uma página web que pode ser editada colaborativamente, ou seja, qualquer par-
ticipante pode inserir, editar, apagar textos. As versões antigas vão sendo arquivadas e podem
ser recuperadas a qualquer momento que um dos participantes o desejar. Assim, ela oferece um
ótimo suporte a processos de aprendizagem colaborativa. A maior wiki na web é o site "Wikipé-
dia", uma experiência grandiosa de construção de uma enciclopédia de forma colaborativa, por
pessoas de todas as partes do mundo. Acesse-a em português pelos links:
Primeiros Passos
Para uma melhor aprendizagem é recomendável que você siga os seguintes passos:
• Ler a Ambientação do Moodle para aprender a navegar neste ambiente e se utilizar das
ferramentas básicas do mesmo;
Perfil do Tutor
8
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
A classificação por um tutor desta natureza proporciona o melhor feedback possível, é crucial, e,
para a maior parte dos alunos, constitui o ponto central do processo de aprendizagem.’ Este tutor
ou instrutor:
• fornece explicações claras acerca do que ele espera, e do estilo de classificação que irá
utilizar;
• identifica as nossas falhas, mas corrige-as amavelmente’, diz um estudante, ’e explica por-
que motivo a classificação foi ou não foi atribuída’;
• tece comentários completos e construtivos, mas de forma agradável (em contraste com um
reparo de um estudante: ’os comentários deixam-nos com uma sensação de crítica, de
ameaça e de nervosismo’)
9
Parte III
10
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
This is an unofficial translation of the GNU General Documentation License into Brazilian Por-
tuguese. It was not published by the Free Software Foundation, and does not legally state the
distribution terms for software that uses the GFDL–only the original English text of the GFDL does
that. However, we hope that this translation will help Portuguese speakers understand the GFDL
better.
É permitido a qualquer um copiar e distribuir cópias exatas deste documento de licença, mas
não é permitido alterá-lo.
INTRODUÇÃO
O propósito desta Licença é deixar um manual, livro-texto ou outro documento escrito "livre"no
sentido de liberdade: assegurar a qualquer um a efetiva liberdade de copiá-lo ou redistribui-lo,
com ou sem modificações, comercialmente ou não. Secundariamente, esta Licença mantém
para o autor e editor uma forma de ter crédito por seu trabalho, sem ser considerado responsável
pelas modificações feitas por terceiros.
Nós fizemos esta Licença para que seja usada em manuais de software livre, por que software
livre precisa de documentação livre: um programa livre deve ser acompanhado de manuais que
provenham as mesmas liberdades que o software possui. Mas esta Licença não está restrita a
manuais de software; ela pode ser usada para qualquer trabalho em texto, independentemente
do assunto ou se ele é publicado como um livro impresso. Nós recomendamos esta Licença prin-
cipalmente para trabalhos cujo propósito seja de introdução ou referência.
APLICABILIDADE E DEFINIÇÕES
Esta Licença se aplica a qualquer manual ou outro texto que contenha uma nota colocada pelo
detentor dos direitos autorais dizendo que ele pode ser distribuído sob os termos desta Licença.
11
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
Uma "Seção Secundária"é um apêndice ou uma seção inicial do Documento que trata ex-
clusivamente da relação dos editores ou dos autores do Documento com o assunto geral do
Documento (ou assuntos relacionados) e não contém nada que poderia ser incluído diretamente
nesse assunto geral (Por exemplo, se o Documento é em parte um livro texto de matemática, a
Seção Secundária pode não explicar nada de matemática).
Essa relação poderia ser uma questão de ligação histórica com o assunto, ou matérias relaci-
onadas, ou de posições legais, comerciais, filosóficas, éticas ou políticas relacionadas ao mesmo.
As "Seções Invariantes"são certas Seções Secundárias cujos títulos são designados, como
sendo de Seções Invariantes, na nota que diz que o Documento é publicado sob esta Licença.
Os "Textos de Capa"são certos trechos curtos de texto que são listados, como Textos de Capa
Frontal ou Textos da Quarta Capa, na nota que diz que o texto é publicado sob esta Licença.
Uma cópia "Transparente"do Documento significa uma cópia que pode ser lida automatica-
mente, representada num formato cuja especificação esteja disponível ao público geral, cujos
conteúdos possam ser vistos e editados diretamente e sem mecanismos especiais com editores
de texto genéricos ou (para imagens compostas de pixels) programas de pintura genéricos ou
(para desenhos) por algum editor de desenhos grandemente difundido, e que seja passível de
servir como entrada a formatadores de texto ou para tradução automática para uma variedade
de formatos que sirvam de entrada para formatadores de texto. Uma cópia feita em um formato
de arquivo outrossim Transparente cuja constituição tenha sido projetada para atrapalhar ou de-
sencorajar modificações subsequentes pelos leitores não é Transparente. Uma cópia que não é
"Transparente"é chamada de "Opaca".
Exemplos de formatos que podem ser usados para cópias Transparentes incluem ASCII sim-
ples sem marcações, formato de entrada do Texinfo, formato de entrada do LaTex, SGML ou XML
usando uma DTD disponibilizada publicamente, e HTML simples, compatível com os padrões, e
projetado para ser modificado por pessoas. Formatos opacos incluem PostScript, PDF, formatos
proprietários que podem ser lidos e editados apenas com processadores de texto proprietários,
SGML ou XML para os quais a DTD e/ou ferramentas de processamento e edição não estejam
disponíveis para o público, e HTML gerado automaticamente por alguns editores de texto com
finalidade apenas de saída.
12
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
Você não pode usar medidas técnicas para obstruir ou controlar a leitura ou confecção de
cópias subsequentes das cópias que você fizer ou distribuir. Entretanto, você pode aceitar com-
pensação em troca de cópias. Se você distribuir uma quantidade grande o suficiente de cópias,
você também precisa respeitar as condições da seção 3.
Você também pode emprestar cópias, sob as mesmas condições colocadas acima, e também
pode exibir cópias publicamente.
Se os textos requeridos em qualquer das capas for muito volumoso para caber de forma
legível, você deve colocar os primeiros (tantos quantos couberem de forma razoável) na capa
verdadeira, e continuar os outros nas páginas adjacentes.
Se você publicar ou distribuir cópias Opacas do Documento em número maior que 100, você
precisa ou incluir uma cópia Transparente que possa ser lida automaticamente com cada cópia
Opaca, ou informar, em ou com, cada cópia Opaca a localização de uma cópia Transparente
completa do Documento acessível publicamente em uma rede de computadores, a qual o público
usuário de redes tenha acesso a download gratuito e anônimo utilizando padrões públicos de
protocolos de rede. Se você utilizar o segundo método, você precisará tomar cuidados razoavel-
mente prudentes, quando iniciar a distribuição de cópias Opacas em quantidade, para assegurar
que esta cópia Transparente vai permanecer acessível desta forma na localização especificada
por pelo menos um ano depois da última vez em que você distribuir uma cópia Opaca (direta-
mente ou através de seus agentes ou distribuidores) daquela edição para o público.
É pedido, mas não é obrigatório, que você contate os autores do Documento bem antes de
redistribuir qualquer grande número de cópias, para lhes dar uma oportunidade de prover você
com uma versão atualizada do Documento.
13
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
MODIFICAÇÕES
Você pode copiar e distribuir uma Versão Modificada do Documento sob as condições das se-
ções 2 e 3 acima, desde que você publique a Versão Modificada estritamente sob esta Licença,
com a Versão Modificada tomando o papel do Documento, de forma a licenciar a distribuição
e modificação da Versão Modificada para quem quer que possua uma cópia da mesma. Além
disso, você precisa fazer o seguinte na versão modificada:
A. Usar na Página de Título (e nas capas, se houver alguma) um título distinto daquele do Do-
cumento, e daqueles de versões anteriores (que deveriam, se houvesse algum, estarem listados
na seção "Histórico do Documento"). Você pode usar o mesmo título de uma versão anterior se
o editor original daquela versão lhe der permissão;
B. Listar na Página de Título, como autores, uma ou mais das pessoas ou entidades responsá-
veis pela autoria das modificações na Versão Modificada, conjuntamente com pelo menos cinco
dos autores principais do Documento (todos os seus autores principais, se ele tiver menos que
cinco);
E. Adicionar uma nota de copyright apropriada para suas próprias modificações adjacente às
outras notas de copyright;
F. Incluir, imediatamente depois das notas de copyright, uma nota de licença dando ao público
o direito de usar a Versão Modificada sob os termos desta Licença, na forma mostrada no tópico
abaixo;
G. Preservar nessa nota de licença as listas completas das Seções Invariantes e os Textos de
Capa requeridos dados na nota de licença do Documento;
I. Preservar a seção entitulada "Histórico", e seu título, e adicionar à mesma um item dizendo
pelo menos o título, ano, novos autores e editor da Versão Modificada como dados na Página de
Título. Se não houver uma sessão denominada "Histórico"no Documento, criar uma dizendo o
título, ano, autores, e editor do Documento como dados em sua Página de Título, então adicionar
um item descrevendo a Versão Modificada, tal como descrito na sentença anterior;
J. Preservar o endereço de rede, se algum, dado no Documento para acesso público a uma
cópia Transparente do Documento, e da mesma forma, as localizações de rede dadas no Docu-
mento para as versões anteriores em que ele foi baseado. Elas podem ser colocadas na seção
"Histórico". Você pode omitir uma localização na rede para um trabalho que tenha sido publicado
pelo menos quatro anos antes do Documento, ou se o editor original da versão a que ela se refira
der sua permissão;
14
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
seção e preservar a seção em toda substância e fim de cada um dos agradecimentos de contri-
buidores e/ou dedicatórias dados;
M. Apagar qualquer seção entitulada "Endossos". Tal sessão não pode ser incluída na Versão
Modificada;
N. Não reentitular qualquer seção existente com o título "Endossos"ou com qualquer outro
título dado a uma Seção Invariante.
Se a Versão Modificada incluir novas seções iniciais ou apêndices que se qualifiquem como
Seções Secundárias e não contenham nenhum material copiado do Documento, você pode optar
por designar alguma ou todas aquelas seções como invariantes. Para fazer isso, adicione seus
títulos à lista de Seções Invariantes na nota de licença da Versão Modificada. Esses títulos preci-
sam ser diferentes de qualquer outro título de seção.
Você pode adicionar uma seção entitulada "Endossos", desde que ela não contenha qual-
quer coisa além de endossos da sua Versão Modificada por várias pessoas ou entidades - por
exemplo, declarações de revisores ou de que o texto foi aprovado por uma organização como a
definição oficial de um padrão.
Você pode adicionar uma passagem de até cinco palavras como um Texto de Capa da Frente
, e uma passagem de até 25 palavras como um Texto de Quarta Capa, ao final da lista de Textos
de Capa na Versão Modificada. Somente uma passagem de Texto da Capa da Frente e uma de
Texto da Quarta Capa podem ser adicionados por (ou por acordos feitos por) qualquer entidade.
Se o Documento já incluir um texto de capa para a mesma capa, adicionado previamente por
você ou por acordo feito com alguma entidade para a qual você esteja agindo, você não pode
adicionar um outro; mas você pode trocar o antigo, com permissão explícita do editor anterior que
adicionou a passagem antiga.
O(s) autor(es) e editor(es) do Documento não dão permissão por esta Licença para que seus
nomes sejam usados para publicidade ou para assegurar ou implicar endossamento de qualquer
Versão Modificada.
COMBINANDO DOCUMENTOS
Você pode combinar o Documento com outros documentos publicados sob esta Licença, sob
os termos definidos na seção 4 acima para versões modificadas, desde que você inclua na com-
binação todas as Seções Invariantes de todos os documentos originais, sem modificações, e liste
todas elas como Seções Invariantes de seu trabalho combinado em sua nota de licença.
O trabalho combinado precisa conter apenas uma cópia desta Licença, e Seções Invariantes
Idênticas com multiplas ocorrências podem ser substituídas por apenas uma cópia. Se houver
múltiplas Seções Invariantes com o mesmo nome mas com conteúdos distintos, faça o título de
15
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
cada seção único adicionando ao final do mesmo, em parênteses, o nome do autor ou editor
origianl daquela seção, se for conhecido, ou um número que seja único. Faça o mesmo ajuste
nos títulos de seção na lista de Seções Invariantes nota de licença do trabalho combinado.
COLETÂNEAS DE DOCUMENTOS
Você pode fazer uma coletânea consitindo do Documento e outros documentos publicados
sob esta Licença, e substituir as cópias individuais desta Licença nos vários documentos com
uma única cópia incluida na coletânea, desde que você siga as regras desta Licença para cópia
exata de cada um dos Documentos em todos os outros aspectos.
Você pode extrair um único documento de tal coletânea, e distribuí-lo individualmente sob
esta Licença, desde que você insira uma cópia desta Licença no documento extraído, e siga esta
Licença em todos os outros aspectos relacionados à cópia exata daquele documento.
Se o requerido para o Texto de Capa na seção 3 for aplicável a essas cópias do Documento,
então, se o Documento constituir menos de um quarto de todo o agregado, os Textos de Capa
do Documento podem ser colocados em capas adjacentes ao Documento dentro do agregado.
Senão eles precisarão aparecer nas capas de todo o agregado.
TRADUÇÃO
Tradução é considerada como um tipo de modificação, então você pode distribuir traduções
do Documento sob os termos da seção 4. A substituição de Seções Invariantes por traduções
requer uma permissão especial dos detentores do copyright das mesmas, mas você pode incluir
traduções de algumas ou de todas as Seções Invariantes em adição às versões orignais dessas
Seções Invariantes. Você pode incluir uma tradução desta Licença desde que você também in-
clua a versão original em Inglês desta Licença. No caso de discordância entre a tradução e a
16
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
TÉRMINO
Você não pode copiar, modificar, sublicenciar, ou distribuir o Documento exceto como expres-
samente especificado sob esta Licença. Qualquer outra tentativa de copiar, modificar, sublicen-
ciar, ou distribuir o Documento é nula, e resultará automaticamente no término de seus direitos
sob esta Licença. Entretanto, terceiros que tenham recebido cópias, ou direitos de você sob esta
Licença não terão suas licenças terminadas, tanto quanto esses terceiros permaneçam em total
acordo com esta Licença.
Para usar esta Licença num documento que você escreveu, inclua uma cópia desta Licença
no documento e ponha as seguintes notas de copyright e licenças logo após a página de título:
Se você não tiver nenhuma Seção Invariante, escreva "sem Seções Invariantes"ao invés de
dizer quais são invariantes. Se você não tiver Textos de Capa da Frente, escreva "sem Textos de
Capa da Frente"ao invés de "com os Textos de Capa da Frente sendo LISTE"; o mesmo para os
Textos da Quarta Capa.
Se o seu documento contiver exemplos não triviais de código de programas, nós recomenda-
mos a publicação desses exemplos em paralelo sob a sua escolha de licença de software livre,
17
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
tal como a GNU General Public License, para permitir o seu uso em software livre.
18
Parte IV
Planejamento em desenvolvimento de
sistemas
19
Capítulo 1
Planejamento em desenvolvimento de
sistemas
20
Capítulo 2
Plano de ensino
2.1 Objetivo
Disponibilizar ao usuário conhecimentos acerca de planejamento de sistemas.
2.3 Pré-requisitos
Os usuários deverão ser, necessariamente, familiarizados com o padrão de modelagem UML
e possuir algum conhecimento em programação, além de ser desejavel o conhecimento de projeto
modelado a objeto.
2.4 Descrição
O curso será realizado na modalidade Educação a Distância e utilizará a Plataforma Moodle
como ferramenta de aprendizagem. O curso tem duração de uma semana e possui um conjunto
de atividades (lições, fóruns, glossários, questionários e outros) que deverão ser executadas de
acordo com as instruções fornecidas. O material didático estará disponível on-line de acordo com
as datas pré-estabelecidas em cada tópico. Esse assunto é dinâmico e pode ser que alguma
coisa de desatualize com o tempo.
2.5 Metodologia
O curso está dividido da seguinte maneira:
2.6 Cronograma
• Introdução;
21
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
• Práticas de planejamento;
• Disciplinas de um projeto.
As lições contém o contéudo principal. Elas poderão ser acessadas quantas vezes forem neces-
sárias, desde que esteja dentro da semana programada. Ao final de uma lição, você receberá
uma nota de acordo com o seu desempenho. Responda com atenção às perguntas de cada lição,
pois elas serão consideradas na sua nota final. Caso sua nota numa determinada lição for menor
do que 6.0, sugerimos que você faça novamente esta lição.
Ao final do curso será disponibilizada a avaliação referente ao curso. Tanto as notas das lições
quanto a da avaliação serão consideradas para a nota final. Todos os módulos ficarão visíveis
para que possam ser consultados durante a avaliação final.
Aconselhamos a leitura da "Ambientação do Moodle"para que você conheça a plataforma de En-
sino a Distância, evitando dificuldades advindas do "desconhecimento"sobre a mesma.
Os instrutores estarão a sua disposição ao longo de todo curso. Qualquer dúvida deverá ser
enviada no fórum. Diariamente os monitores darão respostas e esclarecimentos.
2.7 Programa
O curso planejamento desenvolvimento de sistemas oferecerá o seguinte conteúdo:
2.8 Avaliação
Toda a avaliação será feita on-line.
Aspectos a serem considerados na avaliação:
Instrumentos de avaliação:
• AF = Avaliações
22
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
2.9 Bibliografia
Este curso foi inspirado nos slides de aula do professor da UnB Doutor Ricardo Starciarini
Puttini da disciplina Metodologia de desenvolvimento de software ministrada no departamento de
engenharia elétrica.
23
Capítulo 3
Introdução
Serviço: atividade realizada por mão-de-obra qualificada também tendo em vista alguma ne-
cessidade específica.
24
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
3.3 Considerações
É importante conceber o software como um produto, todavia trata-se de um produto intangí-
vel. Sendo assim, a prática de desenvolvimento de sistemas necessita de documentos para que
possamos acompanhar sua evolução. Isso causa problemas na medida em que estes documen-
tos necessitam de tempo para sua aprovação. O tempo é algo crítico na produção de software,
portanto nota-se que boas práticas de engenharia de software muitas vezes têm também des-
vantagens. Isso mostra como a produção de software ainda esta "engatinhando"e considerações
a acerca da eficácia de modelos de engenharia de software podem vir à tona, com alguma razão
até.
Deve-se enfatizar o papel de um projeto de software também fora da esfera técnica: um proje-
tista de software deve estar atento a questões éticas, profissionais e sociais. Isso é uma temática
bastante polêmica: como saber o que é certo ou errado num mundo tão complexo como o de
hoje? Apenas como reflexão, jamais com intuito de condenar ninguém, podemos colocar o de-
senvolvimento de sistemas militares em pauta. Vale a pena refletir um pouco sobre algumas
questões como essa.
Como aspectos éticos, não restringindo apenas a esses, pode-se considerar quesitos como:
confidencialidade, competência, transparência, direito de propriedade intelectual e finalidades do
uso do computador.
O primeiro é em relação à imprecisão das estimativas de prazo. Isso ocorre, via de regra,
quando no projeto não se dedica tempo para capturar dados sobre a atividade de desenvol-
vimento. Mais adiante veremos práticas que enfatizam a captura desses dados. A discussão
anterior é válida também no que diz respeito a estimativa de custos.
25
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
O pessoal pode falhar durante o projeto. Gerente sem background em software, falta de
treinamento e principalmente resistência a mudanças aos fatores que devem ser evitados para
afugentar o fracasso do seu projeto.
"Se a equipe está com os prazos atrasados, é conveniente contratar mais programadores e
facilmente tirar o atraso."Análise: contratar mais pessoas, à medida em que estas tem que ser
inseridas no projeto podem atrasar ainda mais. Somente com planejamento isso pode ocorrer.
"Os objetivos devem ser definidos em linhas gerais e com o decorrer do projeto os detalhes
vão sendo acrescentados."Análise: a coleta de requisitos é fundamental, causa primordial de fra-
casso de projetos.
"O cliente pensa: como o próprio nome indica, o software é flexivel e portanto mudanças no
projeto do software podem ser realizadas de forma tranqüila."Análise: não ha nada mais falso, se
uma mudança for solicitada no final do projeto com certeza vai gastar mais tempo.
"O software fica pronto quando o programa funciona."Análise: estatísticas da indústria mos-
tram que aproximadamente 60% dos recursos gastos com o programa ocorrem após a primeira
entrega para o cliente.
26
Capítulo 4
A partir dessa definição, podemos inferir algumas características do software como produto.
Como a definição já indica, o software não deve ser feito de maneira desordenada, sem planeja-
mento. Pelo contrário, valendo-se de práticas de engenharia, procura-se desenvolver o produto
de maneira sistemática, ou seja, de acordo com o método. Isso é essencial em grandes projetos
de software, pois se não houvesse planejamento, qualquer erro poderia colocar todo um projeto
(e muito dinheiro) em risco.
O software também não é como um carro onde se pegam peças, juntam-nas para formar o
produto e depois pode-se vendê-lo em série. De forma geral, um software é feito sob medida
para determinado cliente: cada empresa tem suas necessidades e cabe ao projetista conceber
um sistema que satisfaça-as da maneira mais eficiente possível, ainda que existam softwares de
uso genérico vendidos em grande escala.
27
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
• Eficiência: o software deve otimizar os recursos do sistema afim de que não haja desperdí-
cio;
• Fácil manutenção: com o decorrer do projeto, o software deve evoluir de acordo com mu-
danças no requisito;
A prioridade desses atributos varia de produto para produto, cabendo ao projetista dentro do
contexto do ambiente defini-las.
A definição está relacionada com "o quê"o software deve ser; aqui se encaixam práticas
como análise do sistema, análise de requisitos e planejamento de projeto.
Análise de requisitos: aqui deve-se definir de maneira clara e detalhada a função do ssoftware,
é aqui que de fato se estabelece o que o software deve ser.
No desenvolvimento, por sua vez, o foco já é em "como"o software deve fazer aquilo que
foi determinado na etapa anterior. Ao seu término, o software já deve estar em uso funcional.
Etapas: projeto de software, codificação e testes de software.
28
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
Nota: casualmente, o termo projeto também pode ser usado para denominar a engenharia de
software como um todo, desde o início.
Codificação: uma vez nessa etapa, converte-se o projeto em alguma linguagem de progra-
mação para que os computadores possam executar.
Testes: testa-se se o softwarepara verificar se atende aos requisitos e ao mesmo tempo pro-
cura por falhas (bugs) lógicos ou funcionais
Manutenção: aqui, busca-se por mudanças afim de que o produto evolua, pois é muito pro-
vável que o cliente não fique plenamente satisfeito ao final da etapa de desenvolvimento.
Tipos:
Além das etapas listadas abaixo, paralelamente deve-se executar atividades de proteção (con-
trole) do projeto:
Alguns exemplos: falta de pessoal bem-treinado, atrito entre a equipe, não atendimento aos
requisitos mínimos de desempenho dentre diversos tipos de riscos.
29
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
Alguns exemplos: falta de pessoal bem-treinado, atrito entre a equipe, não atendimento aos
requisitos mínimos de desempenho dentre diversos tipos de riscos.
30
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
31
Capítulo 5
Práticas de planejamento
No que concerne à monitoração, deve-se designar parte da equipe como responsável por
essa etapa, descrever os procedimentos de monitoração, os aspectos monitorados e a monitora-
ção de retorno do cliente.
Outro dado imprescindível que deve ser monitorado é os defeitos. Num eventual relatório
sobre este dado, deve aparecer o código do projeto no qual o defeito foi observado, a descrição
precisa do defeito, estágio no qual foi identificado, o nome de quem identificou e o de quem é
reponsável pela correção do defeito e as datas convenientes.
32
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
Quando planejar os perfis dos profissionais deve-se relacionar cada membro, segundo uma
hierarquia estabelecida, atribuindo a cada um responsabilidades e um período específico de par-
ticipação no projeto.
Funções de um processo:
• definir artefatos;
• permite que o próprio processo seja reutilizável e que possa evoluir com o passar do tempo;
33
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
Anteriormente em nosso curso já nos deparamos com a definição de artefato. Aqui esse
conceito volta, pois no decorrer do processo os artefatos são modificados e criados ao longo do
processo. Cabe aqui também diferenciar artefatos técnicos tais como: diagramas, componentes,
etc; de artefatos gerenciais, de função de controle de atividades, como: planos de negócio ou
planos de alocação da equipe.
Durante os processos são estabelecidos perfis de acordo com habilidades de cada membro
da equipe, como: analista de sistemas, revisor,dentre outros. Cada perfil é responsável pela exe-
cução de atividades que resultam em artefatos. Exemplo: revisão dos casos de uso, codificação.
Essas atividades são encadeadas em seqüência de forma que o artefato produzido por uma
seja a entrada de outra. Pode ocorrer uma interação na qual um encadeamento (fluxo) de ativi-
dades seja percorrida múltiplas vezes.
Falemos agora do ciclo de vida de um processo. Processos estáticos são vantajosos no sen-
tido que são mais fáceis de assimilar pela equipe e as estimativas podem ser feitas com mais
previsão. Todavia, se o pessoal estiver bem treinado e bem gerenciado, processos flexíveis tor-
nam o projeto muito mais dinâmico. Para tanto, existem classes de processos definidos dos quais
se podem configurar processos, de acordo com o tamanho e nível de treinamento da equipe e da
importância da aplicação. Essa configuração é regida por um guia de configuração, que sugere
opções, atributos e alternativas de configuração.
Uma prática saúdavel da engenharia de software consiste em manter uma base de dados
para cada processo. A engenharia de software só atinge sua excelência com a prática, portanto
o projetista deve ter uma base de dados com informações de cada projeto, para que este seja
analisado quando concluído e a partir daí tirar-se valiosas conclusões a respeito de erros e acer-
tos no projeto.
Nessa base de dados deve-se guardar informações gerais sobre dados de monitoração (es-
forço, defeitos e tamanho), relatórios sobre erros e acertos e referência para textos e documentos
que foram fonte de pesquisa.
Relatório de erros e acertos: podem ser escritos em subdivisões tais como: recursos
humanos, especificação de requisitos, ferramentas, projeto, teste, revisões, qualidade, gerên-
cia,metodologia dentre outras possíveis.
34
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
Por ser uma área extensa, costuma-se subdividi-la em diversas subáreas: engenharia de
requisitos, especificação, projetos, testes, gerência de configuração, ou seja, aquelas áreas
que já vimos um pouco a respeito.
Para o caso em que esteja se desenvolvendo software aberto, deve-se levar em conta que os
desenvolvedores podem estar distantes fisicamente. Assim, são criadas comunidades virtu-
ais para seu desenvolvimento, úteis também para uma discussão acerca das experiências com o
uso do software após este ficar pronto. A gerência aqui assume cores participativas, cada um
toma atividades por conta própria para realizar. As ferramentas e processos usados também não
são definidas por uma só pessoa, várias partes participam da decisão. O foco é na entrega no
menor tempo possível, com posteriores melhorias incrementais no produto, incentivadas pelo
"feedback"dado pelos usuários. Outra característica interessante é que em projetos de software
aberto os próprios desenvolvedores usufruem do software final. A maioria das distribuições
são operacionais, mas instáveis, e a estabilidade vem de forma gradual e iterativa. Por fim,
as ferramentas são preferencialmente abertas e a informação é disponibilizada de forma transpa-
rente.
Ao término de cada ciclo de vida, temos modelos que descrevem a versão do software: mo-
delos de caso de uso, análise, projeto, implementação, implantação, testes e arquitetura. Para
cada ciclo, existem também fases, que resultam em modelos e documentação: concepção, ela-
boração, construção e transição.
35
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
O modelo iterativo utiliza-se de outra abordagem: apenas com um conjunto limitado de re-
quisitos (parciais) inicia-se o desenvolvimento, e com o decorrer do projeto novos requisitos são
determinados. Essa abordagem para projetos grandes via de regra se mostra mais eficaz, pois
com o início do desenvolvimento tem-se uma idéia mais madura de quais requisitos o software
deve atender, do foco do projeto e arquitetura utilizada. Os riscos são catalogados logo no começo
do projeto e as perdas estão relacionadas apenas com o custo de cada iteração. Se o modelo
utilizado fosse o seqüencial, mudanças nos requisitos poderiam acarretar em mudanças trágicas
para o projeto, o que não ocorre no caso iterativo, que não só prevê como "pede"mudanças nos
requisitos. Um fato curioso é que se se julgar pertinente, pode-se iniciar uma iteração sem que a
anterior termine.
Em iterações, o planejamento não ocorre de forma única: nas fases de concepção e elabo-
ração, a cada iteração temos que planejá-las, contudo para as demais fases elas só são bem
planejadas nas primeiras iterações, ao final quase não há planejamento substancial. O planeja-
mento leva em conta, obviamente, os resultados das iterações anteriores, onde se avalia o estado
dessa última iteração, além de mais uma vez catalogar riscos para essa iteração.
Como exemplo pode-se citar o modelo espiral, que enfatiza a análise dos riscos e também
uma forte comunicação com o cliente para melhor definição dos requisitos. No modelo espiral,
inicialmente reuni-se com o cliente para definir os requisitos; depois as etapas seguem (com foco
nos riscos), até a liberação. Em seguida é feita uma verificação do cliente, que via de regra exigirá
novos requisitos e de novo passam-se por aquelas etapas, até nova avaliação do cliente. Como
na primeira iteração toda a base do produto já foi feita, cada iteração adicional costuma gastar
menos tempo que a anterior, por isso o modelo é conhecido como espiral. Cabe um alerta: se
utilizar o modelo espiral, o analista de riscos deve ser extremamente eficiente, pois é isso que
sustenta esse modelo.
36
Capítulo 6
6.1 Arquitetura
É a arquitetura que dita os elementos mais relevantes de um sistema, muito útil para entender
e lidar com o sistema. Os rumos da arquitetura são ditados por elementos como o software do
sistema, versões antigas, padrões que devem ser seguidos, etc.
Como se estabelece uma arquitetura?
Estabelecida nas fases de concepção e elaboração, primeiro define-se softwares, middleware
e políticas adotadas. Requisitos não funcionais são tratados nessa etapa, bem como caracterís-
ticas bem específicas da aplicação. Casos de uso devem ser analisados para o estabelecimento
da arquitetura. Após se estabelecer a arquitetura, o restante dos casos de uso devem ser de
fato implementados na fase de construção, e uma vez implementados, a arquitetura deve ser
aprimorada.
6.2 Fases
6.2.1 Concepção
Atividade que objetiva uma visão inicial do sistema, contendo objetivos para os usuários, mo-
delo com casos de uso, identificação de riscos, estimativa de custos e um planejamento para a
próxima fase (elaboração).
Nesta fase, deve-se reunir número substancial de informações coletadas antes do projeto,
organizá-las e notar as informações que ainda faltam (tipicamente, vão faltar nesse início infor-
mações sobre requisitos de performance, riscos e custos).
Deve-se formar sua equipe nessa fase inicial: gerente de projeto, desenvolvedores, enge-
nheiro de teste, etc. A concepção foi satisfatória se alguns resultados foram atingidos, como: lista
de requisitos, primeiras versões dos modelos de caso de uso, análise, projeto e arquitetura, lista
parcial de riscos, versão inicial do plano de negócios, etc.
6.2.2 Elaboração
Esta fase objetiva concluir todo o estabelecimento de requisitos, efetivá-los por meio do caso
de uso, estabelecer a arquitetura e estabelecer estratégias para controle de riscos.
37
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
Dentre as ações relacionadas com essa etapa, lista-se planejamento, concluir o restante da
equipe e adequar o ambiente de desenvolvimento.
Ao fim dessa fase, deve-se atingir uma nova versão dos modelos, uma arquitetura básica bem
sólida e descrita, relatórios mais específicos sobre riscos e justificativa econômica.
6.2.3 Construção
Essa é a fase que consome a maioria dos recursos que são gastos ao longo do projeto.
Deve-se executá-la visando a um sistema para operação no ambiente do usuário, coerente com
a arquitetura, aprimorar modelos de análise, projeto e implementação, detalhar os últimos casos
de uso, integrar e testar o sistema.
6.2.4 Transição
A idéia por trás dessa fase é tomar o software executável da fase anterior, fazer dele uma
versão beta, disponibilizá-lo para um conjunto de usuários que reportarão erros que serão corri-
gidos, resultando numa versão do software. Além disso, deve-se produzir um manual do software
com o objetivo de auxiliar o usuário a se familiarizar ao produto.
Aqui deve-se levar em conta principalmente se os testes feitos com a versão beta estão con-
siderando os requisitos iniciais e se as partes usuário e cliente estão satisfeitos com o produto.
Esta fase deve disponibilizar o software executável, documentos legais, modelos completos,
descrição da arquitetura, os manuais para usuários e administradores, material para treinamento,
etc.
• Projeto;
• Implementação;
• Teste.
38
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
Uma coleta de requisitos eficiente facilita e muito a fase de desenvolvimento: sem ela, prova-
velmente o software executável passaria longe do inicialmente pretendido pelo usuário.
Não é uma atividade trivial pois existem partes diversas interessadas no sistema (cliente,
usuário, administrador, etc) que podem ter interesses conflitantes.
Fatores que dificultam a coleta de requisitos: mudanças freqüentes nas regras de negócio,
no pessoal e na tecnologia.
A coleta de requisitos gira em torno da comunicação. Deve-se interagir com usuários, espe-
cialistas, sua equipe de desenvolvimento, o maior número possível de partes interessadas a fim
de se catalogar os requisitos da forma mais eficiente possível.
Modelos de caso de uso: é o principal artefato gerado aqui. Deve ser gerado levando em
conta o que o sistema faz para cada tipo de usuário que iterage com ele.
Glossário: é um documento que define termos utilizados na descrição do sistemas, útil para
padronizar uso de conceitos em documentos posteriores.
Protótipo de interface com usuário: facilita a descrição dos relacionamentos entre usuário
e sistema, é como um complemento para os casos de uso, uma espécie de especificação de
interface gráfica.
• projetista das interfaces: define formato das interfaces gráficas, responsável por conceber
alguns protótipos de caso de uso;
39
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
Aqui, tenta-se sanar algumas coisas que porventura faltaram na disciplina anterior. A intera-
ção entre os diversos casos de uso e possíveis redundâncias encontradas entre eles são apara-
das, e busca-se uma descrição maior do sistema pois na disciplina anterior o uso da linguagem
corriqueira pode ter feito com que algumas características do sistemas não tenham sido bem de-
talhadas.
Modelo
Busca permitir aos desenvolvedores, através de linguagem usada por eles, compreender
como implementar o software, sob o ponto de vista interno do sistema. É um artefato usado
no projeto e no desenvolvimento e estabelece como se implementarão os casos de uso. Pode-se
optar por não produzir este artefato, desde que se adote uma linguagem extremamente precisa
nos casos de uso.
Classe
Artefato também produzido no projeto, aqui ela adquire características mais conceituais. Busca
representar os subsistemas no âmbito do modelo, voltando-se para os requisitos funcionais.
Este artefato descreve, através de texto e diagramas, como um caso de uso é implementado
por classes e objetos.
Descrição da arquitetura
É um artefato que descreve os demais artefatos dessa disciplina. O modelo aqui é "que-
brado"em pacotes e descrito num relacionamento entre pacotes. Aqui se descreve também as
principais classes e as mais primordiais realizações dos casos de uso.
• arquiteto: perfil responsável pela qualidade do modelo de análise (se está relevante e com-
pleto) e também pela descrição da arquitetura.
• engenheiro de caso de uso: responsável pela integridade das realizações do caso de uso e
pela relevância dos diagramas que descrevem e realizam os casos de uso.
40
Capítulo 7
Disciplinas de um projeto
7.1 Projeto
Nesta disciplina, os requisitos devem ser aprofundados, objetivando principalmente "preparar
o terreno"para a implementação. Aqui deve-se ter sempre em mente as restrições devido às
tecnologias usadas, buscar que a captura dos requisitos deva ser feita de modo à implementação
não alterar a idéia do projeto e que ela possa ser feita por equipes independentes.
7.1.1 Artefatos
Modelo, classe, realização de casos de uso como na análise, mas seguindo diretrizes que
buscam atingir os objetivos acima.
7.1.2 Perfis
arquiteto: verifica consistência dos modelos de acordo com o que foi feito nos casos de uso
e análise;
41
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
7.2 Implementação
Componentes: é a implementação física de elementos do projeto, sendo que um compo-
nente pode implementar mais de um elemento.
Visão geral da disciplina: implementa classes do projeto, realiza testes de cada unidade de
componente, desenvolve programas executáveis pela integração de componentes.
Artefatos:
Perfis:
• testes das unidades: testa-se cada componente do sistema, e avalia-se o resultado destes
testes.
42
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
7.3 Testes
7.3.1 Introdução
Planejamento dos testes são necessários a cada iteração, testes de integração e de sistema.
Busca-se o que testar, como fazer os testes, realizar os testes e analisar resultados.
7.3.2 Artefatos
• modelo de teste: realiza minúcias de como componentes executáveis são testados e em
que contexto acontecem estes testes;
• caso de teste: descreve como testar , especificado de antemão o que deve ser testado;
• defeito: artefato que indica problemas no software, consta de algo que não é normal no
sistema;
7.3.3 Perfis
• projetista de teste: é o perfil que controla a relevância dos testes a serem realizados, deter-
minando focos na realização dos testes. Adota um cronograma para realização dos testes
e é ele o responsável pelos procedimentos e casos de teste;
• testador de sistema: realiza aqueles testes antes da conclusão da iteração, está mais preo-
cupado com a integração usuário e sistema, por isso não se interessa pelo funcionamento
interno;
Durante a análise de teste, eventualmente podemos adotar métricas para avaliar a qualidade
dos testes que foram feitos. Além disso, devemos comparar se os resultados obtidos estão de
acordo com o plano de teste.
43
CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF
7.4 Protótipo
Usados quando se quer um modelo do sistema, geralmente em casos onde o cliente define
o software em linhas gerais mas ainda não detalhou especificamente o mecanismo de processa-
mento de dados que ele almeja. Os prototipos servem como apoio para definição dos requisitos.
As fases da construção de um prototipo sao análogas as de um sistema completo, porem
sempre mais rápidas e menos detalhadas.
Os requisitos são definidos de acordo com aquela característica de superficialidade, assim é
realizado um rápido projeto seguido de implementação para que posteriormente cliente e proje-
tista se reúnam e vejam detalhadamente o que o cliente quer, ocorrendo dessa forma o que se
denomina de refinamento de requisitos.
Todavia, cautela deve ser adotada com a estratégia do uso de protótipos pois podemos vir a
ter problemas tanto por parte do cliente como do projetista.
O cliente pode querer que seu produto seja já o protótipo, talvez por pressa, e não entender
que na verdade o software ainda será construído, que melhorias ainda devem ser realizadas.
O desenvolvedor por sua vez pode se acostumar com ideia de prototipo e perder o foco na
qualidade, adotando estrategias que valem para prototipos no software final.
44