MÉTODOS ÁGEIS:

Panorama no desenvolvimento de software:

▶ Empresas: mudanças e respostas rápidas, software que atenda isso
▶ Prazo é o requisito mais crítico disso. Processos de desenvolvimento de software
baseados em um planejamento prévio rígido não estão adaptados ao
desenvolvimento rápido de software

Características fundamentais:
▶ Os processos de especificação, projeto e implementação são intercalados;
▶ Não há especificação detalhada do sistema e a documentação do projeto é minimizada
ou gerada automaticamente;
▶ O documento de requisitos do usuário apenas define as características mais importantes
do sistema.
▶ Sistema é desenvolvido em uma série de versões; Os usuários finais e outros
stakeholders (pessoa/organização que tenha interesse ou seja afetado pelo projeto) do
sistema são envolvidos na especificação e avaliação de cada versão.
▶ Eles podem propor alterações ao software e novos requisitos que devem ser
implementados em novas versões; Interfaces de usuário com um sistema interativo
▶ Métodos ágeis: uma abordagem incremental para a especificação, o desenvolvimento
e para a entrega do software; Adequados para situações em que os requisitos de sistema
mudam rapidamente durante o processo de desenvolvimento.
▶ O software é entregue ao cliente, que pode testá-lo, propor alterações e redefinir
requisitos de forma incremental.

Princípios dos Métodos Ágeis

▶ Envolvimento do cliente: intimamente envolvido, fornecer e priorizar novos requisitos
do sistema e avaliar suas iterações.
▶ Entrega Incremental: software é desenvolvido em incrementos com o cliente,
especificando os requisitos para serem incluídos.
▶ Pessoas, não processos: habilidades da equipe devem ser reconhecidas e e exploradas;
Membros da equipe devem desenvolver suas próprias maneiras de trabalhar, sem
processos prescritivos.
▶ Aceitar as mudanças: Saber que os requisitos do sistema vão mudar; Logo, projetar o
sistema de maneira a acomodar essas mudanças.
▶ Manter a simplicidade: Focalize a simplicidade no software e processo; Eliminar a
complexidade do sistema.
Dificuldades de Trabalhar com Métodos Ágeis:

▶ Disponibilidade e retorno (feedback) do cliente;

▶ Definição de prioridades de mudanças em equipes com muitos stakeholders, com

pessoas tendo visões diferentes; Membros da equipe para o trabalho conjunto;

▶ Manutenção da simplicidade; Cultura de empresas em trabalho dirigido a planos.

Manifesto Ágil:

Uma declaração que reflete a filosofia dos métodos ágeis. Descobrindo melhores
maneiras de desenvolver software. Maior valorização: Indivíduos e interações; Software
em funcionamento; Colaboração do cliente; Respostas a mudanças.

Desenvolvimento Ágil e Dirigido a Planos

Pode apoiar o desenvolvimento e a entrega incremental. Um processo ágil não é focado

unicamente no código, e pode produzir alguma documentação de projeto; A maioria dos
projetos de software inclui práticas das abordagens dirigidas a planos e ágil.

OBS: Métodos Ágeis Abordados no Curso de ESW: Extreme Programming (XP); Scrum.

Extreme Programming (XP): é talvez o mais conhecido e mais utilizado dos métodos
ágeis; Abordagem desenvolvida para impulsionar práticas reconhecidamente boas, como
desenvolvimento iterativo, a níveis “extremos”;

▶ Foco na agilidade de equipes e qualidade de projetos, simplificidade, comunicação,

feedback, coragem e respeito; É uma abordagem dinâmica e flexível, necessário muita
disciplina.

▶Requisitos são expressos como cenários, que são implementados diretamente como
uma série de tarefas; Os programadores trabalham em pares e desenvolvem testes para
cada tarefa antes de escreverem o código; Quando o novo código é integrado ao sistema,
todos os testes devem ser executados com sucesso; Há um curto intervalo entre os releases
(lançamentos) do sistema.

Práticas do XP:

▶ Planejamento incremental: requisitos anotados em cartões de história, divisão tarefas;

▶ Pequenos releases: desenvolve-se um conjunto mínimo de funcionalidades úteis.

▶ Projetos simples: Cada projeto é realizado para atender às necessidades atuais, só.

▶ Desenvolvimento test-first: é usado para escrever os testes para uma nova

funcionalidade antes essa seja implementada.

▶ Refatoração: refatorar o código para melhoria, mantem código simples e atualizado

▶ Programação em Pares: desenvolvedores trabalham em pares para apoio mutuo

▶ Propriedade coletiva: desenvolvedores trabalham em todas as áreas do sistema

▶ Integração contínua: tarefa é integrado ao sistema como um todo; testes de unidade.

▶ Ritmo sustentável: horas-extra não aceitáveis, pois reduzem qualidade do código

▶ Cliente no local: cliente deve estar disponível todo o tempo à equipe de XP;

Scrum: é uma metodologia para gerenciamento de projetos complexos, ideal para

ambientes onde os requisitos não são claros e/ou podem mudar com bastante frequência;
Foco no gerenciamento do desenvolvimento iterativo; Não tem uso de práticas de
programação, como em pares e desenvolvimento test-first; Pode ser usado com XP.

▶ A metodologia é baseada em princípios semelhantes aos de XP: equipes pequenas,

requisitos pouco estáveis ou desconhecidos, e iterações curtas.

▶ Dimensões em Scrum diferem de XP: Scrum e XP são complementares, pois o Scrum

provê práticas ágeis de gerenciamento enquanto o XP provê práticas integradas de
engenharia de software.
Fases do Scrum:

▶ Fase de planejamento geral: estabelecem os objetivos gerais do projeto e da arquitetura

do software;

▶ Série de ciclos de sprint: cada ciclo desenvolve um incremento do sistema;

▶ Encerramento do projeto: entrega da documentação exigida e avaliação das lições

aprendidas com o projeto.

Pilares do Scrum:

▶ Transparência: caracteristicas com definições claras e objetivas;

▶ Inspeção: inspeções para verificar se os processos se enquadram nos objetivos

▶ Adaptação: caso não estão de acordo com o esperado, processo deve ser ajustado.

ENGENHARIA DE REQUISITOS:

Requisitos de um sistema: são as descrições do que o sistema deve fazer, os serviços

oferecem e as restrições a seu funcionamento;

Refletem as necessidades do cliente para um sistema que serve a uma determinada

finalidade: Controlar um dispositivo; Inserir um pedido de venda; Buscar informações;

Engenharia de Requisitos: processo de descobrir, analisar, documentar e verificar esses

serviços e restrições.

Requisitos de Usuário e Requisitos de Sistema:

▶ Requisitos de usuário são declarações, em uma linguagem natural com diagramas, de

quais serviços o sistema deverá fornecer a seus usuários e as restrições com as quais este
deve operar;
▶ Requisitos de sistema são descrições mais detalhadas das funções, serviços e
restrições operacionais do sistema de software.

▶ Diferentes níveis de requisitos são úteis, pois comunicam informações sobre o sistema
para diferentes tipos de leitor; Precisam ser escritos em diferentes níveis de detalhamento
para que diferentes leitores possam usá-los de diversas formas.

Requisitos Funcionais e Não Funcionais

▶ Requisitos Funcionais: são declarações de serviços que o sistema deve fornecer, de

como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar
em determinadas situações. Em alguns casos, os requisitos funcionais também podem
explicitar o que o sistema não deve fazer.

- Descrevem o que um sistema deve fazer;

- Dependem do tipo de software, de quem são seus possíveis usuários; Normalmente

descritos de forma abstrata quando expressam requisitos de usuário;

- Requisitos de sistema funcionais mais específicos descrevem em detalhes as funções do

sistema, suas entradas e saídas, exceções, etc. A especificação deve ser completa e
consistente;

- Completude significa que todos os serviços requeridos pelo usuário devem ser definidos;

- Consistência significa que os requisitos não devem ter definições contraditórias.

- Contudo, para sistemas grandes e complexos, é praticamente impossível alcançar

completude e consistência dos requisitos (devido ao grande número de stakeholders).

▶ Requisitos não funcionais: restrições aos serviços ou funções oferecidos pelo sistema.
Incluem restrições de tempo, restrições no processo de desenvolvimento e restrições
impostas pelas normas. Os requisitos não funcionais, muitas vezes, aplicam-se ao sistema
como um todo.

- São requisitos que não estão diretamente relacionados com os serviços específicos

oferecidos pelo sistema a seus usuários;

- Podem estar relacionados às propriedades emergentes do sistema, como confiabilidade,

proteção, disponibilidade, desempenho, tempo de resposta e ocupação de área;

- São frequentemente mais críticos que requisitos funcionais individuais; Podem afetar a
arquitetura geral de um sistema em vez de apenas componentes individuais;

- Único desse, pode gerar uma série de requisitos funcionais relacionados; Surgem por
meio das necessidades dos usuários; Podem ser provenientes das características
requeridas para o software

Documento de Requisitos de Software:

É uma declaração oficial de o que os desenvolvedores devem implementar;

Deve incluir requisitos de usuário e requisitos de sistema; Documentos de requisitos são

essenciais quando um contratante externo está desenvolvendo o sistema de software;

- Métodos ágeis de desenvolvimento argumentam que os requisitos mudam tão

rapidamente que um documento de requisitos já está ultrapassado assim que termina de
ser redigido.

- O nível de detalhes que devem ser incluídos em um documento de requisitos depende

to tipo de sistema em desenvolvimento e do processo utilizado. Sistemas críticos precisam
ter requisitos detalhados, uma vez que segurança e proteção devem ser analisadas em
detalhes.

▶ Também conhecido por Especificação de Requisitos de Software; SRS – Software

Requirements Specification
Estrutura de um SRS:

▶ Prefácio: Define os possíveis leitores do documento; Deve descrever seu histórico e

versões, incluindo justificativa para a criação de uma nova versão e um resumo das
mudanças feitas em cada versão.

▶ Introdução: Deve descrever a necessidade do sistema; Deve descrever brevemente as

funções do sistema e explicar como ele interage com outros sistemas; Também deve
descrever como o sistema atende aos objetivos globais de negócio ou estratégicos da
organização que encomendou o software.

▶ Glossário : Deve definir os termos técnicos usados no documento; Não devem ser
feitas suposições sobre a experiência ou o conhecimento do leitor.

▶ Definição de requisitos de usuário: Deve descrever os serviços fornecidos ao usuário;

Os requisitos não funcionais também devem ser descritos nesta seção; Pode usar
linguagem natural, diagramas ou outras notações compreensíveis pelos clientes.

▶ Arquitetura do sistema: Deve apresentar uma visão geral em alto nível da arquitetura
do sistema previsto; Componentes de arquitetura que são reusados devem ser destacados.

▶ Especificação de requisitos do sistema: Deve descrever em detalhes os requisitos

funcionais e não funcionais; Se necessário, podem ser adicionados detalhes aos requisitos
não funcionais; Interfaces com outros sistemas podem ser definidas.

▶ Modelos do sistema: Pode incluir modelos gráficos que mostram os relacionamentos

entre os componentes do sistema, o sistema e seu ambiente; Exemplos de possíveis
modelos: modelos de objetos, modelos de fluxo de dados ou modelos semânticos de
dados.

▶ Evolução do sistema: Deve descrever pressupostos fundamentais em que o sistema se

baseia, assim como quaisquer mudanças previstas, seja em decorrência da evolução de
hardware, mudanças das necessidades de usuário, etc;

▶ Apêndices: Deve fornecer informações detalhadas e específicas relacionadas à

aplicação em desenvolvimento, além de descrições de hardware e banco de dados, por
exemplo.

▶ Índice: Vários índices podem ser incluídos no documento.

Especificação de Requisitos

É o processo de escrever os requisitos de usuário e de sistema em um documento de

requisitos; Idealmente, os requisitos de usuário e de sistema devem ser claros,
inequívocos, de fácil compreensão, completos e consistentes;

Na prática, isso é difícil de conseguir (muitos stakeholders, diferentes interpretações, etc)

▶ Requisitos de usuário devem descrever os requisitos funcionais e não funcionais de

modo que sejam compreensíveis para os usuários que não possuam conhecimentos
técnicos;

▶ Requisitos de sistema são versões expandidas dos requisitos de usuário, usados por
engenheiros de software como ponto de partida para o projeto do sistema.

Processos de Engenharia de Requisitos

Quatro atividades de alto nível

1. Avaliar se o sistema é útil para a empresa (estudo de viabilidade);

2. Descobrir requisitos (elicitação e análise);

3. Converter requisitos em alguma forma-padrão (especificação);

4. Verificar se os requisitos realmente definem o sistema que o cliente quer (validação).

▶ Atividades são organizadas em torno de uma espiral, como um processo iterativo;

▶ A saída da espiral é um documento de requisitos.

▶ O número de iterações em torno da espiral pode variar;

Elicitação e Análise de Requisitos

▶ Após o estudo inicial de viabilidade, é o próximo estágio no processo de engenharia

de requisitos;

▶ Nesta atividade, engenheiros trabalham com clientes e usuários finais para obter
informações sobre o domínio da aplicação, seus serviços, desempenho, restrições de
hardware, etc;
▶ Cada organização terá seu próprio modelo de processo de elicitação.

Atividades do processo

1. Descoberta de requisitos: Atividade de interação com os stakeholders para descobrir

seus requisitos;

2. Classificação e organização de requisitos: Faz uma lista dos requisitos não

estruturados, agrupa requisitos relacionados e os organiza em grupos coerentes; A forma
mais comum de agrupar os requisitos é o uso de um modelo de arquitetura para identificar
subsistemas e associar requisitos a cada um destes.

3. Priorização e negociação de requisitos: Requisitos entram em conflito devido aos

vários stakeholders; Essa atividade está relacionada com a priorização de requisitos e em
encontrar e resolver conflitos existentes.

4. Especificação de requisitos: Requisitos são documentados e inseridos no próximo

ciclo da espiral; Documentos formais ou informais podem ser produzidos.

Validação de Requisitos

É o processo pelo qual se verifica se os requisitos definem o sistema que o cliente

realmente quer;

A validação é importante porque erros em um documento de requisitos podem gerar altos

custos de retrabalho quando descobertos durante o desenvolvimento ou após o sistema
entrar em serviço

Diferentes tipos de validação:

▶ Verificações de validade: Um usuário pode pensar que é necessário um sistema para

executar determinadas funções. No entanto, maiores reflexão e análise mais aprofundada
podem identificar funções necessárias, adicionais ou diferentes; Os sistemas têm diversos
stakeholders com diferentes necessidades, e qualquer conjunto de requisitos é
inevitavelmente um compromisso da comunidade de stakeholders.
▶ Verificações de consistência Requisitos no documento não devem entrar em conflito;
Ou seja, não deve haver restrições contraditórias ou descrições diferentes da mesma
função do sistema.

▶ Verificações de completude: O documento de requisitos deve incluir requisitos que

definam todas as funções e restrições pretendidas pelo usuário do sistema;

▶ Verificações de realismo: Usando o conhecimento das tecnologias existentes, os

requisitos devem ser verificados para assegurar que realmente podem ser implementados;
Essas verificações devem considerar o orçamento e o cronograma para o
desenvolvimento do sistema.

▶ Verificabilidade: Para reduzir o potencial de conflito entre o cliente e o contratante,

os requisitos do sistema devem ser passíveis de verificação; Isso significa que você deve
ser capaz de escrever um conjunto de testes que demonstrem que o sistema entregue
atende a cada requisito especificado.