ENGENHARIA DE SOFTWARE Univesp

Prévia do material em texto

ENGENHARIA DE SOFTWARE – SEMANA 01 
 
Softwares podem ser desenvolvidos do zero ou estendidos a partir de software já existente. 
Softwares não são somente os programas em sim, mas também toda a documentação que o envolve. 
Atividades fundamentais: 
• Especificação, 
• projeto, 
• implementação, 
• validação, 
• evolução. 
Modelos de processo de software: 
 
 
 
 
Atividades do processo: 
• Especificação 
• Desenvolvimento 
• Validação 
• Evolução 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
RUP 
O Processo Unificado da Rational conhecido como RUP (Rational Unified Process), é um processo 
de engenharia de software criado para apoiar o desenvolvimento orientado a objetos, fornecendo uma forma 
sistemática para se obter vantagens no uso da UML. Foi criado pela Rational Software Corporation e 
adquirido em fevereiro de 2003 pela IBM. 
O principal objetivo do RUP é atender as necessidades dos usuários garantindo uma produção de software 
de alta qualidade que cumpra um cronograma e um orçamento previsíveis. Assim, o RUP mostra como o 
sistema será construído na fase de implementação, gerando o modelo do projeto e, opcionalmente, o modelo 
de análise que é utilizado para garantir a robustez. O RUP define perfeitamente quem é responsável pelo 
Mudança é inevitável em grandes projetos. 
Possíveis soluções: 
• Prototipação 
• Entrega incremental 
https://www.infoescola.com/informatica/engenharia-de-software/
https://www.infoescola.com/engenharia-de-software/uml/
que, como as coisas deverão ser feitas e quando devem ser realizadas, descrevendo todas as metas de 
desenvolvimento especificamente para que sejam alcançadas. 
O RUP organiza o desenvolvimento de software em quatro fases, onde são tratadas questões sobre 
planejamento, levantamento de requisitos, análise, implementação, teste e implantação do software. Cada 
fase tem um papel fundamental para que o objetivo seja cumprido, distribuídos entre vários profissionais 
como o Analista de sistema, Projetista, Projetista de testes, entre outros. 
Fase de Concepção / Iniciação: Esta fase do RUP abrange as tarefas de comunicação com o cliente e 
planejamento. É feito um plano de projeto avaliando os possíveis riscos, as estimativas de custo e prazos, 
estabelecendo as prioridades, levantamento dos requisitos do sistema e preliminarmente analisá-lo. Assim, 
haverá uma anuência das partes interessadas na definição do escopo do projeto, onde são examinados os 
objetivos para se decidir sobre a continuidade do desenvolvimento. 
Fase de Elaboração: Abrange a Modelagem do modelo genérico do processo. O objetivo desta fase é 
analisar de forma mais detalhada a análise do domínio do problema, revisando os riscos que o projeto pode 
sofrer e a 
arquitetura do 
projeto começa a 
ter sua forma 
básica. Indagações 
como "O plano do 
projeto é 
confiável?", "Os 
custos são 
admissíveis?" são 
esclarecidas nesta 
etapa. 
Fase de 
Construção: Dese
nvolve ou Adquire 
os componentes de 
Software. O 
principal objetivo desta fase é a construção do sistema de software, com foco no desenvolvimento de 
componentes e outros recursos do sistema. É na fase de Construção que a maior parte de codificação ocorre. 
Fase de Transição: Abrange a entrega do software ao usuário e a fase de testes. O objetivo desta fase é 
disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final. As atividades desta fase 
incluem o treinamento dos usuários 
finais e também a realização de 
testes da versão beta do sistema 
visando garantir que o mesmo 
possua o nível adequado de 
qualidade. 
 
Manifesto ágil, 2001 
“Estamos descobrindo maneiras melhores de desenvolver software, 
fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. 
Através deste trabalho, passamos a valorizar: 
• Indivíduos e interações mais que processos e ferramentas 
• Software em funcionamento mais que documentação 
abrangente 
• Colaboração com o cliente mais que negociação de 
contratos 
• Responder a mudanças mais que seguir um plano 
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais 
os itens à esquerda.” 
 
 
 
 
 
Princípios dos métodos ágeis 
 
 
Programação extrema e escalamento de métodos ágeis 
 
SEMANA 02 
TIPOS DE REQUISITOS 
Requisitos de sistema/software: 
• Descrições do que o sistema/software deve fazer, os serviços que ele oferece, as restrições sobre seu 
funcionamento. 
• Refletem as necessidades dos clientes que servem a uma finalidade determinada. 
Engenharia de requisitos (Requirements engineering): 
• Processo de descobrir, analisar documentos, verificar e validar esses serviços e restrições. 
 
 
 
REQUISITOS FUNCIONAIS E NÃO-FUNCIONAIS 
Os Requisitos Funcionais definem o que o sistema fará, a Engenharia de Software afirma que os Requisitos Não 
Funcionais definem como o sistema fará. 
Na prática... o que cada um é responsável: 
 
REQUISITOS FUNCIONAIS 
 
 
REQUISITOS NÃO FUNCIONAIS 
 
• Incluir/Excluir/Alterar nome em uma tela de 
manutenção de funcionário 
• Geração de relatório de determinado período 
de vendas 
• Efetuar pagamentos de compra através de 
crédito ou débito 
• Consulta e alterações de dados pessoais de 
clientes 
• Emissão de relatórios de clientes ou vendas 
• Consulta de saldo ou estoque 
 
 
• O tamanho pode ser medido em kbytes e 
número de Chip de RAM. 
• A velocidade está ligada ao tempo de 
utilização da tela, ou transações processadas 
por segundos. 
• A métrica da portabilidade é o número de 
sistema-alvo. 
• A facilidade de uso pode ser medida pelo 
número de janelas ou o tempo de treino 
• A confiabilidade tem ligação com o tempo 
médio que o sistema pode vir a falhar, a 
disponibilidade ou até mesmo a taxa de 
ocorrência de falhas. 
 
 
 
 
 
 
TIPOS DE REQUISITOS NÃO-FUNCIONAIS 
 
 
 
Processo de engenharia de requisitos e especificação de requisitos 
 
 
 
 
MOMENTO PARA DESCONTRAIR... ESTUDAR PRA EVITAR ISSO! 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Elicitação e análise de requisitos 
 
Slides essenciais para entender de uma vez só Elicitação e análise de requisitos: 
https://pt.slideshare.net/wilkerbueno/elicitao-e-anlise?from_action=save 
Ou.. só ver abaixo ;P eu baixei em PDF, converti pra JPG e agora ta aqui. Vivaaaaa kkkkk 
 
 
https://pt.slideshare.net/wilkerbueno/elicitao-e-anlise?from_action=save
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
E AGORA.... 
 
 
Validação de requisitos 
• Processo de checar se os requisitos definem o sistema que o cliente realmente quer. 
• Validação de requisitos se sobrepõe à análise de requisitos, uma vez que está preocupada em 
encontrar problemas com os requisitos. 
• Importante porque erros em um documento de requisitos podem gerar altos custos de retrabalho 
quando descobertos tardiamente. 
Validação x Verificação 
 Validação: checar se os requisitos representam o sistema correto. 
 Verificação: checar se os requisitos estão representados corretamente. 
Exemplos de problemas comuns: 
➢ Validade/corretude: a função era exatamente aquela? 
➢ Consistência: diferentes requisitos não podem entrar em conflito. 
➢ Completude: todos os requisitos necessários devem ter sido incluídos. 
➢ Realismo: os requisitos incluídos devem poder realmente ser implementados. 
➢ Testabilidade: os requisitos devem poder ser validados sobre o sistema implementado. 
Exemplos de técnicas de V&V 
✓ Revisão: os requisitos são analisados sistematicamente por uma equipe de revisores que busca por 
erros. 
✓ Prototipação: um modelo executável do sistema em questão é demonstrado para os usuários finais e 
clientes. Estes podem experimentar o modelo para verificar se ele atende às suas reais necessidades. 
✓ Projeto de casos de teste: adiantar o processo de projetar casos de teste. 
Gerenciamento de requisitos 
Ambiente dinâmico:❖ Ambiente técnico e de negócios muda, inclusive, depois da implantação do software. Mudam 
hardware, integração com outros sistemas, prioridades de negócio, legislações etc. 
❖ Quem comprou e quem usa são pessoas diferentes e entram em conflito depois da implantação. 
❖ Mesmo entre usuários há divergência e apenas uma pequena parte deles foi ouvida durante o 
desenvolvimento. 
SEMANA 03 
MODELOS DE CONTEXTO E INTERAÇÃO 
Modelagem de software 
Modelos de software – são produzidos em: 
➢ Engenharia de requisitos 
• Ajudam a extrair os requisitos 
➢ Projeto de software 
• Ajudam a descrever/documentar o sistema 
Desenvolvimento de modelos abstratos de um sistema 
• Cada modelo com uma visão/perspectiva diferente 
• Deixa de fora detalhes 
• Normalmente usando uma notação gráfica (ex.: UML) 
 
 
 
RELEMBRANDO A ESTRUTURA DE CLASSE: Vídeo super didático. 
 
UML O que é um Diagrama de Classes: https://youtu.be/JQSsqMCVi1k 
UML - Diagrama de Classes – Relacionamentos: https://youtu.be/IJtQWLnHvcQ 
 
 
https://youtu.be/JQSsqMCVi1k
https://youtu.be/IJtQWLnHvcQ
 
Modelos estruturais 
Organizam um sistema em termos de seus componentes e seus relacionamentos. 
 
DIAGRAMAS A BAIXO EXEMPLIFICANDO: 
• Classes e associações 
• A classe de consultas 
• Hierarquia de generalização 
• Hierarquia de generalização com detalhes adicionais 
• Associação por agregação 
 
 
 
 
 
 
 
 
 
 
 
 
Modelos comportamentais 
Modelam o comportamento dinâmico do sistema quando está em execução. 
Mostram o que acontece ou deve acontecer quando o sistema responde a um estímulo de seu ambiente. 
Dois tipos de estímulo: 
• Dados: chegam e precisam ser processados pelo sistema. 
• Eventos: acontecem e disparam o processamento do sistema 
(podem ter dados associados, mas não necessariamente). 
 
 
 
 
 
MODELOGEM ORIENTADA A DADOS 
 
 
MODELOGEM ORIENTADA A EVENTOS 
 
 
 
 
Engenharia dirigida a modelos 
• Model-Driven Engineering (MDE) 
▪ Model-Driven Architecture (MDA) 
• Programa/código é gerado automaticamente a partir de modelos. 
• UML executável 
• Exemplos de casos de sucesso: IBM e Siemens 
• Prós X contras (custo/benefício) 
 
 
 
 
 
 
 
 
 
 
SEMANA 04 
Projeto de software e Padrões de projeto 
Projeto alto nível (conceito) → Projeto detalhado 
1. Contexto e interações externas com o sistema 
 
 
 
 
 
2. Arquitetura do sistema 
 
 
 
 
 
 
 
 
 
3. Principais objetos do sistema 
 
 
 
 
4. Modelos de projeto 
 
 
5. Interfaces 
 
 
 
 
 
 
Padrões de projeto 
• Motivação: padrões de projeto de prédios 
• Formas de descrever as melhoras práticas, bons projetos e capturar a experiência de uma forma que 
torne possível a outros reusar essa experiência 
• Soluções já testadas 
• Geralmente associados a projeto orientado a objetos 
o Incluem herança e polimorfismo 
Elementos essenciais de um padrão de projeto: 
1. Nome significativo (referência). 
2. Descrição do problema (contexto de aplicação). 
3. Descrição da solução de projeto, seus relacionamentos e suas responsabilidades. Não é o projeto 
concreto em si, mas um modelo (em geral, expresso graficamente) para ele a ser instanciado de 
diferentes maneiras. 
4. Declaração das consequências (resultados e compromissos) da aplicação do padrão. 
 
RESUMINDO... 
Modelinho de projeto que alguém fez, deu certo e lançou de forma resumida e prática para que outro não 
precise começar do zero a programação do Software. 
 
 
 
 
 
 
PROJETO DE ARQUITETURA DE SOFTWARE 
 
Uma arquitetura de software é uma descrição de como um sistema de software é organizado. As 
propriedades de um sistema, como desempenho, proteção e disponibilidade, são influenciadas pela 
arquitetura adotada. 
As decisões de projeto de arquitetura incluem questões como o tipo de aplicação, a distribuição do 
sistema, os estilos da arquitetura a serem utilizados e as formas como a arquitetura deve ser documentada e 
avaliada. 
As arquiteturas podem ser documentadas a partir de diferentes perspectivas e visões. Dentre as 
possíveis visões estão a visão conceitual, a lógica, a de processo, a de desenvolvimento e a visão física. 
Os padrões da arquitetura são um meio de reutilizar o conhecimento sobre as arquiteturas genéricas 
de sistemas. Eles descrevem as arquiteturas, explicam quando podem ser usadas e discutem suas vantagens e 
desvantagens. 
Entre os padrões de arquitetura comumente usados, estão: Modelo-Visão-Controlador, Arquitetura 
em camadas, Repositório, Cliente-servidor e Duto e filtro. 
Modelos genéricos de arquiteturas de sistemas de aplicação nos ajudam a compreender o 
funcionamento das aplicações, comparar aplicações do mesmo tipo, validar projetos de sistemas de 
aplicação e avaliar os componentes para reúso em larga escala. 
Sistemas de processamento de transações são sistemas interativos que permitem que as informações 
em um banco de dados sejam acessadas remotamente e modificadas por vários usuários. Os sistemas de 
informação e de gerenciamento de recursos são exemplos de sistemas de processamento de transações. 
Sistemas de processamento de linguagens são usados para traduzir textos de uma linguagem para 
outra e para realizar as instruções especificadas em uma linguagem de entrada. Eles incluem um tradutor e 
uma máquina abstrata que executa a linguagem gerada. 
O projeto e a implementação de software são atividades intercaladas. O nível de detalhamento no 
projeto depende do tipo de sistema a ser desenvolvido e se está sendo usada uma abordagem ágil ou dirigida 
a planos. 
O processo de projeto orientado a objetos inclui atividades para projetar a arquitetura do sistema, 
identificar objetos no sistema, descrever o projeto usando diferentes modelos de objetos e documentar as 
interfaces dos componentes. 
Vários modelos diferentes podem ser produzidos durante um processo de projeto orientado a objetos. 
Estes incluem modelos estáticos (modelos de classes, de generalização, de associação) e modelos dinâmicos 
(modelos de sequência, modelos da máquina de estado). 
As interfaces de componentes devem ser definidas precisamente, de forma que outros objetos possam 
usá-las. Um estereótipo de interface da UML pode ser usado para definição das interfaces. 
Padrão de arquitetura MVC (Modelo-Visão-Controlador), vantagens e desvantagens da sua 
utilização. 
 
O padrão MVC separa a apresentação e a interação dos dados do sistema. O sistema é estruturado em 
três componentes lógicos que interagem entre si. O componente “Modelo” gerencia o sistema de dados e as 
operações associadas a esses dados. O componente “Visão” define e gerencia como os dados serão 
apresentados ao usuário. O componente “Controlador” gerencia a interação do usuário e passa essas 
interações para a Visão e o Modelo. 
 
Vantagens: 
• Permite que os dados sejam alterados de forma independente de sua representação e vice-versa; 
• Apoia a apresentação dos mesmos dados de maneiras diferentes, com as alterações feitas em uma 
representação aparecendo em todas elas. 
Desvantagens: 
• Quando o modelo de dados e as interações são simples, pode haver código adicional e complexidade ao 
código. 
Decisões de projeto de arquitetura 
1. Há uma arquitetura genérica que pode atuar como um modelo para o sistema que está sendo 
projetado? 
2. Como o sistema será distribuído por núcleos/processadores? 
3. Que padrões ou estilos de arquitetura podem ser usados? 
4. Qual será a abordagem para se estruturar o sistema? 
5. Como os componentes estruturais do sistema serão decompostos em subcomponentes? 
6. Que estratégia será usada para controlar o funcionamento dos componentes do sistema? 
7. Qual a melhor organização de arquitetura para satisfazer os requisitos não funcionais? 
8. Como o projeto de arquitetura será avaliado? 
9. Como a arquitetura deve ser documentada? 
 
 
Requisitos não funcionais do sistema: 
• Desempenho• Proteção 
• Segurança 
• Disponibilidade 
• Manutenção 
Visões da arquitetura: 
• Visão lógica 
• Visão de processo 
• Visão de desenvolvimento 
• Visão física 
Padrões/estilos de arquitetura: 
• Forma de apresentar, compartilhar e reusar conhecimento sobre sistemas de software 
• Descrição abstrata, estilizada, de boas práticas testadas e experimentadas em diferentes sistemas e 
ambientes 
• Descrição bem sucedida anterior de uma organização de um sistema (incluindo informações sobre 
quando o uso é adequado, pontos fortes/fracos). 
EXEMPLOS: 
 
 
 
 
 
Vantagens de projetar/documentar a arquitetura: 
• Apoio à comunicação de stakeholders 
• Apoio à análise de sistemas 
• Apoio ao reuso em larga escala 
Exemplos de estilo arquitetural: (EXEMPLOS DE IMAGENS NOS SLIDES DA AULA 14) 
• Arquitetura em camadas 
• Arquitetura genérica em camadas 
• Arq. Do sistema LIBSYS 
• Padrão repositório 
• Repositório para uma IDE 
• Padrão cliente-servidor 
• Cliente-servidor p/ biblioteca de filmes 
• Padrão duto e filtro 
 
 
 
 
 
 
 
SEMANA 5 - Arquitetura orientada a serviços 
O que é SOA e quais são seus benefícios? 
Service Oriented Architectures (SOA) é, em tradução livre, Arquitetura Orientada a Serviços. Esse 
conceito de arquitetura busca disponibilizar as funcionalidades de um sistema como um serviço. 
Desta forma, essas funcionalidades podem ser compartilhadas e reutilizadas entre aplicações. Seu 
principal objetivo é ser mais flexível em atender às necessidades do mercado. 
Principais vantagens do SOA 
• O alinhamento com as regras de negócio; 
• A diminuição do tempo de desenvolvimento; 
• O baixo acoplamento entre as partes do sistema facilita a manutenção; 
• O isolamento da estrutura de um serviço traz flexibilidade durante mudanças; 
• Facilidade de agregar novas tecnologias a plataformas; 
• E a possibilidade de reutilização de componentes. 
 
 
 
Gerenciamento de mudanças 
• CCB – Change Control Board 
o “Grupo de desenvolvimento de produto” 
o Responsável pela tomada de decisões sobre como um sistema de software deve evoluir. 
o Revisa e aprova todas as solicitações de mudança (com exceção de erros simples, em tela, 
por exemplo) 
• Fatores a serem considerados pelo CCB: 
1. Consequências de não se fazer a mudança 
2. Benefícios da mudança 
3. Impacto da mudança (número de usuários afetados) 
4. Custos de se fazer a mudança 
5. Ciclo de release do produto 
Gerenciamento de Versões 
• Recursos de sistemas/ferramentas: 
o Identificação de versões e releases 
o Gerenciamento de armazenamento 
o Registro de histórico de alterações 
o Desenvolvimento independente 
o Apoio a projetos 
 
 
 
 
 
 
Construção de sistemas 
• Características de sistemas/ferramentas: 
1. Geração de script de construção 
2. Integração de sistema de gerenciamento de versões 
3. Recompilação mínima 
4. Criação de sistemas executáveis 
5. Automação de testes 
6. Emissão de relatórios 
7. Geração de documentação 
 
 
 
 
 
SEMANA 6 – Visão geral de Teste de Software 
 
Objetivos do teste? 
• Demonstrar que o teste está livre de defeitos? 
• Encontrar a existência de falhas! 
→→→ Os testes podem mostrar apenas a presença de 
defeitos, mas não a sua ausência. 
 
Nomenclatura usual 
 
 
Teste: atividade de V&V 
Validação de software: 
• Estamos construindo o software certo? 
Verificação de software: 
• Estamos construindo o software da maneira certa? 
 
Atividades estáticas de V&V: 
• Inspeções 
• Revisões 
Caracterização de teste de software: 
Fases de teste 
• Teste de desenvolvimento 
• Teste de release (Teste de aceitação) 
• Teste de usuário 
 
Forma de execução do teste 
• Teste manual 
 
• Teste automatizado 
 Teste de regressão 
 
 
Técnicas de teste 
Como projetar os casos de teste: 
• Teste de caixa-preta 
 
• Teste de caixa-branca 
 
 
 
 
 
Níveis de teste e Desenvolvimento dirigido a testes 
NÍVEIS DE SOFTWARE 
 
Teste de unidade 
• Ex: testar as classes de objeto 
▪ Testar todas as operações associadas ao objeto 
▪ Definir e verificar o valor de todos os atributos associados ao objeto 
▪ Colocar o objeto em todos os estados possíveis (simular todos os eventos que causam mudanças 
de estado) 
Teste de componente (integração) 
• Tipos de interface que podem conter defeitos: 
▪ Interfaces de parâmetro 
▪ Interfaces de memória compartilhada 
▪ Interfaces de procedimento 
▪ Interfaces de passagem de mensagem 
 
 
 
Desenvolvimento dirigido a testes 
▪ TDD – Test-Driven Development 
o Ideia de “test-first” 
o Surgiu como parte de métodos ágeis (XP) 
▪ Pode ser aplicado em engenharia de software “tradicional” 
o Intercalação de testes e implementação de código 
o Desenvolvimento de código incremental em conjunto com teste para esse incremento 
Benefícios 
▪ Melhor entendimento do código 
▪ Cobertura mínima de código pelo teste 
▪ Teste de regressão automatizado 
▪ Depuração simplificada 
▪ Documentação indireta do sistema 
Limitação 
▪ Não elimina necessidade de “teste de sistema” posterior 
 
 
 
 
 
 
 
 
RESMUNIDO SEMANA 1: 
Engenharia de software é uma disciplina de engenharia que se preocupa com todos os aspectos da produção de 
software. 
Software não é apenas um programa ou programas; ele inclui também a documentação. Os atributos principais de um 
produto de software são manutenibilidade, confiança, proteção, eficiência e aceitabilidade. 
O processo de software inclui todas as atividades envolvidas no desenvolvimento do software. Atividades de alto nível 
de especificação, desenvolvimento, validação e evolução são parte de todos os processos de software. 
As ideias fundamentais da engenharia de software são universalmente aplicáveis para todos os tipos de 
desenvolvimento de sistemas. Esses fundamentos incluem processos de software, confiança, proteção, requisitos e 
reúso. 
Existem vários tipos diferentes de sistemas, e cada um requer ferramentas e técnicas de engenharia de software 
adequadas a seu desenvolvimento. Existem poucas, se houver alguma, técnicas específicas de projeto e implementação 
aplicáveis para todos os tipos de sistemas. 
As ideias básicas da engenharia de software são aplicáveis a todos os tipos de sistemas de software. Esses 
fundamentos incluem processos de software gerenciados, confiança e proteção de software, engenharia de requisitos e 
reúso de software. 
Engenheiros de software têm responsabilidades com a profissão de engenharia e com a sociedade. Eles não devem se 
preocupar apenas com as questões técnicas. 
Sociedades profissionais publicam códigos de conduta que definem os padrões de comportamento esperados de seus 
membros. 
Os processos de software são as atividades envolvidas na produção de um sistema de software. Modelos de processos 
de software são representações abstratas desses processos. 
Modelos gerais de processo descrevem a organização dos processos de software. Exemplos desses modelos gerais 
incluem o modelo em cascata, o desenvolvimento incremental e o desenvolvimento orientado a reúso. 
Engenharia de requisitos é o processo de desenvolvimento de uma especificação de software. As especificações 
destinam-se a comunicar as necessidades de sistema dos clientes para os desenvolvedores do sistema. 
Processos de projeto e implementação estão relacionados com a transformação das especificações dos requisitos em 
um sistema de software executável. Métodos sistemáticos de projeto podem ser usados como parte dessa 
transformação. 
Validação de software é o processo de verificação de que o sistema está de acordo com sua especificação e satisfaz às 
necessidades reais dos usuários do sistema. 
Evolução de software ocorre quando se alteram os atuais sistemas de software para atender aos novos requisitos. As 
mudanças são contínuas e o software deve evoluir para continuar útil. 
Processos devem incluir atividades para lidar com as mudanças. Podem envolver umafase de prototipação, que ajuda 
a evitar más decisões sobre os requisitos e projeto. Processos podem ser estruturados para o desenvolvimento e a 
entrega iterativos, de forma que mudanças possam ser feitas sem afetar o sistema como um todo. 
O Rational Unified Process (RUP) é um moderno modelo genérico de processo, organizado em fases (concepção, 
elaboração, construção e transição), mas que separa as atividades (requisitos, análises, projeto etc.) dessas fases. 
Métodos ágeis: são métodos de desenvolvimento incremental que se concentram em desenvolvimento rápido, releases 
frequentes do software, redução de overheads dos processos e produção de códigos de alta qualidade. Eles envolvem o 
cliente diretamente no processo de desenvolvimento. 
A decisão de usar uma abordagem ágil ou uma abordagem dirigida a planos para o desenvolvimento deve depender do 
tipo de software a ser desenvolvido, das habilidades da equipe de desenvolvimento e da cultura da empresa que 
desenvolve o sistema. 
Extreme Programming é um método ágil, bem conhecido, que integra um conjunto de boas práticas de programação, 
como releases frequentes do software, melhorias contínuas do software e participação do cliente na equipe de 
desenvolvimento. 
Um ponto forte da Extreme Programming é o desenvolvimento de testes automatizados antes da criação de um recurso 
do programa. Quando um incremento é integrado ao sistema, todos os testes devem ser executados com sucesso. 
O método Scrum é uma metodologia ágil que fornece um framework de gerenciamento de projetos. É centralizado em 
torno de um conjunto de sprints, que são períodos determinados de tempo, quando um incremento de sistema é 
desenvolvido. O planejamento é baseado na priorização de um backlog de trabalho e na seleção das tarefas mais 
importantes para um sprint. 
O escalamento de métodos ágeis para sistemas de grande porte é difícil. Tais sistemas necessitam de projeto adiantado 
e alguma documentação. A integração contínua é praticamente impossível quando existem várias equipes de 
desenvolvimento separadas trabalhando em um projeto. 
RESMUNIDO SEMANA 2: 
Os pontos mais importantes, segundo Sommerville, são: 
Os requisitos para um sistema de software estabelecem o que o sistema deve fazer e define as restrições sobre seu 
funcionamento e implementação. 
Os requisitos funcionais são declarações dos serviços que o sistema deve fornecer ou descrições de como alguns 
processamentos devem ser efetuados. 
Muitas vezes, os requisitos não funcionais restringem o sistema que está sendo desenvolvido e o processo de 
desenvolvimento que está sendo usado. Estes podem ser os requisitos de produto, requisitos organizacionais ou 
requisitos externos. Eles costumam se relacionar com as propriedades emergentes do sistema e, portanto, aplicam-se 
ao sistema como um todo. 
O documento de requisitos de software é uma declaração acordada dos requisitos do sistema. Deve ser organizado 
para que ambos - os clientes do sistema e os desenvolvedores de software - possam usá-lo. 
O processo de engenharia de requisitos inclui um estudo da viabilidade, elicitação e análise de requisitos, 
especificação, validação e gerenciamento de requisitos. 
Elicitação e análise de requisitos descrevem um processo iterativo que pode ser representado como uma espiral de 
atividades - descoberta, classificação e organização de requisitos, negociação e documentação de requisitos. 
A validação de requisitos é o processo de verificação da validade, consistência, completude, realismo e 
verificabilidade dos requisitos. 
Mudanças organizacionais, mudanças nos negócios e mudanças técnicas inevitavelmente geram mudanças nos 
requisitos para um sistema de software. O gerenciamento de requisitos é o processo de gerenciamento e controle 
dessas mudanças. 
RESUMINDO SEMANA 3: 
A UML não possui um diagrama específico para que se faça a modelagem do banco de dados de um sistema. Explique 
o porquê dessa ausência de diagrama e descreva uma alternativa para que se faça a modelagem de dados utilizando a 
UML. 
A UML não possui uma notação específica para modelagem de banco de dados porque é utilizada dentro de um 
processo de desenvolvimento orientado a objetos e, portanto, assume que os dados serão modelados com o uso de 
classes, seus atributos e relacionamentos. Alternativamente, o diagrama de classes pode ser utilizado para 
representação de um modelo semântico de dados, retratando entidades com classes simplificadas (somente nome, sem 
detalhamento de operações); atributos das entidades, como os próprios atributos das classes, e relacionamentos, por 
meio de associações nomeadas entre classes. 
Um modelo é uma visão abstrata de um sistema que ignora alguns detalhes do sistema. Modelos de sistema 
complementares podem ser desenvolvidos para mostrar o contexto, as interações, a estrutura e o comportamento do 
sistema. 
Modelos de contexto mostram como um sistema que está sendo modelado é posicionado em um ambiente com outros 
sistemas e processos. Eles ajudam a definir os limites do sistema a ser desenvolvido. 
Diagramas de caso de uso e diagramas de sequência são usados para descrever as interações entre o usuário do sistema 
que será projetado e usuários ou outros sistemas. Os casos de uso descrevem as interações entre um sistema e atores 
externos. Diagramas de sequência acrescentam mais informações a eles, mostrando as interações entre os objetos do 
sistema. 
Os modelos estruturais mostram a organização e a arquitetura de um sistema. Os diagramas de classe são usados para 
definir a estrutura estática de classes em um sistema e suas associações. 
Os modelos comportamentais são usados para descrever o comportamento dinâmico de um sistema em execução. 
Podem ser modelados a partir da perspectiva dos dados processados pelo sistema ou pelos eventos que estimulam 
respostas de um sistema. 
Os diagramas de atividades podem ser usados para modelar o processamento de dados, em que cada atividade 
representa uma etapa do processo. 
Os diagramas de estado são usados para modelar o comportamento de um sistema em resposta a eventos internos ou 
externos. 
A engenharia dirigida a modelos é uma abordagem de desenvolvimento de software em que um sistema é representado 
como um conjunto de modelos que pode ser automaticamente transformado em código executável. 
RESUMINDO SEMANA 4: 
Uma arquitetura de software é uma descrição de como um sistema de software é organizado. As propriedades de um 
sistema, como desempenho, proteção e disponibilidade, são influenciadas pela arquitetura adotada. 
As decisões de projeto de arquitetura incluem questões como o tipo de aplicação, a distribuição do sistema, os estilos 
da arquitetura a serem utilizados e as formas como a arquitetura deve ser documentada e avaliada. 
As arquiteturas podem ser documentadas a partir de diferentes perspectivas e visões. Dentre as possíveis visões estão a 
visão conceitual, a lógica, a de processo, a de desenvolvimento e a visão física. 
Os padrões da arquitetura são um meio de reutilizar o conhecimento sobre as arquiteturas genéricas de sistemas. Eles 
descrevem as arquiteturas, explicam quando podem ser usadas e discutem suas vantagens e desvantagens. 
Entre os padrões de arquitetura comumente usados, estão: Modelo-Visão-Controlador, Arquitetura em camadas, 
Repositório, Cliente-servidor e Duto e filtro. 
Modelos genéricos de arquiteturas de sistemas de aplicação nos ajudam a compreender o funcionamento das 
aplicações, comparar aplicações do mesmo tipo, validar projetos de sistemas de aplicação e avaliar os componentes 
para reúso em larga escala. 
Sistemas de processamento de transações são sistemas interativos que permitem que as informações em um banco de 
dados sejam acessadas remotamente e modificadas por vários usuários. Os sistemas de informação e de gerenciamento 
de recursos são exemplos de sistemas de processamento de transações. 
Sistemas de processamento de linguagenssão usados para traduzir textos de uma linguagem para outra e para realizar 
as instruções especificadas em uma linguagem de entrada. Eles incluem um tradutor e uma máquina abstrata que 
executa a linguagem gerada. 
O projeto e a implementação de software são atividades intercaladas. O nível de detalhamento no projeto depende do 
tipo de sistema a ser desenvolvido e se está sendo usada uma abordagem ágil ou dirigida a planos. 
O processo de projeto orientado a objetos inclui atividades para projetar a arquitetura do sistema, identificar objetos no 
sistema, descrever o projeto usando diferentes modelos de objetos e documentar as interfaces dos componentes. 
Vários modelos diferentes podem ser produzidos durante um processo de projeto orientado a objetos. Estes incluem 
modelos estáticos (modelos de classes, de generalização, de associação) e modelos dinâmicos (modelos de sequência, 
modelos da máquina de estado). 
As interfaces de componentes devem ser definidas precisamente, de forma que outros objetos possam usá-las. Um 
estereótipo de interface da UML pode ser usado para definição das interfaces. 
Definir a arquitetura de um software é uma atividade muito importante. Em geral, as noções de separação de 
responsabilidades e independências entre as várias partes do sistema são fortemente consideradas. O padrão de 
arquitetura usado em muitos sistemas Web é o MVC (Modelo-Visão-Controlador). Descreva as funções de cada uma 
das partes do padrão MVC e como elas devem interagir entre si. 
Descreva o padrão de arquitetura MVC (Modelo-Visão-Controlador), citando vantagens e desvantagens da sua 
utilização. 
O padrão MVC separa a apresentação e a interação dos dados do sistema. O sistema é estruturado em três 
componentes lógicos que interagem entre si. O componente “Modelo” gerencia o sistema de dados e as operações 
associadas a esses dados. O componente “Visão” define e gerencia como os dados serão apresentados ao usuário. O 
componente “Controlador” gerencia a interação do usuário e passa essas interações para a Visão e o Modelo. 
Vantagens: 
Permite que os dados sejam alterados de forma independente de sua representação e vice-versa; 
Apoia a apresentação dos mesmos dados de maneiras diferentes, com as alterações feitas em uma representação 
aparecendo em todas elas. 
Desvantagens: 
Quando o modelo de dados e as interações são simples, pode haver código adicional e complexidade ao código. 
RESMUNIDO SEMANA 5: 
Arquitetura orientada a serviços é uma abordagem de engenharia de software em que os serviços reusáveis 
padronizados são os blocos básicos de construção para os sistemas de aplicação. 
Interfaces de serviço podem ser definidas em uma linguagem baseada em XML chamada WSDL. Uma especificação 
WSDL inclui uma definição dos tipos e operações de interface, o protocolo de ligação usado pelo serviço e a locação 
de serviço. 
Os serviços podem ser classificados como serviços utilitários que fornecem uma funcionalidade de uso geral, serviços 
de negócios que implementam parte de um processo de negócios ou serviços de coordenação que executam outros 
serviços. 
O processo de engenharia de serviço envolve a identificação de serviços candidatos à implementação, à definição de 
interface e à implementação de serviço e teste e à implantação de serviço. 
As interfaces de serviço podem ser definidas para sistemas legados que continuam úteis para uma organização. Em 
seguida, a funcionalidade do sistema legado pode ser reusada em outras aplicações. 
O desenvolvimento de software usando serviços baseia-se na ideia de que os programas são criados por composição e 
configuração de serviços para criar novos serviços compostos. 
Modelos de processos de negócios definem as atividades e o intercâmbio de informações que se realizam em um 
processo de negócios. Atividades em um processo de negócios podem ser implementadas por serviços para que o 
modelo de processo represente uma composição de serviço. 
O gerenciamento de configurações é o gerenciamento de um sistema de software em constante evolução. Durante a 
manutenção de um sistema, uma equipe de CM é responsável por garantir que as mudanças sejam incorporadas no 
sistema de uma forma controlada e que os registros sejam mantidos com os detalhes das mudanças que foram 
implementadas. 
Os principais processos de gerenciamento de configurações estão interessados no gerenciamento de mudanças, no 
gerenciamento de versões, na construção de sistema e no gerenciamento de releases. Ferramentas de software estão 
disponíveis para apoiar todos esses processos. 
O gerenciamento de mudanças envolve avaliar propostas de mudanças dos clientes de sistema e outros stakeholders e 
decidir se é efetivo implementá-las em um novo release de um sistema. 
O gerenciamento de versões envolve o acompanhamento das diferentes versões dos componentes de software criadas 
à medida que as mudanças são feitas. 
A construção de sistemas é o processo de montagem de componentes de sistema em um programa executável para 
executar em um sistema de computador-alvo. 
O software deve ser reconstruído e testado frequentemente, imediatamente após a construção de uma nova versão. Isso 
facilita a detecção de bugs e problemas introduzidos desde a última construção. 
Os releases de sistema incluem códigos executáveis, arquivos de dados, arquivos de configuração e documentação. O 
gerenciamento de versões envolve tomar decisões sobre as datas de release de sistema, preparar todas as informações 
para distribuição e documentar cada release de sistema. 
RESMUNIDO SEMANA 6: 
Os testes só podem anunciar a presença de defeitos em um programa. Não podem demonstrar que não existem defeitos 
remanescentes. 
Testes de desenvolvimento são de responsabilidade da equipe de desenvolvimento de software. Outra equipe deve ser 
responsável por testar o sistema antes que ele seja liberado para os clientes. No processo de testes de usuário, clientes 
ou usuários do sistema fornecem dados de teste e verificam se os testes são bem-sucedidos. 
Testes de desenvolvimento incluem testes unitários, nos quais você testa objetos e métodos específicos; testes de 
componentes, em que você testa diversos grupos de objetos; e testes de sistema, nos quais você testa sistemas parciais 
ou completos. 
Ao testar o software, você deve tentar “quebrar” o software usando sua experiência e diretrizes para escolher os tipos 
de casos de teste que têm sido eficazes na descoberta de defeitos em outros sistemas. 
Sempre que possível, você deve escrever testes automatizados. Os testes são incorporados em um programa que pode 
ser executado cada vez que uma alteração é feita para um sistema. 
O desenvolvimento test-first é uma abordagem de desenvolvimento na qual os testes são escritos antes do código que 
será testado. Pequenas alterações no código são feitas, e o código é refatorado até que todos os testes sejam executados 
com êxito. 
Testes de cenário são úteis porque replicam o uso prático do sistema. Trata-se de inventar um cenário típico de uso e 
usar isso para derivar casos de teste. 
Teste de aceitação é um processo de teste de usuário no qual o objetivo é decidir se o software é bom o suficiente para 
ser implantado e usado em seu ambiente operacional. 
No particionamento de equivalências as partições são definidas a partir de uma análise do domínio de entrada para o 
programa. Essa informação é obtida a partir de uma análise da especificação funcional do programa, ou seja, o teste é 
baseado na especificação para definir os requisitos de teste, sem considerar informações sobre a implementação, 
sendo, portanto, um teste caixa-preta ou funcional.