Aula 1 - Engenharia II - quarta - noturno(1)

Prévia do material em texto

Centro Universitário FMU
Disciplina: 
Engenharia de Software II
Aula 1
Bacharelado em Sistemas de Informação
Tecnologia em Sistemas para Internet
Prof.: Celso Eduardo Guimarães
celso.guimaraes@fmu.br
Aula 1
Ciência da Computação
Sistemas para Internet
Engenharia de Software I
I. Apresentação do professor: breve histórico curricular.
II. Horário de aula:
19h00 – 20h15 - 1ª parte da aula (chamada antes de sair para o intervalo)
20h15 – 20h35 – intervalo
20h35 – 21h50 – 2ª parte da aula (chamada no término da aula)
Cada chamada corresponde a 1,5 períodos.
III. Apresentação dos objetivos de aprendizagem da disciplina.
IV. Explicação de como será o Processo Avaliativo dessa disciplina.
V. Revisão de conceitos importantes de Engenharia de Software I.
O Processo avaliativo na Disciplina de Engenharia de Software I
❑ A média final na disciplina será composta por duas partes: N1 e N2
▪ N1 terá peso de 40% na nota.
▪ N2 terá peso de 60% na nota.
▪ Portanto: a média final (MF) será calculada assim:
• MF = (N1 * 0,4) + (N2 * 0,6)
▪ Para compor a N1, teremos 3 avaliações:
• A1 = Prova individual valendo de 0 a 10.
• A2 = Prova individual valendo de 0 a 10. (Sistemas para Internet = prova integradora) – 29/04.
• A3 = Atividades desenvolvidas em sala de aula ou em casa. Poderão ser em grupo ou individual, 
conforme orientação do professor. Todas as atividades valerão de 0 a 10 e a nota final A3 será a média 
aritmética de todas as atividades.
• N1 = A1 + A2 + A3
▪ Para compor a nota N2, teremos:
• A4 = Atividade Prática Supervisionada (APS). Será explicada em breve. Terá peso de 10% da N2.
• A5 = Prova valendo de 0 a 10 a ser realizada dentro do calendário da instituição (entre 01/06 e 06/06)
• A6 = Avaliação substitutiva para quem perdeu A5 ou não conseguiu atingir a média requerida (6,0).
• N2 = (A4 * 0,1) + (A5 * 0,9) ou (A4 * 0,1) + (A6 * 0,9)
▪ Não haverá qualquer tipo de arredondamento.
▪ Média final mínima para ser aprovado = 6,0.
Objetivos de Aprendizagem – Engenharia de Software II
1. Aplicar o RUP
2. Elaborar e desenvolver a documentação de um projeto orientado a objetos com UML.
3. Analisar o processo de desenvolvimento de um projeto orientado a objetos utilizando a UML como linguagem
padrão.
4. Aplicar os principais padrões de projeto, aprofundando a compreensão sobre análise e projeto orientado a
objetos.
5. Aplicar os conhecimentos acerca de Gerenciamento de Configuração de Software e seus desdobramentos.
6. Analisar a teoria sobre Qualidade de Software, evidenciando os principais modelos de maturidade de software –
CMMI, MPSBR e SPICE.
7. Elaborar, planejar e desenvolver documentação de Testes de Software (plano de testes, cenário de testes e casos
de teste).
8. Aplicar os conceitos básicos sobre Desenvolvimento e práticas ágeis de software.
9. Aplicar os conceitos básicos de boas práticas de Desenvolvimento de Software.
10. Aplicar e Desenvolver os conceitos básicos de Testes Ágeis de Software Aplicar os princípios básicos da
Engenharia de Software Orientada a Serviços.
11. Elaborar os diagramas da UML para representar o problema. Refinar os diagramas incluindo particularidades
tecnológicas para detalhar a documentação do sistema a ser codificado.
12. Construir diagramas que representem a arquitetura de implantação e implementação dos componentes do
software
Engenharia: aplicação de métodos 
científicos ou empíricos à utilização dos 
recursos da natureza em benefício do ser 
humano.dicionário
Um engenheiro é um profissional de engenharia, preocupado com a aplicação 
do conhecimento científico, matemático e da criatividade para desenvolver 
soluções para problemas técnicos.
Engenharia é a aplicação do conhecimento científico, econômico, social e 
prático, com o intuito de inventar, desenhar, construir, manter e melhorar 
estruturas, máquinas, aparelhos, sistemas, materiais e processos.
https://pt.wikipedia.org/wiki/Engenharia
É um ramo da engenharia com foco em desenvolver 
sistemas de software de Alta Qualidade e Custos 
Adequados
O QUE É???
Engenharia de Software
Processo de Software
Processo de software é um conjunto de 
atividades que leva à produção de um produto 
de software.
Sommerville
Na elaboração de um produto ou sistema, é 
importante seguir uma série de passos previsíveis
— um roteiro que ajude a criar um resultado de alta 
qualidade e dentro do
prazo estabelecido. O roteiro é denominado...
processo de software (Pressman)
Modelo de Processo de Software
Sommerville
É uma descrição simplificada de um 
processo de software, que é apresentada a 
partir de uma perspectiva específica. Os 
modelos, pela sua natureza, são 
simplificações. 
Os modelos tem como objetivo serem “mapas”, fornecendo 
“diretrizes” de como conduzir um projeto de software.
Processo Unificado
Modelo Cascata
Modelo Espiral
Modelo Ágil xP
Comunicação. Antes de iniciar qualquer trabalho técnico, é de vital 
importância comunicar-se e colaborar com o cliente (e outros interessados). 
A intenção é compreender os objetivos das partes interessadas para com o 
projeto e fazer o levantamento das necessidades que ajudarão a definir as 
funções e características do software.
Planejamento. Qualquer jornada complicada pode ser SIMPLIFICADA caso 
exista um mapa. 
O mapa — denominado plano de projeto de software — define o trabalho de 
engenharia de software, descrevendo as tarefas técnicas a ser conduzidas, os 
riscos prováveis, os recursos que serão necessários, os produtos resultantes a 
ser produzidos e um cronograma de trabalho.
Fases no processo de Desenvolvimento de 
Software
Modelagem. Paisagistas, construtores de pontes, engenheiros aeronáuticos, 
carpinteiros, arquitetos, trabalham com modelos todos os dias. 
Cria-se um “esboço” da coisa, de modo que se possa ter uma ideia do todo —
qual será o seu aspecto em termos de arquitetura, como as partes 
constituintes se encaixarão e várias outras características.
Se necessário, refina-se o esboço com mais detalhes, numa tentativa de 
compreender melhor o problema e como resolvê-lo. 
Um engenheiro de software faz a mesma coisa criando modelos 
para melhor entender as necessidades do software e o projeto que 
irá atender a essas necessidades.
Fases no processo de Desenvolvimento de 
Software
Construção. Essa atividade combina geração de código (manual ou 
automatizada) e testes necessários para revelar erros na codificação.
Emprego. O software (como uma entidade completa ou como um 
incremento parcialmente efetivado) é entregue ao cliente, que 
avalia o produto entregue e fornece feedback, baseado na avaliação
Fases no processo de Desenvolvimento de 
Software
Engenharia de Software
Áreas de Conhecimento
❑ Requisitos de software
❑ Projeto de software
❑ Construção de software
❑ Teste de software
❑Manutenção de software
❑ Gerência de configuração de software
❑ Gerência de engenharia de software
❑ Processos de Engenharia de Software
❑ Ferramentas e Métodos de Engenharia de Software
❑ Qualidade de software
Vamos relembrar sobre conceitos de...
O QUE É UM REQUISITO DE SOFTWARE?
➢ O que são requisitos de software? 
➢ O que são requisitos funcionais?
➢ O que são requisitos não funcionais?
➢ Como descrever requisitos funcionais e não-funcionais? 
➢ Qual a diferença entre requisitos funcionais e regras de negócio?
Questões importantes que você deve saber 
responder!!!
Quais funções são requeridas pelo sistema e quais as 
restrições para a sua operação.
Especificação
Engenharia de Software
Também conhecida como Engenharia de Requisitos
Estágio (fase) importante do processo de software, 
uma vez que erros nesse estágio inevitavelmente 
produzem problemas posteriores no projeto e na 
implementação do sistema.
Uma condição ou capacidade necessária para um 
usuário RESOLVER um problema ou alcançar um 
objetivo
REQUISITO DE SOFTWARE
Engenharia de Requisitos
(IEEE)
Requisitos
Funcionais Não Funcionais
– Permitir cadastramento de novos clientes
– O sistema deveráenviar e-mail de alerta 
quando o estoque atingir o ponto mínimo.
– O sistema deverá emitir relatório diário 
dos indicadores de vendas
Testabilidade Confiabilidade
Segurança Manutenibilidade
Desempenho Escalabilidade
Elicitação de Requisitos
• Veja essa ficha cadastral 
de clientes;
• Imagine que a empresa 
faz essas fichas para 
manter um arquivo 
manual de cadastro de 
clientes ( essa empresa 
não tem um sistema 
informatizado); 
• Vamos agora pensar que essa empresa tem as seguintes regras de negócio:
o Para que os clientes façam compras parceladas, é necessário preencher a ficha de 
clientes;
o O vendedor deverá confirmar as informações por meio de documento e fazendo 
uma ligação no local de trabalho do cliente;
o Todas as informações da ficha precisam ser preenchidas.
O QUE SÃO REGRAS DE 
NEGÓCIO???
• Agora vamos pensar em 
desenvolver um sistema 
para esse cliente;
• Vamos considerar as 
regras de negócios como 
requisitos de software (o 
software terá que 
atender a essas 
funcionalidades);
• Poderíamos ainda estabelecer alguns requisitos funcionais:
o No campo cidade deve existir uma lista de municípios para seleção;
Ou melhor....
o Ao preencher o CEP, os campos cidade e endereço sejam preenchidos 
automaticamente (para isso devemos segregar o campo endereço em logradouro, 
número e complemento).
O QUE SÃO REGRAS DE 
NEGÓCIO???
Diferença de Requisito Funcional e Regra de Negócio
A diferença entre requisito funcional e regra de negócio, 
conceitualmente falando, é que o REQUISITO FUNCIONAL refere-se 
à O QUE O SISTEMA DEVERÁ FAZER, enquanto a REGRA DE 
NEGÓCIO refere-se a COMO O SISTEMA DEVERÁ FAZER. 
Do ponto de vista do negócio (negócio do cliente para o qual o 
sistema está sendo feito), ambos são necessidades (requisito 
funcional e Regra de Negócio), mas cada uma com um foco 
diferente.
Concluindo, sempre que tiver dúvida se o que você está 
escrevendo é uma Regra de Negócio ou um Requisito de 
Software, seja funcional ou não funcional, faça este 
exercício: Tire o software e veja se o que você está 
escrevendo acontecerá sem ele.
Se sim, é uma regra de 
negócio, se não, é um 
requisito de software.
https://www.youtube.com/watch?v=QyJDkR1Ejt4
https://www.youtube.com/watch?v=QyJDkR1Ejt4
Requisitos Funcionais
Requisitos não Funcionais
❑ Definem propriedades e restrições do sistema como 
tempo, espaço, linguagens de programação, versões do
compilador, SGBD, Sistema Operacional, método de
desenvolvimento, etc. 
✓ Uma dica importante é que os requisitos não funcionais 
são geralmente mensuráveis e assim devemos 
preferencialmente associar uma medida ou referência 
para cada requisito não funcional. 
❑RUP
• Abreviação de Rational Unified Process , tornou-se um 
processo proprietário da Rational Software Corporation.
❑2003
• IBM compra a Rational e o processo passar a ser chamado 
de IRUP.
• Todo o framework IRUP é mantido e fornecido pela IBM.
Processo Unificado Histórico
➢O processo é uma tentativa de aproveitar as 
melhores práticas e as melhores características dos 
processos tradicionais.
➢Dedica grande foco em
✓Dar importância à comunicação com o cliente; 
✓Métodos racionalizados (sequenciados) para descrever a visão do cliente sobre um 
sistema – Casos de Uso;
✓Enfatizar a importância do papel da arquitetura de software (ajuda o arquiteto a 
manter o foco nas metas corretas: compreensibilidade, confiança em mudanças 
futuras e reutilização);
✓Sugerir um fluxo de processo iterativo e incremental, proporcionando a sensação 
evolucionária.
Processo Unificado
Rational Unified Process
• É suportado por ferramentas que automatizam
grande parte das atividades de desenvolvimento.
• É processo configurável. 
• Dificilmente um único processo é adequado para o 
desenvolvimento de todos os tipos de software. 
• Ele pode ser ajustado (customizado) para pequenas equipes 
de desenvolvimento bem como para grandes organizações. 
• Captura as melhores práticas de desenvolvimento da Engenharia de 
Software.
Fases do Processo Unificado
Pressman
Fases do Processo Unificado
Concepção
• O objetivo dessa fase é estabelecer um 
Business Case para o sistema.
• Identifica-se todas as Entidades Externas (inclui 
pessoas e sistemas) que irão interagir com o sistema a 
ser construído, definindo também suas interações.
• As informações são usadas para avaliar a contribuição do sistema 
com o negócios para entendimento da viabilidade do sistema (deve-se 
seguir em frente com o projeto?)
Fases do Processo Unificado
Concepção
• Protótipo pode ser desenvolvido 
para validação do cliente.
• As iterações devem ser definidas quanto: quantidade / objetivos.
• O planejamento identifica RECURSOS, AVALIA RISCOS, define um 
CRONOGRAMA e estabelece uma base para as fases que serão 
aplicadas à medida que o incremento de software é desenvolvido.
Fases do Processo Unificado
Elaboração
• OBJETIVO:
✓ Um modelo de requisitos para o sistema;
✓ Uma descrição de arquitetura;
✓ Um plano de desenvolvimento para o 
software.
• Essa fase envolve atividades de comunicação e modelagem.
• Nela devem ser desenvolvidas os casos práticos iniciais levantados na fase 
anterior (concepção). 
• Nessa fase é essencial chegar a um entendimento do domínio do problema.
Fases do Processo Unificado
Elaboração
• Essa etapa amplia a representação da 
arquitetura para o sistema.
• Deve buscar complementar o levantamento (documentação dos 
casos de uso), voltado para a arquitetura do sistema.
• Revisar a modelagem do negócio para os projetos.
• Deve buscar o entendimento de:
-O plano do projeto é confiável?
- Custos são admissíveis?
Fases do Processo Unificado
Construção
• Relacionada principalmente às 
atividades de programação e testes 
do sistema.
• Ao concluir essa fase:
- Deve-se ter um sistema de software em funcionamento e a 
documentação associada pronta para ser liberada para os 
usuários do sistema.
• As partes do sistema são desenvolvidas paralelamente e 
integradas durante essa fase do PU.
Fases do Processo Unificado
Construção
• A fase de construção do PU é idêntica à 
atividade de construção definida para o 
processo de software genérico.
• A entrada para a fase de construção é Modelo de Arquitetura.
• A fase de construção desenvolve ou adquire componentes de software.
• Esses componentes farão com que cada caso prático se torne operacional para os 
usuários finais.
• Os modelos de requisitos e de projeto (iniciados na fase de elaboração), são 
completados para refletir a versão final do incremento de software.
Fases do Processo Unificado
• Ao final dessa fase:
-Deverá ter um sistema de software 
- Documentado
- Funcionando Corretamente
- Documentação e Software devem ser disponibilizados no 
ambiente operacional.
Transição
• Transferência do sistema do “Ambiente 
de Desenvolvimento” para o “Ambiente 
de Produção”.
• Go Live no ambiente real!
Fases do Processo Unificado
Transição
• Essa fase ainda possui os últimos estágios da Construção.
• Entrega-se o software aos usuários finais para testes beta e 
o feedback dos usuários relata defeitos e mudanças 
necessárias.
• Além disso, a equipe de software elabora material com as 
informações de apoio (por exemplo, manuais para o usuário, guias 
para resolução de problemas, procedimentos
de instalação) que são necessárias para lançamento da versão. 
• Na conclusão da fase de transição, o incremento torna-se uma versão 
do software utilizável.
Fases do Processo Unificado
❖ Nesse modelo, é provável que
▪ Ao mesmo tempo em que as fases de construção, transição e 
produção estejam sendo conduzidas.
-Já se tenha iniciado o incremento de software seguinte. 
▪ Isso significa que as cinco fases do PU não ocorrem em sequência, 
mas sim concorrentemente.
Produção
• Durante essa fase
- Monitora-se o uso contínuo do software
- Disponibiliza-se suporte para o ambiente operacional
- Realiza-se e avalia-se relatórios de defeitos e 
solicitações de mudanças.
As duas Dimensõesdo RUP
❑O processo unificado pode ser descrito por 
duas dimensões, ao longo de dois eixos:
• Eixo horizontal representa o tempo e mostra o aspecto dinâmico do processo. 
Ele é expresso em termos de ciclos, fases, iterações e marcos. (Fases)
• Eixo vertical representa o aspecto estático do processo. Ele é descrito em 
termos de atividades, artefatos, papéis e fluxos. (Disciplinas)
1. Iniciação ou Concepção: ênfase no escopo do sistema;
2. Elaboração: ênfase na arquitetura;
3. Construção: ênfase no desenvolvimento;
4. Transição: ênfase na implantação.
As fases indicam a 
ênfase que é dada no 
projeto em um dado 
instante.