UNIDADE IV

Engenharia de
Software I

Profa. MSc. Priscila Facciolli

 Práticas de Engenharia de Software

 É 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 Comunicação

 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.
 Princípios da 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.
Comunicação Efetiva

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

Fonte: Livro-texto.
 Técnica de Reunião Walkthrough

 É 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.
 Joint Application Development (JAD)

 É 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.
 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 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ê.
 Tática de Planejamento

 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.

Práticas de Planejamento − Fases de um Projeto

Processos de
monitoramento e controle
Processos de
planejamento

Processos de Processos de
iniciação encerramento

Processos de
execução

Fonte: Livro-texto.
 Práticas de Planejamento – Plano do Projeto

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 do Planejamento − EAP

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.

Fonte: Livro-texto.
 Práticas do Planejamento

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.

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

............................ .............. .............. .............. ..............

Fonte: Livro-texto.
 Práticas do Planejamento

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.

Fonte: Livro-texto.
 Práticas do Planejamento: Análise de Riscos

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ática de Planejamento

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.
 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

 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.
 Práticas de Modelagem

 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.
 Modelagem Orientada a Objetos

 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.

Fonte: Livro-texto.
 Modelagem Orientada a Objetos

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.

Computador
Autor -utiliza
-Nome ; char
+Nome : char
-Memoria : int
-Idade : int
0..* 1..* +alteraNome()
+Incluir() : bool
+alteraMemoria()
 Modelagem Orientada a Objetos com UML

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 Caso de Uso 1
estrutura física do sistema e
não envolvem as interações. Ator 2
Diagramas de Casos de Uso Ator 1
Caso de Uso 2
e de Classes.

 Exemplos: Caso de Uso 3

Computador
Autor -utiliza
-Nome ; char
+Nome : char
-Memoria : int
-Idade : int
0..* 1..* +alteraNome()
+Incluir() : bool
+alteraMemoria()

Fonte: Livro-texto
 Modelagem Orientada a Objetos com UML

A UML divide os diagramas Início

em 3 categorias: Evento 1 Registro fechado Curso

Curso Aberto
Completado
 Dinâmicos: mostram a interação Atividade 1

ativa entre os elementos Evento 2

Tomada de Tomada de
estruturais do sistema. decisão 1 decisão 2
Adicionar Aluno
 Os principais são os diagramas
Atividade 2 Atividade 3

Interface Produto
de sequência, estado e de Evento 3
Evento 4
: Cliente

atividades. Sincronismo
Dados produto

Pesquisar ()
 Exemplo: Evento 5

Atividade 4
Disponibilidade
Evento 6

Fim

Fonte: Livro-texto.
 Modelagem Orientada a Objetos com UML

 A UML divide os diagramas

Cliente Pedido Pagamento
em 3 categorias:
 Arquiteturais: mostram a
realização do sistema em Produto
componentes funcionais
e executáveis. Pedido
Pagamento

 Os principais Diagramas de
Componentes e de
Implantação. Servidor WEB
- Xenon 2.4 Ghz TCP/IP
Application Server
- Unix TCP/IP
Banco de Dados

 Exemplo:
- Linux - Sun Solaris - W2K3
- TomCat - Web Sphere

Fonte: Livro-texto.
 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

 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.
 Modelagem de Processo de Negócio (BPMN)

 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) – Notações Básicas
Class SPMM

Lane
Atividade Evento-fim
paciente

Paciente
<<Pool>>
Envia pedido Recebe pedido Envia Recebe
médico sintomas sintomas receita
Ocorre
doença Fluxo de
Eu quero ver o médico Eu me sinto doente mensagem

Consultório médico
Evento Pegue sua receita
O médico pede sintomas Fluxo de
início para comprar
sequência
<<Pool>>
remédios

Envia pedido Solicita Recebe Envia receita

médico sintomas sintomas médica

Fonte: Livro-texto.
 MDD – Model Driven Development

 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 – Principais elementos

Outros
modelos
Modelo

Mecanismo para
executar
transformações
Transformação Código-fonte
Ferramenta para
definir
transformações

Fonte: Livro-texto.
 MDD – Model Driven Development

 É 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.
 Práticas de construção – Arquitetura baseada em componentes

 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 – Verificação da qualidade

 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.

Iteração 1 Iteração 2 Iteração 3

R R R
A/P A/P A/P
I I I
T/I T/I T/I

Teste Teste Teste

Tempo
Fonte: Livro-texto.
 Práticas de construção – Controle de mudanças

 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 Implantação

 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.
 Interatividade

 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.
 Resposta

 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.
ATÉ A PRÓXIMA!