Engenharia de Software

Visão Geral de ES, Processo.

Faculdade de Ciências da Universidade Agostinho Neto

Licenciatura em Ciências de Computação
Ano Lectivo 2020
Mateus Padoca Calado
padoca@[Link]
Qual é a diferença entre CC, EI, ES, SI e TI?
 Qual é a diferença entre CC, EI, ES, SI e TI?
Antes de 1990

Depois de 1990
Computer Science
Computer Engineering
Software Engineering
Information Systems
Information Technology
 A importância do Software
• A economia global depende para quase tudo de
software.
• Existem cada vez mais sistemas que são
controlados por software.
• Os países desenvolvidos gastam uma
percentagem apreciável do seu PIB em software.
• O nosso modo de vida depende do software!
 O que é a Engenharia de Software?
• A Engenharia de Software é uma área do
conhecimento que se ocupa de todos os aspectos
relativos ao desenvolvimento profissional de
software.
• Os engenheiros de software devem:
− usar uma abordagem sistemática e organizada que
leva à produção de software de qualidade;
− usar ferramentas e técnicas ajustadas ao problema
em questão, as restrições do desenvolvimento e
aos recursos disponíveis.
− ser bom gestão de projectos.
 O que são as CASE
• Computer-Aided Software Engineering (CASE).
• São aplicações (ferramentas) que servem para
automatizar algumas das tarefas do
desenvolvimento de software.
• Por vezes são separadas em:
− Upper-CASE: aplicadas à análise de requisitos e
ao desenho;
− Lower-CASE: aplicadas à programação, teste,
detecção de erros.
 Desafios da Engenharia de Software
• Heterogeneidade: desenvolver técnicas que
permitam desenvolver software sobre
plataformas e ambientes de execução
heterogéneos;
• Rapidez: desenvolver técnicas que permitam
acelerar a entrega do software ao cliente;
• Confiança: desenvolver técnicas que demonstrem
que o software criado é de confiança.
 O que é o Software?
• Programas de computador e documentação associada
como requisitos, modelos e manuais (de programação,
utilização, instalação).
• Os produtos de software podem ser:
− Genéricos
Desenvolvidos para um mercado geral com clientes
diferentes necessidades.
− Feitos à medida (bespoke)
Desenvolvidos para um determinado cliente de acordo
com sua especificação.
Devem responder às necessidades específicas do
cliente.
 Alguns Tipos de Aplicações
• Isolada (Stand-alone)
– Reside num único computador; Não ligada a outro
software ou hardware ( Processador de texto).
• Embutida (Embedded)
– Parte de uma aplicação envolvendo hardware
(controlador automóvel)
• Tempo Real (Real-time)
– Funções devem executar em intervalos de tempo
definidos; Tipicamente micro-segundos (software de
radar).
• Rede (Network)
– Partes interagindo através da rede (jogo multiutilizador).
 Mitos do Software
• ”Após termos terminado um programa, o nosso
trabalho acabou”;
• ”O único produto a ser entregue no fim do
projecto é um executável”;
• ”Enquanto o software não estiver a funcionar não
é possível avaliar a sua qualidade”;
 Atributos de um bom Software
• Cumprir os requisitos: deve ser capaz de fazer o
que foi pedido;
• Fácil de manter: tem de ser capaz de evoluir para
se ajustar às necessidades;
• Fiável: deve ser de confiança;
• Eficiente: não deve desperdiçar recursos;
• Aceitável: os utilizadores devem aceitá-lo o que
implica que deve ser compreensível, utilizável e
compatível com outros sistemas.
 Custo do Software
• O maior custo de um sistema informático é
muitas vezes o do software.
• Para software feito à medida os custos de
evolução são normalmente superiores aos custos
de desenvolvimento inicial.
• Normalmente é mais cara a manutenção do
software que o seu desenvolvimento.
• Os custos de desenvolvimento estão também
ligados ao modelo de desenvolvimento usado (ver
à frente).
• Estimativa de custos é uma tarefa árdua e crucial.
 Sucesso do Software
• Fazer software é uma ciência e uma arte.
• A execução de tarefas é cada vez mais
rápida e efectiva.
• Permitiu avanços em várias áreas.
• Contudo, o software ainda tem problemas.
 Bugs
• Falta (fault): ocorre devido a erro humano, na
execução de actividades de software.
• Falha (failure): provém do comportamento
requerido para o sistema.
Perspectivas de Qualidade (Garvin 1984)
• Transcendental: a qualidade é algo que se
reconhece mas não se define.
• Utilizador: a qualidade é ajustada ao propósito.
• Produção: a qualidade está em conformidade
com a especificação.
• Produto: a qualidade está inerente às próprias
características do produto.
• Baseada no valor: depende do que o cliente está
disposto a pagar.
 Qualidade do Produto
• Utilizadores avaliam um produto pelas
características externas (e.g., funcionalidade
correcta, numero/tipo de falhas, fiabilidade,
eficiência, facilidade de utilização/ manutenção).
• Desenhadores e equipas de manutenção avaliam
a qualidade pelas características internas do (e.g.,
tipos de faltas).
• Os critérios dependem de quem está a avaliar.
• Existem modelos de qualidade que relacionam a
visão externa do utlizador com a visão interna da
equipa.
Modelo de Qualidade (McCall 1977)
 Qualidade do Software (Norma ISO 9126)
A norma ISO 9126 define como as características da
qualidade do software:
1. Capacidade Funcional (satisfazer as necessidades
expressas ou implícitas);
2. Fiabilidade (manter um nível de serviço em condições
precisas durante um período determinado);
3. Facilidade de Utilização (ser o mais ergonómico possível);
4. Rendimento (ser eficiente i.e. utilizar de forma adequada
os recursos materiais);
5. Manutenção (adaptar-se facilmente a modificações);
6. Portabilidade (adaptar-se facilmente a novos ambientes);
Qualidade do Software (Vários autores)
Vários autores propõem outras características além das 6 já́
referidas. Enunciamos algumas delas:
1. Integridade (ser capaz de proteger os seu código e os
seus dados contra acessos não autorizados);
2. Verificabilidade (facilitar a preparação de procedimentos
de testes);
3. Compatibilidade (ser capaz de interagir de forma simples
com outros softwares);
4. Reutilização (mostrar aptidão a ser reutilizado, no seu
todo ou em partes, em novas aplicações).
 Qualidade do processo
• A qualidade do processo de desenvolvimento e
de manutenção é importante para que o produto
seja de qualidade.
• O processo de desenvolvimento necessita de ser
modelado.
• A modelação de processos é útil para:
− Localizar determinado tipo de falta;
− Encontrar faltas cedo;
− Construir produto seguro;
 Quem participa no processo de software?
• Cliente: quem pede o serviço e irá pagar o produto final.
• Equipa de desenvolvimento: quem constroi o sistema de software.
• Utilizador: quem irá utilizar o produto final.
 O que é o processo?
• Um processo é o conjunto de actividades que têm
como objectivo o desenvolvimento de software.
• Um processo é uma série de etapas envolvendo
actividades, restrições e recursos, tendo em vista
a produção de determinado produto.
• Um processo define: (1) Quem faz, o que faz e
quando fazer; (2) Nem sempre diz como fazer.
• Não existe um processo ideal (Empresas
desenvolvem seus próprios processos).
• Envolve um conjunto de técnicas e de
ferramentas.
 Características de um Processo
• Prescreve todas as actividades principais;
• Utiliza recursos, sujeitos a restrições (e.g. calendarização);
• Pode ser composto por subprocessos organizados
hierarquicamente;
• Cada actividade tem definidos critérios de entrada e de
saída;
• As actividades organizam-se sequencialmente, do ponto
de vista temporal;
• Tem um conjunto de linhas orientadoras que explicam os
objectivos de cada actividade;
• Pode haver restrições para cada actividade, cada recurso
e cada produto.
 Produtividade Software
Custo de desenvolvimento reduzido
• A empresa consumidora quer investir pouco
em software;
• A empresa produtora tem que oferecer
“software barato”.
Tempo de desenvolvimento reduzido
• Suporte rápido às necessidades do mercado.
 Software Barato
• Nem tanto resultado de baixos custos de
desenvolvimento, mas principalmente da
distribuição dos custos entre vários clientes.
• Reuso, extensibilidade e adaptabilidade são
essenciais para viabilizar tal distribuição.
Mas, na realidade, temos a Crise de Software
• 25% dos projectos são cancelados;
• O tempo de desenvolvimento é bem maior do
que o estimado;
• 75% dos sistemas não funcionam como
planeado;
• A manutenção e reutilização são difíceis e
custosas;
• Os problemas são proporcionais a complexidade
dos sistemas.
 Causas da Crise de Software
Essências
• Complexidade dos sistemas;
• Dificuldade de formalização.
Acidentes
• Má qualidade dos métodos, linguagens,
ferramentas, processos, e modelos de
ciclo de vida;
• Falta de qualificação técnica.
Elementos e Actividades do Processo de Software
Elementos Actividades
• Modelos do ciclo de vida • Modelagem do negócio
do software • Levantamento de
• Linguagens requisitos
• Análise e Projecto
• Métodos • Implementação
• Ferramentas • Testes
• Processos • Distribuição
• Planeamento
• Gestão
• Configuração e Mudanças
• Manutenção
 Actividades e Artefatos do Processo de Software

Actividades Artefatos
• Modelagem do negócio • Plano de Negócios
• Levantamento de • Plano de Projecto
requisitos • Plano de Riscos
• Análise e Projeto • Documento de Requisitos
• Implementação • Documento Casos de Uso
• Testes • Documento de
• Distribuição Arquitectura
• Planeamento • Classes
• Gestão • Documento de Testes
• Configuração e Mudanças • Documento de Validação
• Manutenção • Manual do Sistema
 Ciclo de vida do software
Desenvolvimento de software
Algumas características do desenvolvimento de
software:
• Trabalho em equipa;
• Diálogo com os clientes/utilizadores;
• Organização, planificação, gestão do risco, etc...
O processo de desenvolvimento de software pode
ser definido como uma metodologia.
 Ciclo de vida do software

Uma representação abstracta e simplificada do

processo de desenvolvimento software, tipicamente
mostrando as principais actividades e dados usados
na produção e manutenção de software.

Quando um processo envolve a construção de um

produto de software, diz-se que o processo é o ciclo
de vida do software.
 Ciclo de vida do software
As diversas fases de ciclo de vida do software
• Definição e análise de requisitos: o que é que o
sistema deve fazer e quais as restrições existentes;
• Desenho do sistema: definição do software de forma
a cumprir requisitos;
• Implementação: escrita de código;
• Validação: verificação de que o software faz aquilo
que estava especificado;
• Testes: testes modulares, de integração e do sistema;
• Entrega do sistema
• Manutenção
 Ciclo de vida do software
Fases e Tarefas do processo de desenvolvimento de software
 Fases de ciclo de vida do software
Planeamento
Corresponde a uma identificação das necessidades,
selecção de alternativas e definição de plano de
trabalho.
A grande preocupação desta fase é que a partir de
um levantamento de alto nível das necessidades
seja possível elaborar um plano do projecto a
executar nas fases subsequentes, com identificação
de actividades, recursos, prazos e custos.
 Fases de ciclo de vida do software
O conjunto de actividades que deverão ser realizadas na
fase de Planeamento:
• Compreender a missão e organização da empresa;
• Identificar e envolver todos os interessados pela
introdução do sistema;
• Elaborar uma descrição de alto nível do sistema;
• Identificar restrições, problemas e riscos do projecto;
• Identificar alternativas de implementação;
• Elaborar e obter a aprovação de um plano de
projecto;
• Definir o processo de controlo do projecto.
 Fases de ciclo de vida do software
Análise dos Requisitos
O estudo detalhado do domínio do problema que culmina com
a elaboração de um documento onde os requisitos funcionais
da solução a implementar são enumerados.
O requisito é uma funcionalidade que o sistema deve ter. Para
os identificar adequadamente deve-se ter a percepção
detalhada daquilo que o sistema deverá fazer, com elaboração
de questionários, a observação do funcionamento do dia-a-dia,
a recolha e análise de documentos, a elaboração de pequenos
protótipos que permitam validar mais facilmente a percepção.
O objectivo desta fase é expressar sem ambiguidades o que o
sistema deve fazer e não como fazer o sistema.
 Fases de ciclo de vida do software
Desenho do sistema
O desenho procede à especificação formal das características
que a implementação do sistema deverá apresentar, assim
como a realização de determinadas optimizações.
Esta fase de desenho inclui, por exemplo:
• A definição de arquitecturas de computadores,
• As tecnologias de base de dados,
• Os sistemas de execução de agentes,
• As topologias de redes; etc...
É nesta fase que deve ficar completamente definido o
ambiente e as linguagens a utilizar no desenvolvimento.
 Fases de ciclo de vida do software
Desenvolvimento do sistema
A tarefa de desenvolvimento inclui todas as
actividades de implementação do sistema
propriamente dito, ou seja, que estão relacionadas
com a concretização do do modelo de desenho
produzido na tarefa anterior.

Os diversos componentes aplicacionais são

codificados e testados de forma isolada garantindo
assim a correcção interna (testes unitários).
 Fases de ciclo de vida do software
Testes e Integração
Para além dos testes unitários, esta fase destina-se à
realização dos restantes testes.
O objectivo é avaliar a adequada correcção e
funcionamento de todos os componentes do sistema.
A verificação consiste na confirmação que a
codificação (implementação) do sistema está
conforme (correcta) com a especificação técnica
produzida na fase do desenho.
 Fases de ciclo de vida do software
Testes e Integração
Os testes classificados segundo as características do
sistema que avaliam:
• Testes de carga: analisa e avalia o comportamento do
sistema em situações de utilização intensiva;
• Testes de desempenho: analisa o tempo de resposta do
sistema;
• Testes de usabilidade: analisa a adequabilidade do
desenho das interfaces homem-máquina;
• Testes funcionais: determina a correcção da
implementação das funcionalidades.
 Fases de ciclo de vida do software
Testes e Integração
Os testes podem ser classificados segundo o âmbito dos
componentes do sistema que são alvo de verificação:
• Testes unitários: testes do comportamento de
unidades funcionais de código;
• Testes de integração: testes parcelares que vários
programadores realizam com vista a garantir que vários
componentes interactuam de forma adequada;
• Testes de sistema: testes globais em que todos os
componentes do sistema são integrados;
• Testes de aceitação: testes formais que os utilizadores
realizam sobre o sistema.
 Fases de ciclo de vida do software
Instalação
Esta fase consiste na preparação e instalação do sistema
na infraestrutura computacional destino. Envolve um
conjunto de tarefas muitas vezes esquecidas na altura da
preparação do plano do projecto:
• Instalação dos sistemas de suporte requeridos,
• Configuração e parametrização do sistema
implementado
• Definição de perfis, de utilizadores e de níveis de
segurança, etc...
• Preparação da migração para o novo sistema.
 Fases de ciclo de vida do software
Formação
Uma das fases fundamentais para o total sucesso do
processo desenvolvimento de software é a parte de
formação dos utilizadores que vão trabalhar com o
novo sistema.
Esta fase deve ser acompanhada por uma
documentação com os detalhes do funcionamento do
sistema.
 Fases de ciclo de vida do software
Manutenção
Durante a vida útil de qualquer sistema de software
são detectados problemas que não são devidamente
verificados durante a fase de implementação.
Surgem também inúmeras solicitações internas e
externas relativamente a pedidos de alteração de
requisitos que exigem a elaboração de novas
versões/actualizações do software.
O objectivo da manutenção é garantir que a
ocorrência de alguma destas situações é
convenientemente tratada.
Importância do Processo de desenvolvimento

A interacção entre tarefas pode ser definida

segundo diferentes modelos ou processos de
desenvolvimento.
• Impõe consistência e estrutura às actividades de
desenvolvimento;
• Facilita a compreensão, o controlo e a verificação
das actividades;
• Permite registar experiencias que poderão ser
usadas em futuros processo.
 Metodologia, Método e Modelo
Uma metodologia é o estudo dos métodos, é na prática
como que uma receita, para as etapas a serem seguidas
num determinado processo, e são fundamentais para o
desenvolvimento dos projectos.
Os métodos são para ser bem aplicados de acordo com
as necessidades de cada projecto em si, pois não existe
uma receita universal para todos.
Um modelo tem como objectivo estabelecer, com base
em estudos históricos e conhecimento operacional, um
conjunto de boas-práticas, que devem ser utilizadas
para obter um determinado resultado, podendo nem
sempre ser a melhor opção.
 O que é um modelo de processo de Software?

• É uma representação do processo segundo uma

determinada perspectiva.
• Algumas perspectivas possíveis:
− Workflow
 Sequência de actividades no processo;
 As actividades neste modelo representam acções humanas;
− Data-flow or Activity Model
 Fluxo de informação;
 Representa o processo como um conjunto de actividades que
levam a cabo transformações nos dados;
− Papel/acção
 Quem faz o quê: Papel desempenhado pelas pessoas
envolvidas no processo de software;
 Actividades por que são responsáveis.
 Modelo de processo de software
• Cria uma forma de entendimento comum das
actividades, recursos e restrições ao processo
(padroniza o desenvolvimento de software);
• Ajuda a equipa a encontrar inconsistências,
redundâncias, omissões no processo em geral e
nas suas partes em particular;
• Define os objectivos do desenvolvimento
(detectar faltas cedo, obter programas de elevada
qualidade, respeitar o orçamento);
• Deve ser escolhido pela equipa o modelo que
melhor se adapta aos seus objectivos.
Paradigmas de desenvolvimento de software
 Modelo em Cascata
• Também designado por Clássico, Sequencial ou Linear ou
Tradicional ou Waterfall ou Rígido ou Monolítico, foi um
dos primeiros modelos propostos (Winston Royce, 1970);
• Representa as actividades como fases do processo
distintas (especificação, desenho, implementação, teste);
• O desenvolvimento vai saltando de fase para fase à
medida que estas vão sendo cumpridas (etapas surgem
sequencialmente);
• A cada etapa é associada a construção de produtos
intermédios, sendo necessário terminar uma etapa antes
de iniciar a seguinte;
• Funciona bem quando se percebe bem o problema ou
quando os requisitos são definitivos e bem conhecidos.
Modelo em Cascata
 Modelo em Cascata
Desvantagens
• Não permite a redefinição das fases anteriores;
• Projectos reais raramente seguem um fluxo
sequencial;
• É difícil para o cliente definir todos os requisitos
no início do processo;
• Difícil adequação à mudanças de requisitos;
• Se ocorrer um atraso todo o processo é afectado;
• Uma versão funcional estará disponível no final
do processo.
 Modelo em Cascata
Quando Aplicar o Modelo Cascata?
• Sistemas críticos;
• Quando os requisitos são bem compreendidos;
• Quando há pouca probabilidade dos requisitos
mudarem.
 Modelo em Espiral
• Boehm, 1988.
• Trata-se de um modelo evolutivo;
• Combina as actividades do processo com a gestão do
risco para minimizar e controlar o risco;
• O modelo apresenta-se como uma espiral onde cada
iteração é representada por um circuito à volta de
quatro fases:
 Planificação;
 Determinação de objectivos, alternativas e
restrições;
 Avaliação de alternativas e riscos;
 Desenvolvimento e teste.
Modelo em Espiral
 Modelo em Espiral
Vantagens
• Suporta mecanismos de redução de riscos;
• Estimativas tornam-se mais realísticas;
• Mais versátil para lidar com mudanças;
• Obtém-se versões do sistema a cada iteração;
• Disponibiliza produtos cada vez mais refinados e
de melhor qualidade;
• Fácil de decidir o quanto testar;
• Não faz distinção entre desenvolvimento e
manutenção.
 Modelo em Espiral
Desvantagens
• Muita ênfase a parte funcional;
• A avaliação dos riscos exige experiência;
• Exige uma equipa de desenvolvimento
extremamente qualificada;
• É bem aplicado somente a sistemas de larga
escala;
• Não há clareza sobre o esforço de trabalho
necessário das equipas em cada ciclo;
• Pouco utilizado.
 Modelo de Prototipagem

• É um modelo iteractivo e evolutivo;

• Explicitamente projectados para acomodar os
produtos que evoluem com o tempo, em que a cada
nova iteração é produzida uma versão cada vez mais
completa do software;
• Facilidade de mudanças, possibilidade de oferecer
novas funcionalidades e grande interação com o
utilizador;
• Para sistemas de curto prazo ou sistemas pequenos e
médios;
 Modelo de Prototipagem

• Os curtos prazos dos clientes tornam impossível

completar-se um produto de software abrangente;
• Uma versão reduzida pode ser elaborada para fazer
frente à competitividade às pressões do negócio;
• Por outro lado, com o passar do tempo os requisitos
do negócio e do produto mudam frequentemente, à
medida que o desenvolvimento prossegue, o que
dificulta o produto final.
 Modelo de Prototipagem

Actividades simultâneas

Especificação Versão Inicial

Versão
Descrição Inicial Desenvolvimento
Intermediária

Validação Versão Final

 Modelo de Prototipagem
Programação Exploratória
• Disponibilização da primeira versão do sistema o mais rápido
possível que descartado;
• Os requisitos muito bem entendidos e novas funcionalidades
são adicionadas a medida que vão sendo propostas pelo
utilizador (modificações sucessivas no sistema até que o
mesmo seja considerado adequado);
• O objectivo é trabalhar com o cliente (stackholders) em todas
as fases do desenvolvimento, a partir das especificações
iniciais;
• Usado com sucesso para o desenvolvimento no contexto da
Inteligência Artificial (sistemas de reconhecimento de voz,
sistemas de diagnóstico médico, etc).
 Modelo de Prototipagem
Prototipagem Descartável
Obter Requisitos  Elaborar Projecto Rápido  Construir
Protótipo  Avaliar Protótipo  Refinamento do Protótipo
• Em projectos de pequenos e de médio tamanho;
• A ideia é entender os requisitos do sistema;
• Valida partes do sistema (Interface Gráfica e aspectos do
sistema relacionados à arquitectura, tais como
Desempenho, portabilidade, etc...);
• Desenvolvimento de um protótipo para o utilizador
experimentar.
 Modelo de Prototipagem
Problemas
• Sistemas possuem geralmente uma estrutura pobre;
• Habilidades especiais (i.e. em linguagens de prototipação
rápida) podem ser necessárias;
• Dificuldade acrescida no planeamento de projecto, pois há
um número incerto de ciclos para construir o produto (de
estabelecer limites quanto ao escopo e tempo);
• A velocidade da evolução pode trazer problemas no
próprio produto;
• São processos focados na flexibilidade e extensibilidade,
em detrimento de outros critérios de qualidade.
 Modelo Incremental
Desenvolvimento Incremental
• Se os requisitos não estão claros inicialmente;
• Começa com subsistema pequeno e funcional, depois
acrescenta novas funcionalidades a cada versão;
• Uma parte funcional do sistema é entregue ao cliente a
cada iteração (incremento);
• Incrementos iniciais podem ser usados como protótipos
para clarificação de requisitos;
• O cliente define as prioridades para os próximos
incrementos;
• Melhor controlo de erros e baixo risco de falha geral do
projecto.
 Desenvolvimento Incremental

Definição de Atribuição de Projecto da

requisitos iniciais requisitos à iterações arquitectura do sistema

Desenvolvimento
Validação do Integração do Validação do
do incremento do
Incremento Incremento Sistema
sistema
Sistema
Final
 Modelo Incremental
Vantagens
• A formação e a familiarização dos utilizadores
pode decorrer cedo, mesmo que faltem algumas
funções;
• Clientes/utilizadores ficam motivados desde cedo
para novas funcionalidades;
• Redução de riscos a cada etapa do projecto;
• Versões frequentes permitem corrigir problemas
inesperados rapidamente e globalmente;
• A equipa pode focar diferentes áreas de
conhecimento nas diferentes versões.
 RAD (Rapid Application Development)
RAD é um modelo de processo de software iteractivo e
incremental que enfatiza o ciclo de desenvolvimento curto
(60 a 90 dias);
O desenvolvimento rápido é obtido utilizando uma
abordagem de construção baseada em reúso de
componentes testados;
O planeamento é essencial, porque várias equipas de
software trabalham em paralelo em diferentes funções do
sistema;
A modelagem abrange as fases de negócios, de dados e de
processos, enquanto que os fases de teste e de modificação
são frequentemente condensados na construção.
RAD (Rapid Application Development)
 RAD (Rapid Application Development)
Vantagens
• Tentam colocar SW junto do cliente o mais rápido
possível;
• Usam abundantemente ferramentas CASE;
• Usam linguagens de quarta geração (visuais);
• Usam geradores de código;
• Reutilização de componentes.
 RAD (Rapid Application Development)
Desvantagens
• RAD exige recursos humanos experientes e suficientes para
criar um número adequado de equipas RAD;
• A Equipa de projecto deve estar comprometido com as
actividades;
• Maior probabilidade de erros em projectos de desempenho
alto e com interfaces de módulos muito interligadas;
• Se o sistema não puder ser adequadamente modularizado,
as construções dos componentes necessários ao RAD serão
problemáticas;
• O RAD pode não ser ajustado quando os riscos técnicos são
altos, por exemplo, na utilização de uma nova tecnologia.
 Metodologias Ágeis
Os métodos ágeis surgiram como que em reacção à
adopção dos modelos considerados pesados e tiveram
como principal motivação a criação de alternativas para o
modelo em cascata.

A rapidez, a flexibilidade e a capacidade de resposta são

as principais razões do surgimento desta abordagem.

Ao contrário dos métodos de desenvolvimento

tradicionais, cujo foco é nos processos e ferramentas,
esta abordagem dá especial ênfase às equipas, ao
software funcional, à colaboração com o cliente e à
resposta às mudanças.
Metodologias Ágeis
Manifesto para o Desenvolvimento Ágil de software

17 experientes profissionais na área de

desenvolvimento de software se reuniram em 2001,
com um objectivo de revolucionar o processo do
desenvolvimento de software.

Apesar de defenderem práticas diferentes e, por

vezes divergentes, havia algo que os unia, todos
estavam insatisfeitos com o modo como os projectos
de desenvolvimento de software eram geridos, i.e.,
excessivo foco na documentação do projecto e
processos de desenvolvimento demasiado rígidos,
pesados e burocráticos.
Manifesto para o Desenvolvimento Ágil de software
Manifesto para o Desenvolvimento Ágil de software

O Manifesto ágil estabelece quatro valores e doze princípios

fundamentais das metodologias ágeis.

Segundo o Manifesto, as metodologias ágeis devem

valorizar:
• As pessoas e suas interações (ciclos de trabalho) são mais
importantes que os procedimentos e ferramentas;
• Software funcional é mais importante que ter a
documentação completa;
• A colaboração mais próxima com o cliente é mais
importante que a negociação de contratos;
• A capacidade de responder a alterações é mais
importante que seguir um plano sem desvios.
Manifesto para o Desenvolvimento Ágil de software

O Manifesto ágil enumera ainda os 12 princípios a seguir:

• Garantir a satisfação do cliente, através da entrega rápida e
continua de software funcional;
• As alterações nos requisitos tardias ao âmbito do projecto
devem ser aceite, sendo uma vantagens competitivas para
o cliente;
• O Software funcional é entregue frequentemente, dando
preferência ao calendário mais curto;
• Cooperação constante entre as pessoas que entendem do
‘negócio’ e os programadores;
• Construir projectos em torno de pessoas motivados. Dê-
lhes o ambiente e o apoio que necessitam, e confie-os para
realizar o trabalho;
Manifesto para o Desenvolvimento Ágil de software

Os 12 princípios (continuação ...)

• O método mais eficiente e eficaz de transmitir
informações para e dentro de uma equipa de
desenvolvimento é a conversa cara-a-cara;
• Software funcional é a principal medida de progresso
do projecto;
• Os processos ágeis promovem o desenvolvimento
sustentável. Os patrocinadores, programadores e
utilizadores devem ser capazes de manter um ritmo
constante indefinidamente;
• A atenção contínua à excelência técnica e ao bom
projecto realça a agilidade;
Manifesto para o Desenvolvimento Ágil de software
• A Simplicidade e a arte de maximizar a quantidade de
trabalho não feito, é essencial;
• As melhores arquitecturas, requisitos e projectos emergem
de equipas auto-organizadas;
• Em intervalos regulares, a equipa reflecte sobre como
tornar-se mais eficaz, ajustando o seu comportamento em
conformidade.
Esta definição dos 12 princípios representou um passo
significativo na evolução da aplicação das práticas ágeis.
Alguns métodos ágeis: Extreme Programming (XP), Scrum,
Feature Driven Development (FDD), Adaptive software
Development (ASD), Crystal, Dynamic Systems Development
Method (DSDM), Microsoft Solutions Framework (MSF).
 Três Dimensões do Manifesto Ágil
• Software funcional diz respeito à dimensão produto (artefactos
produzidos).
• Foco no cliente, colaboração, aprendizagem e comunicação são
valores relacionados com as pessoas (todos os intervenientes
no projecto de desenvolvimento).
• Flexibilidade, simplicidade, adaptação, sentido prático e
naturalidade são valores relacionados com o processo (linhas
de orientação usadas durante o desenvolvimento).
 SCRUM

O SCRUM não define exactamente o que fazer em

todas as situações.
O pressuposto base do Scrum é que é inútil tentar
prever exactamente o futuro pois a realidade dos
projectos é incerta e volátil. Em vez de ser prescritivo,
o Scrum é adaptativo.
O enfase é colocado em facilitar as alterações ao
produto, em vez de as evitar, de forma a entregar
mais valor ao cliente.
 SCRUM

Processo de desenvolvimento iteractivo e incremental

para gestão de projectos e desenvolvimento ágil de
software.
SCRUM
 SCRUM
Papeis principais Artefactos
• Scrum Master; • Product Backlog;
• Product Owner; • Sprint Backlog;
• Equipa de Desenvolvedores. • Product Increment;
• Definition of Done;
Eventos importantes
• Burndown Charts;
• Sprint; • Release Planning Meeting.
• Sprint Planning Meeting;
• Daily Scrum;
• Sprint Review;
• Sprint Retrospective;
• Release Planning Meeting.
 SCRUM (Papéis)
Scrum Master
Responsável pela ajuda e correcta implantação do SCRUM
junto dos restantes intervenientes. Ao contrário de um gestor
de projectos numa abordagem Cascata, o Scrum Master não é
responsável pelo planeamento, isso é feito pelo Product
Owner e pela equipa.

Algumas das suas responsabilidades são:

• Remover obstáculos que possam prejudicar a equipa;
• Facilitar a reunião diária (Daily Scrum)
• Organizar as sessões de planeamento, revisões de sprint e
restrospectivas;
• Proteger a equipa de interrupções durante o sprint;
• Encorajar a colaboração entre a equipa e o Product Owner.
 SCRUM (Papéis)
Product Owner
Alguém com sólido conhecimento do negócio, organização e
mercado, que representa os utilizadores e outros stakeholders
no projecto. Tem uma visão das funcionalidades do produto
que adicionam valor à organização e transmitir essa visão para
a equipa Scrum.

As suas principais responsabilidades incluem:

• Desenvolver uma visão clara do produto;
• Definir objectivos para cada sprint;
• Produzir e manter um Product Backlog priorizado;
• Clarificar os requisitos do produto;
• Trabalhar com a equipa na definição dos requisitos;
• Especificar os requisitos do produto.
 SCRUM (Papéis)
Development Team
Responsável pela execução das tarefas do projecto de
software, idealmente pretende-se que seja uma
equipa (6 a 10) com caraterísticas multidisciplinares.
As suas funções principais são:
• Auxiliar nas definições de estimativas de tempo;
• Ajudar na priorização dos itens do Sprint;
• Definir os esforços de implementação dos itens do
Sprint;
• Determinar o objectivo do Sprint e desenvolver o
produto propriamente dito.
 SCRUM (Eventos)
Sprint
Designação dada a cada iteração do processo de
desenvolvimento.
A duração recomendada para cada Sprint é entre 2 a
4 semanas o que permite feedbacks constantes do
PO enquanto o produto está a ser desenvolvido.
Sprint Planning Meeting
Designação da reunião que é feita no início de cada
Sprint, nesta reunião devem estar presentes o PO, o
SM e DT e durante a mesma o PO descreve as
funcionalidades de maior prioridade.
 SCRUM (Eventos)
Daily Scrum
Reuniões curtas ( cerca de 15 minutos) realizadas
diariamente pela DT, onde todos respondem a três
questões chave:
• O que cada membro fez desde da última reunião?
• O que é que o membro vai realizar até ao próximo
Daily Scrum?
• Que obstáculos o membro está a encontrar?
Estas reuniões diárias permitem analisar melhor o
progresso e corrigir de imediato algum problema que
possa impactar do desenvolver dos trabalhos do Sprint.
 SCRUM (Eventos)
Sprint Review
Ocorre no final de cada Sprint, e em que participam
PO, DT, SM e demais partes interessadas.
Esta reunião é utilizada para demonstrar as novas
funcionalidades feitas durante o Sprint.
O objectivo é avaliar o que foi produzido pelo DT e
recolher opiniões para, caso necessário, adaptar o
plano para o Sprint seguinte, portanto pretende-se
aprimorar o produto.
 SCRUM (Eventos)
Sprint Retrospective
Último evento de um Sprint e ocorre imediatamente
após o Sprint Review com todos os elementos do DT.
O foco é o aprimoramento do processo, i.e. a interação
entre os membros de equipa, as práticas, as
ferramentas utilizadas, o que funcionou e o que precisa
ser melhorado na próximo Sprint.
Além da identificação dos problemas pretende-se
também identificar as medidas a tomar para a melhoria
do processo a aplicar nos próximos Sprints.
 SCRUM (Eventos)
Release Planning Meeting
Entrega de um ou mais incrementos do produto.
Apesar de poder entrar logo em produção existem
situações em que isso é postergado para que seja feito
somente na Release do produto.
Uma Release é a representação de uma entrega do
produto em produção.
Uma Release é normalmente planeada através do
evento designado Release Planning Meeting.
 SCRUM (Artefactos)
Product Backlog
Uma lista ordenada criado pelo DT mas onde apenas
o PO pode inserir, remover ou reordenar os itens.
O formato mais usual para estes itens é sob a forma
de User Stories, que são ordenados de acordo com o
critério do PO.
Os itens mais importantes ficam no topo e serão os
primeiros a implementar.
 SCRUM (Artefactos)
Sprint Backlog
Conjunto de itens selecionados para serem
implementados durante o Sprint mais o plano para
transformá-lo num incremento.
Assim, no final de cada Sprint planning Meeting, um
novo Sprint Backlog é criado.
Normalmente o plano é composto pelas tarefas
técnicas necessárias para transformar o item num
incremento do produto.
 SCRUM (Artefactos)
Product Increment
No final de cada Sprint o DT entrega ao PO um
incremento do produto, resultante da sua produção
durante o Sprint.
Isto permite que o PO perceba o valor do
investimento e também que vislumbre outras
possibilidades para o produto final.
 SCRUM
Inconveniências
Problemas com prazos: O foco na qualidade de cada uma das
etapas pode levar a atrasos).
Visão segmentada: A segmentação e a tentativa de ser ágil pode
levar os membros da equipa a perder a noção do projecto como
um todo, concentrando-se apenas na sua parte.
Desordem nas funções: A função de cada DT pode não estar
bem definida, o que pode fazer com que alguns membros da
equipa fiquem confusos.
Ausência de documentação: O facto da gestão do projecto ser
dividida faz com que, muitas vezes, apenas algumas etapas
estejam documentadas.
eXtreme Programming (XP)
 eXtreme Programming (XP)
Para projectos a curto e médio prazo e com pequenas e
médias equipas que desenvolvem software baseado
em requisitos imprecisos e instáveis.
XP enfatiza um conjunto de valores como a
comunicação, a simplicidade, o feedback e a coragem,
priorizando a satisfação do cliente acima de tudo.
Esta é uma metodologia que oferece confiança ao
equipa de desenvolvedores, incentivando-os a aceitar
mudanças nos requisitos, mesmo que estas já cheguem
numa fase tardia do ciclo de desenvolvimento.
 eXtreme Programming (XP)
Valores do XP
Comunicação: promover a comunicação entre as
partes envolvidas do projecto, ao preferir conversas
pessoais em detrimento de outros meios de
comunicação e o trabalho em conjunto em vez da
revisão do resultado final.
Simplicidade: construção do código mais simples e
exclusão de funcionalidades desnecessárias, portanto
apenas são implementados os requisitos necessários e
evita-se adicionar funcionalidades que apenas serão
importantes no futuro.
 eXtreme Programming (XP)
Feedback: permite a evidenciar os problemas o mais
cedo possível para que possam ser corrigido
atempadamente.
Coragem: capacidade de assumir riscos e desafios em
favor do projecto.
É necessária coragem para apontar os problemas no
projecto, para pedir ajuda quando necessário,
comunicar ao cliente que um dado requisito não vai ser
implementado no prazo estimado, entre outras
situações que apesar de ser o mais certo a fazer-se não
seria de todo o mais desejável
 eXtreme Programming (XP)
Papéis da metodologia XP:
Programmer (desenvolvedor) é responsável por
manter o código simples e claro e pela escrita dos
testes.
Customer (cliente) descreve os testes cada fase de
desenvolvimento, decidir acerca do cumprimento dos
requisitos e definir as suas prioridades em termos de
implementação.
Tester (analista de teste) é responsável por ajudar o
cliente a escrever os testes funcionais e pela sua
execução.
 eXtreme Programming (XP)
Tracker (fiscal) acompanha a conformidade das
estimativas, o progresso da equipa em cada iteração e
analisa formas de melhorar as estimativas.
Coach é responsável pelo processo como um todo e
por guiar a equipa no processo.
Consultant (consultor) elemento externo que guia a
equipa na resolução de problemas específicos.
Manager (gestor de projecto) é responsável por tomar
as decisões. Deve possuir grande aptidão para lidar
com pessoas e manter as ameaças externas longe da
equipa sob sua supervisão.
 eXtreme Programming (XP)
Inconveniências
• Não é eficaz em projetos de grande escala;
• Problemas de escalabilidade;
• Falta de requisitos específicos para garantir a
satisfação do cliente;
• Imprevisível;
• Planeamento não vigiado;
• Necessários programadores experientes;
• Falta de documentação.
 Rational Unified Process (RUP)
Conjunto de actividades
• Bem definidas ;
• Com responsáveis;
• Com artefactos de entrada e saída;
• Com dependências entre as mesmas e ordem de
execução;
• Com modelo de ciclo de vida;
• Descrição sistemática de como devem ser
realizadas;
• Guias (de ferramentas ou não), templates;
• Utiliza os diagramas de UML.
 Rational Unified Process (RUP)
Características fundamentais do RUP
• Iterativo e incremental, permitindo um
aperfeiçoamento do produto;
• Dirigido aos casos de uso, ou seja, tem a
orientação que o cliente, humano ou outro sistema,
pretende dele;
• Orientado à arquitectura, isto é à forma do
produto, porque uma orientação puramente
funcional como a dos casos de uso não é suficiente
para garantir um produto com qualidade.
 Rational Unified Process (RUP)
Iterativo e incremental

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

Tempo

Requisitos Análise/Projecto Implementação/Teste Implatação

 Rational Unified Process (RUP)
Iterativo e incremental
O ciclo de vida do RUP é composto por quatro fases:
Início (concepção), Elaboração, Construção e Transição.
 RUP (Iterativo e Incremental)
1. Fase de Início
• Delimita o âmbito do projecto e se enquadra o
produto nos outros sistemas com que vai interagir.
• É necessário identificar todos os actores e descrever
os mais significativos.
• Estabelecem-se também os critérios de sucesso,
riscos envolvidos, estimativa dos recursos
necessários, e um plano com as datas dos marcos
mais importantes do projecto.
 RUP (Iterativo e Incremental)
No final desta fase ocorre o marco e cujos
critérios de avaliação, entre outros, são:
• Um documento com uma visão dos requisitos
fundamentais do projecto, restrições existentes, e
características principais;
• Um modelo de casos de uso (entre 10% a 20%);
• A análise dos gastos planeados e dos já efectuados;
• Credibilidade das estimativas de custos, prioridades,
riscos;
• Profundidade dos protótipos desenvolvidos.
 RUP (Iterativo e Incremental)
2. Fase de Elaboração
Faz-se a análise do domínio do problema,
estabelece-se a arquitectura do sistema;
Desenvolve-se o plano do projecto, e eliminam-
se os riscos evidentes do projecto;
No final desta fase deverão existir:
• Um modelo de casos de uso (80% completo)
com todos os actores identificados e a maioria
dos casos de uso desenvolvidos;
 RUP (Iterativo e Incremental)
• A captura de requisitos não funcionais e de outros
não relacionados com os casos de uso;
• Uma descrição da arquitectura do software;
• Um protótipo executável já com os aspectos
arquitecturais incorporados;
• Uma lista de riscos e uma análise do negócio já
revistas;
• Um plano de desenvolvimento para o projecto com
um plano mostrando as iterações e os critérios de
avaliação para cada iteração.
 RUP (Iterativo e Incremental)
3. Fase de Construção
• Nesta fase, todos os componentes e características
da aplicação que ainda não tenham sido introduzidos
são desenvolvidos e integrados no produto;
• São feitos testes exaustivos ao produto;
• Esta é a primeira fase de produção, dado as
anteriores serem essencialmente fases de
desenvolvimento de conceitos;
• De modo a acelerar o processo podem existir
equipas paralelas, que aumenta a complexidade da
gestão de recursos e da sincronização.
 RUP (Iterativo e Incremental)
No final desta fase existe já uma versão beta do
produto pronto para ser entregue aos clientes finais.
Os critérios de avaliação para a fase de construção
envolvem a resposta, entre outras, às questões:
• O produto está suficientemente estável para ser
entregue aos utilizadores?
• A razão entre os custos planeados e os reais
continua aceitável?
 RUP (Iterativo e Incremental)
4. Fase de Transição
• Esta fase tem como objectivo a transferência do produto
para a comunidade de utilizadores.
• Podem ocorrer várias iterações, com o lançamento de
versões beta, versões para correcção de erros, versões
que melhoram o desempenho do sistema.
• Deve ser dada atenção principalmente as sugestões para a
instalação, a configuração e a utilização do produto.
• Os planos e as datas para entrega estejam de acordo com
a realidade, e que o produto final seja alcançado o mais
rapidamente possível mas com os custos controlados.
 RUP (Iterativo e Incremental)
Devem existir as seguintes actividades:
• Testes beta para validar o novo sistema quando
confrontado com as expectativas dos utilizadores;
• Operação paralela com os sistemas legados que vai
substituir;
• Formação aos utilizadores e aos responsáveis pela
manutenção.

No final desta fase deve-se responder as seguintes questões:

• Os utilizadores estão satisfeitos?
• A razão entre os custos planeados e os reais continua
aceitável?
 RUP (Dirigido aos casos de uso)
• Os casos de uso não servem apenas para definir
os requisitos do sistema.
• Várias actividades do RUP são guiadas pelos casos
de uso:
 No planeamento das iterações;
 Na criação e validação do modelo de projecto;
 No planeamento da integração do sistema;
 Na definição dos casos de teste.
• Casos de uso fazem a ligação entre as fases.
 RUP (Orientado à arquitectura)
Arquitectura: visão geral do sistema em termos dos
seus subsistemas e como estes se relacionam;
A arquitectura é definida logo nas primeiras
iterações;
O desenvolvimento consiste em complementar a
arquitectura;
A arquitectura serve para definir a organização da
equipa de desenvolvimento e identificar
oportunidades de reuso;
 RUP (Orientado à arquitectura)
Os casos de uso dizem o que deve ser feito e a
arquitectura descreve como.
A arquitectura é o alicerce do sistema. Quando
desenvolvida com rigor, minimiza riscos
técnicos, favorece o reuso de componentes e
estimula o moral da equipa.
 RUP (Orientado à arquitectura)
Idealmente, tem-se 5 visões da arquitectura

Visão Visão de
Lógica Implementação

Analistas Programadores
Utilizador Final Gestor de Software
Funcionalidade

Visão de Visão de
Processos Distribuição Engenharia de Sistemas
Integração de sistema Topologia do Sistema
Escalabilidade de Desempenho Entrega, instalação
Taxa de transferência Comunicação
 RUP (Conceitos chaves)
• Fases e Iterações
• Actividades
 Passos
 Entradas e saídas
 Guias (de ferramentas ou não), templates
• Responsáveis (papel e perfil, não pessoas)
• Artefactos
• Fluxos de actividades
 RUP (Conceitos chaves)
Fases
Concepção Elaboração Construção Transição
Estabelecer o Eliminar Desenvolver o Entrar no
escopo e principais riscos produto até que ambiente do
viabilidade e definir esteja pronto utilizador
arquitectura para versão beta
económica do
estável testes
projecto
 RUP (Conceitos chaves)
Cada fase pode comportar diversas iterações

Concepção Elaboração Construção Transição

Iteração
1 2 i i+2 i+3 ... j j+1 ...
preliminar

tempo

Grandes marcos
 RUP (Conceitos chaves)
Marcos
Concepção Elaboração Construção Transição

Marco de
lançamento do
Marco dos Marco da Marco da
produto
objectivos do arquitectura do capacidade
ciclo de vida ciclo de vida operacional inicial
tempo

O projecto poderá ser anulado ou completamente

repensado caso o marco não seja atingido
RUP (Fases, Iterações e Fluxos de Actividades)
 RUP (Responsáveis, Actividades e Artefactos)
Os fluxos de actividades do RUP são descritos através de
responsáveis, actividades e artefactos
 RUP (Fluxos de actividades)
• Agrupam actividades correlacionadas
• Fluxos de atividades básicos:
 Modelagem do negócio
 Requisitos
 Análise e projecto
 Implementação e testes
 Distribuição
• Fluxos de actividades de suporte:
 Gestão de configuração e mudanças
 Gestão do projecto
 Configuração do ambiente
 RUP (Fluxos de actividades)
Modelagem do negócio
• Fluxos de atividades básicos:
 Modelagem do negócio
 Requisitos
 Análise e projecto
 Implementação e testes
 Distribuição
• Fluxos de actividades de suporte:
 Gestão de configuração e mudanças
 Gestão do projecto
 Configuração do ambiente
 RUP (Fluxos: Planeamento e Gestão)

Iniciar Aprovar Validar

Projecto Projecto Conclusão
Contratante do Projecto

Identificar
Riscos
Executar
Estudar Plano de
Viabilidade Iteração

Desenvolver Desenvolver Finalizar

Avaliar
Plano de Plano de Projecto
Iteração
Projecto Iteração

Gestor de Reavaliar
projecto Riscos

Priorizar
Arquitecto Casos de
Uso
 RUP (Fluxos: Requisitos)

Desenvolver Elicitar
Documento de necessidades
Analista de Visão dos Stakeholders
Sistema Revisor de
Estruturar o
Encontrar Atores e Modelo de UC Requisitos
Gestão das Capturar um Casos de Uso
Dependências vocabulário comum

Especificador Detalhar UC Revisar os

de UC Requisitos

Disponibilizar Protótipo de
Modelar a
Projetista da Interface com o Utilizador
Interface com o Utilizador
Interface com o Utilizador

Arquitecto Priorizar UC
 RUP (Fluxos: Análise e Projecto)

Projectar
arquitectura
Arquitecto
Revisor do
projecto

Projectar
subsistema
Analisar
Projectista caso de uso Projectar
caso de uso Projectar
Revisar
classes
projecto

Projectista de Projectar
base de base de
dados dados
 RUP (Fluxos: Implementação)
Planear Integração Integrar Sistema
e Subsistemas
Integrador do
Sistema e
Subsistemas

Corrigir
Defeitos

Programador
Estruturar Modelo Implementar Realizar Testes
de Implementação Componentes de Unidade

Revisar
Revisor de Código Código Fonte
 RUP (Fluxos: Testes)

Analista Elaborar Plano Projectar Avaliar Testes

de Testes de Testes Testes

Executar Testes
Testador de de Integração
Integração

Testador de Executar Testes

Sistema de Sistema

Programador Implementar Testes

Principais abordagens