Especificação de Sistemas e Especificação de Requisitos
|
|
- Walter Covalski Teves
- 8 Há anos
- Visualizações:
Transcrição
1 Especificação de Sistemas e Especificação de Requisitos Universidade Federal do Estado do Rio de Janeiro Centro de Ciências Exatas e Tecnologia Escola de Informática Aplicada Curso: Bacharelado em Sistemas de Informação Disciplina: Construção de Sistemas Professor: Luiz Fernando Seibel Grupo: Eduardo Henrique Cavalcante Fontanha de Oliveira Pedro Nuno de Souza Moura
2 Apresentação Tem este trabalho por objetivo funcionar como um guia à apresentação sobre Especificação de Sistemas e Especificação de Requisitos da disciplina de Construção de Sistemas. Assim sendo, cabe explicitar qual o objetivo da etapa de Especificação de Sistemas. Esta tem como pilar sustentador a definição dos aspectos concernentes ao sistema, ou seja, qual o processo atual empregado na empresa, quais os problemas a serem resolvidos e a definição do escopo do sistema. Dessa forma, deve-se, portanto, descrever não só tais propriedades, como também quais tecnologias serão utilizadas no desenvolvimento do sistema e a própria metodologia de trabalho. Analogamente, a etapa de Especificação de Requisitos visa à elicitação, isto é, ao levantamento dos requisitos funcionais que o sistema deve ter, bem como às restrições impostas sobre como o sistema deve executar tais funcionalidades, ou seja, os requisitos não-funcionais. Ademais, é salutar discriminar os não-requisitos (requisitos não-contemplados), aqueles que não serão atendidos pelo sistema. A fim de que o texto e, conseqüentemente, a apresentação, se torne claro e de fácil compreensão, os assuntos compreendidos pela etapa de Especificação de Sistemas serão abordados em tópicos: Visão Geral do Problema Num primeiro momento, após serem definidos o nome do sistema e o propósito deste, deve-se obter a visão geral do problema a ser resolvido. Sendo assim, é feita uma descrição do processo atual da empresa. Nesta, o processo de negócio da empresa é detalhadamente descrito, a fim de que sejam entendidas as necessidades do cliente e o próprio domínio. Além disso, devem ser identificadas outras áreas ou empresas, isto é, entidades externas, que também estarão envolvidas no projeto. É recomendável e interessante utilizar um Diagrama de Atividades para representar tal processo de negócio, facilitando, assim, a visualização do fluxo de processo da empresa. Como exemplo, segue na próxima página um Diagrama de Atividades que descreve o processo de negócio de um ambiente de gerência de tarefas em uma empresa de desenvolvimento de software.
3 Além disso, devem ser levantados os problemas atualmente encontrados. É devido, pois, descrever o referido problema, quais os afetados, quais as conseqüências e sugerir possíveis soluções. Acima de tudo, obteve-se, portanto, uma descrição do processo de negócio da empresa e de seu domínio. A descrição dos problemas a que o sistema se propõe a tratar são de grande valia, dado que auxiliam na definição dos requisitos de negócio e fornecem uma visão aplicada do sistema.
4 Identificação dos Envolvidos Nesta parte, procura-se definir os perfis dos usuários que irão não só utilizar a versão executável do sistema, como também auxiliar o analista a destrinchar o domínio sendo estudado. Desse modo, é conveniente descrever os perfis dos usuários, apontando suas responsabilidades, os resultados esperados e os critérios de sucesso, e o ambiente destes, delineando restrições físicas e sistemas/plataformas utilizados atualmente ou que possam ser utilizados no futuro. Esta atividade é de extrema utilidade, visto que as informações aqui obtidas se farão necessárias à especificação de Requisitos Não-Funcionais e à etapa de Implantação, em que o sistema será delineado ao ambiente do usuário descrito já nesta parte. Requisitos de Negócio Durante a etapa de Especificação de Sistemas, diversas visitas ao ambiente de trabalho da empresa serão feitas, dado que se faz necessário conhecer o processo de negócio, entender os problemas correntes, iniciar o entendimento do domínio e outros aspectos. Contudo, faz-se imperiosa uma reunião com os gerentes da empresa a fim de que sejam definidos os Requisitos de Negócio. Tais requisitos são necessidades que o fluxo de processo atual da empresa demanda, ou seja, são problemas de que os gerentes da empresa têm conhecimento e procuram resolvê-los. Para cada requisito apontado e analisado na reunião, devem ser discriminadas as razões de cada problema, como são resolvidos atualmente (solução atual) e qual a solução que o cliente deseja ou precisa (solução proposta). Note-se que tal solução proposta é sob a óptica dos clientes. É recomendável, ainda, listar tais requisitos de maneira que os de maior prioridade, ou seja, os que foram apontados mais vezes, venham antes. Tornase de fácil percepção, portanto, que deve ser feita uma entrevista tanto com os clientes quando com os usuários. Ademais, o responsável por esta parte deve ser o Analista de Negócio, mais experiente e treinado para efetuar visitas ao ambiente da empresa e levantar problemas e necessidades. Tecnologia/Restrições Tecnológicas Esta parte constitui o pilar sobre o qual a fase de Especificação de Sistemas está consolidada. Nesta, devem ser listadas e descritas minuciosamente quais as tecnologias que serão empregadas no desenvolvimento do sistema. Dessa forma, deve-se citar a linguagem, ferramentas CASE, ambientes de desenvolvimento integrado (IDE), arquitetura e outros a serem utilizados. Frameworks de desenvolvimento também devem ser citados. Além de tais aspectos, devem ser citadas restrições tecnológicas que o próprio domínio da aplicação imponha.
5 Visão da Solução Após tais etapas de compreensão do problema, definição dos macrorequisitos e especificação das tecnologias a serem empregadas, deve-se descrever o sistema de uma maneira mais incisiva. A visão da solução é o cerne disto. Esta pode ser decomposta em: o Descrição do Sistema: Listagem e descrição das características do sistema a ser implementado. Note-se que não ainda devem ser listados aqui os requisitos funcionais. É recomendado esboçar um Diagrama de Atividades com o fluxo para a possível solução para o sistema. o Escopo do Sistema: O que será abrangido, isto é, delineado pelo sistema. Dentre os Requisitos de Negócio apontados, citar aqueles que serão tratados pelo sistema. o Fronteira do Sistema: Fazer um desenho que mostre a interface do sistema com pessoas, entidades externas ou outros sistemas. Faz-se de extrema importância na definição dos atores dos Casos de Uso. o Benefícios Esperados: Listagem e descrição do conjunto de benefícios que são esperados com a solução proposta. o Impactos do Sistema: Quais mudanças são esperadas acontecer no ambiente de operação do sistema. o Critérios de Aceite: Critérios definidos pelos clientes que serão utilizados para validar se o sistema está atendendo às expectativas e faz tudo aquilo que lhe foi proposto. Riscos Deve-se destinar atenção especial aos riscos do projeto. Estes podem atrapalhar em demasia o andamento de um projeto ou até mesmo impedir a conclusão deste. Logo, os riscos do projeto devem ser listados e descritos. A sua descrição consiste no impacto que podem causar. Postos tais preceitos sobre a etapa de Especificação de Sistemas, devese analisar a etapa de Especificação de Requisitos. Esta tem como objetivo levantar/coletar os requisitos do sistema, que são as características, as propriedades, necessárias no sistema. Algumas técnicas para elicitação de requisitos são: o Entrevistas Individuais: Consiste em entrevistas com os gerentes, bem como com os usuários do sistema. Por meio de tal fato, busca-
6 se extrair os problemas correntes no processo de negócio, as necessidades de tais pessoas e seus desejos. o Brainstorming e Brainwriting: O Brainstorming se caracteriza por uma sessão de discussão da equipe de desenvolvimento em conjunto com os clientes e usuários, a fim de que idéias sejam geradas e sejam identificadas as necessidades dos clientes. O Brainwriting é similar ao Brainstorming, porém, em vez de utilizar o meio oral, as pessoas expõem as suas idéias em pedaço de papel. Posteriormente, um membro da equipe lê todos os papéis, que não estão identificados, em voz alta e, então, a idéia é debatida. A vantagem é que pessoas mais tímidas podem participar de maneira ativa, ao passo que no Brainstorming não o podem. Além disso, no Brainstorming boas idéias são geradas, mas, pelo fato de ninguém tomar nota, são esquecidas. o Reutilização de requisitos de projetos anteriores: Caso a empresa de desenvolvimento do software já tenha trabalhado com um domínio similar, então pode reaproveitar os requisitos levantados para tal projeto. Desse modo, economiza tempo e utiliza requisitos que indubitavelmente são consistentes. o Estudo de documentos: Nesta abordagem, documentos do domínio são estudados e analisados, a fim de que sejam identificadas as necessidades e restrições. Relatórios e formulários da empresa também são analisados. Esta abordagem é vantajosa quando utilizada em conjunto com a Metodologia de Desenvolvimento Cleanroom, que é destinada a sistemas que possuem riscos de quebra de patente, e garante que os programadores vão fazer aquilo que foi especificado. o Observação do ambiente de implantação: Consiste em fazer visitas ao ambiente da empresa e observar o seu processo de negócio, como agem os seus funcionários e quais lacunas existem. Assim sendo, identifica os problemas e, conseqüentemente, as necessidades da empresa. o JAD (Join Application Development): Há um coordenador e um anotador. O coordenadora vai entrevistando os clientes e debatendo com eles acerca das funcionalidades, ao passo que o anotador vai registrando aquilo que estiver sendo gerado. Os requisitos podem ser classificados de duas maneiras: o Requisitos Funcionais: Correspondem ao que o sistema deve fazer, ou seja, suas funcionalidades; e o Requisitos Não-Funcionais: São restrições impostas sobre como o sistema deve realizar seus requisitos funcionais.
7 Os Requisitos Funcionais podem ser classificados de duas maneiras: o Requisitos Funcionais Evidentes: São aqueles realizados com o conhecimento explícito do usuário. Correspondem à troca de informação na fronteira do sistema, isto é, com o meio exterior; e o Requisitos Funcionais Ocultos: São aqueles efetuados pelo sistema sem o conhecimento do usuário. Por sua vez, os Requisitos Não-Funcionais podem ser classificados de duas maneiras: obrigatórios e desejados. Os obrigatórios são aqueles que invariavelmente devem ser implementados. Já os desejados são aqueles que podem ser implementados caso não causem maiores transtornos ao projeto. Além disso, os requisitos não-funcionais podem ser classificados por características: de interface, de implementação, de eficiência, de tolerância a falhas, etc. Também podem ser classificados como permanentes (nunca mudará com o tempo) ou transitórios (pode sofrer alterações no futuro). Mais especificamente, os requisitos não-funcionais podem possuir as seguintes categorias: o Usabilidade: O sistema ser user-friendly, ser de fácil uso e aprendizado. Desse modo, deve fornecer menus de ajuda para o usuário e/ou manuais. o Confiabilidade: É o fato de o sistema possuir tratamento de falhas. Especifica quais falhas o sistema será capaz de gerenciar. o Performance: São requisitos de eficiência e precisão que o sistema apresenta. o Configurabilidade: O que pode ser configurado no sistema. o Segurança: São os níveis de acesso e a que funcionalidades cada um tem acesso. o Implementação: A linguagem a ser utilizada e que bancos de dados estarão acessíveis. o Interface: Especifica como deve ser a interface. o Empacotamento: Especifica a forma como o software deve ser entregue ao usuário final. o Legais: Quais os procedimentos que devem ser tomados para que não sejam infringidas normas e regras da área a que o sistema se propõe. No que tange à organização dos requisitos, é interessante dividi-los em: o Casos de Uso: As funcionalidades do sistema para que os usuários atinjam seus objetivos. o Conceitos: Para cada conceito do domínio identificado, listar quais as operações que podem ser realizadas em relação a ele, ou seja, inclusão, exclusão, alteração e consulta. o Consultas: Acesso à informação do sistema que não altera o dado em si.
8 Dessa forma, o Diagrama de Casos de Uso passar a conter apenas as funcionalidades necessárias para que os atores, de fato, atinjam seus objetivos. Torna, pois, mais inteligível o diagrama, facilitando a visualização. Cabe destaque aos Não-Requisitos (Requisitos Não-Contemplados), que são aqueles que foram analisados e revisados com os usuários e não serão implementados devido a problemas de custo, prazos ou outros. É importante ter isso documentado e assinado pelos clientes para que estes, futuramente, não cobrem algo que foi anteriormente acordado em relação ao não-desenvolvimento. Por fim, a importância da especificação de requisitos é que esta estabelece o entendimento entre clientes e fornecedores da solução. Serve, também, como referência para a validação final dos produtos. Sabe-se, ainda, que o investimento na verificação de uma especificação tende a reduzir o custo total do projeto. Ao término da especificação de requisitos, é gerado o documento conhecido como Documento de Requisitos de Software ou Especificação de Requisitos de Software (Software Requirements Specification SRS). O apêndice Documento de Requisitos de Software serve como exemplo de um documento que pode ser gerado nas etapas supracitadas, isto é, de especificação de sistemas e requisitos. A criação de modelos é de suma importância em tais etapas, a fim de seja obtido o entendimento do problema e que seja facilitada a comunicação entre os envolvidos no projeto. Um modelo é uma simplificação da realidade que nos ajuda a entender um problema grande e complexo que não pode ser compreendido como um todo. (Phillipe Krutchen, 2000). Cabe citar os modelos gerados em tais etapas: Diagrama de Atividades: Tem como objetivo fazer uma representação do fluxo de trabalho (workflow) do processo de negócio da empresa a que o sistema se propõe a automatizar. Ademais, pode também ser utilizado para descrever o fluxo principal de um Caso de Uso que tenha complexidade considerável (crítico). Um exemplo de diagrama já foi exposto neste texto. Diagrama de Casos de Uso: Representa interações entre atores (pessoas, entidades externas, periféricos ou outros sistemas) e o sistema em questão, a fim de que seja realizada uma funcionalidade. Descreve, pois, os requisitos funcionais do sistema. Garante o entendimento do requisitos e pode ser utilizado como uma espécie de contrato do sistema. Em outras palavras, ao término do desenvolvimento, o sistema tem estar realizando todas as funcionalidades que foram discriminadas no Diagrama de Casos de Uso. Um exemplo de tal diagrama sobre um Sistema de Gerência de Tarefas segue na próxima página:
9
10 Modelo Conceitual: Descrevem os principais conceitos de um dado domínio, bem como suas propriedades e associações. Em uma visão mais aplicada, descreve quais serão as informações a serem guardadas no banco de dados. Os modelos conceituais mais disseminados são o Diagrama de Entidade-Relacionamento (DER) e o Diagrama de Classes e Objetos. Um exemplo de Diagrama de Classes e Objetos referente a um domínio de um Sistema de Gerência de Tarefas segue abaixo: Pela análise realizada, torna-se fácil percepção que o investimento e a aplicação em uma especificação de sistemas e de requisitos bem feita é extremamente aconselhável, dado que tende a diminuir a incidência de falhas nas etapas posteriores do ciclo de vida de desenvolvimento. Ademais, seja citada esta estatística: custo de um erro na fase de projeto = 1 unidade; custo de um erro no início dos testes = 6.5 unidades; durante os testes = 15 unidades; depois de liberado o software = 60 a 100 unidades.
11 Bibliografia 1. BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. Rio de Janeiro: Campus, WAZLAWICK, Raul Sidnei. Análise e Projeto de Sistemas de Informação Orientados a Objetos. Rio de Janeiro: Elsevier, Material didático do professor Asterio Tanaka, referente à disciplina de Modelagem de Sistemas, no período de 2005/2 do curso de Sistemas de Informação da UNIRIO. Disponível em: 4. Material didático da professora Renata Araújo, referente à disciplina de Análise e Projeto de Sistemas, no período de 2006/1 do curso de Sistemas de Informação da UNIRIO. Disponível em: 5. Material didático do professor Leonardo Azevedo, referente à disciplina de Projeto e Construção de Sistemas com Ambiente de Programação, no período de 2006/2 do curso de Sistemas de Informação da UNIRIO. Disponível em: 6. Notas de aula da disciplina de Modelagem de Sistemas, do curso de Sistemas de Informação da UNIRIO, ministrada pelo professor Asterio Tanaka no período de 2005/2. 7. Notas de aula da disciplina de Análise e Projeto de Sistemas, do curso de Sistemas de Informação da UNIRIO, ministrada pela professora Renata Araújo no período de 2006/1. 8. Notas de aula da disciplina de Projeto e Construção de Sistemas com Ambiente de Programação, do curso de Sistemas de Informação da UNIRIO, ministrada pelo professor Leonardo Azevedo no período de 2006/2.
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 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 maisAnálise e Projeto Orientados a Objetos Aula IV Requisitos. Prof.: Bruno E. G. Gomes IFRN
Análise e Projeto Orientados a Objetos Aula IV Requisitos Prof.: Bruno E. G. Gomes IFRN 1 Introdução Etapa relacionada a descoberta e descrição das funcionalidades do sistema Parte significativa da fase
Leia maisO modelo unificado de processo. O Rational Unified Process, RUP.
Cursos: Sistemas de Informação Disciplina: Administração ADM Prof. Jarbas Avaliação: Prova B1, 5º/6º semestres Data: 27/09/2010 Nome: Gabarito RA: Assinatura: Turma: 1) Segundo as afirmações a seguir,
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 maisProcessos de Desenvolvimento de Software
Processos de Desenvolvimento de Software Gerenciamento de Projetos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e
Leia maisCiência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software
Ciência da Computação ENGENHARIA DE SOFTWARE Análise dos Requisitos de Software Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução Tipos de requisitos Atividades Princípios da
Leia maisProf. Raul Sidnei Wazlawick UFSC-CTC-INE. Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010.
Visão Geral do Sistema Prof. Raul Sidnei Wazlawick UFSC-CTC-INE 2010 Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010. A fase de concepção do UP consiste
Leia maisTópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619
Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o
Leia maisGerenciamento de Problemas
Gerenciamento de Problemas O processo de Gerenciamento de Problemas se concentra em encontrar os erros conhecidos da infra-estrutura de TI. Tudo que é realizado neste processo está voltado a: Encontrar
Leia maisDocumento de Requisitos
Documento de Requisitos Projeto: Data 26/05/2005 Responsável Autor (s) Doc ID Localização Versão do Template Márcia Jacyntha Nunes Rodrigues Lucena Silvia Cássia Pereira Márcia Jacyntha Nunes Rodrigues
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 maisApesar de existirem diversas implementações de MVC, em linhas gerais, o fluxo funciona geralmente da seguinte forma:
1 Introdução A utilização de frameworks como base para a construção de aplicativos tem sido adotada pelos desenvolvedores com três objetivos básicos. Primeiramente para adotar um padrão de projeto que
Leia maisO Processo Unificado: Captura de requisitos
O Processo Unificado: Captura de requisitos Itana Gimenes Graduação em Informática 2008 Captura de Requisitos Modelagem do negócio: Visão de negócios Modelo de objetos de negócio de negócio Especificação
Leia maisELABORAÇÃO DO PLANO DE TRABALHO
CAPÍTULO 02 ELABORAÇÃO DO PLANO DE TRABALHO Simplificação Administrativa Planejamento da Simplificação Pré-requisitos da Simplificação Administrativa Elaboração do Plano de Trabalho Mapeamento Mapeamento
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 maisLEVANTAMENTO DE REQUISITOS DE FORMA ENXUTA
LEVANTAMENTO DE REQUISITOS DE FORMA ENXUTA Kleber Lopes Petry Éder Moretto Garcia Rodrigo Clemente Thom de Souza Proposta de processo para levantamento de requisitos para desenvolvimento de produtos de
Leia maisARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.
ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página
Leia maisEngenharia de Software III
Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,
Leia maisPLANOS DE CONTINGÊNCIAS
PLANOS DE CONTINGÊNCIAS ARAÚJO GOMES Capitão SC PMSC ARAÚJO GOMES defesacivilgomes@yahoo.com.br PLANO DE CONTINGÊNCIA O planejamento para emergências é complexo por suas características intrínsecas. Como
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 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 maisISO/IEC 12207: Gerência de Configuração
ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que
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 maisGovernança de TI. ITIL v.2&3. parte 1
Governança de TI ITIL v.2&3 parte 1 Prof. Luís Fernando Garcia LUIS@GARCIA.PRO.BR ITIL 1 1 ITIL Gerenciamento de Serviços 2 2 Gerenciamento de Serviços Gerenciamento de Serviços 3 3 Gerenciamento de Serviços
Leia maisProf. Raul Sidnei Wazlawick UFSC-CTC-INE. Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010.
Casos de Uso de Alto Nível Prof. Raul Sidnei Wazlawick UFSC-CTC-INE 2010 Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010. Contexto Na fase de concepção
Leia maisPós-Graduação em Gerenciamento de Projetos práticas do PMI
Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL
Leia maisFelipe Denis M. de Oliveira. Fonte: Alice e Carlos Rodrigo (Internet)
UML Felipe Denis M. de Oliveira Fonte: Alice e Carlos Rodrigo (Internet) 1 Programação O que é UML? Por quê UML? Benefícios Diagramas Use Case Class State Interaction Sequence Collaboration Activity Physical
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 maisDocumento de Arquitetura
Documento de Arquitetura A2MEPonto - SISTEMA DE PONTO ELETRÔNICO A2MEPonto - SISTEMA DE PONTO ELETRÔNICO #1 Pág. 1 de 11 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 28/10/2010 1 Elaboração do documento
Leia maisAuditoria e Segurança da Informação GSI536. Prof. Rodrigo Sanches Miani FACOM/UFU
Auditoria e Segurança da Informação GSI536 Prof. Rodrigo Sanches Miani FACOM/UFU Aula passada Pergunta É possível saber se as normas, políticas, procedimentos, processos e controles adotados estão funcionando
Leia maisIntrodução à Engenharia de Software
Introdução à Engenharia de Software Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Imagem Clássica Objetivo da aula Depois desta aula você terá uma visão sobre o que é a engenharia
Leia maisCONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES
CELG DISTRIBUIÇÃO S.A EDITAL N. 1/2014 CONCURSO PÚBLICO ANALISTA DE GESTÃO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI RESPOSTAS ESPERADAS PRELIMINARES O Centro de Seleção da Universidade Federal de Goiás
Leia maisHistórico da Revisão. Data Versão Descrição Autor
Sistema de Gerenciamento de Loja - SIGEL Documento de Visão Versão 1.0.0 Histórico da Revisão Data Versão Descrição Autor 13/01/2011 0.1 Versão preliminar do levantamento de requisitos funcionais e não
Leia maisPlano de Gerenciamento do Projeto
Projeto para Soluções Contábeis 2015 Plano de Gerenciamento do Projeto Baseado na 5ª edição do Guia PMBOK Brendon Genssinger o e Elcimar Silva Higor Muniz Juliermes Henrique 23/11/2015 1 Histórico de alterações
Leia maisAtividade: COBIT : Entendendo seus principais fundamentos
SECRETARIA DE EDUCAÇÃO PROFISSIONAL E TECNOLÓGICA INSTITUTO FEDERAL DO PIAUÍ CAMPUS FLORIANO EIXO TECNOLÓGICO: INFORMAÇÃO E COMUNICAÇÃO CURSO: TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS PERÍODO
Leia maisADMINISTRAÇÃO DE ATIVOS DE TI GERENCIAMENTO DE CONFIGURAÇÃO
1 ADMINISTRAÇÃO DE ATIVOS DE TI GERENCIAMENTO DE CONFIGURAÇÃO 2 INFRAESTRUTURA DE TI Para garantir o atendimento às necessidades do negócio, a área de TI passou a investir na infraestrutura do setor, ampliando-a,
Leia maisSISTEMA INFORMATIZADO PARA CONTROLE DE JOGO E GERAÇÃO DE SÚMULAS DE HANDEBOL
SISTEMA INFORMATIZADO PARA CONTROLE DE JOGO E GERAÇÃO DE SÚMULAS DE HANDEBOL ¹ Hélder SANTOS; ² Bruno FERREIRA; ¹ Estudante de Análise e Desenvolvimento de Sistemas. IFMG campus Bambuí ² Professor do curso
Leia maisPLANEJAMENTO E PROJETOS. Lílian Simão Oliveira
PLANEJAMENTO E GERENCIAMENTO DE PROJETOS Lílian Simão Oliveira Contexto Gerentes lutam com projetos assustadores e com prazos finais difíceis de serem cumpridos Sistemas não satisfazem aos usuários Gastos
Leia maisConcepção e Elaboração
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Análise e Projeto Orientado a Objetos Concepção e Elaboração Estudo
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 maisSistemas de Informação I
+ Sistemas de Informação I Dimensões de análise dos SI Ricardo de Sousa Britto rbritto@ufpi.edu.br + Introdução n Os sistemas de informação são combinações das formas de trabalho, informações, pessoas
Leia mais1. Desenvolver o software iterativamente. Um pouco de reflexão: Acabou aí? 31/08/2010
Engenharia de Software Aula 5 (Versão 2010-02) Melhores práticas para desenvolvimento de software Desenvolver de forma iterativa e gerenciar requisitos Professor Gabriel Baptista ( gabriel.baptista@uninove.br
Leia maisGUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas
PIM PROGRAMA DE INTEGRAÇÃO COM O MERCADO GUIA DE CURSO Tecnologia em Sistemas de Informação Tecnologia em Desenvolvimento Web Tecnologia em Análise e Desenvolvimento de Sistemas Tecnologia em Sistemas
Leia maisEngenharia de Requisitos
Engenharia de Requisitos Introdução a Engenharia de Requisitos Professor: Ricardo Argenton Ramos Aula 08 Slide 1 Objetivos Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.
Leia maisUniversidade Paulista
Universidade Paulista Ciência da Computação Sistemas de Informação Gestão da Qualidade Principais pontos da NBR ISO/IEC 12207 - Tecnologia da Informação Processos de ciclo de vida de software Sergio Petersen
Leia maisDesenvolvimento de Interfaces Prototipação
Autarquia Educacional do Vale do São Francisco AEVSF Faculdade de Ciências Aplicadas e Sociais de Petrolina - FACAPE Centro de Engenharia e Ciências Tecnológicas CECT Curso de Ciência da Computação Desenvolvimento
Leia maisEstrutura do Trabalho: Fazer um resumo descrevendo o que será visto em cada capítulo do trabalho.
UNIVERSIDADE ESTADUAL DE MARINGÁ A monografia é um texto escrito contendo o resultado da pesquisa realizada como trabalho de conclusão do curso de especialização. Os itens básicos a constarem da monografia
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 maisModelo Cascata. Alunos: Bruno Nocera Zanette Pedro Taques
Modelo Cascata Alunos: Bruno Nocera Zanette Pedro Taques Principais Características Gerenciamento Simples das etapas Também conhecido como "Ciclo de Vida Clássico", sugere uma abordagem sistemática e sequencial
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 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 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 mais04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS. Aula 2. Prof. Rafael Dias Ribeiro. M.Sc.
MODELAGEM DE DADOS PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS Aula 2 Prof. Rafael Dias Ribeiro. M.Sc. @ribeirord 1 Objetivos: Revisão sobre Banco de Dados e SGBDs Aprender as principais
Leia maisAnálise e projeto de sistemas PROF. REGILAN SILVA
Análise e projeto de sistemas PROF. REGILAN SILVA Apresentação da disciplina Ver ementa... Solução Técnicas para identificação e detalhamento de requisitos Técnicas para modelagem de sistemas Definir
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 maisMUDANÇAS NA ISO 9001: A VERSÃO 2015
MUDANÇAS NA ISO 9001: A VERSÃO 2015 Está em andamento o processo de revisão da Norma ISO 9001: 2015, que ao ser concluído resultará na mudança mais significativa já efetuada. A chamada família ISO 9000
Leia maisEngenharia de Software Tema da Aula Definição e Especificação de Requisitos I - Conceitos. Exercício
Tema da Aula Definição e Especificação de Requisitos I - Conceitos Prof. Cristiano R R Portella portella@widesoft.com.br Exercício Em grupo de 4 alunos (2 desenvolvedores e 2 usuários), simular uma reunião
Leia maisEngenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante
1 - Q193183 ( Prova: FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / Engenharia de Software / Análise de Requisitos; Engenharia de Requisitos; ) De acordo com Sommerville,
Leia maisReferências internas são os artefatos usados para ajudar na elaboração do PT tais como:
Plano de Teste (resumo do documento) I Introdução Identificador do Plano de Teste Esse campo deve especificar um identificador único para reconhecimento do Plano de Teste. Pode ser inclusive um código
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 maisLevantamento, Análise e Gestão Requisitos. Aula 12
Levantamento, Análise e Gestão Requisitos Aula 12 Agenda Miscelâneas (Parte 3): Gerenciamento dos Requisitos Mutáveis Rastreabilidade de Requisitos Processo de Gestão de Mudanças Requisitos Estáveis e
Leia maisCiclo de Vida Clássico ou Convencional CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS. Ciclo de Vida Clássico ou Convencional. Enfoque Incremental
CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS Elicitação Ciclo de Vida Clássico ou Convencional O Modelo Cascata Análise Ana Paula Terra Bacelo Blois Implementação Material Adaptado do Prof. Marcelo Yamaguti
Leia maisCláudia Araújo Coordenadora Diego Macêdo Programador Marcelo Rodrigues Suporte
BCON Sistema de Controle de Vendas e Estoque Declaração de escopo Versão 1.0 Histórico de Revisão Elaborado por: Filipe de Almeida do Amaral Versão 1.0 Aprovado por: Marcelo Persegona 22/03/2011 Time da
Leia maisANEXO X DIAGNÓSTICO GERAL
ANEXO X DIAGNÓSTICO GERAL 1 SUMÁRIO DIAGNÓSTICO GERAL...3 1. PREMISSAS...3 2. CHECKLIST...4 3. ITENS NÃO PREVISTOS NO MODELO DE REFERÊNCIA...11 4. GLOSSÁRIO...13 2 DIAGNÓSTICO GERAL Este diagnóstico é
Leia maisRenata Alves Campos (CoInfo) Sandra Maria Peron de Lima (DP) Março/2012
Renata Alves Campos (CoInfo) Sandra Maria Peron de Lima (DP) Março/2012 O que é um processo? Um processo é um grupo de atividades realizadas numa seqüência lógica com o objetivo de produzir um bem ou um
Leia maisRicardo Roberto de Lima UNIPÊ 2008.1 APS-I. Históricos e Modelagem Orientada a Objetos
Históricos e Modelagem Orientada a Objetos Histórico Diversas metodologias e métodos surgiram para apoiar OO. Evolução a partir de linguagens C++ e SmallTalk. Anos 80 Anos 80-90: diversidade de autores.
Leia maisFeature-Driven Development
FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por
Leia maisTRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES
TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado
Leia maisUNIP Ciência da Computação / Sistemas de Informação TED I - Orientações Gerais para Elaboração dos Documentos
I - Orientações Gerais para Elaboração dos Documentos A seguir, orientações fundamentais para a elaboração dos documentos do projeto, tendo em vista a complexidade inerente neste processo. Este roteiro
Leia maisEngenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com
Engenharia de Software: conceitos e aplicações Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com 1 Objetivos da aula Apresentar os conceitos de Engenharia de Software e explicar a sua importância.
Leia maisA ITIL e o Gerenciamento de Serviços de TI
A ITIL e o Gerenciamento de Serviços de TI A era da informação Informação, palavra derivada do verbo latim "informare", que significa "disciplinar", "ensinar", "instruir", juntamente com o seu significado
Leia maisGlossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.
Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Versão 1.6 15/08/2013 Visão Resumida Data Criação 15/08/2013 Versão Documento 1.6 Projeto Responsáveis
Leia maisEngenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios
Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios Cronograma das Aulas. Hoje você está na aula Semana
Leia maisFANESE Faculdade de Administração e Negócios de Sergipe
1 FANESE Faculdade de Administração e Negócios de Sergipe ITIL V2 Service Support Aracaju, Setembro de 2009 EDUARDO DA PAIXÃO RODRIGUES LUCIELMO DE AQUINO SANTOS 2 ITIL V2 Service Support Trabalho de graduação
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 maisATIVIDADES PRÁTICAS SUPERVISIONADAS
ATIVIDADES PRÁTICAS SUPERVISIONADAS Tecnologia em Análise e Desenvolvimento de Sistemas 3ª Série Fundamentos de Análise Orientada a Objetos A atividade prática supervisionada (ATPS) é um método de ensinoaprendizagem
Leia maisGerenciamento de Incidentes
Gerenciamento de Incidentes Os usuários do negócio ou os usuários finais solicitam os serviços de Tecnologia da Informação para melhorar a eficiência dos seus próprios processos de negócio, de forma que
Leia maisGerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto
Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com PMBoK Organização do Projeto Os projetos e o gerenciamento
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 maisPlanejando o aplicativo
Um aplicativo do Visual FoxPro geralmente inclui um ou mais bancos de dados, um programa principal que configura o ambiente de sistema do aplicativo, além de uma interface com os usuários composta por
Leia maisConceitos de Banco de Dados
Conceitos de Banco de Dados Autor: Luiz Antonio Junior 1 INTRODUÇÃO Objetivos Introduzir conceitos básicos de Modelo de dados Introduzir conceitos básicos de Banco de dados Capacitar o aluno a construir
Leia maisAUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0
AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento
Leia maisALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA
ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA INTRODUÇÃO O projeto de um banco de dados é realizado sob um processo sistemático denominado metodologia de projeto. O processo do
Leia maisUNIVERSIDADE FEDERAL DO PARANÁ. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o.
CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o. PROFESSOR: Andrey DISCIPLINA: Técnicas Alternativas de Programação AULA: 08 APRESENTAÇÃO Na aula de hoje vamos apresentar e discutir como definir
Leia mais4 O Workflow e a Máquina de Regras
4 O Workflow e a Máquina de Regras O objetivo do workflow e da máquina de regras é definir um conjunto de passos e regras configuráveis. Ao longo de sua execução, um usuário consegue simplificar o seu
Leia maisWilson Moraes Góes. Novatec
Wilson Moraes Góes Novatec Copyright 2014 Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo,
Leia maisProva de Conhecimento para Consultores de Implementação MPS.BR INSTRUÇÕES
Implementação MPS.BR 26 de maio de 2008 4 horas de duração e-mail: (DEIXAR EM BRANCO) RESULTADO: Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Nota INSTRUÇÕES Para a maioria das questões você tem mais de uma opção e
Leia mais