Aula_2_processo_de_software

•
FAI

Leonardo Ferreira
16/04/2021
Prévia do material em texto
Processo de Software
Francisco Glaubos
Universidade Federal do Maranhão
glaubosclimaco@gmail.com
1 / 60
Elementos da ES
2 / 60
Elementos da ES: Processo
Segundo Sommerville:
”[O processo é] um conjunto de atividades e resultados
associados que produzem um produto de software”.
Um conjunto estruturado de atividades exigidas para
desenvolver um sistema de software
atividades são agrupadas em fases
cada fase possui suas respectivas responsabilidades
3 / 60
Fases de um processo de Software
Para Schwartz as principais fases de um processo de
software são :
Especificação de Requisitos: tradução da
necessidade do cliente, para uma descrição das
funcionalidades a serem desenvolvidas.
Projeto de Sistema: tradução destes requisitos
em uma descrição de todos os componentes
necessários para codificar o sistema. Por ex.:
Diagramas de classe, casos de uso, etc.
4 / 60
Fases de um processo de Software
Programação (Codificação): produção do código
que controla o sistema e realiza a computação e
lógica envolvida.
Verificação e Integração: verificação da
satisfação dos requisitos iniciais pelo produto
produzido.
5 / 60
Elementos da ES: visão geral
• Processo
– Define os passos gerais para o desenvolvimento e
manutenção do software
– Serve como uma estrutura de encadeamento de
métodos e ferramentas
• Métodos
– São os “how to’s” de como fazer um passo
espećıfico do processo
• Ferramentas
– Automatizam o processo e os métodos
6 / 60
Elementos da ES
• Cuidado com o “desenvolvimento
guiado por ferramentas”
- É importante usar a ferramenta
certa para o problema
- O problema não deve ser
adaptado para a ferramenta dispońıvel
7 / 60
Elementos da ES
- Problemas:
• Desenvolver aplicativo para android
– JAVA
• Desenvolver aplicativo para iOS
– Objective C ou Swift
• Desenvolvimento de site
– frontend:
∗ CSS (cores, imagens, fontes e detalhes)
e HTML (“esqueleto” da página)
– backend:
∗ PHP e o MySQL (Banco de Dados)
8 / 60
Elementos da ES
• Sistemas operacionais
– Assembly, C/C++
• Sistemas embarcados
– Arduino: plataforma de prototipagem
eletrônica de hardware
∗ Possui um linguagem padrão:
essencialmente c++.
9 / 60
Elementos da ES
10 / 60
Elementos da ES
11 / 60
O Supermercado de ES
ES fornece um conjunto de métodos
para produzir software de qualidade
Pense como em um supermercado...
– Em função do problema, se escolhe o
processo, os métodos e as ferramentas
Cuidado
– Menos do que o necessário pode levar
a desordem
– Mais do que o necessário pode
emperrar o projeto
12 / 60
Exerćıcio 2.1
Problema
Definir o procedimento de implantação para os dois
cenários a seguir. Identifique o que é processo,
ferramento e método.
Caso 1: urna eletrônica
– O software da urna eletrônica acabou de ser
implementado, e precisa ser instalado em 480 mil
urnas
Caso 2: padaria
– O software de controle de venda de pão da
padaria do seu Zé acabou de ser implementado, e
precisa ser instalado
13 / 60
Processos impĺıcitos x expĺıcitos
• Lembrem-se: Processos sempre existem, seja de forma
impĺıcita ou expĺıcita!
– Processos impĺıcitos são dif́ıceis de serem
seguidos, em especial por novatos
– Processos expĺıcitos estabelecem as regras de
forma clara
14 / 60
Processo de qualidade
Última palavra para medir a qualidade de um
processo: Satisfação do Cliente
Outros indicadores importantes
– Qualidade dos produtos gerados
– Custo real do projeto
– Duração real do projeto
15 / 60
Modelos de ciclo de vida
Existem alguns processos pré-fabricados
– Esses processos são conhecidos como modelos de
ciclo de vida
– Esses processos apresentam caracteŕısticas
predefinidas
Devem ser adaptados para o contexto real de uso
– Caracteŕısticas do projeto
– Caracteŕısticas da equipe
– Caracteŕısticas do cliente
16 / 60
Modelo Cascata
Modelo idealizado por Royce em 1970
principal caracteŕıstica: a sequência de atividades
cada fase transcorre completamente e seus produtos são
vistos como entrada para uma nova fase
17 / 60
Modelo Cascata
Útil quando se tem requisitos estáveis e bem
definidos
- projeto de um foguete
Não lida bem com incertezas
Fornece pouca visibilidade do estado do projeto
– Muito tempo para a primeira entrega
– Dificuldade na obtenção de feedback do cliente
É dif́ıcil capturar os requisitos de uma só vez
18 / 60
Modelo Espiral
- projeto é atacado como uma série de pequenos ciclos,
cada um finalizando um versão de um software
executável
- vários conjuntos de quatro fases são executados até se
obter o sistema final
19 / 60
Modelo Espiral
- é uma abordagem mais reaĺıstica para desenvolvimento
de software em grande escala
- capacita a empresa e o cliente, a entender e reagir aos
riscos em cada etapa evolutiva
20 / 60
Modelo Espiral
Foco principal no gerenciamento de riscos. A cada
ciclo
– O conhecimento aumenta
– O planejamento é refinado
– O produto gerado no ciclo anterior é evolúıdo
(não é jogado fora)
Cada ciclo evolui o sistema, mas não
necessariamente entrega um software operacional
– Modelo em papel
– Protótipo
– Versões do produto
– Etc.
21 / 60
Modelo de desenvolvimento incremental e
iterativo
- É uma extensão do modelo espiral. Porém, mais formal
e rigoroso
- Iterações: são passos do desenvolvimento do software
- Incrementos: são versões do software
22 / 60
Desenvolvimento Incremental
- “Mini-cascatas”
23 / 60
Desenvolvimento Incremental
Faz entregas incrementais do software
– Cada incremento é constrúıdo via um mini-cascata
– Cada incremento é um software funcional
Versões anteriores ajudam a refinar o plano
– Feedback constante do cliente
Diminuição da ansiedade do cliente
– O cliente rapidamente recebe uma versão
funcional do software
24 / 60
Desenvolvimento Iterativo
O desenvolvimento é organizado em “mini-projetos”
– Cada “mini-projeto” é uma iteração
– Cada iteração tem duração curta e fixa (de 2 a 6
semanas)
– Cada iteração tem atividades de análise,
projeto,programação e testes
– O produto de uma iteração é um software parcial
25 / 60
Desenvolvimento Iterativo
A iteração deve ser fixa
– Tarefas podem ser removidas ou inclúıdas
– A iteração nunca deve passar da duração previamente
estipulada
O resultado de cada iteração é um software...
– Incompleto
– Em desenvolvimento (não pode ser colocado em produção)
– Mas não é um protótipo!!!
Esse software pode ser verificado e validado parcialmente
– Desenvolvedores
– Usuários
Podem ser necessárias diversas iterações (e.g. 10 a 15) para
ter uma versão do sistema pronta para entrar em produção
26 / 60
Desenvolvimento Iterativo
Iterações curtas privilegiam a propagação de
conhecimento
– Aumento do conhecimento sobre o software
– Diminuição das incertezas, que levam às mudanças
27 / 60
28 / 60
Modelo de Prototipação
Geralmente utilizado como aux́ılio a outro modelo
de processo
Útil para
– Validar um requisito obscuro com o cliente
– Verificar o desempenho de um algoritmo espećıfico
Merge Sort ou Quick Sort
Busca binária ou sequencial
Deveria ser jogado fora no final
– Protótipos não são produtos
– Usualmente os clientes desejam colocar protótipos
em produção
29 / 60
Modelos tradicionais x modelos evolutivos
30 / 60
Modelos tradicionais x modelos evolutivos
31 / 60
Modelos tradicionais x modelos evolutivos
32 / 60
Modelo de Desenvolvimento Ágil: Visão
Geral
São dadas respostas rápidas e flex́ıveis a mudanças:
– O projeto é replanejado continuamente
– São feitas entregas incrementais e constantes do
software, refletindo as mudanças solicitadas
33 / 60
Modelo de Desenvolvimento Ágil: Visão
Geral
Alguns prinćıpios:
Satisfazer o cliente
Acolher modificações nos requisitos
Entregar o software com frequência
Trabalhar junto ao cliente
Promover conversas face a face
Medir o progresso com software funcionando
Manter um ritmo constante de trabalhoCuidar da qualidade
Buscar por simplicidade
34 / 60
Processo Unificado
35 / 60
Processo Unificado
(benef́ıcios esperados)
Identificação de riscos precoce
Visibilidade do progresso
Envolvimento do usuário
Controle sobre a complexidade
Menos defeitos
Aprendizado em iteração passadas
36 / 60
Processo Unificado (exemplo)
Analisar os requisitos no ińıcio do projeto
- Casos de uso
- Lista de requisitos não funcionais
Priorizar os casos de uso
- Significativos para a arquitetura como um todo
- Alto risco
Em cada iteração
- Selecionar casos de uso por prioridade para serem analisados
- Atribuir tarefas para a iteração a partir da análise detalhada
desses casos de uso
- Fazer projeto e programação de parte do software
- Testar a parte do software recém projetada e programada e
criar a baseline da iteração
- Apresentar a baseline da iteração ao usuário
*baseline ou branches, itens de configuração formalmente aprovados que servem de base para as etapas seguintes
37 / 60
Processo Unificado (exemplo)
- Após a iteração 10 tem-se um incremento.
38 / 60
Processo Unificado (fases)
O desenvolvimento pode ser decomposto em fase,
com o intuito de retratar a ênfase principal das
iterações
– Concepção
– Elaboração
– Construção
– Transição
39 / 60
Processo Unificado (exemplo)
40 / 60
Fase de concepção
Consiste de:
Identificação de riscos
Listagem inicial dos requisitos
Esboço dos casos de uso
Identificação de arquiteturas candidatas
Estimativas iniciais de cronograma e custo
Principais caracteŕısticas
Menor fase do projeto
Escopo ainda vago
Estimativas ainda vagas
Esforço e duração aproximados
5% do esforço do projeto
10% da duração do projeto
41 / 60
Fase elaboração
Consiste de:
Redução dos riscos
Detalhamento da maioria dos requisitos e casos de uso
Estabelecimento e validação da arquitetura do software
Detalhamento das estimativas de cronograma e custo
Principais Caracteŕısticas:
Grande parte das atividades de análise e projeto já
conclúıda
Diminuição significativa das incertezas
A baseline da arquitetura é estabelecida
Esforço e duração aproximados
20% do esforço do projeto
30% da duração do projeto
42 / 60
Fase de construção
Consiste de:
Implementação dos demais componentes da arquitetura
Preparação para a implantação
Principais caracteŕısticas:
Maior fase do projeto
baseline de testes do produto é estabelecida
Esforço e duração aproximados
65% do esforço do projeto
50% da duração do projeto
43 / 60
Fase de transição
Consistes de:
Execução de testes finais
Implantação do produto
Treinamento dos usuários
Principais Caracteŕısticas
Baseline de liberação do produto é estabelecida
Obs.: Se for a última iteração, baseline − > release
Esforço e duração aproximados
10% do esforço do projeto
10% da duração do projeto
44 / 60
Processo Unificado (caracteŕısticas)
Os requisitos não são completamente definidos
antes do projeto
O projeto não é completamente definido antes da
programação
A modelagem não é feita de forma completa e
precisa
A programação não é uma tradução mecânica do
modelo para código
As iterações não duram meses, mas sim semanas
O planejamento não é especulativo, mas sim
refinado durante o projeto
45 / 60
Exerćıcio 2:
Imagine que você faz parte de uma equipe para
realização do desenvolvimento de um software para
controle de estoque. Analise como o processo unificado
será utilizado no trabalho.
Qual será a duração de uma iteração?
O que vocês pretendem entregar em cada iteração?
Qual será o papel de cada membro do grupo?
Quais são os riscos envolvidos?
Quais decisões arquiteturais precisam ser tomadas (linguagem,
SO, etc.)?
46 / 60
Por que fazer bem feito?
1 Por que é mais barato!
– Historicamente, 60% a 80% do esforço total
ocorre na manutenção
2 Por que é mais rápido!
– Não ter tempo para fazer bem feito agora significa
ter tempo para refazer depois
3 Por que é mais fácil!
– Desenvolvimento ocorre uma única vez
– Manutenção é para sempre
47 / 60
O que é manutenção?
O processo de modificar um sistema de software ou
componente, depois da entrega, para corrigir falhas,
melhorar desempenho ou outros atributos, ou adaptar a
mudanças no ambiente.
IEEE Std 620.12 1990
48 / 60
Quando inicia a manutenção
49 / 60
Quais são os tipo de manutenção?
50 / 60
Quais são os tipo de manutenção?
Manutenção emergencial
– Não programada
– Mantém temporariamente o sistema funcionando
– Necessita uma manutenção corretiva posterior
Manutenção corretiva
– Reativa
– Corrige problemas reportados
– Faz o software voltar a atender aos requisitos
51 / 60
Quais são os tipo de manutenção?
Manutenção preventiva
– Pró-ativa
– Corrige problemas latentes, que podem acontecer
Manutenção adaptativa
– Mantém o software usável após mudanças no
ambiente
Manutenção perfectiva
– Provê melhorias para o usuário
– Melhora atributos de qualidade do software
52 / 60
Mitos gerenciais
Basta um bom livro de ES para fazer bom
software
– Um bom livro certamente ajuda, mas ele precisa
refletir as técnicas mais modernas de ES e ser lido!
Se estivermos com o cronograma atrasado,
basta adicionar mais gente ao projeto
– Adicionar gente a um projeto atrasado faz o
projeto atrasar mais!
Se o projeto for terceirizado, todos os meus
problemas estão resolvidos
– É mais dif́ıcil gerenciar projetos terceirizados do
que projetos internos!
53 / 60
Mitos do cliente
Basta dar uma ideia geral do que é necessário
no ińıcio
– Requisitos amb́ıguos normalmente são uma receita
para desastre!
– Comunicação cont́ınua com o cliente é
fundamental!
Modificações podem ser facilmente
acomodadas, porque software é flex́ıvell
– O impacto de modificações no software varia em
função da modificação e do momento em que ela é
requisitada!
– Novamente, comunicação cont́ınua com o cliente
é fundamental!
54 / 60
Mitos do Desenvolvedor
Assim que o código for escrito o trabalho
termina
– 60% a 80% do esforço será gasto depois que o
código foi escrito!
– Vale a pena esforçar para chegar a um bom
código (boa documentação, bom projeto, etc.)!
Só é posśıvel verificar a qualidade de um
software quando o executável existir
– Toda a complexidade desnecessária deve ser
descartada
55 / 60
Mitos do Desenvolvedor
O único produto a ser entregue em um projeto
é o código
– Além do código, documentações tanto para a
manutenção quanto para o uso são fundamentais!
Engenharia de software gera documentação
desnecessária
- Engenharia de software foca em criar qualidade, e
não criar documentos!
– Algum grau de documentação é necessário para
evitar retrabalho!
– Questione sempre que encontrar um documento
desnecessário para o projeto!
56 / 60
7 prinćıpios de Hooker
Tem que existir uma razão para se fazer software
– Se não for posśıvel identificar essa razão, é melhor não fazer
– Fazer software, em última instância, consiste em “agregar
valor para o usuário”
– É importante enxergar os reais requisitos do software!
Keep it simple, sir! (KISS)
– “um projeto deve ser o mais simples posśıvel, mas não mais
simples que isso”
- Toda a complexidade desnecessária seja descartada.
- Se atenha a atender os requisitos.
57 / 60
Mantenha o estilo
– O projeto de um software deve seguir um único
estilo
– A combinação de diferentes estilos corretos pode
levar a um software incorreto
– Padrões e estilos devem ser estabelecidos no ińıcio
e seguidos por todos
O que é produzido por você é consumido por outros
– Sempre especifique, projete e codifique algo
pensando que outros vão ler
– Sempre exija qualidade nos produtos que você
consome e forneça qualidade nos produtos que você
produz
58 / 60
Esteja pronto para o futuro
– Sistemas de boa qualidade têm vida longa
– Projete desde o ińıcio pensando na manutenção
Planeje para reutilização– Pense no problema geral, e não só no problema
espećıfico
– Busque por soluções já existentes
Pense!
- Pense antes de fazer
- Avalie alternativas
- Reduza os riscos
59 / 60
Nós precisamos de ES
60 / 60