UNIVERSIDADE ESTADUAL DE FEIRA DE SANTANA
BACHARELADO EM ENGENHARIA DE COMPUTAÇÃO
IMPLEMENTAÇÃO E VALIDAÇÃO DE UMA ESTRATÉGIA DE
IMPLANTAÇÃO DE SOFTWARE BASEADA NO MÉTODO PBL
MAYARA DIAS GONÇALVES
Feira de Santana 2014
MAYARA DIAS GONÇALVES
IMPLEMENTAÇÃO E VALIDAÇÃO DE UMA ESTRATÉGIA DE
IMPLANTAÇÃO DE SOFTWARE BASEADA NO MÉTODO PBL
Trabalho de Conclusão de Curso apresentado ao curso de Engenharia de Computação da Universidade Estadual de Feira de Santana, como requisito parcial à obtenção do título de Bacharel em Engenharia de Computação.
Orientadora: Profª Drª Gabriela Ribeiro Peixoto Rezende Pinto
Feira de Santana 2014
Dedico esse trabalho a todos que, de alguma forma, acreditaram em mim e me ajudaram a chegar até aqui. Especialmente a meus pais,
AGRADECIMENTOS
Agradeço primeiramente aos meus pais, Dina e Pedro, por todo o apoio em todos os momentos deste trabalho, sempre me incentivando e confiando no meu potencial. Aos meus irmãos, Michele e Beto pelas comemorações a cada passo dado e por sempre me alegrarem nos momentos complicados.
A meu amor, Felipe, por estar sempre presente, pelo carinho e paciência. Em especial a toda ajuda que ele me deu no decorrer deste trabalho e seus preciosos conselhos.
Agradeço de forma bastante especial à Professora Gabriela Rezende, por ser uma professora e pessoa incrível e ter me inspirado a seguir a carreira acadêmica. Por me orientar, por seus ensinamentos, paciência, suporte, incansáveis leituras do nosso texto.
Meus agradecimentos à equipe da Assessoria Especial de Informática por possibilitarem meu crescimento profissional e contribuírem com o pessoal. Muito obrigada por apoiar esta pesquisa e autorizar a utilização do CASYS.
Por fim, agradeço aos meus amigos, especialmente a Suenny, Tayane, Priscila e Adriano por me falarem “você consegue”, vocês também me ajudaram a chegar aqui.
“There will be an answer, let it be.” (Paul McCartney e John Lennon)
RESUMO
O desenvolvimento de softwares envolve diversos desafios desde a análise de requisitos à entrega do software. Parte desses desafios surge da necessidade de interação com os usuários, fato que ocorre em todo o processo de software. A implantação de um software em um ambiente de trabalho requer cuidados com os usuários e a adaptação dos mesmos à nova rotina deve ser observada e auxiliada por parte da equipe de desenvolvimento e implantação. Este trabalho relata a proposta e validação de uma estratégia de implantação de software baseada no método PBL. Essa estratégia objetiva a suavização dos desafios relacionados à baixa disponibilidade dos usuários e na necessidade de qualificação dos mesmos. Neste trabalho, a estratégia elaborada será detalhada e validada. A validação ocorreu utilizando a técnica de estudo de caso no Centro Universitário de Cultura e Arte, setor da Universidade Estadual de Feira de Santana e o software CASYS contando com a participação de cinco funcionários. Os resultados obtidos serão analisados e discutidos, trazendo a evidência de que o PBL aliado à Engenharia de Software traz resultados positivos no que tange a implantação de software, sobretudo à capacitação dos usuários.
Palavras-chave: Implantação de Software, PBL, Educação, Engenharia de Software, Entrega de Software, Capacitação de Usuários.
ABSTRACT
The development of softwares faces many challenges from the requirements analysis to the delivery of the software. Part of these challenges arise from the need of interaction with the users, fact that occurs in all the software process. A software's implantation on an work environment requires care with the users and the adaptation of them to the routine must be observed and assisted by the development and implantation staff. This work reports the proposal and validation of a software implantation strategy based on the PBL method. This strategy aims to soften the challenges related to the low availability of the users and also the need to qualify them. In this work, the elaborate strategy will be detailed and validated. The validation occurred utilizing the case study technique at the Centro Universitário de Cultura e Arte, sector of the Universidade Estadual de Feira de Santana and the software CASYS counting with the participation of five employees. The results obtained will be analyzed and discussed, bringing up the evidence that the PBL allied to Software Engineering brings positive results to the software implantation, specially to the users's capacitation.
Key-words: Software Implantation, PBL, Education, Software Engineering, Software Delivery, Users's Capacitation.
LISTA DE FIGURAS
Figura 1 - Procedimentos Metodológicos ... 18
Figura 2–Esquema do Modelo Cascata ... 24
Figura 3– Esquema do Modelo Incremental ... 25
Figura 4 - Esquema do Modelo Orientado a Reuso ... 26
Figura 5 - Modelo Cascata ... 30
Figura 6 - Ciclo de vida de software clássico ... 31
Figura 7 - Ciclo de vida de software proposto por Souza (2009)... 31
Figura 8 - Esquema da Metodologia de Implantação de Software Corporativo 32 Figura 9 - O Ciclo PBL ... 35
Figura 10 - Modelo Cascata Adaptado ... 37
Figura 11 - Esquema da Estratégia de Implantação de Software Proposta ... 38
Figura 12 - Visão geral do CASYS ... 50
Figura 13 - Relatório de matrículas ... 52
Figura 14 – Detalhe do relatório de matrículas filtrado para Estudante 1 ... 53
Figura 15 – Detalhe do cadastro de pagamento para Estudante 1 ... 53
Figura 16 - Detalhe do relatório de pagamento filtrado para o Estudante 1 ... 53
Figura 17 - Detalhe da edição de pagamento para Estudante 1 ... 54
Figura 18 - Detalhe da personalização de relatório ... 54
Figura 19 - Detalhe do relatório personalizado... 54
Figura 20 - Exportação do relatório para o formato PDF ... 55
Figura 21 - Detalhe do PDF gerado ... 55
SUMÁRIO 1. INTRODUÇÃO ... 11 1.1 PROBLEMA DE PESQUISA ... 14 1.2 PRESSUPOSTO DE PESQUISA ... 14 1.3 OBJETIVOS ... 14 1.4 JUSTIFICATIVA ... 15 1.5 TRABALHOS CORRELATOS ... 16 1.6 ASPECTOS METODOLÓGICOS ... 18 1.7 ESTRUTURA DA MONOGRAFIA ... 20 2. REVISÃO BIBLIOGRÁFICA ... 21
2.1 AUTOMAÇÃO DE PROCESSOS ADMINISTRATIVOS ... 21
2.2 WEBAPPS ... 22
2.3 PROCESSO DE SOFTWARE ... 23
2.4 TESTES DE SOFTWARE EM WEBAPPS ... 26
2.4.1 Teste de aceitação ... 28
2.5 IMPLANTAÇÃO DE SOFTWARE ... 29
2.6 PROPOSTA DE INCLUSÃO DA FASE DE IMPLANTAÇÃO NO MODELO CASCATA E A METODOLOGIA DE IMPLANTAÇÃO DE SOFTWARE DE SOUZA (2009) ... 30
2.7 PROBLEM-BASED LEARNING (PBL) ... 32
3. UMA ESTRATÉGIA PARA POTENCIALIZAÇÃO DA FoRMAÇÃO DOS USUÁRIOS E DA ACEITAÇÃO DO SOFTWARE ... 36
3.1 ESTRATÉGIA PROPOSTA ... 36
3.1.1 Identificação dos Usuários Finais ... 38
3.1.1.1 Objetivos 38 3.1.1.2 Atividades Programadas ... 39
3.1.2 Levantamento do Perfil do Grupo ... 40
3.1.2.1 Objetivos 40 3.1.2.2 Atividades Programadas ... 40
3.1.3 Preparação do Ambiente ... 41
3.1.3.1 Objetivos 41 3.1.3.2 Atividades Programadas ... 41
3.1.4 Primeiro Contato do Usuário com o Sistema ... 42
3.1.4.1 Objetivos 42 3.1.4.2 Atividades Programadas ... 42
3.1.5 Aplicação do(s) Problema(s) ... 43
3.1.5.1 Objetivos 43 3.1.5.2 Atividades Programadas ... 43
3.1.6 Validação do Aprendizado ... 44 3.1.6.1 Objetivos 44 3.1.6.2 Atividades Programadas ... 45 3.1.7 Conclusão ... 45 3.1.7.1 Objetivos 45 3.1.7.2 Atividades Programadas ... 45 4. METODOLOGIA ... 47 4.1 CAMPO DA PESQUISA ... 48 4.2 O CASYS ... 49
4.3 PROBLEMA APLICADO NO AMBIENTE DE VALIDAÇÃO ... 50
4.4 RESOLUÇÃO ESPERADA PARA O PROBLEMA ... 51
4.5 PARTICIPANTES DA PESQUISA ... 55
4.6 TÉCNICAS E INSTRUMENTOS UTILIZADOS PARA O LEVANTAMENTO DE DADOS 56 4.7 MÉTODO E CRITÉRIOS PARA A ANÁLISE DOS RESULTADOS OBTIDOS ... 57
4.8 ASPECTOS ÉTICOS DA PESQUISA ... 58
4.8.1 Benefícios para os Participantes ... 59
4.8.2 Benefícios para a Sociedade ... 59
4.8.3 Riscos Inerentes à Pesquisa ... 59
4.8.4 Medidas de proteção ... 60
5. DISCUSSÃO E ANÁLISE DOS RESULTADOS OBTIDOS ... 61
5.1 IMPLANTAÇÃO DO CASYS NO CUCA UTILIZANDO A ESTRATÉGIA PROPOSTA 61 5.1.1 Identificação dos Usuários Finais ... 61
5.1.2 Levantamento do Perfil do Grupo ... 62
5.1.3 Preparação do Ambiente ... 63
5.1.4 Primeiro Contato do Usuário com o Sistema ... 63
5.1.5 Aplicação do Problema ... 64
5.1.6 Validação do Aprendizado ... 66
5.1.7 Conclusão ... 67
5.2 RESULTADO DA PESQUISA DE ACEITAÇÃO DA ESTRATÉGIA PROPOSTA ... 67
5.3 ADAPTAÇÃO DO PBL ACADÊMICO EM ENGENHARIA PARA O USO NA ENGENHARIA DE SOFTWARE ... 72
6. CONSIDERAÇÕES FINAIS ... 75
1. INTRODUÇÃO
Nas últimas décadas, as aplicações computacionais têm invadido os mais diversos setores da sociedade. Esta invasão tecnológica pode representar a agilidade e a qualidade dos serviços prestados por estes setores, aumentando a satisfação e a qualidade de vida da população. Neste contexto, a automação de processos é uma prática que substitui ou incrementa a mão-de-obra humana; um exemplo é automação dentro de escritórios em que o computador substitui as planilhas, textos, livros e até calculadoras manuais; e nas fábricas, onde robôs soldam e pintam automóveis (TURBAN, MCLEAN e WETHERB, 2002).
Há uma grande demanda pela informatização das mais diversas atividades, antes só realizadas através de mão-de-obra humana. Entre o leque de áreas em que a automação de processos pode atuar, encontram-se os softwares de gestão empresarial (do inglês Enterprise Resource Planning - ERP), que integram os dados de uma organização, armazenando suas informações de negócios (TURBAN, 2010).
No contexto organizacional, onde o software representa papel fundamental, a Engenharia de Software surge para oferecer aos profissionais da área de computação recursos que os auxiliem, por exemplo, no controle de qualidade de software, dos prazos e dos custos (HIRAMA, 2012). Lobo (2008) explica que a Engenharia de Software é “uma ciência que estuda metodologias e padrões de desenvolvimento de software”. Neste ponto, a Engenharia de Software se torna um campo de conhecimento fundamental para o processo de desenvolvimento de um software ocorrer de forma satisfatória.
A Engenharia de Software aborda diversas áreas, tais como qualidade de software, desenvolvimento de software, manutenção de software, etc. dentre elas, encontram-se os processos de software. No que tange o desenvolvimento de software, Lobo (2008) afirma que processo é um modo de organizar, prover qualidade, controlar o cumprimento de prazos e tornar o desenvolvimento ágil.
Envolvida no processo de desenvolvimento de software, há a implantação de software que, de acordo com Pfleeger (2004, apud SILVA,
2005), é a fase em que o sistema implementado é disponibilizado para o uso real, sendo que se esta entrega não for bem sucedida, pode ocorrer descontentamento por parte dos usuários, o que pode causar baixa produção e eficiência. Neste ponto, fica claro que a participação dos usuários neste processo tem um papel fundamental. É notável, então, a importância da fase da implantação para a aceitação do software produzido.
Souza (2009), defendendo a importância da fase de implantação do software em sua dissertação de mestrado, propõe a adaptação dos ciclos de vida existentes (ou modelos de processo de software). Dentre esses modelos se destacam o modelo cascata, que possui uma estrutura linear; o incremental, que produz diversas versões até o sistema corresponder ao desejado pelos clientes e o modelo orientado a reuso que se baseia na integração de componentes reusáveis (SOMMERVILLE, 2011). Sugere, então, que a fase de implantação, que geralmente é omitida nos referidos modelos, seja incluída e considerada.
Enfatizando a importância de dedicação ao processo de implantação do software, Souza (2009) também propõe uma metodologia voltada para a implantação de softwares corporativos que busca estimular a participação dos usuários e outros interessados, e busca minimizar problemas que porventura surjam durante o período de produção do software.
Alguns desafios são encontrados na literatura quando o assunto é a implantação de um software. Tiago (2009) afirma que as dificuldades de implantar um sistema ERP “decorrem do fato de envolver mudanças organizacionais e que implicam em alterações nas tarefas e responsabilidades entre indivíduos e departamentos”. Neste ponto, pode-se entender que todas as partes da organização onde o sistema será implantado devem estar comprometidas com o processo, já que haverá mudanças significativas na sua forma de trabalho.
Outros aspectos também deverão receber atenção durante a fase de implantação de um software, tais como: rotatividade dos funcionários, possível sobrecarga dos usuários com o novo sistema, falta de capacitação dos funcionários, dependência da organização com o fornecedor do software e necessidade de aprimoramento e atualização (TIAGO, 2010). Estes aspectos
deverão ser observados no momento de elaboração do plano de implantação, levando em consideração as particularidades de cada ambiente.
Ao vivenciar os desafios apontados por Tiago (2010), ao participar da produção e implantação do software denominado Cultura e Arte Sistema (CASYS), desenvolvido em conjunto com a equipe da Assessoria Especial de Informática (AEI) da Universidade Estadual de Feira de Santana (UEFS); e por participar no dia a dia do processo de formação em Engenharia em Computação que adota o método de Aprendizagem Baseada em Problemas (do inglês Problem Based Learning - PBL) para motivar o processo de ensino-aprendizagem; a autora deste trabalho observou, tanto na metodologia de implantação de software corporativo proposta por Souza (2009) quanto em outras metodologias estudadas para a concretização da pesquisa aqui apresentada, que, de uma forma geral, os treinamentos para o usuário são executados de forma expositiva, como em aulas convencionais (utilização do método tradicional de ensino-aprendizagem).
O método tradicional de formação, no contexto dinâmico da sociedade contemporânea, pode representar um desafio à parte no processo de implantação de software, uma vez que o usuário pode sentir que o conhecimento obtido não está relacionado à sua rotina de trabalho, tornando o treinamento desmotivador, minimizando também a oportunidade de aprender fazendo, já que, muitas vezes, a estratégia educacional utilizada separa a teoria da prática.
Por outro lado, o PBL é um método de aprendizagem que utiliza problemas práticos, reais ou simulados, para iniciar, motivar e focar a produção do conhecimento, além de almejar potencializar a capacidade de resolver problemas, de trabalhar em grupo e o desenvolvimento da autonomia (SCHIMDT, 2001 apud RIBEIRO, 2005). Este método foi concebido para o ensino de biologia no final dos anos 1960, porém vem sendo utilizado em diversas áreas de formação, tal como as engenharias (RIBEIRO, 2005). Inclusive, há o estudo da aplicação do PBL não apenas no ensino superior, como também no ensino de biologia no nível médio (ANDRADE, 2007).
1.1 PROBLEMA DE PESQUISA
Este trabalho de pesquisa parte da problemática envolvida na omissão da fase de implantação nos modelos de processo de software tradicionais. O foco é dado no momento da capacitação do usuário, geralmente realizada sob forma de treinamento baseado no método tradicional de ensino-aprendizagem.
1.2 PRESSUPOSTO DE PESQUISA
Como já citado, o desejável é que equipe de implantação busque uma forma de potencializar a motivação e o interesse do usuário no software, ampliando as chances de sucesso da aceitação do produto. Nesta perspectiva, esta pesquisa parte do pressuposto de que o método PBL, aliado às técnicas da Engenharia de Software, poderá ampliar os benefícios previstos em metodologias de implantação de software, já que o mesmo possui algumas características, como a de tornar o usuário parte ativa do processo de aprendizagem e vinculá-lo, assim, ao processo de produção do software.
1.3 OBJETIVOS
A pesquisa que será apresentada neste trabalho almejou integrar os objetivos de metodologias de implantação de software aos objetivos do método PBL, especialmente na fase de capacitação dos usuários para uso do produto. Para verificação de tal proposta, elaborou-se uma estratégia de implantação a partir da metodologia de implantação de softwares corporativos elaborada por Souza (2009) e da dinâmica do método PBL. Para o alcance do objetivo almejado, necessitaram-se:
Compreender os processos de desenvolvimento de software;
Compreender o método de implantação de softwares corporativos proposto por Souza (2009);
Elaborar uma estratégia de implantação de software a partir do processo de software cascata, da proposta de metodologia de implantação de software corporativo de Souza (2009) e do método de Aprendizagem Baseada em Problemas;
Descrever a estratégia proposta;
Verificar e validar a estratégia proposta, a partir da realização de um estudo de caso com os usuários do CASYS, no Centro Universitário de Cultura e Arte, priorizando-se suavizar os desafios relacionados à necessidade de qualificação dos usuários do sistema e baixa disponibilidade dos mesmos.
Discutir e analisar os resultados obtidos.
1.4 JUSTIFICATIVA
A principal contribuição deste trabalho é ampliar as contribuições já fornecidas por pesquisas como a realizada por Souza (2009), a partir da possibilidade de potencialização da motivação da participação dos usuários neste processo e na criação de um ambiente que propicie o aprendizado de software de maneira satisfatória, e que estes se sintam instigados a interagir com o sistema, ampliando as chances de sua aceitação.
Antes do início deste trabalho, já estive envolvida no processo de implementação e início da entrega do CASYS no CUCA. Apesar de não ter iniciado a implementação do CASYS, quando iniciei o estágio na AEI, o sistema ainda não possuía algumas das funcionalidades fundamentais para suprir as necessidades dos usuários. Assim, a equipe de desenvolvimento decidiu agendar a revisão dos requisitos para que o CASYS fosse terminado. Após a revisão dos requisitos, participei da adaptação das funcionalidades já existentes e da implementação das novas, todos estes passos foram documentados. Sendo assim, no que tange a pesquisa de campo, a minha principal motivação foi o desejo de que o CASYS fosse implantado da melhor forma possível.
Acredita-se que este projeto se mostra relevante pela sua contribuição à Engenharia de Software, sobretudo na fase de implantação, propondo a
inclusão nos processos de software de um método de aprendizagem que intensifique a participação dos usuários finais e aumente a autonomia e o comprometimento destes em relação ao uso do software. Este trabalho também carrega caráter social, já que o sucesso da implantação do CASYS no CUCA auxiliará na agilidade das matrículas neste setor, trazendo benefícios para a UEFS, os funcionários, os estudantes e a comunidade local.
1.5 TRABALHOS CORRELATOS
Apesar da autora não ter encontrado trabalhos que unissem a Implantação de Software e o Problem-Based Learning, o que representa uma lacuna na literatura e reforça a importância da pesquisa realizada e aqui apresentada, há um número considerável de trabalhos que tratam dos dois assuntos separadamente. A maioria dos trabalhos correlatos está disponível na internet, uma vez em que a maioria se trata de artigos publicados em eventos e periódicos, trabalhos de conclusão de curso e dissertações de mestrado.
No que tange a fase de implantação de software, pode-se destacar os artigos de Helbert Carvalho Tiago a respeito dos desafios envolvidos na implantação de software e suas vantagens e desvantagens (TIAGO, 2010). Márcio Kina, em seu trabalho de conclusão de curso, intitulado “Implantação de Softwares Livres em uma Pequena Empresa”, também aborda a implantação de software procurando minimizar as alterações no ambiente, porém nenhum destes dois autores desenha uma estratégia e/ou metodologia para potencializar o sucesso da implantação (KINA, 2009).
Ainda sobre implantação de software, Edílson José de Souza, na sua dissertação de mestrado, intitulada “Metodologia de implantação de software corporativo”, propõe uma metodologia de implantação baseada em normas e metodologias pré-existentes (SOUZA, 2009). A metodologia de implantação de software, produto de sua pesquisa, foi utilizada como referência para a estratégia aqui proposta. Conforme explica Souza (2009):
Em engenharia de software e no gerenciamento de projetos, uma metodologia é um conjunto estruturado de práticas, por exemplo, material de treinamento, programas de educação formais, planilhas, e diagramas, que pode ser repetível durante o processo de produção de software (SOUZA, 2009, p.4 apud Regularize, 2009).
É importante mencionar que o trabalho de pesquisa aqui apresentado não almejou a elaboração de uma metodologia de implantação de software, pois acredita-se que a integração que foi feita da metodologia de Souza (2009) ao método PBL poderia ser realizada a partir de qualquer metodologia de implantação de software existente. Por isso, optou-se em utilizar neste trabalho o conceito de estratégia, proposto por MORIN (2006), educador que, ao diferenciar programa de aprendizagem de estratégia de ensino-aprendizagem, explica que:
O programa é a determinação a priori de uma sequência de ações tendo em vista um objetivo. O programa é eficaz, em condições externas estáveis, que possam ser determinadas com segurança. Mas as menores perturbações nessas condições desregulam a execução do programa e o obrigam a parar. A estratégia, como o programa, é estabelecida tendo em vista um objetivo; vai determinar os desenvolvimentos da ação e escolher um deles em função do que ela conhece sobre um ambiente incerto. A estratégia procura incessantemente reunir as informações colhidas e os acasos encontrados durante o percurso (MORIN, 2006, p. 62).
Considerando-se, então, a abertura e flexibilidade que o conceito de estratégia apresenta, ressalta-se que os fatores que levaram à escolha da metodologia de Souza (2009) para este trabalho foram: o modelo do ciclo de vida de software considerado por Souza (2009) se adapta ao utilizado na Assessoria Especial de Informática no desenvolvimento do CUCA; a metodologia foi utilizada pelo Governo de Pernambuco na implantação de um software, sendo que o autor confirma a necessidade de uma metodologia de implantação que estimule a participação dos usuários, buscando minimizar os problemas existentes; Souza (2009) se baseia em práticas já existentes e utilizadas em grandes corporações que seguem padrões de qualidade (e.g. Melhoria de Processos de Software Brasileiro – MPS-BR); por fim, este trabalho foi desenvolvido no Centro de Informática da Universidade Federal de Pernambuco, considerado atualmente um centro de excelência e referência na área de Computação no Brasil.
Dentre os trabalhos que envolvem o PBL, dois se destacam. O primeiro é a tese de doutorado intitulada “A aprendizagem baseada em problemas (PBL): uma implementação na educação em engenharia na voz atores”, de Luiz Roberto de Camargo Barreto Ribeiro (RIBEIRO, 2005), que possui diversos trabalhos na área. Este trabalho objetivou a implementação do PBL no
ensino de engenharia, assim como a avaliação do mesmo por alunos e professores. A tese também aborda conceitos referentes aos fundamentos do PBL, o papel do problema, o processo PBL, entre outros que foram de grande importância para a fundamentação desta pesquisa.
O segundo trabalho que aborda o PBL é um artigo que tem como primeiro autor David Moises Barreto dos Santos, intitulado “Aplicação do método de aprendizagem baseada em problemas no curso de Engenharia de Computação da Universidade Estadual de Feira de Santana”, que também traz os fundamentos do PBL, além da aplicação do método na Universidade Estadual de Feira de Santana, contexto no qual a autora deste trabalho encontra-se inserida. Santos et. al. (2007) apresenta a dinâmica de uma sessão tutorial de forma bastante detalhada em sete etapas.
1.6 ASPECTOS METODOLÓGICOS
A Figura 1 mostra a divisão das etapas de produção deste trabalho, sendo elas: Levantamento Bibliográfico, Elaboração da Estratégia de Implantação e Estudo de caso.
Figura 1 - Procedimentos Metodológicos Fonte: Própria Autora
Engenharia de
Software
• Processos de Software • Implantação de SoftwareProposta
de
Souza (2009)
Método PBL
Levantamento
Bibliográfico
Estudo das etapas da metodologia de Souza(2009) Adaptação do PBL para a Engenharia de Software Adaptação do modelo cascata baseado na metodologia de Souza (2009) E no PBL
Elaboração da
Estratégia
de
Implantação
Aplicação
da
metodologia
elaborada
no
CUCA para o
sistema CASYS
Validação
da
metodologia
baseada
na
experiência dos
usuários
Estudo
de
Caso
A primeira etapa consistiu na pesquisa bibliográfica, ou seja, no estudo dos conceitos necessários à construção do projeto. Este estudo foi iniciado com os conceitos de Engenharia de Software referentes principalmente a processos de software e implantação de software. Tais conceitos eram necessários para o entendimento de como a construção de um software é estruturada e, sobretudo, como a implantação de software era descrita pela Engenharia de Software. Após estes conceitos iniciais, as pesquisas se voltaram para a metodologia proposta por Souza (2009). Nesta sub etapa, foi analisada a estrutura da metodologia proposta pelo autor, assim como as alterações realizadas pelo mesmo no ciclo de vida clássico de software. Por fim, foram estudados os fundamentos da Aprendizagem Baseada em Problemas a fim de adaptá-los para o uso na implantação de softwares. Os resultados obtidos a partir da execução desta etapa serão apresentados no Capítulo 2.
Na segunda etapa, foi considerada a inserção da fase de implementação do modelo cascata, tal como Souza (2009) a inseriu no ciclo de vida clássico de software. Esta alteração foi feita e o foco foi direcionado ao que estava envolvido neste processo. As fases da estratégia de implantação foram inspiradas no modelo de Souza (2009) com alterações feitas pela própria autora baseado na experiência da mesma no estágio na Assessoria Especial de Informática e na observação do ambiente de trabalho do CUCA. Houve também, a necessidade de adaptação do método PBL para que o mesmo se tornasse parte da metodologia proposta. Os resultados obtidos a partir da execução desta etapa serão apresentados no Capítulo 3.
O estudo de caso se iniciou juntamente com a finalização da fase de implementação do CASYS e a sua entrega ao CUCA. Neste período estive aplicando a estratégia proposta e observando a experiência dos usuários. Neste primeiro momento, somente a observação poderia ser realizada no estudo de caso, pois antes de desempenhar pesquisas que envolvem diretamente seres humanos, estas precisam ser aprovadas pelo Comitê de Ética em Pesquisa (CEP). Com a finalidade de aplicar no CUCA o problema desenvolvido e colher dados através um de questionário para validar o método proposto, o projeto foi encaminhado ao CEP. Após a aprovação do projeto pelo
CEP, o problema foi aplicado no CUCA. Logo após a aplicação do problema, foi requisitado aos usuários que eles respondessem o questionário de validação da estratégia. Em seguida, houve a análise dos dados obtidos no questionário e na observação do ambiente de implantação. Os resultados obtidos a partir da execução desta etapa serão apresentados no Capítulo 5.
1.7 ESTRUTURA DA MONOGRAFIA
Este trabalho está articulado em seis capítulos:
No Capítulo 2 serão tratados temas e conceitos que o fundamentaram, passando por WebApps, Processos de Software, Implantação de Software, Problem-Based Learning, entre outros.
O Capítulo 3 apresenta detalhadamente a estratégia de implantação de software proposta, suas etapas, e os objetivos e atividades previstas em cada uma delas.
O Capítulo 4 aborda a metodologia da pesquisa, detalhando: os métodos e técnicas de pesquisas que foram utilizados, o ambiente onde foi realizado o estudo, as pessoas que participaram, o problema que foi aplicado, alguns aspectos éticos envolvidos e os procedimentos metodológicos utilizados.
No Capítulo 5, o estudo de caso foi apresentado, relatando-se a utilização da estratégia proposta na implantação do CASYS no CUCA e tecendo-se a análise dos resultados obtidos durante o processo de validação.
Por fim, no Capítulo 6, as considerações finais são apresentadas.
Alguns trechos deste trabalho estão escritos em primeira pessoa. Esta abordagem foi escolhida devida à minha participação ativa no em todo o processo da pesquisa.
2. REVISÃO BIBLIOGRÁFICA
Esta seção objetiva apresentar a definição de temas e conceitos que foram fundamentais para a elaboração desta pesquisa. Inicialmente será definida a automação de processos administrativos, enfatizando a importância dos aplicativos Web. Logo após será explicada e exemplificada a subárea da Engenharia de Software de processo de software. Ainda inserido no contexto de Engenharia de Software e processos de software, abordam-se os testes de software em WebApps e a implantação de software. No que diz respeito à implantação de software, além da definição desta fase, será abordada a inserção desta fase no modelo cascata e algumas metodologias de implantação de software disponíveis. Por fim, serão apresentados os conceitos relacionados ao método de Aprendizagem Baseada em Problemas.
2.1 AUTOMAÇÃO DE PROCESSOS ADMINISTRATIVOS
Segundo Turban, Rainer e Potter (2005), as primeiras aplicações de computadores em meios administrativos se iniciaram na década 1950, e se limitavam a guardar informações sobre transações, finanças e recursos humanos. É importante ressaltar que, nesta época, os computadores eram muito caros e com baixo desempenho, o que limitava as aplicações que estes conseguiam executar satisfatoriamente. Com o avanço da microeletrônica e, consequentemente, a redução dos custos e aumento do desempenho dos computadores, aplicações mais variadas foram sendo desenvolvidas, tais como sistemas de informações gerenciais e sistemas de automação de escritórios, como são chamados por Turban, Rainer e Potter (2005).
O incremento ou troca da mão de obra humana se tornou cada vez mais disseminado, e o surgimento da internet contribuiu ainda mais com este processo, antes apoiado em ferramentas off-line. A internet, segundo Turban, McLean e Wetherbe (2002), possibilita a descoberta de informações, proporciona comunicação ágil e de baixo custo (trocas de e-mails, chats, etc.), facilitando o intercâmbio de informações internas e a colaboração entre
indivíduos. Neste ponto, vê-se que a internet propicia um ambiente de troca rápida de informações em um ambiente colaborativo, que é exatamente as necessidades atuais das organizações.
2.2 WEBAPPS
World Wide Web, ou simplesmente Web, é um sistema aceito universalmente, que se utiliza da Internet para transportar informações através de uma arquitetura cliente-servidor (TURBAN, RAINER E POTTER, 2005). O HTML é a base para a construção de páginas na Web, esta linguagem pode ser interpretada por navegadores. Segundo Pressman (2011), nos primórdios da World Wide Web, os sites apenas apresentavam informações usando texto e gráficos.
Ainda citando Pressman (2011), o crescimento da HTML tornou possível o oferecimento de capacidade computacional unido às informações, originando-se assim, os WebApps. Estas aplicações são hospedadas em um servidor e o seu acesso se dá através de navegadores Web em qualquer local do mundo através da internet, desde que estejam de acordo com os protocolos desta rede (TURBAN, RAINER e POTTER, 2005). Pressman (2011) diz que os WebApps se tornaram ambientes que oferecem recursos especializados, funções computacionais e conteúdo, além da sua capacidade de integração com bancos de dados, oferecendo grande utilidade para aplicações administrativas.
Os WebApps se tornaram uma categoria de software, apesar de ser distinta das demais. Powell (1998 apud PRESSMAN 2011, p. 37) afirma que aplicações baseadas na Web “envolvem uma mistura de publicação impressa e desenvolvimento de software, de marketing e computação, de comunicações internas e relações externas e de arte e tecnologia”.
Estas aplicações possuem os seguintes atributos (PRESMAN, 2011, p. 37):
Uso intensivo de redes: o software deve residir em uma rede que atenda às necessidades de uma comunidade de clientes;
Simultaneidade: um grande número de usuários pode utilizar simultaneamente o sistema;
Carga não previsível: o número de acessos é bastante variável, hora pode-se não ter acessos e pouco depois, acesso máximo; Desempenho: deve-se ter o cuidado de não deixar o usuário
esperando muito por dados;
Disponibilidade: o sistema deve estar disponível todo o tempo; Orientadas a dados: os WebApps são comumente utilizados para
acessar informações em banco de dados, além de apresentar relatórios, textos, gráficos, vídeos, etc.;
Este trabalho está delimitado no que abrange os conceitos de WebApps, já que o CASYS se encontra nesta categoria.
2.3 PROCESSO DE SOFTWARE
Um processo de software, conforme é definido por Sommerville (2011, p.18), “é um conjunto de atividades relacionadas que levam à produção de um produto de software”. Estas atividades, segundo Pfleeger (2004), podem ser chamadas de ciclo de vida do software, pois descrevem a concepção do software, sua implementação, entrega, utilização e manutenção. As tarefas envolvidas no processo de software dependem das decisões da equipe de desenvolvimento e do tamanho do sistema. Em sistemas pequenos, a quantidade de tarefas provavelmente será menor que para sistemas muito grandes (PRESSMAN, 2011). Como afirma Sommerville (2011), o modelo de software deve incluir, de forma geral, as fases: especificação de software, projeto e implementação de software, validação do software e evolução do software.
Na especificação de software, o propósito do sistema e suas restrições são determinados. Na fase de projeto, o software é produzido de acordo com a especificação do software. A validação tem o propósito de verificar, junto ao cliente, se o sistema desenvolvido cumpre com o propósito e as restrições elucidadas na fase de especificação. No processo de evolução, o sistema se adapta às necessidades de mudança requisitadas pelo cliente.
Existem alguns modelos de processo de software tradicionais, chamados de modelos de processo prescritivo. Estes modelos servem como um guia para as equipes na estruturação do trabalho (PRESSMAN, 2011). Possivelmente, os modelos de processo de software prescritivos mais estudados são o modelo em cascata, o desenvolvimento incremental e a engenharia de software orientada a reuso.
O modelo cascata possui atividades sequenciais bem definidas. O cliente não tem contato com o sistema até ele passar pela etapa de implantação e de testes. Este método é bastante arriscado por esta característica das fases fixas, caso o software tenha sido completamente implementado e o cliente verificar que ele não atende às suas necessidades, haverá uma grande quantidade de tempo perdido retomando atividades anteriores (SOMMERVILLE, 2011). Baseado no processo descrito pelo autor, a Figura 2 demonstra o ciclo de atividades do modelo cascata.
Figura 2–Esquema do Modelo Cascata Fonte: Própria Autora – Adaptado de Sommerville (2011)
Na fase de definição dos requisitos, os objetivos e funcionalidades do software são determinados juntamente com o cliente. Na segunda fase, a
arquitetura do sistema é estabelecida. Na etapa de implementação e teste de unidade, os módulos do programa são implementados e testados separadamente. Na integração e teste de sistema, os módulos são integrados e testados como um todo, após esta etapa o software é entregue aos usuários. Na última etapa, o sistema é instalado no seu ambiente de produção e inicia-se a manutenção, que consiste na correção de erros e implementação de possíveis novos requisitos (SOMMERVILLE, 2011).
O desenvolvimento incremental, descrito na Figura 3, objetiva a produção de diversas versões até que o sistema desenvolvido seja adequado às necessidades do cliente. Este método, apesar de diminuir as chances da elaboração de um produto não usável, causa também diversos problemas. Um deles é a dificuldade de documentar cada versão do produto, elas podem ser muitas, e neste processo perde-se tempo fundamental para a interação cliente/desenvolvedor (SOMMERVILLE, 2011).
Figura 3– Esquema do Modelo Incremental Fonte: Própria Autora – Adaptado de Sommerville (2011)
O modelo de engenharia de software orientado a reuso se baseia na existência de vários componentes reutilizáveis e o desenvolvimento do sistema se concentra na integração desses componentes. Neste ponto, pode-se perceber a vantagem da redução de código produzido, porém pode-se ter um requisito que não seja coberto pelos componentes. Neste caso, um componente reusável deverá ser produzido, isso pode acarretar no aumento do
prazo de entrega (SOMMERVILLE, 2011). O esquema do modelo de engenharia de software orientado a reuso está descrito na Figura 4.
Figura 4 - Esquema do Modelo Orientado a Reuso Fonte: Própria Autora – Adaptado de Sommerville (2011)
Como descrito, pode-se perceber que nenhum modelo de processo de software prescritivo é completo, cabendo à equipe de desenvolvedores escolher o que mais se adéqua ao seu projeto. Também é válido explicitar que esses modelos não são mutuamente excludentes, e geralmente são utilizados em conjunto na produção de grandes softwares, captando o que há de melhor em cada método.
2.4 TESTES DE SOFTWARE EM WEBAPPS
Para garantir a qualidade de um software muitos testes são realizados antes da entrega do sistema ao cliente. No contexto de WebApps, os testes devem ser realizados para assegurar a ausência de erros no conteúdo, na função, na usabilidade, na navegabilidade, no desempenho, na capacidade e na segurança destes sistemas (PRESSMAN, 2011).
Os erros nos WebApps possuem características especiais, que diferem um pouco dos erros encontrados em softwares off-line (PRESSMAN, 2011).
Um WebApp pode ser desenvolvido em diferentes ambientes e configurações, logo há a dificuldade de reproduzir o erro fora do ambiente no qual ele foi encontrado;
Os WebApps estão contidos numa arquitetura cliente-servidor, logo pode ser difícil identificar a origem de um erro: ele pode estar inserido no cliente, no servidor ou na própria rede;
Alguns erros são advindos das configurações do WebApp;
Através destas características, pode-se perceber que o ambiente está intimamente ligado à detecção dos erros.
Dentre os testes para WebApps que foram realizados no desenvolvimento do CASYS estão o teste de conteúdo, teste na base de dados, teste de interface, teste de compatibilidade e teste de aceitação. Conforme explica Pressman (2011):
Teste de conteúdo objetiva a descoberta de erros de sintaxe (ortografia, gramaticais, etc.), erros de semântica (integralidade ou exatidão das informações) e erros na organização ou estrutura do conteúdo apresentado.
Testes na base de dados devem garantir que sejam passadas informações válidas entre cliente e servidor; que os scripts sejam processados corretamente, recuperando informações válidas; que dados do usuário sejam passados corretamente para o servidor; que as consultas realmente acessem o banco de dados.
Testes de interface são aplicados com a finalidade de validar aspectos estéticos da interface do usuário, objetivando a usabilidade do sistema, tornando-o simples de usar e aumentando a sua acessibilidade a usuários portadores de necessidades especiais.
Para Pressman (2011, p. 478), “diferentes computadores, dispositivos de imagens, sistemas operacionais, navegadores e velocidades de conexão de redes podem ter influência significativa na operação da WebApp. Com esta afirmação, é possível verificar a importância de se fazer testes em diversos ambientes a fim de avaliar o comportamento do sistema em cada um destes.
O foco deste trabalho envolve o teste de aceitação, por isso resolveu-se destacá-lo, apresentando-o em uma seção específica.
2.4.1 Teste de aceitação
Embora não seja especificamente um teste de WebApp, o teste de aceitação possui uma grande importância para o sucesso de um software. Pfleeger (2004) afirma que o teste de aceitação é realizado em conjunto com os clientes, e nele se compara o sistema com a descrição dos requisitos do cliente.
Segundo Sommerville (2011), o teste de aceitação possui seis estágios, sendo eles: definir critérios de aceitação; planejar testes de aceitação; derivar testes de aceitação; executar testes de aceitação; negociar resultados do teste e; rejeitar ou aceitar o sistema.
O estágio de definição de critérios de aceitação deve ocorrer antes do produto ser implementado, e é um acordo entre desenvolvedores e clientes dos aspectos necessários para que o software seja aceito. O planejamento de testes de aceitação decide sobre recursos, tempo e orçamento para os testes de aceitação, definindo um cronograma de teste. Também nesta etapa, são discutidas a cobertura dos requisitos e a ordem de teste. No estágio de derivação de testes de aceitação, os testes são projetados para a verificação da aceitação do sistema. A execução dos testes de aceitação idealmente é realizada no ambiente real em que o sistema irá operar. Esta etapa envolve interações entre o sistema e o usuário real, sendo possível a necessidade de treinamento destes usuários. Na negociação de resultados do teste, caso aconteça de todos os testes serem aprovados, cliente e desenvolvedor devem negociar se o sistema está pronto para o uso. A solução dos problemas encontrados deve ser acordada entre cliente e desenvolvedor. Por fim, a rejeição ou aceitação de um sistema envolve a reunião entre desenvolvedores e clientes a fim de decidir se o sistema deve ser aceito. Caso não seja aceito, o sistema deverá ser corrigido nos erros encontrados e os testes de aceitação são repetidos.
Neste ponto é perceptível a relação entre testes de aceitação e implantação de software, que será explicada na próxima seção.
2.5 IMPLANTAÇÃO DE SOFTWARE
Segundo Navarro (2009 apud KINA, 2009), a implantação pode ser definida de duas maneiras: substituição ou instalação. Ainda segundo Kina (2009), esta implantação deve ser realizada cuidadosamente, pois alteram a rotina do meio, sendo possível encontrar resistência dos funcionários e outras dificuldades. Este fator é agravado quando o meio onde ocorre a inserção está adaptado ao trabalho manual. Por isso, se faz necessária uma etapa de implantação, que visa garantir que o sistema seja utilizado de forma adequada.
Martins (2010) diz que a implantação de um software abrange: testes do sistema no ambiente de produção; empacotamento do software para distribuição; distribuição do software; instalação do software; treinamento dos usuários e migração de dados para o novo sistema. Nesta afirmação é possível perceber que a implantação não é a simples distribuição do programa, esta etapa requer grande comunicação entre os desenvolvedores e os usuários finais.
A implantação de um sistema está dividida em etapas (MARTINS, 2007 apud KINA, 2009):
Planejamento: definição dos objetos que serão entregues, além da informação de prazos e comprometimento dos usuários com o processo de implantação;
Desenvolvimento do material de suporte: inclui os artefatos que auxiliam os usuários no uso do sistema;
Testar o sistema em um ambiente de desenvolvimento: o sistema é testado com a supervisão do usuário, que irá corrigir ou aprovar o sistema;
Criação de versão: etapa em que é criada uma versão do software, incluindo os pacotes necessários para a implantação; Versão beta: a versão beta é criada e há a verificação se
realmente o software atende aos requisitos e se haverá problemas com relação à adaptação dos usuários;
Teste no ambiente de produção: o sistema é testado no ambiente no qual irá operar, inclui-se testes de aceitação;
Distribuição do produto: há a distribuição do software para os usuários finais.
2.6 PROPOSTA DE INCLUSÃO DA FASE DE IMPLANTAÇÃO NO MODELO CASCATA E A METODOLOGIA DE IMPLANTAÇÃO DE SOFTWARE DE SOUZA (2009)
O objetivo deste trabalho é a adaptação do modelo de processo de software cascata de forma a incluir a fase de implantação no seu ciclo. O modelo cascata é caracterizado na Figura 5.
Figura 5 - Modelo Cascata
Fonte: Própria Autora – Adaptado de Sommerville (2011)
Como já dito, neste modelo não há explicitamente uma etapa que permita a preparação do ambiente e usuários para a chegada do novo software.
Este trabalho tem por base a dissertação de mestrado de Souza (2009), onde este autor defende a inserção da fase de implantação no modelo clássico
do ciclo de vida do software. Segundo o Souza (2009), esta implantação seria bem delimitada e ocorreria antes da utilização do sistema por parte do usuário. A Figura 6 apresenta o ciclo de vida de software convencional, já a Figura 7 mostra o ciclo de vida de software com a fase de implantação inserida. Este segundo modelo incorpora características do ciclo clássico e inclui a contribuição do referido autor.
Figura 6 - Ciclo de vida de software clássico Fonte: (SOUZA, 2009)
Figura 7 - Ciclo de vida de software proposto por Souza (2009) Fonte: (SOUZA, 2009)
Souza (2009) ainda propõe uma metodologia de implantação onde existiriam 6 fases: Planejamento da Implantação; Preparação do Ambiente; Realização do Treinamento; Implantar em um Departamento; Planejar a Sequência de Implantação; Conclusão e Aceite. O esquema deste método está descrito na Figura 8. É importante ressaltar que não é objetivo deste trabalho o detalhamento destas fases. Caso seja do interesse do leitor o aprofundamento na metodologia proposta por Souza (2009), é sugerida a leitura da sua dissertação de mestrado que é devidamente referenciada na seção Referências.
Neste esquema, a maior parte do contato do usuário com o software se encontra na fase de treinamento, ainda assim, não há o foco de que o usuário seja parte ativa do processo da construção do conhecimento. Este trabalho de pesquisa almejou a inserção do usuário como parte ativa da fase de implantação, a estratégia utilizada será a adaptação do PBL para o seu uso como estratégia na Engenharia de Software. Este método será abordado na próxima seção.
Figura 8 - Esquema da Metodologia de Implantação de Software Corporativo Proposta por Souza (2009).
Fonte: (SOUZA, 2009)
2.7 PROBLEM-BASED LEARNING (PBL)
O PBL possui raízes na teoria do conhecimento de um filósofo chamado John Dewey onde “a aprendizagem parte de problemas ou situações que intencionam gerar dúvidas, desequilíbrios ou perturbações intelectuais” (CYRINO e PEREIRA, 2004). Pode-se então afirmar que a Aprendizagem Baseada em Problemas promove o desafio ao treinando, incitando a dúvida e a pesquisa com a finalidade de saná-la, e neste processo há a construção do conhecimento.
É importante ressaltar que, diferentemente da metodologia tradicional, onde o conhecimento é passado do professor (sujeito ativo) para o estudante (sujeito passivo), o PBL torna o estudante uma parte ativa do processo de aprendizagem. Batista e Batista (2006) afirmam que os principais aspectos do PBL são: aprendizagem significativa, indissociabilidade entre teoria e prática, respeito à autonomia do estudante, o trabalho em pequeno grupo, educação permanente e avaliação formativa. Os autores ainda estendem esses aspectos como:
Aprendizagem significativa: O aprendiz é capaz de relacionar o conteúdo aprendido aos seus conhecimentos prévios
(continuidade), porém também devem ser lançados novos desafios, que o levam a ultrapassar e ampliar o conhecimento (ruptura).
Indissociabilidade entre teoria e prática: Integração entre teoria e prática, uma vez que os problemas são elaborados a partir de situações cotidianas.
Respeito à autonomia do estudante: A responsabilidade pelo aprendizado é direcionada ao aprendiz, que em seus afazeres futuros deverá julgar as importâncias de seus saberes para realizar tarefas.
Trabalho em pequeno grupo: O PBL promove a interação entre o grupo, dando a oportunidade de aprender a ouvir, receber e assimilar críticas e promovendo a análise crítica das ideias dos demais participantes do grupo.
Educação permanente: O maior foco é dado capacidade de resolver problemas e não no aprendizado de muitos conteúdos que poderão se tornar obsoletos em poucos anos após o término dos estudos.
Avaliação formativa: A avaliação cobre todos os aspectos do processo educacional, incluindo docentes, estudantes, o próprio método, resultados, etc. Este processo permite controlar o processo de formação do estudante, garantindo que sejam adquiridas as competências necessárias para a sua formação. Ribeiro (2005) indica que o processo PBL passa por diferentes etapas. Inicialmente um problema é apresentado aos aprendizes. Os mesmos tentam solucionar o problema baseado em experiências anteriores. Após este primeiro momento de levantamento de conhecimento prévio, há a listagem de questões, e os estudantes podem dividir estas questões entre si. Após o momento de questões, no próximo encontro as questões devem ser levadas resolvidas e a solução compartilhada com o grupo, agregando novos conhecimentos e relacionando-os com anteriores. Este processo de levantamento de dúvidas e pesquisa sobre as mesmas dura até o momento em que o problema é resolvido
efetivamente. Após a resolução do problema, há a avaliação. Neste momento diversas vezes a auto avaliação e avaliação dos demais colegas é estimulada.
A Figura 9 apresenta como ocorre a dinâmica PBL, que foi adaptada do trabalho de Santos et. al. (2007), caracterizando o método em 7 fases. No ponto de partida, o problema é apresentado para os estudantes. Neste ponto, estudantes com conhecimento prévio podem esclarecer termos e conceitos não conhecidos pelos outros. No segundo momento, o brainstorming, chuva de ideias, os alunos devem, de forma livre, formular hipóteses. No brainstorming é importante que nenhuma ideia seja descartada, já que esta ação pode inibir alunos mais tímidos ou fazer a equipe perder valiosas informações. Na fase de sistematização, as ideias, hipóteses e fatos são eleitos. Na formulação de questões, após o levantamento de ideias, questões são elaboradas de forma que estas guiem os estudantes à resolução do problema. Na fase a seguir, são estabelecidas as metas de aprendizagem, também é desenvolvido um plano que permita o cumprimento dessas metas. Na sexta fase, avaliação do processo, o aproveitamento do ciclo é avaliado, sendo levantados aspectos que possam estar interferindo no andamento da resolução do problema, seja algo causado pela equipe de estudantes, ou pelo próprio tutor. No seguimento, após as metas elaboradas na fase 5 serem cumpridas, o problema é revisto, reavaliando ideias anteriores e desfazendo possíveis erros cometidos. Todo o processo é repetido desde a segunda fase, ocasionando na resolução do problema.
Figura 9 - O Ciclo PBL
3. UMA ESTRATÉGIA PARA POTENCIALIZAÇÃO DA FORMAÇÃO DOS USUÁRIOS E DA ACEITAÇÃO DO SOFTWARE
Nesta sessão será apresentada a estratégia desenhada a partir da metodologia de implantação de software corporativo proposta por Souza (2009) e da dinâmica do método PBL, a fim de tornar o usuário parte ativa deste processo, maximizando assim as chances de aceitação e uso do software.
3.1 ESTRATÉGIA PROPOSTA
Vale ressaltar que a estratégia aqui elaborada e apresentada foi idealizada para implantações em campos de médio ou pequeno porte, portanto, não haverá separação de implantação por departamentos. Caso haja a necessidade de adaptação para ambientes maiores, o método deverá ser aplicado fracionadamente, de forma que não se perca a característica do PBL referente ao trabalho em pequenos grupos, além de não comprometer a qualidade do processo de implantação.
O PBL, apesar de mais expressivo no momento em que os usuários participam do treinamento, é utilizado em grande parte da estratégia. Esta utilização parte do objetivo de potencializar o desenvolvimento da autonomia do usuário em relação ao software implantado.
Aproveitando as etapas pré-existentes no modelo cascata, a nossa proposta é inserir a fase de implantação logo após a integração e testes de sistema. A alteração foi realizada no período antes da operação e manutenção, uma vez que a fase de operação e manutenção depende diretamente de uma implantação eficaz. A Figura 10 demonstra o esquema do modelo cascata já alterado, inserindo esta fase.
Figura 10 - Modelo Cascata Adaptado Fonte: Própria Autora
Aprofundando-se na fase de implantação, a estratégia elaborada, a partir da adaptação da metodologia proposta por Souza (2009) e a inclusão do método PBL, está articulada em 7 fases.
1. Identificação dos Usuários Finais 2. Definição de Conceitos Chave 3. Preparação do Ambiente
4. Primeiro Contato do Usuário com o Sistema 5. Aplicação de Problemas
6. Validação do Aprendizado 7. Conclusão
O esquema da estratégia de implantação, respeitando a ordem de suas fases e ciclos, está descrito na Figura 11. Pode-se perceber que a sequência de suas etapas não é linear. A aplicação do(s) problema(s) requer a validação de que o usuário alcançou os objetivos propostos. Portanto, a Aplicação do(s) Problema(s) e a Validação do Aprendizado se configuram em um ciclo no
processo, sendo o sucesso do aprendizado a condição da saída desse ciclo para a fase de implantação.
Figura 11 - Esquema da Estratégia de Implantação de Software Proposta Fonte: Própria Autora
As próximas subseções abordarão as fases supracitadas, detalhando-as em: objetivos e atividades programadas.
3.1.1 Identificação dos Usuários Finais
3.1.1.1 Objetivos
O objetivo principal deste processo é a identificação dos usuários finais do sistema a fim de comunicar a eles de maneira eficaz a respeito da mudança e motivá-los a participar da implantação. A ideia principal é que não ocorra a separação de usuários chave e que haja a participação de todos os que irão utilizar o software. Esta prática objetiva que o conhecimento a respeito do
sistema não seja concentrado em poucas pessoas e que todos os usuários compartilhem seus conhecimentos a respeito do software.
Também é de grande importância a identificação de usuários que possam auxiliar no engajamento dos demais membros da equipe. Estes usuários, por fazerem parte da equipe de usuários facilitam a troca de informações acerca das necessidades e impressões com a equipe de desenvolvimento.
O esperado com esta fase é que a equipe do local onde o software será implantado tenha o conhecimento da mudança que será efetuada na sua forma de trabalho resultando em uma equipe engajada e colaboradora com a implantação do sistema. Além disso, que a identificação de usuários auxiliadores facilite a comunicação usuário-implantador.
3.1.1.2 Atividades Programadas
As atividades programadas para esta fase são:
Reunião com a equipe de usuários: Neste ponto, é iniciada a mobilização dos usuários. O sistema é exposto aos presentes e há uma breve explicação de suas funcionalidades e no que elas afetarão positivamente na sua rotina atual. É interessante que se ressalte a importância do projeto para a organização. Caso haja a separação de atividades por setores, esta reunião será útil para identificar os perfis existentes e planejar a implantação baseada nessas divisões.
Identificação de usuários auxiliadores: Identificar dentre os usuários um pequeno grupo (o número dependerá do tamanho do grupo) que serão como um canal de comunicação entre a equipe de desenvolvimento e os usuários.
Explicação de como a implantação será realizada: É importante que os usuários tenham consciência do método que será utilizado. Neste momento deve ser explicado o método PBL, suas características e objetivos, salientando que o usuário aprenderá de forma prática e que em nenhum momento ele será desamparado pela equipe de implantação. É necessário o cuidado para não desviar o foco da implantação do sistema para o PBL,
aprofundando-se em todos os elementos deste método. O implantador deve se atentar para não acabar aplicando um treinamento sobre o método e sobrecarregar o usuário, tornando a estratégia uma fonte de resistência à aceitação do software.
3.1.2 Levantamento do Perfil do Grupo
3.1.2.1 Objetivos
Esta fase objetiva a observação dos aspectos que devem ser trabalhados na equipe de usuários. Um exemplo é um grupo que não possua tanta familiaridade com informática, este seria um conceito chave que guiaria o processo de implantação. A atenção dada para estas particularidades de cada grupo é necessária, já que os problemas do PBL são adaptados para cada realidade. Focando nas necessidades e/ou habilidades dos usuários, procura-se guiar o processo de forma a preencher lacunas existentes e fundamentar melhor o conhecimento.
O resultado esperado para esta fase é uma equipe implantadora consciente nas características dos usuários e focada em atender suas necessidades e desenvolver suas habilidades.
3.1.2.2 Atividades Programadas
A atividade programada para esta etapa é o levantamento do perfil do grupo, assim como o registro destas. Este levantamento é realizado aliando entrevistas, onde o usuário informa as características locais, à própria observação do ambiente.
3.1.3 Preparação do Ambiente
3.1.3.1 Objetivos
O objetivo dessa fase é garantir a infraestrutura necessária ao bom funcionamento do software. Também é objetivo a preparação do software com dados iniciais. Esta fase é necessária para a detecção de problemas técnicos que possam ocorrer durante a aplicação do(s) problema(s) PBL ou na própria utilização do sistema, ocasionando numa possível diminuição das chances de aceitação do software.
O resultado esperado nesta etapa é um ambiente de trabalho com as condições necessárias e um software com dados pré-existentes carregados.
3.1.3.2 Atividades Programadas
Visita ao ambiente de implantação: A finalidade desta atividade é avaliar o estado atual da estrutura local do ambiente de implantação como computadores e rede, caso necessário. Caso seja verificada alguma incompatibilidade nos equipamentos, esta informação deve ser discutida para que se tomem medidas necessárias para a sua resolução.
Inserção inicial de dados: Este processo inclui o cadastro de dados necessários para o funcionamento do sistema. Caso o ambiente de implantação esteja passando por um processo de informatização no momento, os dados virão dos registros pré-existentes. Caso contrário, virão de sistemas legados. Deve-se levar em consideração previamente se o formato desses dados antigos corresponde ao formato atual (colunas de tabelas, tipo de dados). Neste momento devem ser criados, caso necessário, os perfis de usuários do sistema.
3.1.4 Primeiro Contato do Usuário com o Sistema
3.1.4.1 Objetivos
Esta etapa objetiva o contato inicial do usuário com o software. Neste ponto, o usuário será convidado a interagir com o sistema, informando as suas primeiras impressões. Esta etapa não é um treinamento, o pretendido é que o usuário aponte informações iniciais, aspectos positivos e negativos observados. Obtendo essas informações iniciais, a equipe de implantação poderá realizar alterações de pequeno porte antes da aplicação dos problemas. O resultado esperado para esta etapa são informações que resultem em mudanças em curto prazo, uma vez que o modelo cascata não apresenta o contato frequente entre a equipe de desenvolvimento e os clientes. Além disso, a introdução do usuário ao sistema onde ele possa expor sua opinião estimula a participação deste, fazendo-o parte ativa no processo de implantação.
3.1.4.2 Atividades Programadas
Reunião com usuários: Implantadores e usuários devem se reunir em um ambiente que contenha o equipamento necessário para o funcionamento do sistema (espera-se que este ambiente seja o preparado na fase anterior, utilizando uma base de treinamento para não afetar dados reais). Os usuários devem ser convidados a interagir com o sistema, informando aspectos positivos e negativos observados neste breve período.
Recolher o feedback dos usuários: Durante a reunião o as primeiras impressões dos usuários devem ser registradas, levando essas informações ao grupo de desenvolvedores a fim de que possíveis alterações sejam discutidas.
3.1.5 Aplicação do(s) Problema(s)
3.1.5.1 Objetivos
A aplicação dos problemas objetiva a capacitação dos usuários de forma que estes sejam sujeitos ativos no processo de aprendizagem. Os conceitos chave observados na segunda fase deverão ser aplicados na elaboração dos problemas, a fim de aumentar suas chances de sucesso. Um exemplo são usuários que possuam baixa disponibilidade de tempo. Neste caso os problemas devem ser aplicados de forma que sejam resolvidos rapidamente, ou agendar encontros de curta duração.
O esperado é que essa fase resulte em usuários capacitados para a utilização do sistema em suas atividades cotidianas. Também é esperado que a equipe de usuários esteja consciente da importância do software e dos benefícios proporcionados por ele.
3.1.5.2 Atividades Programadas
Elaboração do(s) problema(s): Nesta atividade o(s) problema(s) deve(m) ser elaborado(s) baseado(s) nos perfil do grupo de usuários e nas atividades de cada perfil de usuário. Não devem ser problemas longos, que demandem muito tempo para serem solucionados, afinal é necessário levar em consideração a natureza dinâmica das organizações e não desestimular o usuário no processo de aprendizagem. Ainda para a elaboração dos problemas, BRIDGES e HALLINGER (1998 apud RIBEIRO, 2005) estipulam critérios para a concepção de problemas. Estes critérios são: prevalência, valor integrativo, valor prototípico, alto potencial de impacto e fraca estruturação. Segundo o autor citado
O problema deve ser facilmente encontrado na prática profissional, abranger conceitos de várias disciplinas, oferecer (se for incomum) um bom modelo para estudo, afetar uma grande quantidade de pessoas e apresentar um emaranhado de questões e sub-questões, [...] que promova a aprendizagem de uma ideia geral. (RIBEIRO, 2009, p. 44).
Ribeiro (2005) segue afirmando que possivelmente o fator que mais afeta o processo PBL é a estruturação, sendo que os problemas devem se espelhar o máximo possível em situações profissionais reais. Isto é, devem ser indefinidos, não possuírem informações completas, serem abertos a diversas soluções. O estudante não deve ter conhecimento de como se chegar na solução.
Liberação do(s) manual(s) do sistema: A documentação do usuário deve ser disponibilizada, servindo como consulta tanto no momento da aplicação do(s) problema(s) como posteriormente.
Aplicação do(s) problema(s): Nesta etapa, o usuário já deve ter conhecimento do funcionamento do PBL. Durante aplicação do(s) problema(s), o usuário deve estar ciente dos objetivos do(s) mesmo(s), trabalhando assim para atingi-los. A equipe de implantação deve estar preparada para a aplicação do(s) problema(s), conhecendo o papel do tutor (assumido pelo(s) analistas(s)) e os resultados esperados com a aplicação de um problema.
Acompanhamento da evolução da solução do(s) problema(s): Após a entrega do problema aos usuários é necessário o acompanhamento do andamento da sua resolução. Esta tarefa compreende a verificação e solução de possíveis dificuldades dos usuários nas tarefas necessárias à elaboração do produto. Neste momento, a dinâmica apresentada por Santos et. al. (2007) deve ser utilizada para promover e guiar a discussão do problema.
3.1.6 Validação do Aprendizado
3.1.6.1 Objetivos
Esta fase objetiva a conclusão do ciclo de aplicação de problemas e verificação do sucesso desta etapa. É esperado que esta fase resulte na confirmação de que os usuários estão capacitados e motivados para o uso do software.
