Engenharia de Software
|
|
- Osvaldo Botelho Wagner
- 8 Há anos
- Visualizações:
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 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 maisEngenharia 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 maisExtraçã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 maisProjeto 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 maisEngenharia 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 maisUML - 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 mais3. 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 maisEngenharia 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 maisMODELAGEM 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 maisNa 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 maisEngenharia 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 maisUNIVERSIDADE 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 maisPROCESSO 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 mais2 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 maisO 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 maisRequisitos. 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 maisRequisitos 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 maisModelos 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 maisEngenharia 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 maisAná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 maisRequisitos 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 maisSAD 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
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 maisAPOO 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 maisVerificaçã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 maisAná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 maisGestão do Risco e da Qualidade no Desenvolvimento de Software
Gestão do Risco e da Qualidade no Desenvolvimento de Software Questionário Taxinómico do Software Engineering Institute António Miguel 1. Constrangimentos do Projecto Os Constrangimentos ao Projecto referem-se
Leia maisTRANSIÇÃ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 maisAná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 maisGereComSaber. 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 maisDesenvolvimento 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 maisDesenvolvimento 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 maisEngenharia 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 maisResumo 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 maisISO 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 maisAná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 maisUNIDADE 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 maisUnified 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 maisFase 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 maisParte 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 maisARQUITECTURAS 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 maisEngenharia 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 maisCAP. 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 maisO 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 maisDesenho 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 maisENGENHARIA 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 maisDiagrama 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 maisIntroduçã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 maisEspecificaçã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 maisUnisant 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 maisIndice. 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 maisUnidade II MODELAGEM DE PROCESSOS
Unidade II 3 MODELAGEM DE SISTEMAS 1 20 A fase de desenvolvimento de um novo sistema de informação (Quadro 2) é um momento complexo que exige um significativo esforço no sentido de agregar recursos que
Leia maisDiagrama 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 maisMaterial 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 mais5. 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 maisA 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 maisGestã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 maisSumá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 maisObjetivos. 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 maisAnálise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO)
Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO) Parte: 1 Prof. Cristóvão Cunha Objetivos de aprendizagem
Leia maisAná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 maisModelos 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 maisAná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 maisMetodologias 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 maisRequisitos 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 maisMetodos 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 maisPROFESSOR: 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 maisGestã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 maisEngenharia 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 maisAná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
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 maisLEVANTAMENTO 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 maisInformá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 maisGerê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 maisEngenharia 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 maisGARANTIA 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 maisEngenharia 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 maisUML 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 maisbuild 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 maisInstituto 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 mais4.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 maisDiagrama 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 maisGuia 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 maisEngenharia 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 maisQue 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 maisICORLI. 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 maisBoas 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 maisPesquisa 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 maisFundamentos 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 maisNP 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 maisGerenciamento 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 maisPersistê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 maisConceito. 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 maisArquitecturas 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 maisRequisitos 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 maisUML 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