PX: Um Processo de Desenvolvimento de Software Adaptado para Projetos de Pequeno Porte

Transcrição

1 PX: Um Processo de Desenvolvimento de Software Adaptado para Projetos de Pequeno Porte Renata Burmeister Bäuerle Faculdade de Informática Centro Universitário Ritter dos Reis (UniRitter) Porto Alegre RS Brasil Abstract. This article describes the steps taken to elaborate a proposal of a software development process for a specific environment - RMES. During the preparation of this study, RUP, a development process defined by the Rational Company, was analyzed in detail. Based on this study, PX, a development process, was proposed for an environment in which small projects are developed simultaneously and for which the team is also small. The application of this proposal yielded results that were different from the outcomes expected, it was perceived that a development process has to be flexible so that it may be adapted to the project to which it will be applied. Resumo. Este artigo descreve os passos utilizados para a elaboração de um processo de desenvolvimento de software para um ambiente específico a RMES. Durante a execução deste trabalho, foi realizado um estudo detalhado do RUP, processo de desenvolvimento definido pela empresa Rational. Com base neste estudo foi proposto um processo de desenvolvimento para um ambiente focalizado em projetos pequenos e desenvolvidos em paralelo e que também conta com uma equipe também pequena, o PX. A aplicação desta proposta apresentou resultados diferentes dos esperados, pois percebeu-se que um processo de desenvolvimento precisa ser flexível para ser adaptado ao projeto ao qual será aplicado. 1. Introdução Para se desenvolver software com qualidade é necessária a utilização de um processo de desenvolvimento formalizado e organizado. Em paralelo a isso, é necessário que os projetos e seus artefatos sejam devidamente documentados. No ambiente de trabalho da Rede Metodista de Educação do Sul (RMES) desenvolvem-se projetos de software pequenos. Ou seja, projetos que levam até quatro meses para serem desenvolvidos. Neste ambiente, inicialmente, havia um ambiente onde existia uma equipe bem reduzida e poucos projetos pequenos a serem desenvolvidos. Com o crescimento da Instituição, as solicitações de projetos de software tornaram-se mais frequentes, porém a equipe continuou a mesma, ou seja, reduzida.

2 Com uma situação nova no ambiente de desenvolvimento, esforços começaram a ser despendidos para que o processo utilizado fosse formalizado e melhorado. Com o auxílio de uma consultoria, chegou-se a conclusão de que para se desenvolver software com qualidade, era preciso utilizar um processo de desenvolvimento sistematizado. Além disso, verificou-se que os projetos também necessitavam de documentação, tanto em relação aos projetos, de uma forma geral, quanto em relação aos artefatos que eram gerados durante o desenvolvimento dos mesmos. Partindo dessa constatação inicial, definiu-se um processo e foi adotado o dotproject como ferramenta de acompanhamento. Essas ações proporcionaram um aumento na produtividade, porém, por se tratar de um ambiente bastante particular, com uma equipe reduzida, projetos pequenos e vários deles sendo desenvolvidos em paralelo, esse processo ainda não era capaz de atender a todas as necessidades de acompanhamento e documentação. Desse modo, buscou-se, com este trabalho, definir um processo de desenvolvimento, denominado PX, que seja mais adequado para o ambiente apresentado, proporcionando maior controle e acompanhamento de cada projeto. Para isso, se fez necessária a avaliação de um processo de desenvolvimento. Por ser um dos processos formais de desenvolvimento mais utilizados e documentados, o RUP (Rational Unified Process), definido pela empresa Rational, foi escolhido para servir de base para a solução elaborada por este trabalho. Da mesma forma, a UML (Unified Modeling Language), notação gráfica para a representação visual das soluções elaboradas vinculadas à especificação de um sistema, foi selecionada para a documentação do processo e dos projetos desenvolvidos com ele. O texto prossegue apresentando o referencial teórico, seção 2, a solução implementada, na seção 3, o estudo de caso, seção 4, e, finalmente, as conclusões sobre o trabalho, na seção Referencial Teórico O RUP é um framework de processo, ou seja, permite que o seu conjunto de fases, fluxos de trabalho, artefatos e elementos possa ser adaptado conforme necessidades específicas. Esse processo auxilia o trabalho de profissionais de desenvolvimento de software de todos os níveis hierárquicos e com as mais variadas atribuições. Para cada um dos envolvidos, o RUP define funções (responsabilidades associadas) e formas de melhor desenvolvê-las (IBM, 2008). Ao contrário do que se vê em processos tradicionais de desenvolvimento de software, no RUP é proposto que o trabalho seja feito aos poucos. Isso significa que, por exemplo, nem toda a implementação precisa estar concluída antes que os testes possam ser iniciados. Ao organizar o desenvolvimento em iterações, é possível desenvolver porções menores de uma tarefa em cada etapa, passá-la para a etapa seguinte e na próxima iteração, além de completá-la, revisá-la e ajustá-la quando necessário (KRUCHTEN, 2003).

3 Observa-se ainda que o RUP caracteriza-se por ser um processo iterativo, onde os artefatos gerados são frequentemente alterados. Para que seja possível entender o estado atual de um determinado artefato, é necessário que as alterações feitas possam ser localizadas (KRUCHTEN, 2003). Para que o trabalho funcione de maneira satisfatória, é necessário que todo o ciclo de vida do projeto seja planejado, definindo-se como todas as atividades serão conduzidas. Assim, os problemas são identificados antecipadamente e proporcionando uma solução mais simples e de menor impacto no produto final do projeto. Da mesma forma, a cada iteração, os erros e acertos do processo podem ser identificados, permitindo a sua melhoria (KRUCHTEN, 2003). Outro fator que deve ser observado é que a falta de gerenciamento de requisitos em um projeto de desenvolvimento de software pode causar atrasos nas entregas, frustrações dos envolvidos e insatisfação de todos os interessados. Com relação à prática do gerenciamento de requisitos, o RUP propõe que todos os envolvidos tenham conhecimento dos requisitos do sistema. Desta forma é possível garantir maior qualidade do produto, pois todos sabem o que podem esperar dele e todos os envolvidos têm conhecimento das modificações que o projeto sofre (KRUCHTEN, 2003). Considerando a proposta do RUP, entende-se que a definição da arquitetura de um software deve ser a base para todas as demais etapas do seu desenvolvimento. Para tanto, fornece um conjunto de regras, restrições e diretrizes que permitam chegar à arquitetura mais adequada para o software em questão (KRUCHTEN, 2003). É a arquitetura do sistema que dirá como seus componentes serão integrados. Componentes são módulos ou partes, com funções bem definidas, de um sistema. O desenvolvimento iterativo e incremental permite que os componentes sejam identificados e definidos aos poucos. Assim, permite-se que a arquitetura do sistema seja articulada de forma simplificada, proporcionando uma flexibilidade que pode garantir que a integração aconteça do modo que foi planejada (KRUCHTEN, 2003). Outro elemento muito utilizado pelo RUP é o uso de modelos visuais, os quais buscam auxiliar na compreensão do problema que deve ser atendido pelo software a ser desenvolvido. Os modelos podem funcionar como uma simplificação da realidade, ampliando as possibilidades de entendimento do funcionamento que o software deve apresentar (KRUCHTEN, 2003). O RUP utiliza a UML para estabelecer formas padronizadas de planejamento de um software. Ela possibilita tanto a especificação de itens conceituais como regras de negócios e de funções do sistema, como a de itens concretos como classes a serem escritas em uma determinada linguagem (KRUCHTEN, 2003). Além desses conceitos, este processo utiliza disciplinas, fases e papéis que permitem um gerenciamento mais efetivo do desenvolvimento do software. As fases indicam a linha de tempo do desenvolvimento de um projeto e as disciplinas agrupam as ações que precisam ser realizadas durante todo o processo. Elas estão divididas em: iniciação, elaboração, construção e transição (eixo horizontal). Já as disciplinas compreendem: modelagem de negócios, requisitos, análise e projeto, implementação, teste, implantação, gerenciamento de configurações e mudanças,

4 gerenciamento de projetos e ambiente (eixo vertical). Esta organização encontra-se esquematizada na Figura 1 (IBM, 2008; KRUCHTEN, 2003). Figura 1 fases e disciplinas do RUP Fonte: IBM, 2008 Devido à característica iterativa e incremental do RUP, praticamente todas as disciplinas estão presentes em cada uma das fases. Porém, de acordo com o objetivo principal de cada fase, as disciplinas aparecem com maior ou menor intensidade (IBM, 2008; KRUCHTEN, 2003). A fase de iniciação é onde se deve atingir o consenso entre todos os envolvidos sobre os objetivos do projeto que está sendo iniciado. Normalmente, essa fase é mais longa em projetos de softwares novos, pois existem maiores riscos de negócio e requisitos (IBM, 2008). As disciplinas mais presentes nesta fase são as de modelagem de negócio e de requisitos, justamente por que essas disciplinas realizam o levantamento de informações necessárias para o desenvolvimento de um software. Elas abrangem todo o entendimento do problema inicial que leva à necessidade de desenvolvimento, e o conhecimento e a identificação de como esse problema precisa ser trabalhado (IBM, 2008; KRUCHTEN, 2003). Na fase de elaboração, a principal disciplina é a de análise e projeto. Nessa fase deve ser elaborada a arquitetura de software, que servirá de base para todo o restante do projeto. Devem também ser elaborados os artefatos de projeto como diagramas de casos de uso, modelos de classes e de dados, e suas especificações (IBM, 2008; KRUCHTEN, 2003). A fase de transição do RUP é a fase em que o software é entregue aos usuários. Ao final dela, todos os objetivos do projeto devem ter sido atingidos. As disciplinas que aparecem com maior intensidade nessa fase são as de implantação e de gerenciamento de configurações e mudanças. Essas disciplinas atendem às necessidades de pequenos

5 ajustes que podem se mostrar necessários no software quando da entrega e configurações, tanto do próprio software, como do ambiente em que ele será executado (IBM, 2008; KRUCHTEN, 2003). As disciplinas de gerenciamento de projetos e ambiente estão presentes em todas as fases do processo, pois elas tratam de questões como organização de equipe, alocação de recursos e do próprio ambiente de trabalho (IBM, 2008; KRUCHTEN, 2003; SPM, 2008). Levando em consideração a forma como o RUP se organiza e a recomendação para que o processo, antes de ser utilizado, seja sempre adaptado ao projeto, pode-se concluir que uma adaptação dele para um determinado ambiente de desenvolvimento é possível, como detalha a próxima seção (IBM, 2008; KRUCHTEN, 2003). 3. Solução Elaborada A partir da análise do RUP, pode-se concluir que ele pode ser adaptado conforme as necessidades, ou de acordo com o ambiente em que será aplicado. Sendo assim, resolveu-se, neste trabalho, realizar uma customização do RUP para se adequar ao ambiente de desenvolvimento da RMES. O primeiro passo foi a escolha de um dos projetos que precisava ser desenvolvido para se fazer um teste de utilização do RUP. Por estar sendo feita uma tentativa de aplicação do processo da Rational, o desenvolvimento deste projeto foi executado de uma forma muito diferente do habitual. Durante todo o trabalho foi avaliada a relevância de cada artefato, tarefa e papel propostos no RUP. O resultado desse teste confirmou a necessidade de adaptação do RUP para situações específicas. Na grande maioria das avaliações, tarefas, artefatos e papéis foram modificados. Poucos artefatos foram adequados ao desenvolvimento do projeto na forma como são propostos no RUP. Em alguns casos, concluiu-se que alguns dos artefatos, por conterem informações relacionadas, puderam ser unificados. Outros, em função do porte do projeto, não se mostraram necessários ou foram modificados para se tornarem mais simples de serem trabalhados. Como se trata de um ambiente com uma equipe reduzida, vários papéis foram acumulados por cada um dos envolvidos no projeto. Mesmo assim, as pessoas conseguiram atender às demandas de forma satisfatória, pois o porte dos projetos neste ambiente também é pequeno. De uma forma geral, as tarefas propostas no RUP se mostraram adequadas. Contudo, devido ao porte do projeto, algumas delas puderam ser realizadas ao mesmo tempo, outras precisaram ser modificadas para atender à agilidade do projeto e algumas não se mostraram necessárias por gerarem artefatos que já haviam sido descartados. Reunindo as informações obtidas na análise teórica do RUP e nos testes realizados, foi formulada uma proposta de processo de desenvolvimento de software, o PX, proposto para atender às necessidades do ambiente de desenvolvimento específico da RMES.

6 Inicialmente, é importante observar que a nomenclatura utilizada no RUP para identificar os elementos envolvidos em um processo de desenvolvimento de software foi mantida com o intuito de facilitar o entendimento. Convém salientar os fatores que distinguem o ambiente escolhido para esta adaptação de processo dos demais ambientes: porte dos projetos (que são bem pequenos); tamanho da equipe (bem reduzida) e número de projetos desenvolvidos em paralelo (sempre mais de dois). Assim como no RUP, o PX está organizado em disciplinas. Devido às características dos projetos da RMES: escopo e tempo de desenvolvimento reduzidos; percebeu-se que apenas três disciplinas seriam suficientes para sua composição. As disciplinas do RUP, foram agrupadas de acordo com as características das tarefas que compoe cada uma delas. análise abrange as atividades que no RUP eram distribuídas entre as disciplinas de modelagem de negócios, requisitos e análise e projeto. Durante esta disciplina, deve ser feita toda a modelagem do software, iniciando pela análise de negócio até a modelagem de dados, passando por todas as etapas de levantamento de requisitos, necessidades de usuários, definição da interface gráfica e modelagem e especificações em nível de análise e projeto. Ou seja, devem ser as tarefas definidas desde o momento da solicitação de desenvolvimento de um novo software, até o início da sua implementação; desenvolvimento nessa disciplina estão compreendidas as tarefas das disciplinas de implementação, testes e implantação do RUP. Além da codificação propriamente dita, essa disciplina deve atender às necessidades de teste e de ajustes que em função deles possam se mostrar necessários. Além disso, deve garantir que sejam realizados testes pelos usuários finais no ambiente de homologação. Por fim, o software deve ser colocado em produção para que sua utilização se inicie; gerenciamento é a disciplina que deve tratar das questões de ambiente e do gerenciamento do projeto em desenvolvimento. Ela agrupa as disciplinas de gerenciamento de projetos e ambiente, propostas pelo RUP. As tarefas de aprovação de projetos, entregas, definição de equipe e organização e acompanhamento do trabalho devem ser atendidas por esta disciplina. Da mesma forma que o PX se apresenta com apenas três disciplinas que abrangem todas as disciplinas do RUP, foram definidos apenas quatro papéis para o PX: supervisor, analista de projetos, programador e projetista de interface gráfica. Para que o trabalho seja possível, cada envolvido deverá desenvolver tarefas que no RUP são realizadas por várias pessoas. O supervisor assume as responsabilidades de vários papéis propostos no RUP: administrador de sistemas, analista de teste, coordenador do projeto, revisor, revisor de gerenciamento e revisor técnico. Ele deve ser o principal responsável pelo gerenciamento dos projetos, e seu papel é muito importante no que diz respeito à organização dos projetos que serão desenvolvidos em paralelo. É responsabilidade dele a designação dos envolvidos em cada um dos projetos, com atenção especial aos cronogramas de trabalho, para que não aconteça de a mesma pessoa ter mais de uma tarefa designada para o mesmo tempo de trabalho em projetos diferentes.

7 Cabe ainda a este papel garantir que os envolvidos em cada projeto tenham à sua disposição os recursos e condições necessárias para o desenvolvimento do seu trabalho. Antes de cada envolvido iniciar suas tarefas, é preciso verificar se os aplicativos que serão utilizados estão instalados, se o hardware disponível é adequado e se o tempo e o espaço físico são suficientes para a execução das tarefas nos prazos determinados. Boa parte dos contatos feitos com os solicitantes de um projeto é feita pelo supervisor. Todas as tarefas de negociações e definições burocráticas relativas aos projetos devem ser feitas pelo supervisor. Definições de prazos, aprovações de início de desenvolvimento, entregas e verificações de homologações são algumas dessas tarefas. Por existirem sempre vários projetos em desenvolvimento e somente um supervisor, algumas tarefas de gerenciamento são realizadas por ele em conjunto com outro papel definido por este processo. As tarefas de designação de trabalho, acompanhamento de testes com usuários, análise de resultados de testes, revisões de planejamento e relato do status de projeto são realizadas juntamente com o analista de projetos. Além disso, a analista de projetos trabalha mais próximo à equipe de desenvolvimento dos projetos, por isso essa divisão de responsabilidade para algumas tarefas se torna conveniente. O analista de projetos é o principal responsável pela modelagem de negócios, levantamento de requisitos, análise e projeto de software. Entre os papéis propostos no RUP, ele assume os de analista de sistemas, analista de teste, arquiteto de software, especificador de requisitos, projetista e projetista de banco de dados. A disciplina em que o trabalho do analista de projetos mais aparece é a disciplina de análise. Seu trabalho começa com a coleta de informações com os solicitantes e passa por todos os níveis de modelagem, análise e projeto até chegar aos programadores. Nessa etapa ele deve cumprir as tarefas de criação de modelos de negócios, desenvolvimento do documento de projeto, avaliação de riscos, criação de diagramas de casos de uso, modelos de classes em níveis de análise e projeto, modelos de dados, e criação das especificações de todos os artefatos gerados. No PX, os papéis de implementador e testador proposto pelo RUP, são desempenhados por apenas um papel, o programador. Há, porém, a necessidade de observar para que haja sempre dois programadores, no mínimo, envolvidos em cada projeto, pois a implementação e os testes não devem ser realizados por uma única pessoa em um mesmo projeto. Além disso, o programador pode, eventualmente, auxiliar o analista de projetos em ajustes da modelagem. Pequenas modificações nos modelos de classes de projeto e modelos de dados podem ser propostas pelo programador e acatadas ou não pelo analista de projetos. O quarto papel proposto no PX é o de projetista de interface gráfica com o usuário, equivalente ao papel de mesmo nome, proposto no RUP. Ele é um especialista em interfaces gráficas e sua tarefa principal é a de projetar uma interface adequada para a utilização do software por seus usuários finais.

8 Durante o desenvolvimento do projeto, o projetista de interface, precisa criar um protótipo da interface para que ela possa ser apresentada aos solicitantes para avaliação. Da mesma forma que o RUP, essa nova proposta de processo coloca que um projeto deve ser desenvolvido de forma iterativa e incremental. Pelo porte dos softwares desenvolvidos com este processo, não são planejadas várias iterações, mas cada etapa pode ser revisada sempre que identificada a necessidade de um ajuste ou uma alteração. Ainda como consequência do porte dos projetos, no PX não é contemplada uma disciplina para tratar de mudanças de requisitos. Como o desenvolvimento dos projetos é relativamente rápido, mudanças desse tipo são tratadas como novos projetos. Ao existir a necessidade de desenvolvimento de um software, o analista de projetos deve receber a solicitação de desenvolvimento. Deve se reunir com os solicitantes e procurar obter o maior volume possível de informações sobre o que será necessário para o novo projeto. A organização dessas informações deve resultar no documento de solicitação. Esse artefato deve conter, além das necessidades do software, as informações de identificação do solicitante e a justificativa da solicitação, ou seja, uma descrição da situação existente que o sistema deverá melhorar. A partir do documento de solicitação, o analista de projetos pode trabalhar no desenvolvimento do diagrama de casos de uso de negócio. Essa tarefa consiste em, de forma técnica e detalhada, definir o problema a que o software se propõe a solucionar, identificar os envolvidos no problema e como o software tentará se aproximar da solução ideal. Essa tarefa deve resultar em dois artefatos: o diagrama de caso de negócio e o documento de projeto. O diagrama de caso de uso de negócio é gerado com a utilização de um dos diagramas da UML, que é a forma visual de organizar as informações geradas na tarefa de desenvolver o caso de uso de negócio. O documento de projeto consiste na descrição de todos os detalhes já definidos do projeto até o momento. Ele deve conter todas as informações que existem no documento de solicitação e também as informações geradas no desenvolvimento do caso de uso de negócio. Esse documento será modificado várias vezes durante todo o projeto, cada definição ou alteração deve ser registrada nele. A seguir, devem ser identificadas e priorizadas as solicitações dos envolvidos. Para isso é necessário que seja entendido quem são essas pessoas e o que esperam do software. Com isso, pode ser elaborado um esboço sequencial das funções do software. Reunindo a documentação gerada nas tarefas já cumpridas, o analista de projetos deve identificar e avaliar os riscos do projeto. Com os riscos identificados, é possível planejar o desenvolvimento do projeto incluindo a forma de preveni-los ou tratá-los durante o desenvolvimento. Também deve ser feita, com apoio do supervisor da equipe, a definição das pessoas que trabalharão no projeto e que função cada uma delas deverá desempenhar no seu desenrolar. Essas informações devem ser registradas no documento de projeto e na ferramenta de acompanhamento. A partir desse momento, as atividades do projeto podem ser iniciadas de fato. Cabe ao supervisor avaliar como e quando ele deve ser iniciado, observando que a equipe somente inicia os trabalhos depois que a liberação é formalizada.

9 Uma vez autorizado o início do projeto, o analista de projetos deve trabalhar para que o documento de projetos contenha todas as informações necessárias para que possa ser aprovado pelos solicitantes. É necessário apresentar informações sobre as funções do software, sobre questões que o software não atenderá, prazos e pessoas com quem os solicitantes poderão fazer contato para tratar a respeito do projeto. Cabe ao supervisor a apresentação do documento e o registro de sua aprovação na ferramenta de acompanhamento. Ao buscar a aprovação do documento de projeto, o supervisor retorna com informações de possíveis solicitações recebidas dos solicitantes. Essas informações devem ser repassadas ao analista de projetos que irá registrá-las no documento de projeto sob o título de especificações suplementares. Essas informações não devem resultar em modificações de escopo e requisitos do software, mas sim em pequenos ajustes nas funcionalidades propostas para ele. Mudanças de maior impacto devem ser tratadas como novas solicitações de desenvolvimento, e podem ou não resultar no cancelamento da solicitação anterior. Caberá ao supervisor e aos próprios solicitantes a avaliação de como a situação será tratada. Iniciado o projeto, devem ser identificados atores e casos de uso. O analista de projetos deve identificá-los, estruturá-los em um diagrama e descrever cada um deles. A descrição deve ser detalhada o suficiente para que seja possível a compreensão por todos os envolvidos no projeto. Para finalizar a análise do software, o analista de projetos deve elaborar um mapa da aplicação, que deve conter as possíveis telas do software com as funcionalidades que cada uma deve conter. A realização desta tarefa permite que o analista de projetos faça a priorização dos casos de uso. Nesse ponto, de posse do modelo de caso de uso e do documento do projeto, é importante que o supervisor faça a revisão dos requisitos do projeto. Os demais artefatos gerados também devem ser levados em consideração nessa revisão. Caso haja algum ajuste a ser feito quanto aos requisitos do software em desenvolvimento, ele deve ser realizado nesse ponto. Assim, é possível evitar que uma atividade, que compreende um pequeno ajuste naquele momento, se torne uma mudança maior em um ponto mais avançado do processo. Com os requisitos revisados, a equipe pode dar início à etapa de análise de projeto do software. Enquanto o projetista de interface trabalha no projeto da interface gráfica do software e, posteriormente, em um protótipo dela, o analista de projetos deve trabalhar na análise e no projeto de casos de uso, gerando os modelos de classes em nível de análise e de projeto. Ao finalizar esses modelos, cabe ainda ao analista de projetos, elaborar uma especificação de cada uma das classes no modelo de classes de projeto. Com isso, ele terá condições de elaborar o modelo de dados para o software. Antes do início da implementação do software, o supervisor deve, junto aos solicitantes, buscar a aprovação da interface gráfica, utilizando o protótipo criado. Essa aprovação permite que o programador tenha conhecimento de como os elementos que ele irá implementar deverão interagir com os usuários. Assim ele já pode tratar disso

10 enquanto elabora esses elementos, diminuindo a necessidade de ajustes na finalização do software. Após a implementação de cada elemento, o programador deve realizar os testes de desenvolvedor e a revisão do código. É importante que nessa revisão esteja incluída a documentação do código. Além dos testes feitos pelo programador que implementou os elementos, é necessário que seja realizado um conjunto de testes por outro programador, que deve ser orientado pelo analista de projetos do projeto em questão. Os testes feitos devem se aplicar a cada elemento e, posteriormente, ao software como um todo. Ao ser finalizado com sucesso o conjunto de testes, o software deve ser colocado em um ambiente de homologação. O ambiente de homologação deve ser uma cópia fiel do ambiente onde o software será executado quando estiver em uso (software em operação). Os envolvidos responsáveis pelos testes devem, novamente, testar o software nesse ambiente. Com o sucesso desses novos testes, o supervisor pode solicitar aos futuros usuários que realizem os testes de usuários, que compreendem o uso do software por um conjunto de usuários, como se o software já estivesse em operação. Dessa forma é possível que eles utilizem todas as funções do software e tenham segurança de que todas irão funcionar quando o estiverem utilizando em seu dia-a-dia. O analista de projetos e o supervisor devem acompanhar os testes de usuários e determinar seus resultados a partir dos retornos recebidos dos usuários. Quando os testes forem bem sucedidos, o software estará pronto para ser entregue. A entrega consiste em colocar o software em ambiente de produção, ou seja, no ambiente em que será executado para ser utilizado pelos usuários. Além das tarefas que foram descritas, o processo ainda propõe algumas que não têm um ponto específico do processo para a sua realização. Elas devem acontecer em vários pontos do desenvolvimento do projeto, ou sempre que forem necessárias. Este grupo corresponde a grande parte das tarefas da disciplina de gerenciamento e cabem ao supervisor e ao analista de projeto. Ao supervisor cabe a condução da revisão e o suporte ao desenvolvimento. Ele deve orientar todos os envolvidos sobre como realizar as revisões necessárias durante todo o processo e deve criar as melhores condições possíveis de trabalho para a equipe. Ao analista de projetos cabe, em conjunto com o supervisor, a revisão do planejamento do projeto e os relatos de status do mesmo. Estas duas tarefas devem ser feitas constantemente, para que seja garantido um planejamento que atenda às necessidades do projeto e da equipe nele envolvida e para que os interessados no projeto estejam sempre cientes do seu andamento. A Figura 2 esquematiza o fluxo de como o processo deve funcionar. Por uma questão de visualização do processo, o fluxo segue sempre em uma única direção. Contudo, potencialmente, cada uma das tarefas apresentadas pode ter um retorno para qualquer uma das suas predecessoras, caso alguma necessidade de ajuste seja identificada. As disciplinas e papéis estão identificados à direita da Figura 2. Em cada

11 uma das tarefas estão indicados os papéis responsáveis, o principal responsável à esquerda e o secundário à direita. Figura 2 Fluxo do Processo Com a definição da proposta de processo de desenvolvimento, o próximo passo consistia em eleger projetos que estivessem em pauta para desenvolvimento e aplicá-lo. A seção seguinte mostra como isso foi feito e os resultados obtidos. 4. Estudo de Caso Para permitir uma avaliação consistente da aplicação do PX, o primeiro passo foi o registro de suas disciplinas, tarefas, artefatos e papéis na ferramenta de mapeamento de processos EPF Composer. Este registro permitiu que fosse obtido um panorama mais amplo de como o processo se estrutura e como os seus elementos interagem e influenciam uns aos outros. Além disso, a ferramenta oferece recursos que permitem

12 que cada elemento seja descrito com mais detalhes, dando consistência ao PX e subsídios para o trabalho dos participantes dos projetos. A Figura 3 ilustra a tela de visualização da disciplina de gerenciamento do PX na ferramenta EPF Composer. Destaca-se que todas as disciplinas para o PX foram registradas nesta ferramenta. Figura 3 Tela de visualização da disciplina de gerenciamento. Assim, as tarefas puderam agregar informações sobre objetivos, pré-requisitos e condições para sua realização. Foi possível descrever as características necessárias das pessoas que irão executar cada um dos papéis e ligá-los às tarefas das quais participam e aos artefatos que geram ao realizá-las. Da mesma forma, foram registradas descrições detalhadas dos artefatos e eles foram ligados (associados) às tarefas e aos seus responsáveis. Com esta visualização mais abrangente do PX, o supervisor da equipe pode montar um formulário que permitiu o controle de realização e eficácia de cada tarefa. Para cada tarefa proposta no PX, durante o desenvolvimento dos projetos, foi informado o seu status (ou seja, se ela havia sido realizada), o executor e os principais artefatos que foram utilizados e gerados durante sua execução. O objetivo da utilização do EPF Composer e desse formulário foi o de se obter um parâmetro de comparação para que ao

13 final da execução dos projetos fosse possível verificar se o PX havia ou não se mostrado eficiente, se as tarefas ocorreram conforme o proposto, se os artefatos foram gerados e utilizados, e se os envolvidos realizaram aquilo que estava previsto para cada um dos papéis. Como o PX foi proposto para um ambiente onde vários projetos podem ser desenvolvidos em paralelo, para verificar sua eficiência foram selecionados os dois projetos com maior prioridade para a RMES no período dessa verificação. Os projetos selecionados compreendem: Diário de Classe e Controle EAD, ambos na sua segunda versão de elaboração. O sistema Controle EAD já estava sendo planejado quando a verificação foi iniciada. Os dois sistemas foram projetados para serem desenvolvidos com a linguagem PHP e com o SGBD (Sistema de Gerenciamento de Banco de Dados) Oracle. A modelagem de cada um dos sistemas foi realizada utilizando como ponto de partida a base de dados do sistema acadêmico utilizado, atualmente, pela Instituição. O sistema Controle EAD tem como foco gerenciar a alocação dos alunos matriculados em disciplinas à distância, nas salas de aula do ambiente virtual. Os alunos de várias turmas, de uma mesma disciplina, são agrupados de acordo com a área de conhecimento de seus cursos e, posteriormente, distribuídos em salas virtuais com até sessenta alunos cada. Assim, com essa forma de alocação dos alunos é possível que exista interação com alunos de outros cursos de áreas afins. Além disso, o sistema Controle EAD também faz o registro das aulas presenciais que ocorrem durante o semestre e controla as inscrições dos alunos nesses encontros, as quais são realizadas através do portal da Instituição. Já o sistema Diário de Classe é utilizado para o controle de presenças, avaliações, notas e conteúdos das turmas de educação superior da RMES. Cada um dos diários é criado a partir de uma turma, ou de uma sala virtual, consultando, respectivamente, a base de dados do sistema acadêmico, ou do sistema Controle EAD. Além do registro das informações das aulas e avaliações realizadas, o sistema Diário de Classe permite aos professores a criação de avaliações online, publicação de material de apoio para as disciplinas ministradas, disponibilização do plano de ensino e o envio de mensagens aos seus alunos. Como o projeto do sistema Controle EAD já estava iniciado, foi necessário identificar a partir de qual tarefa o PX poderia ser aplicado. Para viabilizar esta identificação, a estratégia adotada foi a de validar se os objetivos de cada tarefa já haviam sido atingidos. Após essa validação, foi identificado que o PX deveria ser aplicado ao sistema Controle EAD a partir da tarefa Desenvolver Especificações Suplementares. Deste ponto em diante, todas as tarefas puderam ser executadas e validadas como estava previsto no PX e no planejamento dos testes. Em relação ao projeto do sistema Diário de Classe, foi possível a validação das tarefas propostas no PX desde o seu início. A tarefa de receber a solicitação do projeto foi feita com a realização de uma reunião com os solicitantes do projeto, onde as informações previstas pelo PX foram coletadas. Já a partir dessa tarefa, o formulário elaborado para a validação do novo processo foi preenchido.

14 Durante quase todo o desenvolvimento dos projetos, a aplicação e a validação do PX se deu da forma planejada. Por ser um processo simplificado e proposto para o ambiente de desenvolvimento da RMES especificamente, o PX permitiu controle e acompanhamento eficientes dos projetos. Para o supervisor e o analista de projetos, esse foi o principal benefício trazido pelo PX. No que tange ao sistema Controle EAD, o obstáculo encontrado mais difícil de ser transposto foi a mudança na forma de trabalho da equipe. Além do acompanhamento da execução das tarefas previsto no PX, foi necessária também uma maior aproximação entre o supervisor e os demais membros da equipe de trabalho para garantir que não só os objetivos de cada tarefa fossem atingidos, mas que a forma de executá-la e documentá-la se desse da maneira como o PX propõe. Tarefas, artefatos e papéis propostos no PX se mostraram eficientes para o desenvolvimento do projeto do sistema Controle EAD. Porém, em relação ao sistema Diário de Classe, a definição do PX sobre tarefas e programadores envolvidos não se mostrou completamente adequada. Com um escopo um pouco mais amplo e com tempo relativamente menor para ser desenvolvido, o sistema Diário de Classe demandou algumas modificações na etapa de implementação do projeto. Assim, dois programadores trabalharam juntos na implementação do sistema. Além disso, as tarefas de implementação, revisão de código e de execução, acompanhamento e avaliação de testes precisaram ser organizadas em iterações. O modelo de processo proposto já previa que fosse possível o retorno a tarefas anteriores para ajustes, mas com este sistema foi necessário um planejamento mais consistente dessa volta. A fase na qual os programadores trabalham mais efetivamente precisou ser redefinida para que o projeto fosse desenvolvido aos poucos, de forma incremental e organizada em iterações. De fato, as tarefas definidas permaneceram as mesmas para os programadores, mas foi necessária a inclusão de mais três tarefas. Duas para o analista de projetos: o planejamento de iterações de implementação e a definição de cada iteração; e uma para o analista de projetos em conjunto com o supervisor: a homologação final dos usuários. 5. Conclusão Apesar de esta primeira aplicação do processo de desenvolvimento ter demandado mais tempo de trabalho com documentação e registro de tarefas, ficou claro que a equipe trabalhou com mais confiança no que estava sendo realizado. Todos os envolvidos tinham, a qualquer momento, a possibilidade de verificar em que estado se encontrava cada um dos projetos. Com maior controle em relação aos trabalhos realizados, tornou-se mais fácil a identificação e o tratamento de falhas nos projetos. Portanto, mesmo sendo esta nova forma de trabalho mais burocrática do que aquela que a equipe da RMES tinha por prática, o trabalho tornou-se mais eficaz. Além das possibilidades de controle e

15 conhecimento do status dos projetos, a sua finalização se tornou mais fácil de ser atingida. Com os processos testados anteriormente no mesmo ambiente, os problemas, falhas e inconformidades só eram detectadas em fase muito adiantada do desenvolvimento, o que gerava retrabalho e atrasos bem maiores na entrega dos sistemas. Como foi colocado no Estudo de Caso, o processo ainda apresenta pontos em que ele pode ser melhorado, tais como o trabalho com iterações. Porque, mesmo abordando projetos de pequeno porte, o trabalho com iterações facilita o planejamento e o entendimento de um projeto de desenvolvimento. O escopo de cada iteração é reduzido, e as tarefas a serem cumpridas são em menor quantidade, tornando mais fácil de compreender e desenvolver o que está sendo proposto. Mesmo que a intenção seja aplicar um processo de desenvolvimento sempre ao mesmo ambiente e equipe de desenvolvimento, cada projeto tem características próprias e necessidades distintas de qualquer outro. Sendo assim, um processo de desenvolvimento pode ser utilizado como um guia para o trabalho de desenvolvimento, mas os responsáveis pelo projeto não devem engessar a forma de trabalho para atender ao processo eleito. O processo de desenvolvimento deve ser utilizado para orientar e sugerir formas de trabalho e controle, mas quem planeja um projeto deve ter espaço para fazer ajustes ou adaptações de tarefas e artefatos, e para alocar a equipe de trabalho conforme as necessidades do projeto em questão. Durante a elaboração do estudo de caso aplicado, observou-se que a ferramenta proposta para ser implementada não apresentava controles mais eficientes do que algumas das existentes. Assim, julgou-se mais adequado a utilização do EPF Composer, a ferramenta de mapeamento de processos, em paralelo com o formulário de validação do PX e o dotproject, que foi utilizado para o registro das tarefas dos programadores. Para um trabalho futuro, a ferramenta planejada neste estudo, deverá ser remodelada a fim de atender às adaptações que foram feitas no PX durante a execução do estudo de caso. A nova modelagem da ferramenta deverá permitir a utilização do PX de forma mais flexível e realizando um controle mais específico das tarefas realizadas, dos artefatos gerados e da equipe envolvida. Acredita-se que, com a adição desses controles, seja possível criar uma base de conhecimento para melhorar o planejamento de projetos futuros, dando mais subsídios ao analista de projetos e ao supervisor. Com esta base de conhecimento à disposição, torna-se mais simples fazer projeções de tempo necessário para as tarefas, dimensionar a equipe de forma mais adequada e fazer as adaptações necessárias ao processo para cada projeto desenvolvido.

16 Referências IBM (2008) Rational Unified Process, ibm.com/software/awdtools/rup, Maio. IBM (2008) Software Project Management: A Mapping between RUP and the PMBOK, Outubro Kruchten, P. (2003), Introdução ao RUP: Rational Unified Process. Rio de Janeiro, Ciência Moderna.