Boas práticas no Desenvolvimento de Software

Danielle Teixeira

Danielle Teixeira

• Engenheira da Computação
  • Esp. Banco de Dados
  • Esp. Desenvolvimento para Aplicativos Mobile
• Prêmio
  • Proteste Inovação 2015
• No dia-a-dia
  • Analista de Requisitos
• Membro

Ciclo de Desenvolvimento

Porque os projetos dão errado?

Projetos não falham. Pessoas falham.

Porque os projetos dão errado?

• Não ter um time no projeto
• Prazos curtos
• Funcionalidades do negócio não mapeada
• Começar a desenvolver sem prototipar
• Cliente não é envolvido no desenvolvimento do projeto
• Homologação do sistema é suprimida
• Procastinação
• Ambiente não escalável

Projetos que deram "errado"

• Therac-25 (1985)

Desastre: Irradiou doses letais de radiação em pacientes.

Causa: configuração incorreta de modo que o feixe de elétrons seria como um fogo de alta potência;

Consequências: 3 mortos e 3 seriamente feridos

Projetos que deram "errado"

• Google Glass

Sergey Brin: cofundador do Google apresentou o produto ao mercado antes da hora certa.

fonte

O que são boas práticas?

Técnicas identificadas como as melhores para  realizar uma determinada tarefa.

Porque usar boas práticas?

Benefícios 

• Redução do Ciclo de Desenvolvimento do Software;
• Permite uma aplicação mais tolerante a falhas;
• Melhora manutenibilidade;
• Entregar o produto mais funcional.

.etapas {}

Construir um software não é somente escrever código e vê-lo funcionar, é você saber que aquele código será manutenível e que outras pessoas vão alterá-lo.

.produtividade{}

• Pomodoro
• Kanban
• Metodologia Agil

.pomodoro{}

• Técnica de gestão de tarefas, desenvolvida por Francesco Cirillo em 1980

.pomodoro{}

• Passo a passo para aumentar a produtividade

.produtividade {}

• Pomodoro
• Kanban
• Metodologia Agil

.kanban{}

• Técnica de cartões, criado pela Toyota, Kanban é um termo de origem japonesa e significa literalmente “cartão” ou “sinalização”;
• Indicam o andamento dos fluxos de desenvolvimento.

.metodologias Agil{}

• Acelerar o desenvolvimento do software;
• Melhoria contínua do processo;
• Aumenta a comunicação e interação da equipe;
• Atividades organizadas diariamente ;
• Evitar falhas na elaboração;
• Respostas rápidas às mudanças;
• Aumenta produtividade;

.SCRUM {}

• Processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software.

Iterativo

Incremental

• Desenvolvido na década de 90 por Jeff Sutherland

.SCRUM {}

• São atividades divididas que geralmente duram de 2 a 4 semanas.

Sprints

Sprints Backlog

• São listas de funcionalidades a serem implementadas no projeto.

.SCRUM {}

Sprint backlog

.SCRUM {}

• Define os requisitos do produto, decide a data de release e o que deve conter nela.
• Responsável pelo retorno financeiro do produto.
• Aceita ou rejeita o resultado de cada Sprint.

Product Owner

• Líder e mediador que distribui as atividades;
• Protege o time de interferências externas;
• Participa das reuniões diárias, revisão da Sprint, e planejamento.

Scrum Master

.SCRUM {}

Scrum Team

• Multifuncional, entre 5-9 membros.
• Seleciona, entre os itens priorizados, os que irão ser executados durante a Sprint.
• Desenvolve e produz com qualidade atividades da Sprint

.requisitos {}

• Liste os requisitos
  • (entrevistas, questionários, brainstorms e workshops.)
• Trace o escopo do projeto;
• Envolva usuário final;
• Documente;
• Valide os requisitos;
• Teste
• Codifique

.requisitos {}

• Que são requisitos de software?
  • São características e propriedades que o  sistema deve possuir, como deve se comportar, além de suas restrições de operação.
     

.requisitos {}

• Registre os Requisitos do Sistema:
   
  • RF01 - validar campo de email;
  • RN02 - Ao clicar no campo de senha, animar coruja;

  • RNF03 - Requisitos de portabilidade. o sistema deverá rodar em qualquer plataforma.

.requisitos {}

• Baixa qualidade;
• Retrabalho;
• Maior números de bugs;
• Escopo indefinido;
• Problemas de usabilidade;
• Insatisfação do cliente;
• Ciclo de manutenção maior;
• Vulnerável a falhas e invasões.

Consequências de Software sem Requisitos

.prototipacao {}

Processo que facilita o entendimento dos requisitos, apresenta conceitos e funcionalidades do software.

.prototipos Tipos{}

• Baixa fidelidade

• Média Fidelidade

.prototipos Tipos {}

• Alta Fidelidade

.prototipos Tipos {}

.ferramentas {}

fonte

fonte

fonte

fonte

.Arquitetura {}

Camadas de um projeto

• Componentes de software;
• Aplicativos externos;
• Integração de sistemas;
• Propriedades externas.

.Arquitetura {}

Adote um Framework

• Padronização de processos.
• Uso de boas práticas de desenvolvimento.
• Enorme gama de recursos disponíveis.
• Re-uso de código.
• Flexibilidade e Extensibilidade dos projetos.
• Fácil manutenção.
• Produtividade.

.Arquitetura {}

Model View Controller

• Divide a responsabilidade dos componentes;
• Separa camada de desenvolvimento;
• Facilidade de manutenção;
• Reaproveitamento de código.

.modelagem {}

Normalização

• Evita redundância desnecessária  permitindo fácil acesso às informações;
• Evita anomalias no banco.

Banco de Dados bem projetado

.modelagem {}

Evitar

Boa prática

.querys {}

Evitar

Boa prática

Com * o SGBD gasta muito tempo percorrendo todos os campos

SELECT * FROM tabelaX

SELECT COLUNA_A, COLUNA_B FROM tabelaX

.querys {}

UNION

O SGBD não consegue otimizar cláusulas de join ligadas por OR. Neste caso é mais eficiente ligar os conjuntos de resultados por UNION.

SELECT a FROM tab1, tab2 
WHERE tab1.a = tab2.a 
OR tab1.x = tab2.x

SELECT a FROM tab1, tab2 
WHERE tab1.a = tab2.a 
UNION SELECT A FROM tab1, tab2	
WHERE tab1.x = tab2.x

OR

são eliminadas as linhas duplicadas

Evitar

Boa Prática

Utilize padrão de Projeto...

Padrão...

.padroes de Projetos {}

• Documenta boas soluções para problemas recorrentes
• Permite o reuso de conhecimento anterior documentados em boas práticas
• Obtidas através de experiências de sucesso na indústria de software

“Gang of Four”

.padroes de Projetos {}

Benefícios

• Facilita a evolução do código.
• Reuso das soluções
• Desenvolvimento acelerado
  • Reduz tempo de desenvolvimento e validação

.padroes de Projetos {}

.versionamento {}

• Permite que você altere um arquivo e, se fizer algo de errado, volte atrás.

• Guarda as informações de quem alterou alguma funcionalidade.

Controle de versão

.versionar Projeto{}

Se alguém fizer algo de errado..

Já sabem quem é o culpado!

.versionar Projeto{}

• Controlar histórico
• Marcar  e resgatar versões estáveis
• Ramificar o projeto
• Segurança
• Multiplataforma

Porque usar versionamento?

.testes {}

• Teste unitários (unit)

• Testes de integração(service)

• Testes de aceitação (UI)

.testes {}

UI
 

Service

Unit

Testes Automatizados

• Reduz significativamente o custo das empresas e re-trabalho dos desenvolvedores com manutenção.

• Melhorar a performance, consistência e outros fatores importantes.

.testes {}

PhpUnit

• Os testes são automatizados, ou seja, não precisam de intervenção manual durante sua execução;
• São executados continuamente durante o ciclo de desenvolvimento;
• Detectam falhas tanto de digitação e lógica, como também comportamentos inesperados.

• WEB
  • Requisitos de Software
  • Design Patterns
  • Versionamento
  • Prototipos
  • Modelagem
  • Testes
• LIVROS
  • Design Patterns
  • Especificações de Software

Muito obrigada!!!

dannyserena

dannyserena

danielleteixeira