• 

 

 

 

Resumo Engenharia de Software

 

---

 

Resumo Engenharia de Software

 

Ajude-nos a deixar-nos saber Larapedia.com relatou a um amigo / amiga ou relatar nosso site fórum sobre seu blog ou bookmarks sociais como o Facebook eTwitter, graças

 

Los siguientes textos son propiedad de sus respectivos autores y les damos las gracias por la oportunidad que nos brindan para presentar gratis a estudiantes, profesores y usuarios de la Web para sus textos ilustrativos con fines educativos y científicos.

 

 

 

La información en la medicina y la salud en este sitio es de carácter general y para propósitos informativos solamente y por lo tanto no puede sustituir en ningún caso el consejo de un médico (o una persona legalmente autorizada para la profesión).

 

 

 

 

 

Resumo Engenharia de Software

Resumo Engenharia de Software

Capítulo 01 – O Produto

O Software de computadores se tornou uma força motora. É o motor que dirige a tomada de decisão nos negócios. Serve de base à moderna investigação científica e às soluções de problemas de engenharia. É um fator chave que diferencia os produtos e serviços modernos. Está embutido em sistemas de todas as naturezas. O software é virtualmente inevitável no mundo moderno. E à medida que entramos no vigésimo primeiro século, irá se tornar um motor para novos avanços em tudo, da educação elementar à engenharia genética.
O impacto do software em nossa sociedade e cultura continua a ser profundo. À medida que sua importância cresce, a comunidade de software tenta continuamente desenvolver tecnologias que tornem mais fácil, mais rápido e menos dispendioso construir programas de computador de alta qualidade. Algumas dessas tecnologias são dirigidas a domínios específicos da aplicação. Outras se concentram em um domínio tecnológico e outras ainda são mais abrangentes.
Pessoas apostam seus empregos, seu conforto, sua segurança, sua diversão, suas decisões e suas próprias vidas nos softwares de computadores. Ele precisa estar certo.
A Tecnologia abrange um processo, um conjunto de métodos e ferramenta, que nós chamamos de engenharia de Software.

• O Papel Evolutivo do Software

O Software é o produto e ao mesmo tempo, o veículo para entrega do produto. Ele é um transformador de informação – produzindo, gerando, adquirindo, modificando, exibindo ou transmitindo informação. Como veículo, o Software age como uma base de controle do computador (sistemas operacionais), para a comunicação de informações (redes) e para criação e o controle de outros programas (ferramentas e ambientes de Software).
O Software entrega o mais importante produto de nossa época – a informação. Ele transforma dados pessoais de modo que possam ser mais úteis em determinado contexto; gera informação comercial para melhorar a competitividade; fornece um portal para as redes de informação de âmbito mundial e proporciona meios para obter informação em todas as suas formas.
Sofisticação e complexidade podem produzir magníficos resultados quando um sistema é bem sucedido, mas também podem causar enormes problemas para quem construir sistemas complexos.
O programados solitário de antigamente foi substituído por uma equipe de especialistas de Software, com cada um se concentrando numa parte da tecnologia necessária para produzir uma aplicação complexa. Os mesmos questionamentos feitos ao programador solitário estão sendo feitos quando modernos sistemas baseados em computador são construídos:

• Por que leva tanto tempo para concluir o Software?
• Por que os custos de desenvolvimento são tão altos?
• Por que não podemos achar todos os erros antes de entregar o Software aos clientes?
• Por que continuamos a ter dificuldades em avaliar o progresso enquanto o software é desenvolvido?

• Software

Softwares são: (1) instruções (programas de computadores) que quando executadas fornecem a função e o desempenho desejados, (2) estruturas de dados que permitem aos programas manipular adequadamente a informação e (3) documentos que descrevem a operação e o uso dos programas.

• Características do Software

O Software é um elemento de um sistema lógico. Assim o Software tem características que são consideravelmente diferentes daquelas do HW:

• O Software é desenvolvido, ou passa por um processo de engenharia de Software, não é manufaturado no sentido clássico.

A alta qualidade é conseguida por um bom projeto, mas a fase de fabricação do HW pode gerar problemas de qualidade, que são inexistentes para o Software. Ambas as atividades são dependentes de pessoas, mas a relação entre as pessoas é inteiramente diferente, as abordagens também são diferentes.
Os custos do Software são concentrados na engenharia. Isso significa que os projetos de Software não podem ser geridos como se fossem projetos de fabricação.

• O Software não “se desgasta”.

O HW exibe taxas de falha relativamente altas no início de sua vida, logo, os defeitos são corrigidos e a taxa de falhas cai para um nível constante por um certo período de tempo. Ao passar do tempo a taxa de falhas aumenta novamente à medida que os componentes de HW sofrem o efeito cumulativo de poeira, vibração, maltrato, gradientes de temperatura e muitos outros males ambientais, o seja, o HW começa a se desgastar.
O Software não é suscetível aos males ambientais. Teoricamente a curva da taxa de falhas para o Software deveria tomar a forma de “curva idealizada”. Defeitos não detectados irão causar altas taxas de falhas no início da vida de um programa. Todavia, eles corrigidos (sem a introdução de outros erros) e a curva se achata.
O Software não se desgasta, mas se deteriora! Durante a sua vida, o Software passará por modificações. À medida que modificações são feitas, é provável que alguns novos defeitos sejam introduzidos, causando um dente na curva de falhas. Antes que a curva possa voltar ao seu estado original da taxa de falhas estável, outra modificação é solicitada, causando um novo dente na curva. A taxa de falhas mínima começa a subir lentamente – o Software está se deteriorando devido a modificações.
Quando um componente de HW se desgasta é substituído por uma peça sobressalente. No Software não há peças sobressalentes. Toda falha indica um erro no projeto, ou no processo pelo qual o projeto foi traduzido para código de máquina executável. Assim, a manutenção do Software envolve consideravelmente mais complexidade do que a de HW.

• Apesar de a indústria estar se movendo em direção a montagem baseada em componentes, a maior parte de Software continua a ser construída sob encomenda.

Os componentes reutilizáveis foram criados para que o engenheiro possa se concentrar nos elementos realmente inovadores de um projeto. No mundo do Software, é algo que está apenas começando em ampla escala.
Um conjunto de Software deve ser projetado e implementado de modo que possa ser reusado em muitos programas diferentes. Na década de 60 construímos bibliotecas de sub-rotinas científicas que eram reusáveis num amplo conjunto de aplicações científicas e de engenharia. A idéia é criar novas aplicações a partir de partes reusáveis.

• Aplicações de Software

O Software pode ser usado em qualquer situação.
Software de Sistemas: é uma coleção de programas para servir outros programas. Processam estruturas de dados complexas, mas determinadas. São exemplos: Sistemas Operacionais, Acionadores, processadores de telecomunicações.
Software de tempo real: Monitora/Analisa/Controla eventos do mundo real à medida que eles ocorrem. Incluem um componente de coleção de dados, que coleta e formata a informação de um ambiente externo, um componente de análise, que transforma a informação tal como exigido pela aplicação, um componente de monitoração que coordena todos os outros componentes, de modo a que a resposta em tempo real possa ser mantida.
Software comercial: processamento de informação comercial é a maior área de aplicação do Software. Sistemas “discretos” evoluíram para Software de sistemas de gestão da informação (MIS), que acessa uma ou mais bases amplas de dados contendo informações comerciais. Facilita operações comerciais ou tomada de decisão de negócios.
Software Científico e de Engenharia: caracterizado por algoritmos number crunching (que processam números). Possui uma vasta área de aplicação (de astronomia a vulcanologia).
Software embutido: reside nas memórias ROM simples leitura e é usado para controlar produtos e sistemas para o mercado consumidor e industrial. Ex: Forno Microondas.
Software para computadores pessoais: Processadores de texto, planilhas eletrônicas, aplicações gráficas, multimídia e etc são apenas algumas das centenas de aplicações.
Software para WEB: as páginas da web constituem Software que incorpora instruções executáveis. A rede se transforma em um grande computador que fornece um recurso quase ilimitado de Software, que pode ser acessado por qualquer um que tenha um modem.
Software para Inteligência Artificial: Faz uso de algoritmos não numéricos para resolver problemas complexos que não são passíveis de computação ou na análise direta. Sistemas especialistas são representativos de aplicações dentro dessa categoria.

• Software: Uma crise no horizonte?

O pessoal de Software é freqüentemente mais bem-sucedido do que falha. A crise do Software prevista 30 anos atrás nunca parece ter se materializado.
O que temos realmente poderia ser melhor caracterizado como uma aflição crônica do que como uma crise.

• Mitos de Software

Mitos de Software propagaram desinformação e confusão. Esses mitos tinham certos atributos que os tornavam insidiosos.

MITOS DA GERÊNCIA: Os gerentes com responsabilidade sobre o assunto estão freqüentemente sob pressão para obedecer a orçamentos, manter cronogramas no prazo e melhorar a qualidade. Um gerente freqüentemente se agarra na credibilidade de um mito de Software, se isso puder diminuir a pressão.

MITO: Um livro que está cheio de padrões e procedimentos já não fornece ao meu pessoal tudo o que ele precisa saber?
REALIDADE: O livro de padrões pode muito bem existir, mas será que ele é usado? Os profissionais sabem de sua existência: Ele reflete as modernas práticas de Engenharia de Software? É completo? Está voltado para melhorar o prazo de entrega, mantendo o foco na qualidade? Em muitos casos a resposta é não.

MITO: meu pessoal tem ferramentas de desenvolvimento de Software que estão no estado-da-arte, afinal, compramos para eles os computadores mais novos.
REALIDADE: é necessário muito mais do que o último modelo de computador de grande porte para fazer o desenvolvimento de Software de alta qualidade. Ferramentas CASE são mais importantes que o HW para conseguir boa qualidade e produtividade, todavia a maioria dos desenvolvedores ainda não as utilizam efetivamente.
MITO: se nos atrasarmos no planejamento, podemos adicionar mais programadores e ficar em dia.
REALIDADE: o desenvolvimento de Software não é um processo mecanizado como o de fabricação. Adicionar pessoas a um projeto de Software atrasa-o ainda mais, pois precisa gastar tempo orientando os recém-chegados. Pessoas podem ser adicionadas, mas de forma planejada e bem coordenada.
MITO: se eu decidir terceirizar um projeto de Software vou poder relaxar e deixar que aquela firma o elabore.
REALIDADE: se uma organização não sabe como gerir e controlar projetos de Software inteiramente, certamente vai ter problemas quando terceirizar esses projetos.

MITOS DO CLIENTE: Em muitos casos o cliente acredita em mitos de Software porque os gerentes e profissionais de Software fazem pouco para corrigir essa desinformação. Mitos levam a falsas expectativas e, em última analise, à insatisfação com o desenvolvedor.
MITO: o estabelecimento geral de objetivos é suficiente para iniciar a escrita de programas – podemos fornecer os detalhes posteriormente.
REALIDADE: Uma definição inicial malfeita é a principal causa de esforços malsucedidos de Software. Uma descrição formal e detalhada do domínio da informação, da função, do comportamento, do desempenho, das interfaces, das restrições de projeto e dos critérios de validação é essencial. Essas características podem ser determinadas somente depois de intensa comunicação entre o cliente e o desenvolvedor.
MITO: os requisitos de projeto mudam continuamente, mas as mudanças podem ser facilmente acomodadas porque o software é flexível.
REALIDADE: É verdade que os requisitos de Software mudam, mas o impacto da mudança varia com a época em que é introduzida. Se uma atenção séria for dada à definição inicial, solicitações de mudanças que ocorrem no início do desenvolvimento podem ser acomodadas facilmente. Quando mudanças são solicitadas durante o projeto de software, o impacto no custo cresce rapidamente. Mudanças na função, no desempenho, na interface ou em outra característica durante a implementação (código e teste) têm um impacto significativo no custo. Mudanças solicitadas depois do Software entrar em produção podem ficar bem mais caras do que se fossem solicitadas antes.

MITOS DO PROFISSIONAL:
MITO: quando escrevemos um programa e o fazemos funcionar, nosso trabalho está completo.
REALIDADE: alguém um dia disse “quando mais cedo você começar a escrever código, mais vai demorar para acabar”. Entre 60 e 80% de todo o esforço despendido em software vai ser despendido depois dele ser entregue ao cliente pela primeira vez.
MITO: Até que eu esteja com o programa “rodando” não tenho como avaliar sua qualidade.
REALIDADE: um dos mecanismos mais eficazes de garantia de qualidade de Software pode ser aplicado a partir do início de um projeto – a revisão técnica formal. Revisões de Software são como um “filtro de qualidade” que se descobriu ser mais eficaz do que testes para encontrar alguns tipos de defeitos de Software.
MITO: o único produto de trabalho que pode ser entregue para um projeto de Software bem sucedido é o programa executável.
REALIDADE: Um programa executável é apenas uma parte de uma configuração de Software que inclui vários elementos. A documentação fornece a base para uma engenharia bem-sucedida e, mais importante, orienta para o suporte ao Software.
MITO: a engenharia de Software vai nos fazer criar documentação volumosa e desnecessária que certamente nos atrasará.
REALIDADE: a engenharia de Software não se relaciona à criação de documentos. Refere-se à criação de qualidade. Melhor qualidade leva à redução de trabalho. E menor retrabalho em tempos de entrega mais rápidos.

 

2. O Processo
     Quando você elabora um produto ou sistema é importante percorrer uma série de passos previsíveis – um roteiro que o ajuda a criar a tempo um resultado de alta qualidade.

2.1. Engenharia de SW: uma tecnologia em camadas
Aplicação de uma abordagem sistemática, disciplinada e quantificável, para o desenvolvimento, operação e manutenção do software, isto é, a aplicação de engenharia ao software.

2.1.1. Processos, métodos e ferramentas
Engenharia de software é uma tecnologia em camadas. Qualquer abordagem de engenharia deve se apoiar num compromisso organizacional com a qualidade.
O processo de engenharia de software é o adesivo que mantém unidas as camadas de tecnologia e permite o desenvolvimento racional e oportuno para computador.O processo define uma estrutura para um conjunto de áreas_chave de processo, que deve ser estabelecido para a efetiva utilização da tecnologia de engenharia de software. As áreas-chaves de processo formam a base para o controle gerencial de software e estabelecem o contexto no qual os métodos técnicos são aplicados, os produtos de trabalho (modelos, documentos, dados, relatórios, etc) são produzidos, marcos são estabelecidos, qualidade é assegurada e modificações são geridas.
Métodos de engenharia de software fornecem a técnica de como fazer para construir software e incluem atividades de modelagem e outras técnicas. Os métodos incluem um amplo conjunto de tarefas que abrange análises de requisitos, projeto, construção de programas, teste e manutenção.
Ferramentas de engenharia de software fornecem apoio automatizado ou semi-automatizado para o processo e para os métodos. Quando ferramentas são integradas de modo que a informação criada por uma ferramenta pode ser usada por outra, um sistema para o apoio ao desenvolvimento de software, chamado engenharia de software apoiada por computador, é estabelecido. CASE combina software, hardware e uma base de dados de engenharia de software(um depósito que contém informação importante sobre análise, projeto, construção de programas e teste) para criar um ambiente de engenharia de software análogo ao CAD/CAE(projeto/engenharia apoiada por computador) para hardware.

2.1.2. Uma visão genérica da engenharia de sw
Engenharia é a análise, o projeto, a construção, a verificação e a gestão de elementos técnicos(sociais).Independentemente do elemento a ser tratado, as seguintes questões devem ser colocadas e respondidas:

• Qual é o problema a ser resolvido?
• Que características do elemento são usadas para resolver o  problema?
• Como o elemento (e a solução) serão realizados?
• Como o elemento vai ser construído?
• Que abordagem será usada para descobrir erros que foram cometidos no projeto e na         construção do elemento?
• Como o elemento será mantido a longo prazo, quando correções, adaptações e   aperfeiçoamentos forem solicitados pelos usuários?

O trabalho de associado com a engenharia de software pode ser categorizado em três fases genéricas independentemente da área de aplicação, do tamanho do projeto ou de sua complexidade.
A fase de definição se concentra no quê.
A fase de desenvolvimento focaliza o como. Isto é o engenheiro tenta definir como os dados devem ser estruturados
A fase de manutenção focaliza as modificações.  Associadas com a correção de erros, as adaptações necessárias, à medida que o ambiente do software evolui. Quatro tipos de modificação são encontrados durante a fase de manutenção:
Correção: Manutenção corretiva modifica o sw para corrigir defeitos.
Adaptação: Manutenção adaptativa modificações no sw para acomodar mudanças no seu ambiente externo.
Aperfeiçoamento:Manutenção perfectiva aprimora o sw além dos requisitos funcionais originais.
Prevenção:Manutenção preventiva faz mudanças de modo que os programas possam ser mais facilmente corrigidos, adaptados e melhorados.

2.2. O processo de SW
Uma estrutura comum de processo é estabelecida definindo um pequeno número de atividades dessa estrutura, que são aplicáveis a todos os projetos de sw, permite que as atividades da estrutura sejam adaptadas as características do projeto de  sw e às necessidades da equipe de projeto.

 

2.3. Modelos de Processo de SW
Para resolver problemas reais numa instalação industrial, um engenheiro de sw, deve incorporar uma estratégia de desenvolvimento que abrange as camadas de processo, os métodos e ferramentas. Essa estratégia é freqüentemente referida como modelo de processo ou paradigma de engenharia de software. Um modelo é escolhido com base na natureza do projeto e da aplicação, nos métodos e ferramentas a serem usados, e nos controles e nos produtos intermediários e finais que são requeridos.
Todo o desenvolvimento de sw pode ser caracterizado como um ciclo de solução de problema, no qual são encontrados quatro estágios distintos:
Situação atual ->  Definição do problema -> Desenvolvimento técnico -> Integração da solução

2.4. O modelo seqüencial linear
Algumas vezes chamado de ciclo de vida clássico ou modelo em cascata, o modelo seqüencial linear sugere uma abordagem sistemática seqüencial para o desenvolvimento de sw, que começa no nível de sistema e progride através da análise, projeto, codificação, teste e manutenção. O modelo seqüencial linear abrange as seguintes atividades:
Modelagem e engenharia do sistema/informação: como o sw sempre faz parte de um sistema maior, o trabalho começa pelo estabelecimento de requisitos para todos os elementos do sistema depois pela alocação de algum subconjunto desses requisitos para o sw.
Analise de requisitos de software: o processo de definição de requisitos é intensificado e focalizado especificamente no sw. Os requisitos do sistema são documentados e revistos com o cliente.
Projeto: O projeto do sw, é na verdade um processo de múltiplos passos que enfoca quatro atributos distintos do programa: estrutura de dados, arquitetura do sw, representações da interface e detalhes procedimentais.
Geração de código: O projeto deve ser traduzido para linguagem de máquina. Se o projeto é realizado de maneira detalhada, a geração de código pode ser realizada mecanicamente.
Teste: Uma vez gerado o código, o teste do programa tem início, focalizando os aspectos lógicos internos do sw, garantindo que todos os comandos sejam testados, e os aspectos externos funcionais; isto é, conduz testes para descobrir erros e garantir que entradas definidas produzirão resultados reais, que concordam com os resultados exigidos.
Manutenção: O sw irá inevitavelmente sofrer modificações depois de ser liberado para o cliente, uma modificação acontece quando erros são encontrados, quando o sw precisa ser adaptado para acomodar mudanças no seu ambiente externo(SO, ou dispositivos periféricos).
Desvantagens:

• O cliente precisa ter paciência. Uma versão executável do programa não vai ficar disponível até o projeto terminar. Um erro grosseiro pode ser desastroso, se não for detectado até que o programa executável seja revisto.

2.5. O modelo de prototipagem
O paradigma de prototipagem começa com a definição de requisitos. O desenvolvedor e o cliente encontram-se e  definem os objetivos gerais do sw, identificam as necessidades conhecidas e delineiam áreas que necessitam de mais definições. Um “projeto rápido” é então realizado. Esse projeto concentra-se na apresentação daqueles aspectos que vão ficar visíveis ao cliente/usuário. O protótipo  é avaliado pelo cliente e usado para ajustar as necessidades do cliente permitindo ao desenvolvedor  entender melhor o que precisa ser feito.
O cliente e o desenvolvedor devem estar de acordo que o protótipo seja construído para servir como um mecanismo para definição de requisitos. E depois ele é descartado e o sw real é submetido à engenharia com o objetivo de buscar qualidade e a manutenibilidade.
Desvantagem:
O desenvolvedor freqüentemente faz concessões na implementação a fim de conseguir rapidamente um protótipo executável. Um SO ou uma linguagem de programação inapropriada pode ser usado simplesmente por estar disponível e serem conhecidos; um algoritmo ineficiente pode ser implementado.

2.6. O modelo RAD
O desenvolvimento rápido de aplicação é um modelo de processo de desenvolvimento de sw incremental que enfatiza um ciclo de desenvolvimento extremamente curto, sendo uma adaptação “de alta velocidade” do modelo seqüencial linear. O RAD abrange as seguintes fases:
Modelagem do negócio: O fluxo de informação entre as funções do negócio é modelado de forma a responder as seguintes questões: Que informação dirige o processo do negócio? Que informação é gerada? Quem a gera?  Para onde vai a informação? Quem a processa?
Modelagem dos dados: As características de cada objeto(atributos) são definidas  e as relações entre esses objetos são definidas.
Modelagem do processo: Descrições do processamento são criadas para adicionar, modificar, descartar ou recuperar um objeto de dados.
Geração da aplicação: O RAD  utiliza ferramentas automatizadas para facilitar a construção do sw.
Teste e entrega: como o processo RAD enfatiza o reuso, muitos componentes de programa já devem ter sido testados. Isso reduz o tempo total de teste.
Cada função principal pode ser tratada por uma equipe RAD distinta e depois integrada para formar um todo.

 

2.7. Modelos de Processo de Software Evolucionários: Torna-se cada vez mais evidente que o SW, como todos os sistemas complexos, evolui durante um período de tempo. Requisitos do negócio e do produto mudam freqüentemente à medida que o desenvolvimento prossegue, dificultando um caminho direto para um produto final; prazos reduzidos de mercado tornam impossível completar um produto de SW abrangente, mas uma versão reduzida pode ser elaborada para fazer face à competitividade ou às pressões do negócio.
2.7.1. O modelo incremental: O modelo incremental combina elementos do modelo seqüencial linear com a filosofia interativa da prototipagem. Cada seqüência linear produz um “incremento” factível do SW. Quando um modelo incremental é usado, o primeiro incremento é freqüentemente chamado núcleo do produto. Isto é, os requisitos básicos são satisfeitos, mas muitas características suplementares deixam de ser elaboradas. Um plano é desenvolvido para o próximo incremento, como resultado do uso e/ou avaliação. O plano visa à modificação do núcleo do produto para melhor satisfazer às necessidades do cliente e a elaboração de características e funcionalidades adicionais. Esse processo é repetido após a realização de cada incremento, até que o produto completo produzido. O modelo de processo incremental, como a prototipagem e outras abordagens evolucionárias, é interativo por natureza. Mas, diferente da prototipagem, o modelo incremental objetiva a elaboração de um produto operacional a cada incremento. O desenvolvimento incremental é particularmente útil quando não há mão-de-obra disponível para uma implementação completa, dentro do prazo comercial de entrega estabelecido para o projeto.
2.7.2. O modelo espiral: O modelo espiral é um modelo de processo de SW evolucionário que combina a natureza iterativa da prototipagem com os aspectos controlados e sistemáticos do modelo seqüencial linear. Fornece potencial para o desenvolvimento rápido de versões incrementais do SW. A versão incremental, durante as primeiras iterações, pode ser um modelo de papel ou protótipo. Um modelo espiral é dividido em um certo número de atividades, que formam uma estrutura chamada de regiões de tarefas. Há de 3 a 6:
- Comunicação com o cliente: tarefas necessárias para estabelecer efetiva comunicação entre o desenvolvedor e o cliente;
­- Planejamento: tarefas necessárias para definir recursos, prazos e outras informações relacionadas ao projeto;
- Análise de risco: tarefas necessárias para avaliar os riscos, tanto técnicos quanto gerenciais;
- Engenharia: tarefas necessárias para construir uma ou mais representações da aplicação;
- Construção e liberação: tarefas necessárias para construir, testar, instalar e fornecer apoio ao usuário;
- Avaliação pelo cliente: tarefas necessárias para obter realimentação do cliente, com base na avaliação das representações do SW criadas durante o estágio de engenharia e implementadas durante o estágio de instalação.
Cada uma das regiões é preenchida por um conjunto de tarefas de trabalho chamado de conjunto de tarefas, que são adaptados às características do projeto a ser desenvolvido. À medida que esse processo evolucionário tem início, a equipe de engenharia de SW move-se em volta da espiral, no sentido horário, a partir do centro. O 1º circuito em torno da espiral pode resultar no desenvolvimento da especificação do produto; passagens subseqüentes em torno da espiral podem ser usadas para desenvolver um protótipo e depois, progressivamente, versões mais sofisticadas do SW. Cada passagem pela região de planejamento resulta em ajustes ao plano do projeto. O custo e o cronograma são ajustados de acordo com a avaliação do cliente. Além disso, o gerente de projeto em quem ajusta a quantidade de iterações necessárias planejada para completar o SW.
O modelo espiral é uma abordagem realística para o desenvolvimento de sistemas e SW de grande porte. Como o SW evolui à medida que o processo avança, o desenvolvedor e o cliente entendem melhor e reagem aos riscos em cada nível evolucionário. Este modelo usa a prototipagem como mecanismo de redução de risco e também permite ao desenvolvedor aplicar a prototipagem em qualquer estágio de evolução do produto. O modelo espiral exige a consideração direta dos riscos técnicos em todos os estágios do projeto e, se aplicado adequadamente, deve reduzir os riscos antes que eles fiquem problemáticos.
Vantagens: As maiores vantagens do modelo espiral advêm de sua flexibilidade e da abordagem baseada na análise de riscos, permitindo:

• utilizar outros modelos de desenvolvimento de software, aproveitando as suas vantagens e evitando os seus problemas, identificados através da análise de riscos;
• para cada atividade do desenvolvimento, responder a pergunta: “quanto é bastante?”, isto é, responder até que nível deve ir a análise de requisitos, o planejamento, a fase de testes, a garantia de qualidade, etc. Cada projeto tem exigências próprias para esses parâmetros e a análise de riscos pode determinar o que deve ser feito em cada situação, descobrindo qual é o risco de não se fazer o bastante;
• um mecanismo para incorporar objetivos de qualidade de software ao desenvolvimento, através da ênfase em identificar todos os tipos de objetivos e limitações em cada ciclo da espiral – isso engloba, naturalmente, objetivos como facilidade de uso e portabilidade do sistema, por exemplo, e limitações como confiabilidade e robustez, entre outras;
• foco na opção de reuso de software já existente, através do levantamento das diferentes alternativas para alcançar os objetivos;
• a eliminação de erros e alternativas inadequadas, através da análise de riscos e da revisão das atividades de cada ciclo;

Dificuldades: As dificuldades inerentes à aplicação do modelo espiral também são causadas pela sua natureza genérica e pelo forte apoio na análise de riscos para obter sucesso, pois:

• é preciso contar com uma equipe experiente na identificação e redução de riscos, sob pena de que sejam tomadas decisões erradas durante o desenvolvimento;
• modelo precisa de uma maior elaboração de seus passos para que possa ser aplicado de maneira consistente por toda a equipe de desenvolvimento. Principalmente se a equipe for grande e contiver membros inexperientes. Como exemplos de atividades que precisam ser mais detalhadas podemos citar a definição de milestones e indicadores do progresso do desenvolvimento, técnicas para definir e sincronizar cronogramas, meios de identificar as principais fontes de riscos e de reduzir os riscos mais comuns;
• a negociação de contrato com um cliente externo é difícil, pois a espiral requer um certo nível de flexibilidade e liberdade nos prazos e custos do desenvolvimento.

2.7.3. O modelo espiral ganha-ganha: O objetivo dessa atividade é formular os requisitos de projeto do cliente. Em um contexto ideal, o desenvolvedor simplesmente pergunta ao cliente o que é necessário e o cliente fornece os detalhes suficientes para prosseguir. As melhores negociações buscam um resultado “ganha-ganha”. Isto é, o cliente ganha obtendo um produto ou sistema que satisfaz à maior parte das necessidades do cliente, e o desenvolvedor ganha trabalhando com orçamentos e prazos de entrega realísticos e possíveis de serem cumpridos. Este modelo define um conj. de atividades de negociação no começo de cada passagem, em torno da espiral. As seguintes atividades são definidas: 1) identificação dos principais “interessados” do sistema ou do subsistema; 2) determinação das “condições de lucro” do interessado; 3) negociação das condições de ganho do interessado para reconciliá-las no âmbito das condições ganha-ganha para todos os envolvidos.
Além da ênfase na negociação inicial, o modelo ganha-ganha introduz 3 marcos de processo, chamados pontos de ancoragem, que ajudam a estabelecer quando um ciclo é completado em torno da espiral e fornecem marcos de decisão antes do projeto de SW prosseguir. Os pontos de ancoragem representam 3 visões de progresso: 1) Objetivos de ciclo de vida: define um conj. de objetivos para cada atividade principal de engenharia de SW. 2) Arquitetura do ciclo de vida: estabelece objetivos que precisam ser satisfeitos, à medida que a arquitetura do sistema, e do SW, é definida. 3) Capacidade operacional inicial: representa um conjunto de objetivos associado com a preparação do SW para instalação/distribuição, preparação do local antes da instalação e assistência requerida por todas as partes que irão usar ou dar suporte ao SW.
2.7.4. O modelo de desenvolvimento concorrente: algumas vezes chamado de engenharia concorrente. Este modelo pode ser representado como uma série de atividades técnicas principais, tarefas e seus estados associados. *A atividade de análise pode estar em qualquer um dos estados notados em qualquer tempo.
Esse modelo define uma série de eventos que vão disparar transições de estado para estado, para cada uma das atividades de engenharia de SW. Ele é freqüentemente usado como paradigma para o desenvolvimento de aplicações cliente/servidor. Um sistema cliente/servidor é composto de um conj. de componentes funcionais. Qdo aplicado a cliente/servidor, o modelo de processo concorrente define atividades em duas dimensões: dimensão de sistema e dimensão de componente. Assuntos em nível de sistema são tratados usando 3 atividades: projeto, montagem e utilização. A de componente usa 2 atividades: projeto e realização. A concorrência é conseguida de 2 formas: 1) atividades de sistema e de componentes ocorrem simultaneamente e podem ser modeladas usando a abordagem orientada a estados; 2) uma aplicação típica cliente/servidor é implementada com vários componentes, cada um dos quais pode ser projetado e realizado concorrentemente.
2.8. Desenvolvimento baseado em componentes: Esse modelo incorpora muitas das características do melo espiral. Evolucionário por natureza, demanda uma abordagem iterativa para a criação de SW. Todavia, o modelo de desenvolvimento baseado em componentes compõe aplicações a partir de componentes de SW previamente preparados (chamados classes). O modelo de desenvolv. baseado em componentes leva ao reuso de SW e isso fornece aos engenheiros um certo nº de benefícios mensuráveis. O processo unificado de desenvolvimento de SW é representativo de um certo nº de modelos de desenvolvimento baseados em componentes, que foram propostos pela indústria. Usando a UML o processo unificado define os componentes que serão usados para construir o sistema e as interfaces que irão conectar esses componentes. Usando uma combinação de desenvolvimento iterativo e incremental, o processo unificado define a função do sistema pela aplicação de uma abordagem baseada em cenário.
2.9. O modelo de métodos formais: Abrange um conj. de atividades que levam à especificação matemática formal do SW de computador. Métodos formais permitem ao engenheiro de SW especificar, desenvolver e verificar um sistema baseado em computador, pela aplicação de uma rigorosa notação matemática. Qdo são usados métodos formais durante o desenvolvimento, um mecanismo para eliminação de vários problemas difíceis de resolver usando outros paradigmas de engenharia de SW é fornecido. Ambigüidade, inconclusão e inconsistência podem ser descobertas e corrigidas mais facilmente, não através das revisões comuns, mas através da aplicação de análise matemática. Qdo são usados durante o projeto, métodos formais servem como base para a verificação do programa e assim permitem que o engenheiro de SW descubra e corrija erros que poderiam passar despercebidos. Preocupações sobre a aplicabilidade dos métodos formais: 1) o desenvolvimento de modelos formais é muito lento e dispendioso; 2) deve-se ter um treinamento extensivo para os desenvolvedores; 3) é difícil usar os modelos como um mecanismo de comunicação, com clientes despreparados tecnicamente.
2.10. Técnicas de quarta geração: Abrange um amplo conj. de ferramentas de SW que têm uma coisa em comum: cada ferramenta permite que o engenheiro de SW especifique alguma característica do SW em alto nível. O paradigma 4GT para engenharia de SW concentra-se na habilidade de especificar SW usando formas especializadas de linguagem, ou uma anotação gráfica que descreve o problema a ser resolvido de forma que o cliente possa entender. O 4GT, começa com a definição de requisitos. O ideal seria que o cliente fosse descrevendo os requisitos e esses fossem traduzidos diretamente num protótipo operacional. O cliente pode não estar certo do que é necessário, pode ser ambíguo na especificação de fatos conhecidos e pode não conseguir, ou não desejar, especificar a informação, de forma que uma ferramenta 4GT possa ser utilizada. O uso de 4GT sem projeto irá causar as mesmas dificuldades que têm sido encontradas quando se desenvolve SW usando as abordagens convencionais. A implementação usando uma 4GL  permite que o desenvolvedor de SW represente os resultados desejados de uma forma que leva à geração automática de código para criar aqueles resultados. Para transformar uma implementação 4GT num produto, o desenvolvedor precisa realizar testes exaustivos, desenvolver documentação adequada e realizar todas as outras atividades de integração da solução, necessárias em outros paradigmas de engenharia de SW. O SW desenvolvido por 4GT deve permitir a realização rápida de manutenção.
2.11. Tecnologia de Processo: As ferramentas de tecnologia de processo permitem a uma organização de SW construir um modelo automatizado do arcabouço comum de processo, dos conjuntos de tarefas e das atividades guarda-chuva. O modelo normalmente representado como uma rede, pode então ser analisado para determinar o fluxo típico de trabalho e examinar estruturas de processo alternativas, que poderiam reduzir o tempo de desenvolvimento ou o custo. Uma vez criado um processo aceitável, outras ferramentas de tecnologia de processo podem ser usadas para atribuir, monitorar e até mesmo controlar todas as tarefas de engenharia de SW definidas como parte do modelo de processo.
2.12. Produto e processo: Ler na apostila.

 

Capitulo 11

Conceitos e princípios de análise

A engenharia de requisitos de software é um processo de descobrimento, refinamento, modelagem e especificação. Os requisitos do sistema e o papel atribuído ao software - estabelecidos inicialmente pelo engenheiro de sistemas - são refinados em detalhes. Modelos dos dados, informação e fluxo de controle, bem como comportamentos operacionais necessários, são criados. Soluções alternativas são analisadas e um modelo de análise completo é criado.
Engenharia de requisitos é o uso sistemático de princípios, técnicas, linguagens e ferramentas comprovadas para a análise, documentação, evolução continuada das necessidades do usuário e especificação do comportamento esterno de um sistema para satisfazer as necessidades do usuário, que sejam efetivas em termos de custo.
Tanto o engenheiro de software quanto o cliente assumem papel ativo na engenharia de requisitos de software - conjunto de atividades que é freqüentemente referido como análise. O cliente tenta reformular uma descrição, às vezes nebulosa, em nível de sistema dos dados, função e comportamento em detalhes concretos. O desenvolvedor age como inquisidor, consultor, solucionador de problemas e negociador.

Panorama
O que é? O papel do software num sistema durante a engenharia de sistemas. No entanto, é necessário olhar mais atentamente para o papel do software - a fim de entender os requisitos específicos que precisam ser satisfeitos para construir software de alta qualidade. Esse é o serviço da análise de requisitos de software. Para realizar o serviço adequadamente, você deve seguir um conjunto de conceitos e princípios subjacentes.
Que faz? Geralmente, um engenheiro de software realiza a análise de requisitos. No entanto, para aplicações comerciais complexas, um "analista de sistema" pode realizar a tarefa.
Por que é importante? Para construção de soluções de software sem perda de tempo e dinheiro, frustração pessoal e clientes insatisfeitos.
Quais são os passos? Requisitos de dados, funcionais e comportamentais são identificados pela elicitação da informação do cliente. Requisitos são refinados e analisados para avaliar sua clareza, completeza e consistência. Uma especificação que incorpora um modelo de software é criado e depois validada tanto pelos engenheiros de software quanto pelas clientes/usuários.
Qual é o produto do trabalho? Uma representação efetiva do software deve ser produzida em conseqüência da análise de requisitos. Como os requisitos do sistema, os requisitos do software, podem ser representados usando um protótipo, uma especificação ou até um modelo simbólico.
Como garanto que fiz corretamente? Os produtos de trabalho de análise de requisitos de software devem ser revistos quanto à clareza, completeza e consistência.

11.1 Análise de requisitos

   Análise de requisitos é uma tarefa de engenharia de software que vence o espaço entre a engenharia de requisitos, no nível de sistemas, e o projeto de software. As atividades de engenharia de requisitos resultam na especificação das características operacionais do software (função, dados e comportamento), indicam a interface do software com outros elementos do sistema e estabelecem restrições que o software deve satisfazer. A análise de requisitos permite ao engenheiro de software refinar a atribuição do software e construir modelos dos domínios de dados, funcional e comportamental que serão tratados pelo software. A análise de requisitos fornece ao projetista de software uma representação da informação, função e comportamento, que podem ser traduzidos para os projetos dos dados, arquitetura, interface e para o nível de componentes. Finamente, a especificação de requisitos fornece ao desenvolvedor e ao cliente os meios de avaliar a qualidade quanto o software é construído.
A Análise de requisitos pode ser dividida em cinco áreas: reconhecimento do problema, avaliação e síntese, modelagem, especificação e revisão. Inicialmente, o analista estuda a Especificação do Sistema e o Plano do Projeto de Software. É importante entender o software no contexto do sistema e revisar o escopo do software que foi usado para gerar as estimativas de planejamento. A seguir, a comunicação para a análise deve ser estabelecida de modo que seja garantido o reconhecimento do problema.
A próxima área é a avaliação do problema e síntese da solução. O analista deve definir todos os objetivos de dados observáveis externamente, avaliar o fluxo e conteúdo de informação, definir e refinar todas as funções do software, entender o comportamento do software no contexto dos eventos que afetam o sistema, estabelecer as características das interfaces do sistema e descobrir restrições adicionais de projeto. Cada uma dessas tarefas serve para descrever o problema de modo que uma abordagem ou solução global possa ser sitentizada.
Após avaliar os problemas atuais e a informação desejada (entrada e saída), o analista começa a sintetizar uma ou mais soluções. Para começar, os objetos de dados, funções de processamento e comportamento do sistema são definidas em detalhe. Uma vez estabelecida essa informação, arquiteturas básicas para implementação são consideradas. O processo de avaliação e síntese continua até que o analista e o cliente se sintam seguros de que o software pode ser especificado adequadamente para os passos subseqüentes de desenvolvimento.
Durante a avaliação e síntese de solução, o principal foco do analista é “que”, não “como”.
Durante a atividade de avaliação e síntese de solução, o analista cria modelos do sistema no esforço de entender melhor os dados e fluxo de controle, o processamento funcional, o comportamento operacional e conteúdo da informação. O modelo serve como fundamento para o projeto de software e como base para a criação de especificações para o software.
O cliente pode estar inseguro do que é precisamente necessário. O desenvolvedor pode estar inseguro de que uma abordagem específica vai conseguir função e desempenho adequado. Por essas e muitas outras razões, uma abordagem alternativa para a análise de requisitos, chamado prototipagem, pode ser conduzida.

11.2 Elicitação de requisitos para o software

   Antes que os requisitos possam ser analisados, modelados ou especificados eles precisam ser reunidos usando-se um processo de elicitação.

11.2.1 Início do processo

   A técnica mais comumente usada de elicitação de requisitos é conduzir uma reunião ou entrevista. A primeira reunião entre um engenheiro de software (o analista) e o cliente. Nenhuma das pessoas sabe o que dizer ou perguntar; ambas estão preocupadas em serem mal-interpretadas; ambas estão pensando sobre aonde isso iria levar (provavelmente ambas tenham expectativas radicalmente diferentes quanto a isso); ambas desejam acabar logo com o encontro, mas ao mesmo tempo, desejam que ele seja um sucesso.
Para facilitar o inicio da comunicação Gause e Weinberg sugere que o analista comece formulando questões livres de contexto, onde o primeiro conjunto de questões livres de contexto focalize o cliente, os objetivos globais e os benefícios. Por exemplo, o analista podia perguntar: “quem está por trás da solicitação deste trabalho? Quem vai usar a solução”? Essas questões ajudam a identificar todos os envolvidos, o benefício mensurável de uma implantação bem-sucedida e possíveis alternativas para o desenvolvimento de software sob encomenda.
O conjunto de questões a seguir possibilita ao analista obter um melhor entendimento do problema e ao cliente verbalizar sua percepção de uma solução: “que problema(s) essa solução enfrentaria? Você pode me mostra (ou descrever) o ambiente no qual a solução será usado”?
O conjunto final de questões focaliza a efetividade da reunião como, por exemplo: “estou formulando muitas questões? Devo perguntar-lhe mais alguma coisa”?
Essas questões (e outras) vão ajudar a “quebrar o gelo” e iniciar a comunicação, que é essencial para a análise bem-sucedida. No entanto, uma reunião na forma de perguntas e repostas não é uma abordagem que tem sido extremamente bem-sucedida. De fato, a seção Q&A deve ser usada apenas para o primeiro encontro e depois ser substituída por uma forma de reunião que combine elementos de solução de problemas, negociação e especificação.

11.2.2 Técnicas facilitadas de especificação de aplicações

Clientes e engenheiros de software em vez de trabalhar como equipe para identificar e refinar requisitos, cada parte define seu próprio “território” e se comunica por intermédio de uma série de memorandos, declarações formais de posicionamento, documentação e sessões de perguntas e respostas. A história tem mostrado que essa abordagem não funciona muito bem.
É com esses problemas em mente que diversos pesquisadores independentes desenvolveram uma abordagem orientada a equipe para elicitação de requisitos que é aplicada durante os primeiros estágios da análise e especificação. Chamada de técnicas facilitadas de especificação de aplicação (facilitated application specification techniques, FAST), essa abordagem encoraja a criação de uma equipe conjunta de clientes e desenvolvedores, que trabalham juntos para identificar o problema, propor elementos da solução, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da solução.
Muitas abordagens diferentes de FAST têm sido propostas. Cada uma faz uso de um cenário ligeiramente diferente, mas todas aplicam alguma variante das seguintes diretrizes básicas:

• Uma reunião em local neutro com a participação de engenheiros de software e de clientes.
• São estabelecidas regras para preparação e participação
• É sugerida uma agenda que é suficientemente formal para cobrir todos os pontos importantes, porém suficientemente informal para encorajar o livre fluxo de idéias.
• Um “facilitador” para controlar a reunião.
• É usado um “mecanismo de definição (Exs: folhas de rascunho, papel-adesivo...).
• A meta é identificar o problema, propor elementos da solução, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da solução em uma atmosfera que propicie que a meta seja alcançada.

Em seqüência mostra o fluxo de eventos que ocorre numa reunião típica de FAST.
Reuniões iniciais entre o cliente e o desenvolvedor ocorrem e perguntas e respostas básicas ajudam a estabelecer o escopo do problema e a percepção geral de uma solução. São selecionados um local de reunião, horário e data para FAST e é escolhido um facilitador.
Enquanto revê a solicitação nos dias que precedem a reunião; são solicitados a cada participante que faça uma lista dos objetos que são parte do ambiente que cerca o sistema, outros objetos que devem ser produzidos pelo sistema e objetos que são usados pelo sistema para desempenhar suas funções. É solicitado também a cada participante que faça outra lista de serviços que manipulam ou interagem com os objetos. Finalmente, são também desenvolvidas listas de restrições e critérios de desempenho.
Exemplo de uma equipe FAST trabalhando para uma empresa de produtos para o consumidor obteve a seguinte descrição de produto:
Nossa pesquisa indica que o mercado para sistema domésticos de segurança está crescendo a uma taxa de 40% ao ano. Gostaríamos de entrar nesse mercado construindo um sistema de segurança doméstico baseado em microprocessador, que iria proteger contra e/ou reconhecer várias “situação” indesejáveis tais como entrada ilegal, fogo, inundação e outras. O produto, chamado experimentalmente de SafeHome, usará sensores adequados para detectar cada situação, poderá ser programado pelo proprietário e discará automaticamente para uma agência de monitoração quando uma situação for detectada.
A equipe FAST é composta de representantes de comercialização, engenharia de software e hardware, e fabricação, além de um facilitador externo.
Cada pessoa da equipe FAST desenvolve as listas descritas anteriormente. Os objetos descritos na SafeHome poderiam ser detector de fumaça, sensores para janelas e portas, etc. A lista de serviços pode ser ligar o alarme, monitorar os sensores, discar o telefone, etc. Cada participante da FAST vai desenvolver listas de restrições (por exemplo custo de fabricação) e de critérios de desempenho (por exemplo um evento de sensoriamente deve ser reconhecido dentro de um segundo).
O primeiro passo da discussão é a necessidade e a justificativa do novo produto – todos devem concordar que o produto é justificável. Depois cada participante apresenta uma lista para discussão. O ideal seria que cada entrada em uma lista pudesse ser manipulada separadamente de modo que as listas possam ser combinadas, as entradas possam ser apagadas e possam sr feitas adições. Nesse estágio, críticas e debates são estritamente proibidos.
Depois é criada uma lista combinada, onde elimina entradas redundantes, adicionarem qualquer idéia nova que surgiu durante a discussão, mas não apaga nada. Assim a discussão pode ter início. O objetivo é desenvolver uma lista de consenso em cada assunto (objetos, serviços, restrições e desempenho).
As listas são então postas de lado para ação posterior. Então é equipe é subdividida em equipes menores; cada uma trabalhando pra desenvolver miniespecificações para uma ou mais entradas de cada uma das listas. Cada miniespecificação é um detalhamento da palavra ou frase que consta de uma lista.
Cada subequipe apresenta então cada uma das suas miniespecificações a todos os participantes do FAST para discussão. Adições, supressões e mais detalhamentos são feitos. Podem ser adicionados novos objetos, serviços, restrições ou requisitos de desempenho. Uma lista de assuntos é mantida de modo que as idéias possam ser trabalhadas depois.
Depois que as miniespecificações são completada, cada participante FAST faz uma lista de critérios de validação para o produto/sistema e apresenta sua lista à equipe. Uma lista de consenso dos critérios de validação é então criada. Finalmente é criado um rascunho completo da especificação, usando todas as entradas produzidas pela reunião FAST.
FAST não é uma panacéia para os problemas encontrados na elicitação inicial de requisitos. Mas a abordagem de equipe fornece os benefícios de muitos pontos de vista, discussão e refinamento instantâneas e é um passo concreto para o desenvolvimento de uma especificação.

11.2.3 Desdobramento da função de qualidade

   Desdobramento da função de qualidade (quality function deployment, QFD) é uma técnica de gestão de qualidade que traduz as necessidades do cliente para requisitos técnicos do software. O QFD concentra-se em maximizar a satisfação do cliente a partir do processo de engenharia de software. Para conseguir isso, o QFD enfatiza o entendimento do que tem valor para o cliente e depois desdobra esses valores através do processo de engenharia. O QFD é identifica três tipos de requisitos:
Requisitos normais: os objetivos e metas que são estabelecidos para o produto ou sistema durante reuniões com o cliente. Se estiver presente é motivo de satisfação do cliente.
Requisitos esperados: esses requisitos estão implícitos nos produtos ou sistema e podem ser tão fundamentais que o cliente não se refere a eles explicitamente. Sua ausência seria causa de insatisfação significativa.
Requisitos excitantes: essas características vão além das expectativas do cliente e mostram ser muito satisfatórias quando presentes.

   O QFD cobre todo o processo de engenharia, no entanto, muitos conceitos QFD são aplicáveis às atividades de elicitação de requisitos.
O QFD usa entrevista com o cliente e observação, levantamentos e exame de dados históricos como dados em bruto para a atividade de elicitação de requisitos. Esses dados são então traduzidos para uma tabela de requisitos, chamada de tabela de voz do cliente, que é revisada com o cliente. Uma variedade de diagramas, matrizes e métodos de avaliação é então usada para elicitar os requisitos esperados e para tentar derivar os requisitos notáveis.

11.2.4 Casos de uso

   À medida que os requisitos são elicitados como parte de reuniões informais, FAST ou QFD, o engenheiro de software (analista) pode criar um conjunto de cenários que identifica uma linha de uso para o sistema a ser construído. Os cenários, frequentemente chamados de casos de usos, fornecem uma descrição de como o sistema será usado.
Para criar um caso de uso, o analista deve primeiro identificar os diferentes tipos de pessoas (ou dispositivos) que usam o sistema ou produto. Esses autores, na verdade, representam papéis que as pessoas (ou dispositivos) desempenham quando o sistema opera. Definido de um modo um tanto mais formal, um ator é qualquer coisa que se comunica com o sistema ou produto e que não faz parte dele.
É importante notar que um ator e um usuário não são a mesma coisa. Um usuário típico pode desempenhar vários papéis diferentes quando usa o sistema, enquanto um ator representa uma classe de entidades externas.
Como a elicitação de requisitos é uma atividade evolutiva, nem todos os atores são identificados durante a primeira iteração. É possível identificar atores principais, durante a primeira iteração, e atores secundários, quando se fica sabendo mais a respeito do sistema. Os atores principais interagem para conseguir a função desejada do sistema e derivam o beneficio pretendido. Trabalham direta e frequentemente com o software. Os atores secundários dão suporte ao sistema, de modo que os atores principais possam fazer seu trabalho.
Uma vez identificados os atores, casos de uso podem ser desenvolvidos. O caso de uso descreve o modo pelo qual um ator interage com o sistema. Algumas questões que devem ser respondidas pelo caso de uso: “que informação o ator deseja do sistema? O ator deseja ser informado sobre modificações inesperadas”?
Em geral, um caso de uso é simplesmente uma narrativa escrita que descreve o papel de um ator à medida que ocorre a interação com o sistema.
Voltando aos requisitos básicos do SafeHome, podemos definir três atores: o proprietário (usuário), sensores (dispositivos ligados ao sistema) e o subsistema de monitoração e resposta (a estação centra que monitora SafeHome). Para a finalidade deste exemplo, consideramos apenas o ator proprietário. O proprietário interage com o produto de certo número de modos diferentes:

• Entra com uma senha para permitir todas as outras interações
• Consulta o estado de uma zona de segurança
• Consulta o estado de um sensor
• Aperta o botão de pânico numa emergência
• Ativa/desativa o sistema de segurança

Caso de uso pra outras interações do proprietário seriam desenvolvidos de modo semelhante.
Cada caso de uso fornece um cenário não-ambíguo de interação entre um ator e o software. Ele pode também ser usado para especificar requisitos de tempo ou outras restrições do cenário.
Casos de uso descrevem cenários que serão percebidos de modo diferentes por diferentes atores. Wyder sugere que o desdobramento da função de qualidade pode ser usado para desenvolver um valor ponderado de prioridade para cada caso de uso. Para conseguir isso, os casos de uso são avaliados do ponto de vista de todos os atores definidos para os sistemas. Um valor de prioridade é atribuído a cada caso de uso por cada um dos atores. Uma prioridade média é então calculada, indicando a importância perceptível de cada um dos casos de uso. Quando é usado um modelo de processo iterativo para a engenharia de software, as prioridades podem influenciar qual funcionalidade do sistema é entregue primeiro.

11.3 – Princípios de Analise

Durante as últimas duas décadas, um grande número de métodos de modelagem da análise foi desenvolvido. Identificaram problemas de análise e suas causas e desenvolveram notações de modelagem e conjuntos heurísticas para resolvê-los. Cada Método de análise tem um ponto de vista singular. No entanto, estão relacionados por um conjunto de princípios operacionais:

• O domínio de informa. de um problema precisa ser representado e entendido (examinando a função).
• As funções do software devem ser definidas.
• O comportamento do software precisa ser representado.
• Os modelos que mostram informa. função e comportamento, (que são relatados de forma compacta), devem ser particionados (reduzindo complexidade) para que revele detalhes em forma de camadas.
• O processo de análise deve ir da informação essencial até o detalhe da implementação (que são necessárias para acomodar restrições lógicas do processamento e as restrições físicas de outros elementos do sistema).

Outro conjunto de princípio diretivo para a engenharia de requisitos (Davis):

• Entenda o problema antes que comece a criar um modelo de análise (um software elegante que resolve o problema errado).
• Desenvolva protótipos que permitam ao usuário entender como a interação homem /máquina vai ocorrer (a qualidade do software é baseada na constatação da “amigabilidade” da interface).
• Registre a origem e a razão para cada requisito (estabelecer rastreabilidade até o cliente).
• Use múltiplas visões dos requisitos (reduzira a probabilidade de que algo seja omitido e aumenta a probabilidade que a inconsistência seja reconhecida).
• Ordene os requisitos (os requisitos a serem satisfeitos no primeiro incremento devem ser identificados).
• Elimine ambigüidades geradas pela linguagem natural (usando revisões técnicas formais).

O engenheiro que lavar a sério esses princípios desenvolverá softwares que fornecerão excelente base para o projeto.

11.3.1 - O domínio da informação

   As aplicações de software podem ser coletivamente chamadas de processamento de dados. O software construído para processar dados (aceitar entrada), transformá-los (tratar), de uma forma para outra (e produzir saída). Ex.: em sistema de folha de pagamento, ou software embutido de tempo real para controlar o fluxo de combustível para um motor de automóvel.
O software também processa eventos. Representam aspectos do controle do sistema, dados booleanos (é ligado ou desligado, verdadeiro ou falso, presente ou ausente).
O domínio de informação de um problema abrange itens ou objetos de dados que contém números, texto, imagens, áudio, vídeo ou qualquer combinação disso.
No domínio de informação há três visões de dados e controles à medida que cada um é processado:

• Conteúdo da informação – objetos individuais de dados e controle que constituem alguma coleção de informação transformada pelo software. Ex.: Cheque de pagamento (nome de quem vai receber, a quantidade líquida a ser paga, a quantidade bruta, as deduções – atributos necessários para criá-lo). Objetos de dados e controle podem ser relacionados a outros (cheque de pagamento tem uma ou mais relações com os objetos cartão de ponto, emprego, banco e outros). Relações definidas, durante a analise do domínio de informação.
• O fluxo da informação – modo pelo qual dados e controle (que definem a interface de cada função) se modificam através de um sistema. Objetos de entrada são trans formados em informação intermediaria, que são transformados em saída. Ao longo desta transformação (funções ou subfunções que um programa deve realizar), informação adicional pode ser introduzida a partir de um deposito de dados existentes. Ex.: arquivo de disco ou buffer de memória.
• Estrutura da informação – representa a organização interna dos vários itens de dados e controle. A estrutura de dados refere-se ao projeto ou à implementação da estrutura da informação no software.

11.3.2 – Modelagem

   Criamos modelos funcionais para maior entendimento da entidade real a ser construída: - quando é física (edifício, avião, maquina), construímos um modelo idêntico, mas menor em escala; - quando é software, o modelo deve assumir uma forma diferente, ser capaz de representar a informação, que o software transforma, as funções (e subfunções), que permitem a transformação, e o comportamento do sistema, à medida que está sendo efetuada.
O segundo e o terceiro princípios operacionais de analise requerem que construamos modelos:

• Modelos funcionais – os software transforma a informação através de 3 funções genéricas: entrada, processamento e saída. Estes quando são criados, os engenheiros de software focaliza funções especificas do problema. Começa com modelo de contexto (nome do software). Durante interações, mais detalhes são fornecidos até que toda funcionalidade do sistema é representada.
• Modelos de comportamento – a maioria do software responde a eventos do mundo externo (estimulo / resposta), essa característica forma a base do modelo comportamental observável (esperando, calculando, imprimindo, consultando), que só serão modificados se ocorrer algum evento (movimento do mouse). Este modelo cria uma representação dos estados e dos eventos que causarão a mudança.

Papeis importantes de modelos criados durante a análise de requisitos:

• Ajuda o analista no entendimento da informação, função e comportamento de um sistema.
• Torna-se focal para revisões que determinará a completeza, consistência e precisão das especificações.
• E base para o projeto, dando uma representação essencial do software que pode ser “mapeada” para a implementação.

Apesar a modelagem ser freqüentemente assunto de preferência pessoal, e atividade fundamental par um bom trabalho de análise.

11.3.3 – Particionamento

   Problemas são grandes e complexos para serem entendidos como um todo. Por isso particionamos (dividimos) em seguimentos facilmente entendidos e estabelecem interfaces de modo que a função global possa ser compreendida. O quarto princípio operacional de analise sugere que o domínio de software informacional, funcional e comportamental podem ser particionados.
Estabelecemos uma representação hierárquica da função ou da informação e depois particionamos o elemento de cima: - expondo detalhes, movendo-nos verticalmente, ou – decompondo funcionalmente o problema, movendo-nos horizontalmente.

 

                    
À medida que o problema é particionado, as interfaces entre as funções são derivadas. Itens que se movem através da interface, devem se restringir às entradas necessárias para realizar a função declarada e às saídas que são necessárias a outras funções ou elementos do sistema.
É um processo que resulta no detalhamento de dados, funções e comportamento.

11.3.4 – Visões essencial e de implementação

   Uma visão essencial dos requisitos apresenta as funções a serem realizadas e informação a ser processada, sem cuidar dos detalhes de implementação.Por exemplo, ler o estado de sensor, do SafeHome não se preocupa com o mecanismo de entrada (estrutura física).
A visão de implementação dos requisitos apresenta a manifestação real de funções de processamento e informação. Em alguns casos é desenvolvida como primeiro passo do projeto do software. O analista deve reconhecer as restrições imposta por elementos predefinidos do sistema e considerar a visão de implementação da função e da informação, quando for apropriada.
A engenharia de requisitos deve focalizar o que o software deve realizar, e não como processo vai ser implementado. Pois ela representa o modo atual de operação, é a locação existente ou proposta para todos os elementos do sistema. O modelo essencial (de função ou dados) é genérico no sentido de que a realização da função não é indicada explicitamente.

PROTOTIPAGEM DE SOFTWARE

A análise deve ser conduzida independentemente do paradigma de engenharia de software que é aplicado. No entanto, a forma que a análise assume varia. Em alguns casos é possível aplicar princípios operacionais de analise e derivar um modelo do software a partir do qual o projeto pode ser desenvolvido.

• Seleção da abordagem de prototipagem

 

O paradigma de prototipagem pode ser de finalidade aberta ou de finalidade fechada. A abordagem de finalidade fechada é freqüentemente chamado de prototipagem para jogar fora. Usando essa abordagem, um protótipo serve apenas como uma demonstração rústica dos requisitos. Uma abordagem de finalidade aberta, chamada prototipagem evolutiva. Usa o protótipo como primeira parte de uma atividade de analise que vai ter continuidade no projeto e construção. O protótipo do sofware é a primeira evolução do sistema acabado.

Antes que uma abordagem de finalidade fechada ou de finalidade aberta possa ser escolhida, é necessário determinar se o sistema a ser construído é adequado à prototipagem

• Métodos e ferramentas de prototipagem

Para realizar a prototipagem rápida, três classes genéricas de métodos e ferramentas estão disponíveis:

Técnicas de quarta geração. Incluem um amplo conjunto de linguagens de relatório e de consulta a base de dados, geradores de programa e aplicações, e outras linguagens não procedimentais de muito alto nível. Como   permitem ao engenheiro de software gerar código executável rapidamente, elas são ideais para a prototipagem rápida.

• ESPECIFICAÇÃO

 

Não há dúvida de que o modo de especificação tem muito a ver com a qualidade da solução. Engenheiros de software que tenham sido focados a trabalhar com especificações incompletas, inconsistentes ou confusas experimentaram a frustração e a confusão, que invariavelmente resulta. A qualidade, pontualidade completeza do software sofre como conseqüência.

• Princípios de especificação

 

A especificação, independentemente do modo pelo qual nos a realizamos, pode ser vista como um processo de representação. Requisitos são representados de uma forma que, em última analise, leva à implementação bem-sucedida do software. Alguns princípios de especificação, adaptados do trabalho de Baizer e Goodman , podem ser propostos:
1. Separe a funcionalidade da implementação.
2. Desenvolva um modelo do comportamento desejado do sistema que abranja os dados e as respostas funcionais a vários estímulos do ambiente.
3. Estabeleça o contexto no qual o software opera, especificando o modo pelo qual outros componentes do sistema interagem com o software.
4. Defina o ambiente no qual o sistema opera e indique como “uma coleção altamente entrelaçada de agentes reage a estímulos do ambiente (modificações em objetos)” produzidas por esses agentes.

 

•  Representação

Já vimos que requisitos de software podem ser especificados de diferentes modos.
O formato da representação e do conteúdo deve ser relevante para o problema. Um esboço geral do conteúdo de uma Especificação de requisitos de software pode ser desenvolvido.
A informação contida na especificação dever ser aninhada. As representações devem revelar camadas de informações de modo que um leitor possa ir para o nível de detalhes desejado. Os esquemas de numeração de parágrafos e diagramas devem indicar o nível de detalhes que está sendo apresentado.
Diagramas e outras formas de notação devem ser restritos em quantidade e consistentes no uso. Notação confusa ou inconsistente, quer seja gráfica ou simbólica, degrada o entendimento e conduz a erros.
As representações devem poder ser revisadas. O conteúdo de uma especificação vai sofrer modificações.
As representações devem poder ser revisadas. O conteúdo de uma especificação vai sofrer modificações.

•  A especificação de requisitos do software

A especificação de requisitos de software é produzida no auge da tarefa de análise. A função e o desempenho alocados ao software como parte de engenharia de sistemas são refinados pelo estabelecimento de uma descrição completa da informação, de uma descrição funcional detalhada, de uma representação do comportamento do sistema, de uma indicação dos requisitos e de outra informação pertinente aos requisitos.
A descrição da informação fornece uma descrição detalhada do problema que o software deve resolver. O conteúdo, fluxo e estrutura da informação são documentados. O hardware, sotware e interfaces humanas são descritos para elementos externos dos sistema e funções internas do software.
Uma descrição de cada função necessária para resolver o problema é apresentada na descrição funcional. Uma narrativa de processamento é fornecida para cada função, restrições de projetos são declaradas e justificadas, características de desempenho são declaradas e um ou mais diagramas são incluídos para representar graficamente a estrutura geral do software e a interação entre as funções do software e outros elementos do sistema. A seção da especificação descrição comportamental examina a operação do software como conseqüência de eventos externos e características de controle gerados internamente.
Critérios de validação é provavelmente a seção mais importante e ironicamente e com freqüência a mais negligenciada da especificação de requisitos do software. Como reconhecemos uma implementação bem-sucedida? Que classes de testes devem ser conduzidas para validar a função. O desempenho e as restrições? Que classes de testes devem ser conduzidas para validar a função, o desempenho e as restrições? Nós negligenciamos essa seção porque completa-la demanda um profundo entendimento dos requisitos de software – algo que freqüentemente não lemos nesse estágio. No entanto, a especificação dos critérios de validação age como uma revisão implícita de todos os outros requisitos. É essencial que o tempo e atenção sejam dedicados a essa seção.
Finalmente, a especificação inclui uma bibliografia e apêndice. A bibliografia contem referencias a todos os documentos que se relacionam ao software. Eles incluem outra documentação de engenharia de software, referencias técnicas, literatura de fornecedores e padrões. O apêndice contém informação que suplementa as especificações. Tabelas de dados, descrição detalhada de algoritmos, figuras gráficos e outros materiais são apresentados no apêndice.

• REVISÃO DA ESPECIFICAÇÃO

Uma revisão da especificação de requisitos do software é conduzido tanto pelo desenvolvedor do software quanto pelo cliente.
A revisão é conduzida primeiro macroscopicamente; isto é, os revisores tentam garantir que a especificação esteja completa, consistente e precisa quando os domínios globais informacional, funcional e comportamental são considerados.
Uma vez completada a revisão, a especificação de requisitos de software é “assinada”, tanto pelo cliente quanto pelo desenvolvedor. A especificação torna-se um “contrato” para o desenvolvimento do software. Solicitações de modificações nos requisitos, depois que a especificação é completada, não serão eliminadas. Mas o cliente deve perceber que cada modificação posterior é uma extensão do escopo do software e conseqüentemente pode aumentar o custo e/ou comprometer o cronograma.

• RESUMO

 

A analise de requisitos é o primeiro passo técnico do processo do software. É nesse ponto que uma declaração geral do escopo do software é refinada para constituir uma especificação completa que se torna a base de todas as atividades engenharia de software que se seguem
A analise deve focalizar os domínios informacional funcional e comportamental de um problema.
Em muitos casos, não é possível especificar completamente um problema num estagio inicial. A prototipagem oferece uma abordagem alternativa que resulta num modelo executável do software a partir do qual os requisitos podem ser refinados.
A especificação de requisitos do software é desenvolvida como conseqüência da analise. 

 

Capítulo 12 - Modelagem de Análise

O modelo de analise é a primeira representação técnica do sistema. Muitos métodos foram propostos para modelagem de analise, dois dominam atualmente: Analise Estruturada é o método clássico de modelagem e a Analise Orientada a Objeto.
A analise estruturada é uma atividade de construção de modelo, não é o único método aplicado consistentemente por todos que o usam.
A Modelagem da Analise usa uma combinação de formas textuais e diagramáticas para mostrar os requisitos de dados, função e comportamento de modo que seja relativamente fácil de entender e mais direto de revisar quanto à correção, completeza e consistência.

O primeiro aparecimento da abordagem de analise estruturada foi “Projeto Estruturado”
Em todas as instancias o método focalizou aplicações de sistemas de informação e não forneciam notação adequada para cuidar dos aspectos de controle e comportamentos de problemas de Engenharia em tempo real.
Na metade dos anos 80 “Extensões” para tempo real foram introduzidas, essas extensões resultaram num método de analise mais robusto que podia ser aplicado efetivamente a problemas de Engenharia.

O modelo de analise deve atingir três objetivos principais:
1. Descrever o que o cliente exige;
2. Estabelecer a base para criação de um projeto de software;
3. Definir um conjunto de requisitos que possam ser validados quando o  software for construído.
No núcleo do modelo fica o dicionário de dados que é um repositório que contém descrições de todos os objetos de dados consumidos ou produzidos pelo software. O diagrama entidade-relacionamento (ERD) mostra as relações entre os objetos de dados. O ERD é a notação usada para conduzir a atividade de modelagem de dados.
O diagrama de fluxo de dados (DFD) serve a duas finalidades:
1. Fornecer indicação de como os dados são transformados a medida que se move através do sistema;
2. Mostrar as funções (e subfunções) que transformam o fluxo de dados.
O DFD fornece informação adicional que é usada durante a analise do domínio de informação e serve como base para modelagem de funções.
O diagrama de transição de estados (STD) indica como o sistema se comporta em conseqüência de eventos externos. Serve de base para modelagem comportamental

A modelagem de dados responde a um conjunto de questões especificas que são relevantes para qualquer aplicação de processamento de dados. Os métodos de modelagem de dados fazem uso do ERD, o qual define todos os dados que são introduzidos, armazenados, transformados e produzidos em uma aplicação. O ERD focaliza apenas os dados representando uma “Rede de Dados” que existe para um determinado sistema; diferentemente do DFD a modelagem de dados considera os dados independentemente do processamento que os transforma.
Objeto de Dados>> a um objeto de dados é uma representação de quase toda a informação composta que deve ser compreendida pelo software. Um objeto de dados pode ser uma entidade externa, uma coisa, uma ocorrência ou um evento, um papel, uma unidade organizacional, um lugar ou uma estrutura.
Os relacionamentos são sempre definidos pelo contexto do problema que esta sendo analisado.
Um objeto de dados encapsula apenas dados, ele pode ser representado por uma tabela.
Atributos>> à Além disso, uma ou mais dos atributos podem ser definidos como identificador, isto é, o atributo identificador torna-se uma “chave” quando deseja se encontrar um exemplo de objeto de dados.
O conjunto de atributos que é adequado para um determinado objeto de dados é determinado entendendo-se o contexto do problema.
Relacionamentos>> à Objeto de dados são conectados uns aos outros de diferentes modos. Podemos definir um conjunto de par objeto/relacionamento que define os relacionamentos relevantes. É importante notar os pares objeto/relacionamento são bidirecionais.
Os elementos da modelagem de dados, objeto de dados, atributos e relacionamentos, fornecem a base para o entendimento do domínio de informações de um problema.
Cardinalidade>> a O modelo de dados deve ser capaz de representar o numero de ocorrências dos objetos numa dada relação. Define o numero máximo de objetos que podem participar de um relacionamento.
Modalidade>> a modalidade de uma relação é 0 se não há necessidade explicita de um relacionamento ocorrer ou se este for opcional. A modalidade é 1 se o relacionamento for obrigatório.
O par objeto/relacionamento é pedra fundamental do modelo de dados. A finalidade principal do ERD é representar objetos de dados dos seus relacionamentos.
Objetos de dados são representados por um retângulo rotulado. Relacionamentos são indicados por um linha rotulada conectando objetos.
Alem da notação básica do ERD o analista pode representar hierarquias de tipo de objetos de dados, que pode representar uma classe ou categoria de informação. Também fornece um mecanismo que representa a associatividade entre objetos.
Modelagem de dados e o diagrama entidade-relacionamento fornecem ao analista uma notação concisa para examinar os dados no contexto de uma aplicação de software.

A informação é transformada a medida que flui através de um sistema baseado em computador, o qual aceita entrada de diversas formas, a saída pode acender um único LED ou produzir um relatório de 200 paginas.
A analise estruturada começou como uma técnica de modelagem do fluxo de informação. Um retângulo é usado para representar uma entidade externa, um círculo representa um processo ou transformação que aplicado aos dados e os modifica de algum modo, uma seta representa um ou mais itens de dados, a linha dupla representa um deposito de dados. É importante não confundir DFD com fluxograma.

DFD é uma representação gráfica que mostra o fluxo da informação e as transformações que são aplicadas à medida que os dados se movem para a saída. Ver figura 12.10
Pode ser usado para representar um sistema, ou SW e qualquer nível de abstração. O DFD pode ser particionado em níveis que mostram mais detalhes de fluxo de informações e funcionais.
O DFD 0, modelo funcional ou modelo de contexto, representa todo O SW como uma única bolha com dados de E/S indicados por setas.
Apesar da continuidade do fluxo da informação precisar ser mantida, reconheça que o item de dados representa em um nível pode ser refinado nas suas partes constituintes no nível seguinte.
A notação gráfica do DFD pode ser ampliada por uma especificação de processo (PSPEC), para especificar os detalhes de processamento implícitos numa bolha de um DFD.

Um sistema de tempo real deve interagir com o mundo real numa base de tempo ditada pelo mundo real. Essas extensões, desenvolvidas por Ward e Mellor[WAR85], permite representar fluxo de controle e processamento de controle bem como fluxo e processamento de dados.

       Servem para acomodar demandas impostas por um sist. De tempo real:

• O fluxo de informações é coletado ou produzido em uma base continua no tempo
• Informação de controle é passada através do sist. e do processamento de controle associado.

 

A distinção entre fluxo de dados discretos e contínuos no tempo tem implicações importantes tanto para o engenheiro de sistemas qto para o projetista de SW.
O fluxo de controle é representado usando uma seta tracejada ou sombreada, juntamente com o processo de controle onde se usa uma bolha tracejada.

Sugerem que a notação tracejada e a sólida sejam representadas separadamente. Assim, um diagrama de fluxo de controle é definido. O DFC contém os mesmo processos que o DFD, mas mostra fluxo de controle, ao invés de dados. Em vez de representar processos de controle diretamente no modelo de fluxo, um a referência notacional( uma barra sólida) para uma especificação de controle é usada.
Uma condição de dados ocorre sempre que entrada de dados em um processo resulta em saída de controle.

É um princípio operacional para todos os métodos de análise de requisitos.
O diagrama de transição de estados representa o comportamento de um sistema mostrando seus estados e os eventos que causam mudança de estado. O estado é qualquer modo de comportamento observável.

       O Mecanismo da Análise permite um revisor examinar os requisitos de SW sob 3 diferentes pontos de vista. Assim certifique-se de usar DER, DFD e STD qdo construir o modelo.
12.6.1 – Criação de um diagrama entidade/relacionamento (DER)
O DER permite ao engenheiro de SW especificar completamente os objetos de dados que são saídas e entradas de um sistema, os atributos que definem as propriedades desses objetos e suas relações.
A seguinte abordagem é adotada
1.    Os clientes são abordados para listar as “coisas” com o processo de negócio
2.    Tomando os objetos, o analista e o cliente define se existe ou não conexão
3.    Se existe conexão cria-se um ou mais pares de objeto/relacionamento
4.    Para cada par objeto/relacionamento, são exploradas cardinalidade e modalidade.
5.    Os passo 2 e 4 são continuados até que tenham sido defeinidos.
6.    Os atributos de cada entidade são definidos
7.    Um DER é formalizado e revisto
8.    Os passo de 1 a 7 são repetidos até que a modelagem de dados seja completada.

Algumas diretrizes simples podem ajudar imensamente durante a derivação do diagrama de fluxo de dados: (1) o diagrama de fluxo de dados de nível 0 deve mostrar o software-sistema como uma única bolha; (2) a entrada e a saída principal devem ser cuidadosamente registradas; (3) o refinamento deve começar pelo dos processos, objetos de dados e depósitos de dados candidatos a serem representados no nível seguinte; (4) todas as bolhas devem ser rotuladas com nomes significativos; (5) a continuidade do fluxo de informação deve ser mantida de nível p. nível; (6) uma bolha de cada vez deva ser refinada;
Todos os verbos são representados como bolhas em um DFD subseqüente. Todos os substantivos ou são entidades externas (caixas), ou objetos de dados ou de controle()setas ou depósito de dados (linhas duplas.). Deve-se notar que a continuidade de fluxo de  informação é mantida entre os níveis 0 e !.Os processos representados no DFD de nível 1 podem ser refinados em níveis inferiores. O refinamento dos DFD continua até que cada bolha realiza uma simples função.

Uma grande classe de aplicações é conduzida por eventos ao invés de dados; produzem informação de controle, em vez de relatórios ou imagens, e processam informação com grande preocupação de tempo e desempenho. Tais aplicações requerem o uso de modelagem de fluxo de controle, além da modelagem de fluxo de dados.
Para selecionar potenciais candidatos a eventos, as seguintes diretrizes são sugeridas:
- Liste todos os sensores que são lidos pelo software;
- Liste todas as condições de interrupção;
- Liste todas as condições de dados;
- Reveja todos os itens de controle como possíveis entradas/saídas da CSPEC;
- Descreva o comportamento do sistema pela identificação de seus estados;
- Enfoque possíveis omissões- um erro muito comum na especificação de controle;

Representa o comportamento do sistema de dois modos diferentes. A CSPEC contem um diagrame de transição de estados, que é uma especificação de comportamento seqüencial. Ela pode também conter uma tabela de avaliação de programa – especificação de comportamento combinatória. Um modo de representação de comportamento um tanto diferente é a tabela de ativação de processos. A PAT representa a informação contida no STD, no contexto de processos, não de estados. Isto é, a tabela indica que processos(bolhas) no modelo de fluxo serão invocados quando um evento ocorrer. Na PAT pode ser usada como diretrizes por um projetista que precisa construir um executivo que controla os processos representados nesse nível.  A CSPEC descreve o comportamento do sistema, mas não nos da informação sobre o trabalho interno dos processos qua são ativados como resultado desse comportamento.

É usada para descrever todos os processos de modo de fluxo que aparecem no nível de ferramenta final. O conteúdo da especificação de processo pode incluir texto narrativo, uma descrição em linguagem de projeto de programa do algoritmo do processo, equações matemáticas, tabelas, diagramas ou gráficos. Fornecendo uma PSPEC para acompanhar cada bolha do modelo de fluxo, o engenheiro de software cria uma mini-especificação que pode servir como primeiro passo para criação da especificação de requisitos do software e como diretriz para o projeto de componente de software que vai implementar o processo.

O dicionário de dados tem sido proposto com uma gramática quase formal para descrever o conteúdo dos objetos definidos durante a análise estruturada.
O dicionário de dados é uma listagem organizada de todos os elementos de dados que são pertinentes ao sistema, com definições precisas e rigorosas, de modo que tanto o usuário  quanto o analista de sistemas tenham um entendimento comum das entradas, saídas, componentes de depósitos e cálculos intermediários. É sempre implementado como uma parte de uma ferramenta de análise e projeto estruturado case.
Formato dos dicionários:
- Nome- o nome principal do item de dados ou controle;
- Sinônimo- outros nomes usados alternativamente;
- Onde usado / como usado- uma listagem dos processos que usam o item de dados ou controle como ele é usado;
- Descrição de conteúdo- notação para representar conteúdo;
- Informação suplementas- outra informação sobre tipo de dados;
A notação permite a um engenheiro de software representar dados de compostos em um dos três modos fundamentais em que eles podem ser construídos:
- Como uma seqüência de itens e dados;
- Como uma seleção entre elementos de um conjunto de itens de dados;
- Como um grupamento repetido de itens de dados;
A descrição de conteúdo é expandida até que todos os itens de dados compostos tenham sido representados como itens elementares, ou até que todos os itens compostos estejam representados em termos que seriam bem entendidos e não ambíguos para todos os leitores. Para sistemas baseados em computador de grande porte, o dicionário de dados cresce rapidamente em tamanho e complexidade. Por isso deve-se usar ferramentas case.

 

Fonte do documento:http://www.oocities.org/br/lukasbcr/esw_cap01.doc

http://www.oocities.org/br/lukasbcr/Cap11_ESW.doc

http://www.oocities.org/br/lukasbcr/Cap12_ESW_Completo.doc

 

Site para visitar: http://www.oocities.org/br/lukasbcr

Autor do texto: não especificado no documento de origem ou indicadas no texto

Google Palavras-chave: Resumo Engenharia de Software Tipo de Arquivo: doc

Se você é o autor do texto acima e concorda em não partilhar o seu conhecimento para o ensino, pesquisa, bolsas de estudo (para uso justo, como mostrado acima, nos Estados Unidos copyrigh baixa "for fair use as indicated in the United States copyrigh low"), envie um e-mail conosco e nós vamos remover o texto rapidamente.

 

Resumo Engenharia de Software

 

Se você quer encontrar rapidamente as páginas relacionadas a um tópico específico, como xx usando o seguinte motor de busca:

 

 

 

 

Visite a página principal

 

 

 

 

Resumo Engenharia de Software

 

 

Por favor, visite índice inicial de todos os temas, graças

 

Termos de uso ea política de privacidade e condições de utilização