Uma Abordagem de Desenvolvimento de Groupware Baseada em Linha de Produto de Software e Modelo 3C de Colaboração

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

Download "Uma Abordagem de Desenvolvimento de Groupware Baseada em Linha de Produto de Software e Modelo 3C de Colaboração"

Transcrição

1 Bruno Freitas Gadelha Uma Abordagem de Desenvolvimento de Groupware Baseada em Linha de Produto de Software e Modelo 3C de Colaboração Tese de Doutorado Tese apresentada como requisito parcial para obtenção do título de Doutor pelo Programa de Pós-Graduação em Informática da PUC-Rio Orientador: Professor Hugo Fuks Rio de Janeiro Dezembro de 2011

2 Bruno Freitas Gadelha Uma Abordagem de Desenvolvimento de Groupware Baseada em Linha de Produto de Software e Modelo 3C de Colaboração Tese apresentada como requisito parcial para obtenção do título de Doutor pelo Programa de Pós-Graduação em Informática da PUC-Rio. Aprovada pela Comissão Examinadora abaixo assinada Prof. Hugo Fuks Orientador Departamento de Informática - PUC-Rio Prof. Alberto Nogueira de Castro Jr. UFAM Prof. Mariano Pimentel UNIRIO Prof. Carlos Jose Pereira de Lucena Departamento de Informática - PUC-Rio Prof. Alessandro Garcia Departamento de Informática - PUC-Rio Prof. José Eugenio Leal Coordenador(a) Setorial do Centro Técnico Científico - PUC-Rio Rio de Janeiro, 21 de dezembro de 2011

3 Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador. Bruno Freitas Gadelha Bruno Freitas Gadelha iniciou seu doutorado no primeiro semestre de 2008 no Departamento de Informática da Pontifícia Universidade Católica do Rio de Janeiro (PUC- Rio). É mestre em Informática (2006), pela Universidade Federal do Amazonas (UFAM), Bacharel em Ciência da Computação (2003), pela mesma universidade. Atua no Laboratório de Engenharia de Software. Tem interesse em desenvolvimento de groupware, learningware, linhas de produto de software e na construção e uso de Objetos de Aprendizagem. Ficha Catalográfica Gadelha, Bruno Freitas Uma abordagem de desenvolvimento de groupware baseada em linha de produto de software e modelo 3C de colaboração / Bruno Freitas Gadelha; orientador: Hugo Fuks f. : il. (color.) ; 30 cm Tese (doutorado) Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática, Inclui bibliografia 1. Informática Teses. 2. Groupware. 3. Linhas de produto de software. 4. Scripts de colaboração. I. Fuks, Hugo. II. Pontifícia Universidade Católica do Rio de Janeiro. Departamento de Informática. III. Título. CDD: 004

4 À minha mãe, pelo apoio e confiança.

5 Agradecimentos Ao meu orientador Hugo Fuks pelas horas dedicadas, estímulo e trabalho árduo que excedendo suas funções de professor orientador, agiu como um verdadeiro educador. Ao professor Alberto Castro pela co-orientação informal, pelo apoio tanto na vida acadêmica quanto pessoal, pelo debate de ideias e pela demonstração de amizade em diferentes momentos do doutorado. Aos professores Mariano Pimentel e Marco Aurélio Gerosa pelas dicas valiosas durante o desenvolvimento desse trabalho. Aos amigos do Groupware@LES Thaís Castro, Kátia Canepa, Débora Cardador e Wallace Ugulino pela amizade e companheirismo durante a caminhada no doutorado. Ao CNPq e à PUC-Rio, pelo auxílio concedido, sem o qual o presente trabalho não seria possível. À Prefeitura Municipal de Manaus pelo apoio e por apostar na melhoria da minha formação acadêmica e consequente melhoria profissional.

6 Resumo Gadelha, Bruno Freitas; Fuks, Hugo. Uma Abordagem de Desenvolvimento de Groupware Baseada em Linha de Produto de Software e Modelo 3C de Colaboração. Rio de Janeiro, p. Tese de Doutorado - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro. Nesta tese investigou-se o desenvolvimento de software no contexto de groupware, especificamente para apoiar a aprendizagem colaborativa. O desenvolvimento de groupware, entretanto, não é trivial. Como todo software, há aspectos tecnológicos e sociais envolvidos no desenvolvimento. Quanto aos aspectos tecnológicos, o desenvolvimento de artefatos de infraestrutura ocupam grande parte do esforço destinado à implementação dessas aplicações, sobrando pouco tempo para a implementação de soluções inovadoras para as questões da colaboração propriamente ditas. Com respeito aos aspectos sociais, deve-se levar em conta que o trabalho em grupo é dinâmico e a composição dos grupos, bem como suas características, se alteram com o passar do tempo. Assim, desenvolveu-se uma linha de produtos de software para groupware baseado no Modelo 3C de Colaboração, onde os groupware são derivados a partir da formalização de técnicas de aprendizagem colaborativa em scripts de colaboração. Foi desenvolvido um protótipo, o GroupwareBuilder para interpretar o script de colaboração e derivar o groupware para suporte específico das suas atividades. Uma avaliação funcional e um estudo de caso foram realizados. Na avaliação funcional, buscou-se obter uma prova de conceito do GroupwareBuilder, na qual dois groupware foram derivados para apoiar os scripts de colaboração Debate Crítico e Buzz Groups. O estudo de caso foi realizado para observar como se daria a derivação de groupware para técnicas de aprendizagem colaborativa modeladas por diferentes professores. A principal contribuição deste trabalho é uma abordagem que possibilita a derivação e adaptação de groupware a partir de scripts de colaboração elaborados pelos usuários e não a partir de uma lista de requisitos funcionais, como em LPS s tradicionais. Palavras-chave Groupware; linhas de produto de software; scripts de colaboração.

7 Abstract Gadelha, Bruno Freitas; Fuks, Hugo (Advisor). An Approach for Groupware Development based on Software Product Lines and the 3C Collaboration Model. Rio de Janeiro, p. DSc. Thesis - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro. In this thesis we explore software development on the context of groupware, specifically on supporting collaborative learning. Groupware development is not a trivial task given that technological and social issues are involved. Considering the technological issues, a huge amount of time is wasted on implementing infrastructure aspects leaving little time for implementation of innovative solutions on collaboration. Considering the social issues, we should take into account that group work is dynamic and that group composition changes over time. So, we developed a software product line for groupware based on the 3C Collaboration Model. The groupware derivation process starts with the formalization of the collaborative learning techniques in collaboration scripts. In order to support this collaboration process we developed the GroupwareBuilder, that reads the collaboration script and derives groupware tailored to the tasks described on the script. We made a functional evaluation and a case study. On the functional evaluation, we aimed on getting a proof of concept for GroupwareBuilder by deriving groupware for supporting the Critical Debate and Buzz Groups collaboration scripts. In order to analyze how GroupwareBuilder derives groupware from other collaborative learning techniques described by different teachers we made a case study. The main contribution of this thesis is an approach that enables the derivation of groupware and the customization of groupware in runtime from collaboration scripts written by the users, and not from a list of software requirements as used in other SPLs approaches. Keywords Groupware; Software Product Lines; Collaboration Scripts.

8 Sumário 1 Introdução Visão Geral da Pesquisa: Problema, Solução, Hipótese e Avaliação Método de pesquisa: Estudo de Caso Etapas da pesquisa Estrutura da tese 19 2 Fundamentação Teórica Linhas de Produto de Software (LPS) Aprendizagem Colaborativa com Suporte Computacional Scripts de Colaboração BPMN Business Process Model Notation Groupware e Modelo 3C de Colaboração RUP 3C-Groupware Groupware Workbench Desenvolvimento Dirigido por Modelos Programação pelo usuário final Trabalhos Relacionados 37 3 Linha de Produto Dinâmica para Groupware Desenvolvimento das linhas de produto de serviços Análise de Domínio Projeto e implementação Representando as Especificações do Designer Representando Scripts de Colaboração com BPMN Representando Requisitos de Sistema com BPMN Linha de Produto para Groupware de Suporte a Aprendizagem Colaborativa Desenvolvendo o Serviço de Fórum de Discussões Desenvolvendo o Serviço de Repositório de Arquivos Derivação de produtos 60 4 Avaliação 63

9 4.1. Avaliação funcional da solução Debate Crítico Buzz Groups Estudo de Caso Protocolo para a realização do estudo de caso Resultados obtidos Discussão 86 5 Conclusão Contribuições e Trabalhos Futuros 92 6 Referências bibliográficas 97

10 Lista de figuras Figura 1. Objetos de fluxo BPMN [41] Figura 2. Objetos de conexão BPMN [41] Figura 3. Swimlanes BPMN [41] Figura 4. Artefatos BPMN [41] Figura 5. Modelo 3C de Colaboração [42] Figura 6. Fluxo Analisar Domínio do RUP 3C-Groupware [25] Figura 7. Modelo de Features 3C Genérico da Linha de Produtos para Groupware Figura 8. Exemplo de Modelo de Features 3C Figura 9. Resumo da abordagem de desenvolvimento das linhas de produto de serviços Figura 10. Exemplo de representação de script de colaboração com BPMN Figura 11. Especificação de um serviço usando BPMN Figura 12. Modelo de Features 3C do serviço Fórum de Discussões Figura 13 Fórum PL Modelo de Componentes UML para o serviço de Fórum de Discussão Figura 14. Fórum Descriptor File (parcial) Figura 15. Modelo de Features 3C do serviço Repositório de Arquivos Figura 16. Modelo de Componentes UML do serviço de repositório de arquivos Figura 17. Repositório Descriptor File (parcial) Figura 18. Esquema de derivação de groupware com o GroupwareBuilder Figura 19. Evolução da linha de produtos Figura 20. Script de Colaboração para a técnica Debate Crítico. Modelado com o Bonita Open Studio Figura 21. Tela de administração do groupware. Cadastro de tarefas Figura 22. Tela de atribuição dos papéis aos usuários do groupware Figura 23. Tela inicial do perfil de usuário do groupware Figura 24. Tela da atividade Debate Geral Figura 25. Script de Colaboração para a técnica Buzz Groups. Modelado com o Bonita Open Studio Figura 26. Tela de administração do Buzz Groups. Cadastro de Tarefas

11 Figura 27. Tela de atribuição dos grupos (papéis) aos usuários do Buzz Groups Figura 28. Tela inicial do perfil de usuário do Buzz Groups Figura 29 - Protocolo para realização do estudo de caso Figura 30. Perfil dos participantes Figura 31. Familiaridade com conceitos da pesquisa Figura 32. Dificuldade de representação da técnica de aprendizagem colaborativa Figura 33. Adequação do groupware ao script de colaboração

12 Lista de quadros Tabela 1. Resumo dos requisitos funcionais do Versus, AVMJ e InGrupo. 49 Tabela 2. Quadro Conceitual 3C para o serviço de Fórum de Discussão. 51 Tabela 3. Links de rastreabilidade entre ações, features e CollabElements. 55 Tabela 4. Quadro Conceitual 3C para o serviço de Repositório de Arquivos 57 Tabela 5. Links de rastreabilidade entre ações, features e CollabElements. 60 2

13 1 Introdução Nesse capítulo é apresentada uma visão geral da pesquisa realizada acerca da derivação de groupware em uma linha de produtos de software a partir de scripts de colaboração. Um script de colaboração é um cenário pedagógico a ser seguido pelos estudantes quando estão envolvidos em uma situação de aprendizagem colaborativa [1]. Uma linha de produto de software (LPS) é um conjunto de sistemas de software que compartilham características (features) comuns e gerenciáveis que satisfazem necessidades específicas de um segmento específico de mercado ou missão e que são desenvolvidos a partir de um conjunto comum de artefatos de forma sistemática [2]. A preocupação com a adequação entre o processo de colaboração e o groupware usado para apoiar a realização do trabalho em grupo é presente na literatura, bem como a adaptação do script de colaboração para adequar-se às limitações do meio computacional [3-5]. A relevância da especificação de groupware para um script de colaboração é reconhecida na literatura por meio de abordagens especificamente projetadas para o desenvolvimento de groupware a partir de processos de colaboração [6]. O desenvolvimento de groupware, entretanto, não é trivial. Como todo software, há aspectos tecnológicos e sociais envolvidos no desenvolvimento [7]. Quanto aos aspectos tecnológicos, o desenvolvimento de artefatos de infraestrutura como protocolos, sincronismo e gerenciamento de sessão ocupam grande parte do esforço destinado à implementação dessas aplicações, sobrando pouco tempo para a implementação de soluções inovadoras [8] para as questões da colaboração propriamente ditas. Além disso, há muitos serviços comuns entre essas diferentes aplicações de groupware, como fóruns de discussão, salas de chat, repositório de arquivos, dentre outras. Como consequência da similaridade tecnológica e funcional entre aplicativos do tipo groupware, é possível desenvolver um núcleo comum para essas aplicações, de modo que as diferenças entre um groupware e outro sejam notadas em função de aspectos funcionais relacionados com o trabalho em grupo que se pretende realizar. A demanda de desenvolvimento dos aspectos tecnológicos comuns entre uma família de aplicações tem sido explorada pelas LPS [2].

14 14 Com respeito aos aspectos sociais, deve-se levar em conta que o trabalho em grupo é dinâmico e a composição dos grupos, bem como suas características, se alteram com o passar do tempo. O grupo aprende, surgem afinidades e conflitos entre os membros, pessoas entram e saem, o que acarreta numa mudança contínua do grupo. A dinâmica de trabalho, os serviços selecionados e a composição do ambiente de trabalho são fundamentais para propiciar a colaboração [9]. Estes fatores são especialmente críticos no contexto da aprendizagem colaborativa. A aprendizagem colaborativa é um caso particular de trabalho em grupo no qual o objetivo comum dos membros é aprender. As atividades de aprendizagem são projetadas para serem executadas por pares ou pequenos grupos de trabalho [10] em função da dificuldade de coordenação em grupos maiores. Aprendizagem colaborativa é um tópico de interesse da comunidade educacional que tenta adaptar o modelo educacional ao desenvolvimento da sociedade. Na sociedade industrial, esperava-se um trabalhador que realizasse atividades repetitivas conforme a orientação de um chefe. Não se esperava a comunicação entre os operários. Como reflexo desse cenário, as salas de aula refletiam essa cultura, colocando o professor na posição de chefe e todos os alunos (operários) voltados para o professor, inibindo dessa forma qualquer comunicação que não seja com o chefe (professor). Em contraste com o encontrado na sociedade industrial, na atual sociedade espera-se muito mais colaboração entre os funcionários. Por exemplo, médicos de diferentes especialidades se reúnem numa junta médica para decidir como tratar do caso de um paciente específico. O projeto de veículos, geralmente envolve profissionais de diferentes formações que devem trabalhar juntos para a conclusão de um projeto inovador. Essa mudança no perfil de trabalhador que não ouve somente o chefe, mas discute e colabora com seus pares é demandada pela sociedade atual e é refletida na educação por meio da adoção de um modelo onde o professor não simula somente o papel de um chefe que transfere aos estudantes (operários) o conhecimento sobre como executar uma tarefa repetitiva. Em vez disso, o professor atua como um coordenador, um mediador, que lidera seus alunos divididos em grupos de trabalho para a solução de problemas complexos. É papel desse professormediador induzir a comunicação, a coordenação e a cooperação entre os 4 membros, além de preparar projetos de aprendizagem que cubram os conhecimentos planejados no currículo do curso. A sala de aula, novamente, é

15 15 uma simulação da empresa, mas uma empresa na qual os funcionários tem mais autonomia, aprendem por conta própria como resolver problemas complexos e como trabalhar em grupo para atingir seus objetivos. É papel do professor-mediador lidar com alguns problemas comuns que ocorrem durante as atividades da aprendizagem colaborativa, tais como: participação desigual nas atividades, resistência ao trabalho em grupo, comportamento incompatível com as atividades, grupos que não se dão bem, competição excessiva pela liderança do grupo, diferenças nos níveis de habilidade, velocidades diferentes de trabalho entre os grupos de uma turma, ausência de estudantes (faltas) e cópia de trabalhos (plágio) [10]. O professor, mediador da aprendizagem, deve ter a sensibilidade para perceber a ocorrência desses problemas e tomar alguma medida de correção como: mudar a formação dos grupos ou adotar outra técnica de aprendizagem colaborativa mais apropriada aos estudantes. A aprendizagem colaborativa com suporte computacional (CSCL Computer-supported Collaborative Learning) é um ramo das ciências da aprendizagem que estuda como as pessoas aprendem juntas com o auxílio computacional [11]. Como resultado de pesquisas em CSCL, diversos groupware foram desenvolvidos para dar suporte a alguma técnica de aprendizagem colaborativa em particular. Por exemplo, o Versus [12] dá suporte a técnica Controvérsia Acadêmica [13], o AVMJ [14] dá suporte a técnica JigSaw [15] e o InGrupo [16] dá suporte a técnica Investigação em Grupo [17]. Todos esses groupware foram especificamente projetados para apoiar a aplicação de uma técnica específica de aprendizagem colaborativa. Todo o esforço relativo ao levantamento de requisitos funcionais e desenvolvimento dos aspectos tecnológicos comuns foi feito para cada sistema, sem haver um reaproveitamento do que fora produzido anteriormente. Nessa tese, investiga-se como derivar groupware a partir da formalização da técnica de aprendizagem colaborativa em scripts de colaboração (por exemplo, por meio da definição de processos em uma ferramenta de modelagem) e do uso de Linhas de Produto de Software (LPS). O uso conjunto de representação das técnicas de aprendizagem e de LPS foi a abordagem escolhida para ser investigada nessa pesquisa, pois privilegia a adaptação de software (derivação de um novo groupware) à forma como o professor quer 5 conduzir o trabalho com sua turma (definição do script de colaboração). Em função da argumentação apresentada, considera-se que a dificuldade de projetar e desenvolver groupware específico para uma técnica de trabalho em

16 16 grupo é um problema relevante o suficiente para justificar a pesquisa dessa tese. Assim como a proposta dessa tese é considerada original, uma vez que não foram encontrados trabalhos que produzam resultados semelhantes entre os trabalhos correlatos listados na revisão de literatura realizada na Seção 2.7. O restante desse capítulo é organizado da seguinte maneira: na Seção 1.1, é apresentada uma visão geral da pesquisa. As etapas realizadas na pesquisa são descritas na Seção 1.2. O método usado para essa pesquisa é argumentado e justificado na Seção 1.3. Por fim, a organização da escrita da tese é apresentada na Seção Visão Geral da Pesquisa: Problema, Solução, Hipótese e Avaliação A visão geral da pesquisa é apresentada a seguir: Teoria: Engenharia de Software aplicada ao desenvolvimento de groupware; Problema: A dificuldade de se obter um groupware adequado a uma técnica de trabalho em grupo específica; Questão: Como diminuir a dificuldade do usuário em obter um groupware adequado à uma técnica de trabalho em grupo? Solução proposta: Uma arquitetura baseada em LPS para derivação automática de groupware específico para uma técnica de trabalho em grupo formalizada como script de colaboração em uma linguagem previamente definida. Hipótese: Se a arquitetura proposta for usada, então será possível derivar um groupware adequado para a técnica de trabalho em grupo formalizada pelo usuário. Avaliação: Prova de conceito (avaliação funcional) para investigar o funcionamento da arquitetura quanto aos aspectos tecnológicos e Estudo de Caso com participantes experientes em educação para avaliar a adequação do groupware gerado para a técnica formalizada pelos participantes. Foi desenvolvido um protótipo chamado GroupwareBuilder para apoiar a avaliação realizada nessa pesquisa. Por meio do protótipo, planeja-se que os processos formalizados pelos participantes sejam usados para derivar groupware. Observação não participativa, onde não há interferência do pesquisador observador, foi realizada 6 durante a realização das tarefas propostas no estudo de caso com os participantes. Os dados coletados na observação são notas textuais, vídeos e áudio, conforme a autorização dos

17 17 usuários e recursos disponíveis. Outros dados coletados são respostas dos participantes ao questionário da pesquisa, os groupware gerados e as técnicas de aprendizagem formalizadas. Falseabilidade: A hipótese será refutada se o groupware derivado por meio da arquitetura proposta não refletir adequadamente a técnica formalizada pelos usuários. A hipótese será confirmada se os groupware refletirem adequadamente a técnica modelada pelos usuários. É possível que a hipótese não seja nem confirmada e nem refutada se nenhum participante conseguir modelar uma técnica de aprendizagem, pois não será possível avaliar a adequabilidade do groupware à técnica. Nesse caso, será preciso analisar as escolhas de projeto feitas na tese, especialmente com relação à linguagem escolhida para representação da técnica de aprendizagem colaborativa. 1.2.Método de pesquisa: Estudo de Caso Estudo de caso é um método empírico considerado adequado para investigar fenômenos num contexto específico [18]. Nessa pesquisa, o fenômeno investigado é a dificuldade inerente ao desenvolvimento de software, que é um trabalho artesanal, para o qual levantam-se requisitos por meio de entrevistas, questionários, e outros instrumentos e realiza-se o projeto, desenvolvimento, teste e implantação do software. O contexto dessa pesquisa é o desenvolvimento de groupware especificamente para dar suporte à técnicas de aprendizagem colaborativa (o contexto é definido de forma ainda mais específica em função do perfil dos participantes, experiência com colaboração apoiada por computador, etc.). Estudo de caso é recomendado, especialmente, quando as fronteiras entre fenômeno e o contexto não são evidentes. Na presente pesquisa, não são evidentes quais são os fatores do contexto que efetivamente influenciam no desenvolvimento de groupware (contexto) em contraste com o desenvolvimento de software tradicional (fenômeno), embora a diferença seja reconhecida pela grande quantidade de referências na literatura de autores atacando o problema de desenvolver groupware específico para uma técnica de aprendizagem colaborativa, como os citados anteriormente. Uma fronteira que se destaca entre 7 o desenvolvimento de groupware e software tradicional, é que o desenvolvimento de groupware requer a análise da colaboração entre os participantes e não somente da interação do usuário com o sistema.

18 18 Outra recomendação para uso de estudo de caso é quando a pesquisa requer o uso de diferentes tipos de dados, como objetivo-quantitativo e, principalmente, qualitativos. O uso de dados objetivo-quantitativos e a investigação de hipóteses são características de um estudo de caso que se assemelham à experimentação [19, 20]. Apesar da semelhança, o método dessa pesquisa não é experimentação porque nem todas as variáveis estão definidas e controladas e, dessa forma, não é possível garantir que sempre serão obtidos os mesmos resultados entre semelhantes estudos de caso, enquanto a reprodutibilidade é uma qualidade esperada de um experimento. Nessa pesquisa, não se pode controlar, por exemplo, como os usuários vão abstrair a técnica de aprendizagem colaborativa na forma de representação gráfica, como também não se pode controlar o julgamento subjetivo dos usuários com relação à adequação do groupware à técnica formalizada. Um item relevante que é parcialmente controlado nesse estudo é o grau de experiência em informática e conhecimento e interesse sobre a aprendizagem colaborativa, item para o qual foram coletadas medidas subjetivas, na forma de resposta dos participantes às perguntas fechadas do questionário de pesquisa. Não é possível caracterizar todas as variáveis que precisariam estar controladas como requerido no método experimentação. O alto grau de controle da experimentação pressupõe o uso de um laboratório em situações artificiais para a realização de experimentos, enquanto na pesquisa aqui apresentada são investigadas situações reais de projetos de aprendizagem formalizados por professores. A escolha de estudo de caso em detrimento da experimentação é também uma escolha do realismo em detrimento da facilidade de generalização obtida quando se tem um ambiente controlado e artificial. Outra importante característica desse estudo que o classifica como estudo de caso é o uso de diferentes tipos de dados: tanto quantitativos como qualitativos. Experimentação focaliza apenas variáveis quantitativas, enquanto estudo de caso interessa-se também por dados e análises qualitativas tal como as declarações dos participantes sobre a adequação do groupware à técnica modelada. Todos estes fatores o baixo grau de controle das variáveis, a presença de dados e análises qualitativas, e a investigação em contextos reais distanciam experimentação do método estudo de caso usado na pesquisa apresentada nessa tese. 8

19 Etapas da pesquisa As etapas dessa pesquisa são listadas a seguir: (1) O sistema FLOCOS, um repositório de objetos de aprendizagem com o registro da cooperação dos usuários de cada objeto de aprendizagem, foi desenvolvido e comunicado em artigos [21]; A partir do desenvolvimento do FLOCOS, foi possível perceber a dificuldade específica do desenvolvimento de groupware, que é a necessidade da análise da interação entre os participantes, ao invés de analisar somente questões de usabilidade e interação do usuário com o sistema; (2) Uma revisão da literatura foi realizada para investigar a dificuldade de desenvolvimento de groupware e está registrada em seções dessa tese; (3) Um segundo protótipo de groupware foi desenvolvido e comunicado em um artigo [22] para explorar o uso de LPS na derivação de groupware baseado no Modelo 3C, uma vez que esse modelo é usado na análise da colaboração. Uma das contribuições dessa etapa de pesquisa foi a adaptação do modelo de features para acomodar o Modelo 3C e, consequentemente, características da colaboração na LPS; (4) Na quarta etapa, a evolução da pesquisa comunicada nos artigos [23, 24] foi usar o conhecimento acumulado sobre o desenvolvimento de groupware: anexou-se o modelo RUP 3C-Groupware para desenvolvimento [25] e a bancada de componentes para desenvolvimento de groupware (Groupware Workbench [26]); (5) A quinta etapa consistiu em generalizar o conhecimento adquirido nas etapas anteriores na forma de uma arquitetura de LPS para derivação de groupware a partir da formalização de técnicas de aprendizagem colaborativa Estrutura da tese No Capítulo 2 é realizada uma revisão da literatura, onde são descritos os conceitos que embasam o desenvolvimento da pesquisa desta tese. São apresentados os conceitos de linhas de produtos de software, aprendizagem colaborativa e scripts de colaboração, o Modelo 3C de Colaboração, desenvolvimento dirigido por modelos e programação pelo usuário final. Por fim, são apresentados os trabalhos correlatos a esta 9 pesquisa. No Capítulo 3 a proposta de arquitetura para a derivação de groupware em linhas de produtos de software a partir de scripts de colaboração é apresentada.

20 20 O capítulo apresenta a abordagem de forma geral e exemplifica a abordagem apresentando o desenvolvimento de uma linha de produtos para groupware de suporte à aprendizagem colaborativa. No capítulo 4, é apresentada a avaliação da proposta desta tese. Essa avaliação é realizada em duas etapas: (1) avaliação funcional da arquitetura, que consiste em uma prova de conceito para mostrar que a linha de produtos desenvolvida é capaz de gerar groupware adequado à uma técnica de aprendizagem colaborativa e, (2) estudo de caso com o objetivo de verificar como se dá a geração de groupware a partir de scripts de colaboração definidos por professores. Ao fim do capítulo, é apresentada uma discussão. Por fim, no Capítulo 5 são apresentadas as conclusões e contribuições dessa pesquisa. O capítulo descreve, ainda, possíveis desdobramentos dessa pesquisa para diferentes comunidades científicas. 0

21 2 Fundamentação Teórica Este capítulo apresenta os conceitos que fundamentam essa pesquisa. A Seção 2.1 conceitua linhas de produto de software e aponta os benefícios de sua adoção. Na Seção 2.2, é apresentado o conceito de aprendizagem colaborativa com suporte computacional, além de conceituar scripts de colaboração e descrever o framework para a criação de scripts usado nessa tese. Em seguida, na Seção 2.3 são apresentados os elementos que constituem a BPMN, que foi usada para representar os scripts de colaboração. A Seção 2.4 apresenta o Modelo 3C de Colaboração e seus recursos para o desenvolvimento de groupware, o RUP 3C-Groupware e o Groupware Workbench. A Seção 2.5 define o conceito de desenvolvimento dirigido por modelos usando (Model Driven Development MDD) na implementação do protótipo desenvolvido nesta tese. A Seção 2.6 define End-user programming, conceito usado em conjunto com o MDD que permite com que o usuário final do protótipo possa derivar seu próprio groupware a partir da LPS descrita nessa tese. Por fim, na Seção 2.7 são apresentados trabalhos relacionados a essa pesquisa Linhas de Produto de Software (LPS) Uma linha de produto de software (LPS) é um conjunto de sistemas computacionais compartilhando um conjunto de características comuns, gerenciáveis que satisfazem as necessidades específicas de um segmento de mercado particular (família de software) e que são desenvolvidos a partir de um conjunto comum de artefatos de forma sistemática [2]. As LPS objetivam prover, a custos reduzidos, software customizados. A adoção das LPS provê benefícios [27], tais como: Customização em massa. Consiste na produção em larga escala de software adaptado às necessidades individuais dos usuários. Tempo de entrega reduzido. Apesar do tempo de entrega de produtos derivados de LPS ser inicialmente alto, devido ao esforço inicial no desenvolvimento dos artefatos comuns que farão parte do núcleo da LPS,

22 22 esse tempo é reduzido com o reuso desses artefatos para entrega de novos produtos. Baixo custo de desenvolvimento. Da mesma maneira que o tempo de entrega, o custo inicial do desenvolvimento de LPS é alto (investimento inicial), porém o autor argumenta que o investimento inicial é justificado a partir da entrega do terceiro produto da LPS aproximadamente. Melhoria na qualidade dos produtos. Os artefatos da LPS são revistos e testados em diversos produtos, e precisam funcionar bem em todos eles. Esses testes intensivos implicam em uma chance maior de detectar e corrigir eventuais problemas, aumentando assim a qualidade de todos os produtos da linha. Os benefícios da adoção de LPS identificados são conseqüência do reuso intensivo e sistemático de software. Os produtos são desenvolvidos a partir de um conjunto de artefatos de software de forma sistemática, em contraste com o desenvolvimento individual de software, a partir do zero, ou através do reuso de software de forma arbitrária [2]. Destaca-se, porém, que a abordagem de LPS pode ser confundida com outras abordagens no desenvolvimento de software [2, 28], tais como: Reuso fortuito de pequena granularidade. Essa abordagem trata do reuso de pequenos pedaços de software geralmente escritos em bibliotecas de funções, módulos, objetos ou pequenos componentes. Na abordagem de LPS, o reuso é planejado, possibilitado e forçado, ao contrário do reuso oportunístico. A base de artefatos inclui aqueles que possuem o maior custo de desenvolvimento no caso de sistemas desenvolvidos isoladamente. Esses artefatos são projetados para serem reusados em mais diversos sistemas. Desenvolvimento de software individual com reuso. Essa abordagem trata do reuso oportunístico no desenvolvimento de software. No desenvolvimento individual de software, é comum que o desenvolvedor já tenha desenvolvido soluções semelhantes que podem ser aplicadas ao novo software em desenvolvimento. Nesse caso, o desenvolvedor geralmente copia e cola, se apropriando do conhecimento adquirido em experiências anteriores de desenvolvimento. Como resultado tem-se sistemas totalmente diferentes e não sistemas construídos a partir da mesma base. Em LPS, os artefatos são projetados explicitamente para 2 o reuso, e a linha de produtos é tratada como um todo, não como vários produtos que são vistos e mantidos separadamente. Cada produto é simplesmente resultado da composição e adequação dos artefatos do núcleo da linha de produtos e de,

23 23 eventualmente, uma pequena coleção de artefatos adicionais exclusivos para esse produto. Apenas desenvolvimento baseado em componentes ou serviços. Embora os produtos nas LPS sejam desenvolvidos através da composição de componentes, alguns dos quais podem ser também Web Services, todos esses componentes devem ser especificados pela arquitetura de linha de produtos. Além disso, os componentes são montados de forma prescrita, o que inclui embutir mecanismos de variação nos componentes para usá-los em produtos específicos. Em uma linha de produtos, a forma genérica do componente é desenvolvida e mantida na base de artefatos essenciais (núcleo da linha de produtos). No caso do desenvolvimento baseado em componentes, se houver necessidade de alguma variação no produto, isso implica em escrever mais código, e essas variações geralmente são mantidas separadamente. No desenvolvimento baseado em componentes falta, também, os aspectos de gestão técnica e organizacional que são tão importantes para o sucesso de um produto de software. Nesta pesquisa, foi usado o desenvolvimento baseado em componentes para a implementação dos artefatos da linha de produtos, conforme descrito no Capítulo 3. Apenas uma arquitetura reconfigurável. Arquiteturas de referência e frameworks são projetados para serem reusados em múltiplos sistemas e, se necessário, serem reconfigurados. Reusar estruturas de arquitetura de software é apropriado visto que é uma parte essencial de qualquer sistema, além de ter um alto custo de desenvolvimento. Uma arquitetura de LPS é projetada para dar suporte à variação necessária para os produtos da linha de produtos, assim torná-la reconfigurável é desejável. No entanto, a arquitetura da LPS é apenas um artefato, embora importante, no núcleo da linha de produtos. Releases e versões de produtos individuais. Uma LPS gera vários produtos ao mesmo tempo, todos esses produtos passam por seus próprios ciclos de lançamento e controle de versões simultaneamente. Assim, a evolução de um único produto deve ser considerada dentro de um contexto mais amplo, ou seja, a evolução da LPS como um todo. No contexto de produtos individuais, uma vez que é lançada uma nova versão, as versões anteriores perdem seu valor e são descartadas. 3 Mas em uma LPS uma versão anterior de um produto, que ainda é considerado com potencial de mercado, é mantida como um membro viável da família de produtos, dado

24 24 que consiste em uma instância de artefatos do núcleo da linha de produtos, assim como outras versões de outros produtos. Apenas um conjunto de normas técnicas. Muitas organizações adotam um conjunto de normas técnicas para limitar as escolhas de seus desenvolvedores de software no que diz respeito aos tipos e fontes dos componentes a serem usados nos sistemas que desenvolvem. Essas normas consistem em restrições para promover a interoperabilidade e reduzir os custos associados à manutenção e suporte de componentes comerciais. No entanto, essas normas são simplesmente restrições impostas às LPS. Na engenharia de linhas de produtos de software são identificadas duas atividades principais: Engenharia de domínio, que consiste na definição dos aspectos comuns e variáveis das LPS, na realização desses aspectos em artefatos de software e a definição dos links de rastreabilidade entre esses artefatos. Os links de rastreabilidade facilitam o reuso sistemático e consistente dos artefatos de software. Engenharia de aplicação que tem por objetivo realizar a derivação dos produtos de software através do reuso dos artefatos produzidos na atividade de engenharia de domínio, explorando a variabilidade definida para a LPS. Essa pesquisa engloba essas duas atividades. A atividade de engenharia de domínio é realizada na definição da abordagem para o desenvolvimento das LPS de serviços descrita na Seção 3.1 desta tese. A atividade de engenharia de aplicação é realizada através da abordagem de derivação de produtos a partir dos scripts de colaboração que é apresentada na Seção 3.4 desta tese. A principal atividade da engenharia de domínio consiste na identificação dos aspectos comuns e variáveis entre os membros de uma família de software. Essa variabilidade é descrita em termos de features que são definidas como uma propriedade do sistema que é relevante para algumas das partes interessadas e é usada para capturar ou discriminar semelhanças entre os produtos em SPL [29]. Após identificadas, as features são então organizadas em um modelo de features (feature modelling). Essa atividade, além de identificar as features comuns e variáveis da LPS, captura também suas interdependências. Foi originalmente proposta pelo método Feature 4 Oriented Domain Analysis (FODA) [30] e tem sido usada em várias abordagens de SPL. O suporte à variabilidade é alcançado, tendo em conta a modularização das features e adotando técnicas para promovê-la. O principal benefício de se

25 25 ter features modularizadas é possibilitar que uma feature seja incluída ou removida da LPS viabilizando a derivação sistemática de produtos e, consequentemente, reduzindo o tempo e custos do processo de derivação na atividade de engenharia de domínio. Diferentes técnicas de desenvolvimento de software podem ser usadas para modularizar features [31] como, por exemplo, polimorfismo, design patterns, frameworks, componentização, compilação condicional e programação orientada a aspectos. De acordo com Galster [32], a variabilidade acontece em diferentes fases no ciclo de vida do software como, por exemplo, na fase de projeto do software, chamada variabilidade de projeto (design time variability), e em tempo de execução, chamada variabilidade em tempo de execução (runtime variability). As fontes para a variabilidade tanto de projeto quanto de execução são tanto mudanças nos requisitos ou propagação de modificações em diferentes níveis (nível de negócio ou de processo, por exemplo) quanto à necessidade de responder a situações de erros. As LPS tradicionais tratam da variabilidade em tempo de projeto, onde as possíveis variações são previstas, modeladas e implementadas durante o projeto da LPS. Para tratar da variabilidade em tempo de execução, a literatura aponta o conceito de linhas de produtos de software dinâmicas (DSPL Dynamic Software Product Lines). DSPL é definida por Burégio et. al. [33] como uma estratégia promissora para lidar com projeto e implementação de mudanças que devem ser realizadas em tempo de execução em aplicações de domínios emergentes, uma vez que produz software capaz de se adaptar a mudanças nas necessidades dos usuários em tempo de execução. A adaptação de software em tempo de execução é uma característica desejável no contexto de groupware, dado que o trabalho colaborativo é dinâmico, o que exige maior flexibilidade dos serviços para se adaptar a mudanças nos requisitos de colaboração. Os requisitos de colaboração nessa pesquisa são formalizados em scripts de colaboração. O uso desses scripts tem sido explorado em pesquisas na área da aprendizagem colaborativa com suporte computacional (CSCL Computer-supported collaborative learning). 2.2.Aprendizagem Colaborativa com Suporte Computacional A aprendizagem colaborativa refere-se 5 a atividades de aprendizagem explicitamente projetadas e executadas por pares ou pequenos grupos de estudantes para atingir objetivos de aprendizagem comuns [10].

26 26 A motivação para a investigação da aprendizagem colaborativa se dá pelo fato das pessoas aprenderem muito umas com as outras. Essa aprendizagem acontece de diferentes maneiras: resolvendo problemas em conjunto, obtendo informações sobre problemas já resolvidos, explicando soluções para problemas, debatendo sobre vantagens e desvantagens de uma determinada escolha, fazendo ou recebendo críticas, dentre outras atividades em grupo [34]. A estruturação da aprendizagem colaborativa ocorre a partir dos seguintes princípios [34]: (1) os estudantes trabalham juntos com o objetivo comum do aprendizado e; (2) os estudantes são responsáveis tanto pela sua própria aprendizagem quanto pela aprendizagem dos demais. Isso implica no estabelecimento de metas coletivas que, quanto melhor atendidas, maiores são as possibilidades de aprendizagem de cada estudante sobre o assunto estudado. A aprendizagem colaborativa é praticada por educadores nos diversos níveis escolares, do ensino fundamental à pós-graduação [34] e em diversas situações de educação, desde a formal, nas escolas à informal, como no caso de museus [11]. O suporte computacional para essas atividades é resultado de avanços na área de Aprendizagem Colaborativa com Suporte Computacional (CSCL). Essa pesquisa contribui para a área de CSCL dado que objetiva prover um ambiente de suporte computacional adequado a técnicas de colaboração descritas em scripts de colaboração. Os scripts são usados na transposição das técnicas de aprendizagem colaborativas para contextos mediados por computador [35]. A próxima seção detalha o conceito de scripts de colaboração Scripts de Colaboração Um script de colaboração consiste em um cenário pedagógico a ser seguido pelos estudantes envolvidos em um ambiente de aprendizagem colaborativa [1]. Scripts de colaboração estruturam o processo interativo entre dois ou mais estudantes propiciando a colaboração através da especificação de uma sequência de atividades de aprendizagem em conjunto com funções (papéis) apropriadas para os estudantes, a fim de provocar o envolvimento em atividades sociais e cognitivas que de outra forma não ocorreria [35, 36]. Pesquisas em scripts de colaboração 6 [37, 1, 35] diferenciam dois tipos de scripts:

27 27 Micro-scripts são modelos de diálogos, geralmente modelos de argumentação, que são embutidos no ambiente computacional e que os estudantes devem adotar e progressivamente internalizar, por exemplo: inícios de sentenças, perguntas ou descrições detalhadas de atividades. Macro-scripts são modelos pedagógicos focados na organização e estruturação da atividade colaborativa. Eles estruturam a interação enfatizando a sequência de atividades que devem ser realizadas pelos estudantes. Essa pesquisa foca nos macro-scripts para guiar o processo de derivação de groupware pois informam em alto nível como as pessoas deverão interagir no groupware. Não há, até o momento dessa pesquisa, uma padronização na descrição de cenários pedagógicos para a o uso combinado com tecnologias computacionais. A Open University of the Netherlands (OUNL) desenvolveu uma linguagem, a IMS Learning Desin (IMS-LD), que foi projetada para possibilitar a descrição de diferentes práticas pedagógicas [38]. No entanto, a linguagem carece de software de suporte, o que dificulta seu uso por pessoas com conhecimentos limitados em computação. A falta de padronização dos scripts de colaboração levou ao desenvolvimento do framework genérico [35] usado nessa pesquisa para determinar a linguagem de especificação desses scripts. Esse framework usa um pequeno número de componentes e mecanismos que são descritos a seguir: Componentes. Compreendem os indivíduos que participam em um script de colaboração, as atividades que eles realizam, os papéis que assumem, o recurso que usam e os grupos que forma. o Participantes. Em geral indica o número de participantes que um script deve ter, por exemplo: três a oito participantes. Pode-se também levar em consideração a opinião ou conhecimento em um domínio, por exemplo participantes com opiniões divergentes. o Atividades. Indica as atividades que os participantes devem executar no script. o Papéis. Refere-se a participantes específicos para os quais atividades devem ser atribuídas e recursos devem ser alocados. Também se pode associar participantes 7 com privilégios, obrigações e expectativas. o Recursos. Compreende objetos virtuais ou físicos que podem oferecer uma informação ou funcionalidade importante. Em geral, é

28 28 associado a participantes, mas também podem ser associados a atividades. o Grupos. Participantes podem ser agrupados para executar as atividades definidas no script. Os critérios para a formação de grupos são diversos como, por exemplo, gênero, faixa etária ou apenas grupos aleatórios para alcançar a quantidade de participantes necessária para as atividades. Mecanismos. Descrevem a natureza distribuída dos scripts através da definição de atributos como: o Distribuição de tarefas. Descreve como as atividades, os papéis e recursos são distribuídos entre os participantes. o Formação de grupos. Descreve como participantes são distribuídos entre os grupos. o Sequenciamento. Descreve como componentes e grupos estão distribuídos através do tempo. Dado que os scripts de colaboração estruturam o fluxo das atividades colaborativas, os grupos e os papéis envolvidos nessas atividades, nessa pesquisa propôs-se o uso do Business Process Modeling Notation (BPMN) para descrevê-los. A próxima seção apresenta o BPMN e seus principais elementos. 2.3.BPMN Business Process Model Notation Business Process Modeling Notation (BPMN) [39] é uma notação para modelar processos de negócios especificada pela Object Management Group (OMG [40]). Foi desenvolvida para prover uma notação que pudesse ser entendida por diferentes tipos de usuários, desde analistas de negócios, que criam as versões inciais do processo, a desenvolvedores responsáveis pela tecnologia de suporte a tais processos, além dos usuários responsáveis pelo gerenciamento do processo. BPMN cria uma ligação padrão entre o projeto de processos de negócio e a implementação desses processos. BPMN define um diagrama de processo de negócios (Business Process Diagram BPD), que é baseado na técnica de fluxograma adaptada para a criação de modelos gráficos de operações de processos de negócios. Um modelo de processos de negócio, então, consiste numa rede de objetos gráficos 8 que são atividades e fluxos de controle que define a ordem de execução das atividades [41]. Os elementos do BPD são divididos em 4 categorias:

29 29 Objetos de fluxo. Um BPD conta com três elementos para representar os objetos de fluxo que são: o Evento (event). Um evento é representado por um círculo e representa algo que acontece durante o andamento de um processo de negócio. Esses eventos afetam o fluxo dos processos e geralmente têm uma causa ou um impacto. Existem três tipos de eventos, baseados em quando eles afetam o fluxo: início, intermediário e fim, representados respectivamente na Figura 1(a). o Atividade (activity). Uma atividade é representada por um retângulo com cantos arredondados e é um termo genérico para o trabalho que a companhia executa. Uma atividade pode ser atômica ou composta. Os tipos de atividade são: tarefas e subprocessos. O subprocesso é identificado por um sinal de soma + centralizado na parte inferior da forma. A atividade é representada na Figura 1 (b). o Gateway. Um gateway é representado por um losango e é usado para controlar a divergência e convergência da sequência de fluxo. Figura 1. Objetos de fluxo BPMN [41]. Objetos de conexão. Os objetos de fluxo são interligados para criar a estrutura do processo de negócio, para tanto, existem três objetos de conexão representados pela Figura 2 e descritos abaixo: o Fluxo de sequência (sequence flow). Um fluxo de sequência é representado por uma seta sólida direcionada e é usada para ordenar as atividades a serem executadas no processo. o Fluxo de mensagem (sequence message). Um fluxo de mensagem é representado pela seta entrecortada direcional e é usada para mostrar o fluxo das mensagens entre dois processos participantes. o Associação (association). Uma associação é representada por uma seta pontilhada direcionada e é usada para associar dados, textos e outros artefatos com objetos de fluxo. Associações são usadas para 9 ilustrar as entradas e saídas das atividades.

30 30 Figura 2. Objetos de conexão BPMN [41]. Swimlanes. Diversos processos usam o conceito de swimlanes como um mecanismo para organizar atividades em categorias visualmente separadas para ilustrar diferentes possibilidades funcionais ou responsabilidades. As swimlanes estão ilustradas na Figura 3. São dois tipos de estruturas: o Pools. Uma pool representa um participante em um processo. Também atua como um container gráfico para dividir o conjunto de atividades de outras pools. o Lanes. Uma lane é uma partição dentro de uma pool e ocupa a largura inteira da pool. Lanes são usadas para organizar e categorizar atividades. Figura 3. Swimlanes BPMN [41]. Artefatos. Os artefatos podem ser adicionados ao diagrama de acordo com a necessidade do processo que está sendo modelado (Figura 4). São três os elementos para representar artefatos: o Objetos de dados (data objects). Objetos de dados são mecanismos para ilustrar como o dado é requerido ou produzido pelas atividades. Eles são conectados a atividades por associações. o Grupo (group). Um grupo é representado por um retângulo com cantos arredondados desenhado com linha pontilhada. O agrupamento pode ser usado com o propósito de documentação ou 0 análise e não afeta o fluxo de sequência. o Anotação (annotation). Anotações são mecanismos para prover informação textual adicional ao leitor de um diagrama BPMN.

Uma Abordagem de Desenvolvimento de Groupware Baseada em Linha de Produto de Software e Modelo 3C de Colaboração

Uma Abordagem de Desenvolvimento de Groupware Baseada em Linha de Produto de Software e Modelo 3C de Colaboração Bruno Freitas Gadelha Uma Abordagem de Desenvolvimento de Groupware Baseada em Linha de Produto de Software e Modelo 3C de Colaboração Tese de Doutorado Tese apresentada como requisito parcial para obtenção

Leia mais

BPMN Business Process Modeling Notation

BPMN Business Process Modeling Notation BPMN Business Process Modeling Notation Business Process Modeling Notation Página 1 Objetivo O objetivo deste curso é apresentar os elementos da notação de modelagem de processos de negócio BPMN 1.1 (Business

Leia mais

Projeto de Sistemas I

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

Leia mais

PESQUISA-AÇÃO DICIONÁRIO

PESQUISA-AÇÃO DICIONÁRIO PESQUISA-AÇÃO Forma de pesquisa interativa que visa compreender as causas de uma situação e produzir mudanças. O foco está em resolver algum problema encontrado por indivíduos ou por grupos, sejam eles

Leia mais

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

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Pó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 mais

Requisitos de Software. Teresa Maciel DEINFO/UFRPE

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

Leia mais

AUTOR: 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 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 mais

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA RESUMO Ricardo Della Libera Marzochi A introdução ao Service Component Architecture (SCA) diz respeito ao estudo dos principais fundamentos

Leia mais

Feature-Driven Development

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

UML - Unified Modeling Language

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

Leia mais

Governança de TI. ITIL v.2&3. parte 1

Governanç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 mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I BPMN I Ricardo de Sousa Britto rbritto@ufpi.edu.br 1 + Processo de Negócio 2 n Coleção de atividades relacionadas e estruturadas que produzem um serviço ou produto específico.

Leia mais

GARANTIA DA QUALIDADE DE SOFTWARE

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

Leia mais

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

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

Leia mais

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

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de Software AULA NÚMERO: 10 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir os conceitos de coesão e acoplamento. DESENVOLVIMENTO Projetar

Leia mais

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil Elicitação de Requisitos a partir de Modelos de Processos de Negócio e Modelos Organizacionais: Uma pesquisa para definição de técnicas baseadas em heurísticas Marcos A. B. de Oliveira 1, Sérgio R. C.

Leia mais

Gestão de Processos de Negócios

Gestão de Processos de Negócios Gestão Operacional da TI Gestão de Processos de Negócios Business Process Management (BPM) Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Professor NOME: RÔMULO CÉSAR DIAS DE ANDRADE

Leia mais

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE

Leia mais

BPMN. Business Process Modeling Notation. Leandro C. López Agosto - 2015

BPMN. Business Process Modeling Notation. Leandro C. López Agosto - 2015 BPMN Business Process Modeling Notation Leandro C. López Agosto - 2015 Objetivos Conceitos Boas práticas de modelagem Elementos do BPMN Tipos de processos Apresentar os conceitos e elementos da notação

Leia mais

Engenharia de Software

Engenharia de Software Universidade São Judas Tadeu Profª Dra. Ana Paula Gonçalves Serra Engenharia de O Processo Uma Visão Genérica Capítulo 2 (até item 2.2. inclusive) Engenharia de - Roger Pressman 6ª edição McGrawHill Capítulo

Leia mais

Oficina de Gestão de Portifólio

Oficina de Gestão de Portifólio Oficina de Gestão de Portifólio Alinhando ESTRATÉGIAS com PROJETOS através da GESTÃO DE PORTFÓLIO Gestão de portfólio de projetos pode ser definida como a arte e a ciência de aplicar um conjunto de conhecimentos,

Leia mais

Processos de gerenciamento de projetos em um projeto

Processos de gerenciamento de projetos em um projeto Processos de gerenciamento de projetos em um projeto O gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de cumprir seus requisitos.

Leia mais

Tó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 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 mais

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

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas

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

BPM Definições e Contexto Prática Aula 1

BPM Definições e Contexto Prática Aula 1 BPM Definições e Contexto Prática Aula 1 BP Business Process Algumas definições sobre o que é Processos de Negócio (BP) Um processo é um fluxo coordenado e padronizado de atividades executadas por pessoas

Leia mais

Engenharia de Requisitos

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

Guia de utilização da notação BPMN

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

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

BPMN - Business Process Modeling and Notation

BPMN - Business Process Modeling and Notation BPMN - Business Process Modeling and Notation AGENDA Notação Conceito Visão Geral da Notação BPMN Notação BPMN no Escritório de Processos NOTAÇÃO - CONCEITO Segundo o dicionário: Ação de indicar, de representar

Leia mais

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

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

Leia mais

Engenharia de Requisitos Estudo de Caso

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

Leia mais

BPMN (Business Process. George Valença gavs@cin.ufpe.br

BPMN (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 mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

ENGENHARIA DE SOFTWARE I

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

Leia mais

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

Metodologia de Gerenciamento de Projetos da Justiça Federal

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

Engenharia de Software III

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

Lista de verificação (Check list) para planejamento e execução de Projetos

Lista de verificação (Check list) para planejamento e execução de Projetos www.tecnologiadeprojetos.com.br Lista de verificação (Check list) para planejamento e execução de Projetos Eduardo F. Barbosa Dácio G. Moura Material didático utilizado na disciplina Desenvolvimento de

Leia mais

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

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

Leia mais

Fase 1: Engenharia de Produto

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

Leia mais

Profissionais de Alta Performance

Profissionais de Alta Performance Profissionais de Alta Performance As transformações pelas quais o mundo passa exigem novos posicionamentos em todas as áreas e em especial na educação. A transferência pura simples de dados ou informações

Leia mais

GESTÃO DAS INFORMAÇÕES DAS ORGANIZAÇÕES MÓDULO 11

GESTÃO DAS INFORMAÇÕES DAS ORGANIZAÇÕES MÓDULO 11 GESTÃO DAS INFORMAÇÕES DAS ORGANIZAÇÕES MÓDULO 11 Índice 1. Importância do ERP para as organizações...3 2. ERP como fonte de vantagem competitiva...4 3. Desenvolvimento e implantação de sistema de informação...5

Leia mais

Estratégias de Pesquisa

Estratégias de Pesquisa Estratégias de Pesquisa Ricardo de Almeida Falbo Metodologia de Pesquisa Departamento de Informática Universidade Federal do Espírito Santo Agenda Survey Design e Criação Estudo de Caso Pesquisa Ação Experimento

Leia mais

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

O modelo unificado de processo. O Rational Unified Process, RUP.

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

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

ISO/IEC 12207: Gerência de Configuração

ISO/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 mais

TRABALHOS TÉCNICOS Coordenação de Documentação e Informação INOVAÇÃO E GERENCIAMENTO DE PROCESSOS: UMA ANÁLISE BASEADA NA GESTÃO DO CONHECIMENTO

TRABALHOS TÉCNICOS Coordenação de Documentação e Informação INOVAÇÃO E GERENCIAMENTO DE PROCESSOS: UMA ANÁLISE BASEADA NA GESTÃO DO CONHECIMENTO TRABALHOS TÉCNICOS Coordenação de Documentação e Informação INOVAÇÃO E GERENCIAMENTO DE PROCESSOS: UMA ANÁLISE BASEADA NA GESTÃO DO CONHECIMENTO INTRODUÇÃO Os processos empresariais são fluxos de valor

Leia mais

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

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

Leia mais

ü Curso - Bacharelado em Sistemas de Informação

ü Curso - Bacharelado em Sistemas de Informação Curso - Bacharelado em Sistemas de Informação Nome e titulação do Coordenador: Coordenador: Prof. Wender A. Silva - Mestrado em Engenharia Elétrica (Ênfase em Processamento da Informação). Universidade

Leia mais

Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO)

Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO) Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO) Parte: 1 Prof. Cristóvão Cunha Objetivos de aprendizagem

Leia mais

Wilson Moraes Góes. Novatec

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

2 Diagrama de Caso de Uso

2 Diagrama de Caso de Uso Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa

Leia mais

RELATÓRIO TREINAMENTO ADP 2013 ETAPA 01: PLANEJAMENTO

RELATÓRIO TREINAMENTO ADP 2013 ETAPA 01: PLANEJAMENTO RELATÓRIO TREINAMENTO ADP 2013 ETAPA 01: PLANEJAMENTO 1. Apresentação geral Entre os dias 15 e 18 de Abril de 2013 foram realizados encontros de quatro horas com os servidores e supervisores da Faculdade

Leia mais

PVANET: PRINCIPAIS FERRAMENTAS E UTILIZAÇÃO DIDÁTICA

PVANET: PRINCIPAIS FERRAMENTAS E UTILIZAÇÃO DIDÁTICA 11 PVANET: PRINCIPAIS FERRAMENTAS E UTILIZAÇÃO DIDÁTICA O PVANet é o ambiente virtual de aprendizagem (AVA) de uso exclusivo da UFV. Os AVAs apresentam diferenças de layout, forma de acesso, funcionamento,

Leia mais

MASTER IN PROJECT MANAGEMENT

MASTER IN PROJECT MANAGEMENT MASTER IN PROJECT MANAGEMENT PROJETOS E COMUNICAÇÃO PROF. RICARDO SCHWACH MBA, PMP, COBIT, ITIL Atividade 1 Que modelos em gestão de projetos estão sendo adotados como referência nas organizações? Como

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Introdução Projeto de Arquitetura (Cap 11 - Sommerville) UNIVERSIDADE FEDERAL DE ALAGOAS Curso de Ciência da Computação Engenharia de Software I Prof. Rômulo Nunes de Oliveira Até agora, estudamos: Os

Leia mais

APOO Análise e Projeto Orientado a Objetos. Requisitos

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

Leia mais

AULA 11 Desenhos, recursos e obstáculos

AULA 11 Desenhos, recursos e obstáculos 1 AULA 11 Desenhos, recursos e obstáculos Ernesto F. L. Amaral 15 de abril de 2010 Metodologia (DCP 033) Fonte: Flick, Uwe. 2009. Desenho da pesquisa qualitativa. Porto Alegre: Artmed. pp.57-73 & 75-85.

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 3 Planejamento e Aula 8 do Projeto Aula 08 do Projeto SUMÁRIO INTRODUÇÃO... 3 ACOMPANHAMENTO DO PROJETO... 3 1. do Progresso...

Leia mais

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

MBA MARKETING DE SERVIÇOS. Turma 19. Curso em Ambiente Virtual

MBA MARKETING DE SERVIÇOS. Turma 19. Curso em Ambiente Virtual MBA MARKETING DE SERVIÇOS Turma 19 Curso em Ambiente Virtual São Paulo, 1 de Setembro de 2011 1. Apresentação O MBA em Marketing de Serviços, coordenado pelos Professores Marcos Cortez Campomar e Geraldo

Leia mais

DIRETRIZES DA EDUCAÇÃO A DISTÂNCIA NO SISTEMA INTEGRADO DE FORMAÇÃO DA MAGISTRATURA DO TRABALHO - SIFMT

DIRETRIZES DA EDUCAÇÃO A DISTÂNCIA NO SISTEMA INTEGRADO DE FORMAÇÃO DA MAGISTRATURA DO TRABALHO - SIFMT DIRETRIZES DA EDUCAÇÃO A DISTÂNCIA NO SISTEMA INTEGRADO DE FORMAÇÃO DA MAGISTRATURA DO TRABALHO - SIFMT 1 SUMÁRIO 1. APRESENTAÇÃO 2. CENÁRIO PROFISSIONAL 3. CONCEPÇÃO DA APRENDIZAGEM E METODOLOGIA 4. ESTRATÉGIAS

Leia mais

Processos de Desenvolvimento de Software

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

CONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS

CONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS MINISTÉRIO DO DESENVOLVIMENTO AGRÁRIO SUBSECRETARIA DE PLANEJAMENTO, ORÇAMENTO E ADMINISTRAÇÃO COORDENAÇÃO-GERAL DE MODERNIZAÇÃO E INFORMÁTICA CONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS MANUAL

Leia mais

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

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

Leia mais

Modelo Cascata ou Clássico

Modelo Cascata ou Clássico Modelo Cascata ou Clássico INTRODUÇÃO O modelo clássico ou cascata, que também é conhecido por abordagem top-down, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação

Leia mais

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

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

Leia mais

Capítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1

Capítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1 Capítulo 2 Processos de Software slide 1 Tópicos apresentados Modelos de processo de software. Atividades de processo. Lidando com mudanças. Rational Unified Process (RUP). Um exemplo de um processo de

Leia mais

IMPLEMENTAÇÃO DAS CAMADAS Inference Machine e Message Service Element PARA UM SERVIDOR DE SISTEMA DE GERENCIAMENTO DE Workflow HOSPITALAR

IMPLEMENTAÇÃO DAS CAMADAS Inference Machine e Message Service Element PARA UM SERVIDOR DE SISTEMA DE GERENCIAMENTO DE Workflow HOSPITALAR IMPLEMENTAÇÃO DAS CAMADAS Inference Machine e Message Service Element PARA UM SERVIDOR DE SISTEMA DE GERENCIAMENTO DE Workflow HOSPITALAR Jeferson J. S. Boesing 1 ; Manassés Ribeiro 2 1.Aluno do Curso

Leia mais

Tutorial Moodle Visão do Aluno

Tutorial Moodle Visão do Aluno Tutorial Moodle Visão do Aluno A P R E S E N T A Ç Ã O A sigla MOODLE significa (Modular Object Oriented Dynamic Learning Environment), em inglês MOODLE é um verbo que descreve a ação ao realizar com gosto

Leia mais

Agenda da Aula. Resumo dos Padrões (Aula 4) Padrões Arquiteturais. Arquitetura Cliente-Servidor. Arquitetura Cliente-Servidor

Agenda da Aula. Resumo dos Padrões (Aula 4) Padrões Arquiteturais. Arquitetura Cliente-Servidor. Arquitetura Cliente-Servidor Reuso de Software Aula 05 Agenda da Aula Linha de Produtos de Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo reuso.software@gmail.com 19 Março 2012 Padrões arquiteturais Cliente-Servidor

Leia mais

)HUUDPHQWDV &RPSXWDFLRQDLV SDUD 6LPXODomR

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

Leia mais

Engenharia de Sistemas Computacionais

Engenharia de Sistemas Computacionais Engenharia de Sistemas Detalhes no planejamento UNIVERSIDADE FEDERAL DE ALAGOAS Curso de Ciência da Computação Engenharia de Software I Prof. Rômulo Nunes de Oliveira Introdução Na aplicação de um sistema

Leia mais

Mídias sociais como apoio aos negócios B2C

Mídias sociais como apoio aos negócios B2C Mídias sociais como apoio aos negócios B2C A tecnologia e a informação caminham paralelas à globalização. No mercado atual é simples interagir, aproximar pessoas, expandir e aperfeiçoar os negócios dentro

Leia mais

3 Metodologia de pesquisa

3 Metodologia de pesquisa 3 Metodologia de pesquisa Neste capitulo será feita uma breve explanação da metodologia de pesquisa que serviu de fundamentação às definições apresentadas. Serão definidos: o objeto de estudo, as questões

Leia mais

Sistemas de Informação I

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

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.

Glossá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 mais

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

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

Abordagem de Processo: conceitos e diretrizes para sua implementação

Abordagem de Processo: conceitos e diretrizes para sua implementação QP Informe Reservado Nº 70 Maio/2007 Abordagem de Processo: conceitos e diretrizes para sua implementação Tradução para o português especialmente preparada para os Associados ao QP. Este guindance paper

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2009 Profa. Dra. Itana Gimenes RUP: Artefatos de projeto Modelo de Projeto: Use-Case Realization-projeto

Leia mais

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

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

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

Leia mais

Processo de Desenvolvimento Unificado

Processo de Desenvolvimento Unificado Processo de Desenvolvimento Unificado Processo de Desenvolvimento de Software? Conjunto de atividades bem definidas; com responsáveis; com artefatos de entrada e saída; com dependências entre as mesmas

Leia mais

Processos Técnicos - Aulas 4 e 5

Processos Técnicos - Aulas 4 e 5 Processos Técnicos - Aulas 4 e 5 Trabalho / PEM Tema: Frameworks Públicos Grupo: equipe do TCC Entrega: versão digital, 1ª semana de Abril (de 31/03 a 04/04), no e-mail do professor (rodrigues.yuri@yahoo.com.br)

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Aula 02 Análise e Projeto OO Edirlei Soares de Lima Análise A análise modela o problema e consiste das atividades necessárias para entender

Leia mais

Princípios de Finanças

Princípios de Finanças Princípios de Finanças Apostila 02 A função da Administração Financeira Professora: Djessica Karoline Matte 1 SUMÁRIO A função da Administração Financeira... 3 1. A Administração Financeira... 3 2. A função

Leia mais

MANUAL DE ATIVIDADES COMPLEME MENTARES CURSO DE ENFERMAGEM. Belo Horizonte

MANUAL DE ATIVIDADES COMPLEME MENTARES CURSO DE ENFERMAGEM. Belo Horizonte MANUAL DE ATIVIDADES COMPLEME MENTARES CURSO DE ENFERMAGEM Belo Horizonte 2013 ÍNDICE 1 APRESENTAÇÃO... 3 2 FINALIDADE... 3 3 DEVERES DO COORDENADOR EM RELAÇÃO AS ATIVIDADES COMPLEMENTARES... 4 4 DEVERES

Leia mais

Universidade de Brasília Faculdade de Economia, Administração, Contabilidade e Ciência da Informação e Documentação Departamento de Ciência da

Universidade de Brasília Faculdade de Economia, Administração, Contabilidade e Ciência da Informação e Documentação Departamento de Ciência da Universidade de Brasília Faculdade de Economia, Administração, Contabilidade e Ciência da Informação e Documentação Departamento de Ciência da Informação e Documentação Disciplina: Planejamento e Gestão

Leia mais

Introdução à Engenharia de Software

Introduçã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 mais

A Linguagem de Modelagem Unificada (UML)

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

OFICINA DA PESQUISA DISCIPLINA: COMPORTAMENTO ORGANIZACIONAL

OFICINA DA PESQUISA DISCIPLINA: COMPORTAMENTO ORGANIZACIONAL OFICINA DA PESQUISA DISCIPLINA: COMPORTAMENTO ORGANIZACIONAL Prof. Ms. Carlos José Giudice dos Santos carlos@oficinadapesquisa.com.br www.oficinadapesquisa.com.br Objetivo Geral da Disciplina: Apresentar

Leia mais

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

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

Leia mais