Requisitos Arquiteturais

Requisitos arquiteturais

Não são requisitos não-funcionais. São requisitos que de alguma forma afetam a arquitetura.

Dado um requisito

O sistema deve ser rápido e capaz de processar grandes quantidades de requisições simultâneas

"Rápido" e "grandes quantidades" são atributos de qualidade chamados performance e escalabilidade, respectivamente. Ainda nesse requisito, fala de todo o sistema, ou seja, é muito genérico. O papel do arquiteto é transformar um requisito como esse em um requisito específico e mensurável. Um exemplo de um requisito esperto seria:

A tela de cadastro de usuários deve possuir um tempo de resposta menor que 8 segundos e suportar 20 usuários simultaneamente em horários de pico (15:00 às 19:00).

Modelo FURPS+

O modelo permite capturar e qualificar requisitos com completude ao longo do projeto.

Devemos capturar requisitos ao longo de cinco dimensões:

• Functionality - Funcionalidade
• Usability - Usabilidade
• Reliability - Confiabilidade
• Performance - Desempenho
• Supportability - Suportabilidade

Dimensão adicional que lida com restrições técnicas:

• Restrições ao desenho
• Restrições à implementação
• Restrições de interface
• Restrições físicas

Funcionais

Funcionalidade

• Lida com aspectos funcionais
• Requisitos funcionais que o sistema deve atender
• Geralmente relacionados ao domínio do problema
• Ex. pequisa de palavras chave do google (muito complexo)
• Segurança, ajuda on-line, log de auditoria, controle de licenças, envio e recebimento de e-mails, i18n, recursos de impressão e relatórios, recursos de work

Não funcionais: URPS

Usabilidade

• Qualidade da interação entre o sistema e o usuário final. Ex: Velocidade que o usuário entre e recupere informações, facilidade de aprendizado para usuários leigos. 

Reliable (Confiabilidade)

• É a disponibildiade do sistema. Qual o tempo que o sistema está disponivel? 
• Ex: um produto com disponibilidade de 99% do tempo ao longo de 24 horas. 
• Outro exemplo é a recuperação de falhas. Dado uma falha, qual o tempo que o sistema demora para se recuperar.

Performance (Desempenho)

• Está relacionado a dois itens: Vazão e Tempo de resposta
• Vazão: associada ao processamento em lote. Ex. processar folha de pagamento
• Tempo de resposta: tempo que o sistema demora pra fazer uma requisição.

Supportability - Suportabilidade

• Está relacionado aos aspectos internos do sistema, onde somente a equipe de TI consegue enxergar e não o usuário final.
• Ex: Manutenabilidade, sistema operacional

Restrições

Elementos que precedem um determinado produto ou escolha a ser feita. Ex: a empresa já usa um banco Oracle, ou a tela de dispositivo é de 3,5'.

• Restrição ao desenho: especifica e restringe as opções de arquitetura do sistema
• Restrição à implementação: especifica e restringe os aspectos de implementação de código
• Restrição de interface: É uma restrição de comunição. Ex. o sistema deve interoperar através de Webservice
• Restrição física: restrições de algum tipo de hardware

Visão Geral da Arquitetura de Software

Exemplo prático de arquitetura de software

Antes de aplicar a arquitetura de software para resolver um problema, deve analisar os condutores para se chegar nas soluções dos problemas desses condutores.

O que é uma arquitetura de software

"Arquitetura de software é o conjunto de decisões que, se feitas incorretamente, podem causar o cancelamento do projeto" - Eoin Woods

Tipos de arquitetos

• Arquiteto de soluções
• Responsável por trabalhar com times comercial e pré-venda na solução pré-liminar de um projeto. 
• Antes do projeto ser aprovado. 
• Faz a ponte entre outros arquitetos, em particular do arquiteto de software.
• Arquiteto de software
• Papel central: liderar a construção de uma arquitetura desde o primeiro dia do projeto
• Usa-se os requisitos críticos
• Toma decisões técnicas
• Arquiteto de dados
• Desafios como BI, ETL, etc.
• Tomada de desciões técnicas
• Arquiteto de Infraestrutura
• Ex.: computação nas nuvens
• Arquiteto de tecnologia Java EE
• Arquiteto de tecnologia .NET
• Arquiteto das nuvens

Conceitos sobre o arquiteto de software

• O arquiteto é um desenvolvedor sênior
• Falso
• Enquanto o desenvolvedor é um especialista, o arquiteto é um generalista.
• O arquiteto não é um desenvolvedor sênior

• O arquiteto domina as APIs de segurança Java ou .NET
• Falso
• Mas precisa dominar as táticas e soluções de mercado que ele vai trabalhar
• O arquiteto domina as táticas arquiteturais de segurança
• O arquiteto desenha plantas e o time de desenvolvimento implementa
• Falso
• O arquiteto junto com o time de desenvolvimento desenvolve cria plantas
• O arquiteto desenvolve a arquitetura
• Falso
• Ele desenvolve a arquitetura junto com time
• O time de arquitetura desenvolve a arquitetura

O que faz um arquiteto de software

Liderar a concepção do software...
...Definindo os atributos de qualidade.

Fornece apoio à construção do software...
...Baseado nos atributos de qualidade.

Decomposição típica das atividades de um arquiteto

• Coleta de requisitos (25%)
• Modelagem e implementação de provas de conceito (50%)
• Provas de conceitos são instrumentos para que arquitetos possam reduzir riscos
• Assistência ao time (25%)

O contexto na arquitetura de software

• É preciso olhar o contexto ambiental onde o arquiteto está envolvido para se tomar decisões arquiteturais. Ex. mudar de framework quando não se tem tempo, nem experiência.

Influências na arquitetura

• Contexto de negócio
• Qual a natureza do projeto que se está trabalhando? Se está trabalhado com um projeto de tempo fechado, não se pode ofender o prazo.
• Diretrizes e requisitos
• Captar as diretrizes do projeto como  escalabilidade, segurança, usabilidade que são elementos críticos.
• Restrições e premissas 
• Tempo, custo e muitas outras restrições. Ex. time júnior sem capacitação.
• Experiência do time
• Ignorar a experiência do time pode trazer consequencias graves no projeto.
• Soluções técnicas disponíveis
• São chamados de ativos arquiteturas. Podem ser elementos importantes para guia o arquiteto no caminho de boas soluções técnicas.
• Atributos de qualidade diversos
• Aspectos como segurança da informação, performance, usabilidade. É preciso conhecer esses atributos para se alcançar uma boa arquitetura

Decisões arquiteturais

"A vida de um arquiteto de software é uma longa sucessão de decisões sub-ótimas e parcialmente tomadas no escuro." - Philippe Kruchten

Pontos a serem observados ao tomar decisões

• Alinhamento estratégico
• nunca colocar a tecnologia na frente do negócio.
• Balanceamento de influências diversas
• experiência do time
• ativos da empresa
• contexto de negócio (diretrizes)
• Análise de riscos
• Processo decisório
• O que é melhor para o projeto e não o que o desenvolvedor quer fazer.

Processo de Testes

Verificação e Validação no MPS-Br

Nível D do MPS-Br

Objetivo: formalizar o processo de teste de software

Os resultados (da verificação e validação) são utilizados por avaliadores se a empresa atingiu os propositos dos processos de teste.

Validação

O propósito do processo Validação é confirmar que um produto ou componente do produto atenderá a seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido.

O objetivo da validação é garantir que o produto correto está sendo desenvolvido. 

Resultados esperados

• VAL1 - Produtos de trabalho a serem validados são identificados
• VAL2 - Uma estratégia de validação é desenvolvida e implementada, estabelecendo cronograma, participantes envolvidos, métodos para validação e qualquer material a ser utilizado na validação.
• VAL3 - Critérios e procedimentos para validação dos produtos de trabalho a serem validados são identificados e um ambiente para validação é estabelecido.
• VAL4 - Atividades de validação são executadas para garantir que o produto esteja pronto para uso no ambiente operacional pretendido.
• A execução dos testes ao longo do processo é possível através de 4 etapas:
• Planejamento
• Projeto de casos de teste
• Execução
• Avaliação dos resultados
• VAL5 - Problemas são identificados e registrados
• VAL6 - Resultados de atividades de validação são analisados e disponibilizados para as partes interessadas.
• VAL7 - Evidências de que os produtos de software desenvolvidos estão prontos para o uso pretendido são fornecidas.

Verificação

O propósito do processo de Verificação é confirmar que cada serviço e/ou produto de trabalho do processo ou do projeto atende apropriadamente os requisitos especificados.

Resultados esperados

• VER1 - Produtos de trabalho a serem verificados são identificados
• VER2 - Uma estratégia de verificação é desenvolvida e implementada, estabelecendo cronograma, revisores envolvidos, métodos para verificação e qualquer material a ser utilizado na verificação.
• VER3 - Critérios e procedimentos para verificação dos produtos de trabalho a serem verificados são identificados e um ambiente para verificação é estabelecido.
• VER4 - Atividades de verificação, incluindo testes e revisões por pares, são executadas.
• VER5 - Defeitos são identificados e registrados
• VER6 - Resultados de atividades de verificação são analisados e disponibilizados para as partes interessadas