engenharia-de-software

UFRJ

Enviado por Mercia Solange em 04/09/2020
Prévia do material em texto
DOCUMENTAÇÃO
DE PROJETO DE SOFTWARE
SocialManager
Versão 1.1
Arthur Sampaio
Antunes Dantas
Lucas Silva
Valter Lucena
Wesley Santos
Universidade Federal de Campina Grande
Professor: Rohit Gheyi
1
Sumário
1 Introdução 5
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Visão da Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Descrição do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Planejamento 7
2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Escolha da Rede Social . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Gerência de Tempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Estimativa de tempo com UCP . . . . . . . . . . . . . . . . . . . . 8
2.2.1.1 Cálculo de UUCP . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1.1.1 Cálculo do UUCW: . . . . . . . . . . . . . . . . . 9
2.2.1.1.2 Cálculo do UAW: . . . . . . . . . . . . . . . . . . 9
2.2.1.2 Cálculo de TCF . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1.3 Cálculo de ECF . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1.4 Estimativa de horas . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Primeira Entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2.1 Cronograma da primeira entrega . . . . . . . . . . . . . . 12
2.2.2.2 Lições aprendidas com a primeira entrega . . . . . . . . . 12
2.2.3 Segunda entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3.1 Definição da estratégia de estimativa de tempo de User
Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3.2 Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3.3 Cronograma da Segunda Entrega . . . . . . . . . . . . . . 16
2.2.3.4 Acompanhamento da segunda entrega . . . . . . . . . . . 17
2.2.3.5 Lições aprendidas com a segunda entrega . . . . . . . . . . 18
2.3 Gerência de Custo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Gerência de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Gerência de Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Processos de Software 24
4 Requisitos 26
4.1 Entrevista com stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Requisitos Não Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1 Requisitos de Processo . . . . . . . . . . . . . . . . . . . . . . . . . 27
2
4.2.2 Requisitos de Produto . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.2.1 Integridade e Segurança . . . . . . . . . . . . . . . . . . . 28
4.2.2.2 Eficiência . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.3 Requisitos Externos . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.3.1 Legais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.3.2 Éticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.1 RF-01 - Vincular rede social . . . . . . . . . . . . . . . . . . . . . . 31
4.3.2 RF-02 - Desvincular rede social . . . . . . . . . . . . . . . . . . . . 32
4.3.3 RF-03 - Visualizar resumo do perfil . . . . . . . . . . . . . . . . . . 33
4.3.4 RF-04 - Visualizar conexões . . . . . . . . . . . . . . . . . . . . . . 33
4.3.5 RF-05 - Desfazer amizade / deixar de seguir usuário . . . . . . . . . 34
4.3.6 RF-06 - Fazer amizade / seguir usuário . . . . . . . . . . . . . . . . 35
4.3.7 RF-07 - Filtrar conexões . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.7.1 Filtros de conexões . . . . . . . . . . . . . . . . . . . . . . 36
4.4 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5 Protótipos de Telas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Projeto Arquitetural 38
6 Modelagem 39
6.1 Análise dos Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2 Diagramas de Sequência . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2.1 Diagrama de Sequência - Caso de Uso: Vincular Rede Social . . . . 39
6.2.2 Diagrama de Sequência - Caso de Uso: Desvincular Rede Social . . 40
6.2.3 Diagrama de Sequência - Caso de Uso: Deixar de Seguir um Perfil . 41
6.2.4 Diagrama de Sequência - Caso de Uso: Visualizar resumo do perfil . 42
6.2.5 Diagrama de Sequência - Caso de Uso: Começar a Seguir um perfil 43
6.3 Contratos de Operação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7 Especificação Formal 45
8 Implementação 46
9 Testes 47
9.1 Plano de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.2 Testes de unidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.3 Testes funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.3.1 RF-01 - Vincular rede social (Instagram) . . . . . . . . . . . . . . . 48
9.3.2 RF-02 - Desvincular rede social . . . . . . . . . . . . . . . . . . . . 50
9.3.3 RF-03 - Ver resumo do perfil . . . . . . . . . . . . . . . . . . . . . . 51
9.3.4 RF-04 - Visualizar conexões . . . . . . . . . . . . . . . . . . . . . . 51
9.3.5 RF-05 - Desfazer amizade / deixar de seguir usuário . . . . . . . . . 52
3
9.3.6 RF-06 - Fazer amizade / seguir usuário . . . . . . . . . . . . . . . . 53
9.3.7 RF-07 - Filtrar conexões . . . . . . . . . . . . . . . . . . . . . . . . 53
9.4 Testes não-funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
10 Projeto Real 54
10.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.1.2 Seleção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.1.3 JInstagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.2 Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
10.2.1 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
10.2.1.1 Análise dos resultados . . . . . . . . . . . . . . . . . . . . 55
10.2.2 Findbugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
10.2.2.1 Más Práticas . . . . . . . . . . . . . . . . . . . . . . . . . 58
10.2.2.2 Corretude . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
10.2.2.3 Internacionalização . . . . . . . . . . . . . . . . . . . . . . 59
10.2.2.4 Performance . . . . . . . . . . . . . . . . . . . . . . . . . 60
10.2.2.5 Código espertalhão . . . . . . . . . . . . . . . . . . . . . . 60
10.2.3 Análise de qualidade: iPlasma . . . . . . . . . . . . . . . . . . . . . 61
10.3 Análise de Custo e Esforço . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
10.4 Testes (Randoop) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
10.5 Evolução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
10.5.1 Refatorando o sistema . . . . . . . . . . . . . . . . . . . . . . . . . 65
10.5.2 Pirâmide do iPlasma após os refatoramentos. . . . . . . . . . . . . . 67
4
1 Introdução
1.1 Motivação
As mı́dias sociais acompanham a evolução da relação entre as pessoas há alguns
anos. Cada vez dedicamos uma fatia maior do nosso tempo a estas e isto é consequência
dos investimentos massivos de empresas desse meio para atrair e engajar novos usuários.
Novas empresas como Instagram, SnapChat, Spotify, entre outras, digladiam-se para con-
quistar novos consumidores no mercado que promete movimentar $36 bilhões de dólares
no ano de 2017 [5].
As grandes plataformas de mı́dias sociais funcionam a base de um modelo rel-
ativamente simples: informações fazem usuários interagirem entre si para criar novas
informações e assim retroalimentar esse sistema. Porém, este modelo a longo prazo pos-
sui problemas. Os gostos, opiniõese amizades pessoais mudam ao decorrer do tempo e
consequentemente o ciclo social que é desenvolvido nessas plataformas também.
Como parte das poĺıticas de engajamento, essas plataformas não possuem features
adequadas para administrar e gerenciar os v́ınculos que o usuário possui. Isso faz com
o que as informações passadas na tela não satisfaçam mais o gosto do mesmo, ocasion-
ando em um menor engajamento e/ou na perca de tempo do mesmo para gerenciar estes
v́ınculos.
Diante da problemática exposta acima e pensando nesses usuários, decidimos criar
um aplicativo h́ıbrido Android que permite que usuários das mais diversas redes sociais
possam gerenciar seus amigos, páginas e seguidores de maneira simples e intuitiva com o
propósito de maximizar a experiência do usuário em suas redes sociais.
É notório que nosso sistema vem com o intuito de ajudar não só o usuário que
quer gerenciar suas redes e manter sua timeline a seu modo, mas também as próprias
plataformas uma vez que o engajamento com o usuário será incrementado com o nosso
sistema.
1.2 Visão da Solução
Gerenciar suas redes sociais em apenas um único lugar.
5
1.3 Descrição do Documento
Para ajudar a leitura deste documento o mesmo foi organizado em seções dispostas
da seguinte forma:
• Seção 1: Apresentação do problema e motivação para a construção do sistema.
• Seção 2: Planejamento para o desenvolvimento e as atividades de gerência são descrita
aqui.
• Seção 3: Definição do processo utilizado para o desenvolvimento do sistema
• Seção 4: Descrição dos requisitos e outras formas de elicitações.
• Seção 5: Projeto arquitetural da solução.
• Seção 6: Modelagem dos dados e casos de uso do sistema.
• Seção 7: Especificação Formal do sistema.
• Seção 8: Resultados da implementação da solução.
• Seção 9: Descrição e resultados de testes do software
6
2 Planejamento
2.1 Introdução
Planejamento é o alicerce de qualquer atividade de engenharia, e isto não é diferente
no mundo do software. A atividade de planejamento permite conhecer as fragilidades do
projeto antes mesmo de implementá-lo. Ou seja, os desenvolvedores pensam antecipada-
mente no que vão trabalhar e preveem caso a caso com o intuito de criar maneiras de
atingir os objetivos com o menor custo e risco posśıvel mantendo o grau de qualidade
satisfatório.
Há inúmeros fatores que impactam diretamente o sistema, como: adição de novos
requisitos, relacionamento interpessoal entre os membros do time, habilidades dos mem-
bros em Ionic, a necessidade de tirar notas boas nas disciplinas, a aceitação do público alvo
pelo aplicativo, dentre outros. Realizar um projeto que encapsule todas essas variáveis
sem um planejamento bem feito tem altas chances de dar errado.
Nesta seção, os processos de planejamento são descritos com o intuito de diminuir
ao máximo o tempo gasto, o custo e os riscos. Aqui também estará exposto a rotina de
trabalho de cada membro da equipe além dos requisitos de software e estratégias utilizadas
para solucionar os mesmos.
2.1.1 Escolha da Rede Social
O objetivo da nosso app é ser um gerenciador de redes sociais. Porém, para o escopo
deste projeto não é posśıvel conectar todas as redes por questões tais como tempo, custo
de produção e poĺıticas de privacidade. Neste momento, escolhemos construir o Social-
Manager para administrar apenas uma rede social porém, com a arquitetura necessária
para integrar no futuro demais redes sociais. Nosso objetivo é que o usuário use nosso
app com frequência para assim o mesmo aumentar seu valor agregado com o passar do
tempo. Contudo, a questão que fica é: Qual rede social primeiro conectar?
Na figura acima é posśıvel notar que o Facebook é a rede que tem o maior engaja-
mento no mundo. Nossa primeira escolha foi o Facebook, mas o mesmo não permite que
se faça algumas operações essenciais sejam feitas via API pública. Assim, estudamos as
API’s das redes sociais (entre as mostradas na figura) com intuito de encontrar a melhor
documentada e de fácil compreensão.
Diante do exposto acima, escolhemos como rede social inicial o Instagram.
7
Figure 2.1: Engajamento de usuários por Rede Social. Fonte: SmarthInsights [4], 2017
2.2 Gerência de Tempo
2.2.1 Estimativa de tempo com UCP
Para estimar o tempo necessário para conclusão do projeto de forma que ele atenda
os requisitos, a equipe utilizou a estimação de pontos por caso de uso. De forma geral, o
tempo para completar o projeto é afetado pelos seguintes fatores:
• Número de passos para completar o caso de uso
• Número e complexidade dos atores
• Requisitos técnicos do caso de uso como concorrência, segurança e performance
• Fatores ambiental como a experiência e o conhecimento do time
O método de pontos por caso de uso provê a habilidade de estimar a quantidade de
horas que um projeto requer para ser conclúıdo através dos seus casos de uso. O método
UCP transforma os fatores que afetam o desenvolvimento do projeto em uma equação
composta por três variáveis [2]:
• Pontos de caso de uso não ajustados (UUCP)
• Fator de complexidade técnica (TCF)
• Fator de complexidade ambiental (ECF)
Sendo assim, tem-se a equação de UCP:
UCP = UUCP * TCF * ECF
8
2.2.1.1 Cálculo de UUCP
O valor UUCP é definido pela seguinte fórmula:
UUCP = UUCW + UAW
É necessário classificar os casos de uso e os atores, de forma a obter os valores para
UUCW e UAW.
2.2.1.1.1 Cálculo do UUCW: Os casos de uso são classificados de acordo com ńıvel de
complexidade, que podem assumir os rótulos simples, médio e alto, com pesos 5, 10 e 15,
respectivamente. Então, soma-se todos os pesos obtidos para obter o valor do UUCW.
Sendo assim, tem-se as seguintes classificações para os casos de uso:
Table 2.1: Classificação dos casos de uso para cálculo de UUCP
Código Caso de uso Nı́vel de complexidade Peso
RF-01 Vincular rede social Médio 10
RF-02 Desvincular rede social Baixo 5
RF-03 Visualizar resumo do perfil Baixo 5
RF-04 Visualizar conexões Médio 10
RF-05 Desfazer amizade / deixar de seguir usuário Baixo 5
RF-06 Fazer amizade / seguir usuário Baixo 5
RF-07 Filtrar conexões Médio 10
TOTAL 50
2.2.1.1.2 Cálculo do UAW: Os casos de uso são classificados de acordo com ńıvel de
complexidade, que podem assumir os rótulos simples, médio e alto, com pesos 1, 2 e 3,
respectivamente. Então, soma-se todos os pesos obtidos para obter o valor do UAW.
Sendo assim, tem-se a seguinte classificação para os atores:
Table 2.2: Classificação dos atores para cálculo de UUCP
Ator Nı́vel de complexidade Peso
Usuário Alto 3
TOTAL 3
9
Com base nos resultados obtidos, calcula-se o valor do UUCP:
UUCP = 50 + 3 = 53
2.2.1.2 Cálculo de TCF
Para calcular o TCF, os fatores técnicos são tabelados e lhes são atribúıdos notas
de 0 a 5. Logo após, faz-se o somatório das notas multiplicadas pelo peso, para cada fator
técnico, de forma a obter o fator técnico total.
Então, obtém-se o valor do TCF a partir da seguinte fórmula:
TCF = 0.6 + (0.01 * Fator técnico total)
Sendo assim, tem-se a seguinte classificação para os fatores técnicos:
Table 2.3: Classificação dos fatores técnicos para cálculo do TCF
Fator Técnico Descrição Peso Nota Peso x Nota
T1 Sistema Distribúıdo 2 0 0
T2 Performance 1 2 2
T3 Eficiência para o Usuário Final 1 3 3
T4 Complexidade do Processo Interno 1 3 3
T5 Reusabilidade 1 3 3
T6 Fácil de Instalar 0.5 2 1
T7 Fácil de Usar 0.5 3 1.5
T8 Portabilidade 2 2 4
T9 Fácil de Alterar 1 2 2
T10 Necessidades Especiais de Segurança 1 3 3
T11 Concorrência 1 1 1
T12 Prover Acesso Direto para Terceiros 1 0 0
T13 Treinamento Especial Para Usuários é Requerido 1 0 0
TOTAL 23.5
Com base nos resultados obtidos, calcula-se o valor final do TCF:
TCF = 0.6 + (0.01 * 23.5)
TCF = 0.6 + 0.235
TCF = 0.835
10
2.2.1.3 Cálculo de ECF
Para calcular o ECF, os fatores ambiental são tabelados elhes são atribúıdos notas
de 0 a 5. Logo após, faz-se o somatório das notas multiplicadas pelo peso, para cada fator
ambiental, de forma a obter o fator ambiental total.
Então, obtém-se o valor do ECF a partir da seguinte fórmula:
ECF = 1.4 + (-0.03 * Fator ambiental total)
Sendo assim, tem-se a seguinte classificação para os fatores ambientais:
Table 2.4: Classificação dos fatores ambientais para cálculo do ECF
Fator Ambiental Descrição Peso Nota Peso x Nota
E1 Familiaridade com UML 1.5 3 4.5
E2 Trabalhadores em tempo parcial -1 4 -4
E3 Capacidade do analista ĺıder 0.5 4 2
E4 Experiência com aplicações 0.5 1 0.5
E5 Experiência com orientação a objetos 1 4 4
E6 Motivação da equipe 1 3 3
E7 Complexidade das linguagens de programação -1 2 -2
E8 Requisitos estáveis 2 4 8
TOTAL 16
Com base nos resultados obtidos, calcula-se o valor final do ECF:
ECF = 1.4 + (-0.03 * 16)
ECF = 1.4 - 0.48
ECF = 0.92
Por fim, em posse dos valores das variáveis UUCP, TCF e ECF, calcula-se o valor
do UCP:
UCP = 53 * 0.835 * 0.92
UCP = 40.71
2.2.1.4 Estimativa de horas
Uma vez calculado o UCP, é posśıvel estimar a quantidade de horas para concluir
o projeto pela seguinte fórmula:
ET = UCP * PF
11
O valor PF representa as horas-homem necessárias para concluir um caso de uso e
é calculado a partir da divisão do número total de horas de um projeto pelo seu UCP.
Nesse caso, utiliza-se estat́ısticas de projetos já conclúıdos para calcular uma média para
o valor PF. Caso nenhuma estat́ıstica tenha sido coletada, recomenda-se usar um valor
para PF entre 15 e 30. Se for o primeiro projeto da equipe, um bom valor é 20.
Dessa forma, tem-se o seguinte resultado para a estimativa total:
ET = 40.71 * 20
ET = 814.292 ≈ 814h
É evidente que esse valor pode variar consideravelmente de acordo com o ritmo da
equipe, mas é necessário estimá-lo em um primeiro momento para que sirvam como base
para o cliente.
2.2.2 Primeira Entrega
A primeira entrega do projeto, marcada para o final de junho, foi composta por
quatro semanas. Foi realizada uma reunião para definição das tarefas iniciais do projeto,
uma vez que o processo de desenvolvimento ainda não estava definido por completo.
2.2.2.1 Cronograma da primeira entrega
Para a primeira entrega, foram estabelecidas as seguintes atividades:
2.2.2.2 Lições aprendidas com a primeira entrega
A primeira experiência com o projeto foi positiva, mas revelou algumas falhas que
poderiam ter sido evitadas, tais como falha na comunicação e acompanhamento mais
atencioso do cronograma por parte dos membros em geral.
A falta de definição detalhada de um processo ou metodologia para auxiliar o de-
senrolar do projeto foi, de fato, o que mais impactou nesse primeiro momento ocasionando
os erros descritos acima. Houve atraso em algumas atividades, o que causou um efeito
cascata assim ocorrendo a não entrega da atividade de modelagem do Bando de Dados.
2.2.3 Segunda entrega
Uma vez definido o processo de desenvolvimento (baseado em Scrum), foi necessário
adaptar a forma na qual as atividades estavam sendo alocadas e desenvolvidas para que
as estimativas de tempo se tornassem posśıveis e atendessem os prinćıpios da metodologia
ágil adotada.
Em Scrum, o product backlog é uma lista de todas as features, contendo breves
descrições das funcionalidades desejadas no produto final. Diante desse artefato, nos
reunimos e escolhemos quais as features principais que deveriam ser desenvolvidas nesta
primeira Sprint, assim, foi definido nosso primeiro Sprint Backlog.
12
2.2.3.1 Definição da estratégia de estimativa de tempo de User Stories
Depois de definidas as estórias de usuário, a equipe utilizou uma prática conhecida
para classificar o ńıvel de dificuldade das estórias, o Planning Poker [3].
A ideia é que cada membro da equipe use uma escala não linear de pontos, no nosso
caso foi a sequência de Fibonacci, para atribuir pesos para cada Estória de Usuário e
assim obter a moda dos pesos escolhidos entre os membros. Para cada estória houve duas
iterações: na primeira os membros da equipe definiam suas notas e no final os membros
13
14
que atribúıram os menores e maiores debatiam o porquê da escolha e em seguida era
realizada mais uma vez a votação. Se ainda houvesse divergência, o peso final seria a
moda entre todos os pesos atribúıdos.
A equipe decidiu, em reunião realizada para discutir sobre o processo, que, como
não há experiência prévia considerável com desenvolvimento para servir como base de
estimativa de tempo, seria necessário criar uma tabela com a quantidade de horas e
número de pessoas alocadas de cada estória.
Peso Horas Pessoas
1 2h 1
2 8h 1
3 12h 2
5 30h 2
8 48h 2
13 65h 3
21 80h 3
2.2.3.2 Sprint 1
US T́ıtulo Pontos de esforço Tempo
1 Como usuário, quero poder fazer login com
minha conta do Instagram
13 65h
2 Como usuário, quero poder desconectar da
minha conta do Instagram
5 30h
3 Como usuário, quero poder ver um resumo da
minha conta do Instagram
8 48h
4 Como usuário, quero poder ver as pessoas que
eu sigo e que me seguem no Instagram
13 65h
5 Como usuário, quero visualizar os usuários que
eu sigo em forma de card e poder deixar de
segui-los
21 80h
6 Como usuário, Como usuário, quero poder vi-
sualizar um menu com as principais opções do
aplicativo
13 65h
TOTAL 60 288h
Portanto, ficou definido que 288 horas de desenvolvimento seriam necessárias para
conclusão da Sprint 1. Essa estimativa poderá ser usada como base para as estimativas
de tempo das sprints futuras, estando sujeita a ajustes para que se adapte ao ritmo da
equipe, observado nessa sprint.
15
2.2.3.3 Cronograma da Segunda Entrega
Após definir quais atividades seriam desempenhadas durante esta iteração foi atribúıdo
as atividades aos membros do grupo.
16
2.2.3.4 Acompanhamento da segunda entrega
Para realizar o acompanhamento diário da sprint utilizamos uma das mais poderosas
ferramentas que a metodologia ágil SCRUM pode nos oferecer: o Burndown Chart.
Ele representa o trabalho restante sobre o tempo, em suma, permite visualizar o
progresso do trabalho executado pela equipe e comparar com o progresso ideal (ou plane-
jado) da equipe traçando assim a quantidade de tempo que ainda falta para completar a
sprint.
Lendo o gráfico é posśıvel notar que os primeiros dez dias o desenvolvimento es-
tavam indo muito bem, acima do esperado. Todavia, após este peŕıodo o desenvolvimento
começou a ficar prejudicado, pois o tempo começou a ficar escasso para os membros e al-
gumas atividades foram postergadas
Ao perceber uma grande diferença entre o desenvolvimento real e ideal, por volta
17
Figure 2.2: Burndown Chart da Segunda Entrega
do vigésimo dia, a equipe se reuniu para avaliar a sprint e ver se retiraria alguma tarefa
para poder fechar a sprint. Chegou-se a conclusão que retirar qualquer tarefa da sprint
poderia por em check a mesma.
Mesmo não sendo posśıvel concluir totalmente a sprint1, como pode ser observado
no gráfico, o burndown chart foi um importante instrumento para evitar que esta situação
piorasse nos auxiliando nas tomadas de decisões no decorrer do projeto.
2.2.3.5 Lições aprendidas com a segunda entrega
Definitivamente seguir os passos de uma metodologia ágil como o SCRUM facilitou
muito o processo de desenvolvimento de software. Isso permitiu fazer estimativas de
custo de maneira mais refinada e próxima da realidade o que ocasionou numa melhora da
gerência do tempo.
Erros que aconteceram na primeira entrega relacionados a comunicação foram mit-
igados através das estratégias descritas ao longo deste texto.
1Ver gerência de risco
18
2.3 Gerência de Custo
Para a equipe de Gerência de Custo, foi atribúıda a atividade de calcular os custos
financeiros do projeto. Os custos foram calculados com base em pesquisa de mercado e
experiência prévia dos integrantes do projeto.
Gasto Valor (Total em 4 meses)
Recursos Humanos R$24.000,00
Aluguel de Escritório R$ 2.000,00
Energia Elétrica R$ 900,00
Internet e Telefone R$ 580,00
Computadores R$ 13.090,00
Mob́ılia R$ 800,00
Total R$ 41.370,00
Além dos custos fixos mostrados na tabela acima, acrescenta-se um lucro de 75%.
Assim, o custo final para o cliente seria de R$ 72.398,00.
2.4 Gerência de Riscos
Uma boa Gerência de Risco é extremamente importante para o sucesso de um
projeto de software. O não gerenciamento e controle dos riscos através da vida útil do
projeto é uma das mais frequentes causas que fazem um projeto falhar [1].
Assim, os riscos do projeto foram discutidos em grupo e estão documentos na tabela
a seguir que lista sua descrição e estratégias de mitigação.
19
ID Categoria Impacto e Descrição de
Risco
Estratégia de Diminuição
PE-1 Pessoal Integrantes indispońıveis
para realização de alguma
atividade designada aos
mesmos.
Realização de reuniões
diárias de curta duração
para acompanhamento
geral
JU-1 Juŕıdico Não aceitação do produto
ao submeter ao review do
Instagram
Atender a todos os tópicos
das poĺıticas de privaci-
dade da API do Instagram
PR-1 Produto e Processo Falta de tempo para de-
sempenhar atividades do
projeto
Realizar uma distribuição
de atividades que en-
volvam adaptação aos
horários do desenvolvedor
PE-2 Pessoal Pouca experiência com
desenvolvimento de
aplicações para disposi-
tivos móveis
Realização de um curso
sobre as ferramentas uti-
lizadas no projeto, assim
como seções de pair pro-
gramming e seção de tirar
dúvidas durante as re-
uniões diárias.
PR-2 Produto e Processo Falha na implementação
dos requisitos
Uso de testes de validação
TEC-1 Tecnológica Complexidade do frame-
work
Utilização de um frame-
work bem conhecido no
mercado para facilitar
a busca de soluções em
fóruns
PR-3 Produto e Processo Tempo de desenvolvi-
mento apertado
Uso e acompanhamento
diário do cronograma com
uma pessoa responsável
por isto.
PR-4 Produto e Processo Não conformidade entre
layouts de telas distintas
Realizar prototipagem de
telas para adequar a um
mesmo padrão
PE-3 Pessoal Falha na Comunicação Uso de ferramentas de
comunicação profissional,
como o Slack, que permite
a criação de canais para fil-
trar os assuntos de cada
conversa e separar as dis-
cussões
TEC-2 Tecnológica Mudança de Tecnologia no
meio do desenvolvimento
Escolher tecnologias con-
solidadas e que atendam
aos requisitos impostos na
disciplina, como a possibil-
idade de realizar diferentes
testes.
20
Caso algum risco não previsto apareça durante o decorrer do desenvolvimento ele
será adicionado a nossa lista e começará a ser acompanhado semanalmente.
Através do monitoramento semanal dos riscos calculamos empiricamente a probabil-
idade dos erros acontecerem naquela semana levando em consideração os fatores pessoais,
técnicos e inesperados (como doenças, etc). Estas probabilidades eram calculadas no
começo de cada semana com base na semana anterior. Após todas as semanas decorridas
temos o seguinte gráfico que explica como foi o comportamento dos riscos.
Figure 2.3: Gerência dos Riscos para a Primeira Entrega. Fonte Própria
21
Da visualização pode-se retirar algumas informações. Por exemplo, na primeira
semana o risco PR-4 tinha uma probabilidade de apenas 0.4 de acontecer, já na segunda
semana esse percentual subiu para 0.8, isso se deu ao fato que integrantes do time encon-
traram divergência em como seria a aplicação e o fluxo de telas, diante disso foi realizado
uma reunião onde conseguiu mitigar o erro. Outras informações podem ser retiradas com
observação semelhante.
Como pode ser visto apartir da quarta semana houve um crescimento referente
à riscos envolvendo as categorias de pessoal e de produto que felizmente algumas foram
controladas e corrigidas a tempo, contudo outras não2 e são nessas dificuldades de gerência
que vamos nos debruçar nas próximas linhas.
Observando o subplot referente a categoria de produto temos que o risco PR-3 não
foi devidamente controlado. Este erro diz respeito ao tempo de desenvolvimento apertado
onde infelizmente a estratégia de diminuição escolhida não foi adequada, uma vez que, os
membros estavam ocupados com atividades acadêmicas e de trabalho.
Outro caso da gerência de risco que deve ser discutido é o do risco de id PR-2,
que diz respeito a falha na implementação dos requisitos. A estratégia de mitigação para
este risco era a criação e a utilização de testes de unidade e regressão, contudo isso não
foi devidamente realizado. Estamos utilizando a API do Instagram que é privada e para
utilizá-la é necessário ter um review aceito pela empresa. Para a criação de aplicativos
que envolvam a rede social eles disponibilizam uma versão de acesso ao sandbox. Contudo,
o que não sab́ıamos é que operações relacionadas a relacionamentos entre usuários não
são permitidas pela API neste modo lançando o erro de Bad Request (erro 400).
Assim, essa abordagem para a gerência de risco possui sua fragilidade: a atribuição
da probabilidade semanal do risco é feita apenas no feeling e está sujeita a erros. En-
tretanto, é uma boa maneira de compreender os riscos que aconteceram além de nortear
previsões dos riscos para as semanas subsequentes.
2.5 Gerência de Recursos
Está listado abaixo os recursos utilizados no desenvolvimento da aplicação:
Recursos Humanos:
• Cinco integrantes do projeto.
Hardware:
• Cinco computadores pessoais (um por desenvolvedor)
• Três smartphones com o sistema operacional Android para teste.
Software:
2Definimos que houve uma má gerência naqueles que tiveram uma probabilidade final maior do que a
inicial
22
• AndroidStudio - IDE para desenvolvimento de código Android
• Visual Code Studio - Editor de texto para código web
• Slack - Ferramenta de comunicação
• IntelliJ - IDE para código Java
• Microsoft Project - Planejamento
• Overleaf - IDE para escrita da documentação
• GitHub - Controle de versão
• Ionic 2 - Framework para desenvolvimento da aplicação
• Angular 2 - Framework web para Javascript
• Karma - Framework para execução de testes em Javascript
• Jasmine - Framework para testes em javascript
23
3 Processos de Software
Processo de Software é um conjunto de atividade relacionadas que lidam com a
produção de um produto de software. Essas atividades incluem definir as regras que
regem o produto, as responsabilidades de cada pessoa da equipe dentro do projeto além
das atividades de especificação, design e implementação, validação e evolução.
Dado a baixa complexidade, o tamanho do nosso projeto e o tamanho da equipe
de desenvolvimento escolheu-se o uso de uma metodologia ágil ao invés de um processo
tradicional, dado que a primeira permite o foco maior no desenvolvimento do software de
qualidade sem o rigor excessivo na produção de artefatos. Assim, escolheu-se o framework
SCRUM com algumas modificações para se adequar ao escopo deste projeto. Adotamos
as seguintes cerimônias com suas quantidade de horas requeridas.
Table 3.1: Cerimônias e seus respectivos timeboxed
Cerimônia Tempo alocado
Reunião de Planejamento da Sprint 1 hora e 30 minutos
Reunião Diária 10 minutos
Reunião de Revisão da Sprint 1 hora
Reunião de Retrospectiva da Sprint 40 minutos
Duração de uma Sprint 1 mês
As reuniões diárias acontecem todas as noites, às 20h, via Slack com todos os
membros reportando as atividades desenvolvidas naquele dia. Todas as demais reuniões
são realizadas presencialmente, salvo raras exceções.
Como este é um projeto que surgiu a partir do interesse de todos os integrantes
escolhemos não utilizar o papel do Product Owner dado que no nosso entendimento,
achamos que, todos possúımos a mesma visão do produto incluindo o product backlog.
Além disto, escolhemos o como o Scrum Master o integrante Lucas Henrique dado seu
conhecimento prévio com a tecnologia e com a metodologiade desenvolvimento escolhida.
escolheu-se o modelo de Desenvolvimento Incremental ( Incremental development),
uma vez que, suas desvantagens relacionadas ao ponto de vista gerencial são mitigadas
com o acompanhamento próximo das entregas para mensurar o progresso.
A ideia básica deste modelo é que as atividades de especificação, desenvolvimento
e validação ocorra de maneira entrelaçada possibilitando rápidas tomadas de decisões no
24
progresso do projeto. Isto resulta em entregas rápidas e utilizáveis que é o foco desta
disciplina.
Com o objetivo de extrair o máximo de conhecimento que a disciplina de Engenharia
de Software I pode oferecer, os membros da equipe irão desempenhar todas as funções
com exceção da gerência do projeto.
25
4 Requisitos
Um dos mais importantes passos no desenvolvimento de um produto de software
é a elicitação de requisitos. Para isto utilizamos uma simples metodologia que pode ser
explicada em alguns passos:
• Definição dos principais stakeholders. No primeiro momento usuários de redes soci-
ais;
• Lançamos uma entrevista com o nosso principal stakeholder, a fim de recolher mais
informações para a elicitação dos requisitos;
• Levantamos os requisitos iniciais com base nas entrevistas e em seguida realizamos
uma prototipagem de telas para ajudar a refletir e refinar as funcionalidades do
sistema. Além de ajudar a guiar a implementação do software;
4.1 Entrevista com stakeholders
A entrevista foi dirigida e lançada nas redes sociais – onde se concentra nosso
público – por meio de formulários usando o Google Forms. Foi entrevistado um total
de 192 pessoas e a seguir estão as perguntas, suas respectivas respostas e uma análise
estat́ıstica em cima da amostra coletada.
• Quais das redes sociais abaixo você utiliza?
• Você sente dificuldade em gerenciar as pessoas de quem você é amigo ou segue nessas
redes?
• O quanto você se preocupa com o ńıvel de interação dos seus contatos com você em
suas redes sociais?
• Você gostaria de saber quem são as pessoas que menos interagem com você em suas
redes sociais?
• Você gostaria de saber se há perfis fantasmas (inativos) entre os contatos de suas
redes sociais?
• Caso tenha respondido ”Sim” a alguma das duas últimas perguntas, utilizaria algum
aplicativo para facilitar a remoção desses amigos das suas redes sociais?1
26
–
Figure 4.1: Resposta da primeira questão.
• Para alguém ser seu amigo ou ser seguido por você em uma rede social, é necessário:2
• Qual o sistema operacional do seu smartphone, caso possua?
A partir das respostas dos entrevistados, chegamos a conclusão que um aplicativo
deste gênero pode ser bem recebido pelo público alvo. A seguir elencamos as funcionali-
dades que consideramos úteis para o nosso escopo.
4.2 Requisitos Não Funcionais
Alguns requisitos não-funcionais (NFRs) foram identificados para o projeto Social
Manager. Abaixo, são apresentadas as descrições para os três tipos de NFR (de processo,
de produto e externos).
4.2.1 Requisitos de Processo
Identificador Descrição
RNF/PROC-01 O aplicativo deve ser desenvolvido com o framework Ionic 2, que
permite que o mesmo seja executado em dispositivos Android e iOS.
RNF/PROC-02 O aplicativo deve utilizar o banco de dados IndexedDB, através da
biblioteca Dexie.js, para que as consultas aos dados sejam mais efi-
cientes.
RNF/PROC-03 Deverá ser feita uma documentação do sistema desenvolvido com o
uso da ferramenta Compodoc.
RNF/PROC-04 Deverão ser utilizadas ferramentas CASE, e é imprescind́ıvel a criação
da modelagem usando a linguagem UML.
1189 respostas para esta pergunta
2190 respostas
27
–
Figure 4.2: Resposta da segunda questão.
4.2.2 Requisitos de Produto
4.2.2.1 Integridade e Segurança
Identificador Descrição
RNF/SEG-01 Apenas o usuário autenticado terá acesso aos tokens gerados durante
o processo de autenticação nas redes sociais.
RNF/SEG-02 As informações dos usuários devem ser armazenadas apenas localmente
e não devem ser fornecidas a terceiros.
RNF/SEG-03 Todas as requisições de informações referentes ao usuário autenticado
devem ser feitas diretamente para o servidor da rede social que ele
esteja administrando no momento.
4.2.2.2 Eficiência
Identificador Descrição
RNF/PER-01 O tempo de resposta para análise de dados dos usuários não deve
exceder 30 segundos. Para qualquer outra operação do sistema, esse
não deve exceder 5 segundos.
RNF/PER-02 O espaço dispońıvel em disco para informações deve ser suficiente para
armazenar todos os dados/atualizações que forem carregados dos servi-
dores das redes sociais.
28
–
Figure 4.3: Resposta da terceira questão.
–
Figure 4.4: Resposta da quarta questão.
–
Figure 4.5: Resposta da quinta questão.
29
–
Figure 4.6: Resposta da sexta questão.
4.2.3 Requisitos Externos
4.2.3.1 Legais
Identificador Descrição
RNF/LEG-01 O aplicativo deve respeitar os termos de uso das APIs das redes sociais
que fazem parte dele.
RNF/LEG-02 Não replicar a experiência de uso dos aplicativos oficiais das redes
sociais.
4.2.3.2 Éticos
Identificador Descrição
RNF/ETI-01 Não compartilhar dados dos usuários com terceiros.
RNF/ETI-02 Não utilizar as informações e mı́dias dos usuários para quaisquer fins que
não estejam diretamente relacionados com o funcionamento do aplica-
tivo.
RNF/ETI-03 Manter os dados dos usuários armazenados apenas pelo peŕıodo
necessário para prover os serviços do aplicativo.
4.3 Requisitos Funcionais
O quadro abaixo apresenta os requisitos funcionais do sistema acompanhados de
seus identificadores e prioridades atribúıdas durante o desenvolvimento.
30
–
Figure 4.7: Resposta da sétima questão.
Identificador Nome Prioridade
RF-01 Vincular rede social Essencial
RF-02 Desvincular rede social Essencial
RF-03 Visualizar resumo do perfil Essencial
RF-04 Visualizar conexões Essencial
RF-05 Desfazer amizade / deixar de seguir usuário Essencial
RF-06 Fazer amizade / seguir usuário Importante
RF-07 Filtrar conexões Importante
4.3.1 RF-01 - Vincular rede social
Descrição: O aplicativo deve permitir que o usuário se conecte através de uma
rede social.
Atores: Usuário
Prioridade: Essencial
Requisitos não funcionais associados: RNF/SEG
Entradas e pré-condições:
• O usuário não deve estar autenticado na rede social em questão.
Sáıdas e pós-condições:
• O usuário estará autenticado.
• Dados principais do usuário estarão salvos localmente.
31
–
Figure 4.8: Resposta da oitava questão.
Fluxo principal de eventos:
I. Ao abrir o aplicativo, a tela de login é exibida e o usuário escolhe a qual rede social
quer se conectar.
II. É aberta uma janela para que o usuário se autentique diretamente com o servidor
da rede social, que retornará um token.
III. O sistema recebe os dados de autenticação do usuário os salva localmente.
IV. O sistema carrega os dados básicos do usuário e carrega a tela principal.
Fluxos secundários:
• No fluxo principal II, se o usuário não conseguir se autenticar, o sistema exibe uma
mensagem de erro e o fluxo volta ao passo I.
4.3.2 RF-02 - Desvincular rede social
Descrição: O aplicativo deve permitir que o usuário se desconecte de uma rede
social.
Atores: Usuário
Prioridade: Essencial
Requisitos não funcionais associados: RNF/SEG
Entradas e pré-condições:
• O usuário deve estar autenticado na rede social que deseja se desconectar.
32
Sáıdas e pós-condições:
• O usuário não estará autenticado na rede social em questão.
Fluxo principal de eventos:
I. O usuário escolhe a opção de sair de determinada conta no menu do aplicativo.
II. O sistema deleta todos os dados locais referentes à rede social em questão.
III. A tela de login é exibida.
4.3.3 RF-03 - Visualizar resumo do perfil
Descrição: O aplicativo deve permitir que o usuário veja o resumo do perfil de
uma rede social.
Atores: Usuário
Prioridade: Essencial
Requisitosnão funcionais associados: RNF/SEG
Entradas e pré-condições:
• O usuário deve estar autenticado na rede social que deseja visualizar seu perfil.
Sáıdas e pós-condições:
• O usuário visualizará o resumo do seu perfil incluindo dados de conexões com outros
usuários.
Fluxo principal de eventos:
I. O usuário seleciona a opção de ver o seu perfil no menu do aplicativo.
II. O aplicativo mostra os dados do usuário.
4.3.4 RF-04 - Visualizar conexões
Descrição: O aplicativo deve permitir que o usuário veja suas conexões, aplicando
um filtro se desejar.
Atores: Usuário
Prioridade: Essencial
Requisitos não funcionais associados: RNF/SEG, RNF/PER-01, RNF/PER-
02
Entradas e pré-condições:
33
• O usuário deve estar autenticado na rede social que deseja visualizar seu perfil.
Sáıdas e pós-condições:
• O usuário visualizará o resumo do seu perfil incluindo dados de conexões com outros
usuários.
Fluxo principal de eventos:
I. O usuário seleciona a opção de ver conexões no menu do aplicativo.
II. O aplicativo mostra as conexões do usuário.
4.3.5 RF-05 - Desfazer amizade / deixar de seguir usuário
Descrição: O aplicativo deve permitir que o usuário desfaça uma amizade ou deixe
de seguir algum usuário.
Atores: Usuário
Prioridade: Essencial
Requisitos funcionais associados: RF-04
Requisitos não funcionais associados: RNF/SEG, RNF/PER-01
Entradas e pré-condições:
• O usuário deve estar autenticado na rede social em questão.
• O usuário autenticado deve ter uma conexão com o usuário em questão.
Sáıdas e pós-condições:
• O usuário não será amigo ou não estará seguindo o usuário em questão.
Fluxo principal de eventos:
I. O usuário autenticado escolhe um usuário dentre seus amigos ou seguidores.
II. O usuário clica no botão de remover amizade/deixar de seguir.
III. O sistema faz a requisição para a rede social informando que o usuário quer desfazer
a conexão com o usuário.
IV. O usuário é informado sobre o sucesso da operação.
Fluxos secundários:
• No fluxo principal, caso aconteça algum erro, a operação é cancelada e o aplicativo
mostra uma mensagem de erro.
34
4.3.6 RF-06 - Fazer amizade / seguir usuário
Descrição: O aplicativo deve permitir que o usuário solicite amizade ou siga algum
usuário.
Atores: Usuário
Prioridade: Importante
Requisitos funcionais associados: RF-04
Requisitos não funcionais associados: RNF/SEG, RNF/PER-01
Entradas e pré-condições:
• O usuário deve estar autenticado na rede social em questão.
• O usuário autenticado não deve ter uma conexão com o usuário em questão.
Sáıdas e pós-condições:
• O usuário autenticado terá solicitado amizade ou terá seguido o usuário em questão.
Fluxo principal de eventos:
I. O usuário autenticado escolhe um usuário dentre seus amigos ou seguidores.
II. O usuário e clica no botão de solicitar amizade/seguir.
III. O sistema faz a requisição para a rede social informando que o usuário autentico
1ado quer ser amigo/seguir o usuário.
IV. O usuário autenticado é informado sobre o sucesso da operação.
Fluxos secundários:
• No fluxo principal, caso aconteça algum erro, a operação é cancelada e o aplicativo
mostra uma mensagem de erro.
4.3.7 RF-07 - Filtrar conexões
Descrição: O aplicativo deve permitir que o usuário filtre suas conexões para
gerenciá-las melhor.
Atores: Usuário
Prioridade: Importante
Anexos: RF-07.1
Requisitos funcionais associados: RF-04
Requisitos não funcionais associados: RNF/SEG, RNF/PER-01
Entradas e pré-condições:
• O usuário deve estar autenticado na rede social em questão.
35
• O usuário autenticado deve estar visualizando suas conexões.
Sáıdas e pós-condições:
• O usuário autenticado verá suas conexões filtradas de acordo com o filtro escolhido.
Fluxo principal de eventos:
I. O usuário escolhe um filtro de conexões.
II. O sistema faz a requisição de dados adicionais caso seja necessário.
III. O sistema filtra os dados.
IV. O usuário visualiza suas conexões filtradas.
Fluxos secundários:
• No fluxo principal, caso aconteça algum erro, a operação é cancelada e o aplicativo
mostra uma mensagem de erro.
4.3.7.1 Filtros de conexões
Os usuários devem poder escolher entre os seguintes filtros para filtrar os usuários:
a. Usuários com pouca interação
b. Usuários inativos
c. Usuários que o usuário logado segue, mas não o seguem de volta
d. Usuários que seguem o usuário logado, mas não são seguidos por ele
e. Novos amigos / seguidores
f. Usuários que desfizeram amizade / deixaram de seguir
4.4 Diagrama de Casos de Uso
O diagrama de casos de uso, expresso em UML (Unified Modeling Language), ex-
pressa os requisitos não funcionais do sistema na forma de casos de uso. Foi decidido que,
para cada requisito funcional, ter-se-á um caso de uso. Utilizando-se do diagrama de ca-
sos de uso do Social Manager, poder-se-á então construir o diagrama de classes do sistema.
36
4.5 Protótipos de Telas
A prototipação das telas foi realizada utilizando o software Marvel App, que permite
confeccionar protótipos de aplicativos
37
5 Projeto Arquitetural
O software utiliza o Ionic 2 e Angular 4 como frameworks. A arquitetura do Ionic
2 é baseada em camadas bem definidas, com separação de regras de negócios, templates
e serviços, através do Angular 4, que utiliza uma padronização de componentes reusáveis
e tem arquitetura inspirada em MVC (Model-View-Controller), porém flex́ıvel quando ao
controller. Para os templates de visualização, são utilizadas as linguagem de marcação
HTML5 e CSS, este com aux́ılio da biblioteca SASS, que proporciona maior reuso e
produtividade. Já para a lógica de negócios e controle da visualização do aplicativo,
tem-se páginas, serviços e componentes (controllers) implementados em TypeScript.
Como não há servidor intermediário entre a aplicação e as redes sociais, não há
nenhuma persistência de dados em quaisquer locais que não sejam o dispositivo do usuário.
Todos os dados são providos pelas redes sociais que o aplicativo gerencia.
38
6 Modelagem
6.1 Análise dos Casos de Uso
Para aumentar o ńıvel da especificação e reduzir a possibilidade de erros, será feito o
diagrama de sequência dos cinco principais casos de uso do sistema, bem como os contratos
de operação dos mesmos. Os casos de uso são: Visualizar Resumo do Perfil, Desvincular
Rede Social, Vincular Rede Social, Desfazer Amizade e Visualizar Conexões.
6.2 Diagramas de Sequência
A seguir, serão mostrados alguns diagramas de sequência referentes aos casos de
uso apresentados neste documento, focando na interação entre os serviços promovidos
por cada classe da aplicação.
6.2.1 Diagrama de Sequência - Caso de Uso: Vincular Rede Social
Figure 6.1: Diagrama de sequência do caso de uso Vincular Rede Social
39
6.2.2 Diagrama de Sequência - Caso de Uso: Desvincular Rede
Social
Figure 6.2: Diagrama de sequência do caso de uso Desvincular Rede Social
40
6.2.3 Diagrama de Sequência - Caso de Uso: Deixar de Seguir um
Perfil
Figure 6.3: Diagrama de sequência do caso de uso Deixar de Seguir um Perfil
41
6.2.4 Diagrama de Sequência - Caso de Uso: Visualizar resumo do
perfil
Figure 6.4: Diagrama de sequência do caso de uso Deixar de Seguir um Perfil
42
6.2.5 Diagrama de Sequência - Caso de Uso: Começar a Seguir um
perfil
Figure 6.5: Diagrama de sequência do caso de uso Começar a Seguir um Perfil
6.3 Contratos de Operação
Para especificar de maneira mais clara quais são os requisitos de cada caso de uso,
foram feitas algumas tabelas especificando o comportamento esperado do sistema para
cada caso de uso aqui detalhado.
Table 6.1
Contrato Vincular Rede Social
Operação login()
Pré-Condição O usuário não esteja conectado na rede social.
Pós-Condição O usuário estará logado e seus dados básicos estarão devidamente carregados e salvos no aplicativo.43
Table 6.2
Contrato Desvincular Rede Social
Operação logout()
Pré-Condição A rede social a qual o usuário deseja-se desconectar deve ter sido vinculada anteriormente.
Pós-Condição Os dados da conta do usuário devem ter sido exclúıdos do sistema.
Table 6.3
Contrato Deixar de Seguir um Usuário
Operação unfollow(userID: string)
Pré-Condição O usuário estar logado na rede social e seguir o perfil que será usado na operação.
Pós-Condição O perfil passado não estará mais na lista de seguidores do usuário.
Table 6.4
Contrato Começar a Seguir um Usuário
Operação follow(userID: string)
Pré-Condição O usuário estar logado na rede social e não seguir o perfil que será usado na operação.
Pós-Condição O perfil passado agora estará na lista de seguidores do usuário.
44
7 Especificação Formal
Semelhante o que ocorre em outras engenharias, para aumentar a confiabilidade e
a consistência do desenvolvimento deste produto optou-se por realizar uma especificação
baseada em formalismos matemáticos.
Contudo, dado o alto ńıvel técnico requerido para realizar esse tipo de atividade
constrúımos a especificação em Alloy, considerados por muitos um método formal leve,
com o intuito de estudar o comportamento do sistema precavendo situações inesperadas
nos mais distintos cenários. Todo o código utilizado para gerar o seguintes cenários podem
ser encontrados no nosso repositório do github.
Figure 7.1: Um único usuário. Figure 7.2: Dois Usuários com suas respecti-
vas mı́dias.
Aqui é posśıvel observar as relações básicas entre usuário, mı́dias e comentários.
Uma mı́dia pertence há um único usuário exclusivamente, e o mesmo acontece entre
mı́dia e comentário.
Neste segundo cenário, podemos observar o comportamento descrito no cenário
acima. Além disto, foi definido a relação entre followers e following, onde um usuário
A que segue o usuário B tem B na lista de following, e B possui o usuário A na lista de
followers.
45
8 Implementação
Depois de definido o que seria a aplicação, o grupo reuniu-se para decidir qual tec-
nologia usar. Como seria uma aplicação móvel que não usa muitos recursos espećıficos
do sistema operacional, optamos por utilizar um framework que usa tecnologias web para
criar aplicativos h́ıbridos, semelhantes aos desenvolvidos nativamente. O framework uti-
lizado chama-se Ionic. Ele usa Angular 4, SCSS e HTML, além do Cordova, para criar
aplicações móveis. Estas aplicações podem ser portadas para diferentes sistemas opera-
cionais, o que estimulou mais ainda a adoção do Ionic, pois seria posśıvel alcançar mais
usuários com menos esforço. Além disso, os membros da equipe tinham mais experiência
com o desenvolvimento de aplicações web. Depois de decidido a tecnologia, a equipe de de-
senvolvimento passou por um peŕıodo de estudos para aprender os detalhes da framework
utilizada. Além disso, para facilitar o acesso aos recursos do Instagram, utilizou-se uma
biblioteca chamada Instajam, que facilita as requisições. Um dos primeiros problemas
no desenvolvimento foi a tecnologia. Dos quatro integrantes do time de desenvolvimento,
apenas um tinha familiaridade com Ionic e Angular 4. Isso foi contornado com um treina-
mento antes do ińıcio do desenvolvimento da aplicação. Porém, o que mostrou-se ser o
maior empecilho foi a própria API do Instagram. Por motivos de segurança, a empresa
restringe o acesso inicial para um ńıvel onde é posśıvel apenas fazer um número baixo de
requisições por hora, além de não poder alterar o relacionamento entre os usuários (como
deixar de seguir alguém). Isso impactou muito o desenvolvimento pois a equipe ficou di-
versos momentos impedida de testar a aplicação e perdeu muitas horas de trabalho. Além
disso, algumas funcionalidades, como parar de seguir um usuário, ainda não puderam ser
testadas pois o ńıvel de acesso atual não permite. Para tentar minimizar os problemas,
foi diminúıdo a quantidade de requisições feitas, otimizando alguns métodos e reduzindo
a quantidade de testes feitas entre a implementação de uma funcionalidade e outra. In-
felizmente, a alteração de relacionamento dos usuários não pode ser testada. Foi enviado
para o Instagram uma requisição de acesso total a API dela, porém tal autorização não
saiu a tempo da entrega do projeto.
46
9 Testes
9.1 Plano de testes
Durante processo de validação e verificação, foi necessária a criação de um plano de
testes. As funcionalidades do sistema devem ser testadas para que haja maior confiança de
que o software realmente funciona como planejado. Como o software não estava totalmente
pronto quando esta documentação foi escrita, os testes realmente implementados ficaram
limitados ao escopo das funcionalidades até então implementadas.
Para testes de unidade, escolheu-se as ferramentas Karma e Jasmine, dada sua
ampla adoção entre os projetos em Javascript.
A equipe definiu que seriam realizados testes de caixa branca e caixa preta. Ferra-
mentas de análise estática, como TSLint, também deveriam ser utilizadas para detectar
bad smells.
Para testes não funcionais, escolheu-se a ferramenta Monkey, que faz testes aleatórios
e sequenciais a fim de encontrar bugs em aplicativos.
9.2 Testes de unidade
Os testes de unidade tem, nesse projeto, o objetivo de verificar se as entidades estão
sendo devidamente criadas e se são funcionais. Além disso, os provedores da aplicação
também devem ser testados para garantir que os dados estão sendo corretamente carrega-
dos das redes sociais e se as falhas na execução dessas tarefas estão sendo devidamente
detectados e tratados. Nossa estratégia foi utilizar caixa branca no desenvolvimento dos
testes. No entanto, por limitação da API, essa etapa precisou ser colocada em segundo
plano, pois atrasaria bastante o desenvolvimento das funcionalidades básicas iniciais do
aplicativo.
9.3 Testes funcionais
Para testar os requisitos funcionais, foi utilizado o emulador de um dispositivo An-
droid. Realizou-se os testes de caixa preta, baseados nos fluxos descritos na especificação,
com escopo limitado aos casos de uso implementados até então.
47
9.3.1 RF-01 - Vincular rede social (Instagram)
I. Ao abrir o aplicativo, a tela de login é exibida e o usuário escolhe a qual rede
social quer se conectar.
Figure 9.1: Tela de login do aplicativo
II. É aberta uma janela para que o usuário se autentique diretamente com o servidor
da rede social, que retornará um token.
Figure 9.2: Tela de login da rede social
48
III. O sistema recebe os dados de autenticação do usuário os salva localmente.
IV. O sistema carrega os dados básicos do usuário e carrega a tela principal.
Figure 9.3: Tela principal do SocialManager
Fluxo secundário:
No fluxo principal II, se o usuário não conseguir se autenticar, o sistema exibe uma
mensagem de erro e o fluxo volta ao passo I.
Figure 9.4: Mensagem de erro
49
9.3.2 RF-02 - Desvincular rede social
I. O usuário escolhe a opção de sair de determinada conta no menu do aplicativo.
Figure 9.5: Menu do aplicativo
II. O sistema deleta todos os dados locais referentes à rede social em questão.
III. A tela de login é exibida.
50
Figure 9.6: Tela de login do aplicativo
9.3.3 RF-03 - Ver resumo do perfil
Este requisito não foi totalmente implementado e, por ora, faz parte do menu do
aplicativo, como mostrado no RF-02.
9.3.4 RF-04 - Visualizar conexões
Este requisito possui filtros de conexão. Por ora, esses filtros estão implementados
como opções no menu do aplicativo. Abaixo segue o fluxo principal para o filtro de
seguidores mútuos.
I. O usuário seleciona a opção de ver conexões no menu do aplicativo.
51
Figure 9.7: Menu do aplicativo
II. O aplicativo mostra as conexões do usuário.
Figure 9.8: Conexões mútuas
9.3.5 RF-05 - Desfazer amizade / deixar de seguir usuário
Este requisito está parcialmente implementado.Como é posśıvel observar no screen-
shot abaixo, para cada usuário seguido pelo usuário autenticado, há a opção de unfollow.
52
Figure 9.9: Opção de unfollow na lista de usuários
9.3.6 RF-06 - Fazer amizade / seguir usuário
Este requisito não foi implementado porque não fez parte de nenhuma sprint até
então.
9.3.7 RF-07 - Filtrar conexões
Este requisito não foi implementado porque não fez parte de nenhuma sprint até
então. No entando, como foi citado no RF-04, é posśıvel fazer tal filtragem a partir do
menu do aplicativo.
9.4 Testes não-funcionais
53
10 Projeto Real
10.1 Introdução
10.1.1 Motivação
Analisar um projeto real é essencial para um maior aproveitamento da disciplina, já
que podemos identificar caracteŕısticas, teorias e práticas (positivas e/ou negativas) que
estão sendo discutidas em sala de aula, possibilitando a construção de uma visão mais
abrangente do que é desenvolver software no mundo profissional.
10.1.2 Seleção
Os critérios utilizados para seleção do projeto foram:
• Linguagem: O projeto precisava ser escrito em Java.
• Número de linhas de código: O projeto precisava ter no mı́nimo 10 mil linhas de
código.
• Boas práticas de Software: Para a equipe, era essencial que o projeto fosse bem
estruturado, escrito de forma simples e bem documentado.
10.1.3 JInstagram
O JInstagram é uma biblioteca não oficial para a API do Instagram. Alguns projetos
que usaram o JInstagram:
• Digital Foot Prints - http://digitalfootprints.dk/
• Tweet Wall Pro - http://www.tweetwallpro.com/
• REnsta: Instagram Repost Add for Android - https://play.google.com/stor/apps/details?id=com.sembozdemir.renstagram
• OpSocial - http://www.opsocial.com.br/
54
10.2 Análise
10.2.1 Metrics
Resultado obtido ao rodarmos a ferramenta Metrics no projeto JInstagram:
Figure 10.1: Resultados do Metrics
10.2.1.1 Análise dos resultados
Total Lines of Code: Essa métrica se refere a quantidade de linhas de código que
o projeto possui. No caso do JInstagram, 11095.
McCabe Cyclomatic Complexity: Essa métrica quantifica a complexidade do pro-
grama através da medida de caminhos linearmente independentes que ele possui. Quanto
maior a medida, mais complexo o código é. O McCabe Cyclomatic também indica a
quantidade de testes que deverão ser escritos para executar todos os fluxos do programa.
O máximo de complexidade ciclomática encontrada no JInstagram é 12.
Number of Parameters: Métrica que indica a quantidade de parâmetros que existe
nos métodos do código. Métodos com quantidade grande de parâmetros são dif́ıceis de
entender e consequentemente de modificar e reusar. No JInstagram, essa medida é 6.
/* (non-Javadoc)
55
* @see
org.jinstagram.InstagramClient#getRecentMediaFeed(java.lang.String,
int, java.lang.String, java.lang.String, java.util.Date,
java.util.Date)
*/
@Override
public MediaFeed getRecentMediaFeed(String userId, int count, String
minId, String maxId, Date maxTimeStamp,
Date minTimeStamp) throws InstagramException {
Preconditions.checkEmptyString(userId,
USER_ID_CANNOT_BE_NULL_OR_EMPTY);
Map<String, String> params = new HashMap<String, String>();
Number of Attributes: Métrica que mostra a quantidade de atributos por classe.
Classes com muitos atributos podem indicar problemas de coesão por coincidência, gerando
problemas na execução do problema. Tais classes devem ser refatoradas. No JInstagram,
há classes com 16 atributos, número considerável aceitável.
Number of Static Attributes: Métrica que demonstra a quantidade de atributos
estáticos no código. O JInstagram possui 122 no total, sendo este um número razoável
para a quantidade de linhas de código que o projeto possui.
Number of Methods: Métrica que conta a quantidade média de operações por classe,
sendo desejável que essa média varie entre 3 e 7 métodos, pois um valor acima dessa faixa
pode indicar que a classe é pouco coesa e possui um grau de complexidade maior que o
desejável, enquanto que um valor abaixo dessa faixa indica que a classe não é necessária e
que esta poderia ser decomposta em uma construção de dados. No JInstagram, a média
de métodos por classe é de aproximadamente 7.5, sendo esta, uma medida razoável. No
entanto, no projeto, há classe com 67 métodos, indicando uma alta complexidade.
Number of Static Methods: Métrica responsável por explicitar a quantidade de
métodos estáticos por classe. Apenas 11 métodos estáticos são encontrados no JInstagram.
Number of Overridden Methods: Métrica que analisa a quantidade de métodos so-
brescritos por outras classes. O projeto possui apenas 1 método sobrescrito, o que é uma
medida baixa, dado o número de linhas de código.
Lack of Cohesion of Methods: Coesão é um conceito muito importante em pro-
gramação OO. Ela indica se a classe representa uma ou várias abstrações. A ideia é que
se a classe apresenta mais de uma abstração, ela deve ser refatorada em mais de uma
classe. O Metrics apresentou resultado médio de 0,235 para o JInstagram, dando a en-
tender que as classes do projeto são relativamente coesas.
56
/* (non-Javadoc)
* @see
org.jinstagram.InstagramClient#searchFoursquareVenue(java.lang.String)
*/
@Override
public LocationSearchFeed searchFoursquareVenue(String foursquareId)
throws InstagramException {
Map<String, String> params = new HashMap<String, String>();
params.put(QueryParam.FOURSQUARE_V2_ID, foursquareId);
return createInstagramObject(Verbs.GET, LocationSearchFeed.class,
Methods.LOCATIONS_SEARCH, params);
}
Figure 10.2: Método que ilustra a baixa quantidade de linhas de código por método.
Nested Block Depth: Métrica que se refere a profundidade dos blocos aninhados nos
métodos das classes, ou seja, através dela é posśıvel se ter uma ideia do tamanho e da
complexidade dos métodos do projeto. O Metrics apresentou valor um valor 0.942, que
é um valor baixo, significando que os métodos aparentemente não precisam ser divididos
em outros menores.
Methods Lines of Code: Métrica que mostra a quantidade de linhas de código por
método. O JInstagram apresenta uma média aproximada de 5 linhas de código por
método, o que acarreta em um código coeso, fácil de ler e de modificar.
Instability: Essa métrica mede o esforço necessário para alterar um pacote sem a neces-
sidade de alterar outros como consequência. A instabilidade (I) é um valor que varia entre
0.0 (mı́nima instabilidade) e 1.0 (máxima instabilidade) e que determina quão instável é
um pacote. Esse valor pode ser calculado pela seguinte equação: I = Ae Aa + Ae
Onde Ae são os acoplamentos eferentes e Aa são os acoplamentos aferentes. A
medida média dessa métrica para o JInstagram é 0.674, o que não é uma medida boa,
indicando que os pacotes do projeto são, em média, instáveis.
Abstractness: Essa métrica mede o quão abstrato um pacote é. Seu cálculo se dá
através da razão entre a soma das quantidades de classes abstratas (Ca) e interfaces (I)
pela quantidade de classes não-abstratas (Cn): A = (Ca + I)/Cn
O valor da métrica varia entre 0.0 (pacote concreto) e 1.0 (pacote abstrato). O
Metrics apresentou valor médio 0,035 para os pacotes do JInstagram, dando a entender
que os pacotes possuem poucas classes abstratas e interfaces se comparado com o número
de classes não-abstratas em seus pacotes.
Weighted methods per Class: A métrica WMC é a soma da complexidade de todos
57
os métodos por classe, sendo um indicador da quantidade de esforço que é demandada
para desenvolver e manter uma determinada classe. O valor médio dessa métrica para o
JInstagram foi de 8.88, que é um valor considerado bom, pois está dentro do limite (1 até
50).
10.2.2 Findbugs
A análise de bugs, realizada com a ferramenta Findbugs, identificou um total de
321 ocorrências de bugs em todo o projeto. A prinćıpio, a ferramenta qualifica os eventos
detectados, e os divide em categorias. As categorias identificadasno JInstagram foram:
Bad practice (más práticas), Correctness (corretude), Internationalization (internacional-
ização), Performance (performance) e Dodgy code (código espertalhão).
Figure 10.3: Categorias de bugs identificados pelo Findbugs
10.2.2.1 Más Práticas
Esta categoria agrupa todas as ocorrências identificadas de bugs que são causados
pelo uso de más práticas de programação.
Figure 10.4: Bugs da categoria Bad Pratice identificados no projeto.
As 3 ocorrências desta categoria no projeto são do tipo Format string problem
(problemas de formatação de string), e todas elas ocorrem pelo mesmo motivo, que é a
utilização de “
n” para realizar uma quebra de linha. Na formatação de strings, é prefeŕıvel utilizar “%n”,
que produzirá o caractere de quebra de linha espećıfico da plataforma onde o programa
está sendo executado, ou usar o método getLineSeparator() da classe System, que possui
a mesma finalidade.
10.2.2.2 Corretude
Nesta categoria são indicadas as ocorrências onde o código escrito realiza algo não
previsto pelo desenvolvedor.
58
private static final String EXCEPTION_PATTERN = "Error in method {0}."
+ "\n\tException name: {1}.\n\t"
+ "Stack trace: {2}.\n\tTime spent in the method: {3}
milliseconds.";
Figure 10.5: Exemplo de ”Format string problem”.
Figure 10.6: Bugs da categoria Correctness identificados no projeto.”
Duas das 3 ocorrências de bugs desta categoria no projeto são do tipo Null pointer
dereference (desreferencia de um ponteiro nulo), onde valores nulos são passados como
parâmetros de métodos que não devem ser nulos, e a outra é do tipo Format string prob-
lem, onde a formatação informada para a string é do tipo MessageFormat, quando a mais
indicada seria a utilizada no “printf”. Em tempo de execução, todos os argumentos de
formatação serão ignorados e a string retornada será exatamente como provida, sem nen-
huma formatação.
10.2.2.3 Internacionalização
Todas as ocorrências desta categoria são do tipo Dubious method used (uso duvidoso
de método), e acontecem pelo mesmo motivo: o código chama um método que executará
uma conversão byte-string (ou vice-versa) assumindo que a codificação da plataforma é a
adequada, fazendo com que o comportamento do programa varie entre plataformas.
59
String sig = EnforceSignedRequestUtils.signature(rawMethodName,
sigParams, accessToken != null ?
accessToken.getSecret() : null);
Add Comment
Figure 10.7: Exemplo de “Null pointer dereference”
Figure 10.8: Exemplo de ”Format string problem”.
10.2.2.4 Performance
Esta categoria agrupa as ocorrências de trechos de códigos no projeto que não
estão necessariamente errados, mas que podem ser melhorados a fim de obter um melhor
desempenho.
O bug do tipo Questionable boxing of primitive value (encaixotamento questionável
de um valor primitivo) ocorre ao utilizar o método valueOf(), criando um encaixotamento
a partir de uma string apenas para extrair o valor primitivo, quando seria mais eficiente
utilizar o método estático parseXXX, onde XXX é o tipo primitivo desejado. A ocorrência
do tipo Unread field (campo não lido) se dá ao utilizar um campo que nunca é lido e
poderia, portanto, ser removido da classe.
10.2.2.5 Código espertalhão
Nesta categoria são agrupadas as ocorrências de bugs relacionados à trechos de
códigos desnecessários ou até mesmo fluxos que nunca serão executados.
Esta é a categoria com maior número de ocorrências de bugs do projeto. Das 307
identificadas pela ferramenta, 306 são do tipo Useless code (código inútil), e acontecem
quando o trecho de código não realiza nenhum trabalho útil, ou quando um objeto é criado
e modificado, mas não produz nenhum efeito colateral nem é utilizado fora do método
onde foi criado. A outra ocorrência é do tipo Dead local store (armazenamento local
morto), e se dá quando o trecho de código associa um valor à uma variável local, mas a
variável não é lida ou utilizada em nenhuma instrução subsequente.
byte[] content = "Dummy Payload".getBytes();
Figure 10.9: Exemplo de “Dubious method used”
60
Figure 10.10: Bugs da categoria Performance identificados no projeto.
try {
value = Integer.valueOf(intValueStr);
} catch (NumberFormatException e) {
logger.error("Invalid Integer value for key: " + key + ", value :"
+ intValueStr);
}
Figure 10.11: Exemplo de “Questionable boxing of primitive value”
10.2.3 Análise de qualidade: iPlasma
Para complementar a análise da qualidade do projeto em questão, utilizamos a
ferramenta iPlasma a fim de gerar a seguinte pirâmide de qualidade:
Algumas observações a partir do resultado gerado pela ferramenta:
• O número de subclasses de uma classe é médio, o que indica um bom potencial de
reuso.
• O número de métodos por classe é alto, o que acarreta em classes menos coesas e
mais dif́ıceis de reusar e modificar.
• A quantidade de caminhos de execução independentes é baixa, o que culmina em
um código menos complexo.
• O resultado para a profundidade que as classes do projeto se encontram na árvore
de herança é médio, o que pode gerar classes mais complexas por herdarem o com-
portamento de todas as suas classes precursoras.
Métrica Referência Baixo Referência Médio Referência Alto Valor Obtido Resultado
NDD 0.25 0.41 0.57 0.03 Baixo
HIT 0.09 0.21 0.32 0.10 Médio
NOC 6 17 26 7.22 Médio
NOM 4 7 10 7.99 Médio
LOC 7 10 13 7.70 Médio
CYCLO 0.16 0.20 0.24 0.13 Baixo
CALL 2.01 2.62 3.20 4.09 Alto
FOUT 0.56 0.62 0.68 0.35 Baixo
61
Figure 10.12: Bugs da categoria Dodgy Code identificados no projeto.”
Figure 10.13: Exemplo de “Dead local store”.
Tanto os resultados obtidos através da ferramenta iPlasma, quanto os obtidos pela
ferramenta Metrics, nos fornecem uma visão geral a respeito da qualidade do código do
projeto real em questão. É interessante perceber que existem métricas que obtiveram
valores similares nas duas ferramentas, como a complexidade ciclomática (ambas apre-
sentaram valor baixo). Em contraste, a métrica número de métodos por classe, que foi
avaliada como baixa pelo Metrics, recebeu valor considerado médio, pelo iPlasma. Dessa
forma, o uso de mais de uma ferramenta é essencial para que, em caso de ocorrência desse
tipo de divergência, seja posśıvel uma investigação mais profunda a fim de decidir qual
dos resultados é o mais consistente.
10.3 Análise de Custo e Esforço
Para realizar a análise de custo, esforço e tempo foi utilizado o software SLOCCount.
Os resultados da análise feita pelo software se encontram na tabela a seguir:
SLOC Directory SLOC by Language
11103 jInstagram-master java=11103
Totals grouped by language (dominant language first):
java: 11103 (100.00%)
Total Physical Source Lines of Code (SLOC) = 11,103
Development Effort Estimate, Person-Years (Person-Months) = 2.50 (30.06)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 0.76 (9.11) (Basic COCOMO model,
Months = 2.5 * (person-month)
Estimated Average Number of Developers (Effort/Schedule) = 3.30
Total Estimated Cost to Develop = $ 338,340 (average salary = $56,286/year,
overhead = 2.40).
62
Figure 10.14: Pirâmide de Qualidade
10.4 Testes (Randoop)
O Randoop é um gerador de testes unitários em formato JUnit para Java. No JIn-
stagram, executamos os testes gerados durante 60 segundos para cada conjunto de classes
contidos nos pacotes do projeto. Os testes existentes antes da utilização do Randoop,
cobriam 53,7% do código das classes da pasta fonte do projeto.
Figure 10.15: Cobertura dos testes existentes no projeto.
Com os testes gerados pelo Randoop, a cobertura subiu para 58,8%, aumentando
em pouco mais de 5 pontos percentuais.
63
Figure 10.16: Cobertura dos testes gerados pelo Randoop.
Apesar da diferença entre os valores de cobertura ter sido pequena, ela foi suficiente
para identificar falhas e erros não detectados anteriormente pelos testes existentes no
projeto. Dos27528 casos de testes gerados pelo Randoop, 580 mostraram erros e outros
388 apontaram algum tipo de falha. Para os testes anteriores, nenhum dos 530 casos de
testes indicavam alguma falha ou erro.
Figure 10.17: Cobertura dos testes antigos em um trecho de código.
64
Figure 10.18: Cobertura dos testes gerados pelo Randoop em um trecho de código.
10.5 Evolução
10.5.1 Refatorando o sistema
O sistema foi refatorado utilizando as informações geradas pela ferramenta Metrics,
buscando sempre melhorar as métricas mais problemáticas.
O Metrics indicou alguns métodos com um alto numero de linhas de código. Sele-
cionamos a classe Instagram para realizar um refatoramento, pois a mesma possúıa uma
média de 6,167.
Figure 10.19: Número de linhas por método da classe Instagram antes do refatoramento.
Aplicando três extract method no método request, esse valor caiu para 5,133, dimin-
uindo o valor máximo de linhas de código por método da classe de 43 para 17.
Figure 10.20: Número de linhas por método da classe Instagram após o refatoramento.
Como pode-se observar, houve um decréscimo de pouco mais de 1 ponto na média.
Neste refatoramento, foram realizadas 32 remoções e 44 adições.
Seguindo a mesma métrica, foram realizados mais extract methods na classe In-
stagramBase, que possúıa uma média de 5,319 linhas de código por método, e um valor
máximo de 28 linhas. Após os refatoramentos, a média baixou para 5,04 e o valor máximo
baixou para 19. Neste refatoramento, foram realizadas 64 remoções e 95 adições.
65
Figure 10.21: Diff de um dos extract methods realizados na classe InstagramBase.
A classe InstagramSubscription também foi refatorada seguindo a mesma métrica.
Antes do refatoramento, sua média de linhas de código por método era de 7,2, com um
valor máximo de 23. Após a realização de um extract method, a média cai para 6,9. Neste
refatoramento, foram realizadas 5 remoções e 9 adições. Mesmo que as mudanças tenham
sido pequenas, foram suficientes para baixar a média de linhas de código por método da
classe.
Figure 10.22: Diff do refatoramento realizado na classe InstagramSubscription.
O Metrics identificou, ainda, que a classe OEmbedInformation possúıa um alto valor
de complexidade ciclomática. Antes do refatoramento, a média era de 1,355, e o valor
máximo de complexidade era 12.
Figure 10.23: Complexidade ciclomática da classe antes do refatoramento.
Ficou claro que a alta complexidade devia-se às várias condições ternárias existentes
no método toString da classe. Após a criação de um método auxiliar que pôde ser reusado
em todas as verificações, a média baixou para 1,031, e o valor máximo para 2.
Figure 10.24: Complexidade ciclomática da classe depois do refatoramento.
66
Neste refatoramento, ocorreram 35 remoções e 42 adições, como mostra o diff a
seguir.
Figure 10.25: Diff do refatoramento feito na classe OEmbedInformation.
No geral, mesmo antes dos refatoramentos, a maioria das métricas identificadas
estavam na faixa dos valores considerados aceitáveis. Algumas métricas, como a com-
plexidade cliclomática e número de linhas por métodos, que não estavam nessa faixa
anteriormente, passaram a estar após os refatoramentos.
10.5.2 Pirâmide do iPlasma após os refatoramentos.
Após realizados os refatoramentos, a ferramenta iPlasma foi novamente executada
em cima do projeto. A pirâmide resultante está representada logo abaixo.
Figure 10.26: Pirâmide do iPlasma após os refatoramentos.
Utilizando uma tabela para visualizar a diferença entres os valores antes e após os
refatoramentos, temos:
67
Métricas Valor antes do refatora-
mento
Valor após refatora-
mento
NDD 0.03 0.03
HIT 0.10 0.10
NOC 7.22 7.22
NOM 8.04 8,04
LOC 7.67 7.67
CYCLO 0.13 0.13
CALL 4.08 4.08
FOUT 0.35 0.35
Podemos observar que, após os refatoramentos, os valores das métricas continuaram
os mesmos. Uma das razões para isso, é que o projeto sempre apresentou métricas con-
sideradas normais, mesmo antes do refatoramento, com poucas ocorrências de métricas
problemáticas. Por serem poucas, dado a quantidade de linhas de código, o refatoramento
guiado por essas métricas não acarretaram numa mudança significativa desses valores.
68
Bibliography
[1] Narciso Cerpa and June M. Verner. Why did your project fail? Commun. ACM,
52(12):130–134, December 2009.
[2] Roy K. Clemmons. Project estimation with use case points. 2006.
[3] Luiz Duarte. Planning poker: como estimar tempo de desenvolvimento de soft-
ware, 2016. http://www.luiztools.com.br/post/planning-poker-como-estimar-tempo-
de-desenvolvimento-de-software/ - acessado em 27 de junho de 2017.
[4] Smart Insights. New global social media research, 2017.
http://www.smartinsights.com/social-media-marketing/social-media-strategy/new-
global-social-media-research/ - acessado em 26 de maio de 2017.
[5] Social Media Today. How much time do people spend on social me-
dia, 2017. http://www.socialmediatoday.com/marketing/how-much-time-do-people-
spend-social-media-infographic - acessado em 26-Maio-2017.
69
	Introdução
	Motivação
	Visão da Solução
	Descrição do Documento
	Planejamento
	Introdução
	Escolha da Rede Social
	Gerência de Tempo
	Estimativa de tempo com UCP
	Cálculo de UUCP
	Cálculo do UUCW:
	Cálculo do UAW:
	Cálculo de TCF
	Cálculo de ECF
	Estimativa de horas
	Primeira Entrega
	Cronograma da primeira entrega
	Lições aprendidas com a primeira entrega
	Segunda entrega
	Definição da estratégia de estimativa de tempo de User Stories
	Sprint 1
	Cronograma da Segunda Entrega
	Acompanhamento da segunda entrega
	Lições aprendidas com a segunda entrega
	Gerência de Custo
	Gerência de Riscos
	Gerência de Recursos
	Processos de Software
	Requisitos
	Entrevista com stakeholders
	Requisitos Não Funcionais
	Requisitos de Processo
	Requisitos de Produto
	Integridade e Segurança
	Eficiência
	Requisitos Externos
	Legais
	Éticos
	Requisitos Funcionais
	RF-01 - Vincular rede social
	RF-02 - Desvincular rede social
	RF-03 - Visualizar resumo do perfil
	RF-04 - Visualizar conexões
	RF-05 - Desfazer amizade / deixar de seguir usuário
	RF-06 - Fazer amizade / seguir usuário
	RF-07 - Filtrar conexões
	Filtros de conexões
	Diagrama de Casos de Uso
	Protótipos de Telas
	Projeto Arquitetural
	Modelagem
	Análise dos Casos de Uso
	Diagramas de Sequência
	Diagrama de Sequência - Caso de Uso: Vincular Rede Social
	Diagrama de Sequência - Caso de Uso: Desvincular Rede Social
	Diagrama de Sequência - Caso de Uso: Deixar de Seguir um Perfil
	Diagrama de Sequência - Caso de Uso: Visualizar resumo do perfil
	Diagrama de Sequência - Caso de Uso: Começar a Seguir um perfil
	Contratos de Operação
	Especificação Formal
	Implementação
	Testes
	Plano de testes
	Testes de unidade
	Testes funcionais
	RF-01 - Vincular rede social (Instagram)
	RF-02 - Desvincular rede social
	RF-03 - Ver resumo do perfil
	RF-04 - Visualizar conexões
	RF-05 - Desfazer amizade / deixar de seguir usuário
	RF-06 - Fazer amizade / seguir usuário
	RF-07 - Filtrar conexões
	Testes não-funcionais
	Projeto Real
	Introdução
	Motivação
	Seleção
	JInstagram
	Análise
	Metrics
	Análise dos resultados
	Findbugs
	Más Práticas
	Corretude
	Internacionalização
	Performance
	Código espertalhão
	Análise de qualidade: iPlasma
	Análise de Custo e Esforço
	Testes (Randoop)
	Evolução
	Refatorando o sistema
	Pirâmide do iPlasma após os refatoramentos.