Please enable JavaScript.
Coggle requires JavaScript to display documents.
ENGENHARIA DE SOFTWARE (parte I) (Engenharia de Requisitos (Tarefas…
ENGENHARIA DE SOFTWARE (parte I)
O
processo de desenvolvimento de software
compreende um conjunto de:
Ações
Atividades
Tarefas
...Que resultam num artefato de software
Uma metodologia genérica para desenvolvimento de software possui 5 etapas:
Comunicação
Antes de iniciar, é necessário entender os objetivos e requisitos
Planejamento
O plano descreve as tarefas, riscos, recursos, cronograma de trabalho e produto resultante
Modelagem
É necessário que o engenheiro de software crie um modelo que auxilie o desenvolvimento e melhore o entendimento sobre as necessidades que serão supridas
Construção
Etapa que é feita a codificação e testes
Entrega
Nesta etapa o software é entregue (completo ou parcial) onde o usuário vai testar e dar seu feedback
Engenharia de Requisitos
Processo de descobrir, analisar e documentar serviços que o sistema irá oferecer e suas restrições
Requisitos:
Condição ou capacidade que deve ser alcançada ou possuída por um serviço, sistema ou componente para satisfazer um contrato ou outro documento formalmente imposto. Inclui necessidades quantificadas e documentadas dos
Stakeholders
É necessário a distinção clara entre os diferentes
tipos de requisitos
, que podem ser as necessidade básicas de negócio, requisitos abstratos de alto nível e requisitos concretos de baixo nível.
Requisitos de negócio:
Representa a razão do projeto, as métricas que serão utilizadas para aferir seu sucesso e as necessidades organizacionais de alto nível que devem ser satisfeitas.
Normalmente são especificados no
documento de visão
e devem estar alinhados aos requisitos de usuário. Dois elementos principais dos requisitos de negócio são:
Visão do produto
e
Escopo do projeto
.
Visão do produto:
A visão do produto descreve de forma sucinta o que o produto final é, e o que ele pode se tornar, podendo ser tanto a solução completa ou apenas uma parte dela
Escopo do projeto:
Identifica qual parte da visão do produto ou iteração de desenvolvimento o projeto contemplará, definindo o que está dentro e o que está fora do projeto;
Estrutura do Documento de Visão
Introdução:
Fornece uma visão geral de todo o documento de visão
Posicionamento:
Apresenta o problema e as oportunidades de negócio relacionadas
Descrição dos envolvidos e usuários:
Faz uma breve descrição sobre os
stakeholders
e identifica os principais problemas que a solução deve tratar
Visão geral do produto:
Fornece uma visão geral do produto, com suas principais funcionalidades, interface com outros sistemas e configuração
Funcionalidades do produto:
Descreve os requisitos de usuário
Restrições:
Descreve todas as restrições além dos requisitos externos e organizacionais
Precedência e Prioridade:
Define a prioridade de desenvolvimento das funcionalidades do sistema
Outros requisitos do produto:
Lista os padrões aplicáveis, os requisitos de hardware, de desempenho e de ambiente
Requisitos de documentação do produto:
Descreve a documentação a ser elaborada ou atualizada para dar apoio no uso e implantação adequada do sistema
Requisitos de usuário:
descrição em linguagem natural com diagramas, dos serviços e restrições que o sistema deve oferecer
Gerentes Clientes
Arquiteto de sistema
Engenheiros clientes
Usuário final do sistema
Gerentes contratantes
Requisitos de sistema:
detalhamento dos requisitos de usuário. Pode fazer parte do contrato entre empresa contratante e empresa desenvolvedora do sistema
Usuários finais do sistema
Engenheiros clientes
Arquiteto de sistema
Desenvolvedores de software
Requisitos Funcionais:
Requisitos relacionados às funcionalidades e restrições que o sistema irá oferecer
Funcionalidade:
Conhecida como
feature
, é um conjunto de requisitos funcionais logicamente relacionados que fornecem valor ao usuário.
Regra de negócio:
Define a forma de fazer negócio, refletindo a política interna, regras básicas de conduta e processos bem definidos. Totalmente independente de um sistema
Requisitos não-funcionais:
Requisitos relacionados não exatamente aos serviços que o sistema irá oferecer, e sim à questões técnicas como implementação, disponibilidade, tempo de resposta, restrições e imposições. Podem ser separados em tipos:
Requisitos de produto:
Especificam ou restringem o comportamento do sistema. Exemplos: Requisitos de
desempenho
,
usabilidade
,
confiabilidade
e de
proteção
.
Requisitos organizacionais:
Derivados das políticas da empresa do cliente e do desenvolvedor. Exemplos: Requisitos de
processo operacional
,
desenvolvimento
e de
ambiente operacional do sistema.
Requisitos externos:
Derivam de um fator externo ao sistema.Exemplos: Requisitos
reguladores*,
legais
e
éticos.**
Requisitos de interface externa:
Requisitos não-funcionais que descrevem uma conexão entre o produto de software e um usuário, um outro software ou um dispositivo de hardware
Requisitos de interface de hardware:
Características de hardware que são importantes ao sistema
Requisitos de interface de usuário:
Interfaces de produto com seu usuário. Para cada interface são detalhados nome, objetivo e casos de uso
Requisitos de interface de comunicação:
Descrevem as características das redes de comunicação utilizadas
Requisitos de interface de software:
Interface do produto com outros softwares, que enviam ou recebem informações
Procura traçar uma ponte entre as etapas de projeto e construção de software
Tarefas propostas pela engenharia de requisitos
Concepção:
É na concepção que se estabelece o entendimento básico do problema, quais serão as pessoas atendidas, a natureza da solução desejada, a eficácia da comunicação e colaboração dos
stakeholders
. Os
stakeholders
:
...definem um
plano de negócio
..identificam o
tamanho do mercado
...fazem a análise de
viabilidade inicial
...determinam o
escopo do projeto
Levantamento:
Estabelecer junto ao cliente, as
metas
a serem atingidas, os
objetivos
que devem ser cumpridos, e as
necessidades
que devem ser atendidas. Alguns problemas podem ocorrer:
Problemas de escopo
: ocorrem quando os limites do que o software abrange são definidos de forma precária ou quando os usuários definem detalhes técnicos que podem confundir
Elaboração:
Etapa onde as informações obtidas das fases de levantamento e concepção são detalhadas. Tem por objetivo produzir um modelo de requisitos mais refinados.
...é guiada pela construção de
cenários
que descrevem as interações com o sistema
Cada
cenário
é analisado para extrair as
entidades de domínio
de negócio. Os atributos e serviços de cada entidade e até o relacionamento são identificadas e uma série de diagramas complementares pode ser produzida
Negociação:
processo de gerenciamento dos conflitos gerados a partir da proposição de prioridades conflitantes, excesso de requisitos e escassez dos recursos.
Especificação:
Uma especificação pode ser um ou uma combinação de:
Documento por escrito;
Conjunto de modelos gráficos;
Modelo matemático formal;
Um conjunto de cenários de uso;
Um protótipo
Validação:
etapa onde é avaliada a qualidade dos artefatos produzidos pela engenharia de requisitos. É feita a
revisão técnica
que examina a especificação em busca de:
Erros no conteúdo ou na interpretação;
Pontos que requerem esclarecimentos;
Informações omissas ou inconsistentes;
Requisitos conflitantes ou inatingíveis.
Gestão:
conjunto de atividades que ajuda a equipe a controlar, identificar e acompanhar as novas demandas do software
Restrições:
Limitações às possíveis soluções do software em desenvolvimento, tendo o foco o produto entregue e não o projeto. Restrições são impostas e não se negociam. Podem ser de origem de
negócio
ou
técnicas.
Restrições de Negócio
Recursos orçamentários ou de tempo:
Sistema deve ser entregue em seis meses ou pode ter um orçamento máximo de 2 milhões de reais
Disponibilidade dos envolvidos no projeto:
Só um funcionário de cada departamento pode ser disponibilizado e por um tempo máximo de algumas horas
Recursos da equipe de projeto ou das partes interessadas:
Não pode ser utilizado uma tecnologia emergente pois a equipe ainda não a dominou
Outras restrições organizacionais:
Funcionários não podem fazer autenticação através de cartão por ser um local de alto risco biológico
Restrições Técnicas
Linguagens de programação:
Produto deve ser restrito a uma única linguagem de programação como por exemplo Elixir
Plataformas e produtos específicos de software e hardware:
Produto deve ser compatível com Linux e computadores com capacidades limitadas
Tamanho de mensagens:
Mensagens enviadas para outros módulos do sistema ou para a internet devem possuir no máximo 20kB
Espaço ocupado pelos componentes de software da solução:
Produto deve ocupar no máximo 200MB do espaço em disco das máquinas
Atributos de qualidade:
Conjunto de requisitos que descrevem características e serviços de um produto e representam as metas de qualidade a serem atingidas por um produto.
A Hewlett-Packard (HP) descreveu um conjunto de atributos de qualidade denominados FURPS.
F
uncionality
U
sability
R
eliability
P
erformance
S
uportability
Funcionalidade:
Refere-se aos serviços que o software oferece
Usabilidade:
Considera-se a facilidade que ocorre a interação entre o usuário e o software; e o design.
Confiabilidade:
Refere-se a quantidade e gravidade das falhas, além da recuperação de uma falha e a precisão dos resultados que o sistema fornece;
Performance:
Usa como medida o tempo de resposta, uso de recursos, tempo de processamento e eficiência.
Facilidade de suporte:
Refere-se ao quão complexo é a manutenção e extensibilidade do software