Curso de Pós-graduação Lato-Sensu em Análise,

Curso de Pós-graduação Lato-Sensu em Análise,
Projeto e Gerência de Sistemas de Informação Disciplina: Modelagem de Negócio e Gerência de Requisitos de Software Professora Giselle Teixeira de Almeida 07/05/2010

SUMÁRIO Conceitos Gerais Sobre Requisitos; Requisitos de Software;
Análise e Especificação de Requisitos; Técnicas para Verificação de Requisitos; Técnicas para Gerência de Requisitos ao Longo do Projeto; Atividades Propostas. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

PARTE I REQUISITOS DE SOFTWARE: Definição e Conceitos Gerais
Tipos de Requisitos Documentos de Requisitos Levantamento de Requisitos Importância da Especificação de Requisitos Critérios de Qualidade para Especificação de Requisitos Técnicas para Elicitação de Requisitos Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

REQUISITOS DE SOFTWARE Definição e conceitos gerais:
Necessidades dos futuros usuários do sistema a ser desenvolvido. Uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo. Uma condição ou capacidade que deve ser alcançada ou estar presente em um sistema ou componente deste para satisfazer um contrato, padrão, especificação ou outros documentos formalmente impostos (Maciaszek, 2000). Definem o problema a ser resolvido pelo sistema de software, não descrevem o software que resolve o problema. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

REQUISITOS DE SOFTWARE
Normalmente são identificados a partir de um domínio (área de conhecimento ou de atividade específica caracterizada por um conjunto de conceitos e de terminologia compreendidos por especialista nessa área denominado especialista do domínio). Um especialista do domínio é uma pessoa que tem familiaridade com o domínio do negócio, mas não necessariamente com o desenvolvimento de software. Frequentemente, esses especialistas são os futuros usuários do software em desenvolvimento. No contexto de software, um domínio corresponde à parte do mundo real que é relevante, quais informações e processos desse domínio precisam ser incluídos no sistema a ser desenvolvido. O domínio também é chamado de domínio do problema ou domínio do negócio. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

REQUISITOS DE SOFTWARE Tipos de Requisitos:
Os requisitos de software podem ser dos seguintes tipos: funcionais; não-funcionais; normativos. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

REQUISITOS DE SOFTWARE Requisitos Funcionais:
Definem as funcionalidades do sistema. Devem refletir as necessidades dos usuários. Definem o problema a ser resolvido pelo sistema. Descrevem uma interação entre o sistema e seu ambiente. Funcionalidades do sistema conforme percebidas pelos atores externos (usuários). Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

REQUISITOS DE SOFTWARE Exemplos:
O sistema deve permitir que cada professor realize o lançamento de notas das turmas nas quais lecionou. O sistema deve permitir que um aluno realize a sua matrícula nas disciplinas oferecidas em um semestre letivo. O coordenador deve poder obter o número de aprovações, reprovações, trancamentos em cada disciplina oferecida em um determinado período. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

REQUISITOS DE SOFTWARE Requisitos Não-Funcionais (Restrições):
Declaram as características de qualidade que o sistema deve possuir e que estão relacionadas às suas funcionalidades. Descrevem uma restrição para o sistema que limita as possíveis escolhas de solução para o problema. Normalmente conhecidos como requisitos de qualidade de uma aplicação. Devem ser detalhados em uma seção da documentação do software. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

REQUISITOS DE SOFTWARE Exemplos:
confiabilidade: medidas quantitativas da confiabilidade do sistema. Ex.: tempo médio entre falhas, recuperação de falhas ou quantidade de erros por milhares de linhas de código-fonte. desempenho: requisitos que definem tempos de resposta esperados para as funcionalidades do sistema. portabilidade: restrições sobre plataformas de hardware e software nas quais o sistema será implantado e sobre o grau de facilidade de transportar o sistema para outras plataformas. segurança: limitações sobre a segurança do sistema em relação a acessos não-autorizados. usabilidade: requisitos que se relacionam ou afetam a usabilidade do sistema. Exemplos incluem requisitos sobre a facilidade de uso e a necessidade ou não de treinamento dos usuários. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

REQUISITOS DE SOFTWARE Requisitos Normativos:
Declaração de restrições impostas sobre o desenvolvimento do sistema. Estas restrições definem, por exemplo, a adequação a custos e prazos, a plataforma tecnológica, aspectos legais (licenciamento), limitações sobre a interface com o usuário, componentes de hardware e software a serem adquiridos, eventuais necessidades de comunicação do novo sistema com sistemas legados, etc. Estas restrições também podem corresponder a regras de negócio (restrições ou normas ou políticas de funcionamento específicas do domínio do problema que influenciarão de um modo ou de outro no desenvolvimento do software). Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

REQUISITOS DE SOFTWARE Documentos de Requisitos:
É o produto do levantamento de requisitos. Declara e descreve todos os requisitos de um software, usualmente escrito em uma notação informal (linguagem natural), em um formato ou linguagem inteligível pelo cliente, é a Descrição de Requisitos. O documento que especifica estes requisitos, utilizando um formato mais apropriado para a implementação, é a Especificação de Requisitos. Geralmente, ambos os documentos (descrição e especificação de requisitos) descrevem o que o software proposto deve fazer sem se preocupar em como deve ser feito. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Não deve conter informações sobre soluções técnicas que serão adotadas para desenvolver o sistema. Sistemas serão avaliados pelo seu grau de conformidade aos requisitos, não importa quão complexa a solução tecnológica tenha sido. Serve como um termo de consenso inicial entre a equipe técnica (desenvolvedores) e o cliente. Constitui a base para as atividades subsequentes do desenvolvimento do sistema e fornece um ponto de referência para qualquer validação futura do software construído. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Uma das formas de se medir a qualidade de um sistema de software é pela sua utilidade. Um sistema será útil para seus usuários se atender aos requisitos definidos e se estes, por sua vez, refletirem as necessidades dos usuários. Portanto, no documento, os requisitos devem ser expressos de uma maneira tal que eles possam ser verificados e comunicados a leitores técnicos e não-técnicos. A equipe técnica deve entender o documento de requisitos de tal forma que permita obter soluções técnicas apropriadas. Clientes devem entender o documento de requisitos para que possam priorizar o desenvolvimento dos requisitos, conforme as necessidades das organizações em que trabalham. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Estabelece o escopo do sistema (o que faz parte e o que não faz parte do sistema). O escopo de um sistema muda muitas vezes durante o seu desenvolvimento. A mudança no escopo obriga que clientes e desenvolvedores tenham parâmetros para decidir em que medida os recursos de tempo e financeiros devem mudar. Contudo, o planejamento inicial do projeto deve se basear no escopo inicial. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Os requisitos são voláteis, podem sofrer modificações durante o desenvolvimento do sistema. Atualmente as organizações precisam se adaptar a mudanças cada vez mais rápidas. Durante o período de desenvolvimento, vários aspectos podem mudar: tecnologias utilizadas, expectativas dos usuários, regras de negócio, etc. A medida que novos requisitos são detectados ou os existentes mudem, os desenvolvedores devem verificar cuidadosamente o impacto destas mudanças no sistema. E os clientes devem decidir se estas devem ser consideradas no desenvolvimento, uma vez que influenciam o cronograma previsto e os recursos financeiros alocados. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

É praticamente impossível pensar em todos os detalhes a princípio. Além disso, quando o sistema é posto em produção e operação, os usuários descobrirão requisitos nos quais não haviam pensado inicialmente. Resumindo, os requisitos de um sistema complexo inevitavelmente mudarão durante o seu desenvolvimento. “No desenvolvimento de software, a existência de requisitos voláteis corresponde mais à regra do que à exceção”. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

É desejável que o documento de requisitos tenha seus requisitos ordenados pelos usuários em função do seu grau de prioridade (que adição de valor a presença deste requisito no sistema traz para o usuário?). As prioridades atribuídos aos requisitos, permitem ao gerente de projeto tomar decisões a respeito do momento no qual cada requisitos deve ser considerado durante o desenvolvimento do sistema. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Levantamento de requisitos (definição e considerações gerais) Levantamento de requisitos = elicitação de requisitos = análise de requisitos = projeto lógico = fase de definição e compreensão do problema; Etapa de compreensão do problema aplicada ao desenvolvimento de software; Seu principal objetivo é que usuários e desenvolvedores tenham a mesma visão do problema a ser resolvido; Desenvolvedores juntamente com clientes tentam levantar e definir os requisitos do sistema a ser desenvolvido; Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

O envolvimento do cliente desde o início do processo de desenvolvimento ajuda a assegurar que o produto desenvolvido realmente atenda às necessidades identificadas. O enfoque prioritário é responder claramente à questão: “o que o usuário necessita do novo sistema?” A equipe de desenvolvimento tenta entender o domínio que deve ser automatizado pelo sistema de software; Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Compreende também um estudo exploratório das necessidades dos usuários e da situação do sistema atual (se este existir). Para isto, várias técnicas são empregadas, tais como: leitura de obras de referência e livros-texto, observação do ambiente do usuário, realização de entrevistas com os usuários, entrevistas com especialistas do domínio, reutilização de análises anteriores, comparação com sistemas preexistentes do mesmo domínio de negócio, etc. O artefato resultante é o Documento de Requisitos (Descrição de Requisitos + Especificação de Requisitos). Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

É a etapa mais importante em termos de retorno em investimentos feitos para o projeto de desenvolvimento. Muitos sistemas foram abandonados ou nem chegaram a uso porque os membros da equipe não dispensaram tempo suficiente para compreender as necessidades do cliente em relação ao novo sistema. É fato que, normalmente, um sistema de informações é utilizado para automatizar processos de negócio de uma organização. Portanto, esses processos devem ser bem compreendidos antes da construção do sistema. Um estudo baseado em sistemas feitos em 1997 feito por Carper Jones mostrou que os custos resultantes da má realização dessa etapa de entendimento podem ser 200 vezes maiores que o realmente necessário. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

REQUISITOS DE SOFTWARE Importância da Especificação de Requisitos:
Quanto mais tarde um erro é detectado, maior é o custo de sua correção: FASE CUSTO RELATIVO Requisitos 0,1 Projeto 0,2 Codificação 1 Testes de Unidades 2 Testes de Aceitação 5 Manutenção 20 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Uma Especificação de Requisitos é importante porque: estabelece uma base de concordância entre o cliente e o fornecedor sobre o que o software fará. mapeia o problema. uma especificação de requisitos de alta qualidade é um pré-requisito para um software de alta qualidade. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Evite focar na corretude como o único critério de qualidade!!!
REQUISITOS DE SOFTWARE Critérios de Qualidade para Especificação de Requisitos: Corretude: reflete fielmente a realidade e necessidades dos usuários e cliente; Consistência: informações em diferentes locais não são contraditórias; Clareza: sem ambigüidades, possibilita sua verificação; Completude: não há nenhuma informação necessária ou importante para os usuários e cliente que esteja omitida; Coesão: descreve exatamente o que é necessário para o cliente, sem acrescentar informações desnecessárias. Evite focar na corretude como o único critério de qualidade!!! Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

REQUISITOS DE SOFTWARE Técnicas para Elicitação de Requisitos:
Entrevistas; Sessões de JAD (ou FAST); Reuniões de Grupo; Brainstorm; Análise de Documentos; Questionário; Observações; Sistemas Legados; Casos de Uso, etc. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

PARTE II ANÁLISE DE REQUISITOS: Definição e Conceitos Gerais
Validação dos Modelos Verificação dos Modelos Análise do Domínio X Análise da Aplicação Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ANÁLISE DE REQUISITOS Definição e Considerações Gerais:
O levantamento de requisitos e a análise de requisitos em conjunto recebem o nome de engenharia de requisitos (Wilson de Pádua, 2003). O termo “análise” significa decompor o sistema em seus componentes e estudar a interação entre estes com o objeto de entender melhor o funcionamento do sistema. No contexto de software, esta é a etapa em que os analistas realizam um estudo detalhado dos requisitos levantados na etapa anterior (levantamento de requisitos) e constroem os modelos que representam o sistema a ser desenvolvido. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ANÁLISE DE REQUISITOS A análise também não leva em conta o ambiente tecnológico a ser utilizado. O objetivo é construir a melhor estratégia de solução para o problema sem se preocupar com detalhes da tecnologia a ser utilizada. É necessário saber o que o sistema deve fazer para, posteriormente, definir como esse sistema irá fazê-lo. Os modelos construídos na fase de análise devem ser cuidadosamente validados e verificados. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ANÁLISE DE REQUISITOS Validação dos modelos
O objetivo da validação é assegurar que as necessidades do cliente estão sendo atendidas pelo sistema. Ex.: será que o software correto está sendo construído? A especificação construída para o software deve ser correta, consistente, completa, realista e sem ambiguidades. Os analistas apresentam os modelos criados para que os usuários façam a validação, isto é, atestem que entenderam os modelos e que estes refletem suas necessidades. Os modelos devem ser bem definidos, erros no levantamento de requisitos implica na construção de modelos errados, ocasionando conflitos e impactos nos custos e prazos. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ANÁLISE DE REQUISITOS Verificação dos modelos
O objetivo da verificação é analisar se os modelos construídos estão em conformidade com os requisitos definidos. Ex.: será que o software está sendo construído corretamente? A exatidão de cada modelo em separado é analisada e posteriormente a consistência entre os modelos. Obs.: diferente da validação (atividade de análise), a verificação é uma etapa típica da fase de projeto. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ANÁLISE DE REQUISITOS Análise do Domínio X Análise da Aplicação
De acordo com alguns autores, a fase de análise pode ser subdividida em: análise do domínio (ou análise do negócio); análise da aplicação. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ANÁLISE DE REQUISITOS Análise do Domínio ou do Negócio
Modela objetos do mundo real que serão processados pela aplicação. Ex.: em um sistema de controle acadêmico: aluno, professor, disciplina, turma, sala de aula, etc. Os analistas devem interagir com especialistas do domínio, pois os objetos identificados correspondem a conceitos com os quais estes profissionais lidam diariamente. Modela as regras de negócio e os processos de negócio realizados pela organização. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ANÁLISE DE REQUISITOS Análise da Aplicação
Identifica objetos de análise que normalmente não fazem sentido para os especialistas de domínio, porém necessários para suprir as funcionalidades do sistema. Um objeto de aplicação é qualquer objeto necessário para que o sistema possa se comunicar com seu ambiente. Têm a ver com aspectos computacionais de alto nível. Só têm sentido no contexto de software, diferentemente dos objetos de domínio. Ex.: tela de inscrição em disciplina é um objeto componente de uma aplicação de controle de uma instituição de ensino. Apenas identifica objetos da aplicação, não os detalha, nem está interessada na implementação dos mesmos (fase de projeto). Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ANÁLISE DE REQUISITOS Separação do domínio da aplicação
Um dos motivos para separação da análise do domínio (objetos do domínio) e análise da aplicação é o reuso. Modelar separadamente o domínio dos aspectos específicos da aplicação permite que os componentes resultantes dessa modelagem tenham maior potencial de reusabilidade no desenvolvimento de aplicação dentro do mesmo domínio de problema. Principais diagramas da UML para análise: diagrama de casos de uso, diagrama de classes, diagrama de atividades, diagrama de estados, diagrama de interação. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ATIVIDADES PROPOSTAS:
PARTE III ATIVIDADES PROPOSTAS: Elicitação de Requisitos Estudo de Caso – Sistema de Controle Acadêmico Estudo de Caso Particular Pesquisa sobre Ferramentas de Gerência de Requisitos Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ATIVIDADES PROPOSTAS Elicitação de Requisitos
Baseado em sua experiência, tente escrever um documento de requisitos para um Sistema de Controle Acadêmico - SCA. Esse sistema deve controlar as inscrições de alunos em disciplinas, a distribuição das turmas, salas, professores, etc. Deve permitir também o controle de notas atribuídas aos alunos em diversas disciplinas. Você pode se basear na forma de funcionamento da sua própria universidade. Com base em sua experiência, tente escrever um documento de requisitos para um sistema de software do seu cotidiano (por exemplo, um sistema para automatizar algum processo na empresa em que trabalha, aproveitando o conhecimento do domínio do negócio que você tiver). Durante a elaboração desse documento, resista o máximo possível à tentação de considerar detalhes técnicos e de implementação. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA
Descrição da situação: O estudo de caso é sobre uma universidade que precisa de uma aplicação para controlar alguns processos acadêmicos, como inscrições em disciplinas, lançamentos de notas, alocação de recursos para turmas, etc. Após o levantamento de requisitos inicial desse sistema, os analistas chegaram à seguinte lista de requisitos funcionais: RF1. O Sistema deve permitir que alunos visualizem as notas obtidas por semestre letivo. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

RF2. O Sistema deve permitir o lançamento das notas das disciplinas lecionadas em um semestre letivo e controlar os prazos e atrasos neste lançamento. RF3. O Sistema deve manter informações cadastrais sobre disciplinas no currículo escolar. RF4. O Sistema deve permitir a abertura de turmas para uma disciplina, assim como a definição de salas e laboratórios a serem utilizados e dos horários e dias da semana em que haverá aulas de tal turma. RF5. O Sistema deve permitir que os alunos realizem a inscrição em disciplinas de um semestre letivo. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

RF6. O Sistema deve permitir o controle do andamento das inscrições em disciplinas feitas por alunos. RF7. O Sistema deve se comunicar com o Sistema de Recursos Humanos para obter dados cadastrais sobre os professores. RF8. O Sistema deve se comunicar com o Sistema de Faturamento para informar as inscrições realizadas pelos alunos. RF9. O Sistema deve manter informações cadastrais sobre os alunos e sobre seus históricos escolares. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Regras de Negócio Algumas regras iniciais do negócio também foram identificadas para o sistema. Essas regras são descritas a seguir: RN01. Quantidade máxima de inscrições por Semestre letivo: em um semestre letivo, um aluno não pode se inscrever em uma quantidade de disciplinas cuja soma de créditos ultrapasse 20. RN02. Quantidade de alunos possíveis: uma oferta de disciplina em uma turma não pode ter mais de 40 alunos inscritos. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

RN03. Pré-requisitos para uma disciplina: um aluno não pode se inscrever em uma disciplina para a qual não possua os pré-requisitos necessários. RN04. Habilitação para lecionar uma disciplina: um professor só pode lecionar disciplinas para as quais esteja habilitado. RN05. Cancelamento de matrícula: um aluno deve ter a matrícula cancelada se for reprovado mais de duas vezes na mesma disciplina. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

RN06. Política de Avaliação de Alunos: a nota de um aluno em uma disciplina (um valor de 0 a 10) é obtida pela média de duas avaliações durante o semestre, A1 e A2, ou pela frequência nas aulas. se o aluno obtiver nota maior ou igual a 7,0 (sete), será aprovado; se o aluno obtiver nota maior ou igual a 5,0 (cinco) e menor que 7,0 (sete), deverá fazer a avaliação final; se o aluno obtiver nota menor que 5,0 (cinco) será reprovado; se o aluno tiver uma frequência menor que 75% em uma turma, será automaticamente reprovado. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Documentação do Modelo de Caso de Uso (Atores) Nesse sistema de controle acadêmico, o analista identificou e documentou os seguintes atores: Aluno: indivíduo que está matriculado na universidade, que tem interesse em se inscrever em disciplinas do curso. Professor: indivíduo que leciona disciplinas na universidade. Coordenador: pessoa interessada em agendar alocações de turmas e professores, e visualizar o andamento de inscrições de alunos. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Departamento de Registro Escolar (DRE): departamento da universidade interessado em manter informações sobre os alunos matriculados e sobre seu histórico escolar. Sistema de Recursos Humanos: este sistema legado é responsável por fornecer informações cadastrais sobre os professores. Sistema de Faturamento: este sistema legado tem interesse em obter informações sobre inscrições dos alunos para realizar o controle de pagamento de mensalidades. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Documentação do Modelo de Caso de Uso (Pacotes e seus Respectivos Casos de Uso) O analista também identificou os casos de uso a seguir e os organizou em três pacotes: Gerenciamento de Inscrições; Gerenciamento de Recursos Acadêmicos; Acompanhamento de Semestre Letivo. Os casos de uso que apresentam comentários (entre parênteses e em itálico) são aqueles para os quais não são fornecidas descrições detalhadas. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Gerenciamento de Inscrições: Realizar Inscrição; Cancelar Inscrição (Aluno cancela inscrições em uma ou mais ofertas de disciplinas em que havia solicitado inscrição); Visualizar Grade Curricular (Aluno visualiza a grade curricular atual); Visualizar Andamento de Inscrições; Abrir Turma (Coordenador abre uma turma); Fechar Turma (Coordenador fecha uma turma); Atender Lista de Espera. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Gerenciamento de Recursos Acadêmicos: Manter Grade Curricular (Coordenador define informações sobre uma grade curricular); Manter Disciplina; Manter Aluno (DRE mantém informações obre aluno); Fornecer Grade de Disponibilidade; Fornecer Habilitações (Professor informa as disciplinas da grade curricular que está apto a lecionar); Atualizar Informações sobre Professor. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Acompanhamento de Semestre Letivo: Lançar Avaliações e Frequência; Obter Diário de Classe (Professor obtém diário de classe para determinado mês do semestre letivo corrente); Visualizar Avaliações e Frequências; Solicitar Histórico Escolar (Aluno solicita a produção do seu histórico escolar). Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

A seguir são apresentados o Diagrama de Casos de Uso e as descrições de alguns casos de uso no formato essencial e expandido. A descrição dos demais casos de uso fica como atividade proposta. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Documentação do Modelo de Caso de Uso (Diagrama de Casos de Uso) Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Realizar Inscrição (CSU01)
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Documentação do Modelo de Caso de Uso (Descrição dos Casos de Uso) Realizar Inscrição (CSU01) Sumário: Aluno usa o sistema para realizar inscrição em disciplinas. Ator Primário: Aluno. Ator Secundário: Sistema de Faturamento. Precondições: O Aluno está identificado pelo sistema. Fluxo Principal: O Aluno solicita a realização de inscrição. O sistema apresenta as disciplinas para as quais o aluno tem pré- requisitos (conforme a RN03), excetuando-se as que já tenha cursado. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Realizar Inscrição (CSU01) - continuação
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Realizar Inscrição (CSU01) - continuação Fluxo Principal (continuação): O Aluno define a lista de disciplinas que deseja cursar no próximo semestre letivo e as relaciona para inscrição. Para cada disciplina selecionada, o sistema designa o aluno para uma turma que apresente uma oferta para tal disciplina. O sistema informa as turmas para as quais o Aluno foi designado. Para cada turma, o sistema informa o professor, os horários e os respectivos locais das aulas de cada oferta de disciplina. O Aluno confere as informações fornecidas. Aqui, é possível que o caso de uso retorne ao passo 3, conforme o Aluno queira revisar (inserir ou remover itens) a lista de disciplinas a cursar. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Realizar Inscrição (CSU01) - continuação Fluxo Principal (continuação): O sistema registra a inscrição do Aluno, envia os dados sobre a mesma para o Sistema de Faturamento e o caso de uso termina. Fluxo Alternativo (4): Inclusão em lista de espera Se não há oferta disponível para alguma disciplina selecionada pelo Aluno (conforme a RN02), o sistema reporta o fato e fornece a possibilidade de inserir o Aluno em uma lista de espera. Se o Aluno aceitar, o sistema o insere na lista de espera e apresenta a posição na qual o Aluno foi inserido na lista. O caso de uso retorna ao passo 4. Se o Aluno não aceitar, o caso de uso prossegue a partir do passo 4. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Realizar Inscrição (CSU01) - continuação Fluxo de Exceção (4): Violação de RN01 Se o Aluno atingiu a quantidade máxima de inscrições possíveis em um semestre letivo (conforme RN01), o sistema informa ao Aluno a quantidade de disciplinas que ele pode selecionar, e o caso de uso retorna ao passo 2. Pós-condições: O Aluno foi inscrito em uma das turmas de cada uma das disciplinas desejadas, ou foi adicionado a uma ou mais listas de espera. Regras de Negócio: RN01, RN02, RN03. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Visualizar Avaliações e Frequências (CSU02)
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Visualizar Avaliações e Frequências (CSU02) Sumário: Aluno visualiza avaliação que recebeu (notas e frequência) nas turmas de um semestre letivo. Ator Primário: Aluno. Precondições: O Aluno está identificado pelo sistema. Fluxo Principal: O Aluno solicita a visualização das avaliações para as ofertas de disciplina em que participou. O sistema exibe os semestre letivos nos quais o Aluno se inscreveu em pelo menos uma oferta de disciplina. O Aluno seleciona os semestres letivos cujas avaliações deseja visualizar. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Visualizar Avaliações e Frequências (CSU02) - continuação
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Visualizar Avaliações e Frequências (CSU02) - continuação Fluxo Principal (continuação): O sistema exibe uma lista de avaliações agrupadas por semestres letivos selecionados e por turma. O Aluno visualiza as avaliações e o caso de uso termina. Fluxo de Exceção (2): Aluno sem inscrição Não há semestre letivo no qual o Aluno tenha participado de alguma oferta de disciplina: o sistema reporta o fato e o caso de uso termina. Pós-condições: O Aluno obteve as avaliações que desejava visualizar. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Fornecer Grade de Disponibilidades (CSU03)
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Fornecer Grade de Disponibilidades (CSU03) Sumário: Professor fornece a sua grade de disponibilidade (disciplinas que deseja lecionar, juntamente com dias e horários em que está disponível) para o próximo semestre letivo. Ator Primário: Professor. Precondições: O Professor está identificado pelo sistema. Fluxo Principal: O Professor indica o desejo de fornecer sua grade de disponibilidades para o próximo semestre letivo. O sistema apresenta a lista de disciplinas disponíveis (conforme RN04). O Professor preenche a grade com as disciplinas que deseja lecionar no próximo semestre letivo. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Fornecer Grade de Disponibilidades (CSU03) - continuação
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Fornecer Grade de Disponibilidades (CSU03) - continuação Fluxo Principal (continuação): O sistema apresenta a lista de dias da semana e de horários do semestre letivo seguinte. O Professor preenche a grade com sua disponibilidade de dias da semana e horários para o próximo semestre letivo. O Professor solicita ao sistema que registre sua grade. O sistema registra a grade fornecida pelo professor e o caso de uso termina. Fluxo de Exceção (3): Modificação na grade atual O professor solicita que o sistema apresente a mesma grade do semestre atual. O sistema apresenta a configuração de grade requisitada. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Fornecer Grade de Disponibilidades (CSU03) - continuação
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Fornecer Grade de Disponibilidades (CSU03) - continuação Fluxo de Exceção (3): Modificação na grade atual (continuação) O professor realiza as modificações que deseja na grade e solicita o seu registro. O sistema registra a grade alterada e o caso de uso termina. Fluxo de Exceção (3): Disciplinas não fornecidas Se o Professor não forneceu disciplina alguma: o sistema reporta o fato e o caso de uso continua a partir do passo 2. Fluxo de Exceção (3): Dias e horários não fornecidos Se o Professor não r dia e horário algum: o sistema reporta o fato e o caso de uso continua a partir do passo 4. Pós-condições: o sistema registrou a disponibilidade do Professor para o próximo semestre letivo. Regras de Negócio: RN04. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Lançar Avaliações e Frequências (CSU04)
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Lançar Avaliações e Frequências (CSU04) Sumário: Professor realiza o lançamento de avaliações e frequências para alunos das ofertas de disciplinas lecionadas por ele no semestre corrente. Ator Primário: Professor. Precondições: O Professor está identificado pelo sistema. Fluxo Principal: O Professor solicita o lançamento de notas. O sistema exibe a lista de turmas e disciplinas correspondentes do semestre corrente nas quais o Professor lecionou. O Professor seleciona a turma e, dentro desta, a oferta de disciplina para a qual deseja realizar o lançamento de notas. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Lançar Avaliações e Frequências (CSU04) - continuação
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Lançar Avaliações e Frequências (CSU04) - continuação Fluxo Principal (continuação): O sistema exibe a lista de alunos da oferta de disciplina seleciona e requisitada a primeira nota (A1), a segunda nota (A2) e a quantidade de faltas para cada aluno. O Professor fornece as notas de A1 e de A2 e a quantidade de faltas (frequência) para cada aluno. O sistema exibe o resultado da avaliação de cada aluno (conforme RN06), para verificação pelo Professor. O Professor confere os dados e confirma o lançamento. O sistema registra as avaliações e frequências e o caso de uso termina. Fluxo Alternativo (7): Erro no lançamento O professor detecta que lançou uma avaliação ou frequência errada para algum aluno. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Lançar Avaliações e Frequências (CSU04) - continuação
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Lançar Avaliações e Frequências (CSU04) - continuação Fluxo Alternativo (7): Erro no lançamento (continuação) O professor corrige a informação que foi lançada erroneamente do aluno. O sistema aceita a correção e o caso de uso do continua a partir do passo 7. Fluxo de Exceção (4): Avaliação em branco ou errada Se o Professor não fornece alguma nota, ou frequência, ou fornece dados inválidos: o sistema reporta o fato e o caso de uso retorna ao passo 4. Pós-condições: as notas de uma ou mais disciplinas ofertadas e lecionadas pelo professor foram lançadas no sistema. Regras de Negócio: RN05, RN06. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Manter Disciplina (CSU05)
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Manter Disciplina (CSU05) Sumário: DRE realiza o cadastro (inclusão, remoção, alteração e consulta) dos dados sobre disciplinas. Ator Primário: DRE. Fluxo Principal: DRE requisita a manutenção de disciplinas. O sistema apresenta as operações que podem ser realizadas: a inclusão de uma nova disciplina, a alteração dos dados de uma disciplina, a exclusão de uma disciplina e a consulta de disciplinas. O DRE indica a opção a realizar ou opta por finalizar o caso de uso. O DRE seleciona a opção desejada: inclusão, alteração, exclusão ou consulta. Se o DRE deseja continuar com a manutenção, o caso de uso retorna ao passo 2; caso contrário, o caso de uso termina. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Manter Disciplina (CSU05) - continuação
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Manter Disciplina (CSU05) - continuação Fluxo Alternativo (4): Inclusão O DRE requisita a inclusão de uma disciplina. O sistema apresenta um formulário em branco para que os detalhes da disciplina (código, nome e quantidade de créditos) sejam incluídos. O DRE fornece os detalhes da nova disciplina. O sistema apresenta uma lista de disciplinas para que o DRE selecione as que são pré-requisitos para a disciplina a ser criada. O DRE define zero ou mais disciplinas como pré-requisitos. O sistema verifica a validade dos dados. Se os dados forem válidos, inclui a nova disciplina; caso contrário, o sistema reporta o fato, solicita novos dados e repete a verificação. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Manter Disciplina (CSU05) - continuação Fluxo Alternativo (4): Remoção O DRE seleciona uma disciplina e requisita que o sistema a remova. Se a disciplina pode ser removida, o sistema realiza a remoção; caso contrário, o sistema reporta o fato. Fluxo Alternativo (4): Alteração O DRE altera um ou mais dos detalhes sobre uma disciplina e requisita sua atualização. O sistema verifica a validade dos dados e, se eles forem válidos, altera os dados na lista de disciplinas da universidade. Fluxo Alternativo (4): Consulta O DRE solicita a realização de uma consulta sobre uma lista de disciplinas. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Manter Disciplina (CSU05) - continuação Fluxo Alternativo (4): Consulta O sistema apresenta uma lista com os códigos de todas as disciplinas, permitindo que o DRE selecione a disciplina desejada. O DRE seleciona uma disciplina. O sistema apresenta os detalhes da disciplina e seus pré-requisitos (se existirem) no formulário de disciplina. Pós-condições: uma disciplina foi inserida ou removida, ou seus detalhes foram alterados. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Visualizar Andamento de Inscrições (CSU06)
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Visualizar Andamento de Inscrições (CSU06) Sumário: O Coordenador usa o sistema para visualizar o andamento de inscrições sendo realizadas pelos alunos em disciplinas ofertadas para o próximo semestre letivo. Ator Primário: Coordenador. Precondições: O Coordenador está identificado pelo sistema. Fluxo Principal: O Coordenador solicita a visualização do andamento de inscrições realizadas pelos alunos. O sistema exibe a lista de disciplinas para as quais existe pelo menos uma oferta para o próximo semestre. O coordenador seleciona a disciplina para a qual deseja visualizar o andamento de inscrições. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Visualizar Andamento de Inscrições (CSU06) - continuação
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Visualizar Andamento de Inscrições (CSU06) - continuação Fluxo Principal (continuação): O sistema exibe a lista de turmas nas quais existe oferta para a disciplina selecionada, juntamente com as distribuições correspondentes: professor, horários, locais e situação (aberta ou fechada). O Coordenador seleciona uma das turmas. O sistema apresenta a lista de alunos inscritos na turma para a disciplina selecionada, ordenador por data de inscrição. O coordenador visualiza as inscrições. Se o Coordenador deseja continuar a visualização, o caso de uso retorna ao passo 5; é também possível que o caso de uso retorne ao passo 3, de acordo com a ação do Coordenador; caso contrário, o caso de uso termina. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Atualizar Informações Sobre Professor (CSU07)
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Atualizar Informações Sobre Professor (CSU07) Sumário: Administrador do sistema usa o sistema para atualizar as informações cadastrais sobre professores a partir do SRH. Ator Primário: Administrador. Ator Secundário: Sistema de Recursos Humanos (SRH). Precondições: O Administrador está identificado pelo sistema. Fluxo Principal: O Administrador solicita ao sistema que obtenha os dados atualizados sobre professores. O sistema se comunica com o SRH e obtém os dados a partir deste. O sistema apresenta os dados obtidos e solicita a confirmação do Administrador para realizar a atualização. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Atualizar Informações Sobre Professor (CSU07) - continuação
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Atualizar Informações Sobre Professor (CSU07) - continuação Fluxo Principal (continuação): O Administrador confirma a atualização. O sistema atualiza os dados cadastrais dos professores e o caso de uso termina. Fluxo Alternativo (4): Desistência de atualização O Administrador declina da atualização e o caso de uso termina. Fluxo de Exceção (2): Houve uma falha na obtenção de dados O sistema não consegue obter os dados a partir do SRH. O sistema reporta o fato e o caso de uso termina. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Atender Listas de Espera (CSU08)
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Atender Listas de Espera (CSU08) Sumário: Coordenador atende ás demandas representadas pelas listas de espera por vagas para uma disciplina. Ator Primário: Coordenador. Ator Secundário: Sistema de Faturamento. Precondições: O Coordenador está identificado pelo sistema. Fluxo Principal: O sistema apresenta as listas de espera existentes para as disciplinas. O Coordenador seleciona uma das listas de espera. O sistema apresenta os detalhes da lista de espera selecionada (data de criação e quantidade de alunos). Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Atender Listas de Espera (CSU08) - continuação
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Atender Listas de Espera (CSU08) - continuação Fluxo Principal (continuação): O Coordenador fornece os dias e respectivos horários da oferta de disciplinas que deseja criar. O sistema apresenta as salas e os professores disponíveis nos dias e horários fornecidos pelo Coordenador. O Coordenador seleciona um professor e uma ou mais salas. O Coordenador fornece a quantidade de alunos a serem alocados na nova oferta de disciplina (conforme RN02). A partir de uma lista fornecida pelo sistema, o Coordenador seleciona a turma na qual deseja alocar a oferta de disciplina. O sistema cria a oferta de disciplina e transfere a quantidade de alunos fornecida no passo 7 da lista de espera para a oferta recém-criada, de acordo com a ordem dos alunos da lista. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Atender Listas de Espera (CSU08) - continuação
ATIVIDADES PROPOSTAS Estudo de Caso – Sistema Controle Acadêmico - SCA Atender Listas de Espera (CSU08) - continuação Fluxo Principal (continuação): Se o Coordenador deseja continuar o atendimento das listas de espera, o caso de uso retorna ao passo 1; caso contrário, o sistema envia os dados de inscrições de alunos para o sistema de faturamento e o caso de uso termina. Fluxo de Exceção (7): Violação de RN02 Se a quantidade de alunos que o Coordenador fornecer for inválida (violar a regra de negócio RN02), o sistema reporta o fato e solicita um novo valor. O Coordenador corrige o valor e o caso de uso prossegue a partir do passo 8. Regra de Negócio: RN02. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Diagrama de Classe Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Glossário O glossário contém os termos relevantes do domínio, a maioria deles correspondentes a classes identificadas. A definição do glossário para o Sistema de Controle Acadêmico é apresentada a seguir: Aluno: representa um aluno da universidade. Aula: representa o acontecimento semanal de uma aula de alguma oferta de disciplina. Toda aula acontece em uma sala da universidade. Avaliação: representa uma avaliação atribuída à participação de um aluno em uma turma que oferece alguma disciplina da universidade. Disciplina: uma disciplina componente da grade curricular da universidade. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Grade de Disponibilidades: representa a grade de dias da semana e os respectivos horários no semestre letivo seguinte ao atual nos quais um professor está disponível para lecionar na universidade. Representa também as disciplinas que o professor está apto a lecionar nesse mesmo semestre letivo. Grade Curricular: uma grade curricular corresponde a um conjunto de disciplinas, juntamente com os pré-requisitos de cada uma delas. De tempos em tempos, a instituição de ensino atualiza a sua grade curricular. Nessa atualização, novas disciplinas podem ser criadas, assim como disciplinas existentes podem ser removidas da grade. Lista de Espera: representa uma lista dos alunos que estão esperando que uma certa disciplina seja oferecida em alguma turma. Oferta de disciplina: representa a alocação de uma disciplina em alguma turma. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Participação: representa a participação de um aluno em alguma disciplina ofertada pela universidade. A participação de um aluno em uma oferta de disciplina possui uma avaliação. Professor: representa o indivíduo que leciona as disciplinas ofertadas pela universidade. Sala: representa um dos locais da universidade que podem ser utilizados para as aulas de uma ou mais disciplinas ofertadas. Turma: representa uma turma aberta em algum semestre letivo da universidade. Um turma possui diversas disciplinas ofertadas. Diário de classe: corresponde a um formulário que contém os nomes dos alunos inscritos em determinada oferta de disciplina. Nesse formulário, o professor lança a quantidade de faltas e as avaliações de cada aluno. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Diagrama de Atividade O diagrama de atividade apresentado ao lado aplica-se à descrição da lógica de funcionamento do caso de uso Realizar Inscrição. Note que este diagrama realça as atividades do caso de uso que têm potencial para serem realizadas em paralelo. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Diagrama de Atividade Outra possibilidade é utilizar o diagrama de atividade para documentar regras de negócio. O diagrama de atividade ao lado representa a lógica de implementação da regra de negócio Política de Avaliação de Alunos (RN06). Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Diagrama de Atividade Também é possível utilizar o diagrama de atividades para a modelagem e representação de fluxos de processos de negócio principais, como ilustrado ao lado. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ATIVIDADES PROPOSTAS Estudo de Caso Particular
Baseado no estudo de caso apresentado anteriormente, reúna-se com seus colegas formando grupos de 5 pessoas e, posteriormente, tente elaborar desde o documento de requisitos até o diagrama de atividades (fluxo de processos de negócio) para um sistema de software do seu cotidiano (por exemplo, um sistema para automatizar algum processo na empresa em que trabalha, aproveitando o conhecimento do domínio do negócio que você tiver), cujo domínio do problema e negócio sejam do seu conhecimento, vivência e experiência. Durante a elaboração desse documento, resista o máximo possível à tentação de considerar detalhes técnicos e de implementação. Entrega e apresentação no dia 21/05. Artefatos: documento de requisitos, regras de negócio, modelo completo de casos de uso, diagrama de classes, glossário e diagrama de atividades (fluxo dos processos de negócio). Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

ATIVIDADES PROPOSTAS Pesquisa – Ferramenta de Gerência de Requisitos:
Faça uma pesquisa e produza um relatório a respeito das principais ferramentas de gerência de requisitos existentes no mercado. Faça um comparativo entre elas. Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

Curso de Pós-graduação Lato-Sensu em Análise,

Apresentações semelhantes

Apresentação em tema: "Curso de Pós-graduação Lato-Sensu em Análise,"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Curso de Pós-graduação Lato-Sensu em Análise,

Apresentações semelhantes

Apresentação em tema: "Curso de Pós-graduação Lato-Sensu em Análise,"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback