Padrões_Desenvolvimento

Padrões de
Desenvolvimento
Wagner Zaparoli
wzaparoli@gmail.com

Padrões de Desenvolvimento 2
Agenda

Parte 1 – Aspectos Teóricos

Fundamentos

Abrangência
Prover
Comunicação
Base
Desenvolvimento
Base
Manutenção
Base
Certificações
Orientação
Usuário
Base
Gestão
Padrões e
Documentação

Questões
• O que criar?
• Como manter?
• Como recuperar?
• Onde guardar?
• Como criar?
• Quando criar?

Classificação*
*
Sommerville, 2010
• Documentação do Processo: registra o processo de desenvolvimento e
manutenção, como cronogramas, atas de reunião, e-mails, padrões e
metodologia.
• Documentação do Produto: descreve o produto que está sendo desenvolvido,
sob o ponto de vista dos engenheiros de software e dos usuários.

Processo
• Planos, estimativas e cronogramas: são normalmente produzidos por
gestores para prever e controlar o processo de desenvolvimento do software.
• Relatórios: são utilizados para descrever como os recursos estarão sendo
utilizados durante o processo.
• Padrões: detalha um conjunto de regras que tratam de como o processo
deve ser implementado. Podem ter origem organizacional, nacional ou
internacional.
• Especificações técnicas: descreve as estratégias de implementação,
problemas já identificados, e as razões para as decisões tomadas no projeto,
entre outras características.
• Mensagens, memorandos: registra os detalhes da comunicação diária
entre gestores e desenvolvedores.

Produto
• Usuário final: tem por objetivo apresentar o sistema, suas
funcionalidades, facilidades de uso, mensagens de erros e
respectivas ações.
• Administrador do sistema: detalha o modo de instalação do
software, os principais arquivos e requisitos mínimos de hardware, e
como iniciar o sistema, deixando-o disponível para uso.
• Sistema: apresenta todos os detalhes da criação do software (ciclo
de vida), desde os requisitos até o plano de implantação e aceite
final. Indicado principalmente para a equipe técnica que vai
desenvolver e manter o software.

Criação de
Documentos

Drops da Criação
Estudo de
Viabilidades
Especificação
Telas e
Relatórios
Diagrama de
Casos de
Uso
Especificação
de Erros
Especificação
Casos de
Teste
Plano de
Implantação
Especificação
Integração
Modelo Físico
de Dados
Lista da
Equipe
Técnica
Termo de
Aceite Cliente
Diagrama de
Classes
Manual do
Sistema
Manual de
Treinamento
Planejamento
Testes
Desenho
Lógico
Arquitetura
Especificação
Atributos
Especificação
dos Padrões
Especificação
de Métodos
Modelo
Conceitual de
Dados
Especificação
de Requisitos
Atas de
Reunião
E-mails
Memorandos
Relatório
Mudanças de
Escopo
Relatório
Gerência de
Risco
Matriz de
Rastreabilid
ade
Controle de
Fábrica de
Software
Cronograma

Pós-desenvolvimento
Desenvolvimento
Pré-desenvolvimento
Estudo Preliminar
ProjetoAnáliseConcepção
Construção Teste/Docum. Homologação Implantação
Planejamento
G
E
S
T
Ã
O
Manutenção
Organizando a Criação (o que/quando)

Pré-desenvolvimento
Estudo Preliminar
 Resumo das funcionalidades (nível de complexidade, estimativa esforço,
especialidade técnica);
 Restrições, Benefícios e Riscos (impacto, probabilidade, ações de mitigação e
contingenciais);
 Resumo das integrações;
 Lista de necessidades de hardware/software para auxiliar o desenvolvimento;
Estimativa de esforço de gestão;
 Estimativa de custos;
 Relação custo/benefício  viabilidade.

Desenvolvimento
Planejamento
 Proposta de desenvolvimento aprovada;
 Lista da equipe técnica (nome, e-mail, telefones);
 Papéis e responsabilidades de cada membro da equipe;
 Especificação do ambiente de desenvolvimento;
 Cronograma.

Desenvolvimento
Concepção
 Especificação de requisitos;
 Modelo conceitual de dados;
 Desenho conceitual da arquitetura;
 Aceite do cliente.

Desenvolvimento
Análise
 Diagrama de casos de uso;
 Especificação de casos de uso;
 Especificação das integrações;
 Especificação dos erros e respectivos tratamentos;
 Modelo lógico de dados;
 Diagrama de classes;
 Desenho lógico da arquitetura;

Desenvolvimento
Projeto
 Especificação das classes;
 Especificação dos métodos;
 Especificação dos atributos;
 Modelo físico de dados;
 Especificação de telas/relatórios;
 Planejamento dos testes de construção;
 Desenho físico da arquitetura;

Desenvolvimento
Construção
 Estrutura física do banco de dados;
 Relatório de carga inicial de dados para homologação;
 Código-fonte (documentado);
 Especificação dos casos de testes unitários/integração;
 Evidência da realização dos testes unitários/integração;
 Especificação dos casos de testes sistema/regressão.

Desenvolvimento
Teste/Docum.
 Evidência da realização dos testes sistema/regressão;
 Lista de problemas evidenciados;
 Manuais (treinamento, usuário, sistema).

Desenvolvimento
Homologação
 Evidências do teste de aceitação;
 Planejamento do teste de produção;
 Evidências da realização do treinamento (lista de presença).

Desenvolvimento
Implantação
 Lista de rotinas de produção;
 Catálogo da infra-estrutura disponível;
 Relatório de inspeção das cargas efetuadas;
 Evidências da realização do teste de produção;
 Termo de aceite assinado.

Pós-desenvolvimento
Manutenção
 Especificação dos requisitos de manutenção;
 Relatório de análise de impactos, riscos, restrições, esforço, custos e benefícios;
 Lista de recursos (hw/sw/humanos);
 Plano de testes da manutenção;
 Evidências de atualização da documentação legada;
 Código-fonte atualizado;
 Evidências da realização dos testes de manutenção;
 Termo de aceite assinado.

 Atas de reunião;
 Relatório de controle de mudanças de escopo;
 Relatório de controle de riscos;
 Relatório de controle do acompanhamento (cronograma);
 Relatório de controle de entregas (validações clientes, pacotes para
fábrica, produto para homologação/produção);
 Evidências de controle da comunicação;
 Evidências de controle da qualidade (relatórios de inspeção);
 Evidências de controle de recursos/custos.
G
E
S
T
Ã
O

Organizando a Criação (como)
Pessoas
Metodologia
Tecnologia
Qualidade

Pessoas
• Quem faz:
 De acordo com a natureza do documento, os seus criadores
podem assumir diferentes perfis, embora grande parte da criação
seja responsabilidade da equipe técnica que desenvolve o software.
 A questão a ser refletida aqui é a capacidade e competência que
esse responsável tem em criar um documento com qualidade e que
vai ser de fato útil em seus objetivos.
• Quem usa:
 Analogamente à elaboração, os usuários do documento também
podem assumir perfis variados, desde o analista de banco de
dados, que recebe os requisitos de software e tem de transformá-
los em modelo de dados, até o cliente final, que recebe um manual
e deve operar o sistema;
 É importante que exista um protocolo de sincronismo
estabelecido entre o documento e seu leitor, que pode ser feito
através de uma descrição contida no próprio documento, ou mesmo
um treinamento básico que esclareça os detalhes.

Metodologia
 Estrutura: capa, capítulos/seções, índice e glossário;
 Estilo de escrita: construção verbal, gramática, tamanho de
sentenças e parágrafos, prolixidade, precisão e objetividade.
 Inspeção: revisão formal do documento sob vários pontos de vista,
como o sintático, semântico, conformidade com padrões, conformidade
com o negócio, etc.;
 Padrões
 Processo: orienta a produção do documento;
 Produto: governa a organização e a estrutura do documento;
 Protocolo de troca: descreve como o documento deve ser
produzido para permitir e facilitar a sua troca entre equipes,
sistemas e organizações;
 Produção
 Criação: entrada inicial das informações no documento;
 Revisão: melhora do texto, levando-se em consideração a
pontuação, erros gramaticais e redundâncias;
 Produção: preparação do documento para uma impressão
profissional.

Tecnologia
• Documentos textuais: incorporam em seu conteúdo, grande parte de
texto, como manuais, especificações e relatórios. Editores de texto,
hypertexto e imagem, ferramentas de prototipagem, ferramentas CASE*;
• Diagramas: abarcam diagramas de diversas naturezas, como os
definidos pela análise estruturada ou pela UML. Editores de texto,
ferramentas CASE, editores de diagramas.
• Artefato de código: referenciam os códigos-fonte (programas) de um
software. Editores, compiladores, analisadores (de programas),
depuradores, geradores de códigos, reengenharia de programas,
ferramentas de testes.
*
ISO/IEC 14102

Dicas
• Edição
 Utilize verbos na forma ativa ao invés da passiva – você deve ver um botão ..., um botão
será mostrado;
 Utilize construções gramaticais e ortografia corretas;
 Não utilize sentenças grandes para apresentar diferentes fatos;
 Mantenha parágrafos curtos;
 Não seja prolixo; seja preciso;
 Se a descrição estiver complexa, refaça-a;
 Faça uso de tópicos para organizar melhor o texto;
 Não faça referências baseadas somente nos rótulos – descreva-as simplificadamente;
• Processo
 Defina antecipadamente o processo de criação dos documentos, citando as entradas, as
saídas e as responsabilidades;
 Insira nesse processo, atividades de inspeção;

Dicas
• Padrões
 Para identificação;
 Para estruturação;
 Para apresentação;
 Para atualização.
• IEEE
 Documentos devem ser produzidos em mídias e formatos diversos, de acordo com a
natureza de seus usuários;
 Devem conter informação de como imprimir;
 Como usuários podem não distinguir cores, é importante que haja exemplos;
 Avisos, advertências e observações devem ser feitas em um formato consistente, que o
destaque do resto do texto.
 Ilustração e texto que o referencie devem aparecer próximos um do outro.

Dicas
Veja documento
Checklist para Avaliação da
Documentação

Pontos Chaves
 A documentação de software é usada para descrever o sistema a seus usuários e aos
engenheiros de software, os quais são responsáveis por desenvolver, manter e usar o sistema.
 Documentação com diferentes níveis de detalhes deveriam ser produzidos para usuários de
diferentes tipos.
 Métodos ágeis tendem a documentar pouco. Entretanto, independente do método de
desenvolvimento, aos menos os requisitos e a arquitetura deveriam ser documentados.
 A qualidade dos documentos é item fundamental quando eles são utlizados em larga escala.
Estruturá-los de forma adequada, com uma linguagem simples e clara são aspectos bem vindos.
 Padrões em documentação é requisito importante. Eles devem definir como os documentos
serão produzidos, quais características de produto utilizar, como devem ser organizados e como
devem ser trocados.
 Sistemas de gerenciamento de documentos devem ser utilizados em sistemas de grande portes
para que se assegure que a documentação será mantida e terá fácil acesso.

Sugestões Bibliográficas
• Sommerville, Ian. Software Engineering. 8th Edition. Addison-. Wesley.
• Pressman, R. S., Engenharia de Software. 5. ed. São Paulo: Makron Books,
2002.
• IEEE, 1997. IEEE Standard for Software User Documentation, IEEE Std1063-
1987. New Yourk: Institute of Electrical and Electronics Engineers.
• IEEE, 2001. Draft Standard for Software User Documentation, IEEE
Std1063/D5.1.2001. New Yourk: Institute of Electrical and Electronics
Engineers.
• IEEE Computer Society. Swebok – Guide to the Software Engineering Body
of Knowledge, 2004.
• ROCHA, A. R. C. (Org.) ; MALDONADO, J. C. (Org.) ; WEBER, K. C. (Org.) .
Qualidade de Software - Teoria e Prática. 1. ed. São Paulo: Prentice Hall,

Padrões_Desenvolvimento

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (11)

Semelhante a Padrões_Desenvolvimento

Semelhante a Padrões_Desenvolvimento (20)

Mais de Wagner Zaparoli

Mais de Wagner Zaparoli (10)

Padrões_Desenvolvimento