engenharia de requisitos 2010 autora :professora carmen lucia asp de queiroz

Engenharia de Requisitos

2010

Autora :Professora Carmen Lucia Asp de Queiroz

Esta apostila foi desenvolvida para ajudar na aprendizagem e desenvolvimento dos alunos na disciplina de Engenharia de Requisitos da UniverCidade. Seu conteúdo é uma pesquisa de vários autores, sendo em grande parte, transcrições dos mesmos. Ao final de cada aula será apresentada a bibliografia utilizada.

Esta apostila tem como objetivo ser uma primeira leitura para os alunos, propiciando subsídios para que possam se aprofundar nos temas tratados.

Objetivos da disciplina:

• Apresentar ao aluno o desenvolvimento de software como uma metodologia.

• Desenvolver a capacidade de o aluno realizar de forma correta e satisfatória o levantamento de requisitos de um sistema computacional.

No intuito de ser didática, esta apostila está estruturada da seguinte forma:

Tópico 1 - Visão Geral da Engenharia de SoftwareTópico 2 - Processos de Desenvolvimento de SoftwareTópico 3 - Paradigmas de Desenvolvimento de SoftwareTópico 4 - Análise e Especificação de Requisitos Obs: Cada tópico acima será ministrado em 1 encontro (4 tempos de aula), com exceção do tópico 4, cujo conteúdo será diluído pelo restante do curso, principalmente, através de exercícios de levantamento de requisitos.

· Sistemas Computacionais

o Definição e conceitos básicos

o Evolução do desenvolvimento

· Natureza do produto “software”

· Definição de Engenharia de Software

Tópico 1 - Visão Geral da Engenharia de Software

VISÃO GERAL DA ENGENHARIA DE SOFTWARE

Uma empresa de software de sucesso é aquela que consistentemente produz software de qualidade que vai ao encontro das necessidades dos seus clientes. Uma empresa que consegue desenvolver tal software, de forma previsível, cumprindo os prazos, com uma gestão de recursos, quer humanos quer materiais, eficiente e eficaz, é uma empresa que tem um negócio sustentável.

Booch, Rumbaugh e Jacobson


Sistema

Um sistema é um grupo de componentes inter-relacionados que trabalham rumo a uma meta comum, recebendo insumos e produzindo resultados em um processo organizado de transformação.

Componentes de um Sistema

Entrada Processamento Saída

Feedback e Controle

Propriedades e comportamento dos componentes estão intrinsecamente interligados

Exemplo: o software só operará se o processador estiver operacionalO processador poderá realizar computações apenas se o sistema desoftware, que define essas computações, tiver sido instalado com sucesso.


Sistema de Informação Computadorizado, ou simplesmente, Sistema de Informação

“...Pode ser definido como o processo de transformação de dados em informações que são utilizadas na estrutura decisória da empresa e que proporcionam a sustentação administrativa visando à otimização dos resultados esperados” (Rezende, 2002) .


Informação: é todo o dado trabalhado, útil, tratado, com o valor significativo atribuído ou agregado e com um sentido natural e lógico para quem o usa.

Dado: é compreendido como um elemento da informação, um conjunto de letras, números ou dígitos, que tomado isoladamente não transmite nenhum conhecimento

Sistema de Informação Computadorizado, ou simplesmente, Sistema de Informação (continuação)


Sistema de Informação Computadorizado, ou simplesmente, Sistema de Informação (continuação)

Características:

• Grande volume de dados e informações;

• Complexidade de processamento;

• Muitos clientes e / ou usuários envolvidos;

• Contexto abrangente, mutável e dinâmico;

• Interligação de diversas técnicas e tecnologias;

• Suporte a tomada de decisões empresariais;

• Auxílio na qualidade, produtividade e competitividade organizacional.

O sistema de informação é um sistema sócio-técnico cujos componentes são indivíduos, tarefas e equipamentos necessários ao seu funcionamento

Implantar um sistema de informação em uma Organização equivale a nela intervir visando a uma mudança.



Componentes de um Sistema de Informática

• Pessoas

• Software

• Hardware

• Banco de dados

• Documentos de diversas naturezas

• Procedimentos manuais que se integram aos automatizados

Sistema

Hardware

Procedimentos

Documentos

Base de Dados Software

Pessoas

ENTRADAS

SAÍDAS


Software

É a parte programável de um sistema de informação. Ele é um elemento central: realiza estruturas complexas e flexíveis que trazem funções, utilidade e valor ao sistema.

O software pode ser:

Genérico – desenvolvido para ser vendido para uma gama de clientes diferentes.

Encomendado (personalizado) – desenvolvido para um único cliente, de acordo com a sua especificação.

Natureza do software é um produto intangível.


Atributos de um bom Software

O software deve entregar a funcionalidade e desempenho exigidos pelo usuário e deve ser manutenível, digno de confiança e utilizável.

Manutenibilidade - O software deve evoluir para alcançar necessidades de mudança;

Confiabilidade - O software deve ser confiável;

Eficiência - O software não deve desperdiçar recursos do sistema;

Usabilidade - O software deve ser usável pelos usuários para os quais ele foi projetado.


A importância dos softwares

• As economias de TODAS as nações desenvolvidas dependem de software;

• Mais e mais sistemas são controlados por software;

• O gasto com engenharia de software representa uma parte significativa do PIB em todos os países desenvolvidos;

• Os custos de software freqüentemente dominam os custos do sistema;

• Os custos de software são maiores para mantê-lo do que para desenvolvê-lo.


Exemplos de problemas causados por erros de softwares:

• Aeroporto Internacional de Denver. Erro no sistema de transporte automático de bagagens. Estima-se um prejuízo por volta dos 360 milhões de dólares com o erro. Para o conserto foram investidos 86 milhões de dólares.

• Ariane 5. É um Projeto da Agência Espacial Européia que levou 10 anos para ser concluído e custou 8 Bilhões de dólares. O foguete tem capacidade para 6 toneladas e prometia a supremacia européia no espaço. O primeiro vôo marcado para 4 de junho de 1996. Quarenta segundos após a decolagem houve a explosão (8 bilhões de investimentos foi junto). A carga do foguete estava avaliada em 500 milhões de dólares.

• Therac-25. É um equipamento de Radioterapia. Entre 1985 e 1987 se envolveu em 6 acidentes, causando mortes por overdoses de radiação. O software deste equipamento foi adaptado de um antecessor, Therac-6, que apresentou falhas por falta de testes integrados e falta de documentação.

Problemas dos Sistemas de Informática:

• Não fazem o que deveriam fazer;

• São caros;

• São entregues tarde demais;

• São de baixa qualidade (cheios de defeitos, difíceis de usar e lentos).


Origem dos problemas dos Sistemas de Informação

• Falta de treinamento das pessoas que operam;

• Processos de negócios inadequados;

• Deficiências da tecnologia;

• Falta de empenho dos órgãos de topo das organizações;

• Falta de comprometimento e empenho dos usuários;

• Incompreensão do valor dos sistemas de informação;

• Falta de entendimento entre o pessoal da Informática e os usuários;

• Deficiências no processo de desenvolvimento;

• Falhas na coordenação do projeto;

• Mudanças freqüentes dos requisitos do negócio.


Engenharia de Software


Arte(o homem transforma e domina a matéria)

Atendimento das necessidades humanas

(geração de valor através do tratamento da informação)

Conhecimentos científicos e empíricos

(parte do métodos provém da ciência e parte provém da experiência prática)

Habilitações específicas

(as pessoas envolvidas têm que ter habilitações

específicas)

Recursos naturais(são as máquinas utilizadas

para materializar as abstrações geradas pela ciência

da computação)

Formas adequadas

(utilidade)

Dispositivos e estruturas(devem ser reunidos para atender

às necessidades humanas)

Processos(baseia-se numa ação sistemática e não na

improvisação)


Conceito de Engenharia:

“Arte de aplicar conhecimentos científicos e empíricos e certas habilitações específicas à criação de estruturas, dispositivos e processos que são utilizados para converter recursos naturais em formas adequadas ao homem”, Aurélio.

Definição da Engenharia de Software

Uma das definições mais utilizada hoje em dia foi proposta pelo Institute of Electrical and Electronics Engineering (IEEE) em 1993, e defende que "a Engenharia de Software é a aplicação de um processo sistemático, disciplinado, e quantificado ao desenvolvimento, operação e manutenção de software; ou seja, a Engenharia de Software é a aplicação de técnicas de engenharia ao software".

A Engenharia de Software preocupa-se com as teorias, os métodos e as ferramentas para o desenvolvimento profissional de software.

Seu objetivo é o desenvolvimento e operação de um produto (software).


Desafios enfrentados pela Engenharia de Software

Lidar com sistemas legados, lidar com diversidade crescente e lidar com necessidades de tempos de entrega reduzidos.

Sistemas legados - Sistemas velhos e valiosos devem ser mantidos e atualizados;

Heterogeneidade - Os sistemas são distribuídos e incluem uma combinação de hardware e software;

Entrega - Há uma pressão crescente para entrega mais rápida do software.


Mitos e Realidades no Desenvolvimento de Software

MitoMinha equipe tem as ferramentas mais atuais de Engenharia de Software e os melhores computadores.

Realidade• Não basta!!!• Mesmo a melhor ferramenta não pode fazer um desenvolvedor medíocre se tornar um bom desenvolvedor.


Mitos e Realidades no Desenvolvimento de Software (continuação)

MitoO problema de atraso no cronograma pode ser resolvido aumentando a equipe.

Realidade• Não são todas as tarefas que podem ser divididas.• Novas pessoas precisam ser treinadas pelas pessoas que já estão no projeto.• Acrescentar mais pessoas a um projeto atrasado pode fazer com que ele se atrase ainda mais.



MitoTodos os programadores são iguais.Todos os programadores experientes têm as mesmas habilidades.

Realidade• Programadores com a mesma experiência podem ser bastante diferentes.



MitoO programa está 95% pronto.

Realidade• Programadores são extremamente otimistas.• Programadores costumam acreditar na própria capacidade de resolver problemas de forma imediata, mesmo na contínua evidência do contrário.



MitoPara iniciar a programação basta uma identificação geral dos objetivos. Os detalhes podem ser identificados depois.

Realidade• A falta de identificação adequada dos objetivos é a principal causa de fracasso de projetos.• A descrição detalhada dos requisitos de informação, funções, desempenho e interface, das restrições de projeto e dos critérios de validação é essencial e deve ser feita com o usuário/cliente.



MitoRequisitos mudam continuamente, mas mudanças no software podem ser feitas rapidamente porque o software é flexível.

Realidade• Requistos mudam continuamente, mas o impacto das mudanças varia de acordo com o momento em que estas ocorrem.



MitoEnquanto não se tem um programa “rodando” não é possível avaliar a sua qualidade.

Realidade• O software pode ser avaliado desde a sua concepção através de revisões que são mais efetivas do que testes.



MitoO único produto de um projeto de desenvolvimento de software é um programa funcionando.

Realidade• Um programa funcionando é apenas parte de uma configuração do software que inclui programa, documentação e dados.• A documentação é a base para um proheto bem sucedido e guia para a manutenção de software.


Ciência da Computação x Engenharia de Software

A Ciência da Computação preocupa-se com a teoria e os fundamentos.

A Engenharia de Software preocupa-se com a prática do desenvolvimento e entrega de software útil.

As teorias da ciência da computação são atualmente insuficientes para servir como base única para a engenharia de software.


Engenharia de Sistemas x Engenharia de Software

A engenharia de sistemas preocupa-se com todos os aspectos do desenvolvimento de sistemas baseados em computador, incluindo hardware, software e engenharia de processos. A engenharia de software faz parte desse processo.

Engenheiros de sistemas estão envolvidos na especificação, projeto arquitetural, integração e desenvolvimento de sistemas.


Engenharia de Software x Engenharia de Requisitos

• A Engenharia de Requisitos faz parte da Engenharia de Software.

• A engenharia de requisitos é a disciplina que procura sistematizar o processo de definição de requisitos. Aborda um ponto fundamental do desenvolvimento de software: a definição do que se produzir.

• A engenharia de requisitos tem sido identificada como uma fase crucial por tratar de conhecimentos não apenas técnicos, mas também gerenciais, organizacionais, econômicos e sociais, e estar intimamente associada a qualidade do software.

• As atividades da engenharia de requisitos vão desde a idéia de desenvolver um sistema de software até a modelagem conceitual do que se vai construir.


Atividades associadas à Engenharia de Software

• Concepção

• Implementação

• Manutenção

Ao longo de cada fase existem tarefas, subprodutos a desenvolver, pontos de verificação e intervenientes. Existe também um conjunto de atividades de suporte contínuas: gestão de projeto, controle de qualidade, gestão da configuração, elaboração de documentação, elaboração de estimativas, gestão do risco, entre outras.


Referências Bibliográficas

Booch, Grady; Rumbaugh, James; Jacobson, Ivar. UML – Guia do Usuário. Rio de Janeiro: Campus, 2000.

O´Brien, A. James. Sistemas de Informação e as Decisões Gerenciais na Era da Internet. São Paulo: Saraiva, 2004.

Paula Filho, Wilson de Pádua. Engenharia de Software – Fundamentos, Métodos e Padrões. Rio de Janeiro: LTC, 2003.

Ribeiro, Carlos Augusto. Apostila de Engenharia de Requisitos.

Rocco, Giovanni Ely. Engenharia de Requisitos. Universidade de Caxias do Sul - Centro de Ciências Exatas e Tecnologia - Departamento de Informática.

Rocha, Ana Regina. Apostila de Engenharia de Software – COPPE/UFRJ.

Silva, Alberto; Videira, Carlos. UML, Metodologias e Ferramentas CASE. Disponível em, <http://www.centroatl.pt/titulos/tecnologias/uml.php3>. Acesso em 31/01/2005.

Souza, Isabel Fernandes de. Apostila de Engenharia de Sistemas de Informação – Parte I.

Sommerville, Ian. Engenharia de Software. São Paulo: Pearson Education, 2003.


http://www.centroatl.pt/titulos/tecnologias/uml.php3

· Definição de processos de desenvolvimento de software

· Ciclos de vida de softwares e suas fases

o Ciclo de vida clássico

o Prototipação

o Modelo espiral

o Técnicas de 4ª geração

Tópico 2 - Processos de Desenvolvimento de Software

PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE

Processo - É um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações, usado para atingir uma meta. Esta meta geralmente está associada a um ou mais resultados concretos finais, que são os produtos da execução do processo.

Processo definido tem documentação detalhada:

• o que é feito (produto)• quando (passos)• por quem (agentes)• as coisas que usa (insumos)• as coisas que produz (resultados)


Um processo de desenvolvimento de software é o conjunto de atividades de engenharia necessárias para transformar os requisitos do usuário em software.

Processo de Desenvolvimento

de Software

Requisitos do

Usuário

Sistema novo

ou modificado


Modelo x Processo

Um modelo é algo teórico, um conjunto de possíveis ações.

O processo deve determinar ações práticas a serem realizadas pela equipe como prazos definidos e métricas para se avaliar como elas estão sendo realizadas.

Modelo + Planejamento = Processo


Modelos de Processo (Ciclos de Vida)

• Um ciclo de vida define um conjunto de atividades específicas;

• É conceituado a partir da percepção de uma necessidade;

• É desenvolvido de forma a se transformar em um conjunto de itens entregue a um cliente;

• Entra em operação, ou seja, é utilizado dentro de algum processo de negócio;

• É retirado de operação ao final da vida útil.


Etapas que compõem o desenvolvimento de sistemas:

• Determinação dos requisitos - Identificar as necessidades do cliente.

• Análise - Criar modelos conceituais associados ao negócio.

• Desenho - Criar uma visão detalhada do sistema considerando a tecnologia que será utilizada.

• Implementação - Construir o sistema com base nos modelos das fases anteriores.

• Testes – Avaliar a qualidade do sistema, verificando os requisitos e corrigindo os problemas encontrados.


Ciclo de vida do desenvolvimento de softwares:

• Codifica-remenda

• Cascata

• Espiral

• Prototipagem evolutiva

• Entrega evolutiva (Cascata e Prototipagem evolutiva)

•Dirigidos por prazo (time-boxed)

• Dirigidos por ferramentas


Ciclo de vida do desenvolvimento de softwares – Codifica-Remenda

• O ciclo de vida mais caótico é aquele que pode ser chamado de “codifica-remenda”;

• Parte apenas de uma especificação (ou nem isso);

• Os desenvolvedores começam imediatamente a codificar, remendando à medida que os erros vão sendo descobertos;

• Infelizmente, é provavelmente o ciclo de vida mais usado;

• É um modelo de alto risco, impossível de gerir e que não permite assumir compromissos confiáveis.


Ciclo de vida do desenvolvimento de softwares – Cascata

Os principais sub processos são executados em estrita seqüência, o que permite demarcá-los com pontos de controle bem definidos. A fase seguinte só pode iniciar quando a anterior tiver sido concluída e aprovada pelas partes envolvidas.

Desvantagem: O modelo em cascata puro é de baixa visibilidade para o cliente porque ele só recebe o resultado no final. Além disso, ele dificulta a realização de mudanças com o processo em andamento (requisitos sempre mudam). Portanto, é um modelo de alto risco, tanto para o cliente quanto para os desenvolvedores.

Requisitos

Análise

Desenho

Implementação

Testes


Ciclo de vida do desenvolvimento de softwares – Cascata (variante)

Para permitir que, em fases posteriores, haja revisão e alteração de resultados das fase anteriores. É uma visão mais realista do desenvolvimento de software.

Desvantagem: É difícil de ser gerenciado e, como o modelo cascata “puro”, é de baixa visibilidade para o cliente porque ele só recebe o resultado no final e é um modelo de alto risco, tanto para o cliente quanto para os desenvolvedores.

Requisitos

Análise

Desenho

Implementação

Testes


Prototipação

Protótipo de software é um sistema que...

– não tem tempo de vida definido;

– pode servir a múltiplos propósitos;

– deve ser construído rapidamente e com baixo custo;

– é parte integrante de um design centrado no usuário, para avaliação e modificação.

Avaliar protótipo

- Usuário -

Definir objetivose requisitos de informação

Construir/Revisarprotótipo

Prototipagem:

- Protótipos descartáveis;- Protótipos evolutivos – evolui para o produto final.

Inconvenientes:

O usuário passa a ver o protótipo como uma versão final;

Compromisso do desenvolvedor em gerar um protótipo em um curto espaço de tempo.


Ciclo de vida do desenvolvimento de softwares – Espiral

• o produto é desenvolvido em uma série de iterações;

• cada nova iteração corresponde a uma volta na espiral;

• permite construir produtos em prazos curtos, com novas características e recursos que são agregados à medida que a experiência descobre sua necessidade;

• as atividades de manutenção são usadas para identificar problemas; seus registros fornecem dados para definir os requisitos das próximas liberações;

Desvantagem: requer gestão sofisticada para ser previsível e confiável.


Avaliar alternativas,Identificar,

Resolver riscosDesenvolvimento,

verificar produto do próximo nível

Planejamento da próxima iteração

Determinar objetivos, alternativas e restrições

Ciclo de vida do desenvolvimento de softwares – Espiral (continuação)

Atividades do Modelo Espiral

Determinar objetivos, alternativas e restrições: são definidos os objetivos específicospara essa fase do projeto.

Avaliação e redução de riscos: para cada um dos risco do projeto identificado, é realizada uma análise detalhada e são tomadas providências para reduzir esses riscos.

Desenvolvimento e validação: depois da avaliação dos riscos, é escolhido o modelo de desenvolvimento para o sistema.

Planejamento da próxima iteração: o projeto é revisto e é tomada uma decisão sobre continuar com o próximo loop da espiral.:


Ciclo de vida do desenvolvimento de softwares – Espiral (continuação)

Modelo Espiral – Observações:

• é, atualmente, a abordagem mais realística para o desenvolvimento de software em grande escala;

• usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva;

• pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável;

• exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso;

Quando o modelo espiral é aplicado a um único projeto, tem-se o modelo de prototipagem evolutiva.



Ciclo de vida do desenvolvimento de softwares – Prototipagem evolutiva

A espiral é usada não para desenvolver o produto completo, mas para construir . Os protótipos cobrem cada vez mais requisitos, até que se atinja o produto desejado.

Desvantagem: Requer gestão muito sofisticada e equipe disciplinada e experiente.

Planejamentoda iteração

Requisitos Desenho

ImplementaçãoTestesAvaliaçãoda iteração

Projeto Terminado

Nova iteração

Análise


Ciclo de vida do desenvolvimento de softwares – Entrega evolutiva

Permite que, em pontos bem definidos, os usuários possam avaliar partes do produto e fornecer realimentação quanto às decisões tomadas.

Requisitos

DesenhoDetalhado

Implementação

TestesAvaliaçãoda iteração

Projeto Terminado

Nova iteração

Análise

DesenhoArquitetônico


Ciclo de vida do desenvolvimento de softwares – Entrega evolutiva

• O sistema é particionado em partes independentes que podem ser entregues à medida que forem ficando prontas e avaliadas;

• Permite que, em pontos bem definidos, os usuários possam avaliar partes do produto e fornecer realimentação quanto às decisões tomadas;

• Os incrementos funcionam como protótipos do sistema;

• Novos requisitos podem ser incorporados aos outros incrementos do sistema;

• Deve-se identificar funcionalidade prioritárias que serão desenvolvidas primeiro;

• Os processos de cada incremento podem ser independentes. Pode-se utilizar Cascata;

• Risco menor de fracasso completo do sistema;

• A funções entregues primeiro são testadas mais vezes, à medida que os incrementos são entregues.


Ciclo de vida do desenvolvimento de softwares – Dirigidos por prazo

O produto é o que se consegue fazer dentro de um determinado prazo, que normalmente, é estabelecido de forma política.

Desvantagem: O produto entregue é apenas parcial. O restante será entregue disfarçado de manutenção.


Ciclo de vida do desenvolvimento de softwares – Dirigidos por ferramenta

Algumas ferramentas podem impor processos rígidos, que podem ser adequados para tipos bem específicos de produtos. Essas ferramentas são conhecidas por ferramentas CASE (Computer Aided Software Engineering ).

Ferramentas CASE ajudam os desenvolvedores a aumentar sua produtividade ao construírem aplicativos de negócios, sistemas de software e dispositivos incorporados.

Exemplos: Posseidon (free), Rational Rose, System Architect, PowerDesigner, etc.


Recursos que podem ser encontrados numa ferramenta CASE:

• Ferramentas para arquitetura e modelagem de design;

• Ferramentas para geração de código completamente executável;

• Ferramentas para geração de scripts a partir de diagramas destinados à banco de dados;

• Ferramentas para testes de componente e atividades de análise de tempo de execução.


Ferramentas CASE - Recomendações

• Uma ferramenta CASE não é a solução para todos os problemas da organização;

• A organização deve ter certeza de estar pronta para a nova ferramenta.

Dessa forma, uma ferramenta só deveria ser selecionada após a definição do processo de desenvolvimento, dos métodos e de ter sido utilizada num projeto piloto.

Processos de desenvolvimento de software mais conhecidos:

• Personal Software Process (PSP)

• Team Software Process (TSP)

• Processo Unificado Racional (Rational Unified Process – RUP)

Processo de desenvolvimento para dar suporte a projetos didáticos:

• PRocesso para Aplicativos eXtensíveis InterativoS (Praxis)


Personal Software Process (PSP) ou Processo Pessoal de Software

Objetivos do PSP:

• Ajudar as pessoas a serem melhores engenheiros de software;

• Estabelecer um mecanismo para melhorar, no nível pessoal, a capacidade de planejamento, acompanhamento e qualidade dos resultados.

O PSP pode ser usado por pessoas em empresas que ainda estão no nível 1 do CMM (Capability Maturity Model). Alguns benefícios mútuos não aparecerão mas certamente a pessoa perceberá as melhorias no nível pessoal.


Estágios do PSP

Classificação

Processos pessoais básicos

Processos pessoais com planejamento

Processos pessoais com gestão da qualidade

Processos pessoais cíclicos

Nome

PSP0

PSP0.1

PSP1

PSP1.1

PSP2

PSP2.1

PSP3

Registro de tempos, Registro de defeitos, Padronização dos tipos de defeitos

Padronização da codificação, Medição do tamanho, Proposição de melhorias de processos

Estimativas de tamanho, Relatórios de testes

Planejamento de tarefas, Planejamento de cronogramas

Revisões de código, Revisões de desenho

Modelos de desenho

Desenvolvimento cíclico

Elementos novos de processo


Team Software Process (TSP) ou Processo de Software para Times

O TSP é um modelo para gerenciar equipes de desenvolvedores de software (compostas geralmente de mais de 20 pessoas) no desenvolvimento e na manutenção de projetos. Nele, são utilizados métodos de disciplina, oferecendo assim, condições para uma equipe definir e melhorar continuamente o processo de desenvolvimento de software.

Introductory Team Software Process - (TSPi)

Devido à sua complexidade, é bastante difícil aplicar o TSP em equipes com menos de 20 pessoas. Por esse motivo, Humphrey desenvolveu o TSPi que é baseado em 7 princípios.


Princípios do TSPi

1. Fornecer um framework simples, com base nos fundamentos do PSP (Personal Software Process);

2. Desenvolver produtos em vários ciclos;

3. Estabelecer medidas-padrão para qualidade de software;

4. Fornecer medidas precisas para equipes;

5. Utilizar avaliações de papéis e de equipe;

6. Fornecer disciplina nos processos;

7. Fornecer direção para soluções de problemas do trabalho em equipe.


O TSPi utiliza os seguintes conceitos do desenvolvimento de software:

• Roteiros: podem ser considerados um guia de execução de atividades;

• Formulários: para coleta e totalização dos dados;

• Padrões: três tipos de documentos padrões que auxiliam as equipes no desenvolvimento:

• Padrão de tipos de defeitos;

• Padrão para composição das anotações do projeto;

• Padrão de critérios de qualidade.


Rational Unified Process – RUP

• O RUP é um processo de desenvolvimento de software que utiliza a Unified Modeling Language - UML – como notação de uma série de modelos que compõem os principais resultados das atividades de uma metodologia.

• O RUP utiliza pequenos ciclos do projeto (mini-projetos), que correspondem a uma iteração e resultam em um incremento no software.



Embora o RUP sugira um processo, ele pode ser considerado como:

• uma abordagem de desenvolvimento de software que é iterativa, centrada na arquitetura e dirigida por casos de uso, ou seja, levantamento de requisitos baseados na visão do usuário;

• um processo de engenharia de software bem definido e bem estruturado. Ele claramente define quem é o responsável pelo que, como as coisas são feitas e quando fazê-las;

• um produto processo que fornece um framework de processo customizável para a engenharia de software. Essas customizações podem ser feitas para suportar pequenas equipes e abordagens disciplinadas ou menos formal para o desenvolvimento.



Desenvolvimento iterativo controlado é superior à abordagem tradicional em cascata por várias razões:

• Gerenciar a mudança de requisitos;

• Integração contínua;

• Redução dos riscos;

• Possibilidade de mudanças táticas;

• Facilita o reuso;

• Resulta numa arquitetura mais robusta;

• Aprendizado;

• Refinamento do processo.



Todos os componentes do processo, da captura dos requisitos aos testes, são dirigidos por casos de uso.



Os Casos de Uso definidos para um sistema são a base de todo o processo de desenvolvimento. Eles orientam o desenvolvimento:

• Na análise de requisitos os casos de uso são usados para capturar os Requisitos;

• No design devem ser identificadas as classes a partir dos casos de uso;

• Na implementação os casos de uso são implementados;

• Nos testes os casos de uso devem ser verificados. Os casos de uso tornam-se casos de teste.


RUP – Estruturação do processo


RUP - Fases do ciclo de vida do software

O processo tem quatro fases:

• Início (Inception): definição do escopo do projeto

• Elaboração (Elaboration): planejamento do projeto, especificação das características e design da arquitetura

• Construção (Construction): construção do produto

• Transição (Transition): colocar em ação (deployment) para a comunidade de usuários


RUP – Iterações do ciclo de vida do software

Uma iteração é um ciclo completo de desenvolvimento finalizando com uma versão (release) de um produto executável que é um pedaço incrementado no produto final em desenvolvimento.


RUP – Desenvolvimento iterativo


Praxis

• É desenhado para suportar projetos realizados individualmente ou por pequenas equipes, com duração de seis meses a um ano;

• Abrange tanto métodos técnicos (requisitos, análise, desenho, testes e implementação, etc) quanto métodos gerenciais (gestão de requisitos, gestão de projetos, garantia da qualidade, gestão de configurações, etc);

• Propõe um ciclo de vida composto por fases que produzem um conjunto precisamente definido de artefatos (documentos e modelos);

• Sua linguagem de modelagem é a UML;

• Reflete muitos elementos do Processo Unificado;

• Assim como o RUP, é um processo concreto, ou seja, contém um conjunto de padrões e gabaritos para serem aplicados.


Os processos essenciais a qualquer projeto estão representados no diagrama de rede (ou diagrama de precedência) abaixo:

Planejamento do Escopo do Produto

Definição do WBS

Definição dasAtividades

Seqüência dasAtividades

Planejamento dos Recursos

Estimativas eDurações

Estimativados Custos

Planejamento dos Riscos

Programação

Orçamentodos Riscos

Planejamento Global


Além dos processos da figura anterior, alguns projetos requerem também os processos auxiliares abaixo:

Planejamento da Qualidade

Planejamento da

Comunicação

Identificaçãodos Riscos

AnáliseQualitativa

AnáliseQuantitativa

Planos de Resposta ao

Risco

Planejamento Organizacional

Contratação de Pessoal

Planejamento de Aquisições

Preparação daDocumentação


Planejamento do Escopo do Projeto

A entrada para este processo é a descrição do produto que será produzido, ou do serviço a ser executado pelo projeto.

O escopo do produto não deve ser confundido com o escopo do projeto. O escopo do projeto define o conjunto de trabalhos que serão executados para construir e entregar o produto.

Como o escopo do projeto descreve as principais atividades a serem executadas, é a base para a elaboração do cronograma e do orçamento.

Algumas vezes é necessário especificar o que o produto não vai produzir, principalmente quando existe algo que as pessoas possam presumir como sendo parte implícita do produto.



Processos podem ser definidos para:

• Desenvolvimento de software

• Manutenção de software

• Aquisição de software

• Contratação de software

Para cada um desses processos, pode-se definir sub processos.

• O fogo está sob controle• Reação (e não agindo pró-ativamente)

– Não há tempo para melhoria

• Os “ bombeiros” se queimam• As cinzas podem voltar a se incendiar mais tarde• Sua única forma de controle - prevenção de incêndio

Embora existam várias ferramentas para ajudar as organizações a desenvolver software com qualidade, a maioria das organizações gasta suas energias “apagando incêndios”



Albuquerque, Antonio Roberto; Schiavo, Luciano. Uma visão de abordagem de desenvolvimento de software do Rational Unified Process. Disponível em <http://www.simpep.feb.unesp.br/Artigos%20Apresentados.htm>. Acesso em 01/02/2005.

Hazan, Claudia. Implantação de um processo de medições de software. Disponível em http://www.bfpug.com.br/Artigos/Palestra%20_Medicoes%20Claudia%20Hazan.pdf . Acesso em 03/02/2005.

Leite, Jair C. Processo de Desenvolvimento de Software. Disponível em <www.dimap.ufrn.br/~jair/ES/slides/Processo.pdf>. Acesso em 01/02/2005.

Martins, José Carlos Cordeiro. Gerenciando projetos de desenvolvimento de software com PMI, RUP e UML. Rio de Janeiro: Brasport, 2004.


Ribeiro, Carlos Augusto. Apostila de Engenharia de Requisitos.

Souza, Isabel Fernandes de. Apostila de Engenharia de Sistemas de Informação – Qualidade – Parte VIII.


<http://www.ibm.com/br/products/software/rational/des.phtml>. Acesso em 03/02/2005.

<http://www.esicenter.unisinos.br/index.php?pg=frm_rumocmmi25.php>. Acesso em 03/02/2005.

<www.dimap.ufrn.br/~jair/ES/slides/rup.pdf> . Acesso em 01/03/2005.


http://www.bfpug.com.br/Artigos/Palestra%20_Medicoes%20Claudia%20Hazan.pdf

http://www.ibm.com/br/products/software/rational/des.phtml

http://www.esicenter.unisinos.br/index.php?pg=frm_rumocmmi25.php

· Conceitos da Modelagem Estruturada

· Conceitos da Modelagem Essencial

· O Paradigma Orientado a Objetos

o Objetos e classes

o Relacionamentos entre objetos

o Abstração

o Polimorfismo, Herança e Encapsulamento

Tópico 3 - Paradigmas do Desenvolvimento de Software

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE

Considerações sobre a Modelagem

• A modelagem é um técnica de engenharia aprovada e bem-aceita;

• Um modelo é uma simplificação da realidade;

• Construímos modelos para compreender melhor o sistema que estamos desenvolvendo;

• Construímos modelos de sistemas complexos porque não é possível compreendê-los em sua totalidade;

• Um modelo é expresso através de uma linguagem (linguagem de modelagem).


A linguagem para a construção de modelos deve ter:

• Elementos do modelo - conceitos e semântica fundamentais ao modelo;

• Notação dos elementos - representação visual dos elementos do modelo;

• Guidelines - guias de como e onde usar a linguagem.


Objetivos alcançados com a Modelagem

• Os modelos ajudam a visualizar o sistema como ele é ou como desejamos que seja;

• Os modelos permitem especificar a estrutura ou o comportamento de um sistema;

• Os modelos permitem que as discussões sobre as modificações e correções nos requisitos do usuário sejam feitas com baixo custo e mínimo risco;

• Os modelos proporcionam um guia para a construção do sistema;

• Os modelos documentam as decisões tomadas.


Princípios da Modelagem

• A escolha dos modelos a serem criados tem profunda influência sobre a maneira como um determinado problema é atacado e como uma solução é definida;

• Cada modelo poderá ser expresso em diferentes níveis de precisão;

• Os melhores modelos estão relacionados à realidade;

• Nenhum modelo único é suficiente. Qualquer sistema não-trivial será melhor investigado por meio de um pequeno conjunto de modelos quase independentes.


Antes da Modelagem Estruturada - 1950~meados da década de 60

• Programar é uma arte;

• Pouco método formal – maioria: tentativa e erro;

• Descrição em textos (linguagem natural) e fluxograma.


Modelagem Estruturada - Meados da década de 60~meados da década de 70

Ambiente:

• Em 1969 – Criada a Disciplina de Engenharia de Software

Características da Análise Estruturada:

• Representação gráfica dos requerimentos dos sistemas;• Preocupação com os fluxos de dados;• Prega a separação entre modelo lógico e físico do sistema, mas não diz como fazê-la.


Modelagem Estruturada

Ferramentas estruturadas para análise:

• Alguma coisa que nos ajude a segmentar nossos requisitos e o documento em si, particionado antes da especificação – Diagrama de Fluxo de Dados (DFD).

• Algum meio para armazenar dados sobre os dados – Dicionário de Dados (DD).

• Novas ferramentas para a descrição da lógica e do programa de ação, alguma coisa melhor que narrativa de texto – Português estruturado, Tabelas de decisão e Árvores de decisão.


Modelagem Essencial - Meados da década 70~final da década de 80

Ambiente:

• Sistemas distribuídos;• “Inteligência” embutida;• Hardware de baixo custo;• Impacto no consumidor.

Características da Análise Essencial:

• Encontrar o Modelo Essencial do Sistema;• Abandono da modelagem do sistema atual;• Particionamento por Eventos;• Incorporação da Modelagem de Dados no processo de Especificação.

FASES DO PROJETO OBJETIVO ATIVIDADE

Descrever o comportamento desejado para o sistema

Descrever a organização da tecnologia automatizada que incorporará o

comportamento desejado

Incorporar o modelo de implementação ao hardware e software

Projeto Lógico

ProjetoTecnológico

Implementação

Elaborar o modelo essencial

Elaborar o modelode implementação

Construir o sistema

Princípios da Modelagem Essencial


SUBMODELO OBJETIVO FERRAMENTAS

Descrição do ambiente noqual o sistema opera

Descrição do comportamento em resposta a eventos em seu ambiente

Ambiental

Comportamental

• Descrição do propósito• Lista de eventos• Diagrama de contexto

• MER• DFD• DTE• Dicionário de Dados• Miniespecificação de processos

O Modelo Essencial


Tecnologia Perfeita

A tecnologia perfeita é útil pois facilita a identificação da essência do sistema. Com ela, um sistema teria um processador perfeito e um container perfeito.

Um processador perfeito seria capaz de fazer qualquer coisa instantaneamente, não custaria nada, não consumiria energia, não ocuparia espaço, não geraria calor, nunca cometeria um erro e nunca quebraria.

Um container perfeito teria muitas das mesmas virtudes e seria capaz de conter uma quantidade infinita de dados. Qualquer processador poderia alcançar adequadamente os seus dados.



O Paradigma da Orientação a Objetos - Final da década 80~até hoje

Ambiente:

• Sistemas desk-tops poderosos

• Software Free

• Inteligência Artificial

• Sistemas especialistas

• Redes neurais artificiais

• Data Mining

• Computação paralela


O Paradigma da Orientação a Objetos - Final da década 80~até hoje

Ambiente:

• Programação em pequenos devices

• Sistemas embarcados

• Processo de Desenvolvimento de Software

• Modelos de Qualidade de Software – CMM/ISO/SPICE

• Processo de Desenvolvimento de Software – RUP/EUP/PRAXIS

• Metodologia Orientada a Objetos

• Gerenciamento de Projetos

• Gerenciamento de Requisitos

• Gerenciamento de Versão e Configuração

• A orientação a objetos é um novo paradigma de

desenvolvimento de software que visa abordar o

mundo real como tal

• A filosofia básica é a visão do domínio do problema

como um conjunto de objetos, que possuem

características, comportamentos e comunicam-se

através de mensagens



Princípios da Orientação a Objetos:

1. Qualquer coisa é um objeto.

2. Os objetos realizam tarefas através da requisição de serviços a outros objetos.

3. Cada objeto pertence a uma determinada classe. Uma classe agrupa objetos similares.

4. A classe é um repositório para comportamento associado ao objeto.

5. Classes são organizadas em hierarquia.

O paradigma da orientação a objetos visualiza um sistema de software como uma coleção de agentes interconectados chamados objetos. Cada objeto é responsável por realizar tarefas específicas. É através da interação entre objetos que uma tarefa computacional é realizada.

• Objeto

• Conjunto de objetos semelhantes: Classe

Objeto Representação Gráfica do Objeto

Conjunto de Objeto Representação Gráfica dos Objetos = Classe

Animal

leão : Animal


Conjunto de Objetos

Representação Gráfica dos Objetos = Classe

Comportamento

Características

Animal

pesoalturacor

come()locomove()corre()



Mensagens

• Quando se diz na terminologia da orientação a objetos que objetos estão trocando mensagens significa que esses objetos estão enviando mensagens uns para os outros com o objetivo de realizar uma tarefa dentro do sistema no qual eles estão inseridos.

Objeto

Objeto

Objeto

Objeto

Objeto

• A comunicação entre os objetos é feita através de mensagens.

– Abstração de dados– Informação de controle

Ande

Representação Gráfica Mensagem

Mensagem

joão : Homem

coelho : Animal

1: ande( )



Princípios da orientação a objetos como aplicações do Princípio da Abstração

Orientação a Objetos

Encapsulamento Polimorfismo Herança

Abstração


Encapsulamento

• Objetos possuem comportamento (operações que o objeto pode realizar);

• O mecanismo de encapsulamento é uma forma de restringir o acesso ao comportamento interno de um objeto.

• O objeto requisitante precisa conhecer quais as tarefas que um outro objeto sabe fazer ou que informação ele conhece.

• Interface de um objeto – é o que ele conhece e o que ele sabe fazer, sem descrever como o objeto conhece ou faz. A interface de um objeto define os serviços que ele pode realizar e consequentemente as mensagens que ele recebe.

• Através do encapsulamento, a única coisa que um objeto precisa saber para pedir a colaboração a outro objeto é conhecer a sua interface


Polimorfismo - etimologicamente, quer dizer “várias formas“.

• O polimorfismo indica a capacidade de abstrair várias implementações diferentes de uma única interface. Ex: Controle remoto do DVD que serve também para a TV;

• A abstração também é aplicada no polimorfismo: um objeto pode enviar a mesma mensagem para objetos semelhantes, mas que implementam a sua interface de forma diferente;

• Na Informática, e em particular no universo da POO, é definido como sendo um código que possui "vários comportamentos" ou que produz “vários comportamentos“;

• De maneira prática isto quer dizer que a operação em questão mantém seu comportamento transparente para quaisquer tipos de argumentos; isto é, a mesma mensagem é enviada a objetos de classes distintas e eles poderão reagir de maneiras diferentes.


Herança

• As características e o comportamento comuns a um conjunto de objetos podem ser abstraídos em uma classe;

• Na herança, classes semelhantes são agrupadas em hierarquia;

• Cada classe em um nível da hierarquia herda as características das classes nos níveis acima.

Maiorabstração

Menorabstração

Figura

Figura Geométrica Linha

Quadrado Círculo


Estereótipos

• são extensões de elementos do modelo;• podem ser utilizados para denotar especializações significativas de classes;• podem ser indicados através de ícones próprios, ou incluindo-se o nome do estereótipo em aspas francesas (<< >>).

Divisão das classes do Modelo de Análise

Jacobson propõe a divisão das classes do Modelo de Análise de acordo com os seguintes estereótipos: entidades (entity), fronteiras (boundary) e controles (control).

<< boundary >>Tela de Venda

<< control >>Controlador de Venda

<< entity >>Venda


Classes de Entidades

• Modelam informação persistente, sendo tipicamente independente da aplicação;

• São candidatas mais fortes a serem reutilizadas;

• Geralmente são necessárias para cumprir alguma responsabilidade do produto;

• Frequentemente correspondem a entidades de banco de dados.

Classes de Fronteiras

• Tratam da comunicação com o ambiente do produto;

• Modelam as interfaces do produto com usuários e outros sistemas;

• Durante a análise de domínio considera-se que as classes de fronteira surgem de cada par ator-caso de uso.


Classes de Controles

• Coordenam o fluxo de um caso de uso complexo, encapsulando lógica que não se enquadra naturalmente nas responsabilidades das entidades;

• São tipicamente dependentes da aplicação;

• Um caso de uso muito simples pode ser coordenado por uma classe de fronteira;

• Por exemplo, pode-se definir classes de controle para coordenar um subfluxo ou um fluxo alternativo mais complexo, um algoritmo, a geração de um relatório ou uma regra de negócio complexa.


Classes Abstratas x Classes Concretas

• Na hierarquia de classes, é comum especificar que certas classes são abstratas – significando que não poderão apresentar instâncias diretas;

• Por contraste, uma classe concreta é aquela que pode ser instanciada;

• As classes abstratas são constituídas através da união de conceitos genéricos, que serão adequados ao domínio da aplicação através apenas de suas subclasses;

• Classes abstratas são as candidatas em potencial para a reutilização, já que são modeladas para este fim. Elas representam a melhor solução para reutilizar comportamentos não associados diretamente ao domínio da aplicação;

• Como as classes abstratas são mais complexas, elas devem justificar a sua existência. Devem ser definidas para servirem ao domínio público da organização, deixando flexível a implementação específica.

Unified Modeling Process (UML)

• É uma linguagem de modelagem visual para modelar sistemas orientados a objetos;

• Sua definição ainda está em desenvolvimento e possui diversos colaboradores da área comercial, como: Digital, HP, IBM, Oracle, Microsoft, Unisys, IntelliCorp, i-Logix e Rational;

• É independente tanto de linguagem de programação quanto de processos de desenvolvimento.


OMT + BOOCH = UML 0.8Grady BoochJames RumbaughOut 1995

OMT + BOOCH = UML 0.9 Iva JacobsonJun 1996

OMT + BOOCH = UML 1.0Microsoft, IBM, HP, outrasJan 1997

OMT + BOOCH = UML 1.1Set 1997

UML 1.2 UML 1.3 UML 1.4 UML 1.5 1997-2002

UML 2.012/junho/2003



Visões de um Sistema de Software

Visão de Casos de Uso

Visão de ProjetoVisão de Implementação

Visão de Processo Visão de Implantação


A UML sugere as seguintes visões para um sistema:

• Visão de Casos de Uso: descreve o sistema de um ponto de vista externo como um conjunto de interações entre o sistema e os agentes externos ao sistema. Esta visão é criada inicialmente e direciona o desenvolvimento das outras visões.

• Visão de Projeto: enfatiza as características do sistema que dão suporte tanto estrutural quanto comportamental, às funcionalidades externamente visíveis do sistema.

• Visão de Implementação: abrange o gerenciamento de versões do sistema, construídas através de agrupamento de módulos (componentes e subsistemas).

• Visão de Implantação: corresponde à distribuição física do sistema em seus subsistemas e à conexão entre essas partes.

• Visão de Processo: esta visão enfatiza as características de concorrência (paralelismo), sincronização e desenho do sistema.


Diagramas da UMLDiagramas

da UML

Diagramas de Casos de Uso

Diagramas de Classes

Diagramas De Objetos

Diagramas De Interação

Diagramas de Atividades

Diagramas de Implementação

Diagramas de Transições de Estado

Diagramas de Implantação

Diagramas de Componentes

Diagramas de Colaboração

Diagramas de Sequência


Visões de um Sistema de Software

Visão de Caso de Uso

Visão de ProjetoVisão de Implementação

Visão de Processo

Visão de Implantação

Diagramas de Caso de UsoDiagram. de Interação

Diagram. de Transição de EstadoDiagram. de Atividades

Diagram. de Classes Diagram. de ObjetosDiagram. de Interação

Diagram. Transição de EstadoDiagram. de Atividades

Diagram. de ComponentesDiagram. de Interação


Diagram. de ImplantaçãoDiagram. de Interação


Diagram. de Classes Diagram. de ObjetosDiagram. de Interação

Diagram. Transição de EstadoDiagram. de Atividades

Work Breakdown Structure – WBS (Estrutura Analítica de Trabalho – EAT)

• O WBS é um chek-list que identifica todas as partes do projeto e as tarefas associadas.

• É peça central no planejamento de qualquer projeto.

• Contém dois tipos de elementos:

• Pacote Trabalho – Corresponde a uma atividade que será atribuída a uma pessoa ou equipe.

• Tarefa Resumo – Corresponde a um agrupamento de pacotes de trabalho.

Quando uma equipe recebe um pacote de trabalho, ela poderá listar o conjunto de atividades que precisam ser executadas e distribuir estas atividades entre os membros da equipe. O pacote de trabalho representa, então, o menor nível de gerenciamento para o gerente do projeto.


Work Breakdown Structure – WBS (Estrutura Analítica de Trabalho – EAT)

Existem WBS padrão para determinados tipos de projetos, que podem servir como ponto de partida para a criação do WBS específico para o projeto, Exemplo: Engenharia Civil, Aeronáutica, Desenvolvimento de Software, etc.

O WBS para desenvolvimento de software pode ser baseado em diferentes linguagens de modelagem (Análise Essencial, UML, etc) e diferentes metodologias de desenvolvimento (Rational Unified Process - RUP, Praxis, etc).

O critério de finalização de uma tarefa pode ser definido através das respostas às seguintes requisitos:

• O que significa terminar esta tarefa? Como saber se tudo foi feito corretamente?• Descobrir critérios de aceitação do cliente para reproduzí-los “em casa”.• Checar a verificação do trabalho através de uma lista de verificação ou teste sistemático.



Projeto deDesenvolvimento

de Software

Implementação

Camada de Regras de Negócio

Camada de Persistência

Camada de Dados

Camada de Interface com o Usuário (GUI)

Manual doUsuário

Especificação

Modelo de Caso de Uso

Modelo de Análise

Modelo deDesigne

Modelo deImplementação

Requisitos doNegócio

Modelo de Negócio

Testes

Modelo deTestes

Testes de Integração

Implantação

Banco deDados

AplicaçõesDe Software

Aplicações deUsuários

Treinamento

Exemplo de WBS para desenvolvimento de software baseado em RUP

Modelo de Implantação


Bezerra, Eduardo. Princípios da Análise e Projeto de Sistemas com UML. Rio de Janeiro: Elsevier, 2002.

Booch, Grady; Rumbaugh, James; Jacobson, Ivar. UML – Guia do Usuário. Rio de Janeiro: Campus, 2000.

DeMarco, Tom. Análise Estruturada e Especificação de Sistema. Rio de Janeiro: Campus, 1989.

Ito, Marcia. UML e a Modelagem de Sistemas – Um Enfoque Prático. Disponível em <http://www.mind-tech.com.br/users/ito/marcia>. Acesso em 01/02/2005.

McMenamim, Sthephen M.; Palmer, John F. Análise Essencial de Sistemas. São Paulo: MacGraw-Hill, 1991.Paula Filho, Wilson de Pádua. Engenharia de Software – Fundamentos, Métodos e Padrões. Rio de Janeiro: LTC, 2003.


Pompilho, S. Análise Essencial – Guia Prático de Análise de Sistemas. Rio de Janeiro: Infobook, 1995.

Souza, Isabel Fernandes de. Apostila de Engenharia de Sistemas de Informação – Parte II.


· O que são requisitos

o Definiçãoo Classificação

· Produção de requisitos

o Levantamento de requisitos- Fontes- Técnicas de comunicação com clientes e usuários

. Análise de documentos

. Entrevistas

. Reuniões

. Observação

. Etnografia

o Registro dos requisitos

Tópico 4 - Análise e Especificação de Requisitos

ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS

Requisitos

The IEEE Standard Glossary of Software Engineering Terminology [IEEE97] define requisito como uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo (...).

Desta definição pode-se aferir que os requisitos de software são derivados de necessidades que usuários têm em resolver algum problema. Situa-se, então, o domínio do problema.


Os domínios da Engenharia de Requisitos


Definição de universo de informações

A especificação de requisitos deve incluir não somente as especificações do domínio do problema, mas também qualquer tipo de informação que descreva o contexto do sistema.

Esse contexto é conhecido como universo de informações, que é a realidade circunstanciada pelo conjunto de objetivos definidos pelos que demandam o software, e inclui todas as fontes de informação e todos os stakeholders.


Definição de domínio do problema

• O domínio do problema é o domínio de atuação do software e inclui todos os elementos que interagem com ele.

• O domínio do problema é, portanto, o ambiente de atuação do software. Neste ambiente principiam as atividades da engenharia de software, a definição das necessidades do software.

• É tarefa dos engenheiros de requisitos entender o problema, na cultura e linguagem dos usuários, e definir um sistema que atenda às suas necessidades. Para tal, o engenheiro de requisitos deve descobrir e estabelecer o universo de informações, de onde obtém os recursos na tarefa de elucidação do problema.


Definição do domínio da solução

• No domínio da solução é enfocada a definição da solução aos problemas dos usuários.

• Os desenvolvedores do software aplicam seus conhecimentos em busca da especificação do sistema a ser desenvolvido.

• Envolve as características da solução e os requisitos do sistema.

• Uma característica é definida como um serviço que o sistema provê para cumprir uma ou mais necessidades dos stakeholders.

• Uma vez estabelecido o conjunto de características com a concordância dos stakeholders, deve-se definir os requisitos mais específicos que serão necessários impor a solução.

• Requisitos são propriedades que um sistema de software deve ter.


Requisitos

• Funcionais – representam os comportamentos que um programa ou sistema deve apresentar diante de certas ações de seus usuários.

• Não-funcionais – quantificam determinados aspectos do comportamento. (Ex: tempo de resposta, tempo médio entre falhas, etc.).

Especificações dos requisitos:

• Explícitos – são aqueles descritos em um documento que arrola os requisitos de um produto, ou seja, a especificação de requisitos.

• Normativos – são aqueles que decorrem de lei, regulamentos e outros tipos de normas a que o produto deve obedecer.

• Implícitos – são expectativas dos clientes e usuários, que são cobradas por esses, embora não documentadas.


Processo de Aquisição e Especificação de Requisitos

Elicitação (Levantamento) de Requisitos – Fontes

– Stakeholders

• Clientes• Usuários• Desenvolvedores

– Documentos

– Livros

– Sistemas de software (específico da organização ou software comercial)

Levantamento de requisitos – Técnicas

– Levantamento orientado a pontos de vista

– Cenários



Levantamento orientado a pontos de vista

• Normalmente, há diferentes tipos de usuário final e, em função disso, diferentes pontos de vista.

• Os pontos de vista podem ser organizados de forma hierárquica, como por exemplo:

Todos os pontos de vista

Cliente Pessoaldo banco

Caixa Gerente Engenheiro

Não-titularda conta

Titularda conta

Serviços

Consultar saldoRetirar dinheiro

Serviços

Pedir chequesEnviar mensagemExecutar transaçãoda listaPedir extratoTransferir fundos

Referência:

Atributos:

Eventos:

Serviços:

Subpontos de vista:

Cliente

Número da conta PINInício da transação

Selecionar serviçoCancelar transaçãoEncerrar transação

Retirada de dinheiroConsulta de saldo

Titular da contaNão-titular da conta

Referência:

Razão:

Especificações:

Pontos de vista:

Requisitos não funcionais:

Provedor:

Retirada de dinheiro

Melhorar serviço do cliente e reduzir trabalho com papel

Usuários escolhem o serviço pressionando o botão de retirada de dinheiro. Em seguida, informam a quantia solicitada. A operação é confirmada e, se o saldo permitir, o dinheiro é entregue.

Cliente

Entregar o dinheiro um minuto após ser confirmada e quantia.

Preenchido posteriormente


Levantamento orientado a pontos de vista (continuação)


Cenários

• Cada cenário aborda um ou um pequeno número de possíveis interações.

• O cenário geralmente começa com um esboço da interação e, durante o levantamento de requisitos, são acrescentados detalhes para criar uma distribuição completa dessa interação.

• O cenário pode incluir:

• uma descrição de estado do sistema no início do cenário;• uma descrição do fluxo normal de eventos no cenário;• uma distribuição do que pode sair errado e de como lidar com isso;• informações sobre outras atividades que possam estar em andamento ao mesmo tempo;• uma descrição do estado do sistema no final do cenário.


Métodos de Coleta de Requisitos

Algumas técnicas das ciências sociais, como psicologia e sociologia, têm sido estudadas e utilizadas nesta atividade, que envolve fatores comportamentais e de relacionamento humano.

Entre os métodos mais comuns estão:

• análise de documentos;• entrevistas (tutoriais, estruturadas, não-estruturadas, semi-estruturadas);• reuniões (Participatory Design, Joint Application Design e Brainstorming);• observações;• etnografia.


Análise de documentos

• A análise de documentos é uma técnica usualmente aplicada na qual explora-se o conhecimento escrito encontrado no universo de informações.

• A análise dos documentos permite um contato com o vocabulário utilizado no domínio do problema e auxilia na construção do glossário de termos especializados, que tem por objetivo definir os objetos e equalizar o conhecimento dos stakeholders.


Técnicas de entrevistas

• Entrevista é uma técnica de interação entre entrevistado (especialista do conhecimento) e entrevistador (engenheiro de requisitos) buscando revelar conceitos, objetos e a organização do domínio do problema, além de buscar soluções ou projeções de soluções que comporão o domínio da solução.

• Entrevistas tutoriais - o entrevistado fica no comando, praticamente lecionando sobre um determinado assunto.

• Entrevistas informais (não estruturadas) - o entrevistador age espontaneamente, perguntando ao entrevistado sem obedecer a nenhuma organização. Esse tipo de entrevista oferece flexibilidade ao entrevistador e, normalmente, é utilizado no início do processo de elicitação.

• Entrevistas estruturadas - são preparadas pelo entrevistador, que define previamente o andamento do procedimento de aquisição de conhecimento.

• Entrevistas semi-estruturadas – são entrevistas que misturam as características das entrevistas estruturadas e das entrevistas não estruturadas.

• Um fator importante a ser considerado nas entrevistas é o registro das informações coletadas, que pode ser realizado através de anotações ou gravações de áudio ou vídeo. O material produzido deve ser organizado e serve como base para a preparação da próxima entrevista.


Técnicas de reuniões

Reunião - Permite uma interação mais natural entre os participantes e que podem oferecer múltiplas visões sobre a questão abordada.

•Joint Application Design, Participatory Design e Brainstorming são metodologias de reuniões que enfatizam a participação coletiva na elicitação de requisitos.

• Joint Application Design (JAD) - Baseia-se em sessões estruturadas e disciplinadas, onde os envolvidos reúnem-se para desenvolver juntos o sistema de software. Em linhas gerais, essas sessões possuem uma agenda detalhada, recursos visuais para auxiliar a exposição de idéias, um moderador e um relator que registra as especificações de acordo comum entre os membros do grupo. O produto final é um documento que contém definições do software.


Técnicas de reuniões (continuação)

•Participatory Design (PD) é uma abordagem que concentra-se mais fortemente no envolvimento dos usuários, em relação ao Joint Application Design, por facilitar o processo de aprendizado entre desenvolvedores e usuários através de experiências conjuntas em situações de trabalho simuladas. Em linhas gerais, os usuários são introduzidos no ambiente dos desenvolvedores, conhecendo possibilidades técnicas e, da mesma maneira, os desenvolvedores colaboram com os usuários em suas tarefas. Ocorre um aprendizado mútuo que vem a contribuir no processo de definição dos requisitos.

•Braistorming - A filosofia básica do brainstorming é procurar deixar que venham a tona todas as idéias possíveis, sem que estas sofram quaisquer críticas durante o processo de criação. Isto diminui os bloqueios, e permite que as idéias fluam melhor. Isto faz com que o inconsciente comece a desbloquear parte do raciocínio não-lógico que estava bloqueado e, quando bem aplicado, seja um poderoso instrumento de trabalho. Nesta reunião, a característica principal é a total ausência de crítica e o julgamento adiado. As idéias que surgirem serão anotadas, por mais loucas que possam parecer, e nunca sofrerão críticas na hora em que forem formuladas.


Técnica de observação

• Observação é uma técnica na qual o engenheiro de requisitos procura ter uma posição sobre o domínio do problema, observando seus elementos e comportamentos.

• Visa obter um entendimento inicial sobre o contexto em estudo.

• As observações consistem em observar alguém no momento da realização de suas tarefas rotineiras no ambiente real.

• O observador procura familiarizar-se com o domínio do problema e elicitar as informações necessárias para o seu entendimento.

• A aquisição desse conhecimento pode ocorrer com interrupção ou não das atividades do observador.


Etnografia

• Outra técnica que pode ser aplicada de forma complementar com o intento de permitir uma visão mais completa e ajustada do domínio do problema é a etnografia.

• Etnografia é a coleta direta, e o mais minuciosa possível, dos fenômenos observados, por uma impregnação duradoura e contínua e um processo que se realiza por aproximações sucessivas.

• É originária da antropologia, em observações de práticas das sociedades.

• No contexto da engenharia de requisitos, é uma técnica que busca revelar informações sobre a estrutura, organização e práticas do domínio do problema.

• A etnografia, segundo conclusão do projeto realizado, pode levar a obtenção de requisitos fechados à prática corrente, o conhecimento tácito.


Validação de Requisitos

A validação de requisitos se ocupa em mostrar que os requisitos realmente definem o sistema que o cliente deseja.

Principais verificações de requisitos:

• Verificações de validade – O sistema deve conciliar as necessidades de todos os seus usuários.

• Verificações de consistência – Os requisitos em um documento não devem ser conflitantes, ou seja, não devem existir restrições contraditórias.

• Verificações de completeza – O documento de requisitos deve incluir requisitos que definam todas as funções e restrições exigidas pelo usuário do sistema.

• Verificações de realismo – Um conjunto de verificações deve ser projetado para mostrar que o sistema entregue cumpre com seus requisitos.


Validação de Requisitos (continuação)

Técnicas de validação de requisitos:

• Revisões de requisitos – É um processo manual, que envolve muitos leitores, tanto do pessoal do cliente como do fornecedor, que verifica o documento de requisitos a fim de detectar anomalias ou omissões.

• Prototipação – É fornecido um modelo do sistema para que o usuário possa verificar se o sistema atenderá às suas necessidades.

• Análise automatizada da consistência - Utilização de ferramenta CASE para fazer a de consistência dos requisitos.

Registro dos requisitos

1. Missão do Produto

2. Limites do Produto

3. Lista de requisitos funcionais

• Nome e descrição do requisito

• Identificação do ator

• Necessidades e Benefícios

• Estabilidade

• Prioridade

4. Descrição dos atores

5. Regras de Negócio

6. Lista de requisitos não funcionais

7. Lista dos requisitos de persistência


1. Missão do Produto

Descrever os objetivos do produto que deverá ser desenvolvido no projeto. De preferência, usar um único parágrafo que sintetize a missão a ser desempenhada pelo produto, ou seja, que valor o produto acrescenta para o cliente e os usuários.

A declaração de missão deve cumprir os seguintes objetivos:

• delimitar as responsabilidades do produto;

• delimitar o escopo do produto;

• sintetizar o comprometimento entre cliente e fornecedor.

Exemplo:

O produto Merci 1.0 visa a oferecer apoio informatizado ao controle de vendas, de estoque, de compra e de fornecedores da mercearia Pereira & Pereira.


2. Limites do Produto

Deve-se determinar o que o produto não fará. Isso evita falsas expectativas por parte dos clientes e usuários e podem ressaltar funções e atributos que serão implementados por outros componentes de um sistema maior, ou em versões futuras desse produto.

Exemplo:

1. O sistema não fará vendas parceladas e só receberá pagamentos em dinheiro ou cheque.

2. O backup e a recuperação das bases de dados do sistema ficam a cargo da administração, não sendo providos pelo sistema.

3. O sistema não terá ajuda on-line.



3. Lista de requisitos funcionais – Nome e descrição do requisito

Os requisitos funcionais definem as ações fundamentais através das quais o produto aceita e processa as entradas especificadas, gerando as respectivas saídas.

Exemplo:

Número Requisito Descrição

1 Manter mercadoria Realizar o cadastro (inclusão, alteração, exclusão e consulta dos dados de uma mercadoria.

2 Manter pedido de compra Realizar o cadastro (inclusão, alteração, exclusão e consulta dos dados de umpedido de compra.

3 Abrir caixa Dar início às operações do caixa.

4 Fechar caixa Encerrar as operações do caixa.

3. Lista de requisitos funcionais – Identificação dos atores

Na terminologia da UML, qualquer elemento externo que interage com o sistema é denominado ator. Note que um ator corresponde a um papel representado em relação ao sistema.

Critérios para identificação dos atores:

• quem está interessado em certo requisito;• quem se beneficiará diretamente do produto;• quem usará informação do produto;• quem fornecerá informação ao produto;• quem dará suporte e manutenção ao produto;• quais os recursos externos usados pelo produto;• quais os papéis desempenhados por cada usuário;• quais os grupos de usuários que desempenham o mesmo papel;• quais os sistemas legados com os quais o produto deve interagir;• o tempo, quando os casos de uso são disparados periodicamente, de forma automática.

Exemplo: Caixa, Atendente, Sistema Financeiro, Setor de Cadastro, etc.


3. Lista de requisitos funcionais – Identificação dos atores (continuação)

Os atores podem ser classificados em:

Ator Primário

• É aquele que inicia uma seqüência de interações de um caso de uso;• É um agente externo para o qual o caso de uso traz benefício direto;• As funcionalidades principais do sistema são definidas tendo em mente os objetivos dos atores primários.

Ator Secundário• É aquele que supervisiona, opera, mantém ou auxilia na utilização do sistema;• Existem apenas para que os atores primários possam utilizar o sistema.

Exemplo-1: Considere um programa para navegar na Internet (browser). Para que o usuário (ator primário) requisite uma página ao programa, um outro ator (secundário) está envolvido: o Servidor Web.

Exemplo-2: Quando um cliente precisa da ajuda do vendedor para registrar suas compras no sistema, o cliente é o ator primário e o vendedor o ator secundário.



3. Lista de requisitos funcionais – Nome e descrição do requisito

Os requisitos funcionais definem as ações fundamentais através das quais o produto aceita e processa as entradas especificadas, gerando as respectivas saídas.

Exemplo:

Número Requisito Descrição Ator

1 Manter mercadoria Realizar o cadastro (inclusão, alteração, exclusão e consulta dos dados de mercadorias.

Gerente de Compras

2 Manter fornecedor Realizar o cadastro (inclusão, alteração, exclusão e consulta dos dados de fornecedores.

Gerente de Compras

3 Manter pedido de compra Controlar os pedidos de compra feitos aos fornecedores.

Gerente de Compras

4 Abrir caixa Dar início às operações do caixa. Caixa

5 Fechar caixa Encerrar as operações do caixa. Caixa

3. Lista de requisitos funcionais – Necessidades e Benefícios

Deve-se identificar as necessidades que os requisitos atenderão e os benefícios que eles podem proporcionar. O levantamento dos benefícios é necessário para determinar se o valor dele compensará o investimento no projeto.

Exemplo:


Núm. Requisito Ator Necessidades Benefícios

1 Manter mercadoria

Gerente de Compras

Identificação das mercadorias.

Fornecer dados para outras funções

Agilidade na compra e venda de mercadorias.

Melhoria do conhecimento dos produtos comercializados.

2 Manter fornecedor

Gerente de Compras

Atualizar os dados dos fornecedores.

Atualizr a lista de produtos comercializados por cada fornecedor.


Controle dos dados de fornecedores.

Conhecimento do mercado de fornecedores.

Avaliação da qualidade de fornecimento.

3 Manter pedido de compra

Gerente de Compras

Registro dos pedidos de compra.

Controle de cancelamento de pedidos.

Acompanhamento do prazo de entrega.

Registro da recepção das mercadorias.


Apoio na avaliação das melhores condições de preço e menores prazos de entrega.

Eliminação da duplicidade de pedidos.

Identificação de mercadorias não entregues.

4 Abrir caixa Caixa Colocar o caixa no modo de venda, informando o seu valor de abertura.

Ter controle dos valores de cada abertura do caixa.

Diminuição de erros na prestação de contas.

5 Fechar caixa Caixa Encerrar as operações do caixa, apurando o total das transações realizadas.

Ter controle da movimentação do período.

Diminuição de erros na prestação de contas.

3. Lista de requisitos funcionais – Prioridade

Representa o valor atribuído ao requisito, pelo cliente, em função do(s) benefício(s) que ele lhe proporcionará.

A prioridade é classificada em:

• Essencial – O requisito é fundamental. Sua falta acarretará o não atendimento das necessidades do cliente.

• Desejável – A existência do requisito contribuirá para o atendimento das necessidades do cliente, mas a sua falta é aceitável.

• Opcional – A existência do requisito está condicionada a sobra de recursos, prazo, etc. Sua falta não prejudica o atendimento das necessidades do cliente.


3. Lista de requisitos funcionais – Estabilidade

Representa a probabilidade do requisito ser alterado no decorrer do projeto, com base na experiência de projetos correlatos.

A estabilidade é classificada em:

• Alta – O requisito tem pouca chance de mudar no decorrer do projeto.

• Média – A probabilidade do requisito mudar no decorrer do projeto estaria em torno de 50% de chance.

• Baixa – O requisito tem grande chance de mudar no decorrer do projeto.



Exemplo: Lista de requisitos funcionais – Prioridade e Estabilidade

Número Requisito Funcional Ator Prioridade Estabilidade

1Manter mercadoria

Gerente de Compras Essencial Média

2Manter fornecedor

Gerente de ComprasEssencial

Baixa

3 Manter pedido de compra Gerente de Compras Opcional Baixa

4 Abrir caixa Caixa Essencial Média

5 Fechar caixa Caixa Essencial Média

4. Descrição dos Atores

Para cada ator deve-se incluir uma descrição sucinta das responsabilidades do respectivo papel.

Deve-se também identificar as características mais importantes do respectivo grupo de usuários.

Exemplo de descrição dos atores:


Ator Descrição

Caixa Funcionário operador comercial do caixa.

Gerente de Compras Funcionário responsável pela gestão dos cadastros de mercadorias e fornecedores, e pela emissão e acompanhamento de pedidos de compra.

Sistema Financeiro Sistema de gestão financeira que recebe os detalhes financeiros das transações diárias, para utilização posterior pela administração financeira da mercearia.

5. Regras de Negócio

Segundo o Business Rules Group (BRG) pode-se definir regra de negócio segundo dois aspectos:


Sistemas de informação Negócio

Regra de negócio é “uma sentença que define ou restringe algum aspecto do negócio (...) sua intenção é manter a estrutura do negócio, ou controlar ou influenciar algum aspecto do negócio”. Nesse contexto, as regras de negócio dizem respeito aos “dados que podem ser cadastrados em um sistema de informação”.

Regras de negócio são “diretivas que visam influenciar ou guiar o comportamento do negócio. Tais diretivas existem como suporte a políticas de negócio, formuladas em resposta a riscos, ameaças ou oportunidades”.

5. Regras de Negócio (continuação)



Classificação das Regras de Negócio:

Regras de Rejeição (Rejector): são regras que rejeitam um evento porque ele conduz o sistema a um estado que não é permitido. As restrições de integridade em bancos de dados são exemplos desse tipo de regra.

Ex1: “Uma conta não pode ter saldo negativo”. Ex2: “Um time não pode ter mais que 11 jogadores em campo”.

Regras de Projeção (Projector): são regras que projetam o evento em outros eventos alterando os fluxos de execução.

Ex1: “Ao criar um cliente, deve ser criada uma nova conta para ele”. Ex2: “Se uma conta tiver saldo maior que 5.000, enviar folheto sobre investimentos”.

Regras de Produção (Productor): são regras que não respondem a eventos, elas apenas definem informações do negócio.

Ex1: “Saldo é igual a crédito menos débito” Ex2: “Uma conta é “Ouro Especial” se seu saldo atual é superior a 30.000 e seu médio saldo médio é superior a 20.000.”



Exemplo:


Nome Condição para realização do pedido de compra (RN01)

Descrição Somente serão aceitos pedidos de compra para fornecedores que tenham menos do que 3 ocorrências de entrega fora do prazo.

Obs: Esta regra de negócio deverá ser aplicada no requisito Incluir pedido de compra.


RequisitosNão

Funcionais

Requisitosdo produto

Requisitosorganizacionais

Requisitosexternos

Requisitoséticos

Requisitos de interoperabilidade

Requisitoslegais

Requisitosde segurança

Requisitosde

privacidade

Requisitosde

implementação

Requisitosde espaço

Requisitosde

desempenho

Requisitosde eficiência

Requisitosde facilidade

de uso

Requisitosde

confiabilidade

Requisitosde

portabilidade

Requisitosde entrega

Requisitosde padrões

6. Lista de requisitos não funcionais

Os requisitos não funcionais podem ser classificados segundo a seguinte estrutura hierárquica

6. Lista de requisitos não funcionais (continuação)

Exemplos:


RNF01 O tempo de totalização da Operação de Venda (isto é, o

intervalo de tempo entre qualquer alteração nos itens de venda

e a exibição do total a pagar) não pode ser maior do que 2

segundos.

RNF02 O tempo para realização de qualquer operação de pesquisa de

usuários, mercadorias, fornecedores ou pedidos de compra não

pode ser maior do que 10 segundos.

RNF03 O leiaute do relatório Nota Fiscal deve ser previamente aprovado pela Secretaria de Receita.

RNF04 O Merci deverá ser desenhado de forma que possa ser expandido para mais de um terminal.

7. Lista dos Requisitos de Persistência

Requisitos de persistência são representados através das classes de entidade, com seus atributos e operações.

Possíveis Notações para uma Classe na UML

Nome da Classe Nome da classe Nome da classe Nome da classe

Lista de atributos Lista de operações Lista de atributos

Lista de operações

Atributos – descrição dos dados armazenados pelos objetos de uma classe. Cada atributo de uma classe está associado a um conjunto de valores que esse atributo pode assumir.

Operações – correspondem à descrição das ações que os objetos de uma classe sabem realizar. O nome de uma operação, normalmente, contém um verbo e um complemento e termina com um par de parênteses.


7. Lista dos Requisitos de Persistência (continuação)

Técnica para identificação das classes - procurar substantivos existentes nos fluxos dos casos de uso.

• eliminar aspectos de implementação e conceitos irrelevantes quanto à missão do produto;

• resolver ambigüidades da linguagem;

• considerar também locuções verbais, desde que equivalentes a substantivos;

• considerar que substantivos podem não resultar em classes, mas em objetos, relacionamentos ou atributos de classes;

• permanecer no nível lógico, não incluindo detalhes da implementação;

• permanecer dentro do escopo do produto, evitando classes não conexas com a missão.



Especificação das classes

• Deve-se escolher nomes significativos, isto é, substantivo no singular;

• Deve-se evitar nomes vagos, assim como nomes reservados da própria metodologia (classe, tipo, etc.);

• Deve-se utilizar nomes que façam parte do domínio do negócio.

Ao longo da análise, a especificação das classes será completada com outros aspectos relevantes, como:

• Operações necessárias para cumprir as responsabilidades;

• Atributos necessários para cumprir as responsabilidades.



Nomenclatura para o diagrama de classes na UML

• Para identificadores – quaisquer espaços em branco e preposições do nome são removidos.

• Para nomes de classes e nomes de relacionamentos – começar com letra maiúscula. Exemplo: Cliente, ItemPedido, Pedido, etc.

• Para nomes de atributos e nomes de operações – escrever a primeira palavra do nome em minúsculas e as palavras subseqüentes, sem espaço em entre elas, começando com a letra em maiúsculo. No entanto, siglas são mantidas inalteradas. Exemplo: quantidade, precoUnitario, CPF, dataNascimento, etc.



Exemplos de classes


Nome da classe Descrição da classe Atributos da classe

Fornecedor representa os fornecedores da empresa

nome

CNPJ

contato

telefone

PedidoCompra representa os pedidos feitos pelos aos fornecedores da empresa

dataPedido

status

Obs: A associação existente entre Fornecedor e PedidoCompra (um fornecedor fornece muitos pedidos e um pedido é fornecido por somente um fornecedor) só ficará evidente após a construção do diagrama de classes. Não pode existir nenhum atributo na classe PedidoCompra, nem na classe Fornecedor, que tente representar essa associação.


Diagrama de Objetos (ou Diagrama de Instâncias)

• Podem ser vistos como instâncias de diagramas de classes, da mesma forma que objetos são instâncias de classes;

• Assim como diagramas de classes, diagramas de objetos são estruturas estáticas. Um diagrama de objetos exibe uma “fotografia” do sistema em um certo momento;

• Cada objeto é representado por um retângulo com dois compartimentos. • No compartimento superior, a identificação do objeto é exibida

• No compartimento inferior, quando utilizado, exibe uma lista de pares da forma nome do atributo: valor do atributo;

• A identificação do onjeto deve ser sempre sublinhada.



Exemplo de Diagrama de Objetos:


Pedido1:Pedido

data = 13/09/2002status = “A”

Item1:ItemPedido

quantidade = 6

Item2:ItemPedido

quantidade = 20

Item3:ItemPedido

quantidade = 1

Mercadoria20:Mercadoria

nome = “caderno M”descrição = “caderno em espiral tamanho médio”


nome = “caneta esf”descrição = “caneta esferográfica 5 mm”


nome = “esquadro”descrição = “esquadro de acrílico 20 cm

Fornecedor10:Fornecedor

nome = “Distribuidora XYZ”CNPJ = 30502231000129contato = “Maria”telefone = 2126657588


Rocco, Giovanni Ely. Engenharia de Requisitos. Universidade de Caxias do Sul - Centro de Ciências Exatas e Tecnologia - Departamento de Informática.

Alenquer , Pablo Lopes . Regras de Negócio para Análise em Ambientes OLAP. Disponível em http://genesis.nce.ufrj.br/dataware/DataWarehouse/Teses/Pablo/TesePablo.pdf Acesso em 02/11/2005.

Bezerra, Eduardo. Princípios da Análise e Projeto de Sistemas com UML. Rio de Janeiro: Elsevier, 2002.


Souza, Isabel Fernandes de. Apostila de Engenharia de Sistemas de Informação – Parte III.



http://genesis.nce.ufrj.br/dataware/DataWarehouse/Teses/Pablo/TesePablo.pdf%20%20extra%C3%ADdo%20em%2002/11/2005

engenharia de requisitos 2010 autora :professora carmen lucia asp de queiroz

Documents