Engenharia de Software

Tamanho: px
Começar a partir da página:

Download "Engenharia de Software"

Transcrição

1 Engenharia de Software Engenharia de Requisitos Departamento de Matemática Universidade dos Açores Hélia Guerra A importância dos requisitos The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all interfaces to people, to machines, and to other software systems. No other part of the work is so cripples the resulting systems if done wrong. No other part is more difficult to rectify later. 2 (Brooks, 1987)

2 factores com maior impacto na falha de projectos Requisitos incompletos Falta de envolvimento dos utilizadores Expectativas pouco realistas Falta de suporte executivo Alterações aos requisitos e às especificações Falta de planeamento Sistema já não é preciso Os requisitos estão envolvidos na maior parte das causas da falha de projectos Erros de requisitos podem sair caros se não forem detectados a tempo 3 requisitos Um requisito é uma expressão do comportamento pretendido para o sistema Um requisito lida com entidades ou objectos o estado em que cada entidade pode estar as funções que devem ser executadas para que as entidades mudem de estado ou as características dos objectos se alterem Os requisitos focam as necessidades dos clientes e não a solução ou a implementação do sistema 4

3 processo para capturar os requisitos Feito por um analista de requisitos ou analista de sistemas O passo final é um documento com a especificação dos requisitos 5 Levantamento de requisitos Os clientes nem sempre exprimem bem as suas necessidades e os seus problemas É importante discutir os requisistos com todas as pessoas envolvidas no sistema É importante chegar a um acordo sobre os requisistos se não houver acordo, o projecto está condenado ao fracasso 6

4 As fontes dos requisitos Clientes: pagam para o software ser desenvolvido Compradores: compram o software depois de pronto Utilizadores: utilizam o sistema Peritos no domínio: familiarizados com o problema que vai ser resolvido Gestores de negócios: conduzem estudos para encontrar tendencias futuras e potenciais necessidades dos compradores Advogados ou auditores: familiarizados com a lei e com o governo Engenheiros de Software ou outros especialista em tencologias 7 pontos de vista Cada interveniente tem uma visão própria do sistema e do seu funcionamento Diferentes intervenientes podem querer diferentes níveis de detalhe para os requisitos Por vezes existem ideias pré-concebidas de uns intervenientes em relação a outros Equipa de desenvolvimento -> utilizadores não sabem bem o que querem não explicam bem o que querem querem as coisas prontas rapidamente não conseguem atribuir prioridades às necessidades não aceitam assumir responsabilidades no sistema... 8

5 pontos de vista Utilizadores -> Equipa de desenvolvimento não as necessidades operacionais dão demasiada importância aos aspectos técnicos não conseguem implementar requisitos de forma clara estão sempre atrasados ultrapassam sempre o orçamento previsto pedem aos utilizadores tarefas que os desviam da sua tarefa principal... O analista de requisitos deve ter uma excelente habilidade nas relações sociais entre os diferentes intervenientes, bem como ter sólidos conhecimentos técnicos 9 Formas de levantamento de requisitos Entrevistar os intervenientes no sistema Revisão da documentação disponível Observação do sistema existente (se aplicável) Aprender com os utilizadores as suas tarefas Entrevistar grupos de intervenientes em conjunto Usar estratégias de domínio especificas, tais como, a Joint Application Design Brainstorming com utilizadores correntes e potenciais utilizadores 10

6 modelo de requisitos de volere 11 tipos de requisitos Funcionais: descrevem a interacção entre o sistema e o seu ambiente O que faz o sistema e quando faz Modos de operação Transformações nos dados Reacções esperadas a estímulos externos Formato dos dados de I/O... 12

7 tipos de requisitos Qualidade ou não funcionais: descrevem qualidades/características que o software deve ter Desempenho (tempo de resposta) Utilização (fácil, tempo de treino) Segurança (acesso restrito, dados isolados, roubo e vandalismo) Fiabilidade e portabilidade (capacidade em detectar e isolar falhas, frequencia de backups, copias em diferentes locais) Manuntenção (corrigir erros, melhorar o sistema, facilidade) Precisão Tempo para entrega Custo tipos de requisitos Restrições ao desenho: decisão de desenho Ambiente físico (plataforma, local ou distribuido, temperatura, humidade, dimensão, linguagens de programação) Interfaces (componentes da interface, sistemas de input, sistemas de output) Utilizadores (quem são, tipos, conhecimentos que têm)... 14

8 tipos de requisitos Restrições ao processo: decisão das técnicas e recursos a usar Recursos (materiais, pessoas, outros) Documentação (tipo, online/offline, livro) Standards resolução de conflitos Diferentes intervenientes no sistema podem ter ideias diferentes surgem potenciais conflitos de ideias Atribuir prioridades aos requisitos essencial: têm que ser satisfeitos desejável: seria bom que fossem satisfeitos opcional: podem ser satisfeitos mas é possível eliminá-los 16

9 documentação dos requisitos Definição dos requisitos: listagem de tudo o que o cliente quer encontrar feito descreve as entidades do ambiente onde o sistema vai ser instalado Especificação dos requisitos: reescrita do documento anterior utilizando termos técnicos adequados à equipa de desenvolvimento 17 Correcção Consistencia Coerencia Completude Viabilidade Relevancia Certificação características dos requisitos Rastreabilidade (Traceability) 18

10 Modelaçãode requisitos É importante usar notações standard para modelar, documentar e comunicar decisões A modelação é útil para se perceber os requisitos Vamos estudar os seguintes paradigmas notacionais Diagramas entidade relacionamento Máquinas de estados Traços de eventos Diagramas de fluxo de dados 19 diagramas entidaderelacionamento Ehen, 1976 Paradigma de notação bastante popular para representar modelos conceptuais Construtores entidades: representam colecções de objectos reais (carros, moedas,...) relacionamentos: ligações entre entidades atributos: anotações feitas nas entidades para descreverem propriedades 20

11 diagramas entidaderelacionamento 21 diagramas entidaderelacionamento Os diagramas ER fornecem uma visão relativamente estável do problema Alterar requisitos significa alterar entidades, atributos e relacionamentos Contudo, pode não ser simples saber qual o nível de detalhe para modelar um problema, nem se determinados dados são entidades ou atributos Os diagramas devem ser usados na fase inicial do processo de requisitos 22

12 UML UML (Unified Modeling Language) é uma notação muito usada para descrever soluções orientadas a objectos A UML foi adoptada pela OMG (Object Management Group) como a notação standard orientada a objectos Diagramas UML Visão estática do sistema (classes, componentes, instalação) Visão dinâmica do sistema (casos de uso, actividades, interação, estados) 23 Diagramas de classes UML O diagrama de classes está presente em qualquer modelo especificado usando a UML É um diagrama ER que relaciona classes (entidades) Resulta de um processo de abstracção através do qual se identificam os objectos (entidades e conceitos) relevantes para sistema e se procuram descrever propriedades (atributos) e comportamentos (operações) desses objectos 24

13 !! Diagrama de classes 25 diagrama de classes Agregação relação has-a Composição relação de agregação mais forte Generalização relação is-a 26

14 máquinas de estados Descrição gráfica do diálogo entre o sistema e o ambiente Nó (estado) representa um conjunto de condições estáveis existentes entre uma ocorrencia de eventos Aresta (transição) representa uma alteração ao comportamento devido à ocorrencia de um evento Útil para especificar como é que o sistema se comporta em resposta a determinada sequencia de eventos 27 máquinas de estados 28

15 máquinas de estados caminho: sequencia de eventos observáveis pelo ambiente que se inicia no estado inicial máquina de estados determinista: para cada estado e cada evento só existe uma transição 29 Diagramas UML de estados 30

16 Diagramas UML de estados 31 Diagramas UML de estados Estados com anotações 32

17 estados A parte mais difícil na construção dos diagramas de estados e saber como decompor o comportamento de um objecto em estados Estados são: - classes de equivalencia de possível comportamento - Intervalos de tempo entre eventos consecutivos - Pontos de controlo identificados na evolução do objecto - Partições do comportamento do objecto 33 Traços Descrição gráfica de sequencias de eventos trocados entre as entidades e o ambiente Linha vertical: linha do tempo para cada entidade indicada no topo Linha horizontal: evento ou interacção entre duas entidades nos extremos da linha O tempo progride do topo para a base Um gráfico descreve um único traço de eventos, representando um comportamento possível do sistema 34

18 Traços Exemplo: comportamento típico à esquerda e comportamento atípico à direita 35 Diagramas de fluxo de dados Um diagrama de fluxo de dados (DFD) modela a funcionalidade e o fluxo de dados de uma função para outra numa visão do sistema de alto nível um processo é representado uma uma elipse fluxo de dados é representado por uma seta armazém de dados é um repositório de dados actor entidade que fornece ou recebe dados é representada por um rectângulo 36

19 Diagrama de fluxo de dados 37 Diagramas de fluxo de dados Vantagens: modelo intuitivo da funcionalidade de um sistema numa visão de alto nível e da dependencia dos dados entre os vários processos fácil leitura e entendimento Desvantagem: podem ser ambíguos para quem não esteja familiarizado com o problema Devem ser usados numa fase inicial, quando os detalhes ainda não são importantes 38

20 Diagramas UmL de casos de uso Componentes limites do sistema: rectangulo grande actores (pessoas, sistemas): figuras do lado de fora do rectangulo: caso de uso: elipse dentro dos limites do sistema que representa uma funcionalidade linha entre um actor e um caso de uso, indicando que o actor participa no caso de uso Os casos de uso são usados para especificar comportamentos importantes do sistema do ponto de vista do utilizador 39 Diagrama UmL de casos de uso 40

21 Casos de uso Identificar os actores Para cada actor, identificar os casos de uso Desenhar o diagrama Decrever cada caso de uso 41 Diagrama de actividades Adequado para modelar fluxo de procedimentos ou de actividades de uma classe 42

22 Linguagem de especificação de requisitos Combina vários paradigmas notacionais Por exemplo, a notação UML tem diagramas de casos de uso (DFD de alto nível) diagramas de classes (diagramas ER) diagramas de sequências (traços) diagramas de colaboração (traços) diagramas de estados (máquinas de estados) 43 prototipos de requisitos Para levantar requisitos de um sistema Pedir aos clientes/utilizadores que aspectos gostariam de ver melhorados que funcionalidades não são úteis que funcionalidades é que faltam Determinar se o problema do cliente tem uma solução viável Optimizar a qualidade dos requisitos 44

23 prototipo de requisitos 45 Abordagens para a prototipagem de requisitos Descartável serve apenas para perceber o problema e não é integrada no produto final Evolucionária Para além de ajudar a perceber o problema também é incorporada no produto final Prototipagem rápida 46

24 Prototipagem vs. modelação Prototipagem boa para responder a questões relacionadas com as interfaces com o utilizador Modelação boa para responder a questões relacionadas com a ordem em que os eventos ocorrem ou com a sincronização de actividades 47 Normas IEEE, 1998 Table of contents 1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms, and abbreviations 1.4. References 1.5. Overview 48

25 Normas IEEE, Overall description 2.1. Product perspective 2.2. Product functions 2.3. User characteristics 2.4. Constraints 2.5.Assumptions and dependencies 2.6.Apportioning of requirements 49 Normas IEEE, Specific requirements 3.1. External interfaces 3.2. Functions 3.3. Performance requirements 3.4. Logical database requirements 3.5. Design constraints 3.6. Software system attributes 3.7. Organizing the specific requirements 3.8. Additional comments 50

26 Normas IEEE, 1998 Appendixes Index 51 validação e verificação Na validação dos requisitos verifica-se se a definição dos requisitos reflecte as necessidades do cliente Na verificação dos requisitos verifica-se se o documento da definição dos requisitos está de acordo com o documento da especificação dos requisitos A validação garante que we build the right system A verificação garante que we build the system right 52

27 técnicas para validação Cruzamento de informação Leitura Entrevistas Revisões Listas de verificação Modelos pré-definidos para verificar funções e relações Cenários Protótipos Simulação Demonstração matemática 53 revisão dos requisitos Revisão dos objectivos estabelecidos e dos objectivos do sistema Comparação dos requisitos com os objectivos Revisão do ambiente onde o sistem irá funcionar Revisão do fluxo de informação e das funções propostas Estimação e documentação do risco, discussão e alternativas Testes ao sistema: como é que os requisitos irão ser revalidados à medida que se fazem alterações 54

28 técnicas para verificação Cruzamento de informação Simulação Verificação de consistencia Verificação de completude Verificação de estados/transições inatingíveis Model checking Theorem prover 55 medição dos requisitos Áreas: produto, processo, recursos O número de requisitos dá ideia da dimensão do sistema O número de alterações aos requisitos indica alguma instabilidade e incerteza no entendimento do problema 56

29 Inquérito aos desenhadores classificação de 1 (Muito bom) a 5 (mau) 1. Entende o requisito completamente. Já desenhou sistemas com requisitos similares e não terá problemas em desenhar este sistema com este requisito 2. Há aspectos novos no requisito mas não muito diferentes dos que já já desenhou com sucesso 3. Alguns aspectos do requisito são muito diferentes dos requisitos que já desenhou no passado, mas consegue perceber o requisito e considera poder fazer um bom desenho para o mesmo 4.Não percebe partes do requisito e não garante conseguir fazer um bom desenho 5. Não percebe nada do requisito e considera não conseguir fazer o desenho 57 Inquérito às equipas de testes classificação de 1 (Muito bom) a 5 (mau) 1. Entende o requisito completamente. Já testou sistemas com requisitos similares e não terá problemas em testar este sistema com este requisito 2. Há aspectos novos no requisito mas não muito diferentes dos que já já testou com sucesso 3. Alguns aspectos do requisito são muito diferentes dos requisitos que já testou no passado, mas consegue perceber o requisito e considera poder fazer bons testes para o mesmo 4.Não percebe partes do requisito e não garante conseguir fazer bons testes 5. Não percebe nada do requisito e considera não conseguir fazer testes 58

30 Visão dos desenhadores/ equipas de teste Bom Necessita de revisão 59 resumo A documentação da definição e da especificação dos requisitos deve descrever o problema e deixar a solução para os designers Existem várias formas de levantar os requisitos Existem várias técnicas para definir e para especificar os requisitos Questões aos requisitos podem ser respondidas usando modelos ou protótipos Os requisitos devem ser validados para se garantir que reflectem as expectativas dos clientes 60

Engenharia de Software

Engenharia de Software Engenharia de Software Engenharia de Requisitos Departamento de Matemática Universidade dos Açores Hélia Guerra helia@uac.pt A importância dos requisitos 2 A importância dos requisitos The hardest single

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Introdução Departamento de Matemática Universidade dos Açores Hélia Guerra helia@uac.pt Engenharia de software A economia de todos os países desenvolvidos depende do software. O

Leia mais

Extração de Requisitos

Extração de Requisitos Extração de Requisitos Extração de requisitos é o processo de transformação das idéias que estão na mente dos usuários (a entrada) em um documento formal (saída). Pode se entender também como o processo

Leia mais

Projeto de Sistemas I

Projeto de Sistemas I Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Processos de software Departamento de Matemática Universidade dos Açores Hélia Guerra helia@uac.pt Processo Um processo é uma série de etapas envolvendo actividades, restrições e

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

3. Engenharia de Requisitos

3. Engenharia de Requisitos Engenharia de Software 3. Engenharia de Requisitos Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Fases do desenvolvimento de software que mais erros originam (fonte: "Software Testing", Ron Patton)

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Processos de software Departamento de Matemática Universidade dos Açores Hélia Guerra helia@uac.pt Processo Um processo é uma série de etapas envolvendo actividades, restrições e

Leia mais

MODELAGEM DE SISTEMA Apresentação

MODELAGEM DE SISTEMA Apresentação MODELAGEM DE SISTEMA Apresentação Prof Daves Martins Msc Computação de Alto Desempenho Email: daves.martins@ifsudestemg.edu.br Apresentação da Disciplina Apresentação da Disciplina Apresentação da Disciplina

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed. REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de software AULA NÚMERO: 08 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos relacionados a modelos e especificações. Nesta aula

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

2 Diagrama de Caso de Uso

2 Diagrama de Caso de Uso 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 Caso de Uso (Use Case) Autoria:Aristófanes Corrêa

Leia mais

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no 1.1 RATIONAL UNIFIED PROCESS (RUP) O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no processo que atende pelo nome de Processo Unificado (ou UP do inglês Unified

Leia mais

Requisitos. Sistemas de Informações

Requisitos. Sistemas de Informações Requisitos Sistemas de Informações Definindo o Sucesso do Software Clientes satisfeitos Eles estão satisfeitos quando você: Atende às expectativas Entrega no prazo Entrega no orçamento O Sucesso começa

Leia mais

Requisitos e Modelação

Requisitos e Modelação Requisitos e Modelação combinação essencial para melhorar o processo de desenvolvimento de software Class4 -End1 -End2 Class1 * * System Actor1 * -End3 -End5 -End7 * Actor2 UseCase1 -End4 * UseCase2 -End6

Leia mais

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1.

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1. Modelos de Sistema Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1 Objetivos Explicar por que o contexto de um sistema deve ser modelado como parte do processo de RE Descrever

Leia mais

Engenharia de Requisitos Estudo de Caso

Engenharia de Requisitos Estudo de Caso Engenharia de Requisitos Estudo de Caso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 Engenharia de Requisitos Exemplo 1 Reserva de Hotel 1. INTRODUÇÃO Este

Leia mais

Análise de Sistemas. Conceito de análise de sistemas

Análise de Sistemas. Conceito de análise de sistemas Análise de Sistemas Conceito de análise de sistemas Sistema: Conjunto de partes organizadas (estruturadas) que concorrem para atingir um (ou mais) objectivos. Sistema de informação (SI): sub-sistema de

Leia mais

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa

Leia mais

SAD orientado a MODELO

SAD orientado a MODELO Universidade do Contestado Campus Concórdia Curso de Sistemas de Informação Prof.: Maico Petry SAD orientado a MODELO DISCIPLINA: Sistemas de Apoio a Decisão SAD Orientado a Modelo De acordo com ALTER

Leia mais

)HUUDPHQWDV &RPSXWDFLRQDLV SDUD 6LPXODomR

)HUUDPHQWDV &RPSXWDFLRQDLV SDUD 6LPXODomR 6LPXODomR GH6LVWHPDV )HUUDPHQWDV &RPSXWDFLRQDLV SDUD 6LPXODomR #5,6. Simulador voltado para análise de risco financeiro 3RQWRV IRUWHV Fácil de usar. Funciona integrado a ferramentas já bastante conhecidas,

Leia mais

APOO Análise e Projeto Orientado a Objetos. Requisitos

APOO Análise e Projeto Orientado a Objetos. Requisitos + APOO Análise e Projeto Orientado a Objetos Requisitos Requisitos 2 n Segundo Larman: n São capacidades e condições às quais o sistema e em termos mais amplos, o projeto deve atender n Não são apenas

Leia mais

Verificação e Validação

Verificação e Validação Verificação e Validação Patrícia Macedo Joaquim Filipe João Ascenso 2005/2006 EST, Setúbal Verificação e Validação Verificação Garante que o software cumpre as especificações Consistência interna Estamos

Leia mais

Análise de Sistemas. Contextualização. O Sucesso. Aula 4. Instrumentalização. Aula 4. Prof. Emerson Klisiewicz. Clientes satisfeitos

Análise de Sistemas. Contextualização. O Sucesso. Aula 4. Instrumentalização. Aula 4. Prof. Emerson Klisiewicz. Clientes satisfeitos Análise de Sistemas Aula 4 Contextualização Prof. Emerson Klisiewicz Aula 4 Gerenciamento de Requisitos Refinamento de Requisitos Aprovação de Requisitos Matriz de Rastreabilidade O Sucesso Clientes satisfeitos

Leia mais

Gestão do Risco e da Qualidade no Desenvolvimento de Software

Gestã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 mais

TRANSIÇÃO DA ISO 9001:2000 PARA ISO 9001:2008 DOCUMENTO SUMÁRIO DE ALTERAÇÕES ALTERAÇÕES QUE PODEM AFECTAR O SISTEMA

TRANSIÇÃO DA ISO 9001:2000 PARA ISO 9001:2008 DOCUMENTO SUMÁRIO DE ALTERAÇÕES ALTERAÇÕES QUE PODEM AFECTAR O SISTEMA TRANSIÇÃO DA ISO 9001:2000 PARA ISO 9001:2008 DOCUMENTO SUMÁRIO DE ALTERAÇÕES A nova norma ISO 9001, na versão de 2008, não incorpora novos requisitos, mas apenas alterações para esclarecer os requisitos

Leia mais

Análise e Conc epç ão de Sist em as de Inform aç ão,qwurgxomrj(qj GH5HTXLVLWRV. Adaptado a partir de Gerald Kotonya and Ian Sommerville

Análise e Conc epç ão de Sist em as de Inform aç ão,qwurgxomrj(qj GH5HTXLVLWRV. Adaptado a partir de Gerald Kotonya and Ian Sommerville Análise e Conc epç ão de Sist em as de Inform aç ão,qwurgxomrj(qj GH5HTXLVLWRV Adaptado a partir de Gerald Kotonya and Ian Sommerville 1 Objectivos Introduzir as noções requisitos de sistema e processo

Leia mais

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática 3ºAno Disciplina de Desenvolvimento de Sistemas de Software Ano Lectivo de 2009/2010 GereComSaber Sistema de

Leia mais

Desenvolvimento estruturado versus orientado a objetos.

Desenvolvimento estruturado versus orientado a objetos. Desenvolvimento estruturado versus orientado a objetos. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Objetivos Identificar diferenças entre: Desenvolvimento

Leia mais

Desenvolvimento Iterativo. Unified Process (UP) Esta abordagem ao desenvolvimento

Desenvolvimento Iterativo. Unified Process (UP) Esta abordagem ao desenvolvimento Desenvolvimento Iterativo Esta abordagem ao desenvolvimento assegura que o sistema cresce de forma incremental assegura que a complexidade se mantém controlada permite ainda obter rápido feedback de várias

Leia mais

Engenharia Informática

Engenharia Informática Escola Superior de Ciência e Tecnologia Engenharia Informática Análise de Sistemas Informáticos 3º ano Exame 12 de Julho de 2006 Docentes: José Correia e João Paulo Rodrigues Duração: 90 m; Tolerância:

Leia mais

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0 O que é BABok? O BABok 2.0, Corpo de Conhecimento de Análise de Negócios, é considerado como um Guia Referência de Práticas de Análise de Negócio. Este guia é publicado e mantido pelo IIBA. O guia BABok

Leia mais

ISO 9000:2000 Sistemas de Gestão da Qualidade Fundamentos e Vocabulário. As Normas da família ISO 9000. As Normas da família ISO 9000

ISO 9000:2000 Sistemas de Gestão da Qualidade Fundamentos e Vocabulário. As Normas da família ISO 9000. As Normas da família ISO 9000 ISO 9000:2000 Sistemas de Gestão da Qualidade Fundamentos e Vocabulário Gestão da Qualidade 2005 1 As Normas da família ISO 9000 ISO 9000 descreve os fundamentos de sistemas de gestão da qualidade e especifica

Leia mais

Análise e Projeto de Sistemas de Informação. Andrêza Leite andreza.lba@gmail.com

Análise e Projeto de Sistemas de Informação. Andrêza Leite andreza.lba@gmail.com Análise e Projeto de Sistemas de Informação Andrêza Leite andreza.lba@gmail.com Roteiro Sistemas de Informação Ciclo de Desenvolvimento de SI Projeto Análise Estruturada Análise Orientada a Objetos Como

Leia mais

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas 4.1 Motivação Sistemas de Informação são usados em diversos níveis dentro de uma organização, apoiando a tomada de decisão; Precisam estar

Leia mais

Unified Software Development Process

Unified Software Development Process 59/170 Unified Software Development Process Sumário Breve história do Unified Process O Unified Process O ciclo de vida do Unified Process O RUP (Rational Unified Process) 60/170 Breve História do Unified

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

Parte I Requirement Engineering. Gestão de Projectos Informáticos. Gestão do Âmbito (Scope Management) Requirement Engineering.

Parte I Requirement Engineering. Gestão de Projectos Informáticos. Gestão do Âmbito (Scope Management) Requirement Engineering. Parte I Requirement Engineering Gestão de Projectos Informáticos Gestão do Âmbito (Scope Management) Requirement Engineering Introduzir as noções requisitos de sistema e processo de engª de requisitos

Leia mais

ARQUITECTURAS DE SOFTWARE

ARQUITECTURAS DE SOFTWARE ARQUITECTURAS DE SOFTWARE AULAS Nº 8 e 9 7-21/12/2007 F. Mário Martins Case Studies: Ligação das partes Use Case Diagram Use Case Specification Passo 1: ---------- Passo 2: ---------- Passo 3: ----------

Leia mais

Engenharia de Software: Introdução. Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes

Engenharia de Software: Introdução. Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes Engenharia de Software: Introdução Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes Programa 1. O processo de engenharia de software 2. UML 3. O Processo Unificado 1. Captura de requisitos 2.

Leia mais

CAP. I ERROS EM CÁLCULO NUMÉRICO

CAP. I ERROS EM CÁLCULO NUMÉRICO CAP. I ERROS EM CÁLCULO NUMÉRICO 0. Introdução Por método numérico entende-se um método para calcular a solução de um problema realizando apenas uma sequência finita de operações aritméticas. A obtenção

Leia mais

O Impacto da Engenharia de Requisitos no Processo de Métricas. Fátima Cesarino CAIXA

O Impacto da Engenharia de Requisitos no Processo de Métricas. Fátima Cesarino CAIXA O Impacto da Engenharia de Requisitos no Processo de Métricas Fátima Cesarino CAIXA Apresentação Diferentes Cenários Desenvolvimento Software Importância do SISP Agradecimento Oportunidade Responsabilidade

Leia mais

Desenho de Software. Desenho de Software 1

Desenho de Software. Desenho de Software 1 Desenho de Software Desenho de Software 1 Sumário Caracterização Conceitos fundamentais Desenho funcional e desenho OO Qualidades Desenho de Software 2 Bibliografia Pfleeger, Capítulo 6 Design the Modules

Leia mais

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

Leia mais

Diagrama de Caso de Uso e Diagrama de Sequência

Diagrama de Caso de Uso e Diagrama de Sequência Diagrama de Caso de Uso e Diagrama de Sequência Milena Alexandre dos Santos Baesso (Mestranda em Engenharia Elétrica) Agenda Ciclo de Vida de um Sistema A Fase de Análise Análise Orientada à Objetos Diagramas

Leia mais

Introdução ao Aplicativo de Programação LEGO MINDSTORMS Education EV3

Introdução ao Aplicativo de Programação LEGO MINDSTORMS Education EV3 Introdução ao Aplicativo de Programação LEGO MINDSTORMS Education EV3 A LEGO Education tem o prazer de trazer até você a edição para tablet do Software LEGO MINDSTORMS Education EV3 - um jeito divertido

Leia mais

Especificação Operacional.

Especificação Operacional. Especificação Operacional. Para muitos sistemas, a incerteza acerca dos requisitos leva a mudanças e problemas mais tarde no desenvolvimento de software. Zave (1984) sugere um modelo de processo que permite

Leia mais

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER Objetivo dessa aula é descrever as características e a simbologia dos diagramas UML e MER na modelagem de sistemas de informação de uma forma a permitir a comunicação entre técnicos e gestores. Modelagem

Leia mais

Indice. Parte I - Um Modelo de Gestão de Projectos. Introdução... 1

Indice. Parte I - Um Modelo de Gestão de Projectos. Introdução... 1 r Indice Introdução.......................................... 1 Parte I - Um Modelo de Gestão de Projectos 1- Características da Gestão de Projectos 11 1.1 Definição de Projecto 11 1.2 Projectos e Estratégia

Leia mais

Unidade II MODELAGEM DE PROCESSOS

Unidade 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 mais

Diagrama de transição de Estados (DTE)

Diagrama de transição de Estados (DTE) Diagrama de transição de Estados (DTE) O DTE é uma ferramenta de modelação poderosa para descrever o comportamento do sistema dependente do tempo. A necessidade de uma ferramenta deste tipo surgiu das

Leia mais

Material para os Discentes da Universidade da Madeira. NP EN ISO 9000, 9001 e 9004. Elaborado em 2005 por. Herlander Mata-Lima

Material para os Discentes da Universidade da Madeira. NP EN ISO 9000, 9001 e 9004. Elaborado em 2005 por. Herlander Mata-Lima Material para os Discentes da Universidade da Madeira NP EN ISO 9000, 9001 e 9004 Elaborado em 2005 por Herlander Mata-Lima 1 NORMAS ISO 9000 As normas ISO 9000 servem de base para as organizações, independentemente

Leia mais

5. Métodos ágeis de desenvolvimento de software

5. Métodos ágeis de desenvolvimento de software Engenharia de Software 5. Métodos ágeis de desenvolvimento de software Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Desenvolver e entregar software o mais rapidamente possível é hoje em dia um dos

Leia mais

A coleta de requisitos se refere ao processo de determinar, documentar e gerenciar as necessidades e requisitos das partes interessadas;

A coleta de requisitos se refere ao processo de determinar, documentar e gerenciar as necessidades e requisitos das partes interessadas; Aula 07 1 2 A coleta de requisitos se refere ao processo de determinar, documentar e gerenciar as necessidades e requisitos das partes interessadas; A principal vantagem deste processo é a criação de uma

Leia mais

Gestão dos Níveis de Serviço

Gestão dos Níveis de Serviço A Gestão dos Níveis de Serviço (SLM) Os sistemas e tecnologias de informação e comunicação têm nas empresas um papel cada vez mais importante evoluindo, hoje em dia, para níveis mais elevados de funcionamento

Leia mais

Sumário. Engenharia de Software. Gestão da Complexidade. Objectivos. Engenharia de Software

Sumário. Engenharia de Software. Gestão da Complexidade. Objectivos. Engenharia de Software Engenharia de Software Engenharia de Software António Rito Silva Rito.Silva@inesc-id.pt Objectivos Problemas Qualidades Técnicas Conclusões Referências Sumário Engenharia de Software 2 Objectivos A engenharia

Leia mais

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software.

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software. Processos de Software Objetivos Apresentar os modelos de processo de software Conjunto coerente de atividades para especificar, projetar, implementar e testar s de software Descrever os diferentes modelos

Leia mais

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)

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) 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 mais

Análise OO. Análise. Antónia Lopes Desenvolvimento C. Objectos 09/10. Antónia Lopes

Análise OO. Análise. Antónia Lopes Desenvolvimento C. Objectos 09/10. Antónia Lopes Análise OO 36 Análise Análise é a investigação do problema Análise de Requisitos é o termo que designa a investigação das necessidades e condições que o sistema, e o projecto em geral, têm de satisfazer.

Leia mais

Modelos Conceptual e Mental

Modelos Conceptual e Mental Interfaces Pessoa Máquina 08-10-2012 Modelos Conceptual e Mental Cap. 6 Conceptualização da Interação 06 Melhor e Pior? 1 Melhor e Pior? Resumo Aula Anterior Análise de Utilizadores O que é? Porquê? O

Leia mais

Análise de Requisitos Conceitos

Análise de Requisitos Conceitos Tema da Aula Conceitos Prof. Cristiano R R Portella portella@widesoft.com.br Analisar (v) 1. Decompor um todo em partes, componentes; fazer análise 2. Observar, examinar com minúcia; esquadrinhar 3. Examinar

Leia mais

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia

Leia mais

Requisitos de Software. Teresa Maciel DEINFO/UFRPE

Requisitos de Software. Teresa Maciel DEINFO/UFRPE Requisitos de Software Teresa Maciel DEINFO/UFRPE 1 Requisito de Software Características que o produto de software deverá apresentar para atender às necessidades e expectativas do cliente. 2 Requisito

Leia mais

Metodos de Programação

Metodos de Programação Metodos de Programação Métodos de Programação Introdução Informática, Computador, Algoritmo Informática: Ciência do processamento da informação Computador: Máquina que serve para processar informação Algoritmo:

Leia mais

PROFESSOR: CRISTIANO MARIOTTI

PROFESSOR: CRISTIANO MARIOTTI PROFESSOR: CRISTIANO MARIOTTI Conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software; Considerado um dos principais mecanismos para se obter software de qualidade

Leia mais

Gestão da Informação

Gestão da Informação Gestão da Informação Aplicações de suporte à Gestão da Informação na empresa Luis Borges Gouveia, lmbg@ufp.pt Aveiro, Fevereiro de 2001 Sistemas de informação para empresas Manutenção e exploração de sistemas

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Conteúdo Definição Questionamentos Típicos Visão Geral Ciclo de Vida dos Requisitos Síntese dos Objetivos Gerência de Mudança Identificação de Requisitos Classificação de Requisitos

Leia mais

Análise de Sistemas. Visão Geral: Orientação a Objetos. Prof. José Honorato Ferreira Nunes honorato.nunes@bonfim.ifbaiano.edu.br

Análise de Sistemas. Visão Geral: Orientação a Objetos. Prof. José Honorato Ferreira Nunes honorato.nunes@bonfim.ifbaiano.edu.br Análise de Sistemas Visão Geral: Orientação a Objetos Prof. José Honorato Ferreira Nunes Prof. José Honorato Ferreira Nunes honorato.nunes@bonfim.ifbaiano.edu.br Resumo: VISÃO GERAL: Modelagem de sistemas

Leia mais

! Software e Engenharia de Software! Engenharia de Software e Programação! Histórico. " Crise do Software

! Software e Engenharia de Software! Engenharia de Software e Programação! Histórico.  Crise do Software Agenda Introdução a Engenharia de Cleidson de Souza cdesouza@ufpa.br http://www.ufpa.br/cdesouza! e Engenharia de! Engenharia de e Programação! Histórico " Crise do! No Silver Bullet! Fases Genéricas do

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

Informática II Cap. 3

Informática II Cap. 3 Cap. 3 1 Tradicionalmente, programar significava apenas a escrita de um programa, que resolvesse o problema pretendido de uma forma aparentemente correcta. Problema Problema Programa Programa Desvantagens:

Leia mais

Gerência de Projetos

Gerência de Projetos Gerência de Projetos Escopo Custo Qualidade Tempo CONCEITO PROJETOS: são empreendimentos com objetivo específico e ciclo de vida definido Precedem produtos, serviços e processos. São utilizados as funções

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Roteiro Análise de requisitos Definição de requisitos do sistema Requisitos Funcionais Requisitos Não Funcionais Exercício Análise de Requisitos Análise de Requisitos É o 1º passo

Leia mais

GARANTIA DA QUALIDADE DE SOFTWARE

GARANTIA DA QUALIDADE DE SOFTWARE GARANTIA DA QUALIDADE DE SOFTWARE Fonte: http://www.testexpert.com.br/?q=node/669 1 GARANTIA DA QUALIDADE DE SOFTWARE Segundo a NBR ISO 9000:2005, qualidade é o grau no qual um conjunto de características

Leia mais

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Engenharia de Software II: Criando a Declaração de Escopo Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Sumário Desenvolvendo o Plano de Gerenciamento do Projeto. Coletando Requisitos. Declarando

Leia mais

UML Visão Geral. Índice. Introdução. Diagramas. Modelos e diagramas. Elementos de modelação. Referências

UML Visão Geral. Índice. Introdução. Diagramas. Modelos e diagramas. Elementos de modelação. Referências UML Visão Geral 1 Índice Introdução O que é a UML? Valor da UML Origens da UML Parceiros da UML Modelos e diagramas Elementos de modelação Diagramas Diagrama de casos de utilização Diagrama de classes

Leia mais

build UNIP Sistemas de Informação Análise Essencial de Sistemas 3 Prof.Marcelo Nogueira A produção de Software é uma atividade build and fix.

build UNIP Sistemas de Informação Análise Essencial de Sistemas 3 Prof.Marcelo Nogueira A produção de Software é uma atividade build and fix. UNIP Sistemas de Informação Análise Essencial de Sistemas Prof.Marcelo Nogueira Análise Essencial de Sistemas 1 Introdução A produção de Software é uma atividade build and fix. Análise Essencial de Sistemas

Leia mais

Instituto Superior Politécnico de VISEU. Escola Superior de Tecnologia

Instituto Superior Politécnico de VISEU. Escola Superior de Tecnologia 1 Tradicionalmente, programar significava apenas a escrita de um programa, que resolvesse o problema pretendido de uma forma aparentemente correcta. Problema Problema Programa Programa Desvantagens: Programas

Leia mais

4.2. UML Diagramas de classes

4.2. UML Diagramas de classes Engenharia de Software 4.2. UML Diagramas de classes Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Um diagrama de classes serve para modelar o vocabulário de um sistema Construído e refinado ao longo

Leia mais

Diagrama de entidades relacionamentos (abordado anteriormente) Diagrama de Fluxo de Dados (DFD)

Diagrama de entidades relacionamentos (abordado anteriormente) Diagrama de Fluxo de Dados (DFD) Diagrama de entidades relacionamentos (abordado anteriormente) Prod_Forn N N 1 Stock 1 1 N Prod_Enc N 1 N 1 Fornecedor Movimento Encomenda Diagrama de Fluxo de Dados (DFD) Ferramenta de modelação gráfica,

Leia mais

Guia de orientação Criação do Próprio Emprego

Guia de orientação Criação do Próprio Emprego B- Criação do próprio emprego pag. 57 Para quem deseja ter uma actividade independente, por conta própria, a criação do seu próprio emprego é uma via alternativa para ingressar no mundo do trabalho. Criar

Leia mais

Engenharia de Software

Engenharia de Software Conceitos básicos sobre E.S: Ambiência Caracterização do software Fases de desenvolvimento 1 Introdução Aspectos Introdutórios Crise do Software Definição de Engenharia do Software 2 Crise do Software

Leia mais

Que Liderança hoje? A Transformação acontece aqui e agora o que permanecerá? Mentoring, Tutoring, Coaching A Inteligência Emocional

Que Liderança hoje? A Transformação acontece aqui e agora o que permanecerá? Mentoring, Tutoring, Coaching A Inteligência Emocional Que Liderança hoje? A Transformação acontece aqui e agora o que permanecerá? Mentoring, Tutoring, Coaching A Inteligência Emocional Estamos numa encruzilhada Não é a falta de saídas que é problemática,

Leia mais

ICORLI. INSTALAÇÃO, CONFIGURAÇÃO e OPERAÇÃO EM REDES LOCAIS e INTERNET

ICORLI. INSTALAÇÃO, CONFIGURAÇÃO e OPERAÇÃO EM REDES LOCAIS e INTERNET INSTALAÇÃO, CONFIGURAÇÃO e OPERAÇÃO EM REDES LOCAIS e INTERNET 2010/2011 1 Protocolo TCP/IP É um padrão de comunicação entre diferentes computadores e diferentes sistemas operativos. Cada computador deve

Leia mais

Boas Práticas em Gerenciamento de Projetos Material utilizado nas aulas de Pós-graduação do Centro de Informática 2010.2

Boas Práticas em Gerenciamento de Projetos Material utilizado nas aulas de Pós-graduação do Centro de Informática 2010.2 O que é um? s: Tradicional e/ou Ágil? Cristine Gusmão, PhD Tem início e fim bem determinados Things are not always what they seem. Phaedrus, Escritor e fabulista Romano O projeto é uma sequência única,

Leia mais

Pesquisa realizada com os participantes do 12º Seminário Nacional de Gestão de Projetos. Apresentação

Pesquisa realizada com os participantes do 12º Seminário Nacional de Gestão de Projetos. Apresentação Pesquisa realizada com os participantes do de Apresentação O perfil do profissional de Projetos Pesquisa realizada durante o 12 Seminário Nacional de, ocorrido em 2009, traça um importante perfil do profissional

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 3 Teste Estático SUMÁRIO INTRODUÇÃO... 3 1. Definição... 3 2. Custo Versus Benefício...

Leia mais

NP EN ISO 9001:2000 LISTA DE COMPROVAÇÃO

NP EN ISO 9001:2000 LISTA DE COMPROVAÇÃO NP EN ISO 9001:2000 LISTA DE COMPROVAÇÃO NIP: Nº DO RELATÓRIO: DENOMINAÇÃO DA EMPRESA: EQUIPA AUDITORA (EA): DATA DA VISITA PRÉVIA: DATA DA AUDITORIA: AUDITORIA DE: CONCESSÃO SEGUIMENTO ACOMPANHAMENTO

Leia mais

Gerenciamento de projetos. cynaracarvalho@yahoo.com.br

Gerenciamento de projetos. cynaracarvalho@yahoo.com.br Gerenciamento de projetos cynaracarvalho@yahoo.com.br Projeto 3URMHWR é um empreendimento não repetitivo, caracterizado por uma seqüência clara e lógica de eventos, com início, meio e fim, que se destina

Leia mais

Persistência e Banco de Dados em Jogos Digitais

Persistência e Banco de Dados em Jogos Digitais Persistência e Banco de Dados em Jogos Digitais Prof. Marcos Francisco Pereira da Silva Especialista em Engenharia de Software Jogos Digitais - Computação Gráfica 1 Agenda Vantagens de usar a abordagem

Leia mais

Conceito. As empresas como ecossistemas de relações dinâmicas

Conceito. As empresas como ecossistemas de relações dinâmicas Conceito As empresas como ecossistemas de relações dinâmicas PÁG 02 Actualmente, face à crescente necessidade de integração dos processos de negócio, as empresas enfrentam o desafio de inovar e expandir

Leia mais

Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores

Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores Primeiro Teste 21 de Outubro de 2006, 9:00H 10:30H Nome: Número:

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Centro de Informática - Universidade Federal de Pernambuco Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville e adaptado pelos professores Márcio Cornélio,

Leia mais

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 UML 2 Guia Prático Gilleanes T.A. Guedes Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 Novatec capítulo 1 Introdução à UML A UML (Unified Modeling Language ou Linguagem de Modelagem

Leia mais