Um estudo de aplicação de modelagem de processo de negócio para apoiar a especificação de requisitos de um sistema
|
|
- Mirela das Neves Aires
- 8 Há anos
- Visualizações:
Transcrição
1 Um estudo de aplicação de modelagem de processo de para apoiar a especificação de requisitos de um sistema Adriana Andrade, Andriele Ribeiro, Eduardo Borges, Wolber Neves Laboratório Synergia - Departamento de Ciência da Computação Universidade Federal de Minas Gerais Caixa Postal Belo Horizonte MG Brasil {aandrade, andriele, pereira, wolber}@dcc.ufmg.br Abstract. Systems specifications are often created either without contextualizing the real problem of the organization, or with a poor understanding of its needs. By modeling the business processes it is possible to achieve a better comprehension of the environment in which the system will be used, thus facilitating the identification and analysis of its requirements. This work describes the application of business modeling techniques as an input to produce a system specification for a public institution of the state of Minas Gerais, Brazil, describing the process used and presenting the results achieved. Resumo. Freqüentemente especificações de sistemas são criadas sem que o real problema da organização seja contextualizado, ou sem que haja real entendimento de suas necessidades. Por meio da modelagem de processos de é possível compreender melhor o ambiente no qual o sistema a ser construído irá funcionar, facilitando assim a identificação e análise de seus requisitos. Este trabalho descreve um caso de aplicação de técnicas de modelagem de processos de como subsídio à especificação de um sistema informatizado para uma instituição pública do estado de Minas Gerais, descrevendo o processo utilizado e apresentando os resultados obtidos. 1. Introdução O sucesso de uma organização está condicionado à eficácia com que os seus processos de são executados. Um sistema informatizado desenvolvido para dar suporte a uma organização deve, portanto, estar alinhado aos processos de onde estará inserido. Freqüentemente as especificações de requisitos de software são criadas sem que haja real entendimento das necessidades e problemas da organização. Por meio das técnicas de modelagem de processos de, é possível compreender melhor o ambiente no qual o sistema a ser construído irá funcionar, o que possibilita identificar requisitos correspondentes às reais necessidades do [Baker 2001]. Modelos de podem trazer vários benefícios no contexto do desenvolvimento de sistemas de software [Eriksson and Penker 2000]: 177
2 Contribuem para que os requisitos sejam completos e reflitam as necessidades de ; Evitam a tomada de decisões prematuras; Permitem que os sistemas desenvolvidos sejam guiados pelo, e não simplesmente pela tecnologia; Permitem um melhor planejamento da integração dos diferentes componentes do sistema; Possibilitam o reuso de lógica de nos diferentes produtos. Para isso, os modelos representam a arquitetura do. Essa representação é realizada descrevendo-se as partes que compõem os processos da organização, como elas são estruturadas, e como interagem para prover as funções oferecidas a seus clientes. Há várias notações propostas na literatura para esse fim, das quais podemos destacar: fluxogramas [Lakin et al. 1996], diagramas UML [Rumbaugh 1999], RADs (role activity diagrams) [Holt et al. 1983], gráficos de Gantt [Aguilar-Savén 2001] e os métodos IDEF [IDEF 2003]. O trabalho aqui descrito se baseia em uma experiência de aplicação das técnicas de modelagem de processos de utilizando a notação UML, como passo anterior à especificação de requisitos de um sistema de software para uma instituição pública. A seção 2 apresenta a contextualização do projeto em que tais técnicas foram aplicadas. A seção 3 descreve o processo criado para guiar as atividades de modelagem, e a execução do mesmo é descrita na seção 4. Finalmente, a seção 5 expõe os resultados obtidos, e as conclusões são apresentadas na seção Contextualização do projeto O projeto aqui discutido foi iniciado com a missão de apresentar ao cliente - instituição pública do estado de Minas Gerais - uma solução de informatização para seus processos internos, permitindo a integração entre suas áreas. Com esse propósito o fornecedor necessitava compreender a estrutura e a dinâmica da organização, levantar os problemas atuais, identificar oportunidades de melhoria e promover o entendimento comum quanto à situação desejada para a organização. Somente após esse trabalho poderiam ser identificados os requisitos para o sistema de software que ofereceria suporte à organização. Para a realização das atividades citadas acima o fornecedor optou pelo uso de técnicas de modelagem de processos de, conforme descrito na seção 3. Para fornecer as informações necessárias à modelagem, o cliente disponibilizou representantes com conhecimento do processo e poder de decisão, visto que não havia documentação dos processos em uso. Desde o início do trabalho, com a ajuda do fornecedor, puderam os representantes do cliente destacar alguns dos problemas que viviam, como: a lentidão de vários processos executados manualmente, inclusive transferência de informações entre sistemas; o retrabalho; o consumo excessivo de papel e conseqüente acúmulo de documentos em arquivos físicos; e a descentralização, replicação e inconsistência de dados. 178
3 Foram considerados dentro do escopo do trabalho somente processos internos da organização, ficando adiado o tratamento de processos que envolvem a participação de agentes externos. 3. Descrição do processo adotado 3.1. Organização do modelo de processos de O primeiro passo para a definição do processo a ser utilizado foi a escolha da notação de modelagem UML. A decisão por utilizar essa notação apoiou-se no fato de que ela, além de utilizar diagramas simples o suficiente para serem compreendidos por clientes e usuários, é a mesma empregada na modelagem de software - o que facilitaria posteriormente o entendimento pelos desenvolvedores do sistema. Apesar de estarem mais voltados à representação de conceitos de sistemas de software orientados a objetos, os diagramas da UML podem ser empregados também para descrever processos de. Para isso alguns perfis (conjuntos de convenções de personalização da UML) já foram propostos na literatura, como os apresentados em [Eriksson e Penker 2000] e [Ng 2003]. Para este projeto adotou-se o perfil definido em [Ng 2003], por ter melhor suporte da ferramenta de modelagem que seria utilizada no projeto. O conceito central para a modelagem dos processos de através da notação escolhida é o de caso de uso de, que representa uma seqüência de ações executadas durante a realização de um processo de. Os processos representados pelos casos de uso de geralmente produzem valor para algum cliente da organização; esses clientes são modelados por meio dos atores de. O modelo de processos de é então formado por um conjunto de casos de uso, cada um representando um processo de voltado para um cliente. Para documentar um processo de o modelo apresenta duas visões, uma externa e outra interna. A primeira é feita através da descrição dos casos de uso, que consiste no detalhamento passo a passo da interação entre os atores e a organização, durante a execução do processo em questão. Esse detalhamento pode ser feito por meio de descrições textuais (para processos mais simples) ou por diagramas de atividades, em notação UML. A visão interna é modelada através da realização dos casos de uso, que detalha como os agentes de (funcionários ou sistemas informatizados existentes na organização) interagem entre si e como as entidades de (recursos físicos, abstratos ou de informação) são manipuladas durante a realização do processo. A realização dos casos de uso é apresentada através dos diagramas de interação (seqüência ou colaboração) da UML. O modelo de processos de descreve também regras que definem ou restringem aspectos do, para satisfazer a requisitos externos (leis, restrições impostas por outros s, etc), e para garantir que os objetivos de cada processo sejam alcançados de forma segura. Tais regras de aparecem no modelo associadas a casos de uso, entidades e/ou agentes de. A Figura 1 apresenta os elementos que compõem o modelo de processos de, através de um diagrama de classes. A Tabela 1 descreve esses elementos e indica a representação UML de cada um. 179
4 Modelo de Negócio 1 < rege Regra de aciona > 1..n 1..n Caso de uso de 1..n ma ni pu la > 1..n /\ é responsável por \/ rege \/ rege 1 1..n Ator de Agente de Entidade de Figura 1. Elementos que compõem o modelo de processos de Tabela 1. Representação UML dos elementos que compõem o modelo de processos de Elemento Descrição Representação no perfil de modelagem de s Notação icônica [Ng 2003] Caso de uso de Ator de Agente de Entidade de Regra de Representação de um processo de que gera valor para algum cliente externo à organização. Papel desempenhado em relação ao por alguém ou alguma coisa no ambiente de. Agente humano ou informático que atua internamente no durante a realização de casos de uso, interagindo com outros agentes de e/ou manipulando entidades de. Recurso físico, abstrato ou de informação, utilizado ou produzido nos processos de. Regra que define ou restringe aspectos do, com o objetivo de satisfazer a requisitos externos (leis, restrições impostas por outros s, etc) e de garantir que os objetivos sejam alcançados de forma segura. 180 Caso de uso estereotipado como «business use case» Ator estereotipado como «business actor» Classe estereotipada como «business worker» Classe estereotipada como «business entity» Não foi utilizada uma representação direta na UML para regras de. As mesmas vêm descritas como restrições, anotações ou descrições textuais. -
5 3.2. Organização das atividades Para guiar as atividades realizadas durante a modelagem dos processos de da organização foi definido um processo a ser seguido e um conjunto de artefatos a serem gerados. A Figura 2 apresenta uma visão geral desse processo. Após uma etapa inicial de definição de escopo e contexto (representada pelas três primeiras atividades no diagrama), os casos de uso de são identificados, representando os processos de a serem tratados. Cada caso de uso identificado é então descrito durante a atividade Detalhamento dos casos de uso de. A descrição dos casos de uso de contém: Definição textual breve e objetiva do caso de uso. Acionamento: descrição de detalhes de quando o caso de uso é acionado. Diagramas de atividades: representação do fluxo do processo de através de diagramas de atividades, em notação UML. Descrição das atividades: descrição textual de cada atividade apresentada nos diagramas de atividades. Problemas conhecidos: lista dos problemas identificados no processo de representado pelo caso de uso. Possibilidades de melhoria: lista das possibilidades de melhoria identificadas para o processo de representado pelo caso de uso. Regras de : descrição detalhada das regras de que regem o processo descrito pelo caso de uso. Dentre esses diversos aspectos documentados para cada caso de uso de, é importante ressaltar aqueles que tratam de melhorias propostas ao processo. A modelagem de processos de contempla não só a documentação dos processos a serem informatizados, mas também a sua melhoria. Durante a descrição de um caso de uso de, eventuais problemas conhecidos quanto à realização do processo que ele representa são documentados e para cada um são propostas possibilidades de melhoria. Por exemplo, baixo desempenho, ausência de padronização das atividades e dificuldade de acesso à informação tratada costumam ser problemas recorrentes. Tais possibilidades são avaliadas e, se aprovadas, incorporadas ao modelo. Na medida em que os casos de uso são descritos, os principais conceitos envolvidos e os recursos utilizados ou produzidos por cada processo vão sendo identificados e modelados como entidades de, formando o Modelo de domínio. As regras de aplicáveis às entidades são também documentadas. Uma vez descritos os casos de uso e identificadas as entidades de, o próximo passo é documentar a realização dos casos de uso, descrevendo como os agentes de (tipicamente funcionários ou sistemas existentes na organização) interagem entre si e com as entidades de para executar o processo representado em cada caso de uso. 181
6 Verificação do atual Início da Modelagem de Processos de Negócio Definição do escopo da modelagem de Levantamento e descrição do contexto MPN - descrição do contexto Identificação dos casos de uso de MPN - atores e casos de uso de negóci o MPN - descrições dos casos de uso Detalhamento dos casos de uso de Modelagem das entidades de M PN - model o de domínio Realização dos casos de uso de negóci o MPN - agentes de MPN Geração da DPN DPN MPN - realizações Revi são dos artefatos Realização de ajustes e correções identificados Modelagem de processos de aprovada? [ Sim ] [ Não ] Fim da Modelagem de Processos de Negócio Figura 2. Atividades realizadas durante a modelagem dos processos de da organização Concluindo-se a visão de casos de uso (descrições e realizações de todos os casos de uso de ) e o modelo de domínio, tem-se o Modelo de Processos de Negócio (MPN) completo. O próximo passo é gerar uma versão desse modelo em formato documental, chamada de Descrição de Processos de Negócio (DPN), que é então revisada pelo cliente e assinada, marcando o final do processo de modelagem de processos de. Caso sejam detectados defeitos na documentação gerada durante a revisão, as devidas correções são providenciadas antes da aprovação final. 182
7 Tabela 2. Resultados das atividades realizadas durante a modelagem dos processos de da organização Atividade Descrição Resultados Verificação do atual Definição do escopo da modelagem de Levantamento e descrição do contexto Identificação dos casos de uso de Detalhamento dos casos de uso de Modelagem das entidades de Realização dos casos de uso de Geração da DPN Revisão dos artefatos Realização de ajustes e correções identificados Levantamento da visão geral do a ser modelado. Definição dos domínios de a serem abordados na modelagem de processos de. Descrição em linhas gerais do como um todo, apresentando o contexto em que os processos de estão inseridos. Levantamento dos casos de uso de e dos atores envolvidos em cada processo. Descrição do fluxo do processo de e identificação de problemas conhecidos, possibilidades de melhoria e regras de aplicáveis. Identificação das entidades de manipuladas nos casos de uso e dos relacionamentos entre elas. Descrição das realizações dos casos de uso de por meio de diagramas de colaboração ou diagramas de seqüência. Geração da Descrição de Processos de Negócio, a partir do Modelo de Processos de Negócio. Revisão pelo cliente da documentação produzida, realizada como critério de aprovação. Correções e ajustes identificados na revisão dos artefatos. - Documento textual que descreve de forma precisa o escopo do modelo de. Documento textual contendo a descrição geral do contexto. Diagrama de casos de uso de. Diagramas de atividades com a descrição dos fluxos dos processos; documentação de casos de uso contendo descrição das atividades, problemas conhecidos e possibilidades de melhoria. Diagramas de classes com as entidades do e as respectivas descrições, compondo o Modelo de Domínio. Diagramas de interação, detalhando como os processos são realizados internamente na organização. Versão documental do Modelo de Processos de Negócio, denominada Descrição de Processos de Negócio. Relatório de revisão contendo os defeitos detectados e o resultado (aprovação ou reprovação). Versão atualizada do Modelo de Processos de Negócio e da Descrição de Processos de Negócio. Concluídas as atividades de confecção e aprovação do MPN e da DPN, dá-se início à especificação do sistema de software a ser desenvolvido como suporte ao processo. Os artefatos produzidos na modelagem de são utilizados como insumo para a identificação dos requisitos do sistema. 4. Execução do processo Para confeccionar o MPN foi realizado um conjunto de oficinas, baseadas em técnicas de Joint Application Development (JAD [McConnell96]). 183
8 Foram realizadas ao todo 11 oficinas, com duração de 4 horas cada. No total, foram especificados 21 casos de uso de, cuja execução contava com o envolvimento de 18 dos 29 setores da organização. Foram documentadas 183 atividades e identificadas 101 entidades de. A partir dos casos de uso de foram derivados 64 casos de uso de sistema, e a modelagem das entidades do sistema permitiu identificar três grandes produtos. A DPN Descrição dos Processos de Negócio foi gerada automaticamente a partir do MPN com o uso de uma ferramenta de geração automática de documentação. Toda a informação levantada era registrada no próprio modelo ou anexada ao mesmo e referenciada por meio de apontadores. Essa forma de documentação trouxe vários benefícios para a equipe de analistas, já que todos concentraram seus esforços em um único artefato de trabalho. Isso também possibilitou minimizar a duplicação de informação em vários artefatos, e gerar o documento a ser entregue ao cliente de forma rápida e eficiente. Um ponto importante a ressaltar foi a necessidade de se fazer alguns ajustes no processo proposto (descrito na seção 3) ao longo da execução dos trabalhos. Durante a modelagem de processos de, percebeu-se que o principal interesse do cliente era documentar a execução interna de seus processos. A interação desses processos com os atores de, na maioria dos casos, não era relevante ou até mesmo não existia. Neste caso, a descrição dos fluxos dos processos de s sob uma perspectiva externa, sugerida pelo processo como parte da descrição dos casos de uso de, não seria representativa. Optou-se então por documentar os processos de apenas sob uma perspectiva interna, por meio das realizações. Outra alteração significativa foi a forma de documentar as realizações: o uso de diagramas de interação para a realização dos casos de uso [Ng 2003] foi substituído pelo uso de diagramas de atividades da UML. Cada informação contida nos diagramas de interação foi mapeada diretamente para os diagramas de atividades: os agentes de foram representados por raias e a interação dos agentes de com as entidades de foi indicada por meio do fluxo de objetos (conforme apresentado na Figura 3). A opção por representar as realizações por meio de diagramas de atividades ao invés dos diagramas de interação previstos originalmente no processo se deu por três motivos: Utilizando o mapeamento descrito, foi possível representar no diagrama de atividades toda a informação relevante que seria apresentada em um diagrama de interação; A notação utilizada nos diagramas de atividades era mais acessível aos representantes do cliente, devido à semelhança entre os diagramas de atividades e os fluxogramas utilizados pelos usuários para documentar informalmente seus processos. A representação de desvios no fluxo pôde ser representada de uma forma mais clara e objetiva nos diagramas de atividades. 184
9 Agentes de : Responsável por custos e orçamentos : Gestor de contratos : Tesoureiro : Contador : Solicitação de convênio/subvenção Recebimento de solicitação de convênio/subvenção Entidades de Registro de convênio/subvenção Anulação de crédito orçamentário : Anulação orçamentária : Convênio/Subvenção Agendamento de pagamento : Cronograma de pagamento [Atualizado] Registro de transferência financeira : Transferência financeira bancária Arquivamento do processo Figura 3. Exemplo de realização de caso de uso de por meio de diagrama de atividades, destacando os agentes e as entidades de 5. Resultados obtidos A aplicação da modelagem de processos de trouxe resultados bastante positivos. A execução dessa etapa antes da realização do levantamento dos requisitos do sistema foi um fator de redução de riscos, tanto para o cliente quanto para o fornecedor. O cliente pôde ter uma visão melhor do seu, identificando as áreas que realmente seriam beneficiadas pela construção do sistema, evitando assim o desperdício de recursos. Foi interessante observar que, durante as oficinas, o cliente pôde perceber que determinados processos não estavam sendo executados da melhor forma. Diante 185
10 desta percepção, alguns processos foram remodelados, evitando que o sistema fosse construído sobre uma base operacional deficiente. Para o fornecedor, a execução da modelagem de processos de resultou em maior facilidade na gestão dos requisitos do sistema. Muitas das constantes mudanças que ocorrem durante o desenvolvimento de um sistema decorrem da inexistência de um consenso entre os representantes do cliente sobre a melhor forma de se executar um processo. A modelagem de processos de fez com que esse consenso fosse alcançado antes do início do levantamento dos requisitos do sistema, tornando esta etapa mais eficiente. A identificação dos casos de uso do sistema também foi bastante facilitada. Como passaram a conhecer melhor a realidade do cliente, os engenheiros de requisitos puderam ser mais pró-ativos nesta atividade, contribuindo com sugestões e ponderações baseadas em conhecimento mais sólido. Esta pró-atividade mostrou-se especialmente útil nas primeiras oficinas, já que naquele momento os representantes do cliente ainda não estavam totalmente seguros com a metodologia de levantamento dos requisitos. Outro benefício trazido pela modelagem de processos de diz respeito à rastreabilidade dos requisitos. Uma característica de qualidade importante para uma especificação de requisitos é a facilidade em se determinar os resultados do desenvolvimento que serão afetados por cada requisito (rastreabilidade para frente), bem como a origem de cada um (rastreabilidade para trás) [Paula 2003] [Daves 1993]. Como os requisitos foram derivados diretamente do Modelo de Processos de Negócio, a rastreabilidade para trás foi garantida documentando-se, para cada requisito, o processo de que o gerou. Um ponto importante no desenvolvimento de um sistema, especialmente quando seu porte não é pequeno, é a sua divisão em produtos. A divisão é uma maneira formal de se exercitar o desenvolvimento incremental, já que produtos coesos e de menor porte são entregues em menor tempo do que um único módulo que contemple todas as funções. Isto é importante tanto do ponto de vista técnico quanto do de, já que muitas vezes o cliente não dispõe de recursos para construir todo o sistema de uma só vez, e a priorização de requisitos dentro de um módulo único não é uma tarefa simples. Esse foi também um ponto em que a modelagem de processos de foi benéfica. Antes de sua realização, cliente e fornecedor imaginavam que o sistema seria composto por três produtos. Após a modelagem, percebeu-se que o número de produtos era realmente três, mas a composição dos mesmos foi bastante modificada. Dois dos produtos foram agrupados em um único, e um produto de controle de fluxo de trabalho (workflow) foi identificado. Apenas um produto permaneceu conforme tinha sido concebido no início. A divisão inicial dos produtos espelhava a divisão funcional da empresa, o que não se mostrou uma boa idéia do ponto de vista de sistemas. A modelagem de processos de fez com que cliente e fornecedor percebessem que duas das áreas eram muito integradas, o que justificaria um único produto para atendê-las. Da mesma forma, o problema de controle de fluxo de trabalho era comum a todas as áreas funcionais, o que justificaria um produto genérico para este fim, e não a inserção de funcionalidades correlatas em um dos produtos específicos para determinada área. 186
11 Após a divisão dos produtos, um deles foi escolhido para ser especificado e construído. Seria necessário, portanto, realizar uma estimativa do tamanho do produto em pontos de função, para orçar-se a fase de Elaboração. O melhor conhecimento da organização, conseguido por meio da modelagem de processos de, também foi fundamental para que essa estimativa fosse bem próxima da contagem oficial de pontos de função, realizada alguns meses depois (após o fim da Elaboração). Percebeu-se inclusive que a aproximação do número real foi maior do que em projetos em que a modelagem de processos de não foi usada. Como último resultado importante, podemos citar o artefato resultante da modelagem de processos de. Esse documento é importante para o cliente, já que é a documentação dos processos da organização. Mas também do ponto de vista do fornecedor o documento foi de grande utilidade, pois serviu para dar uma visão geral às pessoas que entravam no projeto depois de seu início. Foi uma forma simples e barata de integrar novas pessoas à equipe. 6. Conclusão De posse dos resultados obtidos com a modelagem de processos de pôde-se confirmar a grande vantagem em se utilizar esta técnica em uma organização. A modelagem de processos de ajudou a estabelecer algumas estratégias para a especificação de um sistema informatizado, principalmente quanto ao escopo e à divisão do sistema em produtos candidatos. O entendimento mútuo do entre cliente e fornecedor favoreceu um trabalho de maior parceria. Esse entendimento possibilitou ao fornecedor maior poder para propor otimizações ao através de um sistema, diminuindo-se o risco de embutir no sistema vícios que normalmente estão arraigados às praticas dos processos de de qualquer organização. Além dos resultados já identificados, pôde-se concluir que a aplicação da modelagem de processos de é um processo que gera benefícios por si só, independentemente da construção posterior de um sistema de software. Através da dela foi possível contextualizar a situação atual do da organização assim como identificar seus problemas atuais. A partir dessa identificação foi possível oferecer ao cliente um conjunto de sugestões de melhorias à execução de seus processos que puderam ser incorporadas imediatamente ao seu dia a dia, antes mesmo da construção dos sistemas de software identificados. O cliente sentiu-se mais seguro em saber que poderia optar por não especificar e não construir o sistema se ao final do projeto concluísse que essa era a melhor decisão. E isso não implicaria perda de recursos, já que teria sido realizado um importante trabalho de documentação e reengenharia de processos. O produto final da modelagem de processos de pôde ser comercializado como um produto/serviço à parte, o que trouxe maior conforto para o cliente e tornou as negociações comerciais mais fáceis. 187
12 Referências bibliográficas Aguilar-Saven, R., Business process modelling techniques and tools. Department of Production Economics. WP291, Linköping Sweden. Baker, B. (2001). Business Modeling with UML: The Light at the End of the Tunnel, In: The Rational Edge, December/ archives/dec01.html Daves, A. (1993) Software Requirements: Objects, Functions and States. Prentice Hall, Eriksson, H. and Penker, M. Business Modeling with UML: Business patterns at work, John Wiley & Sons ltd., USA, Holt, A. et al., Coordination systems technology as a programming environment. Electrical Communication 57 (4), IDEF (2003). IDEF Family of Methods web page: Lakin, R. et al., BPR enabling software for the nancial services industry. Management services, ISSN: McConnell, S. Rapid Development. Microsoft Press, Ng, Pan-Wei (2003). Effective business modeling with UML: Describing business use cases and realizations, Paula Filho, W. P. (2003) Engenharia de software; fundamentos, métodos e padrões, 2.ed., Rio de Janeiro: Editora LTC. Rumbaugh, J., Jacobson, I. and Booch, Grady (1999). Unified Modeling Language Reference Manual, Addison Wesley,
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 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 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 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 maisPlanejamento da disciplina: Modelagem de processos de negócio
UNIVERSIDADE FEDERAL DE MINAS GERAIS / INSTITUTO DE CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Planejamento da disciplina: Modelagem de processos de negócio Professor: Clarindo Isaías Pereira
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 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 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 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 maisA Linguagem de Modelagem Unificada (UML)
Aécio Costa A Linguagem de Modelagem Unificada (UML) Percebeu-se a necessidade de um padrão para a modelagem de sistemas, que fosse aceito e utilizado amplamente. Surge a UML (Unified Modeling Language)
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 maisREQUISITOS DE SISTEMAS
REQUISITOS DE SISTEMAS MÓDULO 2 PROCESSOS DE NEGÓCIOS CONTEÚDO 1. PROCESSOS DE NEGÓCIO IDENTIFICAÇÃO CONCEITOS MODELAGEM (BPM e UML) PROCESSOS X REQUISITOS 1. PROCESSOS DE NEGÓCIO IDENTIFICAÇÃO CONCEITOS
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 maisDesenvolvimento de um software de gerenciamento de projetos para utilização na Web
Resumo. Desenvolvimento de um software de gerenciamento de projetos para utilização na Web Autor: Danilo Humberto Dias Santos Orientador: Walteno Martins Parreira Júnior Bacharelado em Engenharia da Computação
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 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 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 maisProcesso de Implementação de um Sistema de Gestão da Qualidade
3 Processo de Implementação de um Sistema de Gestão da Qualidade Não existe um jeito único de se implementar um sistema da qualidade ISO 9001: 2000. No entanto, independentemente da maneira escolhida,
Leia mais3. Fase de Planejamento dos Ciclos de Construção do Software
3. Fase de Planejamento dos Ciclos de Construção do Software A tarefa de planejar os ciclos de construção do software pode partir de diretrizes básicas. Estas diretrizes visam orientar que os ciclos de
Leia 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 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 maisDESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES. Trabalho de Graduação
DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES Trabalho de Graduação Orientando: Vinicius Stein Dani vsdani@inf.ufsm.br Orientadora: Giliane
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 maisPERSPECTIVAS DO PROJETO DE ENSINO FÁBRICA DE SOFTWARE *
PERSPECTIVAS DO PROJETO DE ENSINO FÁBRICA DE SOFTWARE * Hudson Henrique de Souza LOPES 1 ; Wellington Garcia PEREIRA 2 ; Getúlio Antero de DEUS JÚNIOR 3. 1 Bolsista do PET EEEC/UFG hudsonhsl@hotmail.com.
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 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 maisMÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS
MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS O termo metodologia não possui uma definição amplamente aceita, sendo entendido na maioria das vezes como um conjunto de passos e procedimentos que
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 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 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 maisFACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador>
FACULDADE DE ENGENHARIA DE COMPUTAÇÃO PROJETO FINAL I e II PLANO DE TRABALHO O Trabalho de Conclusão de Curso (TCC) a ser desenvolvido
Leia maisA Disciplina Gerência de Projetos
A Disciplina Gerência de Projetos Atividades, Artefatos e Responsabilidades hermano@cin.ufpe.br Objetivos Apresentar atividades da disciplina Gerência de Projetos Discutir os artefatos e responsáveis envolvidos
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 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 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 maisAutoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira
Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Introdução Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre
Leia maishttp://www.microsoft.com/pt-br/case/details.aspx...
Casos de Sucesso A Cyrela está completamente focada no pós-venda e a utilização do Microsoft Dynamics 2011 só reflete mais um passo importante na busca pela qualidade do atendimento ao cliente Roberto
Leia maisProjeto Pé na Dança. www.penadanca.com. Bruno Barros Comunicador Visual. bruno@brunobarros.com www.brunobarros.com 21 2704 3991 / 9605 0589
Projeto Pé na Dança www.penadanca.com 1 Sumário I. Esta proposta... 3 II. Metodologia de trabalho... 5 III. Investimento... 6 IV. Cronograma... 6 V. Termos e Condições... 7 VI. Manutenção do site... 7
Leia mais17/02/2009. Curso Superior de Tecnologia: Redes de Computadores. Disciplina: Gestão de Projetos de TI Prof.: Fernando Hadad Zaidan. Unidade 2.
Faculdade INED Curso Superior de Tecnologia: Redes de Computadores Disciplina: Gestão de Projetos de TI Prof.: Fernando Hadad Zaidan 1 Unidade 2.2 2 ESCOPO 3 1 Gerência do Escopo Processos necessários
Leia maisHistórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial
1 of 14 27/01/2014 17:33 Sistema de Paginação de Esportes Universitários Documento de Arquitetura de Software Versão 1.0 Histórico da Revisão Data 30 de novembro de 1999 Versão Descrição Autor 1.0 Versão
Leia maisFATEC Cruzeiro José da Silva. Ferramenta CRM como estratégia de negócios
FATEC Cruzeiro José da Silva Ferramenta CRM como estratégia de negócios Cruzeiro SP 2008 FATEC Cruzeiro José da Silva Ferramenta CRM como estratégia de negócios Projeto de trabalho de formatura como requisito
Leia maishttp://www.wikiconsultoria.com.br/100-motivos-implantar-crm/
Continuando a série 100 motivo para implantar um CRM, veremos agora motivos referentes a BackOffice de CRM. Se você não tem a primeira parte da nossa apresentação, com os primeiros 15 motivos para implantar
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 maisDESENVOLVENDO O SISTEMA
DESENVOLVENDO O SISTEMA Declaração da Necessidade O primeiro passo do processo de análise de sistema envolve a identificação da necessidade [Pressman-95]. Normalmente o analista reúne-se com o usuário
Leia 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 maisManual SAGe Versão 1.2 (a partir da versão 12.08.01)
Manual SAGe Versão 1.2 (a partir da versão 12.08.01) Submissão de Relatórios Científicos Sumário Introdução... 2 Elaboração do Relatório Científico... 3 Submissão do Relatório Científico... 14 Operação
Leia maisDicionário da EAP - Software FarmaInfor
Software FarmaInfor 1.Gerenciamento 2.Iniciação 3.Elaboração 4. Desenvolvimento 5.Trenferência 6. Finalização 6.1 Assinatura 1.1 Montar Equipe 2.1 Levantar Requisitos 3.1 Definir Módulos 4.1 Codificar
Leia maisMETODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO MUSEU PARAENSE EMÍLIO GOELDI
METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO MUSEU PARAENSE EMÍLIO GOELDI HISTÓRICO DE REVISÕES Data Versão Descrição Autor 02/04/2014 1.0 Versão Inicial Ewertton Bravo 27/08/2014 1.1 Alteração da Imagem
Leia maisIntrodução a UML. Hélder Antero Amaral Nunes haanunes@gmail.com
Introdução a UML Hélder Antero Amaral Nunes haanunes@gmail.com Introdução a UML UML (Unified Modeling Language Linguagem de Modelagem Unificada) é uma linguagem-padrão para a elaboração da estrutura de
Leia maisUniversidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática
Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Disciplina: INF5008 Prof.: (monalessa@inf.ufes.br) Conteúdo 3. Gerência de
Leia maisPalavras-Chaves: engenharia de requisitos, modelagem, UML.
APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE
Leia maisRock In Rio - Lisboa
Curso de Engenharia Informática Industrial Rock In Rio - Lisboa Elaborado por: Ano Lectivo: 2004/05 Tiago Costa N.º 4917 Turma: C Gustavo Graça Patrício N.º 4757 Turma: C Docente: Professora Maria Estalagem
Leia maisSETIS- III Seminário de Tecnologia Inovação e Sustentabilidade 4 e 5 de novembro de 2014.
A importância da comunicação no gerenciamento de projetos de softwares: reflexões teóricas Lucas Krüger lucas_kruger-@hotmail.com Resumo: Esse artigo objetiva estudar a comunicação entre cliente e desenvolvedor
Leia maisPrograma do Módulo 2. Processo Unificado: Visão Geral
9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:
Leia maisProduto de Gerenciamento: Business Case
{lang: 'pt-br'} Preliminar Introdução Produto de Gerenciamento: Business Case Esse artigo é parte da nova série de artigos proposta pela Management Plaza e se relaciona aos chamados Produtos de Gerenciamento
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 maisPEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0
PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0 Banco Central do Brasil, 2015 Página 1 de 14 Índice 1. FLUXO DO PEN - PROCESSO DE ENTENDIMENTO DAS NECESSIDADES DE NEGÓCIO... 3 2.
Leia maisMetodologia de Gerenciamento de Projetos da Justiça Federal
Metodologia de Gerenciamento de Projetos da Justiça Federal Histórico de Revisões Data Versão Descrição 30/04/2010 1.0 Versão Inicial 2 Sumário 1. Introdução... 5 2. Público-alvo... 5 3. Conceitos básicos...
Leia maisProposta Comercial. Proposta Comercial de prestação de serviços de Desenvolvimento de web site para o Vereador Marcelo Ramos.
Proposta Comercial de prestação de serviços de Desenvolvimento de web site para o Vereador Marcelo Ramos. 1 1. APRESENTAÇÃO DA PROPOSTA Brasília, 14 de maio de 2010. A LTDA. vem, por meio deste documento,
Leia maisSistemas de Produtividade
Sistemas de Produtividade Os Sistemas de Produtividade que apresentaremos em seguida são soluções completas e podem funcionar interligadas ou não no. Elas recebem dados dos aplicativos de produtividade,
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 maisMetodologia e Gerenciamento do Projeto na Fábrica de Software
.:: Universidade Estadual de Maringá Bacharelado em Informática Eng. de Software III :. Sistema de Gerenciamento de Eventos - Equipe 09 EPSI Event Programming System Interface Metodologia e Gerenciamento
Leia maisGuia de utilização da notação BPMN
1 Guia de utilização da notação BPMN Agosto 2011 2 Sumário de Informações do Documento Documento: Guia_de_utilização_da_notação_BPMN.odt Número de páginas: 31 Versão Data Mudanças Autor 1.0 15/09/11 Criação
Leia maisUNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC
CURSO: Bacharelado em Ciência da Computação DISCIPLINA: ANPS Análise e Projeto de Sistemas AULA NÚMERO: 3 DATA: PROFESSOR: Murakami Sumário 1 APRESENTAÇÃO...1 2 DESENVOLVIMENTO...1 2.1 Revisão...1 2.1.1
Leia mais02/10/2012. Padronização de interfaces. Referências
Referências Engenharia de Usabilidade Prof.: Clarindo Isaías Pereira da Silva e Pádua Contribuição: Cláudio Márcio de Souza Vicente Gestus Hix, D.; Hartson, H. R. Developing User Interfaces: ensuring usability
Leia maisMetodologia e Gerenciamento do Projeto na Fábrica de Software v.2
.:: Universidade Estadual de Maringá Bacharelado em Informática Eng. de Software III :. Sistema de Gerenciamento de Eventos - Equipe 09 EPSI Event Programming System Interface Metodologia e Gerenciamento
Leia maisDefinição de Padrões. Padrões Arquiteturais. Padrões Arquiteturais. Arquiteturas de Referência. Da arquitetura a implementação. Elementos de um Padrão
DCC / ICEx / UFMG Definição de Padrões Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Um padrão é uma descrição do problema e a essência da sua solução Documenta boas soluções para problemas recorrentes
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 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 maisBPMN (Business Process. George Valença gavs@cin.ufpe.br
BPMN (Business Process Modeling Notation) George Valença gavs@cin.ufpe.br 31/10/2012 Introdução Modelagem de processos No ciclo de vida BPM, a etapa de modelagem de processos consiste em um conjunto de
Leia mais1 UML (UNIFIED MODELING LANGUAGE)
1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida
Leia maisIntegração ADMRH com AGROSYS
Treinamentos no produto AdmRH CGI - Consultoria Gaúcha de Informática Ltda - Divisão de treinamentos Guia do Aluno Versão 1.0 Integração ADMRH com AGROSYS Empresa: Participante: Data: Os produtos da CGI
Leia maisGerenciamento de Riscos do Projeto Eventos Adversos
Gerenciamento de Riscos do Projeto Eventos Adversos 11. Gerenciamento de riscos do projeto PMBOK 2000 PMBOK 2004 11.1 Planejamento de gerenciamento de riscos 11.1 Planejamento de gerenciamento de riscos
Leia maisUML: Casos de Uso. Projeto de Sistemas de Software
UML: Casos de Uso Projeto de Sistemas de Software UML Casos de Uso Introdução Casos de uso Elementos do diagrama de casos de uso Descrição de casos de uso Exemplo: Blog Ferramentas de modelagem Bibliografia
Leia maisPalavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML.
MODELAGEM ORIENTADA A OBJETOS APLICADA À ANÁLISE E AO PROJETO DE SISTEMA DE VENDAS ALTEMIR FERNANDES DE ARAÚJO Discente da AEMS Faculdades Integradas de Três Lagoas ANDRE LUIZ DA CUNHA DIAS Discente da
Leia mais1 Inicie um novo. Guia de Referência Rápida de Gerenciamento de Projeto para o Project 2007. projeto
Guia de Referência Rápida de Gerenciamento de Projeto para o Project 2007 1 Inicie um novo Antes de começar um novo, uma organização deve determinar se ele se enquadra em suas metas estratégicas. Os executivos
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 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 maisDesafio Profissional PÓS-GRADUAÇÃO 2012. Gestão de Projetos - Módulo C Prof. Me. Valter Castelhano de Oliveira
Desafio Profissional PÓS-GRADUAÇÃO 12 Gestão de Projetos - Módulo C Prof. Me. Valter Castelhano de Oliveira 1 DESAFIO PROFISSIONAL Disciplinas: Ferramentas de Software para Gestão de Projetos. Gestão de
Leia maisIntrodução ao Processo Unificado (PU)
Universidade Federal de Mato Grosso do Sul Sistemas de Informação - CPCX Introdução ao Processo Unificado (PU) Prof. Fernando Maia da Mota Slides gentilmente cedidos por Profa. Dra. Maria Istela Cagnin
Leia maisII. FASE DE PLANEJAMENTO define a maturidade do entendimento do escopo e, o desenvolvimento do Plano do Projeto PP.
II. FASE DE PLANEJAMENTO define a maturidade do entendimento do escopo e, o desenvolvimento do Plano do Projeto PP. Nesta fase busca-se o refinamento dos objetivos do projeto e detalhamento do melhor caminho
Leia maisTERMO DE REFERÊNCIA (TR) GAUD 4.6.8 01 VAGA
INSTITUTO INTERAMERICANO DE COOPERAÇÃO PARA A AGRICULTURA TERMO DE REFERÊNCIA (TR) GAUD 4.6.8 01 VAGA 1 IDENTIFICAÇÃO DA CONSULTORIA Contratação de consultoria pessoa física para serviços de preparação
Leia maisSISTEMAS DE GESTÃO São Paulo, Janeiro de 2005
SISTEMAS DE GESTÃO São Paulo, Janeiro de 2005 ÍNDICE Introdução...3 A Necessidade do Gerenciamento e Controle das Informações...3 Benefícios de um Sistema de Gestão da Albi Informática...4 A Ferramenta...5
Leia maisDetalhamento da Fase de Planejamento e Programação de Projeto. Gerenciamento de Tempo
Detalhamento da Fase de Planejamento e Programação de Projeto Gerenciamento de Tempo Principal objetivo garantir que o projeto seja concluído dentro do prazo determinado; O cronograma do projeto é sempre
Leia maisDATA WAREHOUSE. Introdução
DATA WAREHOUSE Introdução O grande crescimento do ambiente de negócios, médias e grandes empresas armazenam também um alto volume de informações, onde que juntamente com a tecnologia da informação, a correta
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 maisPrograma do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA)
Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA) Apresentação O programa de Pós-graduação Lato Sensu em Engenharia de Software Orientada a Serviços
Leia maisEngenharia de Software I: Análise e Projeto de Software Usando UML
Engenharia de Software I: Análise e Projeto de Software Usando UML Capítulo 1 Processo de Desenvolvimento de Software Metodologia de Desenvolvimento de Software Uma metodologia é um conjunto de métodos,
Leia maisNotas de Aula 04: Casos de uso de um sistema
Notas de Aula 04: Casos de uso de um sistema Objetivos da aula: Aprender os elementos básicos da modelagem por casos de uso Utilizar as associações entre casos de uso, atores e demais artefatos Compreender
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 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 maisCOMO FAZER A TRANSIÇÃO
ISO 9001:2015 COMO FAZER A TRANSIÇÃO Um guia para empresas certificadas Antes de começar A ISO 9001 mudou! A versão brasileira da norma foi publicada no dia 30/09/2015 e a partir desse dia, as empresas
Leia maisTabela e Gráficos Dinâmicos Como estruturar dinamicamente dados no Excel
Tabela e Gráficos Dinâmicos Como estruturar! Para que serve a Tabela e o Gráfico Dinâmico?! Como criar uma Tabela Dinâmica?! Como criar um Gráfico Dinâmico?! Como podemos atualizar dos dados da Tabela
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 maisEspecificação do 3º Trabalho
Especificação do 3º Trabalho I. Introdução O objetivo deste trabalho é abordar a prática da programação orientada a objetos usando a linguagem Java envolvendo os conceitos de classe, objeto, associação,
Leia maisGerenciamento de Projeto: Planejando os Recursos. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br
Gerenciamento de Projeto: Planejando os Recursos Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Sumário Planejar as Aquisições Desenvolver o Plano de Recursos Humanos Planejar as Aquisições É o
Leia maisManual Geral do OASIS
Manual Geral do OASIS SISTEMA DE GESTÃO DE DEMANDA, PROJETO E SERVIÇO DE TECNOLOGIA DA INFORMAÇÃO OASIS Introdução Esse manual tem como objetivo auxiliar aos usuários nos procedimentos de execução do sistema
Leia mais