Engenharia de Requisitos

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 Software Tópico 2 - Processos de Desenvolvimento de Software Tópico 3 - Paradigmas de Desenvolvimento de Software Tó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.

Tópico 1 - Visão Geral da Engenharia de Software
· Sistemas Computacionais o Definição e conceitos básicos o Evolução do desenvolvimento · Natureza do produto “software” · Definição de 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 Feedback e Controle Saída Entrada Processamento Propriedades e comportamento dos componentes estão intrinsecamente interligados Exemplo: o software só operará se o processador estiver operacional O processador poderá realizar computações apenas se o sistema de software, que define essas computações, tiver sido instalado com sucesso.

Sistema de Informação Computadorizado, ou simplesmente, Sistema de Informação Dado 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) .

Sistema de Informação Computadorizado, ou simplesmente, Sistema de Informação (continuação) Dado Informação 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) 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

É 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 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.

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) Processos (baseia-se numa ação sistemática e não na improvisação) Engenharia de Software Recursos naturais (são as máquinas utilizadas para materializar as abstrações geradas pela ciência da computação) Dispositivos e estruturas (devem ser reunidos para atender às necessidades humanas) Formas adequadas (utilidade)

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 Mito Minha 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) Mito O 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.

Mitos e Realidades no Desenvolvimento de Software (continuação) Mito Todos 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.

Mitos e Realidades no Desenvolvimento de Software (continuação) Mito O 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.

Mitos e Realidades no Desenvolvimento de Software (continuação) Mito Para 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.

Mitos e Realidades no Desenvolvimento de Software (continuação) Mito Requisitos 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.

Mitos e Realidades no Desenvolvimento de Software (continuação) Mito Enquanto 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.

Mitos e Realidades no Desenvolvimento de Software (continuação) Mito O ú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, < 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.

Tópico 2 - Processos de Desenvolvimento de Software
· 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

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)

Processo de Desenvolvimento de Software Requisitos do Usuário Sistema novo ou modificado Um processo de desenvolvimento de software é o conjunto de atividades de engenharia necessárias para transformar os requisitos do usuário em software.

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. Definir objetivos e requisitos de informação Construir/Revisar protótipo Avaliar protótipo - Usuário -

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.

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íficos para 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.: Determinar objetivos, alternativas e restrições Planejamento da próxima iteração Avaliar alternativas, Identificar, Resolver riscos Desenvolvimento, verificar produto do próximo nível

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. Planejamento da iteração Requisitos Análise Desenho Nova iteração Avaliação da iteração Testes Implementação Projeto Terminado

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 Análise Desenho Arquitetônico Desenho Detalhado Implementação Nova iteração Avaliação da iteração Testes Projeto Terminado

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 Elementos novos de processo 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

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 Fornecer um framework simples, com base nos fundamentos do PSP (Personal Software Process); Desenvolver produtos em vários ciclos; Estabelecer medidas-padrão para qualidade de software; Fornecer medidas precisas para equipes; Utilizar avaliações de papéis e de equipe; Fornecer disciplina nos processos; 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.

Rational Unified Process – RUP 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.

Rational Unified Process – RUP 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.

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

Rational Unified Process – RUP 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.

Rational Unified Process – RUP

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 das Atividades Seqüência das Atividades Programação Planejamento dos Recursos Estimativas e Durações Definição do WBS Planejamento Global Estimativa dos Custos Orçamento dos Riscos Planejamento dos Riscos

Além dos processos da figura anterior, alguns projetos requerem também os processos auxiliares abaixo: Planejamento da Qualidade Planejamento Organizacional Contratação de Pessoal Planejamento de Aquisições Preparação da Documentação Planejamento da Comunicação Identificação dos Riscos Análise Qualitativa Análise Quantitativa Planos de Resposta ao Risco

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.

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” 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

Referências Bibliográficas Albuquerque, Antonio Roberto; Schiavo, Luciano. Uma visão de abordagem de desenvolvimento de software do Rational Unified Process. Disponível em < Acesso em 01/02/2005. Hazan, Claudia. Implantação de um processo de medições de software. Disponível em . Acesso em 03/02/2005. Leite, Jair C. Processo de Desenvolvimento de Software. Disponível em < 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. 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. Souza, Isabel Fernandes de. Apostila de Engenharia de Sistemas de Informação – Qualidade – Parte VIII. Sommerville, Ian. Engenharia de Software. São Paulo: Pearson Education, 2003. < Acesso em 03/02/2005. < Acesso em 03/02/2005. < . Acesso em 01/03/2005.

Tópico 3 - Paradigmas do Desenvolvimento de Software
· 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

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 ~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.

Princípios da Modelagem Essencial FASES DO PROJETO OBJETIVO ATIVIDADE Descrever o comportamento desejado para o sistema Projeto Lógico Elaborar o modelo essencial Descrever a organização da tecnologia automatizada que incorporará o comportamento desejado Projeto Tecnológico Elaborar o modelo de implementação Incorporar o modelo de implementação ao hardware e software Implementação Construir o sistema

O Modelo Essencial OBJETIVO FERRAMENTAS SUBMODELO Descrição do propósito Lista de eventos Diagrama de contexto Descrição do ambiente no qual o sistema opera Ambiental Descrição do comportamento em resposta a eventos em seu ambiente MER DFD DTE Dicionário de Dados Miniespecificação de processos Comportamental

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: Qualquer coisa é um objeto. Os objetos realizam tarefas através da requisição de serviços a outros objetos. Cada objeto pertence a uma determinada classe. Uma classe agrupa objetos similares. A classe é um repositório para comportamento associado ao objeto. 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

Conjunto de Objetos Representação Gráfica dos Objetos = Classe Animal peso altura Características cor come() Comportamento 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 Mensagem Ande Representação Gráfica Mensagem

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. Figura Maior abstração Menor 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.

12/junho/2003 UML 2.0 UML UML 1.3 UML UML 1.5 Set 1997 OMT + BOOCH = UML 1.1 Jan 1997 OMT + BOOCH = UML 1.0 Microsoft, IBM, HP, outras Jun 1996 OMT + BOOCH = UML 0.9 Iva Jacobson Grady Booch James Rumbaugh OMT + BOOCH = UML 0.8 Out 1995

Visões de um Sistema de Software Visão de Implementação Visão de Projeto Visão de Casos de Uso 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 UML Diagramas da UML Diagramas de Casos de Uso Diagramas de Classes Diagramas de Atividades Diagramas de Implementação Diagramas De Objetos Diagramas de Transições de Estado Diagramas de Componentes Diagramas de Implantação Diagramas De Interação Diagramas de Sequência Diagramas de Colaboração

Visões de um Sistema de Software Visão de Implementação Visão de Projeto Diagram. de Classes Diagram. de Objetos Diagram. de Interação Diagram. Transição de Estado Diagram. de Atividades Diagram. de Componentes Diagram. de Interação Diagram. de Transição de Estado Diagram. de Atividades Visão de Caso de Uso Diagramas de Caso de Uso Diagram. de Interação Diagram. de Transição de Estado Diagram. de Atividades Visão de Implantação Visão de Processo Diagram. de Classes Diagram. de Objetos Diagram. de Interação Diagram. Transição de Estado Diagram. de Atividades Diagram. de Implantação Diagram. de Interação Diagram. de Transição de Estado Diagram. 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.

Exemplo de WBS para desenvolvimento de software baseado em RUP Projeto de Desenvolvimento de Software Requisitos do Negócio Especificação Implementação Testes Implantação Modelo de Caso de Uso Camada de Regras de Negócio Modelo de Testes Banco de Dados Modelo de Negócio Modelo de Análise Camada de Persistência Testes de Integração Aplicações De Software Modelo de Designe Camada de Dados Aplicações de Usuários Modelo de Implementação Camada de Interface com o Usuário (GUI) Treinamento Modelo de Implantação Manual do Usuário

Referências Bibliográficas 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 < 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. 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.

Tópico 4 - Análise e Especificação de Requisitos
· O que são requisitos o Definição o 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

ANÁLISE E ESPECIFICAÇÃO DE 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.

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 Serviços Consultar saldo Retirar dinheiro Cliente Pessoal do banco Serviços Pedir cheques Enviar mensagem Executar transação da lista Pedir extrato Transferir fundos Titular da conta Não-titular da conta Caixa Gerente Engenheiro

Levantamento orientado a pontos de vista (continuação) Referência: Atributos: Eventos: Serviços: Subpontos de vista: Cliente Número da conta PIN Início da transação Selecionar serviço Cancelar transação Encerrar transação Retirada de dinheiro Consulta de saldo Titular da conta Não-titular da conta Razão: Especificações: Pontos de vista: Requisitos não funcionais: Provedor: 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. Entregar o dinheiro um minuto após ser confirmada e quantia. Preenchido posteriormente

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 Missão do Produto Limites do Produto Lista de requisitos funcionais Nome e descrição do requisito Identificação do ator Necessidades e Benefícios Estabilidade Prioridade Descrição dos atores Regras de Negócio Lista de requisitos não funcionais 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: O sistema não fará vendas parceladas e só receberá pagamentos em dinheiro ou cheque. O backup e a recuperação das bases de dados do sistema ficam a cargo da administração, não sendo providos pelo sistema. 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. 3 Manter pedido de compra Controlar os pedidos de compra feitos aos fornecedores. 4 Abrir caixa Dar início às operações do caixa. Caixa 5 Fechar caixa Encerrar as operações do 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 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 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 Encerrar as operações do caixa, apurando o total das transações realizadas. Ter controle da movimentação do período.

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 1 Manter mercadoria Gerente de Compras Essencial Média 2 Manter fornecedor Baixa 3 Manter pedido de compra Opcional 4 Abrir caixa Caixa 5 Fechar caixa

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)

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 e seu médio saldo médio é superior a ”

5. Regras de Negócio (continuação) 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.

6. Lista de requisitos não funcionais Os requisitos não funcionais podem ser classificados segundo a seguinte estrutura hierárquica Requisitos Não Funcionais Requisitos do produto Requisitos organizacionais Requisitos externos Requisitos de facilidade de uso Requisitos de confiabilidade Requisitos de portabilidade Requisitos éticos Requisitos de interoperabilidade Requisitos de eficiência Requisitos legais Requisitos de entrega Requisitos de padrões Requisitos de desempenho Requisitos de espaço Requisitos de implementação Requisitos de privacidade Requisitos de segurança

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 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.

7. Lista dos Requisitos de Persistência (continuaçã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.

7. Lista dos Requisitos de Persistência (continuação) 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.

7. Lista dos Requisitos de Persistência (continuação) 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.

7. Lista dos Requisitos de Persistência (continuaçã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.

7. Lista dos Requisitos de Persistência (continuação) Exemplo de Diagrama de Objetos: Mercadoria20:Mercadoria nome = “caderno M” descrição = “caderno em espiral tamanho médio” Fornecedor10:Fornecedor nome = “Distribuidora XYZ” CNPJ = contato = “Maria” telefone = Item1:ItemPedido quantidade = 6 Mercadoria12:Mercadoria nome = “caneta esf” descrição = “caneta esferográfica 5 mm” Item2:ItemPedido quantidade = 20 Pedido1:Pedido data = 13/09/2002 status = “A” Mercadoria07:Mercadoria nome = “esquadro” descrição = “esquadro de acrílico 20 cm Item3:ItemPedido quantidade = 1

Referências Bibliográficas 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 Acesso em 02/11/2005. Bezerra, Eduardo. Princípios da Análise e Projeto de Sistemas com UML. Rio de Janeiro: Elsevier, 2002. Paula Filho, Wilson de Pádua. Engenharia de Software – Fundamentos, Métodos e Padrões. Rio de Janeiro: LTC, 2003. Souza, Isabel Fernandes de. Apostila de Engenharia de Sistemas de Informação – Parte III. Sommerville, Ian. Engenharia de Software. São Paulo: Pearson Education, 2003.

Engenharia de Requisitos

Apresentações semelhantes

Apresentação em tema: "Engenharia de Requisitos"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Engenharia de Requisitos

Apresentações semelhantes

Apresentação em tema: "Engenharia de Requisitos"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback