Processo de Desenvolvimento de Software

Prévia do material em texto

MCG241	–	Sistemas	de	Informação
Profa.	Laura	Emmanuella	A.	dos	S.	Santana
lauraemmanuella@macae.ufrj.br
Processo	de	Desenvolvimento	
de	Sistemas
Objetivos
• De#inir	engenharia	de	software
• Apresentar	modelos	de	processo	de	desenvolvimento	de	sistemas
• Apresentar	metodologias	ágeis	no	desenvolvimento	de	sistemas
• Permitir	que	o	aluno	compreenda	o	processo	de	
desenvolvimento	de	sistemas	de	informação	e	o	papel	do	
cliente	e	gestor	nesse	processo
2
O	que	é	engenharia	de	
software?
Engenharia	de	software
• Conjunto	de	ferramentas,	métodos	e	processos	para	o	
desenvolvimento	de	software	com	foco	em	sua	qualidade
• Visa	tratar	o	desenvolvimento	de	software	como	uma	atividade	de	
engenharia
• Desenvolvimento	de	modo	sistemático,	seguindo	processos	
bem	definidos
4
Processo	de	desenvolvimento	
de	software
Processo	de	Desenvolvimento	de	Software
6
• Dados	levantados	no	Chaos	Report	(estudo	
clássico	feito	pelo	Standish	Group)	sobre	
projetos	de	desenvolvimento	de	software	
mostram	o	grande	percentual	de	projetos	
entregues	fora	do	esperado	ou	cancelados	
entre	2011	e	2015
• Successful:	Projetos	de	software	que	
foram	entregues	dentro	do	prazo,	
dentro	do	orçamento	e	com	
funcionalidades	completas
• Challenged:	Projetos	que	foram	
entregues	fora	do	prazo,	fora	do	
orçamento	ou	com	funcionalidades	
incompletas
• Failed:	Projetos	cancelados
7
Processo	de	Desenvolvimento	de	Software
• Um	processo	de	desenvolvimento	de	software	é	um	conjunto	de	
atividades,	parcialmente	ordenadas,	com	a	finalidade	de	obter	um	
produto	de	software	
• É	estudado	dentro	da	área	de	Engenharia	de	Software,	sendo	
considerado	um	dos	principais	mecanismos	para	se	obter	software	de	
qualidade	e	cumprir	corretamente	os	contratos	de	
desenvolvimento
• Prazos,	orçamento	e	funcionalidades
8
Exemplo	de	pro8issionais	envolvidos
• Gerente	de	Projeto
• Responsável	pela	coordenação	das	atividades	necessárias	à	construção	do	sistema
• Define	orçamento,	prazos,	processo	de	desenvolvimento,	cronograma	de	execução	de	atividades,	
recursos,	etc...
• Especialista	do	domínio	(negócio)
• Possui	conhecimento	acerca	da	área	em	que	o	sistema	estará	inserido
• Muitas	vezes	é	o	cliente	usuário	do	sistema
• Analista	de	Sistema
• Interage	com	o	especialista	do	domínio	para	obter	conhecimento	acerca	dos	requisitos	do	sistema
• Responsável	pelo	levantamento	e	análise	dos	requisitos
• Arquiteto	de	software
• Elabora	a	arquitetura	do	sistema	como	um	todo
• Toma	decisões	sobre	quais	subsistemas	compõem	o	sistema	como	um	todo	e	quais	são	as	interfaces	entre	
esses	subsistemas
• Programador
• Implementa	o	sistema
9
Principais	atividades	do	
processo	de	desenvolvimento	
de	software
Principais	atividades	do	processo	de	
desenvolvimento	de	software
11
Levantamento 
de requisitos Análise Projeto (Design) Implementação Testes Implantação
Levantamento	de	requisitos
• A	equipe	tenta	entender	o	domínio	que	deve	ser	automatizado	pelo	
sistema
• Estudo	exploratório	das	necessidades	do	usuário
• Objetiva	o	desenvolvimento	de	um	sistema	correto,	através	do	
levantamento	dos	requisitos	funcionais	e	não	funcionais,	que	permite	
aos	desenvolvedores	entenderem	“o	que	o	sistema	deve	fazer”	e	
algumas	restrições	que	devem	ser	obedecidas
• Técnicas	adotadas:
• Entrevistas	com	o	especialista	e	usuários,	leitura	de	textos	referência	sobre	o	
domínio,	comparação	com	sistemas	já	existentes,...
12
Análise
• Os	requisitos	são	descritos	e	re?inados,	consolidando	o	
entendimento	do	sistema	e	permitindo	a	construção	de	modelos	
conceituais	do	sistema	(diagramas	que	mostram	as	principais	
funcionalidades	do	sistema	e	como	elas	se	relacionam	entre	si	e	com	os	
usuários)
• A	análise	não	leva	em	conta	o	ambiente	tecnológico	a	ser	utilizado,	ou	
seja,	não	entra	em	detalhes	de	implementação
• O	foco	de	interesse	nessa	atividade	é	tentar	construir	uma	estratégia	de	
solução	sem	se	preocupar	com	a	maneira	como	essa	estratégia	será	
realizada
13
Projeto	(Design)
• Aos	modelos	construídos	na	fase	de	análise	são	adicionadas	
restrições	tecnológicas,	como	por	exemplo:
• Arquitetura	física	do	sistema,	padrão	de	interface	gráfica,	algoritmos	
específicos,	gerenciador	de	banco	de	dados
• Produz	uma	descrição	computacional	do	que	o	software	deve	
fazer	de	uma	maneira	coerente	com	a	descrição	feita	na	análise
14
Implementação
• Na	implementação,	o	sistema	é	codi#icado,	ou	seja,	ocorre	a	
tradução	da	descrição	computacional	obtida	na	fase	de	projeto	em	
código	executável	mediante	o	uso	de	uma	ou	mais	linguagens	de	
programação
• EI 	o	resultado	concreto	da	disciplina	de	projeto	em	termos	de	
componentes,	scripts,	código	fonte	e	executáveis	
15
Teste
• Veri#ica-se	o	resultado	da	implementação	através	de	testes	tanto	
das	versões	intermediárias	quanto	as	versões	#inais	do	sistema
• Diversas	atividades	de	testes	são	realizadas	para	veri#icação	do	
sistema	construı́do,	levando-se	em	conta	a	especi#icação	feita	nas	
fases	de	análise	e	projeto
• Um	possıv́el	produto	dessa	fase	são	os	relatórios	de	testes,	que	
apresentam	informações	sobre	erros	detectados	no	software
16
Implantação
• O	sistema	é	empacotado,	distribuı́do	e	instalado	no	ambiente	do	
usuário
• Os	manuais	do	sistema	são	escritos,	os	arquivos	carregados,	os	
dados	são	importados	para	o	sistema	e	os	usuários	treinados	para	
utilizar	o	sistema	corretamente
• Em	alguns	casos,	nesse	momento	também	ocorre	a	migração	de	
sistemas	de	software	e	de	dados	preexistentes
17
Modelos	de	processo	de	
desenvolvimento	de	software
Modelos	de	desenvolvimento	de	software
• O	processo	de	desenvolvimento	de	sistemas	envolve	diversas	
atividades
• A	forma	como	essas	atividades	são	encadeadas	para	a	construção	
do	sistema	é	chamada	de	modelo	de	ciclo	de	vida
• Há	diversos	modelos	de	ciclo	de	vida	e	a	diferença	entre	eles	está	
na	maneira	como	as	várias	atividades	são	encadeadas
19
Modelos	de	desenvolvimento	de	software
• Exemplos	de	modelos
• Cascata
• Iterativo	e	incremental
• Ágil	(evolução	do	iterativo	e	incremental)
20
Modelo	em	cascata
• Modelo	mais	antigo	e	mais	amplamente	usado	por	muito	tempo
• Abordagem	sequencial
• O	resultado	de	uma	fase	é	a	entrada	da	fase	seguinte
21
Modelo	em	cascata
22
Problemas	do	modelo	em	cascata
• Projetos	reais	raramente	seguem	o	Cluxo	sequencial	que	o	
modelo	propõe	
• Logo	no	início	é	diCícil	estabelecer	explicitamente	todos	os	
requisitos.	No	começo	dos	projetos	sempre	existe	uma	incerteza	
natural	por	parte	do	cliente
• O	cliente	deve	ter	paciência.	Uma	versão	executável	do	software	
só	Cica	disponível	numa	etapa	avançada	do	desenvolvimento	
(na	implantação)	
23
Modelo	iterativo	e	incremental
• Processo	de	desenvolvimento	de	software	iterativo,	baseado	em	
re?inamentos	e	incrementos	sucessivos	a	Kim	de	convergir	para	um	
sistema	adequado	
• Em	cada	iteração	incrementa-se	um	pouco	mais	o	produto,	
baseando-se	na	experiência	obtida	nas	iterações	anteriores	e	no	
feedback	do	usuário
• Cada	iteração	pode	ser	considerada	um	miniprojeto	de	duração	Kixa,	
sendo	que	cada	um	destes	inclui	suas	próprias	atividades	de	análise	de	
requisitos,	projeto,	implementação	e	testes
24
Modelo	iterativo	e	incremental
25
Modelo	iterativo	e	incremental
• Em	cada	iteração	é	escolhido	um	pequeno	subconjunto	de	
requisitos,	os	quais	são	rapidamente	projetados,	
implementados	e	testados	pelos	usuários
• Isso	leva	a	uma	realimentação	rápida	-		baseada	em	dados	
concretos	de	usuários,	desenvolvedores	e	testes	–	que	possibilita	
modi#icar	ou	adaptar	a	compreensão	dos	requisitos	do	projeto
26
Metodologias	ágeis
27
O	que	é?
• Metodologias	ágeis	são	conjuntos	de	práticas	que	proporcionam	uma	
forma	de	gerenciar	projetos	mais	adaptável	às	mudanças
• Elas	são	estruturadas	em	ciclos	curtos	sendo	que,	a	cada	novo	ciclo,	é	
entregue	um	conjunto	de	funcionalidades	pré-determinado
• Portanto,	as	metodologias	ágeis	têm	como	principal	restrição	o	tempo	e	são	
caracterizadaspor	produzirem	entregas	rápidas	e	frequentes
• E? 	importante	ressaltar	que	as	metodologias	ágeis	partem	do	pressuposto	que	
a	condução	do	projeto	será	feita	por	uma	equipe	pequena	e	
autogerenciável
• Essa	equipe	normalmente	será	sênior,	multidisciplinar	e	concentrada	em	um	
único	local
• Todo	o	esforço	da	equipe	será	empregado	na	qualidade	da	solução	
apresentada,	que	deverá	acrescentar	alto	valor	para	o	cliente	do	projeto
28
Motivação
• Insatisfação	com	a	metodologia	aplicada	no	desenvolvimento	de	
software	que	levava	muito	tempo	desenvolvendo	
documentação	antes	de	implementar	e	entregar	o	software	ao	
cliente	e	quando	o	software	era	entregue	ao	cliente	algumas	
funcionalidades	já	não	reCletiam	mais	a	necessidade	do	
cliente	
• Devido	à	alta	mudança	nos	requisitos	ao	longo	do	tempo,	ou	seja,	
quanto	mais	demora	a	entrega,	maiores	as	chances	de	os	
requisitos	terem	mudado
29
Motivação
• Necessidade	de	diminuir	o	tempo	de	entrega	e	o	custo	na	
produção
• Custo	era	alto	devido	o	longo	processo	de	produção,	ferramentas	
muito	caras	para	modelagem	do	software	e	muitos	pro#issionais	
envolvidos	
30
O	manifesto	ágil
• O	Manifesto	AI gil	é	uma	declaração	de	princı́pios	que	fundamentam	
o	desenvolvimento	ágil	de	software
31
Vídeo: h3ps://www.youtube.com/watch?v=j5mCirZD-0s 
https://www.youtube.com/watch?v=j5mCirZD-0s
Documentação	no	desenvolvimento	
tradicional
• Documentação	tradicional	é	diferente	da	documentação	ágil
• Documentação	tradicional
• É	insumo	para	a	implementação	do	software,	ou	seja,	é	feita	antes	da	geração	de	
código
• É	detalhada,	pois	será	entregue	ao	cliente	junto	com	o	software
• Manutenção	difícil	e	custo	alto
• Após	todo	o	detalhamento	de	documentação	sobre	uma	funcionalidade,	a	funcionalidade	
é	implementada	e	apresentada	ao	cliente.	Se	o	cliente	precisar	modificar	aquela	
funcionalidade,	toda	a	documentação	deverá	ser	refeita	ou	alterada,	podendo	gerar	
inconsistência
• Muito	tempo	para	especificar	as	funcionalidades	antes	de	implementar	(lembre	
que	as	funcionalidades	geralmente	sofrem	alterações	por	parte	do	cliente	que	
nem	sempre	tem	certeza	do	que	quer	e	passa	a	ter	quando	vê	o	software	em	
funcionamento)
32
Vídeo: https://www.youtube.com/watch?v=3Smbhnmue7Y 
https://www.youtube.com/watch?v=3Smbhnmue7Y
Documentação	no	desenvolvimento	ágil
• Documentação	ágil
• EQ 	resultado	da	implementação,	ou	seja,	após	a	funcionalidade	ser	
implementada	e	validada	pelo	cliente,	é	gerada	alguma	documentação	mıńima	
quando	o	cliente	contrata	essa	entrega	(software	+	documentação)
• Documenta-se	sempre	que	o	benefıćio	superar	o	custo
• Algumas	vezes	pode-se	criar	desenhos	para	auxiliar	no	entendimento	da	solução,	
mas	descartá-los	depois,	eliminando	o	custo	da	manutenção	desse	documento
• Ao	invés	de	vasta	documentação,	prioriza-se	a	comunicação	verbal	entre	os	
membros	da	equipe
• Equipes	pequenas
• Trabalhando	no	mesmo	espaço	4ísico
• Pequenos	incrementos	no	software	de	cada	vez
• Participação	muito	próxima	do	cliente
34
Resumo	sobre	a	documentação	no	
desenvolvimento	ágil
36
SCRUM
Imagens	retiradas	do	vı́deo:	
https://www.youtube.com/watch?v=XfvQWnRgxG0	
37
https://www.youtube.com/watch?v=XfvQWnRgxG0
O	que	é?
• O	Scrum	é	uma		ferramenta	que	contém	processos	e	técnicas	de	
gestão	ágil	para	o	desenvolvimento	de	projetos	de	software
• Quando	usar?
38
Práticas	fundamentais
39
Papéis
No	Scrum,	as	pessoas	envolvidas	no	
projeto	podem	assumir	três	papéis:	
product	owner,	scrum	master	e	
development	team
• O	product	owner	é	o	
responsável	por	gerenciar	o	
conjunto	de	funcionalidades	e	
características	que	o	produto	
deve	ter	(Product	Backlog).	
Portanto,	o	product	owner	atua	
como	representante	do	cliente
• O	scrum	master	é	o	responsável	
por	disseminar	o	scrum	pela	
organização,	garantindo	que	ele	
esteja	sendo	aplicado	de	forma	
correta.	Portanto,	atua	como	um	
facilitador
• Já	o	development	team	é	a	
equipe	de	desenvolvedores	
responsável	por	entregar	as	
funcionalidades	do	produto	e	o	
produto	Jinal
40
41
42
Tipos	de	reuniões
• O	scrum	tem	como	base	4	tipos	de	reunião
• A	primeira	reunião	é	o	sprint	planning	(reunião	de	planejamento	da	
sprint),	que	ocorre	no	primeiro	dia	da	sprint	e	é	o	momento	em	que	
criamos	o	backlog	da	sprint
• O	backlog	da	sprint	nada	mais	é	do	que	o	conjunto	de	funcionalidades	e	
caracterı́sticas	selecionadas	do	backlog	do	produto,	que	deve	ser	entregue	
ao	Xinal	da	sprint
• Nessa	reunião,	o	product	owner	vai	explicar	e	esclarecer	as	dúvidas	sobre	
os	itens	que	estão	no	backlog	e	o	development	team	vai	decompor	os	itens	
em	ações
43
44
Tipos	de	reuniões
• Todos	os	dias	é	realizado	o	daily	scrum,	uma	reunião	de	
alinhamento	em	que	o	time	conta	o	que	foi	feito	no	dia	anterior,	
planeja	o	que	será	feito	no	dia	e	elenca	elementos	e	situações	que	
podem	impedir	a	realização	do	que	foi	planejado	para	o	dia
• Nesse	ponto,	o	time	pode	levantar	dificuldades	e	riscos	que	
precisam	ser	removidos	pelo	scrum	master,	que	deve	atuar	na	
proteção	da	produtividade	da	equipe,	para	alcançar	os	objetivos	
estabelecidos	no	planejamento	do	sprint
45
Daily	Scrum
46
Tipos	de	reuniões
A	cada	conclusão	de	
sprint	é	feita	também	a	
sprint	review	que,	como	
o	próprio	nome	já	diz,	
trata-se	do	momento	em	
que	o	scrum team	veriKica	
se	o	que	foi	feito	está	de	
acordo	com	os	requisitos	
do	produto	e,	se	
necessário,	atualiza	o	
backlog	
47
Tipos	de	reuniões
Outra	reunião	feita	após	
a	conclusão	de	uma	
sprint	é	a	sprint	
retrospective,	em	que	o	
scrum	team	verifica	
possíveis	pontos	do	
processo	que	podem	ser	
melhorados.
48
Resumo