Estima de pontos de caso de uso Trabalho substitutivo ao Projeto Integrador
|
|
- André Galvão Almeida
- 8 Há anos
- Visualizações:
Transcrição
1 Estima de pontos de caso de uso Trabalho substitutivo ao Projeto Integrador Curso: Gestão da Tecnologia da Informação Disciplina: Gerencia de Projetos Professor: Elias Batista Ferreira Aluna: Kaysmier Castro
2 O que e A técnica de estimativa por Pontos de Caso de Uso foi proposta em 1993 por Gustav Karner, da Objectory (hoje, Rational Software). Ela baseia-se em dois métodos bastante utilizados - o mecanismo de Pontos de Função e uma metodologia conhecida como Mk II, uma adaptação da técnica de PFs, bastante utilizada na Inglaterra. A forma de lançar uma estimativa é o principal diferencial da métrica por Casos de Uso: o método trata de estimar o tamanho de um sistema de acordo com o modo como os usuários o utilizarão, a complexidade de ações requerida por cada tipo de usuário e uma análise em alto nível dos passos necessários para a realização de cada tarefa, em um nível muito mais abstrato que a técnica de Pontos de Função. Seus objetivos A técnica de análise de Pontos por Casos de Uso foi criada para permitir que seja possível estimar o tamanho do sistema ainda na fase de levantamento de Casos de Uso, utilizando-se dos próprios documentos gerados nesta fase de análise como subsídio para efetuar estimativas de tamanho, prazo e custo de software. O processo de contagem da métrica PCU é constituída por seis passos descritos a seguir: 1. Contar os atores e atribuir o grau de complexidade; 2. Contar os casos de uso e atribuir a complexidade; 3. Somar o total dos atores com o total de casos de uso para obter o PCU não ajustado; 4. Determinar a complexidade do fator técnico; 5. Determinar a complexidade do fator ambiente; 6. Calcular o PCU ajustado; A medição permite aos gerentes planejar, controlar, melhorar e aperfeiçoar o processo de desenvolvimento de software. Medição resulta em mudança cultural. Coletar dados, calcular e analisar métricas são três passos que devem ser implementados para iniciar um programa de métricas. O custo e o esforço necessários para construir software, mesmo em linhas de código produzidas são fáceis de coletar, desde que convenções específicas para a medição sejam estabelecidas antecipadamente. O software orientado a objetos é fundamentalmente diferente do software desenvolvido utilizando métodos convencionais. Por esse motivo as métricas para os sistemas orientados a objetos devem ser ajustadas considerando as características que a distinguem do software convencional. Existem várias métricas que podem ser utilizadas,
3 dentre as quais encontram-se o número de linhas de código e a Análise de Pontos por Função (APF). Esta última muito utilizada nas organizações de software. A métrica Pontos de Casos de Uso foi escolhida por ser uma métrica baseada fortemente na UML e mais especificamente pelos casos de uso e ainda pelo fato da empresa estar iniciando o uso da UML. Procedimentos de contagem Considerando-se a contagem de PF de funcionalidades entregues em mais de uma midia, a aplicação das regras de contagem de Pontos de Função definidas no CPM tem levado a duas abordagens alternativas, a saber: single instance e multiple instance. A abordagem single instance considera que a entrega de uma função transacional em múltiplas mídias não deve ser utilizada na identificação da unicidade da função. A abordagem multiple instance leva em consideração que a mídia utilizada na entrega da funcionalidade é uma característica de identificação da unicidade da função. Assim, funcionalidades únicas são reconhecidas no contexto da mídia na qual elas são requisitadas para operar. É importante enfatizar que o IFPUG reconhece ambas abordagens, single instance e multiple instance, para a aplicação das regras definidas no CPM. A determinação da contagem de PF seguindo a abordagem multiple instance ou single instance depende da avaliação da Coordenação de Métricas da organização. As estimativas e contagens de PF abordadas neste documento serão baseadas em multiple instance, com exceção dos casos de consultas em.pdf,.doc,.xls e consultas idênticas em tela e papel, que serão consideradas uma única funcionalidade. A seguir são descritos os termos comuns definidos pelo IFPUG [IFPUG, 2009]: Canal: também refere-se a mídia. Múltiplos canais é sinônimo de múltiplas midias. Mídia: descreve a maneira que os dados ou informações se movimentam para dentro e para fora de uma fronteira de aplicação, por exemplo, apresentação de dados em tela, impressora, arquivo, voz. Este termo é utilizado para incluir, dentre outros: diferentes plataformas técnicas e formatos de arquivos como diferentes mídias. Múltiplas Mídias: quando a mesma funcionalidade é entregue em mais de uma mídia. Frequentemente, somente uma mídia é requisitada para um usuário específico em um determinado momento, por exemplo consulta de extrato bancário via internet como oposto a consulta de extrato bancário via terminal do banco. Multi-Mídia: quando mais de uma mídia é necessária para entregar a função, por exemplo, uma nova notícia publicada na Internet que é apresentada em
4 vídeo e texto. Observe que a notícia completa só é apresentada para o usuário se ele ler o texto e assistir o vídeo. Abordagem Single Instance: esta abordagem não reconhece que a mídia utilizada na entrega da função transacional é uma característica de diferenciação na identificação da unicidade da função transacional. Se duas funções entregam a mesma funcionalidade usando mídias diferentes, elas são consideradas a mesma Roteiro de Métricas de Software do SISP 40 Funcionalidade em uma contagem de Pontos de Função. Abordagem Multiple Instance: esta abordagem especifica que o tamanho funcional é obtido no contexto do objetivo da contagem, permitindo uma função de negócio ser reconhecida no contexto das mídias que são requisitadas para a funcionalidade ser entregue. A abordagem multiple instance reconhece que a mídia para entrega constitui uma característica de diferenciação na identificação da unicidade da função transacional. Pesos, Fatores e Ajustes no ca lculo. O processo de contagem dessa métrica consiste nos seguintes passos: 1 -Relacionar os atores, classificá-los de acordo com seu nível de complexidade (simples, médio ou complexo) atribuindo respectivamente os pesos 1, 2 ou 3., conforme a tabela 1. Calcule o TPNAA (Total de Pesos não Ajustados dos Atores) somando os produtos da quantidade de atores pelo seu peso. Complexidade do ator Simples Médio Complexo Descrição Muito poucas entidades de Banco de Dados envolvidas e sem regras de negócio complexas Poucas entidades de Banco de Dados envolvidas e com algumas regras de negócio complexas Regras de negócios complexas e muitas entidades de Bancos de Dados presentes Peso Contar os casos de uso e atribuir o grau de complexidade sendo a complexidade baseada no número de classes e transações. Calcule o
5 TPNAUC (Total de Pesos não ajustados dos casos de usos) somando os produtos da quantidade de casos de usos pelo respectivo peso conforme a tabela 2. Tipo de Caso de Descrição Uso Simples Considerar até 3 transações com menos de 5 classes de análise Médio Considerar de 4 a 7 transações com 5 a 10 classes de análise Complexo Considerar de 7 transações com pelo menos de 10 classes de análise Peso Calcular PCU s não ajustados, também chamados de PCUNA, de acordo com a seguinte fórmula: PCUNA = TPNAA+ TPNAUC 4 - Determinar o fator de complexidade técnica. Os fatores de complexidade técnica variam numa escala de 0 a 5, de acordo com o grau de dificuldade do sistema a ser construído. O valor 0 indica que a grau não está presente ou não é influente, 3 influência média e o valor 5 indica influência significativa através de todo o processo. Após determinar o valor dos fatores, multiplicar pelo respectivo peso ilustrado na tabela 3, somar o total e aplicar a seguinte fórmula: Fator de complexidade técnica (FCT) = (0.01 * Somatório do Fator técnico) Descrição Peso Peso Sistemas Distribuídos 2,0 Desempenho da aplicação 1,0 Eficiência do usuário final (on-line) 1,0 Processamento interno complexo 1,0 Reusabilidade do código em outras aplicações 1,0 Facilidade de instalação 0,5 SisteUsabilidade (facilidade operacional) 0,5 Portabilidade 2,0 Facilidade de manutenção 1,0 Concorrência 1,0 Características especiais de segurança 1,0 Acesso direto para terceiros 1,0 Facilidades especiais de treinamento 1,0
6 5 - Determinar o fator de complexidade ambiental: os fatores de complexidade ambientais indicam a eficiência do projeto e estão relacionados ao nível de experiência dos profissionais. Esses fatores descritos na tabela 4 são determinados através da escala de 0 a 5, onde 0 indica baixa experiência, 3 indica média experiência e 5 indica alta experiência. Após determinar o valor de cada fator, multiplicar pelo peso e somar o total dos valores. Em seguida, aplicar a seguinte fórmula: Fator de complexidade ambiental (FCA) = 1,4 + (-0,03 * Somatório do Fator Ambiental) 6 - Calcular os PCU s ajustados: esse cálculo é realizado com base na multiplicação dos PCU não ajustados, na complexidade técnica e na complexidade ambiental através da seguinte fórmula: PCUA = PCUNA * Fator de complexidade técnica * Fator de complexidade ambiental Fator Descrição Peso F1 Familiaridade com o processo de desenvolvimento de software 1,5 F2 Experiência na aplicação 0,5 F3 Experiência com OO, na linguagem e na técnica de 1,0 desenvolvimento F4 Capacidade do líder de análise 0,5 F5 Motivação 1,0 F6 Requisitos estáveis 2,0 F7 Trabalhadores com dedicação parcial -1,0 F8 Dificuldade da linguagem de programação -1,0 7 - Calcular a estimativa de horas de programação. Karner, o criador da estimativa, sugere a utilização de 20 pessoas-hora por unidade de PCU. Schneider e Winters sugerem o seguinte refinamento : X = total de ítens de F1 a F6 com pontuação abaixo de 3 Y = total de ítens de F7 a F8 com pontuação acima de 3 Se X + Y <= 2, usar 20 como unidade de homens/hora Se X + Y = 3 ou X + Y = 4, usar 28 como unidade de homens/hora Se X + Y >= 5, deve-se tentar modificar o projeto de forma a baixar o número, pois o risco de insucesso é relativamente alto. Estimativa de horas = PCUA * pessoas hora por unidade de PCU.
7 Aplicaça o Estimativa de esforço baseado em Pontos de Casos de Uso 1.0. Mensurando Complexidade dos Atores Ator Interface Peso Qtd. Atores Valor Simples Interface de programa (API) Médio Protocolo (Ex.:TCP/IP) ou interface em modo texto Complexo Interface gráfica Total Mensurando Complexidade dos Use Cases Caso de Uso Descrição Peso Qtd. UC Valor Simples < 3 transações ou < 5 classes de análise Médio 4-7 transações ou 5 a 10 classes de análise Complexo > 7 transações ou > 10 classes de análise Total 9 50 PCUNA 56 PCUNA = Pontos de Casos de Uso Não Ajustados 3.0. Considerando Fatores Técnicos do Projeto Fator Descrição Peso Atribuído Valor T1 Sistema distribuído T2 Objetivos de performance T3 Eficiênca on-line T4 Complexidade de processamento T5 Código reusável em outras aplicações T6 Facilidade de instalação 0,5 1 0,5 T7 Facilidade de uso 0,5 4 2 T8 Portabilidade T9 Facilidade de alterações (changeability ) T10 Concorrência T11 Segurança T12 Acesso direto a terceiros T13 Necessidade de facilidades especiais de treinamento para usuários FatorT 39,5 FCT 0,995 FCT = Fator de Complexidade Técnica
8 4.0. Considerando Fatores Ambientais Fator Descrição Peso Atribuído Valor F1 Familiaridade da equipe com RUP 1,5 3 4,5 F2 Experiência da equipe 0,5 3 1,5 F3 Experiência da equipe em OO F4 Capacidade dos analistas da equipe 0,5 5 2,5 F5 Motivação F6 Estabilidade dos requisitos F7 Estagiários ou funcionários em tempo parcial F8 Domínio da tecnologia e configuração do ambiente -1,5 3-4,5 FatorA 16 FA 0,92 FA = Fator Ambiental 5.0. Pontos de Caso de Uso PCU PCUNA*FCT*FA 51,26 Pessoa-hora por unidade de PCU Estimativa em pessoa-hora Tamanho da equipe Estimativa em horas Estimativa em meses , ,05 1,28 pessoa-hora/pcu pessoas horas meses Uso dos Pontos de Caso de Uso para estimativa de prazo do estudo de caso: Após estimar o esforço necessário para o desenvolvimento do estudo de caso, o próximo passo é estimar o prazo do projeto. Inicialmente o prazo é gerado de forma empírica considerando o esforço estimado e o tamanho da equipe para o desenvolvimento do projeto através de algumas considerações 1 mês possui 22 dias úteis Com a jornada de trabalho de 8horas/dia, a produtividade do profissional no Brasil é de 6 horas/dia. Considerando as considerações propostas aplica-se a equação: Prazo (em dias) = Esforço (em horas) / (Tamanho da equipe * 6)
9 Considerando que a equipe é compreendida de 3 componentes, então temos: Prazo (em dias) = 516,88 / (3* 6) = 28,71 dias Como exemplo: Ele utiliza-se dos próprios documentos gerados nesta fase de análise como subsídio para o cálculo dimensional; Sistema que será usado como exemplo: Site de suporte de produtos para uma grande companhia de software; A estimativa foi feita a partir dos casos de uso de nível muito alto (business modelling), que foram criados em tempo de levantamento de requisitos; Os atores, nessa vez, foram os diferentes tipos de usuários identificados nesses casos de uso; Como exemplos usaremos Tipo de Ator Peso Descrição Ator Simples 1 Outro sistema acessado através de uma API de programação Ator Médio 2 Outro sistema acessado interagindo através da rede Ator Complexo 3 Um usuário interagindo através de uma interface gráfica No caso do exemplo: Tipo de Ator Peso Nº de atores Resultado Ator Simples Ator Médio Ator Complexo Total UAW 12
10 Cálculo do UUCW (Unadjusted Use Case Weight) Para fins de cálculo, dividimos os casos de uso em três níveis de complexidade: Simples (peso 5): Tem até 3 transações, incluindo os passos alternativos, e envolve menos de 5 entidades; Médio (peso 10): Tem de 4 a 7 transações, incluindo os passos alternativos, e envolve de 5 a 10 entidades; Complexo (peso 15): Tem acima de 7 transações, incluindo os passos alternativos, e envolve pelo menos de 10 entidades; Tipo Peso Nº de Casos de Uso Resultado Simples Médio Complexo Total UUCW 210 Cálculo do UUCP (Unadjusted Use Case Points) UUCP = UAW + UUCW No caso do exemplo: UUCP = = 222 Cálculo do Tfactor Fator Requisito Peso T1 Sistema distribuído 2 T2 Tempo de resposta 2 T3 Eficiência 1 T4 Processamento complexo 1
11 T5 Código reusável 1 T6 Facilidade de instalação 0.5 T7 Facilidade de uso 0.5 T8 Portabilidade 2 T9 Facilidade de mudança 1 T10 Concorrência 1 T11 Recursos de segurança 1 T12 Acessível por terceiros 1 T13 Requer treinamento especial 1 Cálculo do TCF (Technical Complexity Factor) TCF = (0.01 Tfactor) No caso do exemplo: TCF = ( ) = Fator Descrição Peso Influência Resultado E1 E2 Familiaridade com RUP ou outro processo formal Experiência com a aplicação em desenvolvimento E3 Experiência Orientação Objetos em a 1 5 5
12 E4 Presença analista experiente de E5 Motivação E6 E7 E8 Requisitos estáveis Desenvolvedores em meioexpediente Linguagem programação difícil de Efactor 26 Cálculo do ECF (Environmental Complexity Factor) ECF = (-0.03 Efactor) No caso do exemplo: ECF = ( ) = 0.62 Cálculo dos UCP (Use Case Points) UCP = UUCP TCF ECF No caso do exemplo: ECF = = ou 109 Use Case Points Cálculo do tempo de trabalho estimado Para simplificar, utilizaremos a média de 20 horas por Ponto de Casos de Uso No caso do exemplo: Tempo estimado = 109 * 20 = 2180 horas de trabalho Para efeito de cálculos usaremos os valores: - O custo da hora-desenvolvimento varia de acordo com a especialização do profissional que irá realizar a tarefa. - Para analistas, este valor se situa entre 80 e 100 reais por hora. - Para programadores, entre 30 e 60 reais a hora. - Na média, para horas de desenvolvimento de cada caso de uso, podese considerar R$ 50,00
13 É obtida a partir da multiplicação do número de casos de uso estimados, pelo valor médio da hora de desenvolvimento. Exemplo: para um sistema de 300 UCP, teríamos: 300 * 50,00 = ,00 Assim neste caso teríamos um custo de desenvolvimento de R$ ,00 (quinze mil reais) Devem ser somados todos os custos envolvidos, desde o início do projeto até o seu final: Custo de treinamento Custo de hw Custo do sw de apoio (licenças de BD, Ferramenta CASE, etc.) Custo do desenvolvimento Outros Bibliografia: 1 - [Hazan, 2008] HAZAN, C. Análise de Pontos de Função: Uma Aplicação nas Estimativas de Tamanho de Projetos de Software. Engenharia de Software Magazine, Edição 2, Devmedia, pp Acesso em 11/agosto/
Estimativas baseada em casos de uso
Estimativas baseada em casos de uso Tipos de Métricas Contagem de Linhas de Código Fonte (LOCs) Análise de Pontos por Função Análise por Casos de uso Outras Técnicas... 2 Foi proposto em 1993 por Gustav
Leia maisESTIMATIVAS BASEADA EM CASOS DE USO
ESTIMATIVAS BASEADA EM CASOS DE USO TIPOS DE MÉTRICAS Contagem de Linhas de Código Fonte (LOCs) Análise de Pontos por Função Análise por Casos de uso Outras Técnicas... Foi proposto em 1993 por Gustav
Leia maisUtilizando métricas para dimensionar um software.
Utilizando métricas para dimensionar um software. Entenda como funcionam as Métricas de Software, como e quando devem ser utilizadas, e qual a real necessidade do uso desta técnica da Engenharia de Software.
Leia maisAula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW
Ciclo de Vida Aula 2 Revisão 1 Processo de Desenvolvimento de Software 1 O Processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto
Leia maisPontos por Caso de Uso
Foi proposto em 99 por Gustav Karner; Baseou-se na Análise por Pontos de Função; Trata de estimar o tamanho de um sistema de acordo com: o modo como os usuários o utilizarão; a complexidade de ações requerida
Leia maisEstudo de Caso de Aplicação da Métrica de Pontos de Casos de Uso numa Empresa de Software
Estudo de Caso de Aplicação da Métrica de Pontos de Casos de Uso numa Empresa de Software Viviane Heimberg (Senior Sistemas) viviane@senior.com.br Everaldo Artur Grahl (FURB/DSC) egrahl@furb.br Resumo:
Leia maisEstimativa de Software Baseada em Ponto de Caso de Uso
Estimativa de Software Baseada em Ponto de Caso de Uso Apresentação Fabio Pinheiro Abreu Bacharel em Ciência da Computação Mestre em Informática Aplicada Certificado PMP Implementador Oficial MPS.BR Consultor
Leia maisEstimativa por Use Case Point (UCP)
Estimativa por Use Case Point (UCP) A análise de sistemas Orientados a Objetos já utiliza, comumente, os diagramas de Casos de Uso (Use Cases) para descrever as funcionalidades do sistema de acordo com
Leia maisUma Abordagem de Estimativa de Software Baseada em Produtividade por Categoria de Caso de Uso
Uma Abordagem de Estimativa de Software Baseada em Produtividade por Categoria de Caso de Uso Paula Franklin Chaves de Sousa 2, Fabio Pinheiro Abreu 1, 2 1 Universidade de Fortaleza UNIFOR Mestrado em
Leia maisUNICAMP Especialização em Engenharia de Software INF-322 Gerenciamento de Projetos de Software: Conceitos e Práticas. Equipe 9
UNICAMP Especialização em Engenharia de Software INF-322 Gerenciamento de Projetos de Software: Conceitos e Práticas Equipe 9 Antônio Schwartz Edmon da Silva Marcelo Uchimura Paulo Ormenese Raphael Guimenes
Leia maisEngenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios
Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Cronograma das Aulas. Hoje você está na aula Semana
Leia maisModelos para Estimativas de Custo. Hermano Perrelli hermano@cin.ufpe.br
Modelos para Estimativas de Custo Hermano Perrelli hermano@cin.ufpe.br 1 Modelos para estimativas de custos Normalmente o custo é uma função de: tamanho do produto habilidades da equipe (pessoal) ambiente
Leia maisENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br
- MÓDULO 2.1 - ANÁLISE DE PONTO POR FUNÇÃO - APF 1. INTRODUÇÃO Criada em 1979 por Allan J. Albrecht (IBM), a APF - ANÁLISE DE PONTOS POR FUNÇÃO é uma técnica para medição de projetos cujo objeto seja o
Leia maisTÉCNICAS DE ESTIMATIVAS DE CUSTOS ANÁLISE POR PONTOS DE FUNÇÃO. Alessandro Kotlinsky Deise Cechelero Jean Carlos Selzer. Resumo
TÉCNICAS DE ESTIMATIVAS DE CUSTOS ANÁLISE POR PONTOS DE FUNÇÃO Alessandro Kotlinsky Deise Cechelero Jean Carlos Selzer Resumo Este artigo descreve os conceitos gerais relacionados a técnica de Análise
Leia maisCapítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1
Capítulo 2 Processos de Software slide 1 Tópicos apresentados Modelos de processo de software. Atividades de processo. Lidando com mudanças. Rational Unified Process (RUP). Um exemplo de um processo de
Leia maisUso da curva ABC na Técnica de Análise por Pontos de Função nas Estimativas de Projetos de Softwarea
Uso da curva ABC na Técnica de Análise por Pontos de Função nas Estimativas de Projetos de Softwarea Ivanir Costa Melhorando a Relação com o Cliente Cronogramas Previsíveis Custos Previsíveis Funcionalidade
Leia maisExperiência de contratação de empresa de contagem de Pontos de Função para auxílio na gestão de contrato administrativo
Experiência de contratação de empresa de contagem de Pontos de Função para auxílio na gestão de contrato administrativo Ricardo Gaspar (21) 2172-8078 ricardo.gaspar@bndes.gov.br 22 de Julho de 2014 Objetivo
Leia maisnatureza do projeto e da aplicação métodos e ferramentas a serem usados controles e produtos que precisam ser entregues
Modelo De Desenvolvimento De Software É uma representação abstrata do processo de desenvolvimento que define como as etapas relativas ao desenvolvimento de software serão conduzidas e interrelacionadas
Leia maisAutoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira
Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Introdução Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre
Leia maisUNEMAT SISTEMA DE INFORMAÇÃO (SI) Professora: Priscila Pelegrini priscila_pelegrini@unemat-net.br
UNEMAT SISTEMA DE INFORMAÇÃO (SI) Professora: Priscila Pelegrini priscila_pelegrini@unemat-net.br SINOP MT 2015-1 COMO SÃO DESENVOLVIDOS OS SISTEMAS DE INFORMAÇÃO? São desenvolvimento como uma estrutura
Leia maisAnálise de Pontos de Função. Por Denize Terra Pimenta dpimenta_aula@yahoo.com.br
Análise de Pontos de Função Por Denize Terra Pimenta dpimenta_aula@yahoo.com.br 1 Não se consegue controlar o que não se consegue medir. 2 Bibliografia "Function Point Analysis: Measurement Practices for
Leia maisSíntese das discussões do fórum Livro-APF: Novembro/2012
Síntese das discussões do fórum Livro-APF: Novembro/2012 Nessa síntese foram abordados, em 57 mensagens, os seguintes assuntos: Contagem de Tipos de Dados de uma CE Contagem de PF de Componentes Contagem
Leia maisO modelo Entidade-Relacionamento. Agenda: -Modelagem de dados utilizando O Modelo Entidade-Relacionamento
O modelo Entidade-Relacionamento Agenda: -Modelagem de dados utilizando O Modelo Entidade-Relacionamento 1 Antes de começarmos: A modelagem conceitual é uma fase muito importante no plamejamento de um
Leia maisUML: Diagrama de Casos de Uso, Diagrama de Classes
UML: Diagrama de Casos de Uso, Diagrama de Classes Diagrama de Casos de Uso O modelo de casos de uso visa responder a pergunta: Que usos (funcionalidades) o sistema terá? ou Para que aplicações o sistema
Leia maisRequisitos do usuário, do sistema e do software [Sommerville, 2004]
Requisitos Objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema Condição ou capacidade necessária que o software deve possuir para que
Leia maisAtividades da Engenharia de Software ATIVIDADES DE APOIO. Atividades da Engenharia de Software. Atividades da Engenharia de Software
Módulo 1 SCE186-ENGENHARIA DE SOFTWARE Profª Rosely Sanches rsanches@icmc.usp.br CONSTRUÇÃO Planejamento do Codificação Teste MANUTENÇÃO Modificação 2003 2 Planejamento do Gerenciamento CONSTRUÇÃO de Codificação
Leia maisIntrodução ao RUP Rational Unified Process. por Denize Terra Pimenta Outubro/2004
Introdução ao RUP Rational Unified Process por Denize Terra Pimenta Outubro/2004 1 Contexto Não é suficiente apenas a presença de desenvolvedores altamente treinados: Precisamos de uma linguagem para a
Leia maisProfessor X Software Educativo: a difícil tarefa de escolher
Professor X Software Educativo: a difícil tarefa de escolher Maria de Fátima Costa de Souza 1,*, Mauro C. Pequeno 1, José Aires C. Filho 2 1 Departamento de Computação Universidade Federal do Ceará (UFC)
Leia maisMetodologia de Desenvolvimento de Software. Prof. M.Sc. Sílvio Bacalá Jr
Metodologia de Desenvolvimento de Software Prof. M.Sc. Sílvio Bacalá Jr Objetivos Discutir aspectos de Engenharia de Software Aplicar um método de desenvolvimento para especificação e projeto de software
Leia maisProposta de Utilização de FDD e APF para Melhoria do Processo de Software
Proposta de Utilização de FDD e APF para Melhoria do Processo de Software Cristiane Ribeiro da Cunha, Cristina D Ornellas Filipakis Curso de Sistemas de Informação Centro Universitário Luterano de Palmas
Leia mais3. Fase de Planejamento dos Ciclos de Construção do Software
3. Fase de Planejamento dos Ciclos de Construção do Software A tarefa de planejar os ciclos de construção do software pode partir de diretrizes básicas. Estas diretrizes visam orientar que os ciclos de
Leia maisTERMO DE REFERÊNCIA. Contrato por Produto Nacional
TERMO DE REFERÊNCIA Contrato por Produto Nacional 1. Antecedentes e Justificativa O Projeto de Assistência à Implementação do Programa de Apoio à Agenda de Crescimento Econômico Equitativo e Sustentável
Leia maisSISTEMAS DE INFORMAÇÃO GERENCIAIS
SISTEMAS DE INFORMAÇÃO GERENCIAIS Aluno: Luiza Cavalcanti Marques Orientador: Silvio Hamacher Introdução A modelagem e a utilização de bancos de dados em atividades gerenciais têm sofrido um aumento significativo
Leia maisProcessos de Software
Processos de Software Prof. Márcio Lopes Cornélio Slides originais elaborados por Ian Sommerville O autor permite o uso e a modificação dos slides para fins didáticos O processo de Um conjunto estruturado
Leia maisResolução da lista de exercícios de casos de uso
Resolução da lista de exercícios de casos de uso 1. Explique quando são criados e utilizados os diagramas de casos de uso no processo de desenvolvimento incremental e iterativo. Na fase de concepção se
Leia maisCasos de uso Objetivo:
Casos de uso Objetivo: Auxiliar a comunicação entre os analistas e o cliente. Descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. O cliente deve ver no diagrama de
Leia maisDimensionamento de Sistemas na REDEPRO Paulo Roberto de Miranda Samarani
4º Seminário REDEPRO Julho/2006 1 Dimensionamento de Sistemas na REDEPRO Paulo Roberto de Miranda Samarani samarani@procergs.rs.gov.br 2 Agenda Contextualização Processo de medição Estimativas de tamanho
Leia maisProf. Antonio Almeida de Barros Jr. Prof. Antonio Almeida de Barros Junior
Prof. Antonio Almeida de Barros Jr. Introdução Dados Informações Banco de Dados Conceitos Básicos em Bancos de Dados Definição BD - Banco de Dados SGBD - Sistema de Gerenciamento de BD Programa de Aplicação
Leia maisUnidade II MODELAGEM DE PROCESSOS
Unidade II 3 MODELAGEM DE SISTEMAS 1 20 A fase de desenvolvimento de um novo sistema de informação (Quadro 2) é um momento complexo que exige um significativo esforço no sentido de agregar recursos que
Leia maisGerenciamento de Requisitos Gerenciamento de Requisitos
Gerenciamento de Requisitos Objetivos da disciplina Descrever o processo de Gerenciamento e Engenharia de Requisitos para projetos Treinar alunos no Gerenciamento de Requisitos Apresentar estudos de caso
Leia maisIntrodução Ciclo de vida tradicional de desenvolvimento Prototipagem Pacotes de software Desenvolvimento de 4ª geração Terceirização
Prof. Ricardo José Pfitscher Material elaborado com base em: José Luiz Mendes Gerson Volney Lagemann Introdução Ciclo de vida tradicional de desenvolvimento Prototipagem Pacotes de software Desenvolvimento
Leia maisPontos de Função. André Chastel Lima Andréia Ferreira Pinto Diego Souza Campos. Engenharia de Software Mestrado Ciência da Computação - UFMS
Pontos de Função André Chastel Lima Andréia Ferreira Pinto Diego Souza Campos Engenharia de Software Mestrado Ciência da Computação - UFMS Roteiro Introdução Métricas de Projeto Análise de Pontos de Função
Leia maisBoas práticas, vedações e orientações para contratação de serviços de desenvolvimento e manutenção de software (Fábrica de Software)
MINISTÉRIO DO PLANEJAMENTO, ORÇAMENTO E GESTÃO Secretaria de Tecnologia da Informação Departamento de Infraestrutura e Serviços de Tecnologia da Informação Departamento de Governança e Sistemas de Informação
Leia maisProfessor: Curso: Disciplina: Aula 4-5-6
Professor: Curso: Disciplina: Aula 4-5-6 Turma: Esp. Marcos Morais de Sousa Sistemas de informação Engenharia de Software I Engenharia de Requisitos 03º semestre 1 Engenharia de Requisitos Prof. Marcos
Leia maisTÉCNICAS DE PROGRAMAÇÃO
TÉCNICAS DE PROGRAMAÇÃO (Adaptado do texto do prof. Adair Santa Catarina) ALGORITMOS COM QUALIDADE MÁXIMAS DE PROGRAMAÇÃO 1) Algoritmos devem ser feitos para serem lidos por seres humanos: Tenha em mente
Leia maisMetadados. 1. Introdução. 2. O que são Metadados? 3. O Valor dos Metadados
1. Introdução O governo é um dos maiores detentores de recursos da informação. Consequentemente, tem sido o responsável por assegurar que tais recursos estejam agregando valor para os cidadãos, as empresas,
Leia maisAmbiente de Simulação Virtual para Capacitação e Treinamento na Manutenção de. Disjuntores de Subestações de Energia Elétrica,
Ambiente de Simulação Virtual para Capacitação e Treinamento na Manutenção de Disjuntores de Subestações de Energia Elétrica Prof. Dr. Lineu Belico dos Reis EPUSP Resumo: O informe técnico apresenta a
Leia maisMINISTÉRIO DO PLANEJAMENTO, ORÇAMENTO E GESTÃO DIRETORIA DE ADMINISTRAÇÃO COORDENAÇÃO-GERAL DE AQUISIÇÕES
MINISTÉRIO DO PLANEJAMENTO, ORÇAMENTO E GESTÃO DIRETORIA DE ADMINISTRAÇÃO COORDENAÇÃO-GERAL DE AQUISIÇÕES BANCO INTERAMERICANO DE DESENVOLVIMENTO REPRESENTAÇÃO NO BRASIL SOLICITAÇÃO DE MANIFESTAÇÃO DE
Leia maisDESENVOLVENDO O SISTEMA
DESENVOLVENDO O SISTEMA Declaração da Necessidade O primeiro passo do processo de análise de sistema envolve a identificação da necessidade [Pressman-95]. Normalmente o analista reúne-se com o usuário
Leia maisMODELAGEM DE SISTEMAS
MODELAGEM DE SISTEMAS Diagramas de Casos de Uso Profa. Rosemary Melo Diagrama de Casos de Uso Modelagem de Sistemas Apresenta uma visão externa geral das funções ou serviços que o sistema deverá oferecer
Leia maisTópicos da Aula. Que é são requisitos? Tipos de Requisitos. Requisitos Funcionais. Classificação de Requisitos. Requisitos de Software.
Engenharia de Software Aula 06 Tópicos da Aula Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo dcc603@gmail.com 26 Março 2012 Funcionais e não funcionais De usuário e do Engenharia de Estudo
Leia maisRoteiro SENAC. Análise de Riscos. Planejamento do Gerenciamento de Riscos. Planejamento do Gerenciamento de Riscos
SENAC Pós-Graduação em Segurança da Informação: Análise de Riscos Parte 2 Leandro Loss, Dr. Eng. loss@gsigma.ufsc.br http://www.gsigma.ufsc.br/~loss Roteiro Introdução Conceitos básicos Riscos Tipos de
Leia maisESCLARECIMENTO V PREGÃO 31/2015
MEC Ministério da Educação Uasg 150002 ESCLARECIMENTO V PREGÃO 31/2015 PREGÃO ELETRÔNICO Nº 31/2015 Processo nº 23000.010097/2015-59 PERGUNTA 1: Conforme o item 2 do edital o mesmo cita que o Ministério
Leia mais18º Congresso de Iniciação Científica IMPLEMENTAÇÃO DE UM MODELO DE TESTE DE APLICAÇÕES WEB
18º Congresso de Iniciação Científica IMPLEMENTAÇÃO DE UM MODELO DE TESTE DE APLICAÇÕES WEB Autor(es) HARLEI MIGUEL DE ARRUDA LEITE Orientador(es) PLÍNIO ROBERTO SOUZA VILELA Apoio Financeiro PIBIC/CNPQ
Leia maisPROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 03
PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 03 RELATÓRIO TÉCNICO CONCLUSIVO
Leia maisESTADO DE PERNAMBUCO TRIBUNAL DE CONTAS
OFÍCIO CIRCULAR COLI Nº 027/2015 Recife, 24 de agosto de 2015. Senhor Licitante, Em resposta aos questionamentos formulados pela empresa FATTO Consultoria e Sistemas a respeito Processo Licitatório nº
Leia maisImplantação de um Processo de Medições de Software
Departamento de Informática BFPUG Brazilian Function Point Users Group Implantação de um Processo de Medições de Software Claudia Hazan, MSc., CFPS claudinhah@yahoo.com Agenda Introdução Processo de Medições
Leia mais3 Qualidade de Software
3 Qualidade de Software Este capítulo tem como objetivo esclarecer conceitos relacionados à qualidade de software; conceitos estes muito importantes para o entendimento do presente trabalho, cujo objetivo
Leia maisUtilizando os Diagramas da UML (Linguagem Unificada de Modelagem) para desenvolver aplicação em JSF
Utilizando os Diagramas da UML (Linguagem Unificada de Modelagem) para desenvolver aplicação em JSF Ben-Hur de Sousa Lopes¹, Jaime William Dias¹ ¹Universidade Paranaense (UNIPAR) Paranavaí Paraná Brasil
Leia maisGerenciamento de Projetos Modulo II Clico de Vida e Organização
Gerenciamento de Projetos Modulo II Clico de Vida e Organização Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos
Leia maisCAPABILITY MATURITY MODEL FOR SOFTWARE. Eduardo Mayer Fagundes e-mail: eduardo@efagundes.com
CAPABILITY MATURITY MODEL FOR SOFTWARE Eduardo Mayer Fagundes e-mail: eduardo@efagundes.com 1. Introdução Após décadas de incontáveis promessas sobre como aumentar à produtividade e qualidade de software,
Leia maisWhite-box test: Também conhecido como teste estrutural, tem por objetivo validar os dados derivados das funções do sistema.
22. Planejamento, Especificação e Execução dos Testes A implantação de um sistema de boa qualidade, dentro de um prazo específico, pode ser seriamente prejudicada caso uma etapa extremamente importante
Leia maisProcessos de gerenciamento de projetos em um projeto
Processos de gerenciamento de projetos em um projeto O gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de cumprir seus requisitos.
Leia maisCurso de Especialização em Tecnologia da Informação. Engenharia de Software
Universidade Federal de Pernambuco Departamento de Informática Curso de Especialização em Tecnologia da Informação Engenharia de Software Questionário para Discussão e Reflexão Aluna: Danielle Novaes de
Leia maisCurso: Engenharia de Software com Ênfase em Padrões de Software (UECE Universidade Estadual do Ceará) RUP
Conceitos RUP RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um processo de Engenharia de software criado pela Rational Software Corporation(a qual foi incorporada pela
Leia maisPROVA DISCURSIVA (P )
PROVA DISCURSIVA (P ) 2 Nesta prova que vale dez pontos, faça o que se pede, usando os espaços indicados no presente caderno para rascunho. Em seguida, transcreva os textos para as folhas de TEXTOS DEFINITIVOS
Leia maisEstimação do esforço de desenvolvimento de um sistema de software com Use Case Points: Análise de um Caso de Aplicação CAPSI 2012
Estimação do esforço de desenvolvimento de um sistema de software com Use Case Points: Análise de um Caso de Aplicação CAPSI 2012 André Sousa 1, Ricardo J. Machado 2, Pedro Ribeiro 3. 1) Departamento de
Leia maisEngenharia de Software Tema da Aula Definição e Especificação de Requisitos I - Conceitos. Exercício
Tema da Aula Definição e Especificação de Requisitos I - Conceitos Prof. Cristiano R R Portella portella@widesoft.com.br Exercício Em grupo de 4 alunos (2 desenvolvedores e 2 usuários), simular uma reunião
Leia mais15/03/2010. Análise por pontos de função. Análise por Pontos de Função. Componentes dos Pontos de Função. Componentes dos Pontos de Função
Análise por pontos de função Análise por Pontos de Função Referência: Manual de práticas de contagem IFPUG Versão 4.2.1 Técnica que permite medir a funcionalidade de um software ou aplicativo, sob a visão
Leia maisMauricio Barbosa e Castro
Mauricio Barbosa e Castro A interação homem-computador está muito relacionada com o processo de projeto, provendo soluções que levam em consideração todas as restrições e requisitos. O aspecto de projeto
Leia maisConceitos Básicos de Rede. Um manual para empresas com até 75 computadores
Conceitos Básicos de Rede Um manual para empresas com até 75 computadores 1 Conceitos Básicos de Rede Conceitos Básicos de Rede... 1 A Função de Uma Rede... 1 Introdução às Redes... 2 Mais Conceitos Básicos
Leia maisRequisitos de Software
Requisitos de Software (Cap 6 - Sommerville) UNIVERSIDADE FEDERAL DE ALAGOAS Curso de Ciência da Computação Engenharia de Software I Prof. Rômulo Nunes de Oliveira Requisitos funcionais e não funcionais
Leia maisEngenharia de Software II
Engenharia de Software II Aula 28 Revisão para a Prova 2 http://www.ic.uff.br/~bianca/engsoft2/ Aula 28-28/07/2006 1 Matéria para a Prova 2 Gestão de projetos de software Conceitos (Cap. 21) Métricas (Cap.
Leia maisagility made possible
RESUMO DA SOLUÇÃO Utilitário ConfigXpress no CA IdentityMinder a minha solução de gerenciamento de identidades pode se adaptar rapidamente aos requisitos e processos de negócio em constante mudança? agility
Leia maisUNIÃO EDUCACIONAL DO NORTE UNINORTE AUTOR (ES) AUTOR (ES) TÍTULO DO PROJETO
UNIÃO EDUCACIONAL DO NORTE UNINORTE AUTOR (ES) AUTOR (ES) TÍTULO DO PROJETO RIO BRANCO Ano AUTOR (ES) AUTOR (ES) TÍTULO DO PROJETO Pré-Projeto de Pesquisa apresentado como exigência no processo de seleção
Leia maisO Processo Unificado
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA O Processo Unificado 879SCC Projeto e Desenvolvimento de Sistemas
Leia maisRelatório de Inteligência Emocional. Nome: Jane Smith
Relatório de Inteligência Emocional Nome: Jane Smith Data: 8 maio 2008 Relatório de Inteligência Emocional (IE) Este relatório descreve as competências-chave para o da Inteligência Emocional (IE), que
Leia maisPerguntas. Que todo usuário deveria fazer antes de comprar um software CAD de baixo custo. Por Robert Green, proprietário da Robert Green Consulting
Perguntas Que todo usuário deveria fazer antes de comprar um software CAD de baixo custo Por Robert Green, proprietário da Robert Green Consulting 5 perguntas que todo usuário deveria fazer antes de comprar
Leia maisFeature-Driven Development
FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por
Leia mais1. Modelagem de Sistemas 1.1. Os Desenvolvedores de Sistemas podem Escolher entre Quatro Caminhos
Sumário Modelagem de Processos Módulo 4 1. Modelagem de Sistemas 1.1. Os Desenvolvedores de Sistemas podem Escolher entre Quatro Caminhos M. Sc. Luiz Alberto lasf.bel@gmail.com Modelagem de Sistemas MP
Leia maisCom metodologias de desenvolvimento
Sociedade demanda grande quantidade de sistemas/aplicações software complexo, sistemas distribuídos, heterogêneos requisitos mutantes (todo ano, todo mês, todo dia) Mas, infelizmente, não há gente suficiente
Leia maisFase de Análise de Requisitos. Engenharia de Software ANÁLISE DE REQUISITOS. Tipos de Requisitos. Tipos de requisitos. Tipos de requisitos
Engenharia de Software Fase de Análise de Requisitos Engenharia de Sistemas de Computador ANÁLISE DE REQUISITOS ANÁLISE DE REQUISITOS Projeto de Software 1 2 Tipos de Requisitos 3 4 Tipos de requisitos
Leia maisMedição tridimensional
A U A UL LA Medição tridimensional Um problema O controle de qualidade dimensional é tão antigo quanto a própria indústria, mas somente nas últimas décadas vem ocupando a importante posição que lhe cabe.
Leia maisGuia de utilização da notação BPMN
1 Guia de utilização da notação BPMN Agosto 2011 2 Sumário de Informações do Documento Documento: Guia_de_utilização_da_notação_BPMN.odt Número de páginas: 31 Versão Data Mudanças Autor 1.0 15/09/11 Criação
Leia mais5. Contagem de Pontos de Função no Desenvolvimento de Software utilizando Métodos Ágeis
5. Contagem de Pontos de Função no Desenvolvimento de Software utilizando Métodos Ágeis Este capítulo descreve orientações, sobre a utilização da métrica Ponto de Função, para medição e remuneração de
Leia maisMicro Mídia Informática Fevereiro/2009
Micro Mídia Informática Fevereiro/2009 1 UML Introdução Fases de Desenvolvimento Notação Visões Análise de Requisitos Casos de Uso StarUML Criando Casos de Uso Orientação a Objetos Diagrama de Classes
Leia maisAbordagem simples aos modos de falha com recurso a um software de organização e gestão da manutenção
Abordagem simples aos modos de falha com recurso a um software de organização e gestão da manutenção Marcelo Batista (1), José Fernandes (1) e Alexandre Veríssimo (1) mbatista@manwinwin.com; jcasimiro@navaltik.com;
Leia maisClassificação de Sistemas: Sistemas Empresariais
Universidade do Contestado Campus Concórdia Curso de Ciências Contábeis Prof.: Maico Petry Classificação de Sistemas: Sistemas Empresariais DISCIPLINA: Sistemas de Informação Gerencial O QI da empresa
Leia maisEngenharia de Software. Tema 1. Introdução à Engenharia de Software Profa. Susana M. Iglesias
Engenharia de Software Tema 1. Introdução à Engenharia de Software Profa. Susana M. Iglesias Sistemas Computacionais Automatiza ou apóia a realização de atividades humanas (processamento da informação)
Leia maisO Gerenciamento de Documentos Analógico/Digital
Tipos de GED: Document imaging Document management Document Imaging / Document Management O Gerenciamento de Documentos Analógico/Digital Mundo analógico Criação Revisão Processamento Arquivo Mundo digital
Leia maisAnálise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO)
Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO) Parte: 1 Prof. Cristóvão Cunha Objetivos de aprendizagem
Leia maisESTUDO DE VIABILIDADE. Santander, Victor - Unioeste Aula de Luiz Eduardo Guarino de Vasconcelos
ESTUDO DE VIABILIDADE Santander, Victor - Unioeste Aula de Luiz Eduardo Guarino de Vasconcelos Objetivos O que é um estudo de viabilidade? O que estudar e concluir? Benefícios e custos Análise de Custo/Benefício
Leia mais3.1 Definições Uma classe é a descrição de um tipo de objeto.
Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Classes Autoria:Aristófanes Corrêa Silva Adaptação:
Leia maisEngenharia de Software II
Engenharia de Software II Aula 14 Revisão http://www.ic.uff.br/~bianca/engsoft2/ Aula 14-07/05/2006 1 Processo de Software Qual é a diferença entre uma atividade de arcabouço e uma atividade guarda chuva?
Leia maisGuia de Contagem. Pontos de Função ANEXO XI. Última atualização em: 11/06/2015
ANEXO XI Pontos de Função Guia de Contagem Última atualização em: 11/06/2015 Praça dos Açorianos, s/n - CEP 90010-340 Porto Alegre, RS 0 -XX - 51-3210-3100 http:\\www.procergs.com.br Sumário 1. Apresentação...
Leia maisGestão do Risco e da Qualidade no Desenvolvimento de Software
Gestão do Risco e da Qualidade no Desenvolvimento de Software Questionário Taxinómico do Software Engineering Institute António Miguel 1. Constrangimentos do Projecto Os Constrangimentos ao Projecto referem-se
Leia maisCapítulo 2 Objetivos e benefícios de um Sistema de Informação
Capítulo 2 Objetivos e benefícios de um Sistema de Informação 2.1 OBJETIVO, FOCO E CARACTERÍSTICAS DOS SISTEMAS DE INFORMAÇÃO. Os Sistemas de Informação, independentemente de seu nível ou classificação,
Leia mais