Eng de Software

Capítulo 04

• Processos de software são atividades envolvidas na produção de um sistema de software. Os modelos de processo de software são representações abstratas desses processos.
• Todos os processos de software incluem especificação, projeto e implementação, validação e evolução de software.
• Modelos genéricos de processo descrevem a organização de processos de software. Exemplos de modelos genéricos incluem o modelo em cascata, desenvolvimento evolucionário e engenharia de software baseada em componentes.
• Modelos de processo iterativos apresentam o processo de software como um ciclo de atividades. A vantagem dessa abordagem é que lea evita um comprometimento prematuro com uma especificação ou projeto. Exemplos de modelos iterativos incluem desenvolvimento incremental e o modelo  espiral.
• A engenharia de requisitos é o processo de desenvolvimento de uma especificação de software. As especificações são usadas para comunicar as necessidades de sistema do cliente a seus arquitetos.
• Os processos de projeto e implementação concentram-se na transformação de uma especificação de requisitos em um sistema de software executável. Métodos sistemáticos de projeto podem ser usados como parte dessa transformação.
• A validação de software é o processo que verifica se o sistema está em conformidade com as especificações e se atende às reais necessidades dos usuários do sistema.
• A evolução de software concentra-se nas modificações existentes nos sistemas de software para atender aos novos requisitos. Essa abordagem está se tornando comum no desenvolvimento de software de sistemas de pequeno e médio portes.
• O Rational Unified Process é um modelo de processo genérico e moderno, organizado em fases (concepção, elaboração, construção e transição), mas que separa as atividades (requisitos, análise e projeto etc.) dessas fases.
• A tecnologia CASE fornece um apoio automatizado aos processos de software. As ferramentas CASE apóiam as atividades individuais de processo; os WORKBENCHES apóiam um conjunto de atividades realcionadas; os ambientes apóiam todas ou a maioria das atividades de processo

CONCEITO DE PROCESSO

Características:

• O processo pode ser decomposto em subprocessos; (Conj. de Atividades/ Etapas/ Sub-processos [Requisitos/ Design/ Condificação/ Teste/ Implantação])
• O processo descreve todas as atividades;
• O processo pode produzir produtos (saídas) intermediárias; (Requisitos -> SRS [Documentação de Especificação de Requisitos])
• O processo necessita de recursos e sofre limites impotos por restrições; (Recursos [pessoa/ infra/ tecnologia] // Restrições [pessoa/ infra/ tecnologia/ Legal])

Capítulo 06

• O requisitos de um sistema de software definem o que o sistema deve fazer e as restrições sobre suas operações e sua implementação.
• Os requisitos funcionais são declarações dos serviços que o sistema deve fornecer ou são descrições de como algumas computações devem ser realizadas. Os requisitos de domínio são requisitos funcionais derivados das características do domínio de aplicação.
• Os requisitos não funcionais restrigem o sistema que está sendo desenvolvido e o processo de desenvolvimento que deve ser usado. Eles podem ser requisitos de produto, requisitos organizacionais ou requisitos externos. Estão, frequentemente, relacionados as propriedades emergentes do sistema e, portanto, aplicam-se ao sistema como um todo.
• Os requisitos de usuário destinam-se às pessoas envolvidas no uso e na aquisição do sistema. Eles devem ser redigidos com o uso de linguagem natural, tabelas e diagramas de fácil compreensão.
• Os requisitos de sistema destinam-se a comunicar, de maneira precisa, as funções que o sistema deve fornecer. Para reduzir a ambiguidade, podem ser escritos em linguagem natural, de maneira estruturada e complementados com tabelas e modelos de sistemas.
• O documento de requisitos de software e a declaração aprovada dos requisitos de sistema. Ele deve ser organizado de tal modo que os clientes de sistema e os projetistas de software possam usá-lo.
• O padrão do IEEE para documentos de requisitos é um ponto de partida útil para padrões de especificação de requisitos mais específicos.

Requisitos: São descrições dos serviços fornecidos pelo sistema e suas restrições operacionais.

Eng. de Requisitos: Processo de descobrir, analisar, documentar e verificar esses serviços e restrições.

"Se uma empresa deseja estabelecer um contrato para o desenvolvimento de um grande projeto de software, ela precisa difinir suas necessidades de maneira suficientemente abstrata, para que uma solução não seja pré-definida."

'Requisitos de usuário: declarações em linguagem natural com diagramas, dos serviços e restrições do sistema.

'Requisitos de Sistema: descrição detalhada dos serviços e restrições do sistema.

"Requisitos funcionais: são declarações de serviços que o sistema deve fornecer.

"Requisitos não-funcionais: são restrições sobre o serviços oferecidos pelo sistema.

"Requisitos de domínio: derivam do domínio de aplicação do sistema e refletem as características e as retrições do domínio.

Dificuldades para se obter: (Requisitos Completos / Consistentes)

• Imprecisão na especificação de requisitos;
• Atendimento a necessidade de diferentes interessados;
• Tamanho e complexidade;

Requisitos não-funcionais:

• Relacionamento às propriedades emergentes do sistema (atributos de qualidade);
• Restrições sobre o projeto de desenvolvimento;
• Restrições sobre ferramentas e tecnologias;

CLASSIFICAÇÃO REQUISITOS:

     Produtos: Requis. Facilidade de Uso/ Eficiência/ Confiabilidade/ Portabilidade

     Organizacionais: Entrega/ Implementação/ Padrões

     Externos: Interoperabilidade/ Legais (privacidade/segurança)

MÉTRICAS PARA ESPECIFICAR REQUISITOS NÃO FUNCIONAIS

Velocidade/ Tamanho/ Facilidade de Uso/ Confiabilidade

REQUISITOS DE DOMINIO

     Dificuldade: Os especialistas de domínio podem deixar determinadoas informações fora de um requisito, simplismente por serem muito obvia para eles. Os requisitos podem ser redigidas na linguagem de domínio da aplicação.

REQUISITOS DE USUÁRIO

     (Robertson, 1999) Sugere a padronização de alguns campos:

       -> Justificava lógica dos requisitos.

       -> Dependencia entre os requisitos

       -> Fonte

REQUISITOS DO SISTEMA

     Alguns problemas com a utilização de linguagem natural.

     -> Ambiguidade natural da Linguagem.

     -> Flexibilidade de linguagem (quando os requisitos são os mesmos ou distintos)

LINGUAGEM NATURAL ESTRUTURADA

-> Restringe a liberdade do analista de requisitos;

-> Padronização;

-> Mantém facilidade de expressão da linguagem natural

-> Utilização de templates e/ou formulários.

-> Podem usar estruturas de controle

-> Podem utilizar notações gráficas.