Planejamento em desenvolvimento_de_sistemas

Planejamento Em Desenvolvimento de Sistemas

2 de Setembro de 2008

Conteúdo

I Sobre essa apostila 3

II Informações Básicas 5

III GNU Free Documentation License 10

IV Planejamento em desenvolvimento de sistemas 19

1 Planejamento em desenvolvimento de sistemas 20

2 Plano de ensino 212.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2 Público Alvo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3 Pré-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.4 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.6 Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.7 Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.8 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.9 Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Introdução 243.1 Conceitos iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2 Exemplo de sistema de informação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3 Considerações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4 Problemas e mitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Práticas de planejamento - Visão geral 274.1 Definição de engenharia de software . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Componentes de um software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3 Procedimentos e atributos de qualidade . . . . . . . . . . . . . . . . . . . . . . . . . 284.4 Etapas de engenharia de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.5 Melhores práticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.5.1 Gerência de riscos: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.5.2 Gerência de riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.5.3 Gerência de configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1

CDTC Centro de Difusão de Tecnologia e Conhecimento Brasília/DF

4.5.4 Gerência de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.5.5 Gerência com uso de métricas . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 Práticas de planejamento 325.1 Planejamento de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2 Modelo de processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.3 Processo de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.4 Ciclos de vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.5 Técnicas de quarta geração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6 Introdução às disciplinas de um projeto 376.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2 Fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.2.1 Concepção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2.2 Elaboração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2.3 Construção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.2.4 Transição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.3 Disciplinas de um projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.4 Coleta de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.5 Análise de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7 Disciplinas de um projeto 417.1 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.1.1 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417.1.2 Perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.2 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427.3 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437.3.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437.3.3 Perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.4 Protótipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2

Parte I

Sobre essa apostila

3


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çaGNU Free Documentation License, cujo teor integral encontra-se aqui reproduzido na seção demesmo nome, tendo inclusive uma versão traduzida (não oficial).

A revisão e alteração vem sendo realizada pelo CDTC ([email protected]), desde outubrode 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 GianelliPena ([email protected]) .

O texto original faz parte do projeto Centro de Difusão de Tecnolgia e Conhecimento, que vemsendo realizado pelo ITI em conjunto com outros parceiros institucionais, atuando em conjuntocom as universidades federais brasileiras que tem produzido e utilizado Software Livre, apoiandoinclusive a comunidade Free Software junto a outras entidades no país.

Informações adicionais podem ser obtidas atréves do email [email protected], ou dahome page da entidade, através da URL http://www.cdtc.org.br .

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 responsabilizamdireta ou indiretamente por qualquer prejuízo oriundo da utilização do material aqui contido.

Licença

Copyright ©2006,Gabriel Gianelli Pena ([email protected]) .

Permission is granted to copy, distribute and/or modify this document under the termsof the GNU Free Documentation License, Version 1.1 or any later version published bythe 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 DocumentationLicense.

4

Parte II

Informações Básicas

5


Sobre o CDTC

Objetivo Geral

O Projeto CDTC visa a promoção e o desenvolvimento de ações que incentivem a dissemina-ção de soluções que utilizem padrões abertos e não proprietários de tecnologia, em proveito dodesenvolvimento social, cultural, político, tecnológico e econômico da sociedade brasileira.

Objetivo Específico

Auxiliar o Governo Federal na implantação do plano nacional de software não-proprietário ede código fonte aberto, identificando e mobilizando grupos de formadores de opinião dentre osservidores públicos e agentes políticos da União Federal, estimulando e incentivando o mercadonacional a adotar novos modelos de negócio da tecnologia da informação e de novos negóciosde comunicação com base em software não-proprietário e de código fonte aberto, oferecendotreinamento específico para técnicos, profissionais de suporte e funcionários públicos usuários,criando grupos de funcionários públicos que irão treinar outros funcionários públicos e atuar comoincentivadores e defensores de produtos de software não proprietários e código fonte aberto, ofe-recendo conteúdo técnico on-line para serviços de suporte, ferramentas para desenvolvimento deprodutos de software não proprietários e de seu código fonte livre, articulando redes de terceiros(dentro e fora do governo) fornecedoras de educação, pesquisa, desenvolvimento e teste de pro-dutos de software livre.

Guia do aluno

Neste guia, você terá reunidas uma série de informações importantes para que você comeceseu curso. São elas:

• Licenças para cópia de material disponível

• Os 10 mandamentos do aluno de Educação a Distância

• Como participar dos fóruns e da wikipédia

• Primeiros passos

É muito importante que você entre em contato com TODAS estas informações, seguindo oroteiro acima.

Licença

Copyright ©2006, Gabriel Gianelli Pena ([email protected]) .

6


É dada permissão para copiar, distribuir e/ou modificar este documento sob os termosda Licença de Documentação Livre GNU, Versão 1.1 ou qualquer versão posteriorpublicada pela Free Software Foundation; com o Capítulo Invariante SOBRE ESSAAPOSTILA. Uma cópia da licença está inclusa na seção entitulada "Licença de Docu-mentação Livre GNU".

Os 10 mandamentos do aluno de educação online

• 1. Acesso a Internet: ter endereço eletrônico, um provedor e um equipamento adequado épré-requisito para a participação nos cursos a distância.

• 2. Habilidade e disposição para operar programas: ter conhecimentos básicos de Informá-tica é necessário para poder executar as tarefas.

• 3. Vontade para aprender colaborativamente: interagir, ser participativo no ensino a distân-cia conta muitos pontos, pois irá colaborar para o processo ensino-aprendizagem pessoal,dos colegas e dos professores.

• 4. Comportamentos compatíveis com a etiqueta: mostrar-se interessado em conhecer seuscolegas de turma respeitando-os e fazendo ser respeitado pelo mesmo.

• 5. Organização pessoal: planejar e organizar tudo é fundamental para facilitar a sua revisãoe a sua recuperação de materiais.

• 6. Vontade para realizar as atividades no tempo correto: anotar todas as suas obrigações erealizá-las em tempo real.

• 7. Curiosidade e abertura para inovações: aceitar novas idéias e inovar sempre.

• 8. Flexibilidade e adaptação: requisitos necessário a mudança tecnológica, aprendizagense descobertas.

• 9. Objetividade em sua comunicação: comunicar-se de forma clara, breve e transparente éponto-chave na comunicação pela Internet.

• 10. Responsabilidade: ser responsável por seu próprio aprendizado. O ambiente virtual nãocontrola a sua dedicação, mas reflete os resultados do seu esforço e da sua colaboração.

Como participar dos fóruns e Wikipédia

Você tem um problema e precisa de ajuda?

Podemos te ajudar de 2 formas:

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çõesque sejam pertinentes ao curso (avisos, notícias). As mensagens postadas nele são enviadas a

7


todos participantes. Assim, se o monitor ou algum outro participante tiver uma informação queinteresse ao grupo, favor postá-la aqui.Porém, se o que você deseja é resolver alguma dúvida ou discutir algum tópico específico docurso, é recomendado que você faça uso do Fórum de dúvidas gerais que lhe dá recursos maisefetivos para esta prática.

. O fórum de dúvidas gerais tem por objetivo disponibilizar um meio fácil, rápido e interativopara solucionar suas dúvidas e trocar experiências. As mensagens postadas nele são enviadasa todos participantes do curso. Assim, fica muito mais fácil obter respostas, já que todos podemajudar.Se você receber uma mensagem com algum tópico que saiba responder, não se preocupe com aformalizaçã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.

A segunda forma se dá pelas Wikis:

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 podemser 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, porpessoas de todas as partes do mundo. Acesse-a em português pelos links:

• Página principal da Wiki - http://pt.wikipedia.org/wiki/

Agradecemos antecipadamente a sua colaboração com a aprendizagem do grupo!

Primeiros Passos

Para uma melhor aprendizagem é recomendável que você siga os seguintes passos:

• Ler o Plano de Ensino e entender a que seu curso se dispõe a ensinar;

• Ler a Ambientação do Moodle para aprender a navegar neste ambiente e se utilizar dasferramentas básicas do mesmo;

• Entrar nas lições seguindo a seqüência descrita no Plano de Ensino;

• Qualquer dúvida, reporte ao Fórum de Dúvidas Gerais.

Perfil do Tutor

Segue-se uma descrição do tutor ideal, baseada no feedback de alunos e de tutores.

O tutor ideal é um modelo de excelência: é consistente, justo e profissional nos respectivosvalores e atitudes, incentiva mas é honesto, imparcial, amável, positivo, respeitador, aceita asidéias dos estudantes, é paciente, pessoal, tolerante, apreciativo, compreensivo e pronto a ajudar.

8


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 tutorou instrutor:

• fornece explicações claras acerca do que ele espera, e do estilo de classificação que iráutilizar;

• gosta que lhe façam perguntas adicionais;

• 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 umreparo de um estudante: ’os comentários deixam-nos com uma sensação de crítica, deameaça e de nervosismo’)

• dá uma ajuda complementar para encorajar um estudante em dificuldade;

• esclarece pontos que não foram entendidos, ou corretamente aprendidos anteriormente;

• ajuda o estudante a alcançar os seus objetivos;

• é flexível quando necessário;

• mostra um interesse genuíno em motivar os alunos (mesmo os principiantes e, por isso,talvez numa fase menos interessante para o tutor);

• escreve todas as correções de forma legível e com um nível de pormenorização adequado;

• acima de tudo, devolve os trabalhos rapidamente;

9

Parte III

GNU Free Documentation License

10


(Traduzido pelo João S. O. Bueno através do CIPSGA em 2001)Esta é uma tradução não oficial da Licençaa de Documentação Livre GNU em Português

Brasileiro. Ela não é publicada pela Free Software Foundation, e não se aplica legalmente a dis-tribuição de textos que usem a GFDL - apenas o texto original em Inglês da GNU FDL faz isso.Entretanto, nós esperamos que esta tradução ajude falantes de português a entenderem melhora GFDL.

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 thedistribution terms for software that uses the GFDL–only the original English text of the GFDL doesthat. However, we hope that this translation will help Portuguese speakers understand the GFDLbetter.

Licença de Documentação Livre GNU Versão 1.1, Março de 2000

Copyright (C) 2000 Free Software Foundation, Inc.59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

É permitido a qualquer um copiar e distribuir cópias exatas deste documento de licença, masnão é permitido alterá-lo.

INTRODUÇÃO

O propósito desta Licença é deixar um manual, livro-texto ou outro documento escrito "livre"nosentido 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émpara o autor e editor uma forma de ter crédito por seu trabalho, sem ser considerado responsávelpelas modificações feitas por terceiros.

Esta Licença é um tipo de "copyleft"("direitos revertidos"), o que significa que derivações dodocumento precisam ser livres no mesmo sentido. Ela complementa a GNU Licença Pública Ge-ral (GNU GPL), que é um copyleft para software livre.

Nós fizemos esta Licença para que seja usada em manuais de software livre, por que softwarelivre precisa de documentação livre: um programa livre deve ser acompanhado de manuais queprovenham as mesmas liberdades que o software possui. Mas esta Licença não está restrita amanuais de software; ela pode ser usada para qualquer trabalho em texto, independentementedo 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 pelodetentor dos direitos autorais dizendo que ele pode ser distribuído sob os termos desta Licença.

11


O "Documento"abaixo se refere a qualquer manual ou texto. Qualquer pessoa do público é umlicenciado e é referida como "você".

Uma "Versão Modificada"do Documento se refere a qualquer trabalho contendo o documentoou uma parte dele, quer copiada exatamente, quer com modificações e/ou traduzida em outralíngua.

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 doDocumento (ou assuntos relacionados) e não contém nada que poderia ser incluído diretamentenesse assunto geral (Por exemplo, se o Documento é em parte um livro texto de matemática, aSeçã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, comosendo 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 CapaFrontal 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, cujosconteúdos possam ser vistos e editados diretamente e sem mecanismos especiais com editoresde 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 deservir como entrada a formatadores de texto ou para tradução automática para uma variedadede formatos que sirvam de entrada para formatadores de texto. Uma cópia feita em um formatode 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 XMLusando uma DTD disponibilizada publicamente, e HTML simples, compatível com os padrões, eprojetado para ser modificado por pessoas. Formatos opacos incluem PostScript, PDF, formatosproprietá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 estejamdisponíveis para o público, e HTML gerado automaticamente por alguns editores de texto comfinalidade apenas de saída.

A "Página do Título"significa, para um livro impresso, a página do título propriamente dita,mais quaisquer páginas subsequentes quantas forem necessárias para conter, de forma legível,o material que esta Licença requer que apareça na página do título. Para trabalhos que nãotenham uma página do título, "Página do Título"significa o texto próximo da aparição mais proe-minente do título do trabalho, precedendo o início do corpo do texto.

12


FAZENDO CÓPIAS EXATAS

Você pode copiar e distribuir o Documento em qualquer meio, de forma comercial ou nãocomercial, desde que esta Licença, as notas de copyright, e a nota de licença dizendo que estaLicença se aplica ao documento estejam reproduzidas em todas as cópias, e que você não acres-cente nenhuma outra condição, quaisquer que sejam, às desta Licença.

Você não pode usar medidas técnicas para obstruir ou controlar a leitura ou confecção decó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émpode exibir cópias publicamente.

FAZENDO CÓPIAS EM QUANTIDADE

Se você publicar cópias do Documento em número maior que 100, e a nota de licença doDocumento obrigar Textos de Capa, você precisará incluir as cópias em capas que tragam, clarae legivelmente, todos esses Textos de Capa: Textos de Capa da Frente na capa da frente, eTextos da Quarta Capa na capa de trás. Ambas as capas também precisam identificar clara elegivelmente você como o editor dessas cópias. A capa da frente precisa apresentar o titulo com-pleto com todas as palavras do título igualmente proeminentes e visíveis. Você pode adicionaroutros materiais às capas. Fazer cópias com modificações limitadas às capas, tanto quanto estaspreservem o título do documento e satisfaçam a essas condições, pode ser tratado como cópiaexata em outros aspectos.

Se os textos requeridos em qualquer das capas for muito volumoso para caber de formalegível, você deve colocar os primeiros (tantos quantos couberem de forma razoável) na capaverdadeira, 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ópiaOpaca, ou informar, em ou com, cada cópia Opaca a localização de uma cópia Transparentecompleta do Documento acessível publicamente em uma rede de computadores, a qual o públicousuário de redes tenha acesso a download gratuito e anônimo utilizando padrões públicos deprotocolos 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 assegurarque esta cópia Transparente vai permanecer acessível desta forma na localização especificadapor 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 deredistribuir qualquer grande número de cópias, para lhes dar uma oportunidade de prover vocêcom uma versão atualizada do Documento.

13


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çãoe modificação da Versão Modificada para quem quer que possua uma cópia da mesma. Alémdisso, 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 listadosna seção "Histórico do Documento"). Você pode usar o mesmo título de uma versão anterior seo 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 cincodos autores principais do Documento (todos os seus autores principais, se ele tiver menos quecinco);

C. Colocar na Página de Título o nome do editor da Versão Modificada, como o editor;

D. Preservar todas as notas de copyright do Documento;

E. Adicionar uma nota de copyright apropriada para suas próprias modificações adjacente àsoutras notas de copyright;

F. Incluir, imediatamente depois das notas de copyright, uma nota de licença dando ao públicoo direito de usar a Versão Modificada sob os termos desta Licença, na forma mostrada no tópicoabaixo;

G. Preservar nessa nota de licença as listas completas das Seções Invariantes e os Textos deCapa requeridos dados na nota de licença do Documento;

H. Incluir uma cópia inalterada desta Licença;

I. Preservar a seção entitulada "Histórico", e seu título, e adicionar à mesma um item dizendopelo menos o título, ano, novos autores e editor da Versão Modificada como dados na Página deTítulo. Se não houver uma sessão denominada "Histórico"no Documento, criar uma dizendo otítulo, ano, autores, e editor do Documento como dados em sua Página de Título, então adicionarum 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 umacó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 publicadopelo menos quatro anos antes do Documento, ou se o editor original da versão a que ela se refirader sua permissão;

K. Em qualquer seção entitulada "Agradecimentos"ou "Dedicatórias", preservar o título da

14


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;

L. Preservar todas as Seções Invariantes do Documento, inalteradas em seus textos ou emseus títulos. Números de seção ou equivalentes não são considerados parte dos títulos da seção;

M. Apagar qualquer seção entitulada "Endossos". Tal sessão não pode ser incluída na VersãoModificada;

N. Não reentitular qualquer seção existente com o título "Endossos"ou com qualquer outrotítulo dado a uma Seção Invariante.

Se a Versão Modificada incluir novas seções iniciais ou apêndices que se qualifiquem comoSeções Secundárias e não contenham nenhum material copiado do Documento, você pode optarpor designar alguma ou todas aquelas seções como invariantes. Para fazer isso, adicione seustí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 - porexemplo, declarações de revisores ou de que o texto foi aprovado por uma organização como adefiniçã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 Textosde Capa na Versão Modificada. Somente uma passagem de Texto da Capa da Frente e uma deTexto 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 porvocê ou por acordo feito com alguma entidade para a qual você esteja agindo, você não podeadicionar um outro; mas você pode trocar o antigo, com permissão explícita do editor anterior queadicionou a passagem antiga.

O(s) autor(es) e editor(es) do Documento não dão permissão por esta Licença para que seusnomes sejam usados para publicidade ou para assegurar ou implicar endossamento de qualquerVersão Modificada.

COMBINANDO DOCUMENTOS

Você pode combinar o Documento com outros documentos publicados sob esta Licença, sobos 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 listetodas 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 InvariantesIdênticas com multiplas ocorrências podem ser substituídas por apenas uma cópia. Se houvermúltiplas Seções Invariantes com o mesmo nome mas com conteúdos distintos, faça o título de

15


cada seção único adicionando ao final do mesmo, em parênteses, o nome do autor ou editororigianl daquela seção, se for conhecido, ou um número que seja único. Faça o mesmo ajustenos títulos de seção na lista de Seções Invariantes nota de licença do trabalho combinado.

Na combinação, você precisa combinar quaisquer seções entituladas "Histórico"dos diver-sos documentos originais, formando uma seção entitulada "Histórico"; da mesma forma combinequaisquer seções entituladas "Agradecimentos", ou "Dedicatórias". Você precisa apagar todas asseções entituladas como "Endosso".

COLETÂNEAS DE DOCUMENTOS

Você pode fazer uma coletânea consitindo do Documento e outros documentos publicadossob esta Licença, e substituir as cópias individuais desta Licença nos vários documentos comuma única cópia incluida na coletânea, desde que você siga as regras desta Licença para cópiaexata de cada um dos Documentos em todos os outros aspectos.

Você pode extrair um único documento de tal coletânea, e distribuí-lo individualmente sobesta Licença, desde que você insira uma cópia desta Licença no documento extraído, e siga estaLicença em todos os outros aspectos relacionados à cópia exata daquele documento.

AGREGAÇÃO COM TRABALHOS INDEPENDENTES

Uma compilação do Documento ou derivados dele com outros trabalhos ou documentos se-parados e independentes, em um volume ou mídia de distribuição, não conta como uma Ver-são Modificada do Documento, desde que nenhum copyright de compilação seja reclamado pelacompilação. Tal compilação é chamada um "agregado", e esta Licença não se aplica aos outrostrabalhos auto-contidos compilados junto com o Documento, só por conta de terem sido assimcompilados, e eles não são trabalhos derivados do 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 Capado 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çõesdo Documento sob os termos da seção 4. A substituição de Seções Invariantes por traduçõesrequer uma permissão especial dos detentores do copyright das mesmas, mas você pode incluirtraduções de algumas ou de todas as Seções Invariantes em adição às versões orignais dessasSeçõ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


versão original em Inglês desta Licença, a versão original em Inglês prevalecerá.

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 direitossob esta Licença. Entretanto, terceiros que tenham recebido cópias, ou direitos de você sob estaLicença não terão suas licenças terminadas, tanto quanto esses terceiros permaneçam em totalacordo com esta Licença.

REVISÕES FUTURAS DESTA LICENÇA

A Free Software Foundation pode publicar novas versões revisadas da Licença de Documen-tação Livre GNU de tempos em tempos. Tais novas versões serão similares em espirito à versãopresente, mas podem diferir em detalhes ao abordarem novos porblemas e preocupações. Vejahttp://www.gnu.org/copyleft/.

A cada versão da Licença é dado um número de versão distinto. Se o Documento especificarque uma versão particular desta Licença "ou qualquer versão posterior"se aplica ao mesmo, vocêtem a opção de seguir os termos e condições daquela versão específica, ou de qualquer versãoposterior que tenha sido publicada (não como rascunho) pela Free Software Foundation. Se oDocumento não especificar um número de Versão desta Licença, você pode escolher qualquerversão já publicada (não como rascunho) pela Free Software Foundation.

ADENDO: Como usar esta Licença para seus documentos

Para usar esta Licença num documento que você escreveu, inclua uma cópia desta Licençano documento e ponha as seguintes notas de copyright e licenças logo após a página de título:

Copyright (c) ANO SEU NOME.É dada permissão para copiar, distribuir e/ou modificar este documento sob os termos da Licençade Documentação Livre GNU, Versão 1.1 ou qualquer versão posterior publicada pela Free Soft-ware Foundation; com as Seções Invariantes sendo LISTE SEUS TÍTULOS, com os Textos daCapa da Frente sendo LISTE, e com os Textos da Quarta-Capa sendo LISTE. Uma cópia da li-cença está inclusa na seção entitulada "Licença de Documentação Livre GNU".

Se você não tiver nenhuma Seção Invariante, escreva "sem Seções Invariantes"ao invés dedizer quais são invariantes. Se você não tiver Textos de Capa da Frente, escreva "sem Textos deCapa da Frente"ao invés de "com os Textos de Capa da Frente sendo LISTE"; o mesmo para osTextos 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


tal como a GNU General Public License, para permitir o seu uso em software livre.

18

Parte IV

Planejamento em desenvolvimento desistemas

19

Capítulo 1

Planejamento em desenvolvimento desistemas

Um software é muito mais que um programa de computador. É o resultado de um conjuntode atividades e ferramentas de planejamento, desenvolvimento e gerência, e o estudo e uso dasmelhores dessas atividades é conhecido como Engenharia de software.

20

Capítulo 2

Plano de ensino

2.1 Objetivo

Disponibilizar ao usuário conhecimentos acerca de planejamento de sistemas.

2.2 Público Alvo

Usuários finais ou novatos que desejam se iniciar na área de engenharia de software.

2.3 Pré-requisitos

Os usuários deverão ser, necessariamente, familiarizados com o padrão de modelagem UMLe possuir algum conhecimento em programação, além de ser desejavel o conhecimento de projetomodelado a objeto.

2.4 Descrição

O curso será realizado na modalidade Educação a Distância e utilizará a Plataforma Moodlecomo ferramenta de aprendizagem. O curso tem duração de uma semana e possui um conjuntode atividades (lições, fóruns, glossários, questionários e outros) que deverão ser executadas deacordo com as instruções fornecidas. O material didático estará disponível on-line de acordo comas datas pré-estabelecidas em cada tópico. Esse assunto é dinâmico e pode ser que algumacoisa de desatualize com o tempo.

2.5 Metodologia

O curso está dividido da seguinte maneira:

2.6 Cronograma

• Introdução;

21


• Práticas de planejamento - Visão geral;

• Práticas de planejamento;

• Introdução às disciplinas de um projeto;

• 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 menordo 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çõesquanto a da avaliação serão consideradas para a nota final. Todos os módulos ficarão visíveispara 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á serenviada 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:

• estudo das praticas mais corriqueiras em engenharia de software.

2.8 Avaliação

Toda a avaliação será feita on-line.Aspectos a serem considerados na avaliação:

• Iniciativa e autonomia no processo de aprendizagem e de produção de conhecimento;

• Capacidade de pesquisa e abordagem criativa na solução dos problemas apresentados.

Instrumentos de avaliação:

• Participação ativa nas atividades programadas.

• Avaliação ao final do curso.

• O participante fará várias avaliações referente ao conteúdo do curso. Para a aprovação eobtenção do certificado o participante deverá obter nota final maior ou igual a 6.0 de acordocom a fórmula abaixo:

• Nota Final = ((ML x 7) + (AF x 3)) / 10 = Média aritmética das lições

• AF = Avaliações

22


2.9 Bibliografia

Este curso foi inspirado nos slides de aula do professor da UnB Doutor Ricardo StarciariniPuttini da disciplina Metodologia de desenvolvimento de software ministrada no departamento deengenharia elétrica.

23

Capítulo 3

Introdução

3.1 Conceitos iniciais

Produto: um objeto é desenvolvido tendo em vista as necessidades do cliente (no caso, opróprio software). Nota: eventualmente no decorrer do curso pode ser usado como sinônimo dopróprio software.

Serviço: atividade realizada por mão-de-obra qualificada também tendo em vista alguma ne-cessidade específica.

Processo: seqüência de etapas pelo qual a produção de um produto ou serviço passa.

Projeto: é a prática que objetiva a criação de um serviço ou produto.

3.2 Exemplo de sistema de informação

Antes de entrarmos no fascinante mundo da engenharia de software, vamos à motivação paranosso curso: um sistema!!!! Podemos tomar como exemplo uma loja virtual. Atualmente já se tor-nou corriqueiro utilizar uma loja virtual, mas há duas gerações atrás... Imagine quão maravilhosopara uma pessoa que viveu no inicio do século passado é uma loja virtual: você se senta à frentede uma máquina, manipula-a e dentro de alguns dias tem um produto em casa. Esse exemplo éinteressante pois diversas atividades por trás desse ato de pedir um produto e ele chegar não sãoclaras para o usuário. Você fornece seu número de cartão de crédito mas por trás disso temos umoutro sistema (banco) que interage com o nosso. Ao pedir seu produto, outro sistema (correios)é acionado afim de entregá-lo em sua casa.

Um bom projetista deve conceber o produto levando em consideração a interação entre osdiversos sistemas, e ao mesmo tempo projetar o software de forma que essas interações pareçamo mais transparentes e naturais possíveis para o usuário.

24


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 quepossamos 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çõesa acerca da eficácia de modelos de engenharia de software podem vir à tona, com alguma razãoaté.

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áticabastante polêmica: como saber o que é certo ou errado num mundo tão complexo como o dehoje? 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 algumasquestõ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 douso do computador.

É de conhecimento de todos que atualmente atividades relacionadas ao desenvolvimento desistemas consistem em parte bem significativa do PIB das nações, principalmente daquelas ditasde primeiro mundo. Além do desenvolvimento, contudo, o que onera muito um software é suamanutenção, sobretudo para sistemas de vida longa. O planejamento no desenvolvimento de sis-temas tem como objetivo tornar o desenvolvimento e manutenção do software economicamenteviável.

3.4 Problemas e mitos

Falemos agora de alguns problemas muito comuns que envolvem a atividade de planejamento.

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ãoanterior é válida também no que diz respeito a estimativa de custos.

Outro problema freqüente é no que diz respeito à produtividade do pessoal de desenvolvi-mento, que usualmente não está no mesmo patamar da demanda pelos serviços por eles pres-tados. Como o que o cliente quer é sempre de certa forma vago, nunca se consegue estimarcom precisão a priori qual a carga de serviço que será demandada pelos profissionais da área dedesenvolvimento.

A qualidade de software também geralmente não é plenamente satisfeita, parâmetros consis-tentes de garantia de qualidade de software surgiram apenas recentemente.

25


Como dito anteriormente, a manutenção é bastante cara. Isso é conseqüência de um plane-jamento que não leva em conta a facilidade de manutenção. Isso deixa mais caro o processo defabricação de um software.

O pessoal pode falhar durante o projeto. Gerente sem background em software, falta detreinamento e principalmente resistência a mudanças aos fatores que devem ser evitados paraafugentar o fracasso do seu projeto.

Existem também um conjunto de lendas acerca do desenvolvimento de software que só ser-vem para desinformar as partes interessadas no projeto. Seria interessante analisar algumasdessas lendas.

"Se a equipe está com os prazos atrasados, é conveniente contratar mais programadores efacilmente tirar o atraso."Análise: contratar mais pessoas, à medida em que estas tem que serinseridas 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 detalhesvã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 noprojeto do software podem ser realizadas de forma tranqüila."Análise: não ha nada mais falso, seuma 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 primeiraentrega para o cliente.

"A qualidade do software só pode ser mensurada com o programa funcionando."Análise: oprograma é somente um item do software, que inclui diversos outros produtos durante a constru-ção e manutenção.

26

Capítulo 4

Práticas de planejamento - Visão geral

4.1 Definição de engenharia de software

Área do conhecimento que se usa de práticas de engenharia para produção sistemática eeconômica de um software confiável e que trabalhe de forma eficiente.

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 produtode maneira sistemática, ou seja, de acordo com o método. Isso é essencial em grandes projetosde 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 oproduto e depois pode-se vendê-lo em série. De forma geral, um software é feito sob medidapara determinado cliente: cada empresa tem suas necessidades e cabe ao projetista conceberum sistema que satisfaça-as da maneira mais eficiente possível, ainda que existam softwares deuso genérico vendidos em grande escala.

4.2 Componentes de um software

Os componentes de um software são:

• instruções: termo um pouco abstrato, relacionado com função e desempenho quando seexecuta;

• estrutura de dados: elemento responsável por organizar e manipular adequadamente ainformação nos programas;

• documentos: descrevem o uso dos programas.

27


4.3 Procedimentos e atributos de qualidade

Métodos: especificam detalhadamente como construir o software;

Ferramentas: auxílio automatizado aos métodos. Exemplo: ferramenta CASE Jude;

Procedimentos: execuções de cada método em uma determinada seqüência que ao finalproduzem certo produto;

Temos os seguintes atributos críticos de qualidade de software:

• Eficiência: o software deve otimizar os recursos do sistema afim de que não haja desperdí-cio;

• Utilidade: relativo à documentação e interface gráfica;

• Fácil manutenção: com o decorrer do projeto, o software deve evoluir de acordo com mu-danças no requisito;

• Dependência: um erro no software não deve causar prejuízos.

A prioridade desses atributos varia de produto para produto, cabendo ao projetista dentro docontexto do ambiente defini-las.

4.4 Etapas de engenharia de software

A engenharia de software pode ser dividida nessas áreas, independentemente do paradigmautilizado: definição, desenvolvimento e manutenção.

A definição está relacionada com "o quê"o software deve ser; aqui se encaixam práticascomo análise do sistema, análise de requisitos e planejamento de projeto.

Análise do sistema: estabelece a função de cada componente num sistema, atribuindo aofinal, a função que o software realizará.

Planejamento do projeto de software: análise de recursos, custos, riscos além do estabe-lecimento do trabalho da equipe.

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 quefoi 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.

Projeto de software: busca reproduzir um modelo para o produto e descrever a arquitetura,as características da interface, além de algoritmos e estruturas de dados.

28


Nota: casualmente, o termo projeto também pode ser usado para denominar a engenharia desoftware 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:

• corretiva: correção de defeitos;

• adaptativa: eventuais mudanças no ambiente exigem esse tipo de manutenção;

• extensiva: aumenta as funcionalidades do produto de acordo com as que foram previa-mente estabelecidas.

Além das etapas listadas abaixo, paralelamente deve-se executar atividades de proteção (con-trole) do projeto:

• revisão: realizada ao término de cada etapa afim de controle de qualidade;

• documentação: elaboração de documentos que expressam informações completas do pro-duto, com objetivo de facilitar o seu uso posterior;

• controle de versão: controla as mudanças ocorridas no software ao longo do projeto.

4.5 Melhores práticas

A essa altura do curso o aluno já deve ter se dado conta da complexidade da atividade deengenharia de software, muito além da programação. Destarte, veremos alguns métodos, co-nhecidos como melhores práticas que auxiliam a atividade do engenheiro de software. Existemoutras práticas melhores, mas julga-se que o conhecimento destas já é interessante para umcurso introdutório.

4.5.1 Gerência de riscos:

Riscos: algo que pode afetar de forma negativa o projeto, sempre existe a possibilidade deocorrer.

Alguns exemplos: falta de pessoal bem-treinado, atrito entre a equipe, não atendimento aosrequisitos mínimos de desempenho dentre diversos tipos de riscos.

29


Como em toda área de engenharia, deve-se dosar a questão de custo-benefício: a gerênciade riscos também gera custos, ela só deve ser utilizada se as perdas geradas pelos riscos envol-vidos superam os custos com gerencia de riscos.

A primeira etapa da gerência de riscos é a avaliação, onde se procura a identificação, análisee priorização dos riscos envolvidos. Feito isso, deve ser realizado o controle: planeja-se comoa gerência de riscos deve agir; depois realiza-se o monitoramento de riscos e quando estesocorrem, a solução dos riscos. Tente imaginar novos riscos que um projeto pode apresentar evisualizar no contexto do projeto como a gerência de riscos funciona de forma prática.

4.5.2 Gerência de riscos

Riscos: algo que pode afetar de forma negativa o projeto, sempre existe a possibilidade deocorrer.

Alguns exemplos: falta de pessoal bem-treinado, atrito entre a equipe, não atendimento aosrequisitos mínimos de desempenho dentre diversos tipos de riscos.

Como em toda área de engenharia, deve-se dosar a questão de custo-benefício: a gerênciade riscos também gera custos, ela só deve ser utilizada se as perdas geradas pelos riscos envol-vidos superam os custos com gerencia de riscos.

A primeira etapa da gerência de riscos é a avaliação, onde se procura a identificação, análisee priorização dos riscos envolvidos. Feito isso, deve ser realizado o controle: planeja-se comoa gerência de riscos deve agir; depois realiza-se o monitoramento de riscos e quando estesocorrem, a solução dos riscos. Tente imaginar novos riscos que um projeto pode apresentar evisualizar no contexto do projeto como a gerência de riscos funciona de forma prática.

4.5.3 Gerência de configuração

Artefatos: são elementos produzidos ou consumidos em uma etapa do projeto, necessaria-mente, não tangíveis.

Exemplos: código-fonte, documento de requisitos,material de treinamento, etc.Tipicamente os artefatos são modificados durante o projeto e à gerência de configuração cabe

o controle dessas mudanças. Por exemplo, identificar a última versão de um programa, evitar umamodificação não autorizada, controlar a situação em que há duas solicitações concorrentes deatualização no programa, entre outras situações são exemplos que ilustram a necessidade dagerencia de configuração.

É uma atividade complexa, pois está relacionada com diversos outros mecanismos, comocontrole de versão, mapeamento das modificações ocorridas, controle de acesso de artefatos eidentificação de mudanças em artefatos entre outros.

Na prática, é realizada da seguinte maneira: um artefato para ser alterado é submetido a umaoperação conhecida como "check-out". Uma vez aí, somente uma pessoa pode alterá-lo. É comose momentaneamente o artefato fosse retirado do sistema, numa comparação bem grosseira.Uma vez alterado, uma nova versão do artefato é produzida e agora ele volta ao sistema atravésde uma operação "check-in".

30


4.5.4 Gerência de requisitos

Está relacionado com o recolhimento, análise e gerência das modificações dos requisitos. Po-dem ocorrer problemas no contexto dos requisitos, tais como mal-entendimento, documentaçãoincorreta e controle impreciso das modificações de requisitos. A gerência se faz necessária nosentido em que naturalmente ocorrem mudanças de requisitos ao longo do projeto, mudanças es-sas geralmente inesperadas e que afetam o palnejamento, desta forma deve-se estar preparadopara elas. A forma com que essa gerência é definida é relativa e depende do cliente, pois ele vaiser a principal responsável pela mudança de requisitos.

4.5.5 Gerência com uso de métricas

Usar métricas é importante pois é o suporte que serve para compararmos nosso projeto comalgo.Se não temos com o que compará-lo, ficamos de certa forma sem rumo, pois não temosnoção do que nosso projeto deve melhorar. Assim, podemos usar métricas de acordo com doisparâmetros. O primeiro é a nível de processo: aqui se analisa produtividade, qualidade e efici-ência na remoção de bugs. Também pode-se avaliar a nível de produto: tamanho, complexidadedo código e funcionalidade. Tendo esses seis elementos como base já é possível ter uma melhornoção dos rumos de seu projeto.

31

Capítulo 5

Práticas de planejamento

5.1 Planejamento de software

Uma etapa de suma importância da construção do software é a de planejamento. Sem essaetapa, o termo engenharia de software perde totalmente o sentido, pois o projeto se torna de-sordenado e sem objetivos claros. As principais partes interessadas nessa etapa são o gerentede negócio, o gerente de software e a equipe de desenvolvimento. Deve abarcar o resumo doprojeto, planejamento, monitoração e perfis dos profissionais.

No resumo , deve-se estabelecer o nome do projeto, o gerente, a data de início e términodo projeto, os objetivos do projeto, calendário de pagamentos do cliente, compromissos firmadosjunto ao cliente entre outras coisas dessa tipo.

No planejamento busca-se estimar os critérios e esforços a serem adotados pela equipe, ociclo de vida, os planos de treinamento, o plano de gerenciamento de risco, discutir o ambientede desenvolvimento, os desvios em relação ao projeto original considerados aceitáveis, dentreoutros.

No que concerne à monitoração , deve-se designar parte da equipe como responsável poressa etapa, descrever os procedimentos de monitoração, os aspectos monitorados e a monitora-ção de retorno do cliente.

As atividades de monitoração são: aplicar os mecanismos de monitoração, executar o projeto,capturar dados e daí analisá-los e realizar previsões. Dentre os dados que podemos analisar,lista-se esforço, defeitos e tamanho. Tomemos o dado "esforço"como exemplo; submete-secada empregado a um relatório semanal, que deve ser aprovado por um superior e não pode sermodificado após ser aprovado. Nesse relatório deve constar um código identificador do programa,do método e da atividade, as horas gastas e uma lista de atividades (diferenciando as planejadasdas inesperadas).

Outro dado imprescindível que deve ser monitorado é os defeitos . Num eventual relatóriosobre este dado, deve aparecer o código do projeto no qual o defeito foi observado, a descriçãoprecisa 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


Os seguintes estágios do projeto são os mais propensos a encontrar defeitos, e a maioriadeles são revisões por motivos óbvios: nas revisões de especificação de requisitos, plano doprojeto, do projeto em si, do plano de gerência de configuração, do código e também na fase detestes.

Quando planejar os perfis dos profissionais deve-se relacionar cada membro, segundo umahierarquia estabelecida, atribuindo a cada um responsabilidades e um período específico de par-ticipação no projeto.

5.2 Modelo de processos

Os processos devem ser modelados para que o gerenciamento se torne viável, e esse modelodepende de fatores como a natureza do projeto, ferramentas que serão usadas e produtos quenecessitam ser entregues.

Os modelos são fundamentais: distinguem o software profissional de um programa de compu-tador mais "amador", pois neste último não há distinção entre especificação, projeto e codificação.Além disso, por maior que seja a boa-vontade das partes interessadas, nunca as especificaçõessão completas: nesse sentido aparece a importância dos modelos de processo na engenharia desoftware.

Antes de seguirmos adiante, vamos exemplificar alguns processos:

• fundamentais: processo de aquisição, fornecimento, desenvolvimento, operação e manu-tenção;

• apoio: documentação, gerência de configuração, garantia de qualidade, verificação, valida-ção, revisão conjunta, auditoria e resolução de problemas;

• organizacionais: gerencia, infra-estrutura, melhoria e treinamento.

Funções de um processo:

• oferecer padrão para realização de projetos;

• definir artefatos;

• sugerir práticas de documentação e diretrizes para realização de trabalhos.

Benefícios de um processo bem descrito:

• ajuda na comunicação entre a equipe;

• estabelece funções bem definidas para cada participante;

• torna o projeto mais inteligível por parte da gerência;

• permite que o próprio processo seja reutilizável e que possa evoluir com o passar do tempo;

• permite otimizar o treinamento.

33


Anteriormente em nosso curso já nos deparamos com a definição de artefato. Aqui esseconceito volta, pois no decorrer do processo os artefatos são modificados e criados ao longo doprocesso. 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 ouplanos de alocação da equipe.

Durante os processos são estabelecidos perfis de acordo com habilidades de cada membroda 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 umaseja 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 maisprevisã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 quaisse podem configurar processos, de acordo com o tamanho e nível de treinamento da equipe e daimportância da aplicação. Essa configuração é regida por um guia de configuração, que sugereopções, atributos e alternativas de configuração.

Uma prática saúdavel da engenharia de software consiste em manter uma base de dadospara cada processo. A engenharia de software só atinge sua excelência com a prática, portantoo projetista deve ter uma base de dados com informações de cada projeto, para que este sejaanalisado 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 documentosque foram fonte de pesquisa.

Informações gerais: tamanho da equipe, ferramentas, datas, esforço, riscos.

Esforços e defeitos: lista de esforços e defeitos separados por fases do projeto.

Tamanho: tamanho total do código (número de linhas).

Relatório de erros e acertos: podem ser escritos em subdivisões tais como: recursoshumanos, especificação de requisitos, ferramentas, projeto, teste, revisões, qualidade, gerên-cia,metodologia dentre outras possíveis.

Processos pessoais (PSP-personal software process): estabelecem ações a serem reali-zadas por cada pessoa, que vão realizando estas ações em pequenos programas que gradual-mente são inseridos no processo como um todo.

34


5.3 Processo de desenvolvimento

Este processo orienta os desenvolvedores a realizar atividades com o intuito de desenvolverum software. Aqui entra as etapas de análise de requisitos, projeto e codificação.

Tradicionalmente, este processo traz as seguintes características: organização hierárquica ecentralizada, trabalho em equipe, existência de um ciclo de vida, necessidade de uma adoçãosistemática de processos, ou seja, características que seguem aquilo que estamos estudando aolongo de nosso curso.

Por ser uma área extensa, costuma-se subdividi-la em diversas subáreas: engenharia derequisitos, especificação, projetos, testes, gerência de c onfiguração , ou seja, aquelas áreasque já vimos um pouco a respeito.

Os processos de desenvolvimento são considerados leves se são mais flexíveis, possuempoucas regras, poucos desenvolvedores com comunicação oral e mesmo ambiente físico de tra-balho. Exemplo: XP (extreme programming). Esse tipo de processo não é recomendável parasistemas de grande porte ou para sistemas desenvolvidos por equipes virtuais (fisicamente dis-tantes).

É interessante no desenvolvimento realizar as tarefas de forma dinâmica, e isto é obtido atra-vés de práticas bem conhecidas da administração de empresas: agir de forma pró-ativa, comu-nicação contínua entre a equipe e o cliente entre outras coisas.

Para o caso em que esteja se desenvolvendo software aberto, deve-se levar em conta que osdesenvolvedores 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 ouso do software após este ficar pronto. A gerência aqui assume cores participativas , cada umtoma atividades por conta própria para realizar. As ferramentas e processos usados também nãosão definidas por uma só pessoa, várias partes participam da decisão. O foco é na entrega nomenor tempo possível, com posteriores melhorias incrementais no produto, incentivadas pelo"feedback "dado pelos usuários. Outra característica interessante é que em projetos de softwareaberto os próprios desenvolvedores usufruem do software final . A maioria das distribuiçõessã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.

5.4 Ciclos de vida

A vida de um software geralmente é dividida em ciclos , o primeiro para desenvolvimento e osdemais para manutenção. Ao final de cada ciclo obtemos uma versão do produto. O ciclo podeser seqüencial ou iterativo.

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. Paracada ciclo, existem também fases, que resultam em modelos e documentação: concepção, ela-boração, construção e transição.

35


O modelo seqüencial é o clássico da engenharia de software. Nesse tipo de ciclo, as ativida-des de engenharia de software são executadas passo-a-passo , uma etapa em seguida da outra,iniciando na análise de requisitos e findando-se com a verificação do produto já desenvolvido.No final de cada etapa, há uma verificação dos artefatos produzidos: caso julgue-se satisfatório,passa-se para a seguinte, caso contrário, deve-se refinar mais essa etapa.

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ãodeterminados. Essa abordagem para projetos grandes via de regra se mostra mais eficaz, poiscom o início do desenvolvimento tem-se uma idéia mais madura de quais requisitos o softwaredeve atender, do foco do projeto e arquitetura utilizada. Os riscos são catalogados logo no começodo projeto e as perdas estão relacionadas apenas com o custo de cada iteração. Se o modeloutilizado fosse o seqüencial, mudanças nos requisitos poderiam acarretar em mudanças trágicaspara o projeto, o que não ocorre no caso iterativo, que não só prevê como "pede"mudanças nosrequisitos. Um fato curioso é que se se julgar pertinente, pode-se iniciar uma iteração sem que aanterior 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 bemplanejadas 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 estadodessa ú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émuma 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 foconos 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. Comona primeira iteração toda a base do produto já foi feita, cada iteração adicional costuma gastarmenos tempo que a anterior, por isso o modelo é conhecido como espiral. Cabe um alerta: seutilizar o modelo espiral, o analista de riscos deve ser extremamente eficiente, pois é isso quesustenta esse modelo.

5.5 Técnicas de quarta geração

A motivação dessas técnicas é tentar especificar um software a um computador em umalinguagem tão próxima da humana quanto possível, ainda que isso esteja longe do ideal. Aespecificação do software deve ser realizada em uma linguagem de alto nível, e disso nasceo código fonte do software. Para conceber um ambiente que usa técnicas da quarta geraçãodevemos nos valer das seguintes ferramentas: linguagens não procedimentais para manipulaçãode banco de dados, definição das telas, geração de códigos, boa capacidade gráfica, suporte aplanilhas eletrônicas, etc. A expectativa ao se usar esse conjunto de técnicas é ganho em tempoe produtividade.

36

Capítulo 6

Introdução às disciplinas de um projeto

6.1 Arquitetura

É a arquitetura que dita os elementos mais relevantes de um sistema, muito útil para entendere lidar com o sistema. Os rumos da arquitetura são ditados por elementos como o software dosistema, 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 estabelecimentoda arquitetura. Após se estabelecer a arquitetura, o restante dos casos de uso devem ser defato implementados na fase de construção, e uma vez implementados, a arquitetura deve seraprimorada.

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 apró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: listade requisitos, primeiras versões dos modelos de caso de uso, análise, projeto e arquitetura, listaparcial 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 casode uso, estabelecer a arquitetura e estabelecer estratégias para controle de riscos.

37


Dentre as ações relacionadas com essa etapa, lista-se planejamento, concluir o restante daequipe e adequar o ambiente de desenvolvimento.

Ao fim dessa fase, deve-se atingir uma nova versão dos modelos, uma arquitetura básica bemsó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 coma arquitetura, aprimorar modelos de análise, projeto e implementação, detalhar os últimos casosde uso, integrar e testar o sistema.

Deve haver um planejamento da construção de acordo com o fim da elaboração e critériossubjetivos para avaliação desta fase. Esses critérios devem englobar os seguintes resultados:plano visando a última fase, software já executável, modelos, arquitetura, manual para os usuáriose atualização do plano de negócios.

6.2.4 Transição

A idéia por trás dessa fase é tomar o software executável da fase anterior, fazer dele umaversã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 softwarecom 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.

6.3 Disciplinas de um projeto

Consiste nas atividades sistemáticas que devem ser realizadas no decorrer das três fasesvistas anteriormente. Espera-se que as fases sejam mais contextualizadas a partir do estudo dasdisciplinas. São elas:

• Coleta e análise de requisitos;

• Projeto;

• Implementação;

• Teste.

Veremos cada uma delas separadamente.

38


6.4 Coleta de requisitos

Consiste, basicamente, em descobrir o que o cliente espera que seja desenvolvido. Aparecenas três primeiras fases. Requisitos são elementos intangíveis que determinam como o sistemadeve responder aos usuários. Não englobam aspectos do projeto. O foco é em determinar o quêprecisa ser feito.

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.

Na concepção, a maioria dos casos de uso são catalogados, e os primordiais detalhados. Naelaboração a preocupação é com os casos de uso a nível de arquitetura e na construção, osrestantes casos de uso são detalhados.

Fatores que dificultam a coleta de requisitos: mudanças freqüentes nas regras de negócio,no pessoal e na tecnologia.

Os erros mais comuns na especificação são: incluir aspectos do projeto, detalhamento decomo se deve implementar algo, uso de vocabulário técnico e requisitos vagos.

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 fimde se catalogar os requisitos da forma mais eficiente possível.

Com a coleta de requisitos, é interessante que se gere os seguintes artefatos : modelos decaso de uso, arquitetura (bem primitiva), glossário e um protótipo da interface com o usuário.

Modelos de caso de uso: é o principal artefato gerado aqui. Deve ser gerado levando emconta 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 parapadronizar uso de conceitos em documentos posteriores.

Protótipo de interface com usuário: facilita a descrição dos relacionamentos entre usuárioe sistema, é como um complemento para os casos de uso, uma espécie de especificação deinterface gráfica.

Essa disciplina apresenta os seguintes perfis :

• especificador do caso de uso: trabalhando em contato com o usuário, descreve minuciosa-mente os casos de uso;

• projetista das interfaces: define formato das interfaces gráficas, responsável por conceberalguns protótipos de caso de uso;

• arquiteto: concebe arquitetura para os casos de uso.

39


6.5 Análise de requisitos

Nesta disciplina, busca-se analisar os requisitos com uma profundidade maior, e estes sãotratados de forma a tentar conceber a estrutura do sistema.

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 linguagemcorriqueira pode ter feito com que algumas características do sistemas não tenham sido bem de-talhadas.

A seguir acompanhamos a descrição de alguns artefatos gerados na análise:

Modelo

Busca permitir aos desenvolvedores, através de linguagem usada por eles, compreendercomo implementar o software, sob o ponto de vista interno do sistema. É um artefato usadono projeto e no desenvolvimento e estabelece como se implementarão os casos de uso. Pode-seoptar por não produzir este artefato, desde que se adote uma linguagem extremamente precisanos casos de uso.

Classe

Artefato também produzido no projeto, aqui ela adquire características mais conceituais. Buscarepresentar os subsistemas no âmbito do modelo, voltando-se para os requisitos funcionais.

Realização dos casos de uso

Este artefato descreve, através de texto e diagramas, como um caso de uso é implementadopor 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 asprincipais classes e as mais primordiais realizações dos casos de uso.

Perfis da análise de requisitos:

• 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 epela relevância dos diagramas que descrevem e realizam os casos de uso.

• engenheiro de componentes: é o perfil cuja função é descrever o relacionamento entre asclasses, de forma a garantir que este relacionamento preserve a determinação dos casosde uso.

40

Capítulo 7

Disciplinas de um projeto

7.1 Projeto

Nesta disciplina, os requisitos devem ser aprofundados, objetivando principalmente "prepararo terreno"para a implementação. Aqui deve-se ter sempre em mente as restrições devido àstecnologias usadas, buscar que a captura dos requisitos deva ser feita de modo à implementaçãonã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 quebuscam atingir os objetivos acima.

Subsistemas de projeto: constituídos por subsistemas como classes e interfaces, ordenamos artefatos de um modelo.

Modelo de implantação: faz o mapeamento entre o software e o hardware. Vale-se de nóspara representar computadores e de links entre esses nós para representar canais de comunica-ção. Busca também descrever configurações de teste e simulação.

Descrição da arquitetura: Os artefatos descritos na arquitetura a nível de projeto são: inter-face de subsistemas, relacionamento entre interfaces, classes, funcionalidades críticas e modelode implantação.

7.1.2 Perfis

arquiteto: verifica consistência dos modelos de acordo com o que foi feito nos casos de usoe análise;

engenheiro de caso de uso, engenheiro de componentes.

De forma suscinta, as atividades relacionadas a essa disciplina são: projeto de caso deuso, classe, subsistema e arquitetura, projetos esses a nív el de orientação a objeto.

41


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.

Tipos de componentes: executáveis, tabelas, bibliotecas, arquivos.

Componentes são artefatos.

Visão geral da disciplina: implementa classes do projeto, realiza testes de cada unidade decomponente, desenvolve programas executáveis pela integração de componentes.

Artefatos:

• modelo de implementação: baseado em componentes, descreve relações de dependênciaentre eles;

• descrição da arquitetura: decompõe modelo de implementação em subsistemas, compo-nentes e relacionamentos;

• subsistemas: responsáveis por organizar artefatos do modelo de implementação, suas fun-cionalidades vem à tona por meio de interfaces.

Perfis:

• arquiteto: mapeia os componentes em nós e verifica se o modelo de implementação estácorreto;

• engenheiro de componentes: responsável por manter íntegro cada subsistema e manter ocódigo dos componentes;

• integrador: o responsável pelo planejamento das interações a nível de análise orientada aobjeto.

Vejamos algumas atividades típicas desta disciplina:

• integração do sistema: através de um planejamento, integra a versão do software queemerge da implementação;

• implementação de elementos: implementa-se componentes, classes e interfaces;

• implementação de subsistemas: implementa-se os subsistemas certificando-se de que oplano de integração seja satisfeito;

• testes das unidades: testa-se cada componente do sistema, e avalia-se o resultado destestestes.

42


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 emque contexto acontecem estes testes;

• caso de teste: descreve como testar , especificado de antemão o que deve ser testado;

• procedimento de teste: como colocar em prática os casos de teste;

• componentes de teste: automatiza os procedimentos de teste;

• plano de teste: descreve estratégias de teste com uso de cronogramas;

• defeito: artefato que indica problemas no software, consta de algo que não é normal nosistema;

• avaliação de teste: análise dos testes.

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 testese é ele o responsável pelos procedimentos e casos de teste;

• engenheiro de componente: cuida dos componentes de teste;

• testador: existem dois tipos

• 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 funcionamentointerno;

• testador de integração: é ele que realiza os testes do funcionamneto interno do sistema, ostestes de integração.

Durante a análise de teste, eventualmente podemos adotar métricas para avaliar a qualidadedos testes que foram feitos. Além disso, devemos comparar se os resultados obtidos estão deacordo com o plano de teste.

43


7.4 Protótipo

Usados quando se quer um modelo do sistema, geralmente em casos onde o cliente defineo 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, poremsempre 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 sedenomina de refinamento de requisitos.

Todavia, cautela deve ser adotada com a estratégia do uso de protótipos pois podemos vir ater 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 entenderque 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 naqualidade, adotando estrategias que valem para prototipos no software final.

44

Education

Planejamento em desenvolvimento_de_sistemas