Slide 1

Prévia do material em texto

Profa. MSc. Priscila Facciolli
UNIDADE IV
Engenharia de 
Software I
 É uma coleção de conceitos, métodos e ferramentas de que o engenheiro de software faz 
uso no seu dia a dia.
 Determinam um modelo de processo de software que inclui atividades técnicas e gerenciais 
para o desenvolvimento da aplicação.
Práticas de Engenharia de Software
Envolve:
 Entender o problema: comunicação e análise.
 Planejar uma solução: modelagem e projeto.
 Executar o plano: geração do código.
 Examinar o resultado: realização de testes.
Práticas de Engenharia de Software
 A comunicação é a prática mais essencial e desafiadora para o desenvolvedor de software.
 É através da comunicação que as necessidades dos clientes são coletadas, utilizando 
entrevistas e outras técnicas.
 As falhas de comunicação são as maiores geradoras de conflitos durante o ciclo de vida 
do software.
Práticas de Comunicação
 Prepare-se antes de se comunicar.
 Sempre que possível, tenha um facilitador.
 Saiba ouvir.
 Faça a comunicação face a face.
 Faça anotações e documente as decisões.
 Envolva os participantes nas decisões.
 Tenha foco, não disperse com outros assuntos.
 Utilize figuras para facilitar o entendimento.
 Busque a negociação ganha-ganha.
Princípios da Comunicação
Comunicação Efetiva
Fonte: Livro-texto.
Interação 
face a face
Interação 
somente de voz
Interação escrita
Multimídia não 
interativa
Escrita não 
interativa
Formas de comunicação
 É uma técnica de reunião informal que pode ser utilizada em qualquer fase do 
desenvolvimento de software.
 É mais utilizada como técnica de revisão de qualquer produto técnico de software
antes de entregá-lo ao cliente.
 Também conhecida como revisão por pares, é muito simples e bem-aceita por todos.
Técnica de Reunião Walkthrough
Envolve três papéis:
 O autor,
 O revisor,
 O escriba.
Técnica:
 O autor descreve o produto técnico passo a passo para que o revisor faça os comentários.
 O escriba registra os apontamentos para posterior correção.
Técnica de Reunião Walkthrough
 É uma reunião de grupo em que há interação livre entre os participantes e substitui a técnica 
de entrevistas.
 Utilizada para definir os requisitos do projeto.
 Visa envolver o cliente como coautor do trabalho, e não apenas um interlocutor, aumentando 
o seu comprometimento.
Joint Application Development (JAD)
Envolve seis papéis:
 Facilitador,
 Usuários,
 Gerentes e desenvolvedores,
 Secretário,
 Observador.
Joint Application Development (JAD)
Fases:
 Definição do tema,
 Pesquisa,
 Preparação,
 Reunião,
 Elaboração do documento final.
Joint Application Development (JAD)
Práticas de uma reunião JAD:
 Agende com antecedência e comunique a todos.
 Convoque as pessoas certas.
 Envie a agenda e documentos antes da reunião.
 Preestabeleça o horário de início e fim.
 Escolha local isento de influências e confortável.
 Utilize várias mídias (quadro, flipchart, etc.).
 Utilize formato arena na sala. 
 Foco 100% no assunto durante a reunião.
Joint Application Development (JAD)
 A prática de comunicação é essencial para o sucesso do desenvolvimento de software. 
Entre as opções abaixo, qual alternativa representa um dos princípios da comunicação 
efetiva?
a) Utilizar o processo cascata.
b) Comunicação face a face.
c) Tratar múltiplos assuntos.
d) Interromper sempre que achar necessário.
e) Procure uma negociação boa para você.
Interatividade
 A prática de comunicação é essencial para o sucesso do desenvolvimento de software. 
Entre as opções abaixo, qual alternativa representa um dos princípios da comunicação 
efetiva?
a) Utilizar o processo cascata.
b) Comunicação face a face.
c) Tratar múltiplos assuntos.
d) Interromper sempre que achar necessário.
e) Procure uma negociação boa para você.
Resposta
 A atividade de planejamento é essencial para aumentar a probabilidade de sucesso 
de um projeto de software.
 Não deve ser burocrático.
 Deve ser feito em ondas sucessivas, à medida que os objetivos do projeto vão evoluindo. 
 Deve ser realizado com a participação de todos os envolvidos.
Tática de Planejamento
Mas o que é um projeto? 
 É um empreendimento temporário para criar um produto único para atender as necessidade 
do seu cliente.
 O PMBOK (Project Management Body of Knowledge) é um guia de boas práticas em 
gerenciamento de projetos.
Baseia-se na tríplice restrição:
 Escopo, prazo, custo e qualidade.
Tática de Planejamento
Práticas de Planejamento − Fases de um Projeto
Fonte: Livro-texto.
Processos de 
monitoramento e controle
Processos de 
planejamento
Processos de 
execução
Processos de 
iniciação
Processos de 
encerramento
Plano do projeto:
 Reúne a documentação necessária para conduzir o projeto.
Deve conter:
 O escopo do projeto.
 O cronograma.
 O orçamento.
 Os riscos.
 Os recursos humanos necessários.
 Os padrões de qualidade esperados.
 Plano para a distribuição das informações.
Práticas de Planejamento – Plano do Projeto
Estrutura Analítica do Projeto (EAP):
 É a decomposição do escopo do projeto em produtos entregáveis com o objetivo de facilitar 
o entendimento e a validação do cliente.
Práticas do Planejamento − EAP
Fonte: Livro-texto.
Recursos:
 Qualquer variável requerida para a execução do projeto.
Alguns tipos de recursos:
 Pessoas, equipamentos, materiais, capital, instalações, entre outras.
Práticas do Planejamento
Responsabilidades:
 É a distribuição do trabalho para as pessoas da equipe do projeto.
 Para evitar conflitos durante o projeto, deve estar claro, para todos os envolvidos, 
quem é o responsável por cada atividade.
Práticas do Planejamento
Fonte: Livro-texto.
Comitê Presidente Marketing Operações 
Relações com acionista e conselho Suporte Principal 
Lançamento de novos produtos Aprova Notificado Principal Suporte 
Controlar orçamentos Suporte 
Programa de treinamento Principal 
............................ .............. .............. .............. ..............
Cronograma:
 É a descrição da sequência 
de atividades, suas 
durações e responsáveis 
para a realização do projeto.
 Envolve quem realizará 
a atividade.
 Determina o tempo total 
do projeto.
Práticas do Planejamento
Fonte: Livro-texto.
Problemas x Riscos
 É tudo aquilo que pode gerar problemas ao projeto.
 Consiste em um conjunto de atividades preventivas para evitar que ocorram problemas 
no projeto.
 Deve conter para cada risco: ações e contingências.
 Deve ser realizado durante todo o projeto.
Práticas do Planejamento: Análise de Riscos
Padrões de Qualidade:
 É a definição de “o quê será feito durante o projeto” para garantir que o produto esteja 
correto.
Plano de Comunicação:
 Deve descrever quais os métodos e para quem as informações de andamento do projeto 
devem ser distribuídas durante a fase de execução.
Prática de Planejamento
 As práticas de planejamento são essenciais para o sucesso de um projeto de software. 
Qual das alternativas abaixo está correta em relação a essa afirmação? 
a) Deve ser feito um cronograma.
b) É preciso definir o número de recursos necessários.
c) Deve ser feita uma análise de riscos.
d) Deve ser elaborada uma Estrutura Analítica do Projeto.
e) Todas estão corretas.
Interatividade
 As práticas de planejamento são essenciais para o sucesso de um projeto de software. 
Qual das alternativas abaixo está correta em relação a essa afirmação? 
a) Deve ser feito um cronograma.
b) É preciso definir o número de recursos necessários.
c) Deve ser feita uma análise de riscos.
d) Deve ser elaborada uma Estrutura Analítica do Projeto.
e) Todas estão corretas.
Resposta
 Consiste num conjunto de atividades para construir modelos (diagramas) que expliquem 
as características e comportamentos de um aplicativo de software.
 Registra o “o quê” e o “como” o software deve ser desenvolvido. Formaliza as definições e especificações obtidas junto ao cliente.
Práticas de Modelagem
Os modelos permitem ter:
 Um meio para a discussão.
 Um meio para comunicação.
 Uma base para a análise.
 Um simulador de situações.
 Uma base de controle.
 Um meio para garantir o correto funcionamento.
Práticas de Modelagem
 O foco da modelagem 
orientada a objetos está 
em ver o mundo como 
um conjunto de objetos 
que interagem entre si 
para produzir um 
resultado comum.
Modelagem Orientada a Objetos
Fonte: Livro-texto.
Principais características:
 Foco na modelagem das informações.
 Identificar os objetos do mundo real.
 Identificar suas características (atributos).
 Identificar seus comportamentos (métodos).
 Formam as classes, que são os blocos básicos para a construção.
Modelagem Orientada a Objetos
 Uma vez identificados os objetos, a relação entre eles forma o sistema a ser desenvolvido.
 Ele será construído a partir da interação entre esses objetos.
Modelagem Orientada a Objetos
Autor
+Nome : char
-Idade : int
+Incluir() : bool
-utiliza
-Nome ; char
-Memoria : int
+alteraNome()
+alteraMemoria()
0..* 1..*
Computador 
UML: Unified Modeling Language
 É a unificação das diversas linguagens de modelagem orientada a objetos existentes.
 Foi criada em 1995 por Booch, Rumbaugh e Jacobson, que unificaram os seus métodos 
Booch, OMT e OOSE, que eram os mais utilizados na época.
 A partir de 1999, passou a ser mantida pela OMG (Object Management Group) –
www.omg.org.
Modelagem Orientada a Objetos com UML
A UML divide os diagramas 
em 3 categorias:
 Estáticos: mostram a 
estrutura física do sistema e 
não envolvem as interações. 
Diagramas de Casos de Uso 
e de Classes.
 Exemplos:
Modelagem Orientada a Objetos com UML
Fonte: Livro-texto
Autor
+Nome : char
-Idade : int
+Incluir() : bool
-utiliza
-Nome ; char
-Memoria : int
+alteraNome()
+alteraMemoria()
0..* 1..*
Computador 
Ator 1
Ator 2
Caso de Uso 3
Caso de Uso 2
Caso de Uso 1
A UML divide os diagramas 
em 3 categorias:
 Dinâmicos: mostram a interação 
ativa entre os elementos 
estruturais do sistema. 
 Os principais são os diagramas 
de sequência, estado e de 
atividades.
 Exemplo:
Modelagem Orientada a Objetos com UML
Fonte: Livro-texto.
Curso Aberto
Curso 
Completado
Registro fechado
Adicionar Aluno
Interface Produto
: Cliente
Dados produto 
Pesquisar ()
Disponibilidade 
Evento 6
Evento 5
Sincronismo 
Evento 4
Evento 3
Atividade 4
Atividade 3Atividade 2
Tomada de 
decisão 1
Tomada de 
decisão 2
Evento 2
Atividade 1
Evento 1
Início 
Fim
 A UML divide os diagramas 
em 3 categorias:
 Arquiteturais: mostram a 
realização do sistema em 
componentes funcionais 
e executáveis. 
 Os principais Diagramas de 
Componentes e de 
Implantação.
 Exemplo:
Modelagem Orientada a Objetos com UML
Fonte: Livro-texto.
Cliente Pedido 
Produto 
Pagamento
Pagamento
Pedido
Servidor WEB
- Xenon 2.4 Ghz
- Linux
- TomCat
Application Server
- Unix 
- Sun Solaris
- Web Sphere
Banco de Dados
- W2K3
TCP/IP
TCP/IP
 A UML é a principal linguagem de modelagem orientada a objetos para o desenvolvimento 
de software e possui diversos diagramas para representar os objetos. O diagrama que 
mostra a interação entre esses objetos é o:
a) Diagrama de classes.
b) Diagrama de casos de uso.
c) Diagrama de sequência.
d) Diagrama de objetos.
e) Diagrama de componentes.
Interatividade
 A UML é a principal linguagem de modelagem orientada a objetos para o desenvolvimento 
de software e possui diversos diagramas para representar os objetos. O diagrama que 
mostra a interação entre esses objetos é o:
a) Diagrama de classes.
b) Diagrama de casos de uso.
c) Diagrama de sequência.
d) Diagrama de objetos.
e) Diagrama de componentes.
Resposta
 Define graficamente o fluxo de comportamento das regras de negócio do sistema.
 Foi publicado em 2004 pela OMG.
Objetivos:
 Fornecer uma notação fácil de entender por todos os envolvidos.
 Ser uma ferramenta de trabalho comum para usuários, analistas e desenvolvedores.
Modelagem de Processo de Negócio (BPMN)
Modelagem de Processo de Negócio (BPMN) – Notações Básicas
Fonte: Livro-texto.
Lane 
paciente
Atividade Evento-fim 
Recebe 
receita
Envia 
sintomas
Recebe pedido 
sintomas
Envia pedido 
médico
Ocorre 
doença
Eu quero ver o médico Eu me sinto doente
Fluxo de 
mensagem
Fluxo de 
sequência
Pegue sua receita 
para comprar 
remédios
O médico pede sintomas
Evento 
início
Envia pedido 
médico
Solicita 
sintomas
Recebe 
sintomas
Envia receita 
médica
C
o
n
s
u
lt
ó
ri
o
 m
é
d
ic
o
<
<
P
o
o
l>
>
<
<
P
o
o
l>
>
P
a
c
ie
n
te
Class SPMM
 Surgiu com o objetivo de criar especificações e modelos apoiados por ferramentas que, 
interpretadas pelo computador, gerem o código de forma automática ao seu final.
 Utiliza a linguagem DSL (Domain-Specific Language) para gerar essas especificações.
 Modelo ainda em fase de experimentos.
MDD – Model Driven Development
MDD – Model Driven Development – Principais elementos
Fonte: Livro-texto.
Modelo 
Mecanismo para 
executar 
transformações
Transformação Código-fonte 
Ferramenta para 
definir 
transformações 
Outros 
modelos
 É a fase que vem após as fases de requisitos e especificações de soluções conceituais. 
É o código.
 Diversas boas práticas devem ser observadas pelo engenheiro de software:
 Desenvolvimento incremental;
 Padrões de codificação;
 Definição da arquitetura;
 Verificação da qualidade;
 Testes constantes, entre outras. 
MDD – Model Driven Development
 A arquitetura define como o software deverá ser construído. É a definição da estrutura 
do sistema.
 O desenvolvimento baseado em componentes (CBSE) visa criar código que possa ser 
reutilizado dentro do sistema desenvolvido ou por outros sistemas.
 Seus principais objetivos são:
 Eliminar duplicação de código;
 Reduzir o tempo de desenvolvimento;
 Aumentar a qualidade.
Práticas de construção – Arquitetura baseada em componentes
 Envolve avaliar se o software desenvolvido está em um nível satisfatório de aceitação.
 Essa avaliação se dá através de testes contínuos durante o processo de desenvolvimento.
Práticas de construção – Verificação da qualidade
Fonte: Livro-texto.
Iteração 1 Iteração 2 Iteração 3
R
A/P
I
T/I
R
A/P
I
T/I
R
A/P
I
T/I
Teste Teste Teste
Tempo
 Controlar as mudanças que ocorrem durante o ciclo de desenvolvimento é uma das tarefas 
mais complexas da engenharia de software.
Os problemas mais comuns são:
 Codificação simultânea;
 Múltiplas versões;
 Alterações contínuas;
 É essencial o uso de ferramentas para o controle das mudanças.
Práticas de construção – Controle de mudanças
 Consiste nas atividades de liberação do software desenvolvido para o ambiente de produção 
do cliente.
A implantação deve garantir:
 Se o software for novo, que esteja completo e funcionando após a instalação.
 Se for uma alteração, que não cause problemas no ambiente e não afete a aplicação em uso.
Práticas de Implantação
Alguns cuidados importantes:
 Elaborar o plano de implantação em conjunto com todos os envolvidos.
 Verificar todo o hardware e software necessário no novo ambiente.
 Garantir o envolvimento de usuários-chaves.
 Ter um processo de retorno à versão anterior em caso de problemas na implantação.
Práticas de Implantação
 O desenvolvimento baseado em componentes é uma boa prática de construção da 
engenharia de software. Entre as alternativas abaixo, qual é um benefício do uso dessa 
prática?
a) Não melhora a qualidade.
b) É uma boa prática para testes.
c) Aumenta o tempo de desenvolvimento.
d) Reúso do código desenvolvido.
e) Nenhuma das anteriores.
Interatividade
 O desenvolvimento baseado em componentes é uma boa prática de construção da 
engenharia de software. Entre as alternativasabaixo, qual é um benefício do uso dessa 
prática?
a) Não melhora a qualidade.
b) É uma boa prática para testes.
c) Aumenta o tempo de desenvolvimento.
d) Reúso do código desenvolvido.
e) Nenhuma das anteriores.
Resposta
ATÉ A PRÓXIMA!